stakeholder-review

概要

Stakeholder-review は、成果物が確定する前に組織全体から厳しい検証を受けることを確実にする「Group IQ」のゲートです。フィードバックを、摩擦の多い「プッシュ」（与えること）から、価値の高い「プル」（求めること）へと変え、認識の一致、安全性、相反する意見の明確な解決に重点を置きます。

鉄則

NO FINAL VERSION WITHOUT DOCUMENTED STAKEHOLDER FEEDBACK AND RESOLUTION

この鉄則に違反すると、プロセスの後半で「影の拒否権」が発動したり、成功指標について認識がずれたり、Group IQ を高める重要な部門横断的な知見が排除されたりします。

ステートマシン

digraph stakeholder_review_flow {
    "Deliverable Drafted" [shape=doublecircle];
    "Step 1: Prepare Pre-read" [shape=box];
    "Step 2: Align Purpose" [shape=box];
    "Step 3: Review Session" [shape=box];
    "Gate: Resolution" [shape=diamond];
    "Step 4: Close the Loop" [shape=box];
    "Final Version Approved" [shape=doublecircle];

    "Deliverable Drafted" -> "Step 1: Prepare Pre-read";
    "Step 1: Prepare Pre-read" -> "Step 2: Align Purpose";
    "Step 2: Align Purpose" -> "Step 3: Review Session";
    "Step 3: Review Session" -> "Gate: Resolution";
    "Gate: Resolution" -> "Step 1: Prepare Pre-read" [label="revise"];
    "Gate: Resolution" -> "Step 4: Close the Loop" [label="resolved"];
    "Step 4: Close the Loop" -> "Final Version Approved";
}

このスキルを使用する場面

• 重要度の高いドキュメント（PRD、戦略メモ、ピッチデッキ）を確定する前。
• プロジェクトに複数の部門横断的な依存関係がある場合。
• 四半期ビジネスレビュー（QBR）やプロジェクトの振り返りの際。
• 提案に対する反応に「沈黙」や「攻撃」が見られる場合。

このスキルを使用しない場面

• 重要度の低い、反復的な社内チームの進捗共有。
• 純粋なブレインストーミングの場（代わりに problem-framing を使用してください）。
• 技術的または戦略的な批評ではなく、精神的なサポートを求めている場合。

主なプロセス

ステップ 1：事前資料を準備する

• ストーリーを簡潔にまとめる： 過去を振り返る指標と今後の目標の両方を盛り込んだ、簡潔な（およそ 5 ページの）ドキュメントまたはプレゼンテーションを作成します。（出典：Johnson, Scaling People）
• 事前に配布する： 会議の 24〜48 時間前にドキュメントを共有します。事前資料がない場合は、セッションの最初の 15〜20 分間を黙読に充てます。（出典：Johnson, Scaling People）

ステップ 2：目的をすり合わせる

• フィードバックの種類を明示する： 求めているのが 称賛（認めること）、コーチング（改善のための助言）、評価（基準に照らした査定）のいずれなのかを明確に伝えます。（出典：Stone, Thanks for the Feedback）
• 期待値をすり合わせる： 「この戦略についてコーチングをお願いしたいと思っています。それに向けて準備していただけましたか？」と確認します。これにより、一方がコーチングを求めているのに、もう一方が評価を行うといった「すれ違い」を防げます。（出典：Stone, Thanks for the Feedback）

ステップ 3：レビューセッションを実施する

• 「フィードバック」ではなく「アドバイス」を求める： 「フィードバックはありますか？」ではなく、「どのようなアドバイスがありますか？」と尋ねます。これにより、対人関係上の摩擦が軽減され、より実行可能な意見が集まりやすくなります。（出典：First Round Review, Berry）
• 対立するのではなく、共に見る： ステークホルダーの「隣に立って」、一緒に成果物を見ます。「メタに移る」戦術を使い、「重要な課題について話せていないように感じます。避けている課題はありますか？」と尋ねます。（出典：Johnson, Scaling People）
• 安全性を保つ： ステークホルダーが沈黙や攻撃に移った場合は、議題の内容からいったん離れ、相互の目的と相互尊重を用いて安全性を取り戻します。（出典：Grenny, Crucial Conversations）

ステップ 4：フィードバックを反映する

• 決定事項を記録する： 決定事項と次のステップを明記して記録します。（出典：Johnson, Scaling People）
• アクションプランを共有する： 寄せられたフィードバックと、その解決方法の要約を配布します。「フィードバックを反映した結果を共有」することで、ステークホルダーが最終的な成果に積極的に関わるようになります。（出典：First Round Review, Berry）

他のスキルとの連携

必須サブスキル：stakeholder-discovery — 適切な人が会議に参加していることを確認します。 推奨サブスキル：assumption-audit — レビュー中に出た主張を検証します。 推奨サブスキル：feedback-coach — セッション中の難しい対人関係を調整します。

合理化の表

考え	現実
「Slack／メールで承認をもらえばいいだけだ」	非同期のフィードバックでは、ライブで構造化されたレビューによる「グループの知性」と微妙なニュアンスが得られません。
「関係者は忙しすぎて、会議に出られない」	今この段階を省くと、後になって多額の手戻りが発生したり、終盤に「裏で拒否」されたりします。
「バージョンが完成してから話せばいい」	それでは遅すぎます。鉄則では、効果を得るには最終決定の前にフィードバックを受ける必要があります。
「相手が何と言うかは、もうわかっている」	確証バイアスによって、成功に欠かせないことの多いフィードバックの10％が見えなくなります。

危険信号

次のように考えている場合は、一旦止まってください。近道をしようとしています。

• 「これはチェック項目を埋めるための形式的な手続きにすぎない」→「グループの知性」がもたらす価値を無視しています。
• 「チームに伝える前に、相手のフィードバックを取捨選択しよう」→透明性と信頼を損なっています。
• 「相手が話している間に、反論を準備している」→「真実の引き金」が引かれ、もう話を聞けていません。

診断チェックリスト

• 事前資料は24時間以上前に配布されていますか？
• 求めるフィードバックの種類（評価、コーチング、評価）について、明確に合意していますか？
• 摩擦を減らすために、「アドバイス」という言葉を使っていますか？
• 決定事項と次のステップを記録する専任の書記がいますか？
• 「部屋の中の象」（言えないと思っていること）を言葉にしましたか？

出典

• Johnson, Scaling People, 第2章・第5章 — QBR、事前資料を読む文化、社内コミュニケーション。
• Stone & Heen, Thanks for the Feedback, 第2章・第3章 — フィードバックの三要素と目的のすり合わせ。
• Grenny et al., Crucial Conversations, 第5章 — 安全性と共通の目的。
• First Round Review, 「The Best Leaders are Feedback Magnets」— アドバイスとフィードバック、フィードバックを最後まで完了させること。