保険業界（生保・損保）のPMO支援とは？基幹刷新・業務DXを成功させる体制づくり

基幹システムの刷新、支払査定のDX、相次ぐ制度改正への対応——保険会社のシステム部門や経営企画の方がPMO支援を探し始めるのは、たいていこの3つのどれかが動き出したタイミングです。先に結論を言うと、保険業界のプロジェクトは、一般的なPMOのスキルセットだけでは回りません。数十年分の既契約、当局の監督下にある規制対応、複数ベンダーが入り乱れる体制。この三重の制約が、他業界にはない難しさを生むからです。僕は金融系SIerのシンプレクスで受注側のPMを4年間務め、独立後は発注側の立場でもプロジェクトに関わってきました。この記事では、その両側の経験を踏まえて、生保・損保のプロジェクト特性、PMOに求められる知見、典型的な失敗パターン、体制づくり、そして支援会社の選び方までを発注側の視点で整理します。

保険会社のシステム開発・DXには、他業界と質的に違う制約が3つあります。銀行・証券を含む金融業界全般のPMOと重なる部分もありますが、本記事では生保・損保に絞って掘り下げます。

数十年分の既契約を背負ったまま走る基幹刷新

生命保険の契約は、30年、40年と続きます。つまり生保の基幹システムは、過去に販売したすべての商品の仕様を——販売停止になった商品も、合併前の会社の商品も——現役のデータとして抱えている。基幹刷新とは、更地に新しい建物を建てる作業ではなく、住人が暮らしたままの家を家財ごと引っ越しさせる作業に近いんです。

しかも、旧商品の仕様書が完全な形で残っていることは稀で、当時の設計を知る担当者はすでに退職しているケースが少なくない。損保も事情は似ていて、商品改定の頻度が高いぶん、料率や特約のバリエーションが膨大に積み上がっています。ERP導入をはじめとする基幹システム刷新一般の論点にはここでは踏み込みませんが、保険の刷新が特に重いのは、過去に販売した全商品の既契約を切り捨てられない点にあります。移行データの調査と検証だけで一つのプロジェクトが成立する規模になる、と最初から見込んでおいたほうがいい。

査定業務DXは「ツール導入」では完結しない

支払査定・引受査定のDXは、生保・損保どちらでもここ数年の主要テーマです。AI-OCRによる帳票の読み取り、自動査定のルールエンジン、不正請求の検知。道具は揃ってきました。ただ、査定業務は例外処理の連続です。約款の解釈が分かれるケース、医的な判断が必要なケース、慎重に見るべき請求パターン。「どの案件を自動で通し、どの案件を人に回すのか」という業務設計を先に固めないままツールを入れると、結局は全件を人が見直すことになり、効果が出ません。ここで問われるのは技術選定の巧拙ではなく、業務設計の解像度です。

規制対応という「動かせない納期」

制度改正や監督指針への対応は、施行日が先に決まっています。通常のプロジェクトなら、遅延したときに「納期を延ばす」「スコープを削る」「リソースを足す」の三択を組み合わせて調整できますが、規制対応では納期という選択肢が最初から存在しない。加えて、システム障害が起きれば当局への報告が必要になり、契約者への影響やレピュテーションにも直結します。品質と期日の両方が固定された、逃げ場の少ない構造。だからこそ、問題が起きてから対処するのではなく、起きる前に潰しておく「前始末」の価値が、他業界より一段高くなります。

進捗・課題・品質管理や会議運営といった一般的なPMOスキルは、当然の前提です。この前提となるPMOの基本的な機能・役割の整理は入門記事にまとめているので、そもそもPMOとは何かから押さえたい方はそちらを先にどうぞ。そのうえで、保険業界のプロジェクトでは次の4つが揃っているかどうかで支援の質が大きく変わります。

①について補足します。生保の契約管理・保全・査定と、損保の商品改定・代理店システム・損害サービスは、同じ「保険」という看板でもまったく別の業務体系です。支援者の「金融系の経験があります」という説明だけで安心してはいけません。生保か損保か、そのなかのどの業務領域か。発注側はそこまで確認する必要があります。

