前回のその44に続いて解説します。
ハードウェア設計の場合も、要件と回路ブロックの仕様（スペック）、回路ブロックのスペックと部品のスペックなどの設計要素間のマッピングが必要になりますし、回路ブロックについては、設計根拠となるシミュレーション結果や実験結果、部品の信頼性データなどとのマッピングも必要になります。ハードウェア設計の場合はソフトウェア設計ほど工程間で明確に分離されていませんが、設計要素間の関連づけを明確にすることの必要性に変わりはありません。
このように、開発工程間の設計要素のマッピングを明確にして、設計要素の網羅性、整合性を確保する設計作業を「Breadth 設計（広がり方向設計）」と呼びましょう。 Breadth 設計は当たり前のことのように感じるかもしれませんが、実施できている開発現場は少ないのが現実です。個別の設計や記述はあるものの、設計要素すべてについて（つまり広さ方向全部について）検討し、その結果を記述することはおろそかになりがちです。たとえば、基本設計工程から詳細設計工程への移行の際、機能とモジュールが１対１に対応していれば問題ないのですが、通常は１つの機能を複数のモジュールで実装したり、複数の機能を１つのモジュールで実装したりする複雑なケースが存在します。このような場合でも、設計文書に記載されているのは、モジュールごとに実装している機能を説明しているだけで、モジュール全体でどのような機能の割り当てにしたのかや、ある機能について他のモジュールとの関連がどのようになっているのかなど、モジュール全体の一覧性やモジュールをまたがった関係などは設計文書に明確に記載されていないことが多いものです。
設計とは工程内での Depth 設計と工程間での Breadth 設計の両方の繰り返しです。この Depth 設計と Breadth 設計が設計の全工程を通じて正しく実施できていると、任意の設計項目について上流から下流までどのようにして設計が進んだのかを、どの時点でも明確に確認することができます。これが、設計におけるトレーサビリティが保証されているということです。
トレーサビリティが保証されていなければ、Depth 設計で機能の詳細化・具体化を慎重に実施したとしても、Breadth 設計が不十分であれば機能の抜けや漏れがないことを保証することができませんし、レビューで確認することもできません。機能とモジュールのマッピングを作成していないために、そもそも機能に抜けがあることに気づかず市場不具合となった、というようなことが起きるのです。
図82.設計トレーサビリティ
設計トレーサビリティが確保できている状態は、図82のように設計の上流から下流までが完全につながっていることを意味します。設計の正当性の保証には、Depth 設計と Breadth 設計の両方が正しく運用されていることが必要なのです。繰り返しになりますが、Breadth 設計は技術者の頭の中の暗黙的な設計作業となっていることが多いことが問題です。このような状態では、たとえば、詳細設計工程で詳細化したモジュールが要求定義工程で詳細化した要件をすべて網羅したものになっているかどうかを確認するのは、非常に大変です。担当している技術者が気づかなければ、第三者がレビューなどで確認するのは困難で、まさに担当者任せとなってしまいます。
Breadth 設計を難しくしている理由のひとつに、設計単位（設計範囲）が設計工程ごとに違うことがあります。たとえば、要求定義工程ではユーザから見た機能（サービス）の分類ごとに要件を文書化し、その単位ごとに詳細化することが多いのですが、基本設計工程ではシステム内部構造上の内部ブロックごとに機能を文書化してあり、この単位で機能の詳細化をしていることが多いと思います。文書化の単位、つまり、設計単位が設計工程ごとに違っているのです。したがって、ある要件がどの機能、どのモジュール、どのテストケースとなって実装されているのかを確認するのは、いくつかの文書をまたがって調べなくてはならないため簡単ではありません。ツール化なども含めて、開発現場に合わせた工夫が必要となります。ただ、このようなことすら認識できていないところも多いのです。
さて、今回は設計におけるトレーサビリティについて解説しました。Depth 設計と Breadth 設計の両方について仕組み化することが大切であることをわかっていただけたと思います。トレーサビリティが保証された設計工程でなければ、設計だけでなくレビューや不具合分析も属人的な作業となり、組織として設計完成度を上げることや保証することは困難です。設計の「見える化」にはトレーサビリティの仕組み化は必要不可欠ですが、仕組み化にあたっては、開発現場ごとの事情や文化を考慮した個別の工夫や対応が必要になります。
