キャッシュレス決済が急速に普及し、金融業界のソフトウェア開発にはかつてない「価値提供スピード」が求められている。一方で、スピードを掲げて「金融アジャイル」を導入したはずが、厳格な品質保証プロセスや複数のパートナー企業がかかわる複雑な体制に阻まれ、「ウォーターフォールより工数がかかるアジャイル」という形骸化の罠に陥る組織は少なくない。
品質とスピードは、本当にトレードオフなのか──。

2026年5月21日、ファインディ株式会社が主催したイベント「品質とスピードを両立する『金融アジャイル』〜価値提供を加速させる実践知〜」では、この問いに正面から向き合い、価値提供の加速を実現してきた金融フロントランナー3社が登壇し、クレディセゾンは「内製×AI」を軸とした開発文化を、楽天カードは「チームトポロジー」による組織設計を、マルイユナイトは「意思決定プロセスそのものの変革」の軌跡を語った。
本イベントレポートでは、切り口の異なる3社の課題解決ストーリーを、CTO・VPoE・EM・開発リーダーが自社に置き換えて考えられる形で整理する。

【イベント概要】

3社の切り口は意図的に異なっている。文化と個人の振る舞いから攻めるクレディセゾン、組織構造から攻める楽天カード、意思決定の権限と仕組みから攻めるマルイユナイト。
同じ「金融アジャイル」という言葉の下で、変革のドライバーがこれほど分かれる点こそ、本イベントの最大の学びである。

【セッション①｜クレディセゾン「内製×AIで挑む、価値提供を加速させる開発戦略」】

登壇：株式会社クレディセゾン エンタープライズ開発センター 課長 氏原 裕矢 氏

セッション概要

「AIを使えば開発が速くなる」という単純な話ではない。AIで価値提供を速くするために、組織として、個人として何が必要だったのか──。
クレディセゾンが5〜6年かけて積み上げてきた内製化・伴走型内製開発・チーム文化、そしてそこにAIをどう効かせているかを、現場の実感をもとに語ったセッションだ。

課題・背景

氏原氏が一貫して強調したのは、速くしたかったのは「コードを書く時間」ではなく「価値が届くまでの時間」だという点だ。
課題に気づくまでの時間、認識を合わせる時間、意思決定をする時間、作って試す時間、フィードバックを受けて直す時間──これらを短くしない限り、価値提供は本当の意味で速くならない。
コードを書く速度だけを上げても、ビジネス部門と開発部門の間に距離があれば、価値は遅れて届く。

金融という事業ドメインには、絶対に失敗が許されない安定運用の領域がある。だからといって、すべてを慎重さ一辺倒で進めれば、新しい価値は生まれない。この緊張関係が出発点だった。

取り組み内容

① バイモーダル戦略──「品質 or スピード」を二択にしない
システム開発を2つのモードに分けて考える。モード1は安定性重視で、失敗が許されない領域をウォーターフォールで着実に進める。モード2はスピード重視で、探索的な新規サービスをアジャイルで小さく試しながら進める。重要なのはどちらかに統一することではなく、領域に応じて使い分けること。金融でも、新しい価値を生むにはモード2が必要だという立場だ。氏原氏自身、入社前は金融会社に「稟議が長く意思決定が遅い」モード1的な組織像を抱いていたが、カジュアル面談での意思決定の速さに驚き、それが入社の決め手になったという。守るべきところは守り、進めるところは驚くほど速く動く──そのギャップこそがクレディセゾンの姿だと語った。

② 伴走型内製開発──作る側と望む側を融合させる
デジタル部門がビジネス部門に寄り添い、業務課題を一緒に考え、一緒にシステムを作る。内製化の目的としてコスト削減・スピード・ノウハウの手の内化が挙げられるが、氏原氏が個人的に「本当の価値」と考えるのは、ビジネス部門との距離が近くなることだ。「何を作るか」だけでなく「なぜ作るのか」「本当にそのやり方でよいのか」まで同じ会社の仲間として一緒に考える。その繰り返しが「あのチームに頼めば一緒に考えてくれる」という信頼を積み上げる。

