質問力チートシート

質問テンプレート

質問テンプレートその1

1. 聞きたいことの一行まとめ
2. 起きている問題（起きている現象の詳細/エラーメッセージ/スクリーンショット）
3. ソースコード（関連するソースコード/全ソースコード）
4. 問題解決するために試したこと（コードもあれば追記）
5. 問題について自分なりに考えたこと（検索結果/自分なりの原因予想/切り分けた内容）

質問テンプレートの例

1. 聞きたいことの一行まとめ
   ・〜〜機能を実装しているのですが、〜〜の箇所で問題があるので、教えて頂けないでしょうか？

2. 起きている問題（起きている現象の詳細/エラーメッセージ/スクリーンショット）(うまくいかない具体的根拠)
   ・XXX を想定したテストが通らない
   ・出力結果が想定していた内容ではない
   ・エラー XXX が発生して実行できない
   ・エラーを解決して〜〜できるようにしたいです。

3. ソースコード（関連するソースコード/全ソースコード）
   ・下記のエラーメッセージから〜〜ファイルの〜〜行目の〜〜箇所が原因ではないかと思っています。
   ・ソースコードを貼り付けたり、GitHubのURLの共有をする

4. 問題解決するために試したこと（コードもあれば追記）
   ・デバッグをした時に変数がnullだったので、〜〜なのではないかと考えた。故に〜〜したのですが、〜〜でした。

5. 問題について自分なりに考えたこと（検索結果/自分なりの原因予想/切り分けた内容）
   ・他の箇所では〜〜なのに、〜〜がうまくいかないのはおかしいのではないかと考えています。
   ・〜〜にはこう書いてあるのに〜〜だとうまくいかないのでなぜ〜〜では動かないのか理解できませんでした。
   ・「○○について調べた結果、△△ということが分かりました。しかし××が分かりません」という形で「わかったこと」と「わからないこと」の両方を説明する質問をする。それにより、質問された人は質問者の理解度を把握できるため、どのあたりから説明を始めればいいかを決められます。

質問テンプレートその2

①背景（どういった話か）
②現状（どういう状態）
③やりたいこと（やってほしいこと）
④調べたこと（どこまで試したか）

質問テンプレートの例

①トップページ改修の案件をやっているのですが、
②バナー画像のスライドが動かず、コンソールに○○エラーが出ている状態です。
③エラーを解決してスライドを動くようにしたいです。
④ちなみに、○○エラーについて調べ○○を試してみたのですがエラーは出たままです。他に方法をご存知ないでしょうか？

質問テンプレートその3

issueのタイトルとURL
質問なのか相談なのか確認なのか提案なのかを最初に言う(フレーミング)
質問したい箇所の概要
問題点(理想と現実)
質問、相談、確認、提案の本題を言う。
スクショやコードのURLを貼付するとよい。

質問テンプレートの例

LUO: テンプレートの改善
https://github.com/zizynonno/luo/issues/220
相談です！
現在トップページのテンプレートの改善を行なっています。
バナーのスライドが動くのがゴールなのですが、現在バナー画像のスライドが動かず、コンソールに○○エラーが出ている状態です。
そこで、

• 1.AAAAAの方法
• 2.BBBBBの方法
• 3.CCCCCの方法

のいずれかで対応したいと思っているのですが、どれで進めた方がいいかを相談したいです！

ソースコード
https://github.com/zizynonno/luo/blob/master/app/controllers/homes_controller.rb#L327-L331

添付されたスクショ

原因の切り分け出来ず、お先真っ暗な時

「うまくいきません。どうすればよいですか？」といった情報量のない相談をしたい衝動に駆られた場合、次のアクションを自身で決められないのが本来の主旨である。故に「XXXが発生していますが、次に取るべきアクションが決められません。切り分けるためのヒントを教えてもらえますか？」とか言うと、手伝ってもらえる可能性が高い。

相手への気遣いで業務を円滑に進める

上司やチームメンバーは質問に答える以前にあなたと同じように自身の業務がある。仕事は迷惑の掛け合いで成り立っていることや、質問をしないことで業務が遅れることは更に迷惑がかかることから、質問はするべきだと考えているが、テンプレートで読みやすくしたり感謝の気持ちを伝えたりと相手への気遣いを忘れず謙虚に質問すれば、少なくとも嫌がられることはない。また、最後まで納得するまで、聞き続けるのはあまりいいことではない。

質問前

まずは、質問する際に「５分だけ、お時間よろしいでしょうか？」と許可を取る

質問後

時間を大幅に過ぎた時は一旦持ち帰る

「お時間を取りすぎてしまったようなので、伺った話をもとに、もう少し調べてみようと思います。」
「なんとなく、判ってきました。あとは自分でやってみようと思います。」
「混乱してきたので、整理してきてもよろしいでしょうか」

質問の終わりにお礼を言う

「お時間頂きありがとうございます！」

質問でHowtoを提案されたが、別の方法でやる

「うまくいかなかったのでこの方法で行きます。」など報告する

エンジニアが嫌う質問

①抽象的で情報量のない言葉

主に「わかりません。うまくいきません」だけの質問を指す。

質問する側は問題解決をしたい。聞く側はなるべく問題解決の協力をしてあげたい。しかし「わかりません。うまくいきません」だけだと具体的でないので解決ができない。

→テンプレートに沿う

→「原因の切り分け出来ず、お先真っ暗な時」を参照

②長く結論が見えてこないもの

聞く側は先ず何が問題・課題なのかが一番の感心ごとだ。チームメンバーは基より特に上司は仕事に追われ時間がないことが多いので、だらだらと長く結論が見えてこない文章や提案を一番嫌う。長ったらしく語って、結局何が言いたいか伝わらないパターンが最悪。

→テンプレートに沿う

③1ミリも自分で考えてきました感が見えないもの

主に「丸投げにしか聞こえないもの、調べずに聞きに来てると勘違いされているもの」を指す。

質問をすると「ググれ」と言われた経験があると思うが、これは、相手が調べずに聞きに来てると考えているため。対策としては「調べたけどわからないので教えてほしい」と相手に伝わればいい。
具体的には「こういうことをする上で自分はこういうやり方を考えているのですが、よりより方法はありますか？」や「自分はこう考えている、でもより良い方法もあるのでは？」など、自分でも様々なケースを検討していることや、また解決方法をより洗練させるための質問と相手に伝わると印象が変わり、無碍に扱われるケースは減ってくる。

→テンプレートに沿う

④以前に聞いた質問と同じようなものと思ってしまう内容のもの

→人間は忘れる生き物なので多少大目に見てほしい気持ちはありつつも、一度した失敗はなるべく繰り返さないように逆引きチートシートを作成し、そこに記載をして対策を取る

参考文献