スクラム開発の導入を検討するとき、多くの担当者がまず知りたいのは「同じように不確実性の高い新規事業や基幹システムの刷新を抱えた企業が、実際にどうやってスクラムを回し、どんな成果を出したのか」という具体的な事例ではないでしょうか。スクラムは透明性・検査・適応という三本柱と、プロダクトオーナー・スクラムマスター・開発チームの三役割、スプリントを中心とした五つのイベントで構成される明確なフレームワークですが、教科書通りに導入しても自社の組織文化や契約形態に合わず形骸化してしまう、というケースが後を絶ちません。だからこそ、自社に近い立場の導入事例・成功事例こそが、投資判断と組織変革の精度を高めてくれます。
本記事は、スクラム開発の導入事例・開発事例・活用事例・成功事例を、発注企業や情報システム部門の視点から掘り下げる「事例特化」の解説です。東京都が準委任契約でスクラムを調達し稼働を分単位で管理した行政事例、りそなグループが勘定系に依存しないAPI基盤をクロスファンクショナルチームで構築した金融事例、中大規模・分散拠点でコミュニケーション分断を乗り越えた工夫まで、一次データとあわせて具体的に解説します。スクラムという具体的なフレームワークが現場でどう機能したのかを、固有名詞と数値で読み解いていきましょう。なお、スクラム開発の全体像をまだ把握していない方は、まずスクラム開発の完全ガイドから読むことをおすすめします。
東京都が準委任契約でスクラムを調達した行政事例
スクラム開発の事例の中でも、契約と調達の壁を行政が正面から乗り越えた点で示唆に富むのが、東京都の取り組みです。公共調達は仕様を固定して請負で発注するのが従来の常識でしたが、スクラムは「作るモノ」を事前に固定できないため、この調達モデルと根本的に相性が悪いという課題がありました。東京都はここに準委任契約という解を持ち込み、行政でもスクラムを成立させられることを示しました。
準委任調達と分単位の稼働管理で成果を出した事例
東京都は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はフルスクラッチ受託と準委任での伴走、外部スクラムマスターの提供を組み合わせ、契約・組織・技術の三方向からスクラムの定着を支援します。全体像の確認には、あらためて完全ガイドをご活用ください。
株式会社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を創業。