③ チーム文化の4原則
伴走は仕組みだけでは続かない。曖昧な相談も意見の変化も増えるなかで、相手を責めず感情的にならず立場で押し切らないために、文化が要る。クレディセゾンが大切にする4原則は次の通りだ。

1. さん付けの徹底──役職呼びもくん付けもせず、全員「◯◯さん」。肩書きや年次で人を見ないことの宣言であり、「上の人に反論しづらい」感覚を薄める土台になる。
2. HRT（謙虚・尊敬・信頼）の原則を100%守る──書籍『Team Geek』の考え方。言うべきことは言うが、相手への敬意は失わない。感情でチームを壊さないための自分への約束。これが心理的安全性とセットで効く。
3. 長所を見る──短所から目を背けるのではなく、人を見る軸を長所に置く。続けるうちに他人の長所が自然に見え、「あの人のやり方を真似てみよう」と自分の苦手にも向き合いやすくなる。
4. 成果を出すチームであることを最重視する──前述の3原則は「仲良しチーム」のためではない。世の中を良くし、お客様に価値を届けるという前提があってこそ、3原則は意味を持つ。

④ 「その場で作る」──AIで意思決定の速度を上げる
ビジネス部門と近くなっても、言葉だけでは認識がずれ、資料化には時間がかかり、持ち帰って作ると認識のズレが起きる。そこで最近取り組んでいるのが、意思決定できるメンバーを集め、出てきた意見をその場で画面やモックに反映する手法だ。「一覧画面だけ」と想定していたものが、触ってもらううちに「まず検索したい」「一覧より先にアラートが見たい」と具体化する。会話の熱量が残るうちに確認できることに価値がある。ここでAIが効く。氏原氏にとってAI活用の本質は、開発者の生産性向上だけでなく、意思決定と認識合わせの速度を上げ、ビジネスと開発が同じものを見ながら決められる状態をつくることだ。ただし、デプロイ段階では品質・セキュリティ・運用性を必ず作り込む。「金融のシステムである以上、そこは絶対に外せない」。意思決定用のプロトタイプだからこそ、まず速く形にすることに価値があるという整理だ。

成果・学び

内製開発チームは2020年に3名でスタートし、現在は約200名規模に。累計の業務削減時間は161万時間、クラウド化率は80%、紙の使用量は102トン（A4換算で約2,040万枚）を削減した。
氏原氏は、DXという大きな言葉の実体は、こうした一つひとつの業務の変化の積み重ねだと語る。
そして最後に、最初から完成形を目指さず「小さく始めて小さく積み重ねる」ことの重要性を、『プログラマが知るべき97のこと』の「ロールプレイングゲーム」（理想のエンジニアを“演じてみる”）になぞらえて締めくくった。

印象的なコメント

AIは強力な道具です。でも、AIだけで価値提供が速くなるわけではありません。価値を届ける相手と近い距離で話せること、違和感を出せること、その場で試せること、そしてチームとして成果に向かえること。そういう土台があってこそ、価値提供のスピードを大きく変える力になる

このセッションから得られる示唆

• 「遅さ」の正体を、コード生産以外（気づき・認識合わせ・意思決定・修正）まで分解して捉える。
• 品質とスピードは二択にせず、領域ごとにモードを使い分ける（基幹はモード1、新規はモード2）。
• AI活用の効果は「意思決定・認識合わせの高速化」に拡張して考える。生産性向上だけに閉じない。
• AIで速くするプロトタイピングと、本番投入時の品質作り込みは明確に分離する。
• 施策の前提として、心理的安全性とHRTという文化的土台への投資が効いてくる。

【セッション②｜楽天カード「金融アジャイル×チームトポロジー」】

