アジャイル開発の導入を検討するとき、多くの担当者がまず知りたいのは「同じように不確実性の高い新規事業や基幹システムを抱えた組織が、実際にどうやってアジャイルを取り入れ、どんな成果を出したのか」という具体的な事例ではないでしょうか。アジャイル開発は、ウォーターフォールに慣れた現場へそのまま持ち込んでも形だけのスクラムに陥りやすく、「朝会をやっているのに進捗が見えない」「振り返りが不満発表会になる」といった失敗が後を絶ちません。だからこそ、自社の状況に近い導入事例・実践事例こそが、投資判断と進め方の精度を高めてくれます。
本記事は、アジャイル開発の導入事例・活用事例・成功事例を、発注側・推進側の視点から掘り下げる「事例特化」の解説です。東京都が準委任契約でアジャイル調達を進め2022年に4プロジェクトを成功させた取り組み、りそなグループがクロスファンクショナルチーム（CFT）で勘定系に依存しないAPIを生み出した事例、金融系SIerが契約手続きのやり直しを減らして管理オーバーヘッドを圧縮した事例、さらに中大規模・分散拠点でコミュニケーション分断を乗り越えた工夫まで、一次データとあわせて具体的に解説します。なお、アジャイル開発の全体像をまだ把握していない方は、まずアジャイル開発の完全ガイドから読むことをおすすめします。
東京都の準委任アジャイル調達と成功事例
行政のシステム調達は、固定要件・一括請負・年度予算という制約が強く、本来もっともアジャイルが入りにくい領域とされてきました。その壁を制度から作り変えた代表例が、東京都の取り組みです。仕様を細かく固定して請け負わせるのではなく、専門人材の能力と工数を調達する準委任型のアジャイル調達に踏み込み、行政でもアジャイルが機能することを実証しました。発注側の組織が変われば、ウォーターフォールが当たり前だった現場でもアジャイルは根づくという、貴重な実例です。
準委任契約で稼働を分単位管理した調達モデル
東京都は2021年ごろから準委任契約によるアジャイル調達を進め、2022年には複数のプロジェクトを成功裏に進めました。注目すべきは、稼働を分単位で管理し、実際に投入された工数に応じて単価を清算するという調達モデルを整えた点です。請負のように「完成物」を固定するのではなく、専門人材が一定期間どれだけ稼働したかで費用を精算するため、要件が動いても契約をやり直す必要がありません。これがアジャイルの「作りながら学ぶ」進め方と整合します。
準委任型の調達は、発注者にとって「完成リスクを自分で負う」ことを意味するため、行政や大企業では強い抵抗が生まれます。それでも東京都が踏み切れたのは、稼働の透明化と清算ルールを制度として明文化し、税金の使途として説明責任を果たせる形に整えたからです。アジャイルを導入したい組織がまず学ぶべきは、ツールやプラクティス以前に「契約と予算の仕組みをアジャイルに合わせて作り変える」という発想の転換だと、この事例は教えています。契約形態の選び方は判断基準とも深く関わるため、メリット・デメリットの観点もあわせてご覧ください。
キックオフのアジャイル模擬体験ワークショップ
東京都の取り組みでもう一つ示唆的なのが、プロジェクトのキックオフで関係者がアジャイルを模擬体験するワークショップを行った点です。アジャイルの失敗の多くは、用語や手順を頭で理解しても、実際の振る舞いが従来のウォーターフォールのまま変わらないことから生じます。発注者・利用部門・開発者が同じ場で短いサイクルを擬似的に回し、優先順位づけや作って見せる体験を共有することで、その後のスプリント運用が形だけにならずに済みます。
この「最初に全員で体感する」アプローチは、行政に限らずあらゆる組織で再現できる打ち手です。アジャイルは開発チームだけの手法ではなく、要件を決めるプロダクトオーナーや、成果を受け取る利用部門までを巻き込んで初めて機能します。導入初期に共通言語と共通体験を作っておくことが、後の「朝会が進捗報告会になる」「振り返りが不満発表会になる」といったアンチパターンを未然に防ぎます。事例から学べるのは、アジャイル導入は技術導入ではなく、組織の学習プロセスの設計だという視点です。
りそなグループのCFT体制によるアジャイル内製事例
金融機関は、勘定系という巨大で堅牢なシステムを抱え、変更に慎重にならざるを得ない領域です。そのなかでアジャイルを実践した代表例が、りそなグループの「りそなガレージ」です。勘定系の重さに引きずられず、新しいサービスを素早く試せる環境を社内に作ったこの取り組みは、大企業がアジャイルで内製力を高める道筋を示しています。外部に丸投げするのではなく、自社のなかに作って検証する力を育てた点が、他の事例と一線を画します。
クロスファンクショナルチームで職能の壁を越えた事例
りそなガレージの中核にあるのが、クロスファンクショナルチーム（CFT）という体制です。企画・デザイン・開発・業務といった職能を一つのチームに同居させ、企画書を部門間で受け渡すウォーターフォール的な分業をやめました。アジャイルが速く回るのは、判断に必要な人が同じチームにいて、その場で意思決定できるからです。職能横断のチームを組むことで、「企画は作ったが開発に伝わらない」「現場の事情が設計に反映されない」といった伝言ゲームの損失が消えます。
大企業でアジャイルがうまくいかない典型的な原因は、部門の壁とレポートラインの縦割りです。CFTはこの構造的な問題に正面から手を入れる打ち手であり、だからこそ経営のコミットメントが欠かせません。チームに権限を委ね、必要なメンバーを兼務でなく専任で配置し、評価制度もチームの成果を見る形に寄せる。りそなの事例が示すのは、アジャイルは開発手法であると同時に、組織設計と人事制度の問題でもあるという事実です。形だけスクラムのイベントを導入しても、職能の壁が残ったままでは速度は出ません。
勘定系に依存しないAPI基盤を内製した事例
りそなの取り組みで技術的に重要なのが、勘定系に依存しないAPI基盤を整えた点です。アジャイルで素早く試行錯誤するには、変更のたびに巨大な勘定系へ手を入れる構造では速度が出ません。そこで、勘定系の外側に疎結合なAPI層を設け、新しいサービスはその層の上で素早く開発・検証できるようにしました。アーキテクチャをアジャイルに合わせて整えることで、ビジネス側の試行錯誤がシステムの重さに足を引っ張られなくなります。
この事例が教えるのは、アジャイルの速度は「進め方」だけでなく「技術構造」にも支えられているという点です。継続的に作って検証するサイクルを回すには、変更しやすいアーキテクチャと、自動化されたビルド・テストの仕組みが土台になります。国内でも大規模アジャイルの約7割が継続的インテグレーション（CI）を実施しているとされ、技術基盤の整備が成功事例の共通項であることがうかがえます。アジャイルを成功させたい組織は、体制と契約に加えて、変更に強い技術構造の設計にも投資する必要があります。
金融系SIerが管理オーバーヘッドを減らした事例
受託開発の現場では、要件が変わるたびに契約をやり直すことが、見えにくいコストを生んでいます。請負契約を前提にすると、変更のたびに見積もり・稟議・契約手続きが発生し、本来の開発以上に管理の手間がかかります。金融系SIerの事例は、この管理オーバーヘッドをアジャイル型の契約で減らした実践として参考になります。契約のあり方そのものが、プロジェクトのスピードと無駄を大きく左右することを示す事例です。
契約手続きのやり直しを減らした事例
この金融系SIerは、変更のたびに契約をやり直す請負前提のやり方から、一定期間の専門人材の稼働を調達する形へ切り替えました。これにより、仕様が動くたびに発生していた見積もり・契約変更の手続きが大幅に減り、開発チームは本来の作る・検証する活動に集中できるようになりました。アジャイルの真価は、機能を速く作ることだけでなく、変更を前提とした契約によって、変更コストそのものを下げる点にあります。
管理オーバーヘッドの削減は、稟議では見えにくい効果ですが、実際のプロジェクト現場では大きな差になります。変更のたびに止まって手続きを待つチームと、決められた稼働枠のなかで優先順位を入れ替えながら進めるチームでは、同じ予算でも到達点がまったく異なります。アジャイル型契約は、要件の不確実性が高いプロジェクトほど効果を発揮します。要件をどう定義し、どう契約に落とし込むかは要件定義・RFPの設計に直結するため、関連する記事もあわせてご覧ください。
スピード要求に応えたアジャイルの効果事例
アジャイルが選ばれる背景には、現場の優先順位の変化があります。JUASの調査では、システム企画時に重視する項目として納期が47%と最も高く、品質29%、コスト24%を上回ったとされます。市場の変化が速い領域では、完璧な仕様を時間をかけて作るより、まず動くものを早く出して反応を見るほうが価値を生みます。アジャイルは、このスピード要求に構造的に応える手法であり、事例の多くが「早く出して学ぶ」ことの効果を裏づけています。
ただし、スピードは要件の不確実性が高い領域でこそ価値になります。固定された要件を確実に作り込む組込みシステムや、法規制で仕様が厳密に定まる領域では、必ずしもアジャイルが最適とは限りません。事例を読むときは、「なぜその組織でアジャイルが効いたのか」という前提条件まで含めて理解することが大切です。自社のテーマが不確実性の高いものなのか、確実性を重んじるものなのかを見極めることが、手法選択の出発点になります。
中大規模・分散拠点の壁を越えた実践事例
アジャイルは小さなチームで力を発揮する手法ですが、現実には複数チーム・複数拠点で進めざるを得ないプロジェクトが少なくありません。国内アジャイルの約8割は8名以下のチームで回っているとされる一方、大規模・分散になると途端にコミュニケーションが分断され、成功率が下がります。この壁をどう越えたかを示す実践事例は、規模の大きい組織にとって最も学びの多い領域です。
チーム間ローテーションと段階的な朝会の工夫
複数チームでアジャイルを進める際、各チームが孤立すると、全体の整合が取れずに手戻りが増えます。これを防いだ実践では、メンバーをチーム間でローテーションさせ、互いの文脈やコードの理解を共有する工夫を取り入れました。属人化を防ぎながら、チームをまたいだ暗黙知の伝播を促す狙いです。さらに、全員が一度に集まる大規模な朝会ではなく、チーム内の朝会と、各チーム代表が集まる二段階の朝会に分けることで、情報共有のコストを抑えています。
大規模アジャイルでありがちな失敗は、人数が増えたぶんだけ会議を増やしてしまい、メンバーが会議疲れに陥ることです。段階的な朝会は、必要な人だけが必要な範囲で同期する設計であり、規模に応じてコミュニケーションを再設計する好例です。アジャイルは小さく速く回すのが原則であり、規模が大きくなったら「より多くの会議」ではなく「より賢い同期の仕組み」を考える必要があります。詳しくは『アジャイル開発の失敗・課題・注意点・リスクについて』もあわせてご覧ください。
分散拠点でCIを徹底し品質を保った事例
拠点が分かれると、対面のコミュニケーションが減り、コードの統合時に問題が一気に表面化しやすくなります。これを防いだ実践では、継続的インテグレーション（CI）を徹底し、各メンバーの変更を頻繁に統合してテストを自動実行する仕組みを整えました。大規模アジャイルの約7割がCIを実施しているとされるのは、分散環境で品質を保つにはCIが事実上の前提になるからです。統合の問題を小さいうちに検知できれば、分散による分断の影響を最小化できます。
分散拠点のアジャイルで成功している事例は、ツールとプロセスの両面で「対面が減ったぶんを技術で補う」設計をしています。コードの状態を常に見える化し、誰がどこを変えているかを共有し、統合の自動化で人手のミスを減らす。こうした技術的な土台があってはじめて、物理的に離れたチームでもアジャイルの速度を保てます。中大規模・分散は最もアジャイルが崩れやすい領域だからこそ、技術と運用の工夫が成功と失敗を鮮明に分けるのです。
まとめ
アジャイル開発の導入事例・活用事例を振り返ると、成功はいずれも「ツールやイベントの形だけでなく、契約・体制・技術基盤という組織の土台までアジャイルに合わせて作り変えている」という一点に集約されます。東京都は準委任で稼働を分単位管理する調達モデルとキックオフの模擬体験で行政にアジャイルを根づかせ、りそなはCFTと勘定系非依存のAPI基盤で大企業の内製力を高め、金融系SIerは契約のやり直しを減らして管理オーバーヘッドを圧縮しました。中大規模・分散では、段階的な朝会とCIの徹底が分断を防ぐ鍵になっています。
事例を読むときに大切なのは、「どんなツールを使ったか」ではなく「なぜその組織でアジャイルが機能したか」という前提条件です。日本ではスクラム導入率が20%を超えても半数近くが失敗すると言われるなか、成功する組織は例外なく土台から変えています。自社の不確実性の高いテーマに照らし、まずは契約と体制という土台の設計から、再現できる一歩を踏み出してください。riplaはフルスクラッチ受託と準委任の伴走で、組織ごと変えるアジャイル導入を一貫して支援します。全体像の確認には、あらためて完全ガイドをご活用ください。
株式会社riplaでは、IT事業会社出身のプロフェッショナルが「Impact-Driven型支援」を通じて、プロダクトやシステムの納品・提供を目的とせず、お客様と同じ目線で、事業成果の達成をゴールとして、高品質なDX/開発支援をいたします。
また、弊社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。
もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。
・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>
株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。IT事業会社出身のプロフェッショナルが集う株式会社riplaにおいて、「Impact-Driven型支援」を掲げ、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の実現に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。