過去案件ブレストが採用される理由と、その限界
リスクの抽出において多くの現場で見られるのが、過去プロジェクトのリスク一覧を参考にしながら、チームでブレストもしくは、たたき台として作ったリスク一覧のレビューを行うアプローチです。
「前回のプロジェクトではこんなリスクがあった」「このベンダーとは以前トラブルがあった」「要件が曖昧になりやすい」といった意見を出し合い、過去の失敗事例を共有しながら一覧を作っていく。
このアプローチが採用されるのは、過去の経験が貴重な財産だからです。
同じ失敗を繰り返さないために、過去のリスク一覧を参照することは有効ですし、複数の視点でリスクを検討すること自体は必要なプロセスです。
経験豊富なメンバーがいれば、重要なリスクをいくつか発見できますし、決して悪いものではありません。
ただし、このアプローチには限界もあります。
リスク一覧が形骸化する4つの構造
断片的なリスク抽出になり、プロジェクト固有のリスクを見落とす
過去の案件と全く同じ状態のプロジェクトはありません。
ベンダーの組み合わせ、活用する技術やサービス、規模、すべてが異なります。
過去の経験をベースにしても、今回のプロジェクト固有のリスクを見落としてしまうのです。
議論が会社内部に潜むリスクに偏りがち
ブレストでは「このベンダーの品質が心配」「あのチームは進捗管理が甘い」「要件が曖昧で設計に着手できないかもしれない」といった、各社内部のリスクに議論が集中しがちです。
言いやすいリスクですし、確かにこれらも大きなリスクになり得ますが、全体PMOが注目すべきは、プロジェクト全体、横断のリスクであるはずです。
リスクは無限にあるため、考え切れない
一定規模を超えたプロジェクトは、単一部署、ベンダーだけにとどまることはほとんどありません。
そのようなプロジェクトの開始時は、先も長く不確実性も高い。
あらゆる可能性を考慮しようとすると、リスク一覧は際限なく膨れ上がる。
結局、優先順位が不明確なまま、数十個のリスクがリストアップされて終わります。
リスク検知が働かない
リスク一覧を作っただけで、それを計画に反映していなければ検知できません。
断片的で優先順位やチェックポイントが不明確なリスク一覧では、定期的な棚卸しもされず、形骸化してしまいます。
せっかく作ったリスク一覧も誰も見なくなり、いざリスクが顕在化すると慌てて対処することになります。
「接合点」に焦点を当ててリスクを抽出する
全体PMOという立場にある方々のリスク管理という意味でJQが推奨するのは、
会社間リスクとプロジェクト間リスク、つまり接合点に焦点を当ててリスクを抽出する方針です。
プロジェクト開始時には、極力発生リスクが高く、顕在化したときにコストやスケジュールなどに与えるインパクトが大きなものを列挙する。
すべてのリスクを洗い出そうとするのではなく、本当に重要なリスクに絞り込むことが有効です。
そもそもリスクは大きく3つに分類できます。
社会的リスク（地震・コロナなど社会で起きた問題によるリスク）、プロジェクト外リスク（発注元の会社の業績悪化など）、プロジェクト内リスク（要件の曖昧さ、ベンダーの品質低下など）です。
社会的リスクやプロジェクト外リスクは発生確率が低いか、コントロール不能なものが多いため、開始時に積極的に考える必要はありません。
本当に重要なリスクは、プロジェクト内リスクです。
特に、マルチベンダー開発の全体PMOという立場であれば、会社間リスクとプロジェクト間リスクという観点でリスクを洗い出すのが最も実効性が高い。
なぜなら、こうしたリスクは顕在化しやすく、顕在化した場合、プロジェクト全体の計画変更や予算追加など大きな調整が必要になる傾向があるからです。
会社間リスクは、具体的には4つの観点で見ます。
ベンダー間の接合点（設計・結合テストの依存関係）
外部設計の開始や終了、外部結合テストの開始や終了に関わるリスクです。
ベンダーAの設計が遅れると、ベンダーBの開発着手が遅れる。
こうした依存関係のある接合点は、リスクが顕在化しやすい。
クライアントとベンダー間の接合点（要件定義・受入テスト）
要件定義の開始や終了、受入テストの開始や終了。
ここでは、クライアントの意思決定が遅れる、レビューに時間がかかる、というリスクは頻発します。
SaaSなど外部サービス利用の接合点
外部サービスの選定、契約、連携テスト。
仕様変更や契約手続きの遅延はプロジェクト全体に影響します。
審査機関（Apple審査など）との接合点
iOSアプリ審査のリジェクトリスク、審査基準の変更、想定外の指摘。これらも頻繁に発生します。
プロジェクト間リスクとは、検証環境の競合や人的リソースの競合。
マルチベンダ開発など、大規模かつ長期プロジェクトでは、担当プロジェクト以外にも複数のプロジェクトがクライアントやベンダー内で並走することが多々あります。
そのような場合、同じ本番や検証環境を使うことや、人的リリースの取り合いにあるようなリスクが考えられます。このような並走プロジェクトがどの程度あり、相互に依存する要素が何かを全体PMOとしては抑え、そこに潜むリスクを洗い出す必要があります。
その他のプロジェクト内リスクとして、会社内リスク（特定ベンダー内の品質や進捗の遅れ）も挙げられますが、これは各会社がまずは真剣に向き合いコントロールするものだと考えています。
全体PMOも当然点検はしますが、リスクが顕在化した場合は、まず各社が要員追加等でリカバリし、会社間リスクを顕在化させないように対処するのが原則。
プロジェクト開始時点で、全体PMOが積極的に洗い出しや対処方法を考える対象にはしなくてよいでしょう。
接合点でのリスクを徹底的に洗い出し、計画としてリスクを低減できる策がないか、リスク検知のマイルストンをプロジェクト初期に考え、スケジュールや体制に反映しておくことがとても大事です。
マスタースケジュールと構成図から接合点とリスクを考える
接合点とそのリスクを考える具体的な抽出手順は次の3ステップです。
マスタースケジュールから接合点を見つける
各ベンダーのスケジュールが一覧化されているマスタスケジュールから複数のベンダー間、クライアント・ベンダー間の接合点に関するリスクを探ります。
「ベンダーAの外部設計完了予定日と、ベンダーBの開発着手予定日の間隔はどれくらいか」「バッファは十分か」「レビュー期間は適切か」を一つひとつ確認していく。
システム構成図から接合点を見つける
各ベンダーから出してもらうシステム構成図から、利用するサービス（スマホアプリ、SaaSなど）を確認し、審査機関との接合点や外部サービス利用に関するリスクを探ります。
「このシステムはスマホアプリだからAppleやGoogle審査がある、審査期間はスケジュールに織り込まれているか」「このSaaSとの連携は誰が担当するのか、契約手続きは誰が進めるのか」といった視点で確認していく。
各社が出す計画と構成図を、徹底的に確認する
マルチベンダー開発では、ある程度マイルストーンを決めても、各ベンダーが思い思いにスケジュールを作ってきます。
できるだけ自分たちのリスクを下げられる計画やアーキテクチャを提案してくる。
「このベンダーのテスト完了予定日は、次のベンダーの着手に間に合うのか」「この外部サービスとの連携は、誰がいつテストするのか」といった疑問を一つひとつ潰していきます。
この方針の最大のメリットは、リスクが具体的で実効性があること。
接合点という明確な観点があるため、リスクの抽出漏れが減り、顕在化しやすく影響の大きいリスクに焦点が当たるため、優先順位も明確になります。
チェックポイントをマスタースケジュールに明記する
このアプローチを実践するうえで、3つの注意点があります。
リスク低減策をスケジュールや体制に反映する
リスク一覧を作るだけでは意味がない。
「ベンダーAとBの間にバッファが足りない」というリスクを発見したら、スケジュールを調整してバッファを確保する。
「Apple審査の期間が織り込まれていない」というリスクを発見したら、審査期間をスケジュールに追加する。
リスクを計画に反映してはじめて、抽出は意味を持ちます。
リスクが顕在化していないか確認するチェックポイントを設ける
工程の終了時や開始時のことが多いですが、それ以外のタイミングのこともあります。
「SaaSの契約手続きは○月○日までに完了しているか確認」「Apple審査の申請は○月○日に仮申請予定」といった具合に。
工程開始終了以外のチェックポイントはマイルストーンとして明記する
スケジュール表に「SaaS契約確認」「Apple審査結果確認」といったマイルストーンを入れておくことで、確認漏れを防ぎます。
リスク一覧は作ったけれど、いつ確認するのか決まっていない──これでは形骸化してしまいます。
チェックポイントを明確にし、マイルストンとして組み込むことで、リスク管理は継続的に機能します。
接合点から始めるリスク管理
プロジェクト開始時のリスク抽出は、過去案件を参考にしたブレストだけでは形骸化します。
断片的で優先順位が不明確なリスク一覧は、結局誰も見なくなる。
必要なのは、会社間リスクとプロジェクト間リスク、つまり接合点に焦点を当てたリスク抽出です。
マスタースケジュールとシステム構成図から、ベンダー間、クライアント・ベンダー間、外部サービス、審査機関の接合点を見つけ出し、そこにリスクがないか確認する。
発見したリスクを計画に反映し、チェックポイントをマスタースケジュールに明記する。
これで、リスク管理は自然と機能します。
会社内リスクを完全に無視するわけではありません。
各ベンダーが自社内のリスクをコントロールすることが前提のうえで、全体PMOとしては接合点のリスクに注力するという優先順位をつけることが重要です。
リスクを無限に洗い出そうとするのではなく、接合点という明確な観点から実効性のあるリスクに絞り込む。
この姿勢こそが、プロジェクト開始時の確実なリスク管理を実現する鍵です。
