アジャイル開発

目次

• 概要
• アジャイル開発とは何か
• アジャイルソフトウェア開発宣言
• 12の原則を実務の言葉で読む
• ウォーターフォール開発
• ウォーターフォールとの違い
• 反復型開発、増分開発、アジャイルの違い
• アジャイルが向いている状況
• アジャイルが向かない状況
• スクラム
• スクラムの作り方
• カンバン
• エクストリームプログラミング
• XPの主要プラクティス
• ユーザーストーリーとバックログ
• 受け入れ条件と完了の定義
• 見積もりと計画
• プロダクトディスカバリーとデリバリー
• スプリントを設計する
• カンバンで流れを設計する
• テストと継続的インテグレーション
• リファクタリングと設計
• アジャイルとアーキテクチャ
• アジャイルとセキュリティ
• アジャイルと運用
• メトリクス
• アジャイルと組織文化
• スケーリングとアジャイルフレームワーク
• 複数チームでのアジャイル
• 契約・調達とアジャイル
• リモートチームでのアジャイル
• AI時代のアジャイル
• よくある失敗
• ケーススタディ
• 現代開発への接続
• 実務チェックリスト
• ミニ比較表
• よくある質問
• まとめ
• 参考文献

概要

変化を前提に、短い周期で学習する開発

アジャイル開発(Agile Software Development)は、最初にすべてを決め切るのではなく、短い周期で動くソフトウェアを作り、利用者や事業からのフィードバックを受けながら進める開発の考え方です。

アジャイルという言葉は便利ですが、便利な分だけ誤用されやすい言葉でもあります。短い会議を増やすこと、仕様変更をいつでも受けること、ドキュメントを書かないこと、設計を後回しにすることは、アジャイルそのものではありません。

この章では、アジャイルを「作業管理の儀式」ではなく、プロダクト、設計、実装、テスト、運用をつなぐフィードバックシステムとして扱います。

この章で重視すること

• アジャイルを「会議の型」ではなく、フィードバック設計として捉える
• スクラム、カンバン、XPの役割の違いを整理する
• ユーザー価値、受け入れ条件、完了の定義を具体化する
• テスト、リファクタリング、CIをアジャイルの中心に置く
• アジャイルを万能視せず、向き不向きを判断する
• 組織文化、契約、運用、セキュリティとの接続まで見る

先に全体像を見る

この図で大事なのは、開発が「実装」だけで閉じていないことです。価値仮説を立て、実装し、利用や運用の情報から学び、次の判断へ戻ります。アジャイル開発は、この循環を短く、見える形にするための考え方です。

アジャイル開発とは何か

アジャイル開発は、変化の多い状況で、ソフトウェアを少しずつ作りながら学ぶための開発アプローチです。

重要なのは、最初の計画を軽視することではありません。計画を「一度決めたら守る約束」ではなく、「現時点の最善の仮説」として扱います。仮説なので、実装、テスト、利用、運用から得た情報で更新されます。

アジャイルが解こうとしている問題

ソフトウェア開発では、次のような不確実性が重なります。

• 利用者が本当に必要としているものが最初から明確ではない
• 仕様を読んだときと、動くものを触ったときで判断が変わる
• 技術的な難しさが、実装して初めて見える
• 市場、競合、制度、組織の優先順位が変わる
• 運用して初めて、性能、障害、サポート負荷が分かる

アジャイルは、これらの不確実性をなくす方法ではありません。不確実性を早く表面化させ、判断を更新できるようにする方法です。

アジャイルの基本単位

アジャイルでは、大きな計画を小さな学習単位に分けます。

この単位が大きすぎると、学習が遅くなります。小さすぎると、作業の切り刻みになり、価値との接続が失われます。

アジャイルは関係の設計でもある

アジャイルは開発者だけの方法ではありません。プロダクトオーナー、デザイナー、QA、運用、セキュリティ、営業、サポート、顧客がどう関わるかの設計でもあります。

たとえば、開発チームが短い周期で作っても、リリース承認が3か月に1回なら学習は遅くなります。利用者の声がサポート部門に閉じているなら、バックログは価値から遠ざかります。障害対応の知見が設計に戻らないなら、同じ失敗を繰り返します。

アジャイル開発は、プロダクト開発と要件定義、テストとTDD、リファクタリング、オブザーバビリティとモニタリング、ソフトウェア工学と強くつながります。

アジャイルソフトウェア開発宣言

アジャイル開発の出発点としてよく参照されるのが、2001年に公開された「アジャイルソフトウェア開発宣言」です。これは、次の4つの価値を掲げています。

ここで誤解しやすいのは、右側が不要という意味ではないことです。ドキュメント、契約、計画、プロセスは必要です。ただし、価値を生むためには、左側をより重視するという判断軸です。

「個人と対話」は、プロセス不要という意味ではない

プロセスやツールは、チームの判断を助けるためにあります。チケット管理、CI、ドキュメント、レビュー手順は重要です。しかし、プロセスが現場の対話を妨げるなら、プロセスが目的化しています。

たとえば、仕様の疑問をチケットのコメントだけで何日も往復するより、関係者が10分話して例を合わせた方が早いことがあります。アジャイルの「対話」は雑談の推奨ではなく、曖昧さを早く解くための手段です。

「動くソフトウェア」は、ドキュメント不要という意味ではない

動くソフトウェアは、進捗と品質を確認する最も強い材料です。一方で、設計判断、運用手順、API仕様、セキュリティ上の前提は文書化しないとチームに残りません。

重要なのは、ドキュメントの量ではなく、意思決定と運用を支えるかどうかです。更新されない大きな仕様書より、具体例、受け入れ条件、ADR、API仕様、Runbookの方が価値を持つことがあります。

「顧客との協調」は、契約を軽視する意味ではない

契約は責任範囲や予算を明確にするために必要です。しかし、契約を守ることだけに集中すると、最終的に価値のないものを予定通り作る危険があります。

アジャイルでは、契約や合意を「変更不可能な壁」ではなく、「価値を届けるための枠組み」として扱います。固定価格契約でも、スコープを小さな単位に分け、優先順位を定期的に見直す設計は可能です。

「変化への対応」は、無計画という意味ではない

計画は必要です。むしろアジャイルでは、計画を何度も作り直します。違いは、計画を現実に合わせて更新することを前提にする点です。

計画を変えられることと、何でも途中で差し込めることは違います。変化を受け入れるには、優先順位、容量、影響範囲、リリースリスクを見える形にする必要があります。

12の原則を実務の言葉で読む

アジャイル宣言には、4つの価値に加えて12の原則があります。実務では、原文を暗記するより、どの判断に効くのかを理解する方が役に立ちます。

