アジャイルの進捗を測るものとは

みなさんこんにちは。

以前の記事「 アジャイルとプロジェクト管理 」では『アジャイルは変化に寛容』と記載しましたが、実際にはどのように変化に対応し、どのように進捗を把握しているのかをお話しします。

進捗を報告する

進捗報告をする時、例えば開発者は「この機能は今70%ほどできています。テストが順調に終了すると今週中には完成の見込みです」のような報告をし、
そして進捗報告を聞いたプロジェクトを管理者はさらにプロジェクト全体のスケジュール（ガントチャートなど）を見て、リリースや納期に間に合うかを確認し、ステークホルダーへの報告をするのではないでしょうか？

ここで前回の記事の「プロジェクト管理のトライアングル」を思い出してみます。

先ほど例に挙げたやりとりは時間を焦点に合わせたタスクの管理に近いものでした。

では、アジャイルな視点でプロジェクト全体の進捗を測るにはどうしたら良いでしょうか。

進捗状況を測る方法

アジャイル・スクラム開発においての進捗は「顧客が満足する動作するプロダクト」で測ります。
アジャイルソフトウェア開発宣言にも『動くソフトウェアこそが進捗の最も重要な尺度です』と記載されています。

プロダクトオーナーやステークホルダーが、実際に動くプロダクトを見て、触って、承認やフィードバックをもらうことでやっと進捗の確認ができたと言えます。
この時のフィードバックから作成するものの優先順位が代わったり、作り直しが発生したりしても、寛容に受け入れ、対応していくことが求められます。

話を少し戻して、作成するものの優先順位が変わった時、全体のスケジュール（ガントチャートなど）は作り直しになり、「現在全体の○％です」と報告していても、作成するものの規模も変化するため毎回パーセンテージの指標があいまいになってしまいます。

そのため、プロジェクト全体の進捗は動くプロダクトをもとに、ビジョン、プロダクトゴールに向かって進めていくことが必要です。

 

また、「この機能は今70%ほどできています。テストが順調に終了すると今週中には完成の見込みです」のような進捗報告も、スプリント内のタスク管理や、デイリースクラム時の報告、タスクボードでの進捗確認などには必要です。

 

プロジェクト全体なのか、スプリントや細かい機能単位なのかを意識して、進捗報告をすることで、チームで前を向いて進むことができます。

理想と現実

アジャイル開発では動くプロダクトを毎スプリント作り、フィードバックから改善を重ね、定期的にリリースできている状態がとても大切です。

しかしながらチームビルディング直後や、保守運用の割合が多いスプリントの場合などには動くプロダクトを作ることが難しいこともあるかと思います。

そんな時も、例えばチーム全体として価値のあるドキュメントの作成をしたり、一歩下がってプロダクトゴールに向けて今何が足りていないのかをディスカッションしたりなど、動くプロダクトをつくるための仕掛けづくりを改めて考えて、再スタートできるような仕掛けづくりが求められます。

最後に

変化に寛容であるからこそ、進捗の確認は常に実施し、鮮度を保つ必要があります。

スクラムイベントをうまく活用し、チーム全員で現状の確認、そしてプロジェクト全体の向かう先を見ながら視点を合わせて進んでいきたいですね。