金融PMのマルチベンダー管理｜要件定義からリリースまでの実務

「A社は自分たちの範囲だと言ってるんですが、B社は違うって言ってて、結局どっちがこのバグ直すんですか」——これは僕が去年、ある地銀の周辺システム刷新案件に途中から入ったときに、現場のリーダーから受けた質問です。答えは「どちらでもない可能性がある」でした。要件定義の時点で責任分界点が曖昧になっていて、誰の担当かを決める工程自体が抜けていたのです。

結論から書きます。金融PMの実務でキャリアの評価が分かれる分岐点は、ベンダーが1社だけの整った案件をこなせるかどうかではなく、複数ベンダーが絡み合った案件で地図を描けるかどうかだと僕は考えています。今回はマルチベンダー管理という、地味だけれど評価に直結するテーマを、要件定義からリリースまでの流れとケース比較で整理してみます。

1. マルチベンダー管理が金融PMの評価を左右する理由

金融機関のシステム刷新やBaaS連携の案件では、コアシステムのベンダー、周辺システムのベンダー、インフラのベンダー、テスト専門会社など、複数の会社が同時に稼働することが珍しくありません。僕がこの5年ほどで関わった金融系の刷新・連携案件は20件強ありますが、そのうち体感で6割程度は3社以上のベンダーが同時並行で動いている案件でした。残りの2社以下で回っている案件と比べると、要件定義フェーズの工数は1.5倍程度に膨らむ印象を持っています。これは単純に打ち合わせの回数が増えるからではなく、各社が自社の契約範囲を守ろうとする力学が働くため、仕様の隙間を誰が埋めるかという調整に時間がかかるからです。

この調整力は、実は面接でも語りやすい実績になります。単独ベンダーの案件を無事に終えた話より、「A社とB社の間で仕様の解釈がずれていたのを、共通の受け渡し基準を作って解消した」というような具体的な調整の経験のほうが、評価担当者には刺さりやすいと僕は感じています。金融PMの求人票には「ベンダーコントロール経験」という一文がさらりと書かれていることが多いのですが、その一文の裏にはこうした地味な調整の積み重ねがあります。

2. ベンダー体制の3パターンと得意領域の違い

マルチベンダー案件と一口に言っても、体制のパターンによってPMがやるべきことは変わります。僕は現場感覚として、大きく3つのパターンに分けて捉えています。1つ目は元請け一括型で、大手ベンダーが全体を受けて下請けを使う形です。この場合、発注側のPMは元請けとの窓口業務が中心になり、下請けとの直接調整は限られます。2つ目は機能別分割型で、コア・周辺・インフラなどを機能単位で別々のベンダーに発注する形です。この場合、PMが各社の橋渡しを担う場面が最も多くなります。3つ目は内製・複数ベンダー混在型で、発注側の内製チームと複数のベンダーが並走する形です。この場合はPMが実質的に技術面の意思決定にも関わることになります。

この分類はあくまで僕の整理した目安であって、実際の案件では途中でパターンが変わることもあります。特に、当初は元請け一括型として発注していたのに、追加要件のたびに専門ベンダーを直接契約してしまい、気づけば機能別分割型に近い状態になっている、というケースを何度か見てきました。体制のパターンが変わったこと自体を発注側の関係者が認識していないと、責任分界の見直しが後手に回りやすいので、僕はプロジェクトの節目ごとに「今、実質的にどの体制になっているか」を棚卸しするようにしています。

3. 要件定義フェーズで責任分界点を明文化する

マルチベンダー案件でPMが最初にやるべき仕事は、責任分界点の明文化です。具体的には、各ベンダーの担当範囲、インターフェースの仕様、成果物の受け渡し方法をRACI表などの形式で整理し、関係者全員が同じ紙を見られる状態を作ることです。これを後回しにした案件では、進行中フェーズで「どちらの担当か」という押し付け合いが起きやすく、僕の観測範囲ではこうした責任分界の未整理がリリース遅延の主因の半数近くを占めていました。

先に挙げた地銀の案件がまさにその典型で、A社とB社のどちらが直すべきバグかが決まっていなかったのは、要件定義の段階で「このAPIのレスポンス仕様はどちらが担保するか」という項目が抜けていたためでした。僕が最初にやったのは、既存の要件定義書を洗い直して、責任の記載がない項目をリストアップすることでした。地味な作業ですが、これをやらないと後工程でどれだけ会議を重ねても解決しません。責任分界点は「誰が」だけでなく「どのタイミングで」まで書くことが大事だと僕は考えています。設計変更が発生したときに誰が影響範囲を確認するのか、という点まで決めておくと、後々の押し付け合いをかなり減らせます。

4. 進行中フェーズのリスクと調整の実務

要件定義が終わって開発が進み始めると、今度は情報の非対称という別のリスクが顔を出します。各ベンダーは基本的に自社に有利な情報だけを出す傾向があり、進捗報告も「順調です」という言葉の裏で細かい懸念が隠れていることが少なくありません。僕が意識しているのは、個社対応の定例会議だけに頼らず、全ベンダーが参加する場を週次で必ず設けることです。ここで「持ち帰り事項」を一元管理する表を運用し、誰が何をいつまでに確認するかを可視化します。この運用を徹底した案件では、伝達漏れによる手戻りを目安で3割程度減らせた体感があります。