原則は独立していない

「頻繁に届ける」と「技術的卓越」はセットです。テストやCIがないまま頻繁に変更すれば、壊れる頻度も上がります。「変更を歓迎する」と「シンプルさ」もセットです。不要な機能や抽象化が多いほど、変更は重くなります。

アジャイルを実践するには、原則を単独の標語ではなく、相互に支え合う仕組みとして見る必要があります。

ウォーターフォール開発

ウォーターフォール開発(Waterfall Model)は、要件定義、設計、実装、テスト、リリースを大きな工程として順番に進める開発モデルです。水が上流から下流へ流れる比喩から、前工程の成果を次工程へ渡していく形として説明されます。

ウォーターフォールは、しばしばアジャイルの反対として語られますが、正確には「変化を抑え、前半で合意と設計を固めることに重心を置くモデル」です。要件が比較的安定している、契約や承認プロセスが重い、規制対応や外部調達が多い、といった状況では有効です。

一方で、利用者の反応を見ないと正解が分からないプロダクトでは、後半になってから大きな認識違いが見つかる危険があります。そのため現代の実務では、全体計画や承認はウォーターフォール的に扱い、実装や検証はアジャイル的に小さく回すなど、両者を組み合わせることも多くあります。

ウォーターフォールが悪いのではない

ウォーターフォールが問題になるのは、未知の多い仕事を既知の仕事として扱うときです。逆に、次のような場合は、順序立てた工程管理が意味を持ちます。

• 外部調達や契約上、成果物の合意が必要
• 規制や監査のため、承認記録を厳密に残す必要がある
• 変更コストが非常に高い物理設備やハードウェアと強く結びつく
• 要件が安定しており、利用者の行動変化も小さい
• 依存関係が多く、事前の調整を怠ると全体が止まる

アジャイルとウォーターフォールの議論では、「どちらが正しいか」より「不確実性をどこで扱うか」が重要です。

ウォーターフォールとの違い

ウォーターフォールは、要件定義、設計、実装、テスト、リリースを大きな段階として順に進める考え方です。アジャイルは、これらの活動を小さな単位で何度も回します。

実務では、完全なウォーターフォールか完全なアジャイルかではなく、制約に応じて混ざります。重要なのは、どこを固定し、どこを学習可能にするかです。

ハイブリッドの考え方

大規模な組織では、予算、契約、監査、リリース承認は年度計画に結びつくことがあります。その場合でも、すべてを大きな工程に閉じ込める必要はありません。

たとえば、次のように分けられます。

• 予算と大きな目的は四半期単位で合意する
• ユーザーストーリーはスプリント単位で具体化する
• アーキテクチャ上の大きな制約は早めに検証する
• UIや業務フローはプロトタイプで利用者に確認する
• リリースはFeature Flagで段階的に公開する

このように、固定すべきものと学習すべきものを分けると、ウォーターフォール的な制約の中でもアジャイルの利点を取り込めます。

反復型開発、増分開発、アジャイルの違い

アジャイルを理解するには、反復型開発、増分開発との違いを押さえると分かりやすくなります。

反復していても、利用者の学習に接続していなければアジャイルとは言いにくいです。増分で作っていても、最後まで公開せず、価値検証が後半に偏るなら、学習は遅くなります。

アジャイルでは、反復と増分を「価値の検証」に結びつけます。

アジャイルが向いている状況

アジャイルは、不確実性が高く、途中で学習できる状況に向いています。

• 利用者の反応を見ながら作りたい
• 要件が変わる可能性が高い
• リリースを小さく刻める
• チームと顧客が継続的に対話できる
• テストやCIで変更を安全に確認できる
• プロダクトの価値が仮説検証に依存している
• 競合や市場の変化が速い

たとえば、新規プロダクト、SaaS、社内業務改善、UI/UX改善、APIの段階的改善、データ活用基盤、LLMアプリケーションなどは相性がよいです。

向いているかを判断する問い

次の問いに多く当てはまるほど、アジャイルの価値は出やすくなります。

• 最初の要件が外れる可能性は高いか
• 利用者に早く見せられる単位はあるか
• リリース後のデータや声を取れるか
• 優先順位を決める責任者はいるか
• チームは自動テストやCIを整えられるか
• 途中で設計を改善する時間を取れるか
• 作ったものを捨てる判断ができるか

アジャイルは、変化を受け止めるための方法です。変化から学べない環境では、形だけ導入しても効果は薄くなります。

アジャイルが向かない状況

アジャイルにも向かない状況があります。

• 法規制や契約上、成果物と承認手順が強く固定されている
• 物理的な製造や調達が中心で、リリースを細かく刻めない
• 顧客や利用者から継続的なフィードバックを得られない
• チームにテストや設計改善の技術的基盤がない
• 優先順位を決める人が不在
• 組織が失敗や学習を許容しない
• 「短期で仕様変更を押し込む口実」として使われている

特に最後は危険です。アジャイルは無計画に変更を受け入れることではありません。変更に耐えるための優先順位、技術的規律、チームの合意が必要です。

向かない状況でも使える部分

全面的なアジャイルが難しくても、一部の考え方は役に立ちます。

• 大きな要件を例と受け入れ条件に分解する
• 早い段階でプロトタイプを確認する
• リスクの高い技術要素を先に検証する
• テスト自動化とCIを導入する
• 定期的なふりかえりでプロセスを改善する
• 完了の定義を明確にする

アジャイルを「全部かゼロか」で捉える必要はありません。制約の中で、フィードバックを早められる場所を探す方が実務的です。

スクラム

スクラム(Scrum)は、アジャイル開発で最も広く使われるフレームワークの一つです。短い期間であるスプリントを単位に、計画、実装、レビュー、ふりかえりを回します。

Scrum Guide 2020では、スクラムを複雑な問題に取り組むための軽量なフレームワークとして定義しています。スクラムは詳細な作業手順ではなく、透明性、検査、適応を働かせるための最小限の構造です。

スクラムの経験主義

スクラムは、経験主義に基づきます。つまり、知識は経験から得られ、判断は観察された事実に基づくという考え方です。

透明性がないと検査できません。検査しても変えられなければ適応できません。スクラムのイベントは、これらを定期的に起こすためにあります。

役割

Scrum Guide 2020では、スクラムチームは1つのチームであり、プロダクトオーナー、スクラムマスター、開発者という3つの責任を持ちます。

ここでいう開発者は、プログラマだけではありません。設計、実装、テスト、分析、運用など、インクリメントを作るために必要な専門性を持つ人を含みます。

イベント

