考え方
質問は恥ではないし役に立つ。きょうびお金を払えば何でも教えてもらえてしまう時代...
プログラミングで発生する「エラー」に立ち向かう秘伝書 のような書物が常にあるとは限らない
- そんなの自分で調べてよ！
- そんなの早く質問してよ！
なんてつまらないすれ違いは勿体ないです。聞きづらい雰囲気があるとしたら先輩側の教え手としての技量不足。先輩も新人さんも効果的に質問しあえるようにするのが鉄則だとおもいます。まとめてみました。
効果的な質問をする時の鉄則
- 主語を書く。
- 質問の目的をはっきりさせる。
- 解決期限をはっきりさせる。
- 5W1Hを伝える。
- 自分で試したことがあれば伝える。
- 質問に関連する操作の内容、ログ、エラーメッセージ等の情報を全部伝える。
- 以下テンプレートに則る。
質問テンプレート
15分かけて考える。ただし以下を埋めるために15分かかってしまったらその時点で書けたところまでで相談する。
## 解決したいこと、目的
## 解決期限
## 解決のために試したこと
- FAQは確認したか？
- ログ収集、過去事例確認等したか？
## 相談者にしてほしいこと
以下のいずれか。
### 1. 仮説を確認したい
- 仮説は何か。
- このプログラムのこの動作は仕様であると考えるが、あっているか、等。
- 仮説の根拠となった事実は何か
### 2. 解決の手段が浮かばないので、次の1手のアドバイスが欲しい
- 解決のために実施したことは何か。
- 可能な限りリストする。
### 3. その他
- **をしてほしいなど、具体的に。
## ほか補足
なお後述の「技術系メーリングリストで質問するときのパターン・ランゲージ」には以下のようなテンプレートが例示されている (パブリックドメイン)。
【所属機関や自分の技能を表現する解説】の【氏名】です。
○○を実行すると、○○というエラーになる問題で困っています。
原因または解決策をご存知の方はいらっしゃいませんか。
私の行った手順は以下です。
(1)
(2)
(3)
すると、以下のような結果になりました。
【表示されたものをコピー＆ペーストする】
私は【予想結果】になると思いました。
なぜなら、【参考資料】には、
以下のように書かれているからです。
> 【適切な分量の引用】
> 【適切な分量の引用】
> 【適切な分量の引用】
原因を確かめるため、以下のようなテストを行ってみましたが、
問題の解決には至りませんでした。
(a) 入力を○○ではなく××にしてみた
→上記と同じ結果になった
(b) ソースプログラムの○○をやめて、××にした
→以下のようなコンパイルエラーになった
【エラーメッセージのコピー＆ペースト】
なお、私の環境は以下の通りです。
【マシン, メモリ量, 関連周辺機器, OS, 利用ソフト, バージョンなどを箇条書きに】
検索エンジンで○○、××、△△を検索しましたが、
◎◎に関するページばかりで、解決に役立つ情報は見つかりませんでした。
このメーリングリストの過去ログも調べましたが、
○○に関する話題は見つかりませんでした。
【個人を識別する適切な署名】
不吉なワードチェックリストと質問への確認ポイント
- 通信 ... どことどこの。どういう層の。
- コネクション ... データベース？
- セッション ... データベース？ネットワーク？
- リプレイス ... 何の。
- 環境 ... 「環境」とは。
- サーバー ... 「サーバー」とは。
- エラー ... どういったエラー？エラーコードは？
- OSの種類やバージョン、言語やフレームワークのバージョン、ライブラリのバージョンは？
- プログラムが異常終了/処理途中で止まる ... 特定のアプリケーションの話か？
- OutOfMemory、ハング ... 本当に特定のアプリケーションのせい？
- 処理が遅い ... これも本当に特定のアプリケーションのせい？偏見をもつと解決が遅くなる。
- ちらつく、もたつく ... 具体的に書いてほしい。
- この、その、あの ... 具体的に書いてほしい。
- 確認してください、対応してください、検討してください ... 具体的に書いてほしい。「回避策を知りたいです」等。
- 体言止め。「これを確認」... 確認する必要がある、なのか、確認した、なのか分からない。
- 分からない ... 意味がとても広い。e.g. 見通しが立たない、想定できない、あり得ない、理解できない。
- 分かっている事項は何か
- お客様先の事象か / 社内環境の事象か
- Version
- 問題のプログラム / サブシステム / ID
- 社内ならどの環境で起こったのか
- 社内なら、以下はいくつか
- サーバー / Middleware Version / OS Version
- Client OS Version / IE Version
- ログインユーザ / 端末毎 の差異はあるか
- プログラムを立ち上げてから再現するまでの手順は
- 環境変数 / 実行コマンド
- 取得済ログは
- 既に試した事項と結果は何か
- 再現手段
- 分かっていない事項、調べていない事項は何か
- 仮説・想定は何か
- 自分で想定できた問題の原因・論拠は何か
- 自分で試せること・想定する結果は何か
- 手順
- 恒久対応策
- 暫定対応策
- 運用回避策
- 仮説に基づいて依頼したいことは何か
- お客様先にて試してほしいオペレーション・理由
- お客様先にて欲しいログ・理由
- 社内にて誰かに依頼したい事項・理由
- 問題、あるべき状態がどこにあるかを論理的に判断するために、具体的に**「固有名詞」と「数字」**で記載する。
- 良い例「〇〇環境でhh:mmに投げたID:xxxxxのジョブが詰まっている」(添付:ログ)
- 良くない例「ジョブが動きません」(口頭)
- 現段階で分かっている**「事実」** と 自分が勝手にそう思った**「仮説」**は明確に分ける。
- 良い例「22:00頃DBが重かった(事実)。アクセスが多そうだったと思った(仮説)。どこのどのログを確認したい(仮説の裏取り)。」
- 良くない例「22:00頃アクセスが多そうだった」(いろいろ根拠無し)
ここまで読んでも質問することをためらってしまう人へ「15分ルール」
質問って難しいですね。しかし先述のテンプレートでも触れたように、**15分ルール**というのが有名なようです。
Follow the “15-Minute Rule”
“Take 15 minutes to solve the problem any way you can. However, if you don’t have an answer after 15 minutes, you must ask someone.”
自分のできる範囲で15分かけて問題を解決すること。ただし15分経っても答えが出ない場合は、必ず誰かに聞くこと。
- New hires are taught self-reliance.
- Everyone knows they have an all important safety net if they get stuck.
- Junior teammates can get mentored by senior colleagues and see the logic of how they solve problems.
- Senior members get to informally review and give feedback on the team’s work.
新人さんに自助努力を促しつつ、困ったときはセーフティネットが必ずあることをチームで共有する。後輩は先輩の指導を受け、彼らがどのように問題を解決しているのかを知ることができる。先輩はチームの仕事をレビューし、フィードバックを与えてくれる。
ということで質問力のあるチームは良いチームです。幸せな質問ライフの一助になればさいわいです。
参考文献
他
- リモートワークのための質問力向上研修を実施しました - Classi開発者ブログ
- 良い質問をして自己成長に繋げるためのあれこれ - Qiita
- 「質問力たったの5か…ゴミめ……」と思われないための質問力の上げ方 - Qiita
- 技術的な質問をするときの5つのポイント
- 良い質問をするには? - ヘルプ センター - スタック・オーバーフロー
- 技術系メーリングリストで質問するときのパターン・ランゲージ
- 論理的思考力と議論
- エンジニアとしての質問・自走の使い分けとテクニック
- 「何がわからないのかわからない」は何がわからないのか - Qiita
- 何がわからないのかわからないはなにもわからない - Qiita
- ジュニアエンジニアに意識してほしいこと - 何でも屋エンジニアのブログ