質問のコツその一: なんでその質問してるのか?も伝えよう

はさみストーリー

後輩「はさみ、どこかわかります?」
先輩「えっ、はさみ?
 えーっと、誰も使ってなければあっちの棚の上かな」
後輩「ありがとうございます、さすが先輩!」
先輩「...」

次の日...

先輩「そいえば、はさみあった?」
後輩「えっと、まだいま探してます、徹夜で探してて」
先輩「いやいやいやいや、棚の上は?」
後輩「誰か使ってるみたいなので...誰かっての探してて」
先輩「にしても、はさみを探すだけで徹夜ってまじかよ。もう買って来ちゃえばいいじゃん」
後輩「おおぉ、さすが先輩!そうします。やったー解決だー」

先輩「てゆーか、なんではさみ必要なの?」
後輩「A4の紙が切れてて、余ってるA3を切ってA4にしようかと」
先輩「いやいや、したらはさみじゃなくても、少ない枚数だったら折って手で切っちゃうとか、そもそも多いんだったら裁断機じゃないとつらいでしょ」
後輩「おおぉ、さすが先輩!そうします。やったー解決だー」

先輩「てゆーか、なんでA4じゃないといけないの?B4やB5はあるよ」
後輩「会議の資料がいつもA4だったのでA4じゃないといけないのかなって」
先輩「いやいや、別に伝わればいいでしょ、B5でもいいんじゃない」
後輩「おおぉ、さすが先輩!そうします。やったー解決だー」

先輩「てゆーか、紙じゃないといけないの?チャットの添付とかで事前に資料配布して見ておいてもらうとか。紙切れだってことで今回はそういう風にさせてくださいって、会議のリーダーに了承取れればそういうのもアリかと」
後輩「おおぉ、さすが先輩!そうします。やったー解決だー」

先輩「てゆーか、その会議、なんの会議?」
後輩「来年度の人事戦略の方向性を決める会議です」
先輩「いやいや、今月末でこの会社倒産するから、その会議要らなくない?それよりも転職活動した方がいいよ」
後輩「おおぉ、さすが先輩!そうします。やったー解決だー」

先輩「てゆーか、君、もともと億万長者でしょ。ムリに転職活動もしなくて良くない?」
後輩「おおぉ、さすが先輩!そうします。やったー解決だー」

ということで...最初の質問の "はさみが置いてある場所" は、「わりとどうでもいい」ことがわかりました。

次の日に、先輩が気になって話しかけてくれたので、問題分析して解決案が色々と挙がってきたからよかったですが、もしかしたら、あと三日間くらいずっと、徹夜ではさみを探し続けたかもしれませんね。

(さて、もちろん、はさみは使った人は、ちゃんと元の場所に戻さないとですね。つーか、紙切れだったら総務に言えばいい!?)

道を踏み外した枝葉の質問

もともとの問題 A があり、
その解決のために B という手段が必要だけど、
それを実現するために C という手段が必要になるけど、
それを実現するために D という手段が必要で...

「Dってどうやればいいですか?」

まあ、Dまで辿り着く道のりが正しければ、特に問題はないかもしれませんが...

そもそも道を踏み外していたら

Dが解決しても根本解決にならない可能性大です。

質問を受けることが多いjfluteですが、「まあ、Dはこうだけど、なんでDが必要になったの?」と聞き返すことがほとんどです。(jfluteと一緒に仕事してる人であれば、よく知っているかと思います)

そして、問題を分析していくと、A から B と来たところで本来 C に行くのではなく、ぜんぜん違う F の方向へ行くべきだったことがわかって、解決方法もぜんぜん違うものになったり。

今回の例は非常に単純なので、普通は自分で気付くだろうと思うかもしれませんが、例えば、プログラミングの世界だったりすると、扱う問題が非常に複雑で、「進む道を間違わない人なんていない」というか間違うのが当然だと思っていたほうが良いくらいで...

常に疑っているくらいでちょうどいい

と言えます。
(これは、何年経験を積んでも持っておきたい前提です)

でも、プログラミングの世界だけとは限らないでしょう。
世の中は、複雑ですから。

