軽量マイルストーンによるアジャイルプロジェクトリスク軽減

DADは、プロジェクト/リリースの進捗状況と健康状態を測定するために、ライフサイクルにいくつかのマイルストーンを組み込んでいる。

DADにはなぜマイルストーンがあるのか?

主流のアジャイル手法には、ガバナンスの考え方はほとんどなく、アジャイルにはマイルストーンは不要であると考える人は多い。スクラムは、最も価値の高い作業をバックログの一番上に位置付ける。そして各スプリント(反復)の終了時に、バックログ内の次の作業が十分な価値を生み出すかどうかによって、次のスプリントに予算をつけるかどうかが決まる。価値がないとみなされると、プロジェクトは終了する。基本的にこの戦略は理にかなっているが、ガバナンスの面で、以下のような欠陥がある:

  • 十分ではない
    プロジェクトへの予算割り当てをやめるタイミングで判断する以外に、はるかに効果的なガバナンスがあるのではないか。例えば、プロジェクトはどのように始まったのだろうか?
  • 現実的ではない
    実際問題、ほとんどの組織では、スプリントごとに予算配分の意思決定を行うわけではなく、複数の反復で構成されるリリース単位で判断をすることのほうが多い。
  • 効果的なマイルストーン
    スクラムはマイルストーンを持たないと主張しているが、本番移行するのに十分な機能があるかどうかを検討したり、今後の戦略を決定したりすることは、暗黙的なマイルストーンである。DADは、マイルストーンを効果的に適用するための指針を明示している。

アジャイルガバナンスはなぜ必要か?

多くの人が思い込んでいるのとは違って、アジャイル・イニシアチブの中で、ガバナンスは不要にはならない。スポンサーやその他の利害関係者には、彼らの投資に対する現在の状況を定期的に報告するべきである。彼らは以下のような質問への答えを期待している:

  • 投資から何が得られ、それにはどんな価値があるのか?
  • 最初の予算要求に沿って提供されているものは何か?
  • 未解決のリスクの状況は? そのリスクを緩和するために何が行われているか?
  • 現在のリリース予定は、元の予測と一致しているか?
  • 本番リリースのために十分な機能はいつできるか?
  • すべての利害関係者がリリース準備できているか?
  • プロジェクトはいつ完了するか?

「それはアジャイルじゃない」という主張は、上のような質問に答えないことで、アジャイルが時に無規律とみなされるゆえんである。事実、このような主張は、アジャイルがなぜ効果を発揮しないかという言い訳のひとつとして、よく利用される。幸いなことに、DADにはこれらの質問に答えるための仕組みがあり、多くの組織ではアジャイルの適用を拡張し、DADのガイダンスを組み込んでいる。実際、アジャイル性を保ちつつ、プロジェクトを管理する方法を模索している人にとっては、DADは非常に魅力的である。

マイルストーン・レビューは非公式なものとすべき

DADの目標で推奨されている戦略に沿った形で「チームミッション達成」マイルストーンをレビューする時には、軽量な形式にするべきである。アジャイル基本ライフサイクルを使用する場合、それは通常、反復もしくはフェーズの終了と一致する。DADになぜフェーズがあるか疑問に思われる場合は、このブログの関連記事にその情報がある。

マイルストーンの日付は伝達する必要がある

DADプロジェクトの各マイルストーンの日付をカレンダーにして、それを利害関係者に提供し、その利害関係者が関心のあるマイルストーンのレビューにあたる反復レビューに参加する予定を組めるようにすることは、良い習慣としておすすめできる。マイルストーンの日付が変更される可能性はあるが、すべての利害関係者へのロードマップとして、プロジェクトポートフォリオ全体にまたがった目標マイルストーンを表示するのは、大変有用だ。

DADマイルストーン

利害関係者のビジョン
方向付けフェーズの目標は、最低限のしかし十分な時間をかけて(通常1〜4週間で)、今回のプロジェクトに意味があり、よって構築フェーズに進んでよいという、利害関係者の合意を得ることである。DADの方向付けの各目標に取り組むことで、初期スコープ、技術、スケジュール、予算、リスクといった従来のプロジェクト情報を、できるだけ軽量な形でデリバリーチームが得ることになる。この情報は、「共通のビジョンを作る」ゴールに記述されているビジョン・ステートメントとして整理され、利害関係者に提示される。ビジョンの形式やレビューの公式度は、状況によって変わりうる。典型的なやり方は、方向付けフェーズの終了時に主要な利害関係者で数枚のスライドをレビューし、プロジェクトの意義とデリバリー手法に関して全員が同じものを確認していることを確実にすることである。