③はプロジェクトの構造の問題です。保険の基幹刷新は、複数のSIerとパッケージベンダーの混成体制になるのが普通です。そして問題は、各社の作業範囲の境界線上で起きます。A社とB社の間に落ちた課題を、どちらが拾うのか。押し付け合いを裁けるのは、発注側の権限を背負って動けるPMOだけです。

④は地味ですが効きます。商品部門は商品性で語り、数理部門はリスクで語り、システム部門は実現可能性で語る。同じ論点でも、部門ごとに見ている景色が違うのが保険会社です。誰かが間に立って翻訳しないと、合意したはずの仕様が後工程で割れます。

プロジェクトの失敗原因は発注側にも受注側にもある——これが僕の一貫した考えです。保険業界の案件で繰り返し起きる失敗は、だいたい次の4つに集約されます。

パターン1：「現行どおり」という名の要件未定義

基幹刷新の要件定義で最も危険な言葉は「現行どおりでお願いします」です。現行の仕様を正確に説明できる人が社内にいないのに現行踏襲と書いた瞬間、要件定義は「終わったことになっている」だけの状態になる。そのズレはテスト工程や移行リハーサルで一気に噴き出し、スケジュール遅延として表面化します。ただ、遅延は症状にすぎません。真因は、スコープの定義が実態とずれていたこと。症状のほうを叩いても解決しないんです。

パターン2：データ移行の後回し

移行を「最後の工程」として扱い、設計・開発が佳境に入ってから検討を始めるパターンです。保険の移行は既契約の全商品仕様と向き合う作業なので、後半に回した時点でほぼ挽回できません。移行方針の策定、データクレンジング、旧商品の仕様調査は、プロジェクトの初期から本体と並走させる。そういう計画にしておく必要があります。

パターン3：業務有識者の枯渇

旧商品や査定実務を語れるキーパーソンは、たいてい現行業務との兼務です。プロジェクトが進むほど各ベンダーからの質問がその数人に集中し、回答待ちの行列ができてボトルネック化する。これは受注側ではなく、発注側の計画責任です。有識者の工数確保と質問窓口の一元化は、体制図を描く段階で織り込んでおくべき設計事項です。

パターン4：制度対応・商品改定との並走でスコープが動き続ける

刷新プロジェクトが走っている間も、制度改正と商品改定は止まってくれません。走行中の変更を「例外」として扱うと、計画は例外のたびに崩れます。最初から「年に何回、どの規模の割り込みが入るか」を前提として計画に組み込んでおくのが現実的です。

この4つに共通するのは、放置した場合の事後対処コストが跳ね上がることです。バグ一つとっても、事前にケアするコストに比べて事後の対処は3〜5倍かかる。移行や規制対応のように後戻りできない工程を抱える保険のプロジェクトでは、この差はさらに開きます。開発プロジェクトの7割は上流で決まるというのが僕の持論ですが、保険業界ほどそれが当てはまる領域はないと思っています。

システム開発の成功率は3割と言われます。僕は「3億円以下のプロジェクトなら、計画を立て切れば大コケしない」と言い続けてきましたが、保険の基幹刷新はその規模を優に超えることが多い。となると、計画を立て切るだけでは足りず、計画とのズレを早く見つけて補正し続ける構造が要ります。それを支えるのが体制設計であり、PMOです。発注側が握るべき設計は3つあります。

① 意思決定の場を設計する

ステアリングコミッティと分科会を形だけ置いても、プロジェクトは進みません。「誰が・何を・いつまでに決めるのか」の対応表を先に作り、判断が必要になりそうな事項を洗い出しておく。会議が報告の読み上げで終わっているなら、それは決める場が設計されていないサインです。意思決定のルートは体制図とセットで定義してください。

② 業務有識者のアサインを「計画」として扱う

前章のとおり、有識者は高確率でボトルネックになります。だから「協力してもらう」ではなく「計画に載せる」。兼務率を数字で決めて部門長と合意し、質問対応の窓口とルールを定める。ここを曖昧にしたまま走り出したプロジェクトは、中盤で必ず詰まります。

③ PMOへの期待値を最初に言語化する

