「質問力たったの5か…ゴミめ……」と思われないための質問力の上げ方

[ディップ Advent Calendar](http://qiita.com/advent-calendar/2016/dip-dev) の15日目です。
今回はちょっと技術とは違う観点の話題で書きます。

---

## はじめに
皆さんは **良い質問** できてますか？
一生懸命相手に聞いても、思った回答が得られなかった経験ってありませんか？
そんな悩みを解決するために、**質問力を上げる**方法をご紹介します。

## そもそも質問とは？
自身の抱える **課題を解決する** ために、他者から情報を引き出すこと。

## 良い質問とは？
課題を解決するための **適切な情報** が引き出せる質問のこと。
ここでいう適切な情報とは、自分の望む回答と全く違う可能性があることを留意しておいてほしい。

## 良い質問をするために
質問とはコミュニケーションの一種である。
そのため、コミュニケーションの基本である5W1Hを意識すると良い。
具体的にどのようにするべきかを以下に述べる。

## 0. 悪い質問の例
はじめに、質問する際の悪い例を紹介する。
陥りがちなものとして **質問だけ** を伝えるケースがある。
例：「すいません、この関数のこの部分の動作が分からないんですけど、どうしたらいいですか？」

この場合 **関数の動作について** の回答は得られるかもしれない。
しかし、関数の動作について確認する場合、単に関数の仕様が知りたいのではなく
**A. その関数を使って何かをしたい**
または
**B.. 何かを実現する方法として、その関数が利用できるか知りたい**
といったケースが多いのではないだろうか。

ここで冒頭を見返してみよう。
質問とは`自身の抱える課題を解決する`ためのものである。
果たしてAやBのケースの場合に、関数の仕様が分かっただけで課題が解決するだろうか？

## 1. 自分の状況をなるべく詳しく伝える
### 5W1Hで語る
良い質問をする上で必要な事として、自分の状況を詳細に伝えることである。
ここで前述の5W1Hが活きてくる。

例：「今週末までに○○の機能を追加する案件をしているのですが、この機能を実装するにあたって、◇◇という関数が使えそうだと考えました。
この関数を使えば△△な動作が上手く実現できると思ったんですが、関数のこの部分の動作仕様が分からないため判断が付きません。（or上手く動きません）
詳しく教えて頂けませんか？」

・・・長い。
しかし、このような質問をすると、回答のバリエーションが飛躍的に増える。
パッと思いつくだけでも

* その関数を使う考えは合ってるよ。その部分の動作は～～～
* その関数で合ってるけど、使う場合はここに気を付けてね
* その関数だと微妙に違うから、こっちの関数を使おう
* 考えの方向性は合ってるけど、新たに関数を作った方が多分楽だよ
* その関数を使ったとしても、その期間だとそもそも実現が難しいから一度相談した方が良いよ
* その機能を実現するなら、他の案件やってるXXXさんにまとめてやって貰った方が良いよ
* etc...

と、これだけ想定できる。
こちらの方が`課題を解決する`可能性が大きいことが分かるだろう。

### 課題の本質
前述の質問の5W1Hは以下のようになる。
いつ：`今週末`までに
どこで：`○○の機能を追加する案件`で
誰が：`（自分）`が
何を：`○○の機能`を
なぜ：`△△な動作が上手く実現する`ために
どのように：`◇◇という関数を`使う・・・が、**動作仕様が分からない**

これを踏まえ、あなたが抱える課題が何なのかを今一度考えてみよう。
ここで間違えてはいけないのが、今回の課題は **関数の動作仕様が分からないことではなく** て、**今週末までに○○の機能を追加する**ことなのである。
その関数を使うのはあくまで **手段の一つ** でしかない。

これを見誤ると前述のような限定的な質問の形になってしまう。
それを防ぐためには、極力**自分の置かれている状況や、自分の考えを詳しく伝えよう**。
そうすることで自分自身も見えなかった課題の本質が浮かび上がることもある。

## 2. 求める回答の質を伝える
質問をするということは、**相手の時間を使う**ことと同義である。
そのため、相手の作業への影響をなるべく減らすべきである。

### 期限を伝える
いつまでに回答が欲しいのか、急ぎなのか否かは必ず伝えよう。
場合によっては相手の計画に影響が出る可能性がある。

### 求める回答の粒度を伝える
Yes / Noだけで良いのか、その理由も含めるのか、具体例（コード）も含めるのか。
どの程度の粒度の情報を回答として期待しているのかを伝えよう。

### 回答方法について伝える
口頭だけで良いのか、メールが良いのか、チャットで良いのか。
それとも何か資料が必要なのか。
どの方法（媒体）で回答が欲しいのかを明確にしておこう。

## 3. 質問と回答は記録する
自分が質問した内容は誰か別の人も疑問・課題に感じることが多い。
そのため、一度した質問や回答は何らかの形で文書化して残しておくと良い。
体裁は難しく考える必要はなく、メモ書き程度でもOK。

## 4. お礼は必ず伝える
社会人として当たり前の礼儀。
また、そのものズバリの回答ではなく回答に至るアプローチ方法について教えて貰った場合、
**調べた過程・見つかった回答**を必ず共有すること。
そうすることで、自分だけでなく**相手の学びにも繋がり**、双方がwin-winの結果となる。

---

## （おまけ）良い質問の副作用
良い質問を意識すると、以下のことを必ず考えるようになる。

* 今の自分の置かれている状況
* 真の課題が何なのか
* どんな回答を期待するのか（＝どうすれば課題が解決するのか）

実はこれらの内容を頭の中で整理するだけで、自分自身で答えに辿りつけることも多い。
経験を積んで知識の引き出しが増えていくと、更にこういったケースが増えやすいように思う。

そのため、もし考える余地が残されている状態でも一旦1人で悩むのを止めて、さっさと誰かに相談した方が答えに辿りつけるかもしれない。
ちなみに質問する相手は人間ではなく、例えば**くまのぬいぐるみ**などでも良い。
※ [ベア(bear)プログラミングとか告白デバッグ](http://dole.moe-nifty.com/etc/2008/01/post_7ecb.html)と呼ばれる正しい手法。

---

## おわりに
良い質問は良いコミュニケーションを生み、チームや組織の活性化に繋がります。
逆に言えば、誰かに質問し辛いような環境は最悪です。

どんどん良い質問をして、皆で成長できるよう頑張りましょう！

--- 

## 質問に関する参考リンク
ちょうど**質問**というテーマで目に入った記事がありましたのでご紹介します。

[質問は恥ではないし役に立つ](http://qiita.com/seki_uk/items/4001423b3cd3db0dada7)
そもそも質問をするにあたって、という1つ上のレイヤーについても触れられている。

[技術系メーリングリストで質問するときのパターン・ランゲージ](http://www.hyuki.com/writing/techask.html)
1つ目のリンクで紹介されていたページ。
10年以上前の記事ですが、質問に関する本質的なことが書かれているおり、今でも非常に参考になる。

[賢い質問のしかた](http://www.ranvis.com/articles/smart-questions.ja.html)
1つ目のリンクで紹介されていたページ。
ちょっとボリュームのある読み物コンテンツ。
これも昔のものですが、同様にコミュニケーションとしての本質部分が書かれている。