検証されたアーキテクチャー
プロジェクトのリスクを早期に軽減することは、よいプロジェクト管理手法のひとつである。「アーキテクチャーを早期に実証する目標が示すように、このためにはいくつかの戦略が採用できる。最も効果的なのは、技術的にリスクの高いビジネス要求を、エンド・ツー・エンドで動作するコードのスケルトンに実装してみることである。DADにおけるアーキテクチャーオーナーの重要な責務は、方向付けフェーズでリスクを特定することである。これらのリスクは、構築フェーズの1〜3回の反復の中で関連する機能を実装することで、軽減もしくは解消することが期待されている。この手法を適用した結果、初期の反復レビューやデモで、機能要件に加えて/もしくはその代わりに、非機能要件をサポートするソリューションの能力が示されることがある。このため、アーキテクチャーに関心を持つ利害関係者がこれらのマイルストーンレビューに参加する機会を与えられることが重要である。

プロジェクトの実行可能性
リリーススケジュールに含めるオプションのマイルストーンは、プロジェクトの実行可能性に関するものである。プロジェクトのあるタイミングで、利害関係者は、方向付けの終了時に合意したビジョンに沿ってプロジェクトが進行しているかどうかを確認するチェックポイントを要求することができる。これらのマイルストーンの予定を立てることによって、利害関係者は、プロジェクトの状況を評価し、必要があれば変更に合意するために、チームと一緒にいるべき重要な日程を認識することができる。ここで可能性がある変更としては、投資レベル、チーム構築、スコープ、リスクアセスメント、もしくはプロジェクト中止の可能性さえ含まれている。これらのマイルストーンは複数存在する可能性がある。もし利害関係者が変更に合意したら、ビジョンはそのタイミングで更新される。スクラムは暗黙的にこのマイルストーンを各スプリントの終了時に行う。DADはこれを明示的に選択し、その頻度を任意にしている。

十分な機能性
各反復の終了時に使用可能なソリューション(スクラムで「潜在的に出荷可能なインクリメント」と呼ばれるもの)をリリースすることを目標とする、ということもある一方、本番移行するのに十分な機能をチームが実装するために、構築フェーズの反復を複数回必要とする、というのもよくあることである。これは時として、最低限実行可能な製品(MVP)と呼ばれるが、これは技術的には正確ではない。古典的にMVPは最小限の本番移行可能な機能を示すものではなく、製品の実用性を確認するためのものである。このマイルストーンと対応するより正確な用語は、「最小限の機能セット」だろう。しかしながら、後者の意味でこの略語が使われていることが多い。

十分な機能が利用可能になり、利害関係者へのリリース移行コストが正当と判断された場合に、DADの「十分な機能性」マイルストーンは、構築フェーズ終了時に達成したとみなされる。例えば、使用可能なソリューションインクリメントは2週間の反復ごとにできるかもしれないが、高いコンプライアンスレベルが要求される環境では実際にそれを本番移行するのに2週間かかるかもしれない。この場合、より多くの機能が完成するまで、移行に要するコストは正当とはみなされない可能性がある。

本番準備完了
重要な場面では、利害関係者へのソリューションデリバリーの一環として最終準備を行うために、公式の移行フェーズが必要になることがよくある。十分な機能が開発され、テストされたら、その後通常必要なのが、データ変換、最終受け入れテスト、製造及びサポート関連の文書化のような移行関連の活動である。理想的には、これらの作業の多くが、機能の各インクリメントを作る一環として構築フェーズの間に継続的に行われている。いくつかのポイントでは、ソリューションを準備完了とするための決定が必要となる。もちろん、継続的デリバリーライフサイクルに従っている場合には、「移行フェーズ」は「移行作業」になるだろう。しかしながら、ソリューションをデプロイする前に、そのソリューションが使用可能であることを確認したい関係者は依然として存在する。

満足した利害関係者
ガバナンス組織やその他の利害関係者は、プロジェクトがいつ公式に終了するかを知りたいことがある。それによって次のリリースを開始したり、他に予算を振りかえたりすることができるからである。プロジェクトは、ソリューション本番開始の翌日に終了するわけではない。トレーニングや本番移行後のチューニング、サポート移管、実装後の再レビューなどのプロジェクト完了作業はしばしばあり、プロジェクトが完了したと判断される前に保証期間を設けることもよくある。リーンには「顧客満足」という用語があるが、これは「満足」の閾値が低すぎることを示唆している。一方DADは、プロジェクトが完了したと判断する前に、サポート担当などの顧客以外の利害関係者の満足を満たす必要もあると考え、マイルストーンの名前を「満足した利害関係者」としている。

マイルストーンを試してみる

アジャイルは、利害関係者に対する透明性と説明責任を促す。みなさんのプロジェクトで重要なマイルストーンの達成を共有し、お祝いしよう。

オリジナル:Reduce Agile Project Risk with Light-Weight Milestones

Reduce Agile Project Risk with Light-Weight Milestones


 (翻訳 中佐藤麻記子)

Pocket