/note/knowledge

言語化のコツ - AIも人間も5W1Hで上手くいく

要約:

■ 1. 5W1Hの基本構造

  • 定義: Why / What / Who / When / Where / Howの6つの項目からなるフレームワーク
  • 目的: 情報の抜け漏れを防ぎ、議論を整理し、意思決定を速くするための枠組み
  • 適用範囲: 日常のコミュニケーション、プロジェクトの設計・開発、AI(LLM・エージェント)とのやり取りに有効
  • SBIモデルとの関係: テキストコミュニケーションのコツとして紹介されているSBIモデルコミュニケーションにも通じる

■ 2. 各項目の要点

  • Why: 目的・意義・期待インパクト
  • What: 成果・スコープ(In/Out、受け入れ基準)
  • Who / When / Where: コンテキスト上の制約(体制・期限・環境/法域)
  • How: アプローチ・設計・手順

■ 3. Whyの重要性

  • 出発点と評価軸: Whyは出発点であり評価軸である
  • 曖昧さの弊害: Whyが曖昧だと議論が迷走し、意思決定が先延ばしになる
  • 全体への影響: 何が目的で何を達成したいのかというなぜが明確でないと、WhatもHowもブレて成果が出ない
  • ゴールとしての役割: Howから見ればWhyはゴールであり、達成基準が曖昧だとWhenやWhereが変わったときにHowをどう変えるべきか判断できない
  • 明確化の必要性: まずはWhyを正しく認知し、測定可能な言葉で明確にする必要がある

■ 4. Whatの役割

  • 方向性とスコープ: Whyが目的・評価軸なら、Whatは方向性とスコープを定める要素
  • 意思決定の明確化: Whatによって進むべき道が決まり、何をやるか(In)、やらないか(Out)が決まる
  • Why→Whatの順序: この順で明確にすることで目的に沿った正しい方向性が固まり、無駄な議論を減らして意思決定が速くなる
  • 軌道修正の容易さ: プロジェクトの向き直りやプロダクトのピボットが必要になっても、Whyに立ち返ってWhatを再定義すれば迅速に軌道修正できる

■ 5. Who、When、Whereの制約

  • 位置づけ: Whatが決まった後に考える制約
  • フォーカスの絞り込み: 制約が定まることでフォーカスが絞られ、実行すべき具体の範囲が決まる
  • 各制約の内容:
    • When(期限): 法規制・イベント・季節性
    • Who(体制/対象): 人数・スキル・ステークホルダー
    • Where(環境): チャネル/デバイス/拠点/法域/セキュリティ制約
  • Howへの影響: 制約が変われば当然Howも変わる
  • How muchの追加: 場合によってはHow muchも制約として加わり、Howに対する予算や規模を決める役割を果たす

■ 6. 制約の明確化

  • 組み合わせの効果: 制約はWhy+Whatと組み合わせて言葉にすると明確になる
  • 具体例: なぜ(何を)、いつまでに、なぜ(何を)、誰に、なぜ(何を)、どこでといった形
  • 効果: こうすることで制約の意味が明確になり、Howの範囲も具体化する

■ 7. Why→What→制約→Howの構造

  • 現場の問題: Howだけが指示される、または指示してしまうことが少なくない
  • 迷走の原因: WhyやWhatが不明確なままでは条件変更が起きた途端に迷走する
  • ゴール共有の不足: これはHowから見たときのゴール(Why)が共有されていないため
  • 実践の重要性: 実行や指示に入る前にWhy→What→制約→Howの順で明確化する
  • 効果: この順番を守るだけで議論のノイズが減り、意思決定が速くなり、再現性が高まる
  • 適用範囲: 日常のコミュニケーション、プロジェクト設計、AIへの指示のいずれでも有効

■ 8. Howの抽象度を揃える

  • 重要性: 指示の効果はHowの抽象度が揃っているかに強く依存する
  • 具体例: Why「お腹が空いた」、What「晩ご飯を食べる」、How「ラーメンを食べる」の場合、さらにタスク分解が必要
  • 抽象度の不一致: ラーメンを食べるとお湯を沸かすは抽象度が異なり同じレイヤーではない
  • 齟齬の原因: 多くのコミュニケーション齟齬はHowの抽象度不一致に起因する
  • 改善方法: うまくいかないときはまずHowの抽象度を揃えることを意識する
  • AIへの適用: AIへの指示でも同様で、抽象度が揃っていないプロンプトはAIがどちらかの解像度に無理やり合わせてしまい不適切な出力を生むことがある

■ 9. Why/Whatの反証を考える

  • 確証バイアスの回避: 仮説を補強する情報ばかり集めると確証バイアスに陥り誤った意思決定につながる
  • 反証の必要性: WhyやWhatを検証するときは反証(falsification)を必ず考える
  • 具体例: Why「売上を伸ばす」、What「新規顧客を増やす」に対して、売上が伸びないのは顧客単価の低下が主因では、新規顧客は増えても解約が悪化していないかなどの反証を考える
  • 効果: 反証を設計するとWhyやWhatや仮説の妥当性が見えてきて、妥当性を検証するためのKPIが定まり、テストやモニタリングの設計が明確になる
  • データ分析とAI: データ分析やAIの出力を使う場面では反証に耐えられるかを立証する視点が重要
  • 検証の習慣: テストコード作成、PoC、AIへの指示のいずれでもWhy/Whatの仮説が反証に耐えられるかを常に確認する

■ 10. 実践のコツと効果

  • フレームワークの性質: 5W1Hは古典的なフレームワークだが、構造を意識して常に満たすだけでコミュニケーションもプロジェクト設計も滑らかになる
  • ドキュメント作成: テキスト化する際はWhy→What→制約→Howの順で書けているかを点検する
  • 習熟: 慣れれば自然にできるようになる
  • 他者への気づき: 自分が5W1Hを意識できるようになると他者の5W1Hの不足にも素早く気づけ齟齬を早期に潰せる
  • 負担の分散: 言語化が得意な人が苦手な人の分まで補ってしまうケースも見られるが、それは相手に過度な負担をかけているということ
  • 基本の徹底: まずは自分が5W1Hを意識し言語化を怠らないことを心がける
  • 普遍性: AIも人間もコミュニケーションの基本は同じで、正確な言語化から始まる