また、ベンダー間の技術的な依存関係が複雑な案件では、PMが技術の詳細まで理解している必要はありませんが、「このベンダーの遅れが他社にどう影響するか」という因果関係だけは押さえておく必要があります。僕はこれを紙芝居のように図で描いて共有することが多いです。矢印一本引くだけで、口頭で説明するより誤解が減ります。人間関係の比喩で言えば、マルチベンダー管理は複数の取引先を持つ商店街の世話役のようなもので、どの店の売上も伸ばしたいけれど、通りの混雑や工事のタイミングを調整する役目を誰かが担わないと、街全体が渋滞してしまうのと似ています。

5. ケース比較：3社体制と6社体制で何が変わるか

体制の規模によって、PMが投じる時間の質が変わることも書いておきます。僕が過去に担当した案件のうち、比較として印象に残っているのが、周辺システム刷新でベンダー3社が絡んだ案件と、決済連携でベンダーが6社近く絡んだ案件です。3社体制のときは、週次の全体定例を1回、個社定例を各社1回の合計で回せていて、PMの調整業務は稼働全体の3割程度だった記憶があります。責任分界点の表もA4一枚で収まる規模で、更新も比較的軽い作業でした。

一方の6社近い体制の案件では、全体定例だけでは情報が拾いきれず、個社定例に加えて2社間の直接調整会をPMが仲介して設定する必要が出てきました。調整業務が稼働の5割を超える時期もあり、責任分界点の表もA4一枚では収まらず、機能別に分割して管理せざるを得ませんでした。この2つを比べて僕が学んだのは、ベンダーの数が単純に倍になったからといって調整の手間も倍になるわけではなく、むしろ組み合わせの数（何社と何社の間で調整が必要か）が効いてくるという点です。3社なら組み合わせは最大3通りですが、6社になると15通り近くまで増えます。体制を組む発注側の担当者と話すときは、社数そのものより「何通りの調整が発生しそうか」を事前に見積もっておくと、必要な調整の場をどれだけ設計すべきかの目安になります。

6. 今日からできる実務アクション（所要時間つき）

ここまで理屈を述べてきましたが、明日からの現場で使える具体的な手順も残しておきます。まず、既存の要件定義書または契約書を見直し、各ベンダーの担当範囲が明記されているかを確認してください。これは慣れていれば半日程度でひと通りチェックできる作業です。曖昧な箇所があれば、次回の定例までにRACI表の形で埋める草案を作ります。草案作成自体は1〜2時間で骨子は組めますが、各社への確認と反映まで含めると1週間ほど見ておくと現実的です。

1. 要件定義書・契約書から責任範囲の記載漏れをリストアップする（目安半日）
2. RACI表の草案を作り、次回定例で各ベンダーに確認を取る（骨子作成1〜2時間、確認反映まで1週間程度）
3. 週次の持ち帰り事項管理表を導入し、担当と期限を明記する（初回設定30分、以降は運用に組み込むだけ）
4. ベンダー間の依存関係を図に描き、影響範囲を共有する（初版作成2〜3時間）
5. エスカレーションルート（誰にいつ上げるか）を事前に決めておく（合意形成に1回の定例分）

この5つは特別なツールを必要とせず、Excelやスプレッドシートでも十分に運用できます。大事なのは形式より、関係者全員が同じ情報を見ている状態を作ることです。ここでよくある失敗も併せて触れておきます。一つは、PM自身が全ての技術的な判断を抱え込もうとしてしまうことです。善意から来る行動なのですが、結果的に各ベンダーの専門性を活かせず、判断のボトルネックがPM一人に集中してしまいます。技術的な判断は各ベンダーの技術リードに任せ、PMは「誰がいつまでに判断するか」というプロセスの管理に専念する方が、案件全体としては早く進む印象があります。もう一つの失敗は、責任分界点を最初に決めたまま更新しないことです。要件定義の時点では正しかった分界点も、開発が進むにつれて仕様変更や追加要件によって実態とずれていくことがあります。僕は月次または大きな仕様変更のタイミングで、責任分界点の記載を見直す機会を意図的に設けるようにしています。これを怠ると、リリース直前になって「この機能はどちらが最終確認するのか」という揉め事が再燃することがあり、僕自身も一度その渦中に入った経験から、定期的な見直しの重要性を痛感しました。

7. (結論)

マルチベンダー管理は、金融PMの求人票の一文には収まりきらないほど、実務としては地味で手間のかかる仕事です。ただ、責任分界点を明文化し、情報の非対称を減らす仕組みを作るという2つを丁寧に積み上げるだけで、案件全体の進みやすさはかなり変わると僕は考えています。ベンダーの社数そのものより、組み合わせの数と更新の頻度を意識するだけでも、調整の見通しはずいぶん立てやすくなるはずです。派手な成果には見えにくいかもしれませんが、こうした調整の経験こそ、次の案件や転職の面接で語れる具体的な実績になっていくはずです。

皆さんいかがでしたでしょうか。マルチベンダーの調整に頭を悩ませている方も、これから複数ベンダー案件を担当する予定の方も、まずは責任分界点の紙一枚から始めてみてください。では今日もがんばりましょう。