(まあ、あまり本質に戻りすぎると、究極...「おれってなんのために生きてるんだろう?」「地球ってどうしてあるんだろう?」とか人類の限界を超える問題になってしまうので、ある程度の決めの前提は必要ですけど(^^)

きっかけとなったストーリー

すごく感覚値ですが、受けた質問の3割くらいは、「枝葉の質問(D)で解決すべき問題ではなかった」という印象です。残りの7割も、素直にDというよりかは、かなり特殊なケースで仕方なくDということで、その解決の実行も慎重にしないといけなかったり。

そして、その場合、大抵Dは非常に "いびつ" です。Dで解決とかあり得ない、このツールでDの機能が必要になるはずがない、とか。質問聞いた瞬間に「おかしい」って思うことがほとんど。

枝葉の質問(問題、解決案)に捕われていると、延々に解決しないかもしれません。変な解決で後でトラブルになるかもしれない。

質問を受けた側が、追求してくれたらラッキーです。本来、背景にある問題を解決する義務はないわけですから。それでも背景を聞かれるってことは気を使ってくれてる、という風にも言えますので感謝しないとですね。興味のない人が背景を聞いて来ることはないでしょう。

なので、質問するときは...

その質問をするきっかけとなった、ストーリーも一緒に添えて

...

さて、本来は、「そもそもこういう問題を抱えてまして」という風に根本の問題(A)自体にフォーカスを当てて質問と言うか相談ができたら最高かもしれません。"必ずそうしないといけない" だと、確かにちょっとフットワーク重い気もしますので、まあそこまで行かなくても...

後輩「はさみ、どこかわかります? 会議の資料作りで、A4紙切れでA3切ろうかと思いまして」

このくらい言えたら、もし変な質問でも、すぐに先輩が突っ込んでくれます。最終的に、しっかりとあるべき姿で問題が解決できたら、途中で道迷ってたとしても結果オーライなわけで。(解決スピードを上げていく努力はまた別として)

あと、質問者がちゃんと背景を見直すことで、質問する直前に「あっ、そういうことか」と自己解決するきっかけにもなります。
 => 問題の本質をたどる帰り道

答えやすい質問のヒント

// 任せられるディベロッパー、七つの姿勢
http://d.hatena.ne.jp/jflute/20170405/reliableseven

で挙げた、
「その七: 答えやすい質問をする」のヒントだったりします。

"いびつ" な枝葉の質問(D)は、聞かれた側にとっては実は答えづらいです。

単純な Yes-No だとして、
「いや、そもそも "D" が必要になることはない...」
「Yes, と言っても、そう手放しでYesってわけじゃなく...」

背景がないと、
枝葉の質問(D)に答えられないことが多いのです。

なので、一言でも背景のストーリーがあれば、その枝葉の質問(D)の意義がわかって、その質問に「ニュアンス」を付けた回答ができると。

答えづらい質問は、聞く方にストレスをかけます。これが「めんどくさいなぁ、俺に聞くな」のきっかけの一つになるわけです。答えやすい質問であれば、めんどうとは思われないわけで。本当に、質問の上手な人の質問は、気持ちがいいほどスムーズに話が進みます。これは楽しいのでぜひ質問されたいって思うものです。(jfluteも、そういう質問できるように頑張らないと...)

オープンソースの運用でも

DBFluteの質問や要望などでも今まで何度もあったと思います。

DBFluteで "D" ってできますか?」
DBFluteに "D" はありますか?」
DBFluteで "D" の機能を入れてほしいです」

多くの場合、その "D" に辿り着いた背景はなんでしょうか?と質問を返させて頂いています。

何も考えずに "D" を実装すると、DBFlute全体の機能バランスを崩し、DBFluteの機能デザインがいびつになってしまう可能性があるから。

何も考えずに "D" だけ教えると、DBFluteユーザーが本来得るべき解決を、見逃してしまう可能性があるから。

実際に、「したら、そもそも C じゃなくて F の機能を実装しますね」ということで解決したことが何度も何度もあります。

これは、オープンソースプロダクトを長生きさせていくコツの大きな一つでもあります。

...

まあ、jfluteが新卒のときに、師匠にさんざん言われたことなんですよね。

その一なので、その二もそのうち書きますね。