技術評論社から「図解即戦力 アジャイル開発の基礎」を発売したので、ぼちぼちと補足記事を書いていきます。
この本は、いわゆる「はじめてのアジャイル開発」ということで開発者とプロジェクトリーダー向けに書いた本です。具体的なプログラミング技術要素は皆無なのですが、特定のプログラム言語やフレームワークに関係なく使えるノウハウ集です。基本は、20年前に発祥した「アジャイル開発憲章」が日本に伝わったところからスタートします。温故知新的に基本を大切にするという精神。で、20年後の最近のシステム開発（特にチケット駆動とDevOps的なシステムリースサイクル）を含めて書き進めてあります。
さて、その中で少し小難しいのが第４章の「EVMを使ったプロジェクト完了時期の予測」の部分で、よく言われる「アジャイル開発では完了時期が予測できない」という誤解を覆します。まあ、漠然とチケット駆動していると完了時期が読めないのは実際そうなのですが、それがアジャイル開発起因という訳ではないという点です。この部分は、計画駆動（ウォーターフォール開発）でも同じで、プロジェクトの初期にスケジュールを立てたとしても、それに沿っているか、あるいはプロジェクト途中で要件が変更になったときとかにも使えます。
EVM（アーンドバリューマネジメント）自体は、もともと建築界隈で使われているものでもあり、昨今では「EVM」で検索すれば結構な解説サイト（コンサルサイト？）が見つかります。細かい用語の定義はコンサルサイトに譲るとして（日本語だと若干揺れがあるので、元の英語で覚えたほうがよさそうです）、グラフとしてはこんな感じです。
書籍の EVM の図は、巷にある EVM にあわせて出来高実績と投入実績の２本の線を書いていますが、実はこの２本の線は同じデータから作られているだけです。なので、実際のプロジェクトではオレンジの出来高実績いわゆるプロジェクトの実績＝進捗率と、計画段階の青の完了時予算の２本のグラフを比較すればOKです。
計画段階が青の線、プロジェクト実行時に遅れが出るのでオレンジの線、これを黄色の線のように遅れを取り返すにはどうしたらいいだろうか？という計算です。
書籍では紙面の都合上、遅れを取り戻すときの計算を省略していますが、ここで補足をしておきましょう。
チケット駆動での遅延を予測する
例えば、120枚のチケット（あるいはタスク、あるいはWBS）があるときを想定する。仮に、1日の消化チケット数を3枚として、1月を20日と考えると、60枚/月の計算になる。実際は、チケット/タスク/WBSの計画時間のブレがあったり、作業量の大きさが変わっているところだが、ここでは説明を簡単にするためにチケットの作業量の「粒」をそろえておく（この手法は、書籍に書いてある）
この計算だと、120枚のチケットは、2か月間で終わることになり、このプロジェクトは2人月と言う計画になる。
プロジェクトの進捗状態はバーンダウンチャートやEVMなどを使うことにあんるだろう。
さて、ここでプロジェクト開始から1か月経った状態、つまりプロジェクトが半分まで来た状態を観測する。
- プロジェクトの実施期間 １か月
- チケットの実績枚数 40枚
プロジェクトの残り期間は１か月で、残チケット数は 120 – 40 = 80 枚と考えられる。この 80 枚を当初の計画である「60枚/月」で割ると、
- 80 / 60 = 1.5か月
という計算が良く使われますが、これは間違いです。この「60枚/月」という値は、プロジェクトを開始する前の予測値なので、仮の値でしかありません。プロジェクトが開始して１か月経っているので、既にプロジェクトとしては「40枚/月」という実績がでています。なので、これを使います。
- 80 / 40 = 2か月
そうなると、残り80枚のチケットを「40枚/月」で割るので、あと2か月程度でプロジェクトが完了することが予測できます。つまり、予定の2か月よりも1か月ほど遅延して3か月のプロジェクトになると予測できます。
プロジェクトによっては1か月の遅延が許容できないことがあります。締め切り日が重要な場合は、プロジェクトを増員します。単純な増員は「人月の神話」に反するところですが、ここでは単純な予測値として、1人月を足すことになるので、1人の増員であればプロジェクトに間に合うのではないかという予測が立つというわけです。
一般的に、計画駆動（ウォーターフォール開発）のほうは締め切りが予測しやすいところですが、これがウォーターフォール開発であってもチケットの消化（ウォーターフォール開発ではWBSなど）が遅延することは同じです。となると、計画駆動開発でもアジャイル開発でもこの EVM の考え方は利用が可能です。むしろ、計画起動で遅延が発生したときに「どのくらい増員すればよいか？」の目安となるでしょう。
計算の肝は、遅延期間を計算するときに、プロジェクト開始の予測値ではなくプロジェクト実施の実績値を使うということです。プロジェクトの計画段階である「60枚/月」という値が楽観的すぎるために遅延が発生しているのすから、それの値を使ってはいけません。実績である「40枚/月」という値を使わないといけません。
チケットの計画時間が統一されないとき
実際のプロジェクトでは、チケット/タスク/WBSの予測時間や実績はさまざまです。できるだけ作業量を揃えたほうがいいのですが、ある程度ブレがあるでしょう。
この場合は、チケット/タスク/WBSの平均値を使います。
計画駆動のWBSの作業量が大きく違う場合は、平均値だと遅延の予測精度が悪いのでもう少し考えないと駄目なのですが、チケット駆動やアジャイル開発で利用するチケット/タスクの作業量が、1時間から1日（8時間）程度の間であれば、まあなんとかなるでしょう。理想的なことを言えば、1チケットは2,3時間程度に揃えておくと、遅延の計算が楽になります。
- 計画時の総時間 = Σ tplan
- 実績時の総時間 = Σ tdone
を考えるわけです。当然のことながらプロジェクトで遅延が発生しているときは「計画時の総時間 ＜ 実績時の総時間」となります。
遅延を計算するときには実績値のほうを使うので、
- tdone ave = Σ tdone / N
のように実績の平均値を使えばOKです。
チケットの増加を予測する
チケット駆動においてはプロジェクトの進行中にチケットが増加するのは必須です。バーンダウンチャートを作るにしても、プロジェクト後半において次々とチケットが増えてしまい、いつプロジェクトが終わるのかが予測がつかなくなってしまうという難点があります。従来型のアジャイル開発の考え方であれば、チケットが増えた分だけ納期を後ろにずらすのが筋ではありますが、状況によっては納期をずらせないこともあるでしょう。また、計画駆動においては納期をずらすことができないので、増員などで対処するしかありません。このとき、どの程度の増員をかけるのか、あるいはリスケジュールをするのかを予測します。
- 計画時 60枚/月の開発スピード チケット総数 120枚
- 実施時 40枚/月の開発スピード 前半のチケットが80枚に増加
プロジェクトの前半（かもしれない？）が終わった状態で、この状況であると仮定しましょう。
この状態で、実施されているチケット数が 40 枚。前半の残りが 80 – 40 = 40 枚。後半が 60 枚と考えてみると、プロジェクト後半では 40 + 60 = 100 枚となります。これを実績ベースの 40枚/月で割ると、
- (40+60) / 40 = 2.5人月
ということで、実際はプロジェクトの残りが 2.5 人月ということが計算できます。が、これは過小評価です。
後半の 60 枚のチケットは、プロジェクト計画時に作成したものなので、プロジェクトが開始する前の予測値でしかありません。既に実績として前半のチケットが 60 枚から 80 枚に増えているという「実績」を得ているので、この増加量をそのまま使いましょう。後半の60枚が80枚に増えると仮定するのが妥当です。このため、前半の残り 40 枚と後半の補正値 80 枚を加算して、
- (40+80)/40 = 3人月
ということになります。
このような単純化された値の場合、この3人月が後半の値ということが直感的にも分りやすいのですが、何故か実際のプロジェクトでは計画時の 60 枚をそのまま利用してしまい、リスケジュールしたときに過小評価をしてしまいがちです。注意してください。それは思ったよりも遅れているのです。
空白のチケットを活用する
先に書いた通り、バーンダウンチャートを使うとプロジェクト後半のチケットの増加に対応できません。特に終了が予測できない状態になってしまいます。なので、書籍では右肩上がりの EVM で解説を行っています。
しかし、EVM では予測値を出すときにウォータフォール開発のようにあらかじめプロジェクト全体の工数が必要となってきます。しかし、アジャイル開発やチケット駆動のようにプロジェクト実行時にチケット/タスク/WBSが増加することには、そのままでは対処できません。
この場合は、空白のチケットを利用します。時間軸上、プロジェクトが完了すれば全体のチケット数が判明します。そこで、プロジェクトが完了した未来の視点からチケット数を見ておいて、全体のチケット数を仮定します。これは計画駆動のWBSの洗い出しと同じ方法なのですが、WBSのように正確に出す必要はありません。
チケットの「粒」を揃えておけば、空白のチケットを 20 枚用意する、100 枚用意する、ということが可能です。つまり、1枚3時間ほどの空白チケットをあらかじめ用意して積んでおくのです。従来では言えば、プロジェクトの「保険」として使うものでもありますが、「空白のチケット」として明示的に用意することで、チケットの増加具合が空白チケットの減少具合で判明します。さらに、EVM と併用すれば、仮ではありますが総チケット数が判明するので、予測グラフが書きやすくなります。
残念ながら、この「空白のチケット」と EVM を組み合わせたツールは現在のところ販売された形跡はありませんが、数式としても簡単なものなので十分に活用できるでしょう。時間軸の問題や精度の問題、「プロジェクト完了時には分散する確率は0になる」の話はまた後日。
