Eclipse Wayをひもとく（その2）

プロジェクト計画と管理という視点～エンドゲーム

3）エンドゲーム
　エンドゲームの時期は、製品として仕上げる時期です。機能の大幅な追加はなく、あくまで質を上げる・磨き上げる時期と位置づけられます。

　リリースプランで最終製品の機能群という“総体”を最初に宣言し優先順位付けします。リリースを構成する各マイルストーンでは、その初期に

　・リリースプランで宣言された機能群のうちまだ実装されていない残り項目
　・前マイルストーン中に発生した追加要求や先送りされた要求
　・しゃれにならない障害

　等を見直して、開発項目の候補リストを更新し、優先順位を付け直します。いわば“要求の棚卸し”をするのです。これによって、初期に宣言した機能群の漏れがないか、追加された機能ともともと宣言された機能とどちらがより重要か、納期までの期間の中で実装すべきなのはどれか？を選択できます。

　さて、何度か“機能”とか“開発項目”という表現が出てきました。アジャイルに限らず反復型プロセスの常ですが、リリースプランでの機能の表現は、ウォータフォール型開発のようにびっちりと詳細まで決めているわけではありません。では、どれくらいの詳細度で記述されるのでしょうか？次に「要求管理という視点」で見てみましょう。

要求管理という視点

　かっちりと定義した要求仕様を粛々と実装していく、という従来型の開発スタイルに慣れた身からすると、アジャイルや反復型プロセスが提唱するような、かっちり決めないうちから開発に入る、というのはどうも不安なものです。どのタイミングでどの程度の詳細度で機能を表現するのか、という感覚をまず理解することが大切です。

　図2は、Jazzプロジェクトにおける要求の構造（図の左側）と、それがプロジェクト計画の構造（図の右側）との関係を模式化したものです。

　アジャイル開発では、機能は“ストーリー”として表現されます。ストーリーは、実装する機能を簡潔に表現したものです。

　「管理者として、私は自分の管理するサーバーが過負荷になっていないかを知りたい」……これはJazzプロジェクトのサイトから拾ってきたストーリーの例です（このストーリーには、150字程度の概略が追記されています）。ユーザー向けの機能の表現であれば、ある役割（「管理者として……」）のもとで、システムを使用してできること（「……自分の管理するサーバーが過負荷になっていないかを知りたい」）を簡潔に記述します。

　しかし、この粒度で書くと膨大な量になりかねません。全体感を把握するには、もう少しおおざっぱな記述が必要です。これが、図の“計画項目（Jazz.net上ではPlan Item）”です。さらに上位のグルーピングの単位として、“テーマ”があります。それぞれJazzプロジェクトから拾ってみましょう。

○テーマの例：
「エンタープライズレベルのスケーラビリティとセキュリティー」
「Jazz製品群の連携」
「セットアップと保守のしやすさ」

○計画項目の例：
「プロジェクトレベルの読み取りアクセス制御」
「サーバーパフォーマンスとスケーラビリティのデータ収集」
「REST APIの提供」

　リリースプランで宣言するのは計画項目です。これをリストアップする時には、テーマの視点から漏れ・抜けがないか確認されます。各マイルストーンで開発するには、明確な利用イメージが想起できかつ各マイルストーン期間中に開発できるような粒度のストーリーレベルまで具体化します。その後、より詳細な（4～8時間位でできる）タスクに分割します。各マイルストーンの初期で要求の棚卸しをする時には、ストーリーと計画項目との関係をもとに漏れ・抜けを発見していくのです。