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