金融PMのステークホルダーマネジメント実務ガイド：合意形成の型

「山根さん、これ経営会議に出す資料なんですけど、あと1時間で作れますか」。勘定系刷新プロジェクトで一緒だったベンダー側のPMから、金曜の夕方にそう聞かれたことがあります。結局その日は資料の体裁より中身の3点だけ整理して、あとは口頭で補足する形で乗り切りました。

結論から言うと、金融PMの仕事の8割は技術力ではなくステークホルダーマネジメントで決まると僕は考えています。特に勘定系刷新やBaaS導入のような大型案件では、経営層・事業部門・システム部門・複数ベンダー、場合によっては監督官庁対応部署まで、利害関係者の数が一般的なシステム開発より一段多くなります。この記事では、僕が地方銀行の勘定系刷新プロジェクトで実際にやってきた会議体設計、RACIの作り方、現場とベンダーの板挟みをどう捌いたか、経営層報告で外せないポイントを、体感値と実例を交えてお伝えします。

0.（結論）合意形成は「会議体設計」と「見せ方」で8割決まる

先に僕の結論を書きます。金融PMのステークホルダーマネジメントは、突発的な調整力ではなく、事前に設計した会議体と報告フォーマットの仕組みでほぼ勝負が決まるというのが僕の実感です。炎上した案件を後から振り返ると、技術的な難易度よりも先に会議体そのものが機能不全を起こしているケースが大半でした。逆に言えば、会議体を整備し直すだけで火種の半分近くは事前に潰せる、というのがこれまで携わった複数の案件を通じた僕の体感値です。仕組み化さえできれば、調整の得意不得意という個人の資質に頼らずに合意形成の再現性が上がる、という点もこの結論を裏付けています。

1. なぜ金融PMにステークホルダーマネジメントが問われるのか

一般的なWeb開発のPMであれば、ステークホルダーは事業部門とエンジニアチームくらいに収まることが多いと思います。ところが勘定系刷新やBaaS・組込金融の案件になると、経営企画部門、リスク管理部門、コンプライアンス部門、複数のベンダー、場合によっては提携先の非金融事業会社まで関与してきます。僕が携わった地方銀行の勘定系刷新案件では、定例的にやり取りする部署だけで7つありました。一般的な業務システム刷新プロジェクトのステークホルダー数がおおむね3〜4部署程度であることを踏まえると、ほぼ倍近い規模感です。あくまで僕が経験した案件同士を比較した体感値であり、業界全体の統計ではありませんが、この利害関係者の多さこそが、金融PMに独特の調整スキルを要求する理由だと考えています。BaaS案件では、これに加えて提携するフィンテック企業側の担当者が加わるため、意思決定のスピード感が金融機関側とずれやすいという別の難しさも出てきます。フィンテック側は週次でどんどん仕様を決めたがる一方、金融機関側はリスク部門の稟議を経てからでないと動けない、というテンポの差が生じやすい点も、経験上つまずきやすいポイントです。

2. 会議体の三層設計：経営報告・進捗会議・エスカレーション

僕が実務で意識しているのは、会議体を「経営報告」「進捗会議」「エスカレーション」の三層に分けて設計することです。ここを混ぜてしまうと、経営会議で現場の細かい課題が延々と議論されたり、逆に現場の進捗会議で経営判断が必要な議題が放置されたりします。

体感値として、経営報告会議は週1回のペースで回している案件が多い印象です。一般的なシステム開発PMの経営報告が月1回程度であることが多いのに比べると、倍以上の頻度になります。これは金融機関の意思決定サイクルそのものが早いというより、経営層が規制対応や資金計画への影響を常に気にしているため、報告の鮮度を求められるからだと僕は理解しています。また、要件定義期は進捗会議を週2回、テスト・移行リハーサル期になると週3回に増やすなど、フェーズに応じて頻度を変えることも意識しています。エスカレーション会議は本来「随時招集」ですが、僕の経験では月に2〜3回は発生するのが普通で、これをゼロにしようとするより「起きるもの」として枠取りしておく方が現実的だと感じています。

3. RACIと合意形成ドキュメントの実務

会議体を整えても、誰が何を決める権限を持つのかが曖昧なままだと、結局同じ議題を何度も蒸し返すことになります。僕は要件定義の初期段階で必ずRACI表を作り、経営報告会議の場で一度承認を取るようにしています。

