アジャイル開発における計画と運営サイクル
ソフトウェア開発において、重要かつ難しい作業の1つが「計画」です。アジャイル開発では、計画を立てずに実装を始めるイメージがあるかもしれませんが、実際には計画を立ててから実装します。ただし、“すべてを事前に予測はできない”という前提で、継続的に計画を立てていくことが肝要です。本稿では、アジャイル開発における計画と運営サイクルに焦点を当てて解説します。
アジャイルにおけるプランニング
アジャイル開発を導入すると、一般的にプロジェクトの初期品質は良くなりますし、要求の充足率も高くなります。何より開発者のモチベーションの向上にもつながります。しかし、プロジェクトを上手く運営できないときもあります。
プロジェクトが上手くいっている場合もそうでない場合も、開発者は各関係者に計画と進捗を説明する責任があります。実際のプロジェクトには、開発のみでなく計画／構想のフェーズ、UIデザインの外注、翻訳、性能テスト、環境テスト、トレーニングなど多くのタスクがあり、上司や顧客をはじめ、これらのタスクに携わる多くのステークホルダー（※注1）がいます。
直接／間接を問わず、利害関係を有する人たちのこと。
アジャイル開発でも適切に進捗状況を把握し、プロジェクト周辺のタスクを考慮に入れながら各ステークホルダーに説明することが重要になります。
ウォーターフォール的な部分
アジャイル開発では、設計と実装とテストは同時に進行します。しかし、常にすべてのタスクが同じペースで進むわけではありません。システム全体のコンセプトや採用する技術の方向性が決まらないうちに、開発をはじめるわけではないですし、すべての画面が完成する前に全体的なユーザビリティ検証はできないかもしれません。
また、セキュリティなどの共通機能は、実装後半になって横断的に各機能に影響を及ぼすかもしれません。テストには、機能をテストする以外にも稼動環境テスト、性能テストなどがあります。もちろんすべて自動化できればそれに越したことはありませんが、手動の部分が多く残ります。
プロジェクトのスタートから製品リリースまでを考えると、アジャイル開発でもウォーターフォール的（一方向的）な部分がありそうです。
スコープ（機能）の柔軟化
ソフトウェア開発において、すべてが計画どおりに進むことはまずありません（威張って言えることではありませんが……）。そのようなときに“リスケ”（リスケジューリング）を行ないます。
アジャイル開発において、リスケはどのように行なわれるのでしょうか。そもそも、アジャイル開発ではウォーターフォールほど厳密に事前に見積もりませんし、リスケとまではいきませんが計画を変更することもあります（むしろ、計画は頻繁に変更します）。
アジャイル開発においてウォーターフォールと最も大きく異なる点は、何を固定するかにあります。図1に示すように一般的に計画の3大要素には、次の3つが挙げられます（時に、これらに「品質」を加えて4大要素とすることがあります）。
- スケジュール
- スコープ（機能）
- リソース（人／金）
アジャイル開発ではスケジュールとリソースは固定し（品質も固定）、スコープを変動要素とします。ここにアジャイル開発の計画における最も大きな特徴があります。これについてはアジャイル開発の流れにおけるいくつかの重要な原則とも深く結びついています。
開発の“一方通行”は、ウォーターフォール方式の最も大きな特徴であり、アジャイル開発にとって大きな弊害と言われています。
実は、その原典とされるWinston W. Royceの論文“Managing the Development of Large Software Systems”（1970）ではイテラティブ（反復的）に開発することの重要性が述べられています。しかしながら、その部分は時を経て抜け落ちてしまいました。
その後、彼の息子であるWalker Royceらを中心に、「RUP」（Rational Unified Process）が提唱され、父の思いは息子によってようやく具現化されました。
RUP自体は大規模なプロジェクトに対して適用され、直系の“アジャイル”手法ではありませんが、多くの部分で共通します。Open UPや、Agile Unified Process といった発展形もあり、XPやスクラムとともに参考となる開発プロセスの1つです。