デイリースクラムは進捗報告会ではありません。目的は、スプリントゴールに向けて次の1日をどう調整するかを決めることです。

成果物とコミットメント

プロダクトバックログは単なるタスクリストではありません。価値、リスク、学習、依存関係を踏まえて順序づけられた、プロダクトの意思決定リストです。

スクラムの作り方

スクラムを始めるとき、イベント名だけを導入すると失敗しやすくなります。先に、何を透明にし、何を検査し、何を変えられるようにするのかを決めます。

最小構成

最小限、次の状態を作るとスクラムとして機能しやすくなります。

• プロダクトゴールがある
• プロダクトオーナーが優先順位に責任を持つ
• バックログ項目が価値と受け入れ条件を持つ
• スプリントゴールが毎回ある
• Definition of Doneが明文化されている
• スプリントレビューで関係者からフィードバックを得る
• レトロスペクティブで改善項目を決め、次に試す

スプリントゴールの作り方

スプリントゴールは「チケットを全部終わらせる」では弱いです。なぜ今回のスプリントが必要かを一文で表します。

悪い例:

• 検索機能の実装
• チケットA、B、Cを完了する
• バックログを消化する

よい例:

• サポート担当者が注文履歴を顧客名で検索できる状態にする
• 新規登録の離脱原因を計測できるようにする
• 請求処理の手戻りを減らすため、例外ケースを画面上で確認できるようにする

スプリントゴールがあると、途中で想定外の問題が出たときに、何を守り、何を削るかを判断しやすくなります。

スクラムが形骸化する兆候

• デイリーがマネージャへの進捗報告になっている
• スプリントレビューで実際に動くものを見せない
• レトロスペクティブの改善が次回に反映されない
• プロダクトオーナーが優先順位を決められない
• Definition of Doneがなく、品質が人によって違う
• スプリントごとに大量の未完了作業が持ち越される

形骸化している場合は、イベントを増やすより、透明性と意思決定の流れを直す方が効果的です。

カンバン

カンバン(Kanban)は、作業の流れを可視化し、仕掛かり作業を制限しながら改善する方法です。

カンバンでは、どれだけ作業を始めたかより、どれだけ完了させたかを見ます。仕掛かり作業(WIP: Work in Progress)を減らすことで、待ち時間、手戻り、レビュー滞留が見えやすくなります。

カンバンの基本要素

Kanban Guideでは、作業の流れを定義し、WIPを制御し、明示的なポリシーを置き、サービスレベル期待(SLE: Service Level Expectation)を扱うことを重視します。

カンバンのメトリクス

代表的なフローメトリクスは次の4つです。

スクラムとカンバンの使い分け

スクラムが時間箱で区切るのに対し、カンバンは流れを継続的に改善する色が強いです。運用、保守、問い合わせ対応、プラットフォームチームなど、割り込みが多いチームと相性がよいです。

スクラムとカンバンは排他的ではありません。スクラムチームがボード上でWIP制限を使うこともありますし、カンバンチームが定期的なレビューやふりかえりを持つこともあります。

エクストリームプログラミング

エクストリームプログラミング(XP: Extreme Programming)は、Kent Beckらによって整理されたアジャイル開発手法です。名前の通り、よい実践を「極端なほど徹底する」ことを狙います。

XPの特徴は、アジャイルの中でも技術的プラクティスを強く扱う点です。短いフィードバック、継続的な設計改善、テスト自動化、ペアプログラミング、顧客との密な協調を重視します。

XPは、YAGNI原則、KISS原則、リファクタリング、テストとTDDと深くつながります。

XPが重視する価値

XPでは、コミュニケーション、シンプルさ、フィードバック、勇気、尊重といった価値が重視されます。

XPは「プログラマ向けのアジャイル」と見られることがありますが、実際にはビジネス側との協調も重要です。技術的規律だけでなく、何を作るかを小さく決め続ける仕組みが必要です。

XPの主要プラクティス

XPには多くのプラクティスがあります。代表的なものを整理します。

XPで大事なのは、これらが互いに支え合うことです。リファクタリングにはテストが必要で、頻繁な統合にはCIが必要で、シンプルな設計にはYAGNI原則が必要です。一つだけ取り出しても効果は限定的です。

ペアプログラミングとモブプログラミング

ペアプログラミングは、2人で同じ問題に取り組む方法です。1人がコードを書き、もう1人が設計、見落とし、テスト、次の一手を見ます。役割は入れ替えます。

モブプログラミングは、複数人で同じ作業を進める方法です。難しい設計判断、障害対応、複雑なリファクタリングでは、知識共有と意思決定が速くなることがあります。

どちらも常時行う必要はありません。難しい作業、属人化した領域、レビューで手戻りが多い領域に使うと効果が出やすいです。

共同所有とコードレビュー

共同所有は、誰か一人だけが触れるコードを減らす考え方です。共同所有があると、ボトルネックや属人化は減ります。ただし、無秩序に誰でも変更してよいという意味ではありません。

共同所有を支えるには、次の土台が必要です。

• 自動テスト
• コーディング規約
• レビュー
• CI
• 設計方針の共有
• 変更履歴の分かるコミット

共同所有は、品質責任を薄めることではなく、品質責任をチーム全体に広げることです。

ユーザーストーリーとバックログ

アジャイルでは、実装単位をユーザー価値に結びつけて扱うため、ユーザーストーリーがよく使われます。

利用者として、
目的の資料を検索したい。
なぜなら、問い合わせ対応の時間を短くしたいから。

ユーザーストーリーは仕様書の代替ではありません。会話の入口です。実際には、受け入れ条件、非機能要件、例外処理、権限、監査、運用の観点を補う必要があります。

よいユーザーストーリーの条件

よく使われる観点にINVESTがあります。

すべてを完璧に満たす必要はありません。ただし、ストーリーが大きすぎる、価値が曖昧、検証不能である場合は、バックログの上位に置く前に分割や具体化が必要です。

バックログは作業リストではない

プロダクトバックログは、単なる作業リストではなく、価値の仮説と優先順位を並べたものです。上位ほど具体的で、下位ほど粗くてよいです。

バックログに入るものは機能だけではありません。

• ユーザー価値を持つ機能
• 技術的リスクの検証
• セキュリティ対応
• 性能改善
• 運用改善
• 障害再発防止
• データ計測
• 法務、監査、アクセシビリティ対応

ただし、何でも入れるとバックログは倉庫になります。上位に置くものは、なぜ今必要か、何が分かれば十分か、どのように完了を判断するかを明確にします。

ストーリー分割の考え方

ストーリーは、技術層で分けるより、価値の薄い縦切りで分ける方が学習しやすくなります。