登壇：楽天カード株式会社 プラットフォーム部 エンジニア支援グループ マネージャー 松尾 宏介氏 ※江上氏は体調不良のため不参加となっております。

セッション概要

カード発行枚数3,387枚（2026年3月末）、2025年度 ショッピング取扱高26.5兆円という巨大な決済プラットフォームの基幹を含むほとんどのシステムを内製開発する楽天カード。
松尾氏は、組織を支援する「イネーブリング」の立場から、複雑さを組織構造で引き取り、主役の開発チームを事業価値に集中させる実践を、書籍『チームトポロジー』の枠組みに沿って語った。

課題・背景

金融の難しさは「規制・コンプラ」「レガシーシステム」「組織のサイロ化」が同時に存在することにある。これらはエンジニア個人のスキルアップだけでは解決しない。

象徴的なのが「認知負荷」の問題だ。エンジニアがフロー状態に入るには2〜3時間の連続した集中が必要とされるが、現場の朝はこうだ──SNSでAIツールの新機能を見つけて試したくなり、社内ポリシーを確認しようとした矢先にCIが赤くなり、調べているうちにPOから「最新KPIはどこで見られる?」と問い合わせが来て、承認フローを思い出した頃にはリファインメントまであと10分。
やりたいのは「プロダクト開発への集中」なのに、周辺の複雑さに振り回されて時間が溶けていく。これを個人の頑張りではなくチーム設計で補うのが解決の方向性だ。

加えて、メインの開発チーム（キャッシング・リボなど）は、組織の縦割り・分断と、アジャイル/スクラムの形骸化という課題を抱えていた。

取り組み内容

① 複雑さを引き取る4つのチームタイプ
『チームトポロジー』が定義する4タイプを、楽天カードはこう実践している。松尾氏は「とんかつ屋」の比喩で解説した。お客様に最高のとんかつを届けるのがホール・キッチン（＝価値を直接届けるStream Aligned＝主役の開発チーム：入会・決済・キャッシング等）。食材調達・秘伝のタレ・包丁メンテ・教育まで全部やらせては大変なので、他チームが引き取る。

• Platformチーム：開発チームが「使うだけ」の状態でツールや基盤を提供。たとえば話題のAIは、専任チームがツール選定、セキュリティ部門との利用ルールの取り決め、データ入力可否の整理を担い、各チームが安心して使える状態をつくる。
• Enablingチーム：横断的に開発チームを支援し、新しい実践ができるようになるまで伴走して、最後は離れる。アジャイルコーチがスクラムイベントに同席したり、AIコードレビューのデモで使い方を教えたりする。合言葉は「魚を与えるのではなく、釣り方を身につけてもらう」。
• Complicated Subsystemチーム：基幹システムなど極めて複雑な領域を専門的に引き取る。基幹はウォーターフォールで開発サイクルが長いため、フロント側にはAPIとして機能を提供し、フロントの速度と基幹の速度の帳尻を合わせる。フロントは基幹の複雑なデータモデルを気にせずインターフェース仕様に沿って叩けばよい。

② バリューストリームに沿ったチーム再編
従来はプロダクト単位の縦割りで、バックログを各チームが持ち、事業側がそれを各チームにばらまくため、タイムラインが揃わず調整コストが膨大だった。これを、事業の流れ（バリューストリーム）に沿って横断的に再編。キャッシング・リボ・分割払いといった事業価値の軸でチームとバックログを束ね直したことで、優先度の調整がチーム内で完結するようになった。

③ スクラムイベントの“意味”が変わった
構造変更は、スクラムの中身を変質させた。最も大きく変わったのがリファインメントだ。以前は「PBIの仕様確認と見積もり」の場だったが、今は「このPBIはどのKPIに効くのか」「期待効果はどれくらいか」「もっと良い方法はないか」を議論する場になった。作業管理の場から、価値を判断する場へのシフトである。スプリントレビューも、dev・PO・ビジネス側が一つの部屋に集まり「これいいね、次こうしよう」と成果を見る場に。大規模な金融組織で“教科書通りのスクラム”を実現すること自体が容易ではない、と松尾氏は実感を込めた。

