はじめに

今回の記事では、プログラマーにとって重要なスキルの１つである「質問」について徹底解説する。

質問の原則

「できるだけ相手の時間を取らずに解決まで到達できるか」が最も重要
自分が腑に落ちるまで粘り強く質問する

文章で質問する場合は以下のポイントをおさえておくべき。

文章は簡潔に、かつわかりやすく
１つの文には１つの内容を書く。読点(いわゆる「、」のこと)を多用しない
同じような文末を繰り返し使わない。できるだけ文末はバラバラにする

質問のタイミング―「Google人工知能チームの15分ルール」を活用せよ

プログラマーとして働き始めたときの頃は、わからないことに自分一人でずっと考えてしまい、それゆえに大幅に時間を浪費してしまったという人も少なくないだろう。私も最初、インターンとして働き始めたときの頃はエラーの解決等を自分だけで長時間感が得て解決できなかったあげく、先輩に聞いたら一瞬で解決したという経験があった。

たしかに、自分で考えて解決するという試みは非常に大切である。ところが、それが原因で長時間浪費してしまったら開発の進捗に悪影響を与えてしまうのだ。

一体、どのようなタイミングで質問をすればいいのだろうか？

その１つの指標として、Google人工知能チームの15分ルールが考えられる。その内容は主に以下の内容になる。(一部改変あり、日本語に翻訳)

最初の15分は自分で解決する

15分後、解決できないなら必ず質問する

前者を守らないと他人の時間を無駄にし、後者を守らないと自分の時間を無駄にする。

これはあくまで一つの指標にすぎない。自分が適切な時間やルールを決めて質問するのが妥当だ。しかし、「まずは自分で考えて、それでもわからないなら質問する」という流れは絶対に理解しておくべきである。

質問の手順

(1)やりたいこと・わからないことを一行で書く

最初に、自分がやりたいことやわからないことを一行で書く。「一行」に拘る理由は、質問される側に今からする質問の大まかな内容を予め理解してもらうためである。

【やりたいこと・わからないことの具体例】

【質問】Pythonの関数の書き方がわからない
【やりたいこと】画像をトリミングしたい

(2)実際にやったことを書く

これをまったくやらずに(1)だけ質問するのは、相手の時間を浪費することはおろか、相手に悪い印象を与えてしまう。そのため、最初は自分で手を動かして試してみることが非常に重要である。そのときに、ソースコードや画像、ファイルのディレクトリなどを付け加えるとやったことが明確になる。

(3)実際に試してやってみたことに対する結果を書く

(2)でやったことに対する結果を書く。(2)と同様に、ソースコードや画像、ファイルのディレクトリなどを付け加えるとより明確になる。そのとき、エラーメッセージやエラーが表示されている画面は必ず添付する。それらの情報はより良い解決策を得るために最も重要だからだ。

(4)原因だと思われること

(1)~(3)で試した結果、解決できなかったものの、その上で自分なりに仮説を用意する。

【具体例】

関数や条件分岐を書くときに正確にインデントを入れていないかもしれない(Python)
JavaScriptファイルの名前を適切に書いていなかったから、読み込まれているファイルを識別できないかもしれない
11行目のクラスのコンストラクタ^[1]の書き方が正しくないかもしれない

(5)参考サイトを箇条書きで表記する

(2)と(3)を書くために実際に使った参考サイトを箇条書きで書く。質問の受け手に、どのような思考プロセスで解決策を調べたのかを明確にするためだ。

ほかにやるべきこと

公式ドキュメントに触れる

プログラミングの世界で何かわからないことが出て調べる際に、最も重要なことは一次情報に触れることである。プログラミングにおける一次情報として最も代表的なものは公式ドキュメントがある。最初の取っ掛かりとして二次情報に触れることは問題ない。しかし、私たちプログラマーが普段の学習や開発で使っているすべての言語・フレームワークには必ず公式ドキュメントが存在する。

プログラマーが学習・開発でわからないことを調べる際に、公式ドキュメントに勝る情報はない。

公式ドキュメントの重要性は以下の記事で言及されている。時間に余裕があれば確認してほしい。

画像検索を使う

わからないことをGoogle検索で調べるとき、画像検索を使うのも一つの手である。例えば、「MongoDBのアーキテクチャ」がわからないときにmongodb architectureで検索してみよう。

理解できる画像をベースに記事を選んでみると、図解を通して今までとは異なるメンタルモデル^[2]に触れられるので理解しやすい。テキストだけ読んでも理解できなければ、画像検索を使うのも一つの手段として挙げられる。

無事解決したときは聞き手に報告・感謝する

わからないことを無事に解決したとき、質問に答えてくれた人に報告し、丁寧に感謝すること。伝えるべき内容は次の通り。

報告：解決した方法を簡潔に伝える。解決した方法が、質問に答えてくれた人にとって新たな学びや気づきにつながることが少なくないからだ。
感謝：絶対に伝えるべき。そもそも、わざわざ貴重な時間を割いて自分のわからないことに付き合ってくれたことは当たり前ではない。上辺だけではなく、本心から丁寧に感謝することは相手に非常に良い印象を与える。

おわりに

今回の記事では、プログラマーの重要なスキルの１つである「質問」について徹底解説した。本記事では主に２つのポイントに絞って解説した。

質問のタイミング
質問の手順
質問以外にもほかにやるべきこと

質問する上で最も重要なことは、質問された人が「質問されてよかったな」と本心から思えるようにすることである。質問する人と質問される人は互いにWin-Winの関係でなければならない。

今回の記事を通して、今後質問をする上で1文でも参考になるものがあれば非常に幸いである。

おまけ：質問のテンプレート

Markdownで質問の段取りを簡潔にまとめてみると以下のようになる。今後質問するときに少しでも参考になれば幸いだ。

question_template.md

# やりたいこと・わからないこと

<!-- 自分のやりたいこと、わからないことについて一行で簡潔にまとめる。 -->
<!-- わからないことがわからない場合は、その旨を適切に伝えること。 -->

# 実際にやったこととその結果

## 実際にやってみたこと

<!-- 実際に試してみたことを書いてみる。 -->
<!-- ソースコードや画像、ファイルのディレクトリなどを使うとより具体的になる。 -->

## 実際にやってみたことに対する結果

<!-- ソースコードや画像、ファイルのディレクトリなどを使うとより具体的になる。 -->
<!-- エラーメッセージやエラーが表示されている画面は必ず添付する。 -->

# 原因だと思われること

<!-- なんでもいいので、とりあえず箇条書きで書いてみる -->

# 参考サイト一覧

<!-- 非常に重要。どのリソースから引用して解決しているのかを明確にする必要がある。 -->

英語の場合は以下のようになる。(例：stack overflowで質問するとき)

基本的なフォーマットは上記のMarkdownファイルと同様である。

question_template_en.md

# What you want to do or what you don't understand

# What you tried doing actually and the result from it

## What you tried doing

## The result from it

# Something that seems to cause

# References

参考サイト

脚注

コンストラクタ(constructor)とは、オブジェクト指向プログラミング言語において、クラスをインスタンス化する際に実行される特別なメソッド。インスタンスの初期化処理などを記述する。 ↩︎
メンタルモデル(mental model)とは、簡潔に言えば頭の中にある「ああなったらこうなる」といった「行動のイメージ」を表現したものである。もとは認知心理学の専門用語。詳細はWikipediaを参照。 ↩︎

Discussion