外部PMOを入れたのに議事録係で終わる。この不満の原因の多くは発注側が「何を任せ、どの場面で判断を求めるか」を定義していないことにあります。進捗の集計だけを頼みたいのか。ベンダー間の課題を裁く権限まで持たせるのか。経営報告の作成まで任せるのか。期待値が曖昧なPMOは、当たり障りのない資料整理に落ち着いていきます。着任前に、期待する成果物と判断を求める場面を言語化して渡すこと。これは支援会社の実力以前の、発注側の設計の問題です。なお、こうした体制づくりを外部に頼む場合に何をどこまで任せられるのかは、PMO支援の内容・提供形態・進め方を解説した別記事で詳しく整理しています。

支援会社の網羅的な比較はここでは行いません（それだけで別のテーマになります）。業界を問わず使えるPMO支援会社の共通の見極め基準は別記事にまとめているので、この章では生保・損保の案件に絞って、業界経験の確認と併せて使う基準だけを挙げます。

支援会社はおおむね3タイプに分かれる

どのタイプが正解かは案件次第です。ただし共通して言えることが一つあります。PMO支援の品質は会社の看板ではなく、着任する個人で決まるということ。タイプの選択と、来る人の見極めは必ずセットで行ってください。

商談で確認したいチェックリスト

• 生保・損保のどちらの経験か。契約管理・査定・代理店など、どの業務領域か
• 基幹刷新なら、どの工程（構想・要件定義・移行・テスト）を担当したのか
• マルチベンダー統制の経験があるか。実際に使った管理の型を見せてもらえるか
• 施行日が固定された規制対応案件を、どう管理したか具体的に語れるか
• 提案に来た人と、実際に着任する人は同じか
• 「業務有識者の負荷をどう設計しますか」と聞いて、具体策が返ってくるか

最後の質問は、僕がおすすめする見極めの質問です。保険案件の急所——有識者のボトルネック——を理解している支援者なら、窓口の一元化や質問管理の仕組みを即答できるはず。一般論しか返ってこなければ、保険業界での経験は浅いと判断していいと思います。

• 生保・損保のプロジェクトには「数十年分の既契約」「規制の動かせない納期」「マルチベンダー体制」という三重の制約がある
• PMOには一般的な管理スキルに加えて、保険業務の解像度・規制への感度・ベンダー統制力・部門間の翻訳力が求められる
• 典型的な失敗は「現行どおり」という要件未定義、移行の後回し、有識者の枯渇。いずれも前始末なら事後対処の3〜5分の1のコストで防げる
• 体制づくりの要は、意思決定の設計・有識者アサインの計画化・PMOへの期待値の言語化。この3つは発注側にしかできない仕事
• 支援会社はタイプの整理と、着任者個人の見極めをセットで行う

基幹刷新も査定業務のDXも、保険会社にとっては10年に一度あるかないかの経験です。社内に経験者がいないのは当たり前で、恥じることでは全くありません。足りない経験は外から借りればいい。ただし丸投げにはせず、この記事で挙げた「発注側が握るべき設計」だけは手放さないこと。それが、外部PMOをコストではなく戦力に変える条件だと僕は思います。

※本記事は一般的な情報提供を目的としたものであり、法的助言ではありません。

---

生保・損保のプロジェクト体制、第三者の目で点検しませんか

「基幹刷新のベンダー提案が妥当かどうか、社内で判断できる人がいない」「査定DXがPoCで止まったまま進まない」「PMOを入れたのに、議事録の作成で手一杯になっている」——保険業界のプロジェクトを検討・推進している方から、よく伺う悩みです。

クリエイティブテックスタジオでは、受注側・発注側の両方を経験したメンバーが、体制づくりの壁打ちから実務のPMO支援まで対応しています。僕自身、受注側のPM時代に担当プロジェクトのQCD未達ゼロを続けてきた品質管理の型を、保険業界特有の制約に合わせて持ち込みます。お話を伺った結果、他社のほうが適していると判断すれば、その旨も正直にお伝えします。

体制図を描く前段階でのセカンドオピニオンも歓迎です。まずは無料相談から現状をお聞かせください。支援内容の詳細はPMO支援サービスにまとめています。