成果・学び

対象事業領域の主要KPIは、昨秋からのチャレンジを経て、前年同期比（YoY）で明確に伸びた。だが松尾氏が伝えたかったのは数字そのものではなく、「作るチーム」から「価値を学び続けるチーム」への変化だ。リリースして終わりではなく、KPIへの影響を見て次のバックログ判断に活かす。チームがドメイン知識を蓄積し、価値を学習し続ける存在へと変わっていった。

印象的なコメント

「金融アジャイルは、慎重さを捨てて速くすることではありません。慎重さを保ちながら、学習の速度を上げていく。複雑さは絶え間なく生まれ続けるので、それを組織で引き取り、開発チームが正しく判断できる構造をつくる。当たり前のスクラムを、頑張って当たり前に近づけていくことが、金融アジャイルの面白いところだと思います」

このセッションから得られる示唆

• 開発チームが事業価値に集中できているか、不要な複雑さを誰かが引き取る設計になっているかを点検する。
• チーム分割の目的は「分けること」ではなく「どの複雑さを誰が引き取るか」を決めること。
• 基幹（長いWF）とフロント（速いアジャイル）はAPIや疎結合で“速度差”を吸収する。
• リファインメントを仕様確認ではなく「KPI・事業価値を判断する場」へと意味づけし直す。
• 大組織では「教科書通りのスクラムを実現すること」自体が成果であり、難度を過小評価しない。

【セッション③｜マルイユナイト「価値提供スピードを加速させる金融アジャイル 〜プロジェクトAからの軌跡〜」】

登壇：株式会社マルイユナイト フィンテックプロダクト部 部長 天﨑暁司氏／同 UXデザイン担当 チームリーダー 新井佳奈氏

セッション概要

登壇した2名はいずれもエンジニア出身ではなく、店舗販売や事業企画といったビジネス寄りのキャリアを歩んできた。だからこそ語れるのが、技術論ではなく意思決定プロセスそのものの変革の物語だ。エポスカード会員830万人、ライフスタイルアプリ540万人を抱える丸井グループが、サイロ化・重厚な稟議文化・複数のパートナー企業がかかわる複雑な体制という状況から、どう価値提供を速くしてきたのか。その段階的なステップが共有された。

課題・背景

内製化以前の課題は大きく2つあった。

組織の問題（縦割り）：
企画・UX・UI・システム・実装が部署ごとにバラバラで、プロダクト全体を見る人がいなかった。さらに「企画→各担当へ振り分け→パートナー企業へ伝達」という多重下請け構造のなかで、正確に伝えるためのドキュメント作成に時間が奪われ、施策の良し悪しを考えるより「連携の段取り」に労力が割かれていた。

意思決定の重さ：
ウォーターフォールゆえ、ごく小さな開発でも毎回社長決裁が必要だった。「アプリにアイコンを1つ追加する」だけでも社長の印鑑をもらいに行く。決裁を通すために精緻な見積もりを作り込む労力もかかる。ユーザーインタビューで課題が見えているのに、決裁が取れず、取れても着手は1年後──「課題が見えているのに動けないジレンマ」が現場を覆っていた。

取り組み内容

① プロジェクトA──包括決裁による権限委譲
突破口は、経営トップダウンの特命チーム「プロジェクトA」（AはアジャイルのA）だった。UI/UXに強みを持つグッドパッチ社との合弁会社・株式会社Mutureの助言を受け、社長直轄で通常組織から切り離し、ビジネス・デザイン・開発のメンバーを一か所に集めた。最大の変化は、予算と期間を固定した「包括決裁」を取得し、その範囲内なら意思決定をすべて現場に委ねたことだ。機能ごとに都度決裁を取る重さから解放されたことが、すべての施策を可能にした。

