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