新人エンジニアのための質問の仕方

# この記事を書いたわけ

一年間SEとして働いてきた中で、私自身が苦手だと思っており、他人からもそのように評価されていたのが「質問の仕方」でした。
それが先日、他人から「質問の仕方がうまいね」と褒められることがあり、ようやく一人前の質問の仕方ができるようになってきたので、どのようにして克服できたのか紹介したいと思います。

## 丸投げな質問をするな
私が入社したばかりの頃は、わからないことがあればすぐに先輩に質問していました。
そのときにしていた質問の内容はだいたいこんな感じです。
「環境構築を手順書通りにやったんですけど、○○のコマンドでエラーがでてしまいます！なんとかなりませんか？」
このような質問を受け取ったら、先輩は暇ならばエラーメッセージを見てくれ、エラーメッセージに書かれていることに対して調査してくれるかもしれませんが、忙しいときにはそんなことはしてもらえません。
こんな質問を繰り返しているうちに先輩からは「技術系メーリングリストで質問するときのパターン・ランゲージを100回よめ」と言われてしまいました。


# 参考文献

私が「質問の仕方」を上達させるために、最初に行ったのは以下の資料を読み、質問するときはここに書かれているテンプレート通りに質問するというものでした。
[技術系メーリングリストで質問するときのパターン・ランゲージ](http://www.hyuki.com/writing/techask.html)

# テンプレート
以下引用です
```
【所属機関や自分の技能を表現する解説】の【氏名】です。

○○を実行すると、○○というエラーになる問題で困っています。
原因または解決策をご存知の方はいらっしゃいませんか。

私の行った手順は以下です。
(1)
(2)
(3)

すると、以下のような結果になりました。

【表示されたものをコピー＆ペーストする】

私は【予想結果】になると思いました。
なぜなら、【参考資料】には、
以下のように書かれているからです。

> 【適切な分量の引用】
> 【適切な分量の引用】
> 【適切な分量の引用】

原因を確かめるため、以下のようなテストを行ってみましたが、
問題の解決には至りませんでした。

(a) 入力を○○ではなく××にしてみた
→上記と同じ結果になった

(b) ソースプログラムの○○をやめて、××にした
→以下のようなコンパイルエラーになった

【エラーメッセージのコピー＆ペースト】

なお、私の環境は以下の通りです。
【マシン, メモリ量, 関連周辺機器, OS, 利用ソフト, バージョンなどを箇条書きに】

検索エンジンで○○、××、△△を検索しましたが、
◎◎に関するページばかりで、解決に役立つ情報は見つかりませんでした。
このメーリングリストの過去ログも調べましたが、
○○に関する話題は見つかりませんでした。

【個人を識別する適切な署名】
```
氏名や所属機関、マシンスペック、署名などは当然先輩に質問する場合は不要なので省いてしまって構いません。

# 質問が回りくどい
上記の「技術系メーリングリストで質問するときのパターン・ランゲージ」に書かれているテンプレート通りの質問をしていると「質問が回りくどい、もっと端的に説明してくれ」と言われてしまいました。
上記のテンプレートを使った質問は「文章を見せて説明する場合に適切な質問の仕方」です。
口頭で説明する場合には
```
私は【目的】がやりたくて、【予想結果】になると思い、【やったこと】を試しました。
しかし、【実際の結果】となってしまいました。
調べても有効な情報が出てきません。
お忙しい中恐縮ですが、少しみていただけませんか？
```
くらいにまとめたほうが回りくどくならずに済みます。
逆にこれだけでまとめきれない場合は口頭で説明するべきではなく、文章や図を見せて質問するべきです。

# 質問の質と時間のトレードオフ
[15分ルール](http://tkybpp.hatenablog.com/entry/2016/08/16/173055)というものがあります。以下引用です。
>問題が起きた時は
【1】最初の15分は自分自身で解決を試みる
【2】15分後も解決していなかったら必ず人に聞く
前者を守らないと他人の時間を無駄にし、後者を守らないと自分の時間を無駄にする。

この時に大事なのは完璧主義にならないことです。15分で調べてできるところまでが、今の自分の実力です。
「問題の切り分け」を新人がやらなくていいと言ったのはこのためです。
おそらく新人であれば、問題解決のために、ググって書いてある方法を試してみるところまでが15分でできる限界でしょう。
15分立ってわからないことは、上述した質問の仕方に従って質問し、先輩がどのようなアプローチで解決するのか見て学びます。
そして徐々に15分でできることを増やしていきましょう。

#無知の知
[Five orders of Ignorance](http://la-acm.org/Archives/laacm0512-Article%2002%20The%205%20Orders%20of%20Ignorance%20OCT%202000.pdf)という資料で無知の知については言及されています。
上記の資料に書かれていることをSEが質問する場面に当てはめて意訳します。

- 0OI - Lack of Ignorance
知らないことはない。簡単にシステムを構築することができる。当然質問することも何もない。
「エラーがでた！でもこれ対処法知ってるんだよね」
- 1OI - Lack of Knowledge
知識がない。しかし、知らないことを知っている。どのようにして、知らないことを知るか知っている。
知らないことを知る手法は、ググるかもしれないし、誰かへの質問かもしれない。
質問であるならば、何を質問すればいいかわかっているので適切な質問ができる。
「エラーがでた！でも原因わかったし、後は調べる（or聞く)だけ」
- 2OI - Lack of Awareness
認知がない。自分が知らないことに気づいていない。何がわからないのかわからない。
何がわからないかわからないため、ググることも、質問することもできないが、何か困っている。
「エラーがでた！これからどうしようかな（少し考えれば、これからどうすればいいかはわかる）」
- 3OI - Lack of Process
プロセスを知らない。知らないことが何なのか探し出すことができない。
「エラーがでた！これからどうすればいいかもわからない。もうだめ。」
- 4OI - Meta Ignorance
超無知。「Five orders of Ignorance」について知らない。
これを読んだ時点で4OIはクリアしている。

質問する際はこの中で自分がどのステップに居るのか理解しておくことが重要です。

## 2OIの人は質問禁止
私の考えではこの中で質問してはいかない人が居るとすれば2OIの人です。
この人はこの後少し時間をかければ、適切な質問を出せる1OIに昇華することができる人です。できないのであればあなたは3OIです。
2OIの段階で質問することはただのサボりです。

## 3OIの人は自分が3OIであることを理解して質問する
3OIの人は自分が「わからないことが何なのか絞り込む方法（切り分け方）」をわからないのだと理解しましょう。
そして、素直に「○○をしていてエラーが出たのですが、切り分け方がわかりません。切り分け方を教えてください。」といいましょう。
しかし、新人のうちはこれでも許されますが、次第に許されなくなってきます。
できるだけ早く「切り分け」の技術を習得しましょう。

# ぼくのがんがえたさいきょうのしつもんのしかた
## 困っているパターンに応じた質問
質問をしたいとき、困っていることには三種類あります。
- 「エラーがでてこまっている」
- 「どうすればいいのかわからない」（画面レイアウトをどうするべきか・ログの設定をどうするべきか）
- 「方法がわからない」（ファイアウォールの設定方法がわからない・サーバの起動方法がわからない）

### エラーが出て困っている
エラーがでてこまっている場合はまずググりましょう。
エラーメッセージが出ていれば、エラーメッセージをコピペしてググることができます。
更にはほとんどの場合は解決策まで書いてあります。
しかしながら、そうは行かない場合があります。例えば「ググったが解決策が出ない」「ググって出た対処法を試したが治らない」場合です。
こうなってくると、新人ではそれ以上の調査は自分の時間を無駄にすることがほとんどです。
本当はこれでもわからなければ、「問題を切り分ける」ということをやらなければなりませんが、技術力・知識量・時間が必要な仕事になるので、
新人であるならば、まずは先輩に質問し「問題の切り分け」のやり方を学びましょう。
もちろん、成長し「問題の切り分け」ができるようになったあとは、問題を切り分けた上で質問するようにしましょう。

#### この場合に使うテンプレート
```
私は【目的】がやりたくて、【予想結果】になると思い、【やったこと】を試しました。
しかし、【実際の結果】となってしまいました。
調べてみると【検索結果】が出てきて、書かれていることは試してみたのですが、
相変わらず【実際の結果】となってしまいます。
お忙しい中恐縮ですが、少しみていただけませんか？
```

### どうすればいいのわからない
どうすればいいのかがわからず質問する場合でも丸投げにしてはいけません。
まずは、「世界のスタンダードはどうなっているのか」を調べることが大事です。
例えばショッピングサイトの画面レイアウトの構成を決めたいのであれば、Amazonを参考にして、「Amazonはどうしてこういうレイアウトにしているのだろう」と考えることが大事です。
そうすると以下の二点が言えるようになり、先輩としてもそれが良いのか、悪いのか判断をするだけでよくなります。
- 「自分はどうしたいのか」
- 「なぜそうするのがいいと思うのか」

#### この場合に使うテンプレート
```
私は【目的】がやりたくて、【参考にしたもの】を参考に【自分はどうしたいのか】と考えました。
そう考えた理由は【なぜそうするのがいいと思うのか】です。
お手数ですが、このやり方でよいか確認してもらえませんか？
```

### 方法がわからない
この場合はググってわからなければすぐに聞くべきです。ただし、聞く前に[本当にやりたいこと（目的）はなにか]も一緒に話すべきです。
もしかしたら、別の方法があるかもしれません。

#### この場合に使うテンプレート
```
不躾な質問で申し訳ありませんが、
私は【目的】がやりたくて【手段】をやりたいのですが、やり方がわかりません。
お力添え願えませんか？
```
##思考の切り分け
スムーズに的確な回答をもらうため、相手の時間を浪費しないために「やったこと」「やりたいこと」「推測」「事実」「わかっていること」「わからないこと」を分割して明記する。
問題の切り分けはできなくても、自分の思考は切り分けましょう。

### やったこと・やりたいこと
質問するとき基本的には、「やったこと」と「やりたいこと」は別のはずです。
「やりたいこと」はできていないわけですから
「やったこと」・「やりたいこと」は「手段」・「目的」とも置き換え可能です。

「やったこと」は実際に行った手順をステップごとに分割して詳細に説明するべきです。複雑になる場合はRedmineやチャット、メールなどで、箇条書きにして伝えた方が良いでしょう。
「やりたいこと」は簡潔に説明するべきです。目的を明記しておけば、「やったこと」とは別のアプローチからの解決策を貰えるかもしれません。

### 推測・事実
質問を受けて一番答えづらいのは推測と事実がごっちゃになっている場合です。
よくあるパターンが、できたと言っていることが実はできていないパターンです。
できたという際にはなぜできたと思ったのかも説明するといいです。

### わかっていること・わかっていないこと
先輩といえど、あなたが何ができるのか、詳細までは把握していません。
そのため、ここはわかっているんだということを伝えておくと、
回答してもらって「そんなことはわかってるけど、それをやってもダメなんだ！」となることは少なくなります。

### 例
× 悪い例
> プロキシのせいでgitでpushが失敗します。どうすればいいですか？

○ 良い例
>ソース修正が完了したので、社内イントラ上にあるgitbucketリポジトリ上に反映させたいです。

↑「やりたいこと」
>そのために以下のことを行いました。
>1. 下記コマンドを実行しadd & commit
>``` git commit -am "fix xxx" ```
>
>2. 下記コマンドを実行しpush
>``` git push origin fix/xxx ```
>

↑「やったこと」
>すると以下のエラーが発生してpushに失敗します。
> 503 hoge hoge

↑「事実」
>私はソースの修正を行ってからgitbucket上にpushするまでの一連の流れを知っています。

↑「わかっていること」
>もしかしたら社内イントラ上にあるgitbucketにpushする際はプロキシを用いない設定にしないといけないのかもしれません。

↑「推測」
>お忙しい中恐縮ですが、予期しないステータスコード503が返される理由と解決策を教えていただけますでしょうか？

↑「わからないこと」

#まとめ
- わからないことがあれば15分は考える、解決しなければ質問をする
- 質問は丸投げしない
- 質問をするときは、自分の無知レベルに応じた質問をする
- 「やったこと」「やりたいこと」「推測」「事実」「わかっていること」「わからないこと」を分割すると良い質問になる

非常に参考になりました。