② パートナー体制の刷新とワンチーム化
従来のオフショア体制（海外拠点中心・メンバー流動的・週1コミュニケーション）を、全員国内メンバーの新パートナーへ切り替え、半常駐で毎日密に対話できる体制を構築。さらに、企画・デザイン・開発が最初からワンチームになり、短いサイクルで要件定義から検証・開発までを一緒に回した。これによりメンバーの意識が「タスクをこなす」から「プロダクトを良くする」へと変わった。

③ 動くもので合意し、軌道修正を繰り返す
これまで大量のドキュメントで品質を担保しようとし、発注までに平均160時間を要していた。プロジェクトAでは、スクラムのイベントの中で動作物やソースコードを使って常にすり合わせることで、ドキュメントを最低限に抑え、作業コストを大幅に削減。さらに、いきなり作らずプロトタイプでユーザーインタビュー検証を行い、開発後もA/Bテストでフィードバックを得て、包括決裁の枠内で柔軟に軌道修正した。

成果・学び

ウォーターフォールなら「最後にまとめて1回」だったリリースが、早期に検証を開始し少しずつ価値を積み上げる形へ。
プロトタイプ変更12回、本番リリース12回を実施し、お客様への価値提供スピードが劇的に向上した。

この成功を全社へ広げるため、2024年に新会社マルイユナイトを設立。バラバラだった企画・UI/UXデザイン・エンジニアを一つの組織に統合し、意思決定ラインを正式に一本化した。事業会社エポスカードとは、「カード起点施策（新カード等）はエポスが意思決定」「プロダクト起点施策（ホーム画面改善等）とUX設計はユナイトが意思決定」と領域で明確に分担し、期初に包括予算を組むことで実行スピードを高めている。

一方で新たな課題も生まれた。カード起点施策（特に基幹システム）は包括予算外で都度決裁が残り、各企画部門からの見積もり依頼が殺到。テック部門の仕事の3〜4割が見積もり算出に奪われ、しかもその半分は企画決裁でペンディングになっていた。これに対し「開発の一次受け」運用を新設。責任者クラスがまず一次受けして概算見積もりを素早く出し、企画決裁を先に通し、詳細見積もりはUX構築後に行うよう順番を最適化した。これにより開発リソースの逼迫が緩和され、決裁までのリードタイムが大幅に短縮した。

印象的なコメント

「私たちが目指すのは“真の内製化”です。それは単なるプロジェクト管理の内製化ではなく、システムをソースコードレベルで完全に自らのコントロール下に置くこと。品質管理も、柔軟な対応も、そして何より意思決定のスピードを上げるためには、自社で技術判断できる体制が不可欠だと考えています」

このセッションから得られる示唆

• 「意思決定の仕組み」自体を改善対象にする。包括決裁・権限委譲はスピードの強力なレバーになる。
• 重厚なドキュメントによる品質担保を、動作物・ソースコードでのすり合わせに置き換える。
• 見積もりプロセスの順番を最適化する（一次受けで概算→決裁→詳細見積もり）だけでリードタイムは縮む。
• 内製化を「管理の内製化」で止めず、ソースコードレベルの“真の内製化”まで段階的に射程を伸ばす。
• トライアル（プロジェクトA）→組織化（新会社設立）という段階的展開が、変革を全社へ広げる現実的な道筋になる。

【Q&Aセッション】

イベント後半は、参加者からの質問をもとに、3社の考え方の違いが鮮明になった。

論点1：アジャイルとウォーターフォールの連携──品質確保とリリースタイミング

