第3章 アジャイルの原則

本章では、スクラムのプラクティスの根底にある「アジャイルの原則」について、伝統的な計画駆動（ウォーターフォール）の開発と比較しながら解説します。

3.1 概要

伝統的な計画駆動の開発は、プロセスが予測可能であり、要件定義、設計、コーディング、テストと順を追って作業できるという信念に基づいています。しかし、プロダクト開発のほとんどが予見できるようなものではないという現実に直面すると、このアプローチは破綻しやすくなります。

一方、スクラムは計画駆動のプロセスとは別の信念に基づいています。不確実なことが多すぎるため、高い精度で先を見通すことが難しい問題に対処するための原則が組み込まれています。

3.2 変動性と不確実性

スクラムは、プロダクト開発にある変動性と不確実性を活用して、革新的なソリューションを作り出します。

• 役立つ変動性を受け入れる: 製造業とは異なり、プロダクト開発においてまったく同じプロセスを繰り返すことはありません。イノベーションを生み出すための「役立つ変動性」は受け入れるべきです。
• イテレーティブでインクリメンタルな開発を採用する:
  • イテレーティブ（反復的）: 計画された手戻り戦略であり、一度作ったものを改善・調整していくことです。
  • インクリメンタル（漸進的）: プロダクトを小さい部品に分割し、少しずつ構築していくことです。 スクラムではこの両方を組み合わせ、各スプリントで動作するインクリメントを作成します。
• 検査、適応、透明性を通じて変動性を活用する: スクラムの核心は、検査、適応、透明性です。計画駆動がプロセスを事前に定義しようとするのに対し、スクラムは構築しながら継続的にプロセスとプロダクトを検査し、適応させます。
• あらゆる形の不確実性を同時に削減する: 「What（目的）」「How（手段）」「Who（顧客）」という不確実性を、フェーズごとに順番に解決するのではなく、同時に少しずつ解決していきます。

3.3 予見と適応

複雑なプロダクト開発では、事前の予測よりも、変化への適応力が重要になります。

• 選択肢を広げておく: 決定を最後の最後まで遅らせる「最終責任時点（Last Responsible Moment：LRM）」の考え方を採用し、不確実な状況下での誤った決定を防ぎます。
• 事前に正しく行うことは不可能だと認める: 事前に完璧な計画を立てようとすると、誤った判断によるコストが急激に上昇します。
• 適応型で探索型のアプローチを好む: 最初から大量の要件を作り出すのではなく、調査・学習・適応を繰り返す探索的なアプローチをとります。
• 経済的に妥当なやり方で変化を受け入れる: スクラムでは、ジャストインタイムで作業を行うため、後になって変更を加える際の「変更コスト曲線」を平坦に保つことができます。
• 予見的な作業と適応型の作業のバランスを取る: 事前の計画がゼロでよいわけではありません。要件定義やプランニングなどの「予見的な作業」と、やりながら合わせる「適応型の作業」のバランスを取ることが重要です。

3.4 検証による学び

スクラムは、継続的な学習が成功の鍵を握っているという前提に立っています。

• 重要な想定をまず検証する: プロダクトに関する大きなリスクや「想定（推測）」は、イテレーティブな開発によって早い段階で検証し、失敗のリスクを軽減します。
• 複数の学習ループを活用する: デイリースクラムやスプリントレビューなど、あらかじめ定義された複数の学習ループを並行して回すことで、学習を加速させます。
• すばやいフィードバックのためのワークフロー: コンポーネントの結合やテストを開発の後工程に回す（ビッグバン・インテグレーション）と、後になって大きな問題が発覚します。スクラムでは作業の流れをまとめ、すばやくフィードバックを受け取れるようにします。

3.5 仕掛中の作業（WIP）

スクラムでは、仕掛中の作業（WIP：Work In Progress）を適切に管理しなければならないという原則があります。

• 作業は経済的に妥当なサイズにまとめよ: バッチサイズ（一度に処理する作業量）を小さく保つことが重要です。これにより、サイクルタイムの削減、リスクの低減、モチベーションの向上が期待できます。
• 在庫を認識し、適切な流れで管理せよ: ソフトウェア開発における「在庫」は見えにくいですが、要件定義だけ終わったドキュメントや、テストされていないコードなどが該当します。これらはムダであり、在庫になりすぎないよう適切なバランスを見出す必要があります。
• 作業者の手待ちではなく、作業の手待ちに注目せよ: 作業者の稼働率を100%に保とうとする（全員を常に忙しくさせる）と、かえって作業の滞留（キュー）を生み出します。リレー競走で「走者」ではなく「バトン（作業）」がいかに止まらずに動くかに注目すべきです。
• 遅延コストを考慮せよ: 作業がキュー（待ち状態）に滞留することは、リリースの遅れに直結し、結果として多大な経済的損失（遅延コスト）を生み出します。

3.6 進捗

計画駆動開発とスクラムでは、「進捗」の捉え方が根本的に異なります。

• リアルタイムの情報に適応して再計画せよ: 計画は無条件に信じるものではなく、状況の継続的な変化に合わせて再計画していくものです。
• 動作する資産を検証することで進捗を測れ: フェーズ（設計完了など）で進捗を測るのではなく、実際に「動作するソフトウェア」を検証することでのみ、本当の進捗を測ることができます。
• 価値に主眼を置いたデリバリーに集中せよ: プロジェクト計画に従って作業を消化することではなく、顧客にとって価値の高いフィーチャーをいち早くデリバリーすることに集中します。

3.7 作業効率

作業効率に関して、アジャイルの原則では以下の3つを重視します。

• すばやく進め、しかし、あわてるな: スプリントではスピードを出しますが、長期的に維持できないような無理なペース（恒常的な残業など）は避けるべきです。「持続可能なペース」を保つことが求められます。
• 品質を作り込め: テストや品質保証を後回し（開発の最終フェーズ）にするのではなく、スプリント内で継続的にテストを行い、品質をプロダクトに「作り込む」必要があります。
• 必要最低限の儀式を行え: 価値を生まない重厚なドキュメント作成や形式主義的なプロセス（儀式）は極力排除し、必要最低限にとどめます。

3.8 終わりに

伝統的な「計画駆動の原則」と「アジャイルの原則」の主な違いは以下の通りです。

トピック	計画駆動の原則	アジャイルの原則
プロセスの構造	開発は工程に基づいており順序がある	開発はイテレーティブかつインクリメンタルであるべきだ
不確実性の管理	事前にすべての不確実性を排除しようとする	あらゆる不確実性を同時に減らしていく
意思決定	適切な工程でそれぞれの判断を行う	選択肢を広げておく / 事前に正しくすることはできない
フィードバック	重大な学びは大きな1回のループで得られる	同時並行した学習ループを複数活用する
在庫 / WIP	在庫は視野の外で、それほど注目されない	在庫を認識して管理し、作業を適切に流そうとする
人間のムダと作業のムダ	稼働率を高くするように人を割り当てる	作業者の手待ちではなく、作業の手待ちに注目せよ
進捗	段階や工程を通過することで進捗を示す	動作する資産を検証することで進捗を測る
品質	品質は最後に得るもの（テストフェーズ）	最初から品質を作り込む

---