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

はさみストーリー

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

次の日...

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

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

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

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

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

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

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

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

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

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

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

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

There is the problem "A" first,
And the solution "B" is needed for "A",
And the solution "C" is needed for "B",
And the solution "D" is needed for "C",

"Do you know how to do "D"?"

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

なので、質問するときは...
(So when you ask a question...)

その質問をするきっかけとなった、ストーリーも一緒に添えて
(Also tell background story of question motivator)

...

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

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

junior "Do your know where scissors are? I want to make A3 paper for meeting documents because of A4 paper short"

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

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

答えやすい質問のヒント

// 任せられるディベロッパー、七つの姿勢
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が新卒のときに、師匠にさんざん言われたことなんですよね。

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