双方向トレーサビリティという考え方

品質を「保証」するうえで、現在これ以上ないと言ってもいい考え方かもしれません。要するに、

上流フェーズと下流フェーズの紐づき、設計フェーズから製造フェーズ、試験フェーズ間の紐づきなど、上から下へ、右から左へ実現できるものは、逆もまた証明できる。

という考え方ですが、残念ながらこれをきちんと意識して開発できるエンジニアはごくわずかしかいません。でも実はこれ、ソフトウェア開発方法論のありとあらゆるところで求められています。

たとえば、ＣＭＭＩ（Capability Maturity Model Integration ： 能力成熟度モデル統合）。

たとえば、ＱＭＳ（Quality Management System）。
たとえば、ＰＭＢＯＫ（Project Management Body of Knowledge）。

たとえば、A-SPICE（Automotive Software Process Improvement and Capability dEtermination）。

基本的に、作業、業務、タスク、アクティビティ、etc.…呼び方はそれぞれですが、そういった単位ごとに分類された仕事の塊をつなげ、フローにする以上は、どのようなものであっても、必ず求められているものだと思います。

実際、ソフトウェア開発の場合、ベースにＶ字モデルかそれに類するものを採用しているフレームワークであれば、大抵どの開発方法論やマネジメントシステムでも、必ず双方向のトレーサビリティは必須事項となっています。

他にも、トヨタなどが推進している"５なぜの法則"なども、もとはと言えば

　「なぜ、現象・事象として今に至ったのか？」
　「なぜ、そういった現象・事象となるような行動を起こしたのか？」
　「なぜ、どのような行動をとろうと思ったのか？」
　「なぜ、(何の情報を得て)そう思ったのか？」
　「なぜ、その情報は正しいと思ったのか？」

と言うように、根拠のトレーサビリティを検証するために実施しているものです。要するに"因果応報(原因があるから結果があり、結果にはその元となる原因がある)"を具体的に実践しているにすぎません。

トレーサビリティの基本的な要件は、

　①商品・製品などの管理単位を明確にし、
　　それを個別識別して“トラッキング（追跡）”できること
　②その記録をさかのぼって“トレースバック（遡及）”できること

です。これが本当の意味でしっかり実施でき、かつ常に証明できる準備さえできていれば、品質は必ず証明することが可能です。

なぜなら、

　・きちんと設計できていれば、その検証は過不足なく実施できる
　・バグや指摘が出たら、その原因も特定できる
　・バグを改善したら、その原因も消滅できる
　・問題の特定ができたら、混入した理由も時期もわかる
　・混入した理由と時期がわかれば、次から混入させない方策がとれる

と言ったことが可能になるからです。
　
みなさんはどうでしょうか。

たとえば、『詳細仕様書』と呼ばれる成果物を作成するとしましょう。そこに記載する文言の一言一句が、何を基にして作成できているか考えたことはありますでしょうか。

もし、基本設計工程を経ているのであれば、『基本仕様書』がベースになっているはずです。では、その『基本仕様書』に書かれている内容だけで、『詳細仕様書』は構成できていますか？

　「実は打合せで〇〇と言う話があって…」

それは

　・議事録になっていますか？
　・『詳細仕様書』→『議事録』へと追跡できる記述になっていますか？
　・その議事内容はなぜ議事録でとどまっていて、
　　『基本仕様書』に記載していないのですか？

と言う質問に、きちんと答えられないような事態に陥ったりしていませんでしょうか。意外と、頭の中の「こうだと思う」と言う認識だけで設計書やプログラムが出来上がっていたりしませんか？

　「そんなことはない！」

と言う人は、過去に一度も"ケアレスミス"以外のバグを出したことがない人です。非常に優秀と言えるでしょう。

しかし、残念ながらそんな人もプロジェクトも非常に稀で、ほとんど存在しないからこそ不良はあります。出てきます。小規模のプロジェクトであればともかく、中規模以降となると３桁程度の不良／欠陥は当たり前のように出ているのではないでしょうか。
　
もし、この双方向トレーサビリティを通常運用の中で実現できているプロジェクトが、今後出てくるようなことがあれば、ごく当たり前のように非常に高い品質を維持できることは間違いありません（少なくとも、私が考える"品質"に対するコンセプトも、この概念を強く継承しています）。

まずは、完璧でなくてもよいので、"意識的に取り組んでみる"だけでもいかがでしょう。