ソフトの開発やテストの進捗管理を定量的に行う具体例２つ
ソフトの開発やテストでは工程の進捗管理が大切
ソフトの開発やテストはハードの開発や製造のように目に見える物が余りないので、うまく管理しないと計画を達成できません。ソフトの開発やテストでは、コスト管理や品質管理と共に、リリースの日程に直接影響する工程の進捗管理も大切です。工程管理と略して呼ぶ時もありますが、この記事では工程の進捗監理と呼ぶ事にします。
管理ですので①計画を作り、②実施の状況を監視して、③計画からのズレがあれば修正する、という管理サイクルを回して当初の計画を達成するのが目的です。目的を達成するためには、監視がしやすいような定量的なメトリクス（評価の方法や値）が必要になってきます。この記事では、ソフトの開発やテストで使える工程の進捗管理について、グータラ親父の経験を元に少し具体的な例を使って紹介していきます。
工程の進捗管理には日程の進捗管理と成果物の進捗管理がある
工程の進捗管理は日程の進捗管理と成果物の進捗管理の２つに大きく分かれます。日程の進捗管理とは、開発やテストの作業が当初の計画日程どおりに遅れ無く進んでいるかどうかの管理です。ソフトの開発日程についての最終的な目標はソフトのリリース日を守る事なのですが、日程の進捗管理がうまく出来ていないとリリース日になってもソフトが完成していなくてリリースできない、というような悲しい状況が起きる事があります。
成果物の進捗管理とは、ソフト開発だと設計書やソースコードや実行コード、テストだとテスト手順書やテスト結果や検出バグ、等の開発作業やテスト作業の成果物が当初の計画通りにできているかどうかの管理です。こちらも、最終的な目標はソフトのリリース時に必要な成果物が完成している事ですが、成果物進捗の管理がうまく出来ていないと、リリース日になってもまだテスト結果が揃っていなくてリリース可否の判断が出来てない、なんて事も起こり得ます。
日程の進捗管理も成果物の進捗管理も、最終的にはソフトのリリース日に当初の計画が達成できていればそれで良いのですが、リリース日になって出来ていませんでしたでは手の打ちようがありません。ですので、ソフトの開発やテストの期間を幾つかに分割して、開発やテストの途中の段階で中間目標の達成状況を監視し対策をする、工程内での進捗管理が大切になってきます。
日程の進捗管理の具体例（ソフトのテストを使ったサンプル例）
では、もう少し具体的に日程の進捗管理のやり方を見てみましょう。下記はソフトのテスト工程を例にした日程の進捗管理を行う管理表のサンプルです。このサンプルを使って日程の進捗管理を紹介してみます。
表１がテストの計画段階で作成する日程の計画表です。各行には細分化したテスト作業が書き出してあります。２列目の計画日の欄には、各々の作業が完了または終了する計画日が書いてあります。このような作業の完了や終了の日は、作業のマイルストーンとして使う事もあるので、マイルストーンの計画表と呼ぶ事もできます。ここまでがテストの計画段階で記入する内容です。
計画日の右横の実績日には、それぞれの行に書かれたテスト作業が実際に完了または終了した日を書いていきます。これは、作業の完了日にこの表１にその日付を書き込む事で簡単に実施できますね。サンプルでは現在を 6月15日と想定していて、6月10日に終了を計画していた結合テストが、計画よりも1日早く6月9日に終了した事が書き込まれています。
この表１だけでも、日程の計画が遅れているか進んでいるのかは定性的には判るのですが、定量的では無いので「進捗に問題があるので対策を実施する」という管理のトリガにはやや使いずらいです。
マイルストーンの完了率を使って日程の進捗を定性的に表す
それでは、表１の計画と実績の情報を元に、日程の進捗管理を定性的に表す工夫をしてみましょう。色々な方法があありますが、一番簡単なのはマイルストーンの完了率です。表１の計画日を各々作業を終了するマイルストーンとして、監視をする日に何％のマイルストーンが計画日までに実施されていたのかを計算します。式で書くと、以下のようになります。
マイルストーン完了率（％）
＝ （計画日までに完了したマイルストーンの件数 * １００）/
当日までに完了を計画しているマイルストンの件数
これを、毎週１回計算して表示すると、表２のようになります。（現在を 6月15日と想定しています）
この表２の例では、4月29日の時点では、この日までに終了すると計画していマイルストーンの件数は３で、実際に完了していたマイルストーン数も３なので、完了率は 100% です。（件数は表１を見て数えます）
でも5月10日の時点では、計画していた件数が4に対して機能Bテスト設計がまだ完了していない（完了したのは5月11日）ので、実績数が3で完了率は 75% に低下しています。その後5月21日までは完了率は 100% 以下ですが、6月10日には 113% と計画より先行するまでに回復し、６月15日の時点では計画どおりの 100% に戻りました。
完了率の数値だけを見ても実際に何が起きたのかはわかりませんが、テストBが想定外に難しくてテストの設計も実施も予定よりも工数が掛かったのかも知れません。そしてこの日程の遅れを挽回するために他のテストチームから助っ人を呼んだのかも知れません。 内情はどうであれ、このようにマイルストーンの完了率という定性化したメトリクスで工程進捗を監視していると管理はやり易いです。 例えば完了率が70%よりも下がったら、重要な問題が起きている可能性ありと判断して、具体的な問題の確認と対策を進める、というような管理のトリガが明確になります。管理においては、調査や対策の必要性の判断はとても重要なので、このような簡単なものでも定量化できるメトリクスがあると役に立ちます。
もっと実体に合わせたいなら作業量を反映するという手もあり
表２ではマイルストーンの達成件数を元に達成率を計算しました。全部のマイルストーンが同じくらいに重要ならばそれで良いのですが、そうでない場合は少し工夫したほうがより実際の進捗の感覚に近づける事ができます。
例えば、機能Ａのテストに必要なテスト工数が５人日で機能Ｂのテストに必要なテスト工数が20人日だったとします。機能Ｂは機能Ａの 4倍の工数が必要なのに機能Ａも機能Ｂも同じ期間で作業が終了する計画なのは、機能Ｂのテストに投入されている人員が機能Ａの４倍という事ですね。
という事は、マイルストーンの維持についての重要度は機能Ｂのほうが機能Ａよりも４倍重要だと考える事もできます。それならばマイルストーンの達成率を計算する時に、機能Ａは工数係数 1を機能Ｂは工数係数 4 を掛け算して達成率を計算するという工夫で、テスト工数によるマイルストーンの維持の重要度を織り込む事もできます。
表１の基本的なマイルストーンに、必要に応じて何等かの重要度の係数を掛け算する事で、より実際の進捗の感覚に塚づける事もできるので、それぞれのテストプロジェクトに合わせて検討するのも良いと思います。
ソフトのテストでの成果物進捗管理の計画の具体例（サンプル）
それでは次に、成果物の進捗管理も、テスト工程のサンプルを使って少し具体的に紹介してみます。
表３が、テスト項目数を例にしたテストの計画段階で作成する成果物の計画表です。各行には細分化したテスト毎のテスト項目数が書き出してあります。２列目から４列目の計画数の欄には、各々の日程までに実施が終了する予定のテスト項目数が書いてあります（空白の欄はゼロ）。
ここまでがテストの計画段階で記入する内容です。日程の進捗管理表と違って、実績を記入する欄はこの計画表にはありません。実績の記入は別の表を使います。
ソフトのテストでの成果物進捗管理の実績の具体例（サンプル）
表３の計画表に対応して、実績を記入するのが表４です。縦方向は表３と殆ど同じですが、表の最下段に（合計）と完了率の行が追加されています。列方向は計画日と同じ日付が書いてありますが、これが実績を監視する日付です。この日付の時点での、各テスト項目の実際の終了件数をこの表４に書き込みます。
（合計）の欄は縦方向の合計なので、実績を確認した時点での完了しているテスト項目の総件数を書き込みます。そして完了率は、監視日の時点でのテスト項目の計画の合計数に対する完了している実績の合計数で計算します。計算式で表すと以下です。
ＸＸ日でのテスト完了率（％）
＝ （ＸＸ日までに完了したテスト項目の合計件数 * １００）/
ＸＸ日までに完了を計画していったテスト項目の合計件数
例えば表４の例では、5月31日の時点では計画していたテスト項目の完了合計件数は表３から750件で、実際に完了したテスト項目の合計件数は表４から688件なので、完了率 = 688*100/750 = 92％ となります。本日が 6月15日と想定しているので、テスト項目の完了率は5月3１日では92%まで低下したのが、本日時点では 98%まで回復してきた、とう事が表４から読み取れます。
この例では、テスト項目数を成果物として使いまっしたが、数える事ができるソフト開発やテストの成果物ならば同じ方法で成果物による進捗管理のメトリクスに使えます。設計段階ならば、設計書のページ数や設計レビューの回数や設計レビューの指摘率 等が使えます。実装段階なら作成・修正したソースコードのライン数やコードレビューの実施回数等が使えます。テスト設計の段階ならテスト設計の項目数、テスト実際の項目数、テストレビュー実施回数やテストで見つけたバグ件数等も使えます。 ソフト開発からテストまでのそれぞれの段階で、必要に応じたメトリクスを使うのが良いと思います。
実績値は自動的に集まるように開発初期に仕組みを作る
このように、工程の進捗管理には日程の進捗管理と成果物の進捗管理の２つありますが、どちらも実績を集めて計画とのズレを見付ける事で管理に繋げるの、で実績値を集める事が必要です。実績値をあつめるための仕組みは、ソフト開発やテストを計画した時点で、日々の作業の中で自動的に実績値が溜まる仕組みを作っておかないと、なかなかうまく集まりません。 例えば、毎日の仕事終わりに、その日の成果物の量を記録する、というような作業を必須として、記録の状況を毎週１回確認する、などの工夫が欠かせません。
定期的な監視とフィードバックで目標達成と目指す
そして、実績が集まってくれば、必ず定期的に計画の値と見比べて、計画からのズレが一定以上に大きくなってきた時には、そのズレを挽回する対策を検討して実施する、というフィードバックをする事で当初の計画を維持するように努める必要があります。 このフィードバックが管理の中で一番大切な事なので、忘れないようにしましょう。
そして、フィードバックをしても計画からのズレが回復できない時には計画そのものを見直して、実際に達成可能な計画に修正するという事も視野に入れて、対策を考えていく事も大切です。