悪い分け方:

• DBテーブルを作る
• APIを作る
• 画面を作る
• テストを書く

よい分け方:

• 注文番号で検索できる
• 顧客名で検索できる
• 日付範囲で検索できる
• 検索結果をCSVで出力できる

技術的には小さくなくても、利用者に見せられる単位で切ると、フィードバックが早くなります。

受け入れ条件と完了の定義

受け入れ条件(Acceptance Criteria)は、個別のストーリーが期待通りかを判断する条件です。Definition of Doneは、すべての作業に共通する完了基準です。

この2つを混同すると、品質が不安定になります。受け入れ条件が満たされても、テスト、レビュー、セキュリティ、運用準備が不足していれば、完了とは言えません。

受け入れ条件の書き方

受け入れ条件は、具体例で書くと認識が揃いやすくなります。

Scenario: 顧客名で注文履歴を検索する
  Given 顧客「山田太郎」の注文が3件存在する
  When サポート担当者が「山田」で検索する
  Then 検索結果に3件の注文が表示される

この形式にこだわる必要はありません。大事なのは、開発者、QA、プロダクトオーナー、利用者が同じ例を見て完了を判断できることです。

完了の定義の例

チームによって異なりますが、Webアプリケーションなら次のような項目が考えられます。

• 受け入れ条件を満たしている
• 単体テスト、統合テストが通っている
• 主要なエラーケースが考慮されている
• レビュー済みである
• ログ、メトリクス、アラートの必要性を確認している
• セキュリティ上の入力検証や権限を確認している
• ドキュメントやRunbookが必要なら更新している
• Feature Flagやロールバック方針が必要なら用意している

Definition of Doneは、理想を全部詰め込むリストではありません。チームが毎回守れる品質基準です。守れないなら、項目を減らすか、守れるように自動化します。

見積もりと計画

アジャイルの見積もりは、未来を正確に予言するためではなく、会話と優先順位づけのためにあります。

よく使われる方法:

• ストーリーポイント
• プランニングポーカー
• Tシャツサイズ
• 相対見積もり
• スループットやサイクルタイムによる予測

見積もりで重要なのは、数字そのものより、なぜその大きさに見えるのかを話すことです。不確実性、依存関係、技術的リスクが見えるなら、見積もりは成功しています。

ストーリーポイントの使い方

ストーリーポイントは、時間ではなく相対的な大きさを表します。作業量、複雑さ、不確実性をまとめた目安です。

ただし、ストーリーポイントには注意が必要です。

• チーム間比較に使わない
• 個人評価に使わない
• ベロシティを目標にしない
• いつまでも細かく議論しない
• 大きすぎるストーリーは分割する

ストーリーポイントが有効なのは、チーム内の計画と会話に使う場合です。管理指標として使うと、数字が目的化します。

見積もらない開発という考え方

見積もりに時間をかけすぎるチームでは、ストーリーを小さくそろえ、完了数やサイクルタイムから予測する考え方もあります。これをNo Estimatesと呼ぶことがあります。

見積もりを完全になくすかどうかより、予測に必要な粒度まで作業を小さくできているかが重要です。大きな不確実性が残っているなら、先にスパイクやプロトタイプで学ぶ方がよい場合もあります。

計画の階層

アジャイルでも計画はあります。ただし、詳細度を階層で分けます。

上位の計画ほど目的を重視し、下位の計画ほど具体的な作業を扱います。

プロダクトディスカバリーとデリバリー

アジャイル開発では、作ることだけでなく、何を作るべきかを学ぶことが重要です。ここで、ディスカバリーとデリバリーを分けて考えると整理しやすくなります。

ディスカバリーだけでは価値は届きません。デリバリーだけでは、間違ったものを速く作る危険があります。

二重トラックアジャイル

実務では、ディスカバリーとデリバリーを完全に直列にすると遅くなります。そこで、次に作る候補を先に探索しながら、現在合意したものを実装する二重トラックの形が使われることがあります。

• ディスカバリートラック: 問題、仮説、プロトタイプ、ユーザー検証
• デリバリートラック: 実装、テスト、リリース、運用

重要なのは、ディスカバリーを「上流工程」として固定しないことです。リリース後の学習が次のディスカバリーに戻る必要があります。

スプリントを設計する

スプリントは、短い期間に作業を詰め込む箱ではありません。価値あるインクリメントを作り、検査し、適応するための時間枠です。

スプリントプランニング

スプリントプランニングでは、次の3つを扱います。

• なぜこのスプリントが価値を持つのか
• 何を選ぶのか
• どのように作るのか

スプリントゴールがないと、チケットの寄せ集めになります。スプリントゴールがあると、途中で予定が崩れても、何を優先するかを判断できます。

デイリースクラム

デイリースクラムでは、昨日やったことの報告より、スプリントゴールに向けた調整を重視します。

よい問い:

• スプリントゴールに対して何が詰まっているか
• 今日、レビュー待ちや依存関係をどう動かすか
• 予定より大きい作業は分割できるか
• 品質やテストでリスクが出ていないか

悪い状態:

• 参加者がマネージャに順番に報告する
• 誰も計画を変えない
• ブロッカーが毎日同じ
• レビューやテストの滞留を見ない

スプリントレビュー

スプリントレビューはデモ会ではありません。作ったものを材料に、プロダクトの方向を検査する場です。

よいレビューでは、次の情報が出ます。

• 何が完成したか
• 何が未完了か
• 利用者や関係者はどう反応したか
• 次に優先すべきことは何か
• リスクや前提は変わったか

レビューで拍手だけして終わるなら、フィードバックの設計が足りません。

レトロスペクティブ

レトロスペクティブは反省会ではありません。次のスプリントで試す改善を決める場です。

扱うテーマ:

• 作業の流れ
• コミュニケーション
• テストやレビューの負荷
• 障害や手戻り
• 技術的負債
• 心理的安全性
• 外部依存

改善案は大きすぎると続きません。次のスプリントで試せる小さな実験にします。

カンバンで流れを設計する

カンバンを使うときは、ボードを作るだけでは不十分です。列、WIP制限、完了条件、例外ルールを明確にします。

列の設計

列は組織図ではなく、作業の状態を表します。

悪い例:

• 企画
• 開発
• QA
• 運用

この分け方だと、部門間の受け渡しは見えますが、作業がなぜ止まっているかが見えにくくなります。

よい例:

• 未着手
• 準備完了
• 実装中
• レビュー待ち
• 修正中
• リリース待ち
• 完了

チームの目的は、列を増やすことではなく、流れを見えるようにすることです。

