Club-Zコラム第28回

【第28回】トレーサビリティの保証がない設計では不具合はなくならない

株式会社RDPi　　代表取締役　石橋　良造

2010.01.21

このように、設計とは工程内での Depth 設計と工程間での Breadth 設計の両方の繰り返しです。この Depth 設計と Breadth 設計が設計の全工程を通じて正しく実施できていると、任意の設計項目について上流から下流までどのようにして設計が進んだのかを、どの時点でも明確に確認することができます。これが、設計におけるトレーサビリティが保証されているということです。

トレーサビリティが保証されていなければ、Depth 設計で機能の詳細化・具体化を慎重に実施したとしても、Breadth 設計が不十分であれば機能の抜けや漏れがないことを保証することができませんし、レビューで確認することもできません。機能とモジュールのマッピングを作成していないために、そもそも機能に抜けがあることに気づかず市場不具合となった、というようなことが起きるのです。



設計トレーサビリティが確保できている状態は、図82 のように設計の上流から下流までが完全につながっていることを意味します。設計の正当性の保証には、Depth 設計と Breadth 設計の両方が正しく運用されていることが必要なのです。繰り返しになりますが、Breadth 設計は技術者の頭の中の暗黙的な設計作業となっていることが多いことが問題です。このような状態では、たとえば、詳細設計工程で詳細化したモジュールが要求定義工程で詳細化した要件をすべて網羅したものになっているかどうかを確認するのは、非常に大変です。担当している技術者が気づかなければ、第三者がレビューなどで確認するのは困難で、まさに担当者任せとなってしまいます。

Breadth 設計を難しくしている理由のひとつに、設計単位（設計範囲）が設計工程ごとに違うことがあります。たとえば、要求定義工程ではユーザから見た機能（サービス）の分類ごとに要件を文書化し、その単位ごとに詳細化することが多いのですが、基本設計工程ではシステム内部構造上の内部ブロックごとに機能を文書化してあり、この単位で機能の詳細化をしていることが多いと思います。文書化の単位、つまり、設計単位が設計工程ごとに違っているのです。したがって、ある要件がどの機能、どのモジュール、どのテストケースとなって実装されているのかを確認するのは、いくつかの文書をまたがって調べなくてはならないため簡単ではありません。ツール化なども含めて、開発現場に合わせた工夫が必要となります。ただ、このようなことすら認識できていないところも多いのです。


さて、今回は設計におけるトレーサビリティについて解説しました。Depth 設計と Breadth 設計の両方について仕組み化することが大切であることをわかっていただけたと思います。トレーサビリティが保証された設計工程でなければ、設計だけでなくレビューや不具合分析も属人的な作業となり、組織として設計完成度を上げることや保証することは困難です。設計の「見える化」にはトレーサビリティの仕組み化は必要不可欠ですが、仕組み化にあたっては、開発現場ごとの事情や文化を考慮した個別の工夫や対応が必要になります。お困りのことがあればご連絡ください。

では、今回はここまでにしたいと思います。次回もお楽しみに。