― 丸投げを防ぎ、良回答を引き出す技術 ―
1. はじめに
エンジニアリングの現場では「質問力」が評価に直結します。
しかし、質問の仕方を体系的に学ぶ機会はほとんどありません。
この記事では、
- 相手に伝わりやすく
- 回答の質が最大化され
- 丸投げにならない
そんな質問の作り方を、フォーマット・図解・実例つきで解説します。
2. なぜ質問力が重要なのか
質問力が高いと、次のようなメリットがあります。
- 誤解が減る
- 回答が速くなる
- 相手の負担が減る
- 自分の理解が深まる
- 評価が上がる
質問力は“コミュニケーションの生産性”を高める技術です。
3. NG質問の典型パターン
❌ 丸投げ
これどうすればいいですか？
❌ 情報不足
エラーが出ました。助けてください。
❌ 範囲が広すぎる
このシステムってどう設計すればいいですか？
❌ 目的が不明
AとBどっちがいいですか？
どれも「前提・目的・自分の考え」がなく、
相手がゼロから考え直さないといけない質問になっています。
4. 良い質問の構造（5層モデル）
良い質問には、共通する「型」があります。
┌────────────────────────────────────────────────────┐
│ 良い質問の構造（5層モデル） │
├────────────────────────────────────────────────────┤
│ 1. 結論：何を知りたいか（最短でゴールを共有する）─ │
│ 2. 前提：背景・環境（情報のズレをなくす） │
│ 3. 自分の理解・仮説：私はこう思う（丸投げを防ぐ） │
│ 4. 調査・試行：何を調べ、何を試したか（重複回答防止） │
│ 5. 質問：焦点を絞った問い（相手の思考コストを最小化） │
└────────────────────────────────────────────────────┘
この5つを埋めるだけで、
相手が答えやすく、誤解が少なく、深い回答が返ってくる質問になります。
5. 疑問が出たときに 5層構造へ変換するプロセス
いきなり5層を全部埋めようとすると負荷が高いので、
段階的に5層へ到達するプロセスとして整理します。
STEP1：まず「モヤっとした疑問」をそのまま書く
最初は雑でOK。思考の生ログでいいです。
例：
「このAPIのエラーコードってどう扱うんだっけ？」
「キャッシュってどれが正解なんだ？」
STEP2：その疑問を「結論（知りたいこと）」に変換する
モヤっとした疑問を 1行の質問に圧縮します。
例：
「POST /user のエラーコードの扱いについて確認したい」
→ これで 5層の①：結論 が完成。
STEP3：状況を思い出して「前提・状況」を書く
自分が何を見た／何をしていたかを整理します。
例：
仕様書のエラー一覧を読んだ
不正データを送ったら 409 が返った
→ これで ②：前提・状況 が完成。
STEP4：自分の理解・仮説を言語化する
「私はこう思う」を必ず入れます。
例：
「バリデーションは400、業務エラーは409だと理解している」
→ これで ③：自分の理解・仮説 が完成。
STEP5：試したこと・調べたことを整理する
重複回答を避けるための情報です。
例：
「仕様書を確認したが、業務エラーの基準が不明」
「実際に送信したら 409 が返った」
→ これで ④：調査・試行 が完成。
STEP6：最後に「質問」を選択肢 or 焦点に絞って書く
ここが一番重要です。
例：
「このケースは 400 と 409 のどちらが正しいでしょうか？」
「業務エラーの基準を教えてほしいです。」
→ これで ⑤：質問 が完成。
疑問 → 5層構造はこの流れで作れる
疑問が出る
↓
① 結論（知りたいこと）に変換
↓
② 前提・状況を書き出す
↓
③ 自分の理解・仮説を書く
↓
④ 試したことを書く
↓
⑤ 質問を選択肢 or 焦点に絞る
6. 実例：Linuxでエラーが出たとき
ここでは、実際の疑問を5層モデルに変換するプロセスを実演します。
STEP1：生の疑問
Linuxでエラーが出た、どうしたらいい？
STEP2：① 結論
【質問内容】
Linuxで発生したエラーの原因と対処方法を知りたいです。
STEP3：② 前提・状況
【前提・状況】
・yum update を実行した際にエラーが発生しました。
・環境は Rocky Linux 8.9 です。
STEP4：③ 自分の理解・仮説
【自分の理解・仮説】
依存関係の衝突が原因ではないかと考えています。
STEP5：④ 試したこと
【試したこと】
・dnf clean all を実行しましたが改善しませんでした。
・/var/log/dnf.log を確認しましたが、原因を特定できませんでした。
STEP6：⑤ 質問
【質問】
このエラーは依存関係の問題でしょうか？
また、切り分けのために確認すべきポイントがあれば教えていただけると助かります。
完成した5層モデル（実演版）
【質問内容】
Linuxで発生したエラーの原因と対処方法を知りたいです。
【前提・状況】
・yum update を実行した際にエラーが発生しました。
・環境は Rocky Linux 8.9 です。
【自分の理解・仮説】
依存関係の衝突が原因ではないかと考えています。
【試したこと】
・dnf clean all を実行しましたが改善しませんでした。
・/var/log/dnf.log を確認しましたが、原因を特定できませんでした。
【質問】
このエラーは依存関係の問題でしょうか？
また、切り分けのために確認すべきポイントがあれば教えていただけると助かります。
結論：最初は「穴埋め形式」でOK。
繰り返すと、疑問が出た瞬間に自動で5層で考えられるようになる。
7. 質問フォーマット（用途別）
7-1. 汎用フォーマット
【質問内容】
【前提・状況】
【困っていること】
【自分の理解・仮説】
【試したこと】
【質問】
7-2. 選択肢提示型
【前提】
【自分の理解】
【選択肢】
A案：
B案：
C案：
【質問】
上記の前提で、どの案が適切でしょうか？
7-3. トラブルシュート型
【問題】
【状況】
【試したこと】
【仮説】
【質問】
7-4. 仕様確認型
【確認したい仕様】
【前提】
【自分の理解】
【疑問点】
【質問】
7-5. タスク相談型
【現状】
【自分の考え】
【選択肢】
【質問】
8. 現場での実例（Before/After）
Before（NG）
キャッシュってどうしたらいいですか？
After（5層モデルを意識した質問）
【質問内容】
ユーザー情報のキャッシュ方式について相談です。
【前提】
読み取り頻度が高く、更新頻度は低い状況です。
【自分の理解】
ローカルキャッシュが最もパフォーマンスが良いと考えています。
【選択肢】
A案：アプリ内ローカルキャッシュ
B案：Redisキャッシュ
C案：キャッシュなし（DB直）
【質問】
上記の前提で、どの方式が最適でしょうか？
特に「更新頻度が低い場合」の判断基準を知りたいです。
9. 質問力を鍛えるための習慣
- 質問前に「自分の仮説」を1行書く
- 質問を“選択式”に変換してみる
- 前提・状況を必ず書く
- 質問は1つに絞る（欲張って詰め込みすぎない）
10. まとめ
- 質問力はセンスではなく 技術
- 「5層モデル」と「フォーマット」を使えば、誰でも再現性高く鍛えられる
- 最初は 穴埋め形式 でOK
- 繰り返すことで、自動的に5層で考える思考回路 が身につく
- 具体的に説明する・エラーメッセージを提示する・試したことを伝える・質問を簡潔にする
このあたりを「5層モデル」に乗せていくと、現場でのコミュニケーションが一気に楽になります。