• クレディセゾン：API連携で仕様を合わせるタイミングを設け、品質保証のゲートはウォーターフォール側に合わせる。
• 楽天カード：理想形として「feature toggle」を活用。先行チームが先にリリースしつつ新機能をフラグで閉じておき、後から来た基幹システムのリリース後にフラグを解放して連携を開始する。リリースタイミングを無理に揃えずに済む。
• マルイユナイト：基幹はまだ完全にウォーターフォール。複数のパートナー企業がかかわる複雑な体制をパズルのように組み合わせ、リリース可能なタイミングにフロント側を合わせる。ビジネス優先度が高い場合はトレードオフで調整する。

論点2：サイロ化した組織を。
価値に集中させるため、現場ができること

• 楽天カード：まず「自分たちが美しいと思えるものは何か」を言語化し、価値観を全員で共有できる場をつくる。偉い人だけが盛り上がると白けるため、全員での雰囲気づくりが第一歩。
• マルイユナイト：キャリア・経験・知識の壁を取り払い、フラットに同じ視点で仮説を育てる。多種多様なメンバーが対等に対話することを期待する（「まだできていない部分も多い」と率直に補足）。
• クレディセゾン：仕組みづくりよりも、ユーザーと本当に一緒に作る。週に5〜6時間の打ち合わせがあった時期もあった。役割分担しすぎず一緒に作る「気合い」の部分も大きい。

論点3：AIによる組織文化の変化と失敗（クレディセゾン）

AIが開発フローに組み込まれて文化は変わった、と氏原氏。部下
がAIで仕上げた成果物に「人の温かみが見えない」と感じる一方、ジュニアエンジニアが一定レベルの成果を出せるようになり、AIは知識の「補助輪」として機能している。失敗については、大きな事故は起きていないものの、「何でもできてしまう」AIエージェントやコーディングAIで事故になりかけた経験があると率直に語った。

論点4：アジャイル導入のきっかけ──誰が提案し、誰が決めたか

• マルイユナイト：完全なトップダウン。株式会社Mutureのメンバーが現場に入って課題を紐解いた。現場は「ウォーターフォールが当たり前」で課題に気づけず、外部の専門人材が入ったことで初めて変化を起こせた。
• 楽天カード：かつての縦割り・長工期でみなが疲弊していた頃、当時の部長が社長に「リードタイムを半分にします。半分にならなかったら僕が半分になります」と宣言。トップの意思決定のもと内部プロダクトのパイロットチームから始め、うまく回って横展開した。
• クレディセゾン：アジャイルもウォーターフォールも両方やっている。どちらでやるかの決定権は基本的にチームリーダーの裁量に委ねられ、きっかけや提案は各自に任されている。

論点5：リモート環境下での若手育成と成長度合い
の確認

• マルイユナイト：新メンバー向けに「オンボーディングクエスト」を用意（セットアップに加え、会社の成り立ちや伴走パートナーの紹介を含む）。在宅勤務で復職したメンバーにも自宅で取り組んでもらえる。成長度合いの確認は定期的な1on1で見ている。
• クレディセゾン：公募で約100人を（カウンター業務や電話対応をしていた人材を含め）エンジニアへ転換する試みを実施。新卒含め半年程度の研修と、社内向けシステムを企画・開発する時間を与えてから現場配属する。成長確認は「リモートでも対面でも変わらない。どれだけコードが仕上がるか、機能ができるかで見る」。

論点6：ビジネスとエンジニアの連携と定量データ（楽天カード）

集まって目の前で話すチームと、Zoom越しでしか会話しないチームでは差が出ている、と松尾氏。リモートでもオフラインでも、人が集まり心理的安全性高く「ワイガヤ」できる場づくりに力を注いでいる。KPI/KGIツリーといった定量データも用いるが、数字だけに偏らず「みんなで価値を提供できる場をどうつくるか」を大切にしている。失敗から学ぶことも、アジャイルの醍醐味だと語った。

共通して見えたこと

