⑩「動的リスク」を捉えるレトロスペクティブ設計—Agentforce Voice導入で使えるふりかえりテンプレート【Salesforce×PMO×郭嘉】

郭嘉の思考の核心は、静的な情報だけでなく「状況が動いた瞬間」を捉えることにありました。今回は、この"動的リスク"の視点を、Agileのレトロスペクティブ（ふりかえり）に組み込む設計を紹介します。

「静的リスク」と「動的リスク」の違い

一般的なリスク管理は、プロジェクト開始時に洗い出した「静的リスク」（要員不足、予算超過、要件の複雑さなど）を管理することが中心です。

しかし実際にプロジェクトを炎上させるのは、進行中に状況が変化することで新たに生まれる「動的リスク」であることが多いです。

• 想定していなかったAPI連携の仕様制約が、統合テスト段階で発覚する

• キーマンの異動・離脱により、暗黙知が急に失われる

• 経営層の優先順位が変わり、スコープが土壇場で追加される

郭嘉が曹操に評価されたのは、まさにこうした「状況が変化した瞬間」を誰よりも早く捉え、次の一手を提案できたからです。通常のリスク登録簿の更新は月次・隔週が多く、この俊敏さに追いつけません。

レトロスペクティブを「動的リスク検知の場」に再設計する

多くのAgileチームのレトロスペクティブは「良かったこと・改善したいこと（KPT/KPTA）」の振り返りに留まっています。ここに、動的リスクを拾うための問いを追加します。

追加する3つの問い

1. 「今週、想定と違ったことは何か」
   　　良し悪しに関わらず、"予測が外れた事象"を全員で列挙する。これが動的リスクの種です。

2. 「その予測外れは、他のどこに波及しうるか」
   　　1つのチームで起きた予測外れが、別チームの計画にどう影響するかを考える。Salesforce実装であれば、フロント（SCV/Agentforce Voice画面）の仕様変更がバックエンド（Amazon Connectフロー）に波及するようなケースが典型です。

3. 「次のスプリントで、これを"静的リスク"として登録すべきか」
   　　一過性か、継続的に管理すべきリスクかをその場で判定し、必要ならリスク登録簿に正式に追加する。

Agentforce Voice案件で特に効くふりかえりの型

音声・AI関連の機能は、テストで発見しにくい"体感品質"の問題が多く発生します。以下の型をレトロスペクティブに組み込むと効果的です。

• AI応答精度のドリフト確認：先週と今週で、AIの応答傾向に変化がなかったかを定性的にレビューする

• オペレーター体感のヒアリング：現場のオペレーターが感じた"やりづらさ"を毎回1つ以上共有してもらう

• 通話品質の異常値チェック：レイテンシや切断率など、監視データの異常値を機械的にレビューする時間を固定で設ける

テンプレート：動的リスク・レトロスペクティブ（60分構成）

1. 良かったこと・困ったこと共有（15分）：通常のKPT

2. 予測外れの棚卸し（15分）：上記「追加する3つの問い」の1・2を実施

3. 音声/AI特有の体感レビュー（15分）：Agentforce Voice案件の場合のみ

4. 静的リスクへの正式登録判定（15分）：問い3を実施し、リスク登録簿を更新

まとめ：ふりかえりは「過去の反省」ではなく「未来の予兆」を拾う場

郭嘉の強みは、過去の失敗を分析することよりも、今まさに動いている状況から次の展開を読むことにありました。レトロスペクティブも、単なる反省会ではなく、動き続けるプロジェクトの中から次のリスクの芽を拾う場として設計し直すことで、初めて"動的"な価値を持ちます。

もしこの記事を読んで「くわしく知りたい」と感じたなら、次の3冊は必読です。

アジャイルなチームをつくる ふりかえりガイドブック 始め方・ふりかえりの型・手法・マインドセット

チームファシリテーターとしてふりかえりを突き詰めてきた
著者の豊富な経験をもとにした解説で、具体的な始め方、
チームの状況にあった型や手法の選び方がわかります。

Amazonで確認する。

SCRUM BOOT CAMP THE BOOK【増補改訂版】 スクラムチームではじめるアジャイル開発

Amazonで確認する。


<関連記事>

この記事が参考になったら、スキ・フォローをお願いします。

#三国志 #PMO #Salesforce #AgentforceVoice #AmazonConnect #レトロスペクティブ #アジャイル #十勝十敗