スクラム開発の導入事例で成果を出した組織は、イベントを真似るより先に、契約の形、チームの編成、経営層の関与という土台を整えていました。
自社に近い立場の導入事例や成功事例は、投資判断と組織変革の精度を高めてくれます。東京都、りそなグループ、金融系SIer、中大規模の分散拠点の四つの事例から、その中身を読み解きます。全体像をまだ把握していない方は、まずスクラム開発の完全ガイドからご覧ください。
・業務システム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「業務システム開発の完全ガイドブック」で詳しく解説しています。
・スクラッチシステム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「スクラッチシステム開発の完全ガイドブック」で詳しく解説しています。
東京都が準委任契約でスクラムを調達した行政事例
東京都の取り組みは、契約と調達の壁を行政が正面から越えた例として参考になります。公共調達は仕様を固定して請負で発注するのが従来の常識ですが、スクラムは作るモノを事前に固定できないため、この調達モデルと相性が悪いという課題がありました。東京都は、ここに準委任契約という解を持ち込み、行政でもスクラムを成立させられることを示しました。
準委任調達と分単位の稼働管理で成果を出した事例
東京都は2021年から準委任契約によるアジャイル・スクラム開発の調達を本格化させ、2022年には複数のプロジェクトで成果を上げたとされています。準委任契約で調達するのは、完成した成果物ではなく専門人材の能力と稼働です。この調達の仕方は、要件が動くスクラムと整合します。
発注者は作るモノを固定する代わりに、スクラムマスターやエンジニアといった専門人材の稼働時間を確保し、スプリントごとに優先度の高い機能から作ってもらう形を取りました。注目したいのは、稼働を分単位で管理し単価で清算する仕組みを取り入れた点です。
準委任契約は成果が見えにくく青天井になるという発注者の不安を招きがちですが、東京都は稼働の透明性を高めて、その懸念を解消しました。投じた時間とアウトプットを可視化することで、行政の説明責任とスクラムの柔軟性を両立させました。この仕組みは後述するスクラムの要件定義のあり方とも深く関わるため、詳しくは『スクラム開発のRFP・要件定義書・提案依頼書について』もあわせてご覧ください。
キックオフのアジャイル模擬体験で認識を揃えた事例
この事例で見逃せないのは、プロジェクトの開始時に発注者と開発者が一緒に、アジャイル・スクラムの模擬体験ワークショップを行ったことです。スクラムでは、発注者側のプロダクトオーナーがスプリントごとに優先順位を判断し、レビューでフィードバックを返す役割が欠かせません。模擬体験を通じて関係者全員が進め方とそれぞれの責任を体感したことが、その後の円滑な運用につながりました。
この「最初に認識を揃える」工夫は、規模を問わずどのスクラム導入にも応用できます。スクラムは用語こそシンプルですが、プロダクトオーナーの権限、スクラムマスターの役割、開発チームの自己組織化といった概念は、体験してみないと腹落ちしにくいものです。慎重な行政組織がワークショップから入ったことは、スクラム導入の第一歩が「ツールの導入」より先に「役割の共有」にあることを物語っています。
りそながクロスファンクショナル体制で構築した金融事例
金融機関は、勘定系という巨大なレガシーと厳しい規制・セキュリティ要件を抱えているため、スピード重視の手法とは縁遠いと思われがちです。しかし、りそなグループは「りそなガレージ」と呼ばれる開発体制を立ち上げ、勘定系に依存しないAPI基盤の構築にスクラムを適用しました。大規模で規制の厳しい業種でもスクラムが機能することを示す好例です。
クロスファンクショナルチームで自律性を高めた事例
りそなの取り組みの核心は、企画・設計・開発・運用といった役割を縦割りにせず、必要な専門性を一つのチームに集めたクロスファンクショナルチーム（CFT）の編成にあります。スクラムの開発チームには、外部に頼らずスプリント内で機能を完成させられる自己完結性が求められます。
りそなはこの原則に沿って、ビジネス側とIT側が同じチームで意思決定する体制を整え、稟議や部門間の調整による遅延を構造的に減らしました。各部門に確認を取りながら進める従来型では、スプリントの短いサイクルに意思決定が追いつきません。
そこで、チーム内で完結できる権限を与えれば、デイリースクラムで出た課題をその日のうちに解決し、スプリントレビューで実際に動くものを見せられるようになります。この編成が「自己組織化」という価値を最大限に引き出します。スクラムのスピードは、イベントの形式ではなく、こうした権限委譲から生まれるのです。
勘定系非依存のAPI基盤で開発を高速化した事例
もう一つの工夫は、勘定系システムに直接依存しないAPI基盤を構築したことです。勘定系は変更に膨大な検証コストがかかるため、手を入れるたびにスプリントが止まってしまいます。りそなはAPIという中間層を設けて、勘定系を直接触らずに新サービスを開発できる構造を作り、スクラムの短いサイクルで安全に機能追加を繰り返せる土台を整えました。
この事例が教えるのは、レガシーを抱える大企業がスクラムを成功させるには、組織体制だけでなく技術アーキテクチャの工夫も欠かせないということです。変更に弱い基幹システムをそのままスクラムの対象にすると、検査と適応のサイクルが回らなくなります。
そこで、変更に強いレイヤーを切り出し、そこをスクラムの主戦場にする発想は、金融に限らず製造業や行政など、巨大なレガシーを抱えるあらゆる組織に応用できる成功パターンです。
金融系SIerが契約手続きの無駄を減らした事例
スクラムの効果は、開発スピードの向上に加えて、発注者と受注者の間の契約や管理にかかる手間を減らせる点にも表れます。ある金融系SIerでは、スクラムの導入によって契約手続きのやり直しに伴う管理工数を減らせました。地味ながら、投資対効果に直結する重要な成果です。
仕様変更のたびの契約やり直しを減らした事例
請負契約でウォーターフォール開発を行う場合、仕様が変わるたびに、契約の変更や追加見積もり、稟議が発生します。新規事業のように要件が頻繁に動く領域では、この契約手続きのやり直しだけで、膨大な管理工数とリードタイムを浪費してしまいます。
この金融系SIerは、スクラムと準委任契約を組み合わせて、仕様変更を「バックログの優先順位の入れ替え」として吸収し、契約そのものを変えずに進められる体制を作りました。その結果、仕様変更のたびに発生していた契約事務の手間が減り、現場は本来の開発に集中できるようになりました。
スクラムのバックログは、優先順位を機動的に並べ替えられる仕組みです。やるべきことの順番を変えるのに契約を結び直す必要がないため、変化の速い事業環境にそのまま追従できます。スピードという目立つ成果の裏で、こうした事務コストの削減が静かに効いている点は、稟議で投資を説明する際の有力な材料になります。
スピード要求にスクラムが応えたデータの裏づけ
こうした事例の背景には、企業がシステム開発に何を求めているかを示す調査があります。日本情報システム・ユーザー協会（JUAS）の2012年の調査では、企画段階で重視する項目として納期を挙げた割合が47%と最も高く、品質の29%、コストの24%を上回りました。つまり多くの企業は、コストや品質以上に「早く形にすること」を求めており、この納期重視の傾向は、スクラムが選ばれる理由を端的に説明しています。
スクラムは、動くものを短いサイクルで届ける手法であり、このスピード要求に正面から応えます。仕様を固めてから作るウォーターフォールは確実性が高いものの、市場投入までに時間がかかります。これに対してスクラムは、最も価値の高い機能から先にリリースし、市場の反応を見ながら改善できます。
新規事業やデジタルサービスのように、スピードが競争力に直結する領域で成功事例が多いのは、この特性によるものです。事例を読むときは、自社が納期・品質・コストのどれを最優先するのかを照らし合わせるとよいでしょう。
中大規模・分散拠点で分断を乗り越えた事例
スクラムは、少人数チームでこそ真価を発揮する手法です。実際、国内のアジャイル開発の約8割が8名以下のチームで、約半数が2〜4か月という短い期間で行われているとされます。
しかし現実には、複数チーム・複数拠点にまたがる中大規模のプロジェクトでスクラムを回さざるを得ない場面も多くあります。ここで分断をどう乗り越えたかという事例には、応用価値の高い工夫が詰まっています。
チーム間ローテーションで属人化を防いだ事例
複数チームでスクラムを回すと、各チームが担当範囲に閉じこもり、知識が属人化してしまいます。属人化は、スクラムに限らずあらゆる開発の敵ですが、複数チーム体制では特に深刻化しやすいリスクです。一人の優秀なエンジニアに依存した状態は、その人がいなくなった瞬間にプロジェクトを止めてしまいます。
ある中大規模プロジェクトでは、これを防ぐためにメンバーを定期的にチーム間でローテーションさせました。人が動くことで、特定のチームにしか分からないブラックボックスが減り、知識がプロジェクト全体で循環します。意図的に知識を分散させる取り組みは、短期的にはスピードが落ちて見えても、中長期ではプロジェクトの持続可能性を高めます。
大規模アジャイルの約7割が継続的インテグレーション（CI）を実施しているとされています。こうした技術的な仕組みと人のローテーションを組み合わせることで、分散環境でも品質と知識共有を保てます。この属人化リスクは失敗事例の典型パターンでもあるため、詳しくは『スクラム開発の失敗・課題・注意点・リスクについて』もあわせてご覧ください。
段階的な朝会で分散拠点の情報共有を整えた事例
分散拠点でデイリースクラム（朝会）を全員参加のまま行うと、時間がかかりすぎて本来の目的を見失いがちです。この事例では、まず各チーム内で朝会を行い、全体に関わる論点だけを、各チームの代表が集まる二段階目の朝会に持ち上げました。スクラム・オブ・スクラムズと呼ばれるこの仕組みにより、情報共有の階層を整理し、デイリースクラムが肥大化するのを防ぎました。
このように、スクラムのイベントは規模に応じて構造を工夫する余地があります。重要なのは、デイリースクラムの目的が「進捗報告」ではなく「スプリントゴール達成を阻む障害の早期発見と調整」にあるという原則を見失わないことです。
段階的な朝会は、その原則を守りながら分散環境に適応させた好例です。また、中大規模のスクラムでは、フレームワークを杓子定規に当てはめるのではなく、原則を保ったまま自社の構造に合わせて翻訳することが成功の条件になります。
まとめ
導入事例や成功事例を振り返ると、成果を出した組織に共通するのは、「スプリントやデイリースクラムというイベントを真似ること」ではなく、土台を整えてからフレームワークを回す姿勢です。その土台は、次の三つです。
- 準委任契約による人材調達
- クロスファンクショナルな自律チーム
- 経営層のコミットメント
四つの事例は、行政・金融・中大規模の現場で、それぞれ別の壁を別の工夫で越えています。
- 東京都：準委任調達と分単位の稼働管理で、行政の壁を越えた
- りそな：クロスファンクショナルチームとAPI基盤で、金融の制約を越えた
- 金融系SIer：契約手続きの無駄を減らした
- 中大規模の現場：ローテーションと段階的な朝会で、分断を越えた
日本のスクラム導入率は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を創業。