Salesforceプロジェクトのリスク管理：郭嘉に学ぶ「兆候」の読み方と、報告・対応の型【実践編】(十勝十敗の理-番外編)

前回の記事「十勝十敗の理」の実践編です。

導入：リスクは「起きてから」では遅い

郭嘉は、孫策の死や袁紹軍の内部不和といった「起きる前の歪み」を読み、曹操に進言しました。

PMOに必要なのも同じ力です。

リスクそのものではなく、リスクの手前にある兆候を拾うこと。

これが今回のテーマです。

1. 何を観察するか：兆候センサー5選

兆候は、数字に出るものと空気に出るものに分かれます。

数字に出る兆候

・ベロシティと完了率の乖離
ポイントは消化しているのに、受け入れ完了が増えない

・変更要求の増え方
件数より「同じ画面・同じ機能への再変更」の回数を見る

・不具合の再オープン率
修正の質ではなく、要件理解のズレを示す

空気に出る兆候

・レビューでの沈黙
ユーザー部門が質問も反対もしなくなったときは要注意

・用語のズレ
「案件」「リード」「完了」など、同じ言葉を別の意味で使っている

特に危険なのは用語のズレです。

数字には出ないまま、リリース直前に爆発します。

2. 何を「兆候」と判断するか

1回の遅延は、ただの遅延です。

3スプリント連続で同じ種類の遅延が続けば、それは構造の問題です。

判断の基準は3つです。

1. 反復：同じ種類の事象が2回以上起きていないか
2. 傾向：悪化の方向に動いていないか
3. 波及：他チーム・他機能に飛び火しそうか

このうち2つ以上が当てはまったら、「兆候」として扱います。

台帳に書く前に、まず兆候メモを残してください。

日付／事象／気になった理由（3行）

この小さな点の積み重ねが、「線」になります。

3. 誰に報告するか：相手によって目的が違う

郭嘉は、同じ懸念でも相手と伝え方を選びました。

報告も、相手によって目的が変わります。

PL・開発リード

目的：事実確認と原因の切り分け
伝えること：事象・頻度・影響範囲

顧客PM・業務責任者

目的：判断と協力の依頼
伝えること：選択肢と期限

経営層・スポンサー

目的：意思決定と資源の確保
伝えること：影響の大きさと推奨案

大切なのは、現場にはまず「確認」、経営には最初から「判断」を求めることです。

経営層に事象だけ伝えても、動いてもらえません。

4. 報告の型：「兆候→影響→選択肢→推奨」の4行

報告は長くすると読まれません。

次の4行に収めます。

兆候：直近3スプリントで、受け入れ時の再変更が毎回増加している
影響：このままだと、本番リリースが2週間遅れる可能性がある
選択肢：A. スコープ縮小　B. 受け入れ基準の事前合意　C. 期間延長
推奨：Bを即実施。来週のレビューで効果を確認し、改善しなければAへ

郭嘉が曹操に「勝てるが、代償は何か」を添えたのと同じ構造です。

問題だけを持っていかず、必ず選択肢と推奨を添える。

これだけで、報告が「愚痴」から「進言」に変わります。

5. 対応の型：小さく打ち、効果を測る

兆候への対応は、いきなり大手術をしないのが原則です。

1. 一手目は小さく：ルールの追加、レビューの前倒し、確認の1回増加など
2. 見る指標を決めておく：「次のスプリントで再変更が減ったか」を判定基準にする
3. 効かなければ二手目へ：スコープ調整や体制変更など、重い手に進む

そして結果は必ず振り返ります。

うまくいった手も、効かなかった手も「理」として残す。

これが「十勝十敗の理」につながります。

6. よくある失敗：兆候を見ても動けない3つの理由

・「まだ問題になっていない」と思ってしまう
兆候は、問題になる前だから兆候です

・指摘して空気を悪くしたくない
一時の停滞が、全体の前進を守ります

・自分の責任範囲ではないと考える
PMOの仕事は、境界をまたぐ歪みを拾うことです

まとめ

・観察：数字と空気、両方のセンサーを持つ
・判断：反復・傾向・波及で「線」にする
・報告：相手を選び、4行の型で伝える
・対応：小さく打ち、測り、振り返る

郭嘉の先見は、予知ではなく観察の積み重ねでした。

明日から、まず「兆候メモ」を1行書くことから始めてみてください。

<関連記事>

<参考書籍>
▶︎SCRUM BOOT CAMP THE BOOK【増補改訂版】 スクラムチームではじめるアジャイル開発

基礎編、実践編と
架空の開発現場を題材に、開発が始まるときから時系列にスクラムではどう進めていくのかを説明されていており読みやすい。
Amazonでみる

#Salesforce #PMO #プロジェクトマネジメント #リスク管理 #郭嘉 #三国志 #三国志に学ぶプロジェクトマネジメント #十勝十敗 #実践