「実践・ソフトウェアのISO9000」（日本能率協会マネジメントセンター：新倉忠隆著）の内容から抜粋しています．（1994年版のISO9001の解説です．出版当時のTickITにも対応しています．）

４．８　製品の識別及びトレーサビリティ

品質システム構築のポイント

• 　ソフトウェアのトレーサビリティには以下の２つがある．

  a) 製品に関するトレーサビリティ

  b)文書及びデータに関するトレーサビリティ

  　a)は，ソフトウェアアイテム（ソフトウェアの部品の最小構成要素）が製品にどのように組み込まれているかが追跡できることである．ハードウェア製品などの部品がどのように製品に組み込まれているかを管理できることと同じである．

  　b)は，ソフトウェアに対する要求事項が製品のどの部分で実現されているかを追跡できることをいう．逆に，できあがっているソフトウェアの構成部品（例えば，いくつかの内の一つの実行モジュール）が，どの要求事項を実現するためのものかを追跡できることもいう．

  　ISO9001で要求されているトレーサビリティは，a)だけであるが，TickITではb)のトレーサビリティも要求される．

• 　ソフトウェア製品のトレーサビリティが確保されている状態では，正体不明のものがない．逆に例えば，プログラマが勝手にプログラム仕様書どおりにプログラムを作成せず，１本のプログラムを作成すべきところを２本に分けてしまった場合には，仕様書とのトレーサビリティが確保できず，正体不明のものができていることになる．
• 　不適合の発生を防止するという観点でトレーサビリティに関する要求をどの程度にするかを決めればよい．トレーサビリティを確保していない場合には，「あるリリースで発生した問題が，次のリリースのソフトウェアに解決策が適用されないまま出荷されてしまう．」とか，「特定の顧客にだけ提供していた機能やバグの修正が，新しい製品のリリース時に忘れられてしまい，問題が発生する．」といったトラブルが起きることになる．
• 　通常，ソフトウェアは，コンピュータ上では必ず識別のための情報がついている．識別の規則を体系的に”命名規約”として決めてもよく，また，”同じ名称にならないように任意に付与する”という簡単な手順を識別の方法としてもよい．後者の場合，どのような名称にしたかの管理は必要である．

審査に関連して

• 　あるリリースの製品で発生した問題に対する解決策が，別のリリースでも必要であるかを確認する仕組みがあるか調べるとよい．
• 　未解決のバグに対する特別なプログラムが，責任者の知らない間に顧客に提供されているような状況がないか，注意するとよい．

2000年版では

　製品の識別及びトレーサビリティに関して，1994年版からの実質的な変更はない．但し，2000年版の「7.5.3 識別及びトレーサビリティ」では，1994年版の”検査・試験の状態”に関する要求事項が一緒になっている．

以上
１９９５，２００２　新倉忠隆