【内製開発Summit 2025】内製化組織に求められるDOUBLE BRIDGE MODEL MANAGEMENT
2025年2月27日、ファインディ株式会社が主催するイベント「内製開発Summit 2025」が、野村コンファレンスプラザ日本橋にて開催されました。
本記事では、ネオファースト生命保険株式会社代表取締役社長の上原高志さんによるセッション「内製化組織に求められるDOUBLE BRIDGE MODEL MANAGEMENT」の内容をお届けします。
開発内製化におけるテクノロジーの理解不足や、事業部意見優先の社内風土を克服するためのマネジメント「Double Bridge Model」についてお話いただきました。
■プロフィール
上原 高志
ネオファースト生命保険株式会社 代表取締役社長
1995年4月株式会社三和銀行（現 三菱ＵＦＪ銀行)入行、2016年1月同行イノベーション・ラボ所長、2017年10月Japan Digital Design株式会社CEO、2021年4月SOMPOホールディングス株式会社デジタル戦略部チーフエバンジェリスト、2021年7月SOMPO Light Vortex Executive Vice President、2023年4月SOMPOホールディングス株式会社 投資戦略室 特命部長、2024年4月ネオファースト生命保険株式会社代表取締役社長就任。
金融DX最前線を走り続けた経営者の視点
本日は限られた時間ではございますが、「内製化組織に求められるDOUBLE BRIDGE MODEL MANAGEMENT」というテーマでお話しさせていただきます。なお、この名称は私が独自に作ったものですので、何らかの著作物に基づくものではありません。
今日のアジェンダは大きく3つございます。一つ目が、エンジニア内製化の高まりとその背景。二つ目が、内製化における課題。そして最後に、私たちの取り組み事例のご紹介をさせていただきます。
私は三菱UFJ銀行を含め3社での経験があり、多くの壁にぶつかりながら内製化に取り組んできました。おそらく皆様も共感いただける『あるある』をお伝えできればと思います。
まず簡単な自己紹介をさせていただきます。私は工学部出身ですが、専攻は都市設計でした。エンジニアとしては中学2年生がピークで、MSXや98シリーズの時代にアセンブラなどを触っていた程度です。現在は時々Udemyなどで新しい言語を見て勉強している状況です。
社会人としては銀行に入社し、調査部や企画部門、後半は法人部門の企画や新規事業開発に携わりました。その後デジタル分野でスタートアップ投資を担当し、Coinbaseやエクサウィザーズなどへの投資を手掛けました。当時は『銀行が存続するには新しい産業の創出が必要だ』という考えのもと、スタートアップ支援に取り組んでいました。
2016年にフィンテックブームが到来し、多くの人がこの分野に参入する中、私は投資支援側の立場でしたが、銀行からの指示でプレイヤー側に転向することになりました。その後、Japan Digital Designを立ち上げ、様々な取り組みを行いました。
その後、ご縁があって損保分野に移り、「ライトボルテックス」という会社の立ち上げに参加しました。スマートフォームの開発や特許取得などを進めていましたが、業界を揺るがす事件が発生し、新規事業どころではない状況になりました。
そして昨年4月から、デジタルだけでなく営業やオペレーションを含む総合的な経営に挑戦したいという思いから、ネオファースト生命の社長に就任いたしました。
続いて、会社の紹介です。ネオファースト生命は10年前に設立された生命保険会社です。元々はDIY生命という代理店向けの小規模な会社で、当初は損保が主な投資元で一部第一生命グループも出資していました。その後、損保がひまわり生命と連携することになったため、2015年に社名をネオファースト生命に変更し、現在に至っています。
主な販売チャネルは代理店（保険の窓口など）や銀行窓販（みずほ銀行、福岡銀行など）です。昨年12月には契約件数100万件を突破し、『第2創業』として今後3年で更に100万件の増加を目指して新体制で取り組んでいます。
「デジタルで何かやれ」からスタートした2016年の内製化黎明期
では本題に入らせていただきます。まず、エンジニアの内製化の機運についてお話しします。
2016年、当時の頭取から突然『デジタルで何かやれ』と指示を受けたことが始まりでした。通常、新規事業を始める際には明確なミッションや計画があるものですが、この時は何もないところからのスタートでした。小規模なチームで『何をやるのか』というところから議論を始め、数ヶ月かけて様々な取り組みを模索しました。
内製化の背景にあった経営課題としては、国内市場の縮小（人口減少・高齢化による消費額減少）、市場の飽和と限界感、伝統的企業特有の『祖業を捨てられない』という制約、新たな顧客セグメントや付随領域の開拓ニーズなどがありました。
日本企業は段階的な改善（インクリメンタル）が得意ですが、急激な変化に弱いという危機感から、破壊的イノベーションや変革が求められていました。こうした経営者の思考構造から『内製化』や『出島』といった発想が生まれていきます。これは、メーカーも金融機関も同様の傾向が見られました。
そうして立ち上げた新組織で、NTTグループや日立など様々な企業と連携してPOC（概念実証）を展開しました。ブロックチェーンを活用した自動車アクセス管理システム、訪日中国人向けアプリ開発（テンセントとの協業）、睡眠のSaaS化（家電のサブスクリプションモデル）、多言語メニューの開発など、多くのPOCに取り組みました。
結果として、すべてのPOCは『成功』しましたが、実際の『事業化』には至りませんでした。約1年間の活動を通じて、なぜ事業化に至らなかったのか、その課題が明らかになりました。
成功したPOCが事業化されない「3つの要因」
一つ目の課題は、デザイン思考の実践的理解の不足でした。当時は見よう見まねで進めており、真の意味での体験設計や効果的なプロセスの構築ができる経験者がいなかったため、ビジネスとして成立させるレベルまで到達できませんでした。
二つ目の課題が、プロトタイプ内製化力の強化です。典型的なパターンとして、業務委託でPOCを進めていると、プロジェクト開始から約1ヶ月経過した頃、要件定義を進める中で『これは間違っている』と気づくことが多々ありました。しかし、予算確保済みの業務委託では、方向修正や中止が難しく、結果として時間の無駄や使い物にならない成果物、柔軟な対応ができないなどの問題が生じました。これらの経験から、専属のエンジニアの必要性や、初期段階からセキュリティを検討する重要性を痛感しました。
三つ目の課題は、優秀なエンジニアと協働するためには、柔軟な働き方の提供が必要だということでした。多くのエンジニアは独自アプリ開発などの兼業を行っていることも珍しくなく、そうした人材とどう付き合うかという制度設計が必要になりました。しかし、銀行という組織の中でそのような柔軟な制度を構築することは極めて困難でした。
この三つの課題に対して、従来型の業務委託からグループ内システム子会社との協業、各ベンダーからの出向受け入れ、嘱託として1年単位での採用、外部に会社を設立するなど様々なアプローチを検討しました。
結局、『なぜ内製化したいのか』という根本に立ち返った結果、外部に新会社を設立する選択肢を選びました。こうして『Japan Digital Design』が誕生することになりました。
二つの開発アプローチの成果と限界
Japan Digital Design（JDD）は0から始めて約100人の組織になり、そのうち銀行員は10〜15人程度という『動物園のような』多様な環境でした。定例会議の時間設定だけでも1週間かかるという状況で、異なる文化を持つメンバー間の調整に多くの時間が費やされました。
DXを進めると様々な課題に直面しました。私たちは大きく分けて二つのパターンを試しました。一つは事業部門がオーナーシップを持ち、デジタル部隊がサポートする形態。もう一つはデジタル部隊が主導して新事業を創出する形態です。
『事業部門主体＋デジタル部隊サポート』の形態では、事業部門のシステム知識不足（『お金さえ取ってくれば作れるもの』という認識）、製造プロセスへの事業部門の不参加、製販不一致、顧客ニーズやMVPの見極め不足、相互の責任転嫁などが課題として生じました。
一方で、『デジタル部隊主導での新事業開発』の形態では、美しい提案資料とアーキテクチャは作れるが販売力が不足、『売る』という行為へのコミットメント不足、販売の切迫感やガッツの欠如などが課題になりました。
最終的に、『2番煎じでも売れば売れる、最先端でも売らなければ売れない』というビジネスの基本原則を実感しました。PayPayの例のように、初期は不完全でもユーザーフィードバックを取り入れながら改善していくプロセスの重要性を認識しました。
「ダブルブリッジモデル」誕生の背景
大企業が外部委託や内製化でデジタル人材を取り込む際に直面する『コミュニケーションケーパビリティ』も問題の一つでした。
制作を元々外部にいた人間が行うことで、事業部門側の当事者意識の欠如、オーナーシップ不足、目的を無視したルール優先主義、制作者へのリスペクト不足などが問題として起こりえます。また、内製化でよくある『出島型組織』が進みすぎると、本体との一体感や運命共同体意識が薄れ、両者の溝が深まるという反作用が生じます。
さらに、共通言語の不在も問題でした。そもそも専門用語の言葉の意味がわからないので、『アジャイル』などの用語の意味や実践方法の理解が不足し、要件定義の範囲や必要なデータに関する認識の共有も全くできませんでした。
こうした課題を解決するためには、内製化部隊が必要だと私は考えました。しかし、100%の内製化は現実的ではありませんでした。エンジニアリソースと事業ニーズの需給バランスは常に変動していて、ピッタリ重なり続けることはなかなかありません。
エンジニアを雇いすぎると暇な人材が発生してしまうし、少なすぎると実現できない企画が増加してしまいます。スクラム開発でも、チケットサイズと人員のバランスを完全に保つことは困難です。こうした状況を考えると、大企業における内製化の理想的な割合は最大でも50:50程度。現実的には20:80から30:70の割合が目標になります。
この程度の内製化があれば、アーキテクチャや開発方針を自社でコントロール可能になり、内外をブリッジする人材が育成されます。共通言語や理解を持った人材が社内に存在することで、外部リソースの活用効率が向上し、結果として開発レベルの向上とコスト削減の両立が可能になります。このような「ダブルブリッジモデル」により、内製化と外部連携の最適なバランスを実現することが重要です。
2030年時価総額3000億円へ。ネオファースト生命の成長戦略
では次に、ネオファースト生命での現在の取り組みについてご紹介します。
ネオファースト生命は2030年に向けて、企業価値と年間契約数（トランザクション）を2倍に、1件あたりの契約コストを半分にすることを目標として掲げています。これらの目標が達成されれば、エンベデッドバリュー（保険会社の価値指標）に基づいた時価総額は約3000億円となり、『ユニコーン企業』の仲間入りを果たすことになります。このビジョンの核心は、トランザクション増加とコスト削減の両立にあります。
社長就任後、綿密な計画を立てて進めていましたが、第一生命ホールディングスのCIOであるスティーブン・バーナム氏から『3ヶ月後にはあなたが頭を抱えている姿が見える』と予言されました。経営、営業、オペレーション変革、予算折衝など多くの責任を負う社長一人でデジタル・システム改革を進めることの限界を指摘されたのです。
その助言を受け、新たなCIOとしてラジャン・ナンダ氏を招聘しました。わずか数十分の面談で意気投合し、採用が決定しました。興味深いことに、ナンダ氏は当初のオファーよりも高い条件で入社することになりましたが、後に『最初の低めのオファーでも入社するつもりだった』と明かしています。
ナンダ氏から入社前に5枚のワードファイルが送られてきて、必要な資料リストを提示されました。その内容は3分の1がシステム関連、3分の2が商品戦略やオペレーション、営業戦略など非システム分野でした。
これを受けて、資料フォーマットを整理し、各部門に資料準備を指示しました。全社的な情報収集が始まりました。この過程で膨大な資料が集まり、ナンダ氏は入社後わずか2週間でこれらをすべて読破しました。これにより「オペレーションとシステムが全部頭の中で繋がる人材」が誕生したことが私にとって最も大きな成果でした。
「3ヶ月で頭を抱える」予言を覆すCIO採用と組織変革
新CIO着任前に取り組んだ重要なステップが『As-Isの見える化』です。現状のシステム構成を可能な限り詳細化するよう社内に指示したところ、当初『システム構成図はない』と言われましたが、大型商品の納品物を調査すると詳細な定義書が発見されました。
しかし、コスト削減の影響もあり、システム改変の履歴が十分に更新されていないなど、ブラックボックス化した領域も明らかになりました。
現場チームの協力を得て、既存システムの構成を可視化するとともに、各要素に対する課題や不満をマッピングしました。これにより、「なぜデータがここでスタックするのか」「なぜここが繋がっていないのか」といった問題点が徐々に明確になりました。これらの準備作業を新CIO着任前に進めることで、着任後すぐに本格的な改革に取り組める環境を整えました。
また、それに加えて『踊り場宣言』というものを行い、不要不急の開発以外は一旦停止することにしました。このプロジェクトを進める中で気づいたのは、他者が作成した工程表やエクセルシートには魂が入っておらず、やる気が起きにくいということです。自分自身がプランニングから魂を込めて作成したものには強いコミットメントが生まれ、モチベーションも高まります。
やらなければいけないもの以外は一度立ち止まる。この決断により、不要な手戻りや二重投資を避けることができました。新体制が整うまでは、まずは準備に集中し、新たに着任してから構想や実現方法を自ら考えていくことが、結果的にコミットメントを引き出す上で最も重要だと考えました。
システム構成図は「ない」と言われた会社で始めた可視化プロジェクト
そうして取り組みを進める中で『部分的なデジタル化の限界』や『部門最適による非効率な業務プロセス』など、いくつかの課題が見えてきました。
社内では、ダイレクトチャネルでの保険受付システム、給付金のデジタル処理、住所変更のデジタル化、銀行向けデジタル化、保険ショップ向けデジタル化など様々な分野でシステムのデジタル化が進められていました。
しかし、これらは個別のデジタル化であったため、新商品を導入する際には、それぞれのデジタル化されたシステムに搬送・運営確認が必要となり、開発を重ねるごとにスパゲッティのように複雑化し、開発コストが上昇していきました。機能はさほど変わらないにもかかわらず、『システムにコストがかかりすぎている』という評価だけが残る負のスパイラルに陥っていました。
また、『部門最適による非効率な業務プロセス』も課題でした。コールセンター、保険引受（アンダーライティング）、支払い処理、営業のCRMなど、各部門は自分たちにとって最適なシステムを追求していました。個々の部門では正しい判断であっても、会社全体で見ると冗長性が生じ、コスト増加につながっていました。各部門でシステム開発を行うことで「このシステムを作るなら、こちらの要望も取り入れてほしかった」といった不満も生まれていました。
これらの課題の根本を探っていくと、『社内にIT人材が不足しており、実現方法やプロセスに関するノウハウが欠如していること』『適切なアーキテクチャを構想できる経験者の不在』『レガシーシステム上に機能を追加し続けたことによるシステムの複雑化』などが原因として見えてきました。
デジタル化が進むほど複雑化する矛盾
この根本原因の解決方法として、まず、エンジニアを採用し、現状把握と課題解決の方向性を明確にしました。その上で、エンタープライズアーキテクチャのモダン化・シンプル化を進めています。将来のテクノロジートレンドを見据えつつも、完璧を求めるのではなく、着実に実現可能な目標を設定して共通基準をクリアすることを重視しました。
今後は、「AI前提のデータフロー設計」「STP（ストレート・スルー・プロセッシング）化の実現」「End to Endの業務プロセス自動化によるオペレーション変革」「コスト最適化（保守ではなく開発へのリソース配分）」などをTo-Beとして、進めていきたいと考えています。
また、2030年までのフューチャーステートを設定し、四半期ごとのローンチ計画を含むロードマップを短期間（約4ヶ月）で作成しました。
実行手法としては、組織全体でアジャイル手法を採用し、Azure DevOpsをコミュニケーションツールとして活用しています。DevOps開発管理としては、経営層と現場が同じツールを使用し、ペーパーレス・レポートレスの環境を実現しました。機能開発の領域や進捗、方向性を全員が常に把握できる状態を維持しています。
また同時に、OpsXプロジェクトも始動しました。コールセンターやオペレーション部門の機能開発と連動した自動化・効率化を推進しています。デジタル化そのものが目的ではなく、オペレーションやサービスレベルの向上がゴールなので、デジタル技術を十分に活用できる業務のあり方やルールの変革も同時に進めています。
アジャイルアプローチには、事業部門とデジタル部門の垣根を越え、全員が同じビジョンと情報を共有することで、組織全体の方向性を統一する狙いがあります。
開発の方向性を決める前に、まず根本的な理解が必要です。営業部門が求めている本質的なニーズは何か、オペレーション部門が直面している課題の優先順位は何か。これらを明確に把握することが出発点となります。
このような全体像を理解した上で初めて、エンジニアは適切な順序で機能開発やシステム構築を進めることができます。小さなシステムや機能から段階的に構築していくアプローチも、この共通理解があってこそ効果的に機能します。組織の全メンバーがこの全体像を把握することで、部分最適ではなく全体最適に近づけるように進んでいこうと考えています。
4ヶ月で構築した2030年へのロードマップ
そのような取り組みの中で、経営として重要なのが「ダブルブリッジ（二重橋）モデル」です。これは「テクノロジーサイクル」と「ビジネスサイクル」、二つのサイクルを同時に回していくアプローチです。
「テクノロジーサイクル」では、ホールディングスベースでアーキテクチャの構築をし、CIOが企業全体のブループリントの策定をします。その上で、グループ全体での集中購買によるコスト削減を図っていく。
同時に、POC（概念実証）を集約し、必要なAIやラグに関するPOCを効率的に実施しています。それらを実装する中で得た経験値を「センターオブエクセレンス」としてシステムの子会社に知見集約し、他のグループ企業にも展開しています。
一方で、「ビジネスサイクル」では市場・顧客ニーズを把握し、許容可能な顧客需要の見極めをします。その上で、必要な品質・コスト・最低限の要件定義を割り出し、売上・利益・コストの最適化を進めます。
この二つのサイクルを同時に進行させることが重要です。システム開発だけでは不十分であり、何を作るべきか、開発したシステムでどのような価値を提供できるかを常に確認しながら進めなければ、優れたシステムを開発しても使われない、あるいは「売れない」という結果になりかねません。この二重橋のようなサイクルを、両方ともマネージしていくのが私の重要な役割であると考えています。
全社参加型のアジャイル開発体制
また、アジャイル開発を進める中で全体最適を維持するため、以下のガバナンス体制を構築しています。
「PIプランニング（プログラム・インクリメント・プランニング）」を3ヶ月に一度行い、全ての関係者（営業・オペレーション・デジタル部門等）が集まり、1.5〜2日間かけて方向性を確認・調整します。優先順位の見直しや地殻変動への対応を協議し、大きなプロジェクトではなく、小さな機能を継続的に開発・統合することで、新しい機能をビジネス的にローンチすることができます。
また、PIプランニングのチェックや決済を行う場として、「プロダクトマネジメントコミッティ」を私が座長となって毎月開催し、開発速度（ベロシティ）の確認や品質評価と必要に応じたリソース調整をしています。これらのサイクルを回し続けることで、開発を止めることなく課題解決を進めることができ、継続的な開発体制が構築されています。
このような取り組みを行っている会社ですので、ご興味があればぜひお声かけください。以上で発表を終わります。ご清聴ありがとうございました。