WIP制限

WIP制限は、チームに「もっと働け」と言うためのものではありません。仕事を始めすぎて完了が遅くなる状態を防ぐためのものです。

たとえば、レビュー待ちが5件あるのに新しい実装を始めると、完了は増えません。レビュー待ちを解消した方が、リードタイムは短くなります。

明示的なポリシー

明示的なポリシーとは、作業が次の状態に進む条件です。

例:

• 「準備完了」に入るには受け入れ条件が必要
• 「レビュー待ち」に入るにはCIが通っている必要がある
• 「完了」に入るにはリリース済み、またはFeature Flagで無効化可能である必要がある
• 緊急障害は通常WIPとは別枠にするが、翌営業日にふりかえる

ポリシーが暗黙だと、チームメンバーごとに完了の感覚がずれます。

テストと継続的インテグレーション

アジャイル開発では、変更を頻繁に行うため、テストとCIが重要になります。テストがないアジャイルは、変更を受け入れるほど壊れやすくなります。

テストピラミッド

TDDはXPの中核的な実践です。テストを先に書くことで、仕様の確認だけでなく、設計の使いやすさも早く検証できます。

CIは、変更を小さく統合し続けるための仕組みです。テスト、静的解析、フォーマット、ビルドを自動化することで、チームは安心して変更できます。

テストがないチームで何から始めるか

既存システムでは、最初から理想的なテストピラミッドを作るのは難しいです。その場合は、壊れると困る場所から始めます。

• 主要なユースケースの統合テスト
• 重要なドメインロジックの単体テスト
• バグ修正時の再発防止テスト
• 認証、権限、課金、データ削除のテスト
• デプロイ前のスモークテスト

アジャイルに必要なのは、完璧なテストではなく、変更のたびに主要な不安を減らす安全網です。

CIで見るべきもの

CIは「テストを実行する場所」だけではありません。変更の品質を早く可視化する場所です。

• ビルド
• 単体テスト
• 統合テスト
• 静的解析
• フォーマット
• 型チェック
• セキュリティスキャン
• 依存関係チェック
• パッケージ作成

CIが遅すぎると、開発者は結果を待たなくなります。頻繁な統合を支えるには、速いフィードバックと、必要に応じた段階的なチェックが必要です。

リファクタリングと設計

アジャイル開発では、設計をしないのではなく、設計を継続的に行います。最初に全体を固定する代わりに、変更のたびに構造を整えます。

リファクタリングが機能する条件:

• 自動テストがある
• 変更が小さい
• コードレビューが機能している
• 設計上の臭いを言語化できる
• 技術的負債を見える形で扱う

設計を後回しにするだけでは、アジャイルではなく場当たり開発になります。シンプルな設計、テスト、リファクタリングをセットで扱うことが重要です。

継続的設計

継続的設計とは、最初の設計を軽視することではありません。初期設計で全体の方向を決め、実装から得た学びで設計を更新することです。

初期に考えるべきこと:

• 境界づけられたコンテキスト
• データの所有権
• 認証と認可
• 監査ログ
• 外部システム連携
• スケーリングの見通し
• 失敗時のふるまい

継続的に見直すべきこと:

• 重複
• 責務の肥大化
• テストしにくい設計
• 依存方向
• データモデルの歪み
• 運用時の観測性

アジャイルな設計は、無設計ではなく、変化に合わせて構造を育てる設計です。

アジャイルとアーキテクチャ

アジャイルとアーキテクチャは対立しません。むしろ、アーキテクチャが重すぎると変更できず、軽すぎると変更のたびに壊れます。

最初に決めるべきアーキテクチャ

すべてを詳細に決める必要はありませんが、後から変えにくいものは早めに検討します。

• データストアの基本方針
• 外部APIとの契約
• 認証方式
• モジュール境界
• デプロイ単位
• 監査やログの要件
• マルチテナントの有無
• 可用性と復旧の目標

これらは、ユーザーストーリーの裏側で後から大きな手戻りを生みやすい領域です。

アーキテクチャスパイク

不確実な技術要素は、スパイクとして短く検証します。スパイクは本番コードを作る活動ではなく、判断材料を得る活動です。

スパイクの完了条件:

• 何を知りたいかが明確
• 期間が固定されている
• 結果が文書化される
• 採用、延期、却下の判断につながる
• 必要なら捨てられる

スパイクを通常開発に混ぜると、実験コードがそのまま本番化しがちです。学習と実装を区別します。

アジャイルとセキュリティ

セキュリティは最後に診断するだけでは遅くなります。アジャイルでは、セキュリティも小さな単位で設計、実装、検証に組み込みます。

セキュリティをバックログに入れる

セキュリティ作業は、独立した後工程ではなく、バックログとDefinition of Doneに入れます。

• 認証と認可の受け入れ条件を書く
• 入力検証をテストする
• 監査ログの必要性を確認する
• 秘密情報の扱いをレビューする
• 依存関係の脆弱性チェックをCIに入れる
• 脅威モデリングを重要機能の前に行う

軽量な脅威モデリング

毎回重い文書を作る必要はありません。重要なストーリーでは、次の問いを確認します。

• 誰がこの機能を悪用できるか
• 権限を越えて見える情報はないか
• 入力値は信頼できるか
• ログに秘密情報が出ないか
• 失敗時に安全側へ倒れるか
• 監査や追跡が必要か

アジャイルなセキュリティは、最後にまとめて止めるのではなく、早めに小さくリスクを減らすことです。

アジャイルと運用

リリースして終わりではありません。実際の価値は、利用され、運用され、問題が観測され、改善されることで分かります。

運用から学ぶ

運用で得られる情報:

• どの機能が使われているか
• どこでエラーが起きているか
• レイテンシがどの程度か
• 問い合わせがどこに集中しているか
• 障害時に復旧できるか
• ログやメトリクスで原因を追えるか

これらは次のバックログに戻すべき情報です。運用と開発が切り離されると、アジャイルの学習ループは途中で切れます。

フィーチャーフラグと段階的リリース

Feature Flagを使うと、デプロイと公開を分けられます。

• 一部ユーザーにだけ公開する
• 問題があればすぐ無効化する
• A/Bテストを行う
• 大きな変更を小さくマージする
• リリース日とデプロイ日を分ける

ただし、Feature Flagは増えすぎると複雑になります。期限、所有者、削除タイミングを管理します。

メトリクス

アジャイルのメトリクスは、チームを監視するためではなく、学習と改善のために使います。

よいメトリクスの条件

• 行動を悪く歪めにくい
• チーム自身が改善に使える
• 価値や流れに関係する
• 単独で評価しない
• 定性的な情報と合わせて読む