• Responsible（実行責任）：実際にタスクを進める担当者・ベンダー
• Accountable（説明責任）：最終的な意思決定権者。金融PMの案件では部門長クラスであることが多い
• Consulted（協議先）：判断前に意見を聞くべきリスク管理部門やコンプライアンス部門
• Informed（報告先）：決定事項を事後共有すればよい関係者

ここで大事なのは、RACI表を作って終わりにせず、議事録のフォーマットにRACIの項目を組み込むことです。例えば仕様変更を承認する場面では、議事録に「この決定のAccountableは業務部長」と明記しておく運用にしています。こうしておくと、後から「言った・言わない」の水掛け論になりにくくなります。僕の体感では、議事録にRACIを明記する運用に変えてから、同じ議題の蒸し返しは体感で半分程度に減りました。RACI表自体は特別なツールを使わず、Excelやスプレッドシートで十分で、要件定義書の付録として更新し続けるだけで機能します。RACI表の作成自体は初回でも半日あれば骨子は作れますが、実際に機能させるには関係部門に一つひとつ説明して回る時間が別途1〜2週間ほど必要になる、という点は見積もっておいた方がよいと思います。

4. 現場部門とベンダーの板挟みをどう捌くか

ここからは僕の失敗談です。ある勘定系刷新プロジェクトで、現場の業務部門が「この機能は絶対に譲れない」と主張し、開発ベンダーは「スケジュール上どうしても入らない」と主張する場面がありました。僕は当初、双方の言い分を個別に聞いて板挟みのまま調整しようとしたのですが、これがうまくいきませんでした。双方とも「相手が譲歩すべきだ」という前提で話していたため、個別調整では合意点が見えなかったのです。1週間ほど個別ヒアリングを重ねても状況は膠着したままでした。

最終的にうまくいったのは、両者を同じ場に呼び、機能の優先度を業務影響度とリスクの2軸で一緒に採点し直すというやり方でした。感情論ではなく採点という共通のものさしを置いたことで、「今回は見送るがフェーズ2で必ず対応する」という着地に持ち込めました。この一件のあと、僕は優先度採点のフォーマットをプロジェクト標準として残し、以降の類似の対立ではこのフォーマットを使うルールに変えました。板挟みになったときは、個別調整より先に双方が納得できる評価軸を用意することを優先する、というのが今の僕のやり方です。個別ヒアリングに時間をかけすぎるくらいなら、早い段階で合同の採点会に切り替える方が、結果として調整期間を短く済ませられる、というのがこの案件から得た教訓です。

5. 経営層報告で外せない3つのポイントとよくある失敗

経営層への報告は、細かい進捗より意思決定に直結する情報を優先すべきだというのが僕の考えです。具体的には次の3点を必ず盛り込むようにしています。

1つ目は、予算とスケジュールに対する現在の乖離幅を数字で示すことです。「順調です」だけでは経営層は判断できません。2つ目は、放置すると重大リスクに発展しうる課題を、対応期限とセットで示すことです。3つ目は、経営判断が必要な論点を明確に切り分けて提示することです。僕の体感では、この3点を毎回同じフォーマットで示すようにしてから、経営会議での質疑が具体的になり、会議時間そのものも短縮できた案件がありました。

逆に、この3点を曖昧にしたまま報告を続けた案件では、後になって経営層から「聞いていなかった」という指摘が入り、リカバリーに余計な時間がかかった経験もあります。よくある失敗パターンとしては、進捗報告のスライド枚数を増やして安心感を演出しようとすることです。枚数が多いほど論点がぼやけ、経営層が本当に見るべき乖離幅とリスクが埋もれてしまいます。対処法としては、報告フォーマットをあえて1ページに固定し、詳細は別紙に回すというルールを最初から決めておくことをおすすめします。

(結論)

皆さんいかがでしたでしょうか。金融PMのステークホルダーマネジメントは、その場の調整力に頼るのではなく、会議体設計・RACI・報告フォーマットという仕組みで支えるものだと僕は考えています。今日からできる一歩としては、まず今関わっているプロジェクトの会議体を「経営報告」「進捗」「エスカレーション」の3つに整理し直してみることをおすすめします。それだけでも、次の板挟みの場面で動きやすくなるはずです。では今日もがんばりましょう。