質問への回答は三者三様でありながら、底流には共通点があった。
慎重さ（品質）は捨てない。基幹はウォータフォール、フロントはアジャイルという使い分けを前提にしつつ、連携の工夫で速度差を吸収する。
そして、リモート/AI時代であっても、人が対等に対話し、価値観を共有する「場」への投資が成果を分けるという認識である。

【イベント全体【まとめ】】

共通課題

3社が口を揃えたのは、金融開発のボトルネックが「コードを書く速度」ではないという点だ。
真の障壁は、縦割り・サイロ化した組織と、重厚で時間のかかる意思決定プロセスにある。
価値が届くまでのリードタイム全体を縮めない限り、アジャイルは「工数だけかかる形だけのアジャイル」に陥る。

各社アプローチの違いヒント

同じゴール（価値提供の加速）に、文化・構造・プロセスという異なる入口から到達しようとしている点が示唆に富む。自社のボトルネックがどこにあるかによって、最初に手をつけるべき入口は変わる。

成功要因

• ビジネス／デザイン／開発の「ワンチーム化」と心理的安全性という土台を、施策の前提として築いていること。
• 品質を捨てずに速度を上げる設計（モードの使い分け、API・feature toggleによる疎結合、品質ゲートの維持）。
• トライアルから始めて段階的に広げる現実的な展開（パイロットチーム、プロジェクトA→新会社）。
• 経営層の関与（トップダウンの号令や包括決裁）と、現場の自律（裁量・価値観の共有）の両輪。

今後重要になるテーマ

AI時代の開発組織づくりにおいて、AIは「開発を速くする道具」にとどまらず、「意思決定と認識合わせを速くする道具」へと役割を広げつつある。
同時に、AIエージェントの暴走リスクの管理、AI前提での若手育成、そしてリモート下でも対話の質を保つ「場づくり」が、品質とスピードの両立を左右する次の論点になる。
内製化も、「管理の内製化」から「ソースコードレベルの内製化」へと深度が問われていく。

この記事の要点

1. 価値提供スピードの本質は「コードを書く時間」ではなく、気づき→認識合わせ→意思決定→試作→修正という価値が届くまでのリードタイム全体にある。
2. 品質とスピードは二択ではない。基幹はウォーターフォール、新規はアジャイルと領域で使い分け、連携の工夫（API・feature toggle）で速度差を吸収する。
3. 共通の根本課題は縦割り・サイロ化と重厚な意思決定プロセスであり、これがアジャイル形骸化の主因。
4. クレディセゾンは文化（伴走型内製開発・HRT・「その場で作る」）とAIによる意思決定の高速化で攻める。
5. 楽天カードはチームトポロジーで複雑さを各チームに引き取らせ、主役の開発チームを事業価値に集中させ、リファインメント/スプリントレビューの意味を変えた。
6. マルイユナイトは包括決裁による権限委譲と段階的変革（プロジェクトA→新会社設立）で、社長決裁の重さから脱却した。
7. 内製化は3社共通の方向性だが、「管理の内製化」か「ソースコードレベルの真の内製化」かで定義と深さが異なる。
8. AIは生産性向上だけでなく意思決定・認識合わせの高速化に効く一方、エージェントの事故リスク管理が新たな論点になる。
9. 施策が機能する前提として、ワンチーム化・心理的安全性・対話の場づくりへの投資が共通して重要。
10. 自社が最初に手をつける入口は、文化・構造・プロセスのどこにボトルネックがあるかで決まる。3社の違いはその選択の参考になる。

最後に

「金融アジャイルを導入したが形骸化している」「品質を担保するほどスピードが落ちる」と感じているなら、まず問うべきは「自社の遅さは、本当にコードを書く速度の問題なのか」だ。
決裁・調整・認識合わせのどこにリードタイムが潜んでいるかを可視化し、開発チームが不要な複雑さを抱えていないかを点検する。
文化・構造・プロセスのどの入口から手をつけるかは、各社の状況によって異なる。3社の実践は、その入口を選ぶための具体的な地図を提供してくれる。