はじめに
この連載では、トレーサビリティ活動（または追跡可能性）についてお話しています。この連載が対象にするのは、ユーザ企業の情報システム部門の皆さんです。しかし、ユーザさんに限らず、トレーサビリティ活動の中身を知りたい方、その実施のヒントを得たい方、そして開発者の方々にも有益な情報たるべく書いています。
まずは、前回のまとめからお話していくことにしましょう。
前回のまとめ
トレーサビリティ活動とは、「顧客要件（＝開発の出発点）から、プログラムなどの最終成果物（＝終点）までの過程を追跡できるようにすること」でした。自分たちが望んでいた要件が、設計、実装、テストを経て、最終的にどのような仕様のプログラムとして納品されたのかについて、そのプロセスをいつでも辿ることができるようにするわけですね。
前回挙げた例を再掲します。以下は、「顧客要件」を次のステップである「機能」に分割したイメージ図です。2つの箱は、それぞれが顧客要件と機能を記述した文書（成果物）だと思ってください。
前回に戻って、解説を読んでみてください。
ちなみに、気にせず先に進んでいただいても全く問題ありません。
何をすればトレーサビリティを確保したことになるのか
さて、上の図において、トレーサビリティを確保するとは具体的にどういう状態をさすのでしょうか？ そうですね、以下のようなことを明言できれば良いのでした。
- 顧客要件No.1を満たす機能は、機能No.1、No.2で定義しています
- 機能No.2は、顧客要件No.1を実現すべく定義したものです
この要領で、要件を固め、設計し、実装し、テストし、納品するまでの間、「今、進行中のこの作業では、要件の何番目を設計（あるいは実装・テスト…）していることになります」と、常に明らかにできること。それが「成果物」を「追跡」できるという状態です。
逆に言えば、「このテスト仕様書のケースNo14は、顧客要件のどれが満たされていることを確認するためのものですか？」と聞いて、開発側の担当者さんが「う～ん」と悩んでしまうようでは、トレーサビリティが確保されているとは言えないのでした。
どうすればトレーサビリティを確保できるのか
では、どのようにトレーサビリティを確保すれば良いのか？ 前回は、そのための方法として「各文章に固有の番号をつけて管理できる仕組みを作りましょう」というところまでお話ししました。
さて、ここでいくつかの性格パターンに分かれると思います。
- 最初から読んだがまだよく分からん。 or 前回は飛ばした。
言葉で説明されただけで内容を理解するのは難しいものですよね。大丈夫です。
今後具体的な活動方法をエクササイズによって確認していきます。進みましょう。
- 納得できないと先に進みたくない。
連載の第1回に戻って、少し我慢してゆっくり読んでみてください。
＞＞第1回へ
- 分からない部分は気にしない。とにかく実践して覚えたい。
この回はスキップして、第3回に進みましょう！
＞＞第3回へ
- なんだかとにかくイライラしてきた。。。
イライラするほど真面目に向き合ってくださっていることに、感謝します。
この先「あ、そうか」と霧が晴れるかもしれません。
流し読みでけっこうですので、先に進んでみてはいかがでしょう。
