5W1H（Why/What/Who/When/Where/How）は、日常のコミュニケーションやプロジェクトの設計・開発に有効な普遍の型です。 さらに、AI（LLM・エージェント）とのやり取りでも威力を発揮します。
過去にもテキストコミュニケーションのコツとしてSBIモデルコミュニケーションを紹介しましたが、5W1HはSBIモデルにも通じます。
そこで自分の登壇資料でも度々紹介している5W1Hに注目し、各要素の意味と役割、Why→What→制約→Howの順で書く理由を解説します。
引用元：問題を解決するために必要な習慣 / developer-lifehack p.76
1. 5W1Hとは
5W1Hは有名なフレームワークなのでご存じの方も多いと思います。 5W1H = Why / What / Who / When / Where / How の6つの項目からなり、情報の抜け漏れを防ぎ、議論を整理し、意思決定を速くするための枠組みです。*1
各項目の要点は以下のとおりです。
- Why：目的・意義・期待インパクト
- What：成果・スコープ（In/Out、受け入れ基準）
- Who / When / Where：コンテキスト上の制約（体制・期限・環境/法域）
- How：アプローチ・設計・手順
5W1Hについては、『マンガでわかる! 5W1H思考』がとてもわかりやすいので、ぜひ一読をお勧めします。
2. Whyから始めよ
Whyは出発点であり評価軸です。ここが曖昧だと議論が迷走し、意思決定が先延ばしになります。 結局、何が目的で、何を達成したいのかという「なぜ？」が明確でないと、WhatもHowもブレて成果が出ません。
また、Howから見ればWhyはゴールです。達成基準が曖昧だと、WhenやWhereが変わったときにHowをどう変えるべきか判断できません。 まずはWhyを正しく認知し、測定可能な言葉で明確にしましょう。
3. Whatが方向性を決める
Whyが目的・評価軸なら、Whatは方向性とスコープを定める要素です。 Whatによって進むべき道が決まり、何をやるか（In）／やらないか（Out）が決まります。
Why→Whatの順で明確にすることで、目的に沿った正しい方向性が固まり、無駄な議論を減らして意思決定が速くなります。プロジェクトの向き直しやプロダクトのピボットが必要になっても、Whyに立ち返ってWhatを再定義すれば迅速に軌道修正できます。
4. Who, When, Whereが制約になる
これらはWhatが決まった後に考える制約です。 制約が定まることでフォーカスが絞られ、実行すべき具体の範囲が決まります。
制約が変われば当然Howも変わります。 場合によっては How much も制約として加わります*2。 この場合、Howに対する予算や規模を決める役割を果たします。
制約は Why＋What と組み合わせて言葉にすると明確になります。 「なぜ（何を）、いつまでに？」「なぜ（何を）、誰に？」「なぜ（何を）、どこで？」といった形です。こうすることで制約の意味が明確になり、Howの範囲も具体化します。
引用元：『マンガでわかる! 5W1H思考』P.138
5. Why→What→制約→Howの構造を意識する
現場では、Howだけが指示される、または指示してしまうことが少なくありません。 しかし、WhyやWhatが不明確なままでは、条件変更が起きた途端に迷走します。 これは、Howから見たときのゴール（Why）が共有されていないためです。
したがって、実行や指示に入る前に、Why→What→制約→Howの順で明確化しましょう。 日常のコミュニケーションでも、プロジェクト設計でも、AIへの指示でも、この順番を守るだけで議論のノイズが減り、意思決定が速くなり、再現性が高まります。
この構造は『マンガでわかる! 5W1H思考』でも紹介されています。
引用元：『マンガでわかる! 5W1H思考』P.152
6. Howの抽象度を揃える
指示の効果は、Howの抽象度が揃っているかに強く依存します。
例を挙げると、Why「お腹が空いた」、What「晩ご飯を食べる」、When「今夜」、Where「家で」、Who「自分ひとり」と決まったとします。
ここでHowを「ラーメンを食べる」と決めても、実際にはさらにタスク分解が必要です。カップラーメンを作るのか、出前を取るのか。カップラーメンなら「お湯を沸かす」「蓋を開ける」などに分解されます。
このとき、「ラーメンを食べる」と「お湯を沸かす」は抽象度が異なり、同じレイヤーではありません。 多くのコミュニケーション齟齬は、Howの抽象度不一致に起因します。 うまくいかないときは、まずHowの抽象度を揃えることを意識してみてください。
これはAIへの指示でも同様です。抽象度が揃っていないプロンプトは、AIがどちらかの解像度に無理やり合わせてしまい、不適切な出力を生むことがあります。
引用元：抽象化をするということ - 具体と抽象の往復を身につける / Abstraction and concretization
7. Why/Whatの反証を考える
仮説を補強する情報ばかり集めると確証バイアスに陥り、誤った意思決定につながります。 これを避けるため、WhyやWhatを検証するときは反証（falsification）を必ず考えます。
例をあげるとWhy「売上を伸ばす」、What「新規顧客を増やす」とします。 それに対して反証は「売上が伸びないのは顧客単価の低下が主因では？」「新規顧客は増えても解約が悪化していないか？」などになります。
こうして反証を設計すると、Why、Whatや仮説の妥当性が見えてきますし、妥当性を検証するためのKPI（新規数・解約率・ARPUなど）が定まり、テストやモニタリングの設計が明確になります。
とくにデータ分析やAIの出力を使う場面では、反証に耐えられるかを立証する視点が重要です。 テストコード作成、PoC、AIへの指示のいずれでも、Why/Whatの仮説が反証に耐えられるかを常に確認しましょう。
8. おわりに
5W1Hは古典的なフレームワークですが、構造を意識して常に満たすだけで、コミュニケーションもプロジェクト設計も滑らかになります。 とくにドキュメントやチケットなど、テキスト化する際は、 Why→What→制約→How の順で書けているかを点検しましょう。 慣れれば自然にできるようになります。
自分が5W1Hを意識できるようになると、他者の5W1Hの不足にも素早く気づけ、齟齬を早期に潰せます。 言語化が得意な人が苦手な人の分まで補ってしまうケースも見られますが、それは相手に過度な負担をかけているということです。 まずは自分が5W1Hを意識し、言語化を怠らないことを心がけましょう。
AIも人間も、コミュニケーションの基本は同じ、正確な言語化から始まります。