代表的な指標

ベロシティの扱い

ベロシティは、チームが過去にどれくらいのストーリーポイントを完了したかを見る参考値です。計画には使えますが、評価指標にしてはいけません。

ベロシティを目標にすると、次のような問題が起きます。

• ポイントが膨らむ
• 小さく見えるが価値の低い作業が増える
• 品質改善が後回しになる
• チーム間比較が始まる
• 予測のための数字が政治的な数字になる

進捗を知りたいなら、ベロシティだけでなく、リリースされた価値、リードタイム、品質、顧客反応を合わせて見ます。

メトリクスを改善ループにする

Scrum Guideは、透明性、検査、適応をスクラムの中心に置いています。メトリクスも同じで、数字を集めるだけでは意味がありません。現状を見えるようにし、原因を話し、次の実験へつなげることで初めて改善に効きます。

よいメトリクスは、チームに「次に何を試すか」を考えさせます。数字が悪いこと自体より、数字を見ても行動が変わらないことの方が危険です。

アジャイルと組織文化

アジャイルはチームの文化にも強く依存します。

• 失敗から学べる心理的安全性
• 優先順位を明確にするプロダクト責任
• 開発者が品質に責任を持てる裁量
• 顧客や利用者との継続的な対話
• 技術的負債を隠さず扱う透明性
• 部門間の受け渡しではなく、共通目標で動く関係

アジャイルの導入でよく起きる失敗は、会議やボードだけを導入し、意思決定や品質への責任を変えないことです。形式だけ真似ても、フィードバックは速くなりません。

心理的安全性と責任

心理的安全性は、何をしても許されるという意味ではありません。問題、リスク、失敗、疑問を早く出せる状態です。

アジャイルでは、悪いニュースが早く出るほど対応しやすくなります。逆に、失敗を責める文化では、問題は隠れ、後半に大きくなって現れます。

マネジメントの役割

アジャイルな組織でのマネジメントは、細かい作業指示より、次のような支援に重心を置きます。

• 目的と優先順位を明確にする
• チームが意思決定できる範囲を決める
• 外部依存や組織障害を取り除く
• 技術的負債や品質改善の時間を守る
• 学習のための情報をチームに返す
• 短期成果と持続可能性のバランスを取る

スケーリングとアジャイルフレームワーク

単一チーム(5-10人)のアジャイルは比較的単純です。複数チーム、複数部門では、新しい問題が出ます。

複数チーム間の依存関係

課題:

• チーム A の出力がチーム B の入力になる場合、どう同期するか
• リリース計画をどう調整するか
• 共通ライブラリやプラットフォームの変更をどう波及させるか
• チーム間のコミュニケーションオーバーヘッド

パターン:

どれが「正解」ではなく、組織の規模、分散度、技術的結合度に応じて選びます。

依存関係の管理

複数チームの依存が多すぎる場合、アジャイルの反復性は損なわれます。

対策:

• API 契約で疎結合にする
• 非同期通信を活用する
• リリーススケジュールを共有し、チームは独立してスプリント
• feature flag で結合度を下げる
• 技術的に独立した領域に分ける

組織スケールでのメトリクス

複数チームでは、個別ベロシティより「プロダクト全体の進捗」「品質」「リリース頻度」を見る方が重要になります。

ポートフォリオレベルの指標:

• リリース頻度(毎週、毎月など)
• lead time(要件からリリースまで)
• デプロイ頻度と失敗率(DORA metrics)
• 技術的負債の増加率
• チーム間の遅延・ブロッカー

複数チームでのアジャイル

チームが増えると、アジャイルは難しくなります。人数が増えるほど、コミュニケーション、依存関係、リリース調整、設計方針の共有が重くなるからです。

スケール時の典型的な問題

• チーム間の依存で待ちが増える
• バックログの優先順位が部門ごとに分裂する
• 共通基盤チームがボトルネックになる
• リリースが大きくなり、頻度が落ちる
• アーキテクチャの境界が曖昧で変更が衝突する
• 会議が増え、意思決定が遅くなる

先にチーム境界を見る

複数チームのアジャイルでは、フレームワークを導入する前に、チーム境界を見直します。

• 1チームで価値を届けられるか
• データやAPIの所有権は明確か
• チーム間の依存は減らせるか
• 共通基盤はセルフサービス化できるか
• リリース単位は分離できるか

アジャイルを大規模化するというより、依存関係を減らし、小さなチームが自律的に価値を届けられる構造を作ることが重要です。

契約・調達とアジャイル

エンタープライズやシステム統合では、固定価格契約、受託開発、SLA が重なり、自由なアジャイル適用が難しくなります。

契約形態の工夫

従来の固定価格・固定期間:

要件確定 → 設計 → 開発 → テスト → リリース
最初にすべて決める

アジャイル契約:

スコープ: 大枠を決める(外枠)
予算: 人月か四半期の固定
変更: 優先順位の入れ替えで対応(スコープ内)
品質: 明確な受け入れ条件と Definition of Done

重要なのは「スコープと品質は固定」「優先順位は変動可能」という設計です。

ハイブリッドの実例

パターン:

• 全体計画は四半期ウォーターフォール(予算・契約上の必要)
• 実装はスクラム(4週間スプリント)
• リリースは段階的フェーズドロールアウト
• 監査・承認ログは後付けで記録

メリット:

• 企業のガバナンス要件を満たす
• 短いスプリントで学習できる
• 重大な設計変更は四半期の境界で吸収

変更管理の仕組み

契約が厳密な場合は、変更要求を明示的に扱う必要があります。

変更リクエストプロセス:

1. 新機能要望や仕様変更が出る
2. 既存バックログのどの項目を削減するか協議
3. 優先度、工数見積もり、期待される効果を記載
4. ステアリングコミッティが承認/却下
5. 承認なら次スプリントに含める

料金:

• スコープ内の優先順位変更: 追加費用なし
• 範囲外の新規要求: 追加契約

契約下でのメトリクス

契約が厳密な場合、透明性が信頼を生みます。

毎スプリント報告:

• 完了した機能リスト(Definition of Done 済み)
• 品質メトリクス(テストカバレッジ、バグ数)
• 次スプリントのプラン
• リスクや遅延の早期警告

四半期報告:

• リリース可能な増分
• 技術的負債の状況
• 予算使用率
• 次期計画の提案

SLA が厳密な場合は「99% uptime を達成する」を成功指標にし、達成状況を継続的に報告します。

リモートチームでのアジャイル

リモート環境では、対面の偶然の会話が減るため、情報共有を意図的に設計する必要があります。

