7つのアジャイル開発手法の実践ガイド（第1回）

XP、スクラム、リーンソフトウェアから駆動型開発まで

スクラム

　スクラム（Scrum）はSCRUMという頭字語だと誤解されているようですが、そうではありません。スクラムという名前は、ラグビーのスクラムから来ています。ラグビーでは、軽度の反則（ボールを前に落とすなど）の後に試合を再開するときに、スクラムというプレーをします。分かりやすく言えば、チームが一丸となってボールをゴール方向に進ませることです。

　スクラムはアジャイルなプロジェクトを管理するためのプロジェクトマネジメントフレームワークです。その第一の目的は、各イテレーション後に、最高のビジネス価値を提供するソフトウェアを引き渡すことです。スクラムは「スプリント（Sprint）」という30日間のイテレーションをベースとしています。理論的には、スプリントは2週間または4週間のどちらでも構いませんが、一般に受け入れられている期間は4週間です。

　スクラムに欠かせない重要なポイントは、「プロジェクトチームは自己組織化しなければならない」ことです。つまり、チームメンバは規範的な計画や一連のタスクに従うのではなく、最初はスプリントの目標に基づき、その後は毎日のスクラムミーティングを通して、日次ベースで自ら組織的な調整を行います。チームの規模としては4～9人が推奨されています。

　プロジェクトチームは毎日同じ時刻にミーティングを開き、プロジェクトについて話し合います。その際、立ってミーティングを行うことで、ミーティング時間を短くすることが期待されます。ミーティングは10～15分で終了することを目標とします。各メンバは順に次の3つの質問に答えます。

1. 前回のスクラムミーティング以降に何を行ったか。
2. 現在から次のスクラムミーティングまでの間に何を行うことを計画しているか。
3. 障害があるか。

　この報告は状況ミーティングではありません。言い換えれば、チームメンバが報告するのはタスクが何パーセント完了しているかということではありません。報告するのは、どのような作業を行ったか、なぜそれを行ったか、それが完了したかどうかということです。進捗を遅らせる事態が発生した場合は、障害と見なします。障害が報告されたら、適切なチャネルに即座に上申することを含め、チームはその障害を処理する方法を決定します。

　1つのプロジェクトに複数のチームが関与している場合は、日次スクラムミーティングの階層が発生する可能性があります。これをスクラムのスクラムとも言います。例えば、3つのチームが3つの関連するスプリントで作業にかかわっているとします。この場合は、チームごとに日次スクラムミーティングを開くほかに、各チームから1人ずつメンバが集まって追加スクラムミーティングを開き、チームが連携していることを確認します。この追加スクラムからの情報は、翌日に個々のチームのスクラムにフィードバックされます。

　スクラムでも、次のような役割が定義されています。

• プロダクトオーナー
プロダクトオーナーは、チームが作成しているプロダクトの顧客またはユーザーの代表です。実際の顧客であることが理想ですが、プロダクトの顧客の協力が得られない場合は、顧客の関心を表現する人がこの役割を引き受けます。また、プロダクトチームと顧客を結び付けることもプロダクトオーナーの担当です。

• スクラムマスタ
スクラムは、障害のあるまたは緊急のプロジェクトを取り扱う方法として始まりました。スクラムマスタは、プロジェクトチームをまとめるための役割を担います。スクラムマスタの仕事は主に、チームの活動を円滑にし、報告し、優先順位が最も高い作業に焦点を当て、チームの進捗を遅らせる可能性がある障害を取り除くことです。スクラムマスタ向けの認証トレーニングがあり、3つの異なるレベルのプラクティスをサポートします。

• チームメンバ
チームのその他のメンバはすべて一般のチームメンバと見なされます。これには、開発者、アーキテクト、プロジェクトマネージャ、テスタ、データベース管理者など、あらゆる人が含まれます。スクラムではチームの概念が重要なので、スクラムマスタとプロダクトオーナーの主な役割しか実施されません。

　スクラムでは、関連する項目のリストのことを「バックログ」と呼びます。スクラムプロセスでは、プロダクトバックログ、リリースバックログ、スプリントバックログの3つのバックログが定義されています。

　プロダクトバックログは、プロダクトを引き渡すための要件がすべて示されたリストです。通常、これらの要件は概要レベルで定義され、スプリントバックログのスコープを設定する場合に使う見積もりが含まれます。リリースバックログはプロダクトバックログから引き出されたもので、要件の一覧を表します。このリストは優先順位順で、リストの各項目には一意の優先順位が割り当てられています。また、このリスト内の各要件には、プロダクトバックログで定められた見積もりよりも細分性の高い見積もりが含まれます。

　各スプリントの開始時に、プロジェクトチームはリリースバックログからの項目を分類し、一番上（最も重要な項目）から開始して、これらの項目をスプリントバックログに追加します。スプリントバックログが満杯になるくらい十分な数の項目が選択されると、スプリントバックログはロックされます。見積もりには、分析、設計、コーディング、テスト、文書化など、各項目を完了するまでの合計時間が含まれます。

　バックログに関連するもう1つの項目として、バーンダウンチャート（Burndown Chart）があります（図2を参照）。バーンダウンチャートは、現在のスプリントで完了すべきスプリントバックログ内の残存項目数を示します。そのため、チームと残存作業の進捗状況の確認に役立ちます。バーンダウンチャートの直線は、完全に安定し均等に分散した方法で作業を完了する理想的なイテレーションを表し、曲線は時間をかけて実際に完了された作業を表します。日次レコードを更新していくことで、スプリントの目標達成におけるチームの進捗状況を表すことができます。

