- 先輩に質問したら「もうちょっと聞きたいことをまとめてくれない？」と怒られた
- StackOverflowに質問したけど誰も答えてくれずしばらくして通知が届いたらdownvoteだった
- 質問しても曖昧な回答しか返ってこなくて、お互い気まずい空気が流れる
- そもそも技術系の質問するのが苦手
どれか1つでも該当する方にはこの記事が役に立つかもしれません。ちなみに僕は新人時代にフルコンボだドン
最近ではプラハチャレンジのメンターとして質問を受ける側に立つことが多いのですが、「これは答えやすい」と思う質問もあれば「ちょっと答えづらい...」と思う質問もあります。かれこれメンターとして1000個近くの質問を受けて来たので、せっかくの経験を生かしてより良い質問に繋がるチェックシートを作ってみました。
相手に十分な情報を与えているか
「プログラマが知るべき97のこと」に登場する「The Guru Myth」という章があります。直訳すると「賢者の神話」で、要は ベテランエンジニアは魔法を使って答えを導き出しているわけではない。与えられた情報から推測を重ねているだけなので、そもそも必要な情報がなければ答えは出せない ということです
「アプリケーションを動かしたけどうまく動きません。なぜでしょうか？」とだけ聞かれても、回答者としては
- 「動かす」とは何を指しているのか？
- （httpie等でAPIエンドポイントにリクエストを飛ばしたのか？ボタンをクリックしたのか？その手順をデプロイ先で実行したのか手元のPCで実行したのか？）
- 「うまく動かない」とは何を指しているのか？
- （正常に処理されたけど動きが遅いだけなのか？ビルド時にエラーが起きているのか実行時にエラーが起きているのか？どんなエラーレスポンスが返ってきているのか？）
など分からないことだらけで、答えられないんですよね...
改善策：必要な情報を与えよう
「相手は判断に足る情報を持っているか？」と考えるのが非常に大切です。例えばこんなことを工夫してみると良いでしょう：
相手が再現できる状態にする
作ったアプリケーションが「動かない」のであれば、再現手順を添えてGitHubにあげてみましょう。「もしかしたらコレが原因かもしれないからこのデータが欲しい」と回答者が考えた時、自分の手元でアプリケーションを動かせれば、必要な情報を回答者が自ら取得できるので問題解決の確率はグッと高まります
逆に回答者が手元で再現できないと結局は質問者に「こういうコマンドを打ってみてもらえますか？ターミナルに何が出ました？」とか代行してもらう必要があるので手間がかかるし、伝達ミスが起きる可能性もありますからね...
最小サンプルを作成する
時々StackOverflowで「このクエリ何で動かないの？」という短い質問と共に200行ぐらいの鬼長いクエリが貼られていたりしますが、案の定こういう質問には回答が集まりません。めちゃくちゃ複雑なアプリケーションをパッと渡されて「なんでこのエラーが出るの？」と聞かれるより、同じエラーを再現する最小サンプルを渡された方が考えやすいですよね。なので出来ることなら問題を再現するためのサンプルを作ってみましょう。
そして意外と最小サンプルを作っている途中で自己解決してしまうことが多いんですよね。というのもアプリケーションのエラーって（個人的な経験では）９割以上が自分のコードミスが原因なので、最小サンプルを作ってみると「あれ？動いた...さっきのは何だったんだろう...もしかして自分が追加したこの部分がおかしいのかな...」と問題解決の糸口が掴めたりします。
OSSを参考にしてみる
沢山の開発者とissueを通して会話する必要上、OSSのissue templateも必要な情報を伝えるフレームワークとして非常に参考になります。大体のテンプレートは
- 前提条件
- 再現手順
- 何が起きることを期待していたのか
- 実際に何が起きたのか
あたりを必須入力にしているので最低限上記4つのポイントは盛り込んでみると答えやすい質問になるのではないでしょうか。
(Issueテンプレートの例)
Next.js
Prisma
Svelte
Lerna
AWSのサポートプランに関するガイドラインも参考になります
具体的な質問になっているか
大体の傾向として、具体的な質問には具体的な回答が、曖昧な質問には曖昧な回答が返ってきます。
- DDDって何ですか？
- CQRSとCQSは何が違うんですか？
- CQRSではデータソースを読み取りと書き込みで分離することもあると耳にしましたが、読み取りデータソースの遅延が一部ユースケースでは許容できない場合は、書き込み用データソースを参照することを許容するしかないのでしょうか？
といった質問を比較した時、1より2、2より3の方がベテランエンジニアの経験や知識をたくさん搾り出せる感じがしますよね。逆に1ぐらいの曖昧な質問だと
「DDDとは、思想である」
「DDDとは、人類の果てなき挑戦の歴史である」
「DDDとは、夢である」
と~プロフェッショナル 仕事の流儀~みたいな回答が返ってきてコレジャナイ感が漂うリスクがありますし、何より曖昧な質問をする癖がついてしまうと 「困ったら誰かに聞けば良い」という癖が染み付いてしまい、自分で調べて考える能力が鍛えられないので、自力で問題を解決できない状態が続いてしまう可能性があります
エンジニアとして最初の1~2年はそれでも大丈夫なのですが、周りに聞いても答えてもらえない、自分がその件に関しては一番詳しい立場、という仕事が少しずつ増えてきます。そうなった時に自己解決する手段を自分の中に蓄積していないと本当に困ってしまうんですよね
(僕の過去の職場では曖昧な質問をすると胸ぐらを掴まれて貴重なご指導を賜ることも...)
改善点：自分が何を理解していないのか書き出してみよう
僕が新しいことを学ぶ時によく使う手法なのですが、まず自分が情報をインプットして 「理解できたこと」と「理解できなかったこと」を書き出してみます。
例えばDDDについて初めて記事を読んで「なんじゃこりゃ全然わからん」と思ったらこんな風に書き出してみます：
- 理解できたこと
- DDDとはドメイン知識を一箇所にまとめること
- ドメイン領域をできるだけ変更・テスト容易にしたい
- 値オブジェクトを使った方がプリミティブ値を使うよりコードを読んだときに意味を理解しやすく感じた
- 理解できていないこと
- ドメイン知識かそうでないかの区別
- オニオンアーキテクチャとは何が違うの?
- 新しく画面を作るたびにエンティティが増えちゃうの？
この時点で「理解できたこと」は完全に間違っていても構いません。大事なのは「理解できていないこと」の方です。
理解できていないことを書き出してみると、当初「DDDって何ですか？」としか聞けなかった曖昧な質問が少し具体的になるのではないでしょうか？
- ドメイン知識とそうでない知識はどうやって区別するのでしょうか？
- オニオンアーキテクチャとDDDは何が違うのでしょうか？共存できるものなのでしょうか？
- 新しい画面が増えるたびにエンティティも増えていくのでしょうか？
これなら回答者も的を絞って答えられるので、より的確に答えが得られそうですよね。何ならこのリストを共有するだけでも回答者が回答のレベルを調整できるので、自分の理解力を伝達するツールとしても重宝します。
自分が理解できていないことを知ることは、理解への第一歩です。「何が分からないかすら分からない...」と苦しむ瞬間があるかもしれませんが、どんなに小さくても構わないので、自分が理解できていないことを書き出して具体的な質問に変換してみてください。どんなに大きな課題も解きほぐしていけばシンプルな課題の集合になるはずです。プログラミングと一緒ですね！
そして理解できていないことがちょっとでも理解できたら、「理解できたこと」に書き足していきましょう。少し勉強疲れを感じてきたときに「理解できたこと」を読んでみると、自分の学習成果を実感してモチベーションが回復するかもしれません。1ヶ月ぐらい経ってから理解できていないことのリストを見返してみると こんなことで詰まっていたなんてお可愛いこと... ってな具合に自分の成長を実感できて楽しいですよ！
色んなリソースにあたったか
記事を1つ読んで「分からないから聞いてみよう！」と飛びつく前に、少なくともGoogle検索1ページ目に出てきたサイトは全部読みましょう。QiitaやZennで検索して1ページ目に出てきた記事を一通り読みましょう。人って情報のストライクゾーンが結構狭いので、説明方法を変えてみたらすんなり理解できることが意外と多いんですよね。なので質より量です。というか量（色んな説明を読むこと）が質（深い理解）になるので、量は学習の初期ほど大切だと思います。
特に画像検索は結構オススメです。 例えばCQRSがいまいち理解できなかったら「CQRS」で画像検索してみましょう：
しっくりくる図を起点に記事を選んでみると、図解を通して今までと異なるメンタルモデルで情報に触れるおかげか腑に落ちることが多くてベネ。
YouTubeも最近は教材が充実してますよね。人によって得意な学習方法は体感（手を動かす）、視覚（文字を読む）、聴覚（話を聞く）の3つに分類されるそうですから、読んで理解するのが苦手な人も聞いて理解するのは得意だったりするかもしれません
ただ、何より大切なのは一次情報に触れることです。 OSSの仕様について質問して回答を得たとしても、それは二次情報なので間違っている可能性があります。最初のとっかかりとして二次情報を参照するのは全く問題ありませんが、OSSのレポジトリで交わされているdiscussionやissueなど、より一次情報に近い二次情報に目を通して裏を取る癖はつけた方が良いと思います。最終的には実際に書かれたコードが正なので直接コードを読むのがベストなんですけどね...
そのためには酷ですが英語を勉強するしかありません。一次情報が欲しければ英語は避けて通れません。質問を受けた時に僕は英語リソースを返すことが多いのですが、決して英語マウントを取りたいとかそういうわけではなく一次情報が英語である確率が圧倒的に高いからなんですよね...「DeepL兄貴、一生ついていきますぜ！」というのも1つの生存戦略ですが、意外と開発で使われる単語ってそこまで多くないので頑張ってみてください！
まとめ
というわけでここまでの内容をまとめてみると、答えやすい質問を組み立てるには
- 相手に十分な情報を与える
- 前提条件、再現手順、期待した結果、実際の結果など
- 最小サンプル
- OSSを参考にしてみる
- 具体的な質問を考える
- 理解していること、理解していないことを分解する
- 理解していないことを具体的な質問に変換する
- 色んなリソースにあたる
- 質より量
- 体感、視覚、聴覚優位の学習方法を試してみる
- なるべく一次情報に近づくために英語を学ぶ
こんなアプローチが誰かの参考になり、より良い質問に繋がれば幸いです。
Discussion