「再見積もりで工数が2倍！？」～余裕が無いプロジェクトほどトレーサビリティ活動をすべき理由

はじめに

　この連載では、トレーサビリティ活動（または追跡可能性）についてお話しています。この連載が対象にするのは、ユーザ企業の情報システム部門の皆さんです。しかし、ユーザさんに限らず、トレーサビリティ活動の中身を知りたい方、その実施のヒントを得たい方、そして開発者の方々にも有益な情報たるべく書いています。

　まずは、前回のまとめからお話していくことにしましょう。

前回のまとめ

　トレーサビリティ活動とは、「顧客要件（＝開発の出発点）から、プログラムなどの最終成果物（＝終点）までの過程を追跡できるようにすること」でした。自分たちが望んでいた要件が、設計、実装、テストを経て、最終的にどのような仕様のプログラムとして納品されたのかについて、そのプロセスをいつでも辿ることができるようにするわけですね。

　前回挙げた例を再掲します。以下は、「顧客要件」を次のステップである「機能」に分割したイメージ図です。2つの箱は、それぞれが顧客要件と機能を記述した文書（成果物）だと思ってください。

何をすればトレーサビリティを確保したことになるのか

　さて、上の図において、トレーサビリティを確保するとは具体的にどういう状態をさすのでしょうか？ そうですね、以下のようなことを明言できれば良いのでした。

　この要領で、要件を固め、設計し、実装し、テストし、納品するまでの間、「今、進行中のこの作業では、要件の何番目を設計（あるいは実装・テスト…）していることになります」と、常に明らかにできること。それが「成果物」を「追跡」できるという状態です。

　逆に言えば、「このテスト仕様書のケースNo14は、顧客要件のどれが満たされていることを確認するためのものですか？」と聞いて、開発側の担当者さんが「う～ん」と悩んでしまうようでは、トレーサビリティが確保されているとは言えないのでした。

どうすればトレーサビリティを確保できるのか

　　では、どのようにトレーサビリティを確保すれば良いのか？ 前回は、そのための方法として「各文章に固有の番号をつけて管理できる仕組みを作りましょう」というところまでお話ししました。

　さて、ここでいくつかの性格パターンに分かれると思います。