図2　スクラムのバーンダウンチャート

　スプリントの最後に、チームは関係のあるステークホルダとミーティングを開き、どの作業が完了したかを明白にし、次のスプリントの優先順位を評価します。さらに、未処理の障害と、その影響および考えられるソリューションについても話し合います。

　最後になりますが、スクラムはプロジェクトのマネジメント面に焦点を当てたものであり、技術的なプラクティスは何も指定していないので、他のアジャイル開発手法とうまく組み合わせることができます。通常はXPと組み合わせますが、他のアプローチと組み合わせてもうまくいきます。

リーンソフトウェア開発（Lean Software Development）

　リーンソフトウェア開発は、「lean＝細身の、無駄がない」という単語の意味から、新しいダイエット法の一種であるなどと冗談を言われたりしますが、これはまったくの冗談でもありません。リーン開発は、ソフトウェアプロセスから無駄を取り除くことを目的とした開発手法であり、要件から始めて、ビジネスが要求されるシステムをどのように見ているかを取り込んでいきます。

　リーン開発の手法は、トヨタなどの企業が過去数十年に渡り完成させたリーン生産プロセスから生まれたものです。リーン開発の目標は、ビジネスが競合力を保つために必要とされる複雑なソフトウェアシステムを定義し、構築し、引き渡すという取り組みに対処することです。リーン開発は、技術的なプラクティスではなく、ソフトウェア開発のプロジェクトマネジメント面を重視している点でスクラムと似ており、特にプロジェクトのコストとROIの属性を焦点にしています。

　リーン開発の大きな柱になっているのが、「正しい」要件の収集です。要件はビジネスへの影響に基づいて評価し、明確で完全で検証可能な方法で定義しなければなりません。不完全な要件、見つからない要件、間違った要件、検証不可能な要件、競合している要件は、要件定義プロセス時に除外されます。

　このように要件を重視するため、リーンプロセスでは顧客が絶対不可欠な役割を果たします。生産の観点から見れば、リーン開発は新製品の開発のようなものと考えることができます。要件に焦点を置くことは、顧客が果たす役割と価値を具体化するのに役立ちます。開発チームが対処しているビジネス価値と機能要件について顧客からコンスタントなフィードバックを得ることが、リーンアプローチの中心的要素です。

　リーン開発では、豊富な数量的メトリックに基づいて、多くのプロジェクトが失敗する原因が構成とマネジメントにあることを明らかにします。各自がバラバラで、それぞれが孤立し、「私の問題ではない」という姿勢で進行しているプロジェクトは、リーン開発を導入すると急変します。リーン開発では、リソース関連の問題、例えばチームに適切なスキルセットがない、チームメンバが不足している、離職率が高すぎる、といった問題についての対応も試みます。この意味で、リーン開発は「根本的な原因」を重視する手法であると言えます。

　開発手法の中にはチーム内の役割の厳密な定義を求めるものもありますが、リーン開発ではもっと部局横断的なアプローチが取られます。チームメンバはシステムの機能面と技術面のクロストレーニングを受けるだけでなく、さまざまなチームメンバと協力し合ってシステム機能のビジネス価値と、解決すべきビジネス問題を理解します。

　W. Edward Deming博士の総合的品質管理（Total Quality Management：TQM）という著作から生まれたリーン生産は、主に次の2つの概念に要約することができます。

1. プロセスが重要である。
2. 人がプロセスを構築し改善する。

　TQMは50年近くに渡って改良され、製造業界での実績は折り紙付きです。TQMはメトリックを非常に重視し、メトリックもリーンソフトウェア開発の大きな役割を果たしています。

　リーンソフトウェアプロセスに加わったもっと新しい考えが『制約条件の理論（Theory of Constraints）』 （Eliyahu M. Goldratt他著、North River Pr、1999年12月）です。これも主に2つの概念から成り立ちます。

1. 制約条件を特定する。
2. 制約条件を改善/除去する。

　「制約条件の理論」は、ビジネス組織を自己完結体系として効果的に管理する方法についての知識を具体的に表したものです。

　リーンソフトウェア開発では7つのリーン原則を推進しています。この開発手法はこれらの原則を中心に展開し、リーン開発の他の面はすべてこれらの原則を補足するために作られています。7つの原則は次のとおりです。

1. 無駄を排除する
値を付加しないものはすべて排除します。

2. 品質を組み込む
プロセス全体を通して前提条件の検証と再検証を繰り返します。価値がなくなったメトリックやプラクティスは捨てます。

3. 知識を身に付ける
短期間の反復サイクルを使用して、迅速でコンスタントなフィードバックを提供し、正しいことに焦点が当てられていることを確認します。

4. コミットメントを遅らせる
決定するための知識が十分に得られるまで意思決定を行いません。問題と有効なソリューションのトレードオフをしっかりと理解することが必要です。

5. 迅速に引き渡す
ビジネス問題を見極め、その問題に対処するシステム（または機能）を引き渡すまでの時間（つまり、市場化までの時間）を最小限にします。

6. 人を尊重する
チームに成功する力を与えます。

7. 全体を最適化する
部局横断的なチームを活用して、問題（およびその問題を解決するためのシステム）の重要でクリティカルな面を見逃さないようにします。

　繰り返しますが、リーン開発はプロジェクトマネジメント面に焦点を当てる手法であり、技術的なプラクティスは何も指定していないので、ソフトウェア開発の技術的な面に焦点を当てるXPなどの他のアジャイル開発手法とうまく組み合わせることができます。