リモートで弱くなりやすいもの

• 曖昧な仕様の早期解消
• 設計意図の共有
• 困っている人の発見
• 雑な相談
• ふりかえりでの本音
• 新しいメンバーのオンボーディング

リモートで強くするべきもの

• 短い設計メモ
• 受け入れ条件
• 非同期レビュー
• ADR
• 録画やスクリーンショット付きの説明
• ペア作業の時間
• チャットではなく短い同期会話に切り替える判断

リモートでは、文書化が重要になります。ただし、文書だけで済ませるのではなく、文書で前提をそろえ、必要なところだけ対話で解くのが実務的です。

AI時代のアジャイル

生成AIやAIエージェントによって、実装、テスト、調査、ドキュメント作成の速度は上がります。しかし、速く作れるほど、何を作るべきか、どう検証するか、品質をどう守るかが重要になります。

AIで変わること

• プロトタイプを短時間で作れる
• テストケースのたたき台を作れる
• 既存コードの理解を支援できる
• ドキュメントや仕様の草案を作れる
• リファクタリング案を出せる

AIで変わらないこと

• 利用者の問題を理解する必要
• 優先順位を決める責任
• セキュリティや品質の説明責任
• 運用で起きたことから学ぶ必要
• チーム内の合意形成

AIはフィードバックループを速くできますが、判断そのものを不要にするわけではありません。むしろ、仮説検証と品質基準が弱いチームでは、間違ったものを高速に増やす危険があります。

LLMアプリケーションの開発スプリント

LLM ベースのアプリケーション(Chatbot、RAG、エージェント)では、従来のアジャイルが部分的に変わります。

特有の課題:

• プロンプトの「完璧」な仕様を先に定義できない(試行錯誤が本質)
• テストが定量的でない(出力の品質判定が主観的)
• バージョンアップでもモデル変更でユーザーの体験が変わる(Hyrum’s Law の AI 版)
• 安全性、バイアス、ハルシネーション対策が後付けではコスト高

適応:

LLM アプリケーションのアジャイルでは:

• プロンプトを実装の中心に見る(コード以上にプロンプトが重要)
• キーボード入力のテストケース集 と期待出力例を作る
• 実運用で「ユーザーが何に困ったか」をログに残す
• モデルのアップデート時には backward compatibility の検証が必須
• ハルシネーション検出とフォールバック を Definition of Done に入れる

アジャイルと AI 倫理

AI を使った機能では、アジャイルの価値観と倫理的責任が衝突することがあります。

早く学習する vs 害を早く検出して止める

短いスプリントで「とにかく出して反応を見よう」がお勧めできない領域:

• 信用スコア、採用支援、医療診断(不公正なバイアスの社会的害)
• 生成コンテンツ(著作権侵害、偽情報の急速拡大)
• 監視・制御機能(プライバシー侵害、差別)

こうした領域では、「出してから修正」でなく、「社会的影響を事前に検証」してからリリースする judgement が必要です。

AI 時代のアジャイルメトリクス

従来のベロシティ、バーンダウン、サイクルタイムに加え、LLM アプリケーション開発では新しい指標が必要になります。

これらは Goodhart’s Law の対象になりやすいため、複数指標を組み合わせることが重要です。

よくある失敗

会議だけスクラムになる

デイリー、レビュー、レトロスペクティブはあるが、リリース可能な成果物が増えない状態です。スクラムの目的は会議を増やすことではなく、透明性、検査、適応を回すことです。

対策:

• スプリントゴールを明確にする
• レビューで動くものを見せる
• 未完了の理由をふりかえる
• Definition of Doneを作る

変更を何でも受け入れる

変化への対応は、すべての要求を即座に受けることではありません。バックログで優先順位を管理し、何をやらないかを決める必要があります。

対策:

• 変更要求をバックログに入れる
• 現在のスプリントゴールへの影響を見る
• 追加するなら何をやめるかを決める
• 緊急差し込みのルールを明確にする

テストがないまま短期反復する

テストがない状態で反復を速くすると、壊す速度も上がります。アジャイルの速度は、技術的安全網とセットです。

対策:

• 重要経路のテストから始める
• バグ修正時に再発防止テストを書く
• CIを必須にする
• リファクタリングを小さく行う

ベロシティを目標にする

ベロシティは計画の参考値であり、評価指標ではありません。目標にするとストーリーポイントが膨張し、グッドハートの法則が発動します。

対策:

• チーム間比較に使わない
• 顧客価値や品質指標も見る
• 見積もりよりフロー改善に注目する
• 完了の定義を守る

技術的負債を後回しにする

短い周期で作るほど、設計改善を日常に組み込む必要があります。負債返済を特別なイベントにすると、たいてい先送りされます。

対策:

• リファクタリングを通常作業に含める
• 負債をバックログで可視化する
• 障害や遅延と負債を関連づける
• 大きな負債は段階的に返済する

プロダクトオーナーが不在

優先順位を決める人がいないと、チームは声の大きい要求や緊急対応に流されます。

対策:

• 意思決定者を明確にする
• 判断基準を共有する
• ユーザー価値と事業価値を言語化する
• 関係者調整をプロダクトオーナーの責任として扱う

レビューが承認会になる

スプリントレビューが「合格をもらう場」になると、学習が止まります。レビューは成果を材料に次の方向を検査する場です。

対策:

• 早い段階で未完成のものも見せる
• 利用者の反応を見る
• 次のバックログ変更につなげる
• 承認とフィードバックを分ける

ケーススタディ

ケース1: 社内検索機能

背景:

サポート部門では、顧客からの問い合わせ時に注文履歴や過去対応を探す時間が長く、対応品質にばらつきがありました。

悪い進め方:

• 最初に全検索条件を洗い出す
• 大きな検索画面を一括で作る
• 完成後にサポート担当者へ見せる
• 想定と違う使い方が分かり、大きく手戻りする

アジャイルな進め方:

• まず問い合わせ件数の多い3種類を調べる
• 注文番号検索だけを小さく作る
• サポート担当者に実際の業務で使ってもらう
• ログから検索条件と失敗パターンを見る
• 顧客名検索、日付検索、テンプレート表示へ広げる

学び:

最初から万能検索を作るより、利用頻度の高い経路を小さく検証した方が、UI、権限、性能、検索語の揺れを早く学べます。

ケース2: 決済機能

背景:

新しい決済手段を追加する必要がありました。外部決済API、監査ログ、返金処理、障害時の再試行が関係します。

注意点:

この領域では「小さく作る」だけでは危険です。お金、監査、整合性、セキュリティが関係するため、初期の設計判断が重要になります。

進め方:

