378.質問する技術
初回：2024/08/21
私の所に質問に来る人は、本当に限られています。というか、ほとんど誰も質問に来ません。
P子「嫌われてるんじゃないの？」※1
・・・
P子「認めるんだ」
とはいうものの、『結果には、すべて原因がある』と信じる私としては、やはり原因について考察しておくのは悪い事ではないと思います。
1.質問者が来た時の私の対応
まず、質問者が来た時の私の対応を振り返ってみたいと思います。
以前にも書いたと思いまますが、『魚を与えるのではなく、魚の釣り方を教えよ』というのが質問者に対する私の基本スタンスなので、質問者が知りたい『答え』は言いません。自分で答えを導けるようにするには、まずは質問者がどのレベルに達しているかを確認する必要があります。『釣り方を教える』にしても、竿も持っていない、エサの付け方や選び方も知らない、漁場も知らない...では、教える以前の問題です。さらに言うと、どんな魚が欲しいのかさえ知らない場合もあります。
すると、最初にすべきは、質問者の知識レベルを確認するために、こちらから色々と質問することになります。
質問者A：「システムが動かないんです」
私：「サーバーの電源は入ってるの？」
質問者A：「そんなの当たり前でしょ。バカにしてるんですか？」
私：「プロキシの設定とか出来てます？」
質問者A：「はあ？ピロシキ？」
P子「無理やりに作った会話ね」
まあ、エンジニアライフをご覧の皆様なら、こんな低レベルな会話にはならないと思いますが、昔は『動かない』としか情報を提供しない質問者もいました。それもシステム開発者側の人間です。Webアプリケーションを扱っているので、動かないだけでは、サーバー側で起動しないのか？クライアントで動かないのか？サーバーのlocalhostでは動くのか？他のユーザーでも同じなのか？
この辺りは本来は質問者が最初に自分で確認しておくべき項目でしょう。
最近、システムのプログラムを変更したのか？ サーバーに、何かインストールしたのか？サーバーにパッチやWindowsUpdateが実行されていないか？
昔あった事象では、アンチウイルスソフトが自動で更新されてスキャン方法が変更され、プリンタスプールへの入出力が対象になり印刷が遅くなるという事象がありました。そういうケースで判らないというなら判りますが、自分で何も確認せずに質問に来る場合、ひとつづつ状況を『質問』して確認する必要があります。
先の例は、『質問＝なにかトラブルを解決したい』ケースですが、『質問＝判らない事があるので理解したい』ケースもあります。
その場合も、質問者がどこまで理解できていて、何が理解できないのか？ をこちらが理解するために、最初から説明していく必要があります。このケースでは、1の質問に対して、10の説明が必要になってきます。
まとめると、
・質問者には答えは言わない。
・質問者の知識レベルを確認するために、こちらから色々と質問する
・質問者がどこまで理解できているのか判らないので、1から10まで説明する
P子「そりゃだめね。だれも質問に来なくなるわね」
とりあえず、嫌われてるから質問に来ないという事じゃないって判って、ほっとしました。
P子「ん－そうかなぁ」
2.質問する側の心構え
では、質問に来る人はどうするのが良いのでしょうか？
トラブルを解決したいケースでは、自分が何をしたのか？ どこまで調査したのかを述べる必要があるでしょう。出来れば簡潔に...です。判らない事があるので理解したいケースでは、どこまで理解できていて、どこで判らなくなっているのかを説明するのが良いでしょう。これは判らない所だけを説明するのではなく、理解できているところも含めて説明しないといけません。
P子「結構、邪魔くさいわね」
まともに質問しようとすると、準備に時間がかかります。かといって準備不足で質問に来ても、やり取りに時間がかかります。
そんな中、これらの問題を解決できるかもしれない方法を見つけました。
≪参考資料1≫
https://el.jibun.atmarkit.co.jp/densol/2024/08/post_108.html
自分の分からないことを分かるようになる魔法
Innovation "D"
2024/08/14
この中で私は、『仮説検証を実践する』という言葉に惹かれました。
質問者は『質問』に来るのではなく、自分で立てた『仮説検証を実践』した経緯を『説明』するのが良いのではないかと思いました。つまり、仮説検証した結果が自分の仮説と合わない、なぜなのか？ 仮説が間違っていたのか、検証方法が間違っていたのかを『確認』してもらいに来ればよいのではないかという事です。
この『仮説検証』を繰り返している人は、いずれ仮説の精度や検証の正確性が向上するでしょう。質問する側ではなく質問される側の人間になるでしょう。
この『仮説検証の説明』ならば、比較的短時間で済むのと、質問者がどれくらい理解しているのかも大体わかります。何より、魚を欲しているのではなく、〇〇を釣るためにエサに△△を使ったが、××だった...みたいな説明になるため、釣りの方法を教える必要性がありません。そんな場合は、こちらも仮説を立てて、△△ではなく□□なら、食いつきが良くならないか？などと手短にアドバイスできます。
また、長々と質問したり説明するのではなく、質問者に『君の仮説は？』と聞いて持っていないなら、それを立てさせ、持っているなら検証させればよいのでお互い、時間が節約できそうです。
3.まとめ
長年の疑問であった『質問者が来ない』問題について、解決策が見つかりました。
P子「いや、手遅れでしょう」
いくつになっても遅いという事はありません。
質問する側としては『仮説検証を実践』した経緯を『説明』することにより、新たな視点での検証方法を聞き出すのが、効率的な質問方法だと思います。
本来『仮説検証を繰り返す』のは、エンジニアの基本中の基本でしょう。トラブル対応であっても、新製品の開発であっても『仮説検証』は大切です。
ただ、最近のタイムパフォーマンス重視の世の中では、『仮説検証』に時間がかけられなくなってきている気がします。一発正解以外は認めない...みたいな。ただ、一発正解が手段ではなく目的化してしまうと、一発正解できることだけをするようになる...つまり、新しい事にチャレンジしなくなってしまいます。このことの方が気がかりです。
P子「タイムパフォーマンスも重要だけど、時には時間がかかることにも取り組まなくっちゃね」
ほな、さいなら
======= <<注釈>>=======
※1 P子「嫌われてるんじゃないの？」
P子とは、私があこがれているツンデレPythonの仮想女性の心の声です。