• 決済APIのスパイクを行う
• 正常系だけでなく、失敗、二重送信、タイムアウトを検証する
• 監査ログと冪等性を最初から設計する
• Feature Flagで一部ユーザーから公開する
• メトリクスとアラートを用意する

学び:

アジャイルは重要設計を省くことではありません。リスクが高い領域では、早く検証し、設計を明確にし、小さく公開することが必要です。

ケース3: 既存システムの改善

背景:

10年以上運用している業務システムで、機能追加のたびに不具合が増えていました。

悪い進め方:

• 新機能だけを短いスプリントで作る
• テストやリファクタリングは後回し
• 毎回リリース前に手動確認が膨らむ

アジャイルな改善:

• 変更頻度が高い領域からテストを追加する
• リリース手順を自動化する
• 小さなリファクタリングを毎回含める
• 障害の多い機能をバックログ上位に置く
• リードタイムと変更失敗率を見る

学び:

既存システムでは、アジャイル導入と技術的負債の返済を分けられません。短期反復の前に、変更を安全にする土台が必要です。

現代開発への接続

現代のアジャイルは、単なる開発チーム内の作業方法ではなく、プロダクト、設計、テスト、運用をつなぐフィードバックシステムとして理解する方が実務的です。

DevOpsとの関係

DevOpsは、開発と運用の分断を減らし、リリース後の情報を開発へ戻す考え方です。アジャイルが開発中のフィードバックを短くするなら、DevOpsは運用まで含めたフィードバックを短くします。

両者は競合しません。アジャイルだけで運用を見ないと、リリース後の学習が弱くなります。DevOpsだけでプロダクト価値を見ないと、デリバリーは速くても何を届けるかの判断が弱くなります。

SREとの関係

SREは、信頼性を計測可能な目標として扱います。SLOやエラーバジェットは、開発速度と信頼性のバランスを取るための材料になります。

アジャイルチームがSREの考え方を取り入れると、次の判断がしやすくなります。

• 今は新機能より信頼性改善を優先すべきか
• リリース頻度を上げても安全か
• 障害から何を学び、バックログに戻すか
• ユーザーに影響する品質をどう測るか

実務チェックリスト

始める前

• [ ] プロダクトゴールがある
• [ ] 優先順位を決める責任者がいる
• [ ] 利用者や関係者からフィードバックを得る経路がある
• [ ] 小さくリリースできる単位がある
• [ ] テストやCIの最低限の土台がある
• [ ] Definition of Doneがある
• [ ] 技術的リスクを先に検証する方法がある

スプリント中

• [ ] スプリントゴールが説明できる
• [ ] 作業が大きすぎる場合に分割している
• [ ] レビュー待ちやテスト待ちが見えている
• [ ] 未完了の理由を隠していない
• [ ] 変更要求は優先順位として扱っている
• [ ] 品質改善を通常作業に含めている

リリース後

• [ ] 利用状況を見ている
• [ ] エラーや問い合わせを見ている
• [ ] 運用で分かったことをバックログに戻している
• [ ] Feature Flagやロールバック方針が整理されている
• [ ] リリース後の学びをレビューで扱っている

ミニ比較表

スクラム、カンバン、XP

アジャイルで使う言葉

よくある質問

Q1. アジャイルでは設計書を書かないのか

書きます。ただし、設計書そのものを目的にしません。設計判断、境界、API契約、運用手順、セキュリティ上の前提など、後から必要になる情報は残します。

Q2. スクラムを導入すればアジャイルになるのか

なりません。スクラムは透明性、検査、適応を起こすための枠組みです。優先順位、品質、技術的規律、フィードバック経路がなければ、イベントだけが残ります。

Q3. スプリント中の変更は受けてよいのか

状況によります。スプリントゴールを壊す変更なら、何をやめるかを決める必要があります。緊急障害のような例外は、扱い方を明示しておくと混乱が減ります。

Q4. ドキュメントはどれくらい必要か

判断、運用、引き継ぎ、監査、設計理解に必要な分は書きます。誰も読まない大きな文書より、更新される短い文書、具体例、ADR、Runbook、API仕様の方が役立つことが多いです。

Q5. アジャイルとウォーターフォールは混ぜてもよいか

混ざることはあります。大事なのは、どこを固定し、どこで学習するかを明確にすることです。全体予算は固定しつつ、スコープや優先順位を調整する設計もあります。

Q6. アジャイルにPMは不要か

不要とは限りません。ただし、PMが細かいタスク指示だけを行うと、チームの自己管理と衝突します。目的、制約、関係者調整、リスク管理を支援する役割として再設計する必要があります。

Q7. アジャイルで品質は下がらないか

品質を後回しにすれば下がります。アジャイルは変更頻度が高いため、むしろ自動テスト、CI、レビュー、リファクタリング、Definition of Doneが重要になります。

まとめ

アジャイル開発は、短い周期で動くソフトウェアを作り、フィードバックから学び続けるための考え方です。スクラムはチーム運営と検査・適応、カンバンは作業の流れ、XPは技術的規律を支えます。

アジャイルを機能させるには、会議やボードだけでは足りません。ユーザー価値を見極めるプロダクト判断、変更に耐える設計、テストとCI、継続的なリファクタリング、チームが学べる文化が必要です。

また、アジャイルは「速く作る」ためだけの方法ではありません。間違いを小さくし、学習を早め、価値のないものを作り続けないための方法です。その意味で、アジャイルは開発手法であると同時に、プロダクトと組織の学習設計でもあります。

参考文献

公式・標準

• Manifesto for Agile Software Development
• Principles behind the Agile Manifesto
• The 2020 Scrum Guide
• The Kanban Guide

論文

• Winston W. Royce, Managing the Development of Large Software Systems

講義・記事

• Martin Fowler, The New Methodology
• Martin Fowler, Is Design Dead?
• Martin Fowler, Continuous Integration
• Martin Fowler, Feature Toggles
• Atlassian Agile Coach, Agile
• Google Cloud Architecture Center, DevOps tech: Continuous integration

書籍

• Kent Beck, Cynthia Andres, Extreme Programming Explained: Embrace Change
• Kent Beck, Test Driven Development: By Example
• Mike Cohn, User Stories Applied
• Mike Cohn, Agile Estimating and Planning
• Jeff Patton, User Story Mapping
• Gene Kim, Jez Humble, Patrick Debois, John Willis, The DevOps Handbook
• Nicole Forsgren, Jez Humble, Gene Kim, Accelerate

解説・補助

• Extreme Programming: A Gentle Introduction
• Scrum.org, What is Scrum?
• Kanban University, What is Kanban?