Club-Zコラム第28回

印刷用表示 | テキストサイズ 小 | 中 | 大 |


clubZ_info_renewal.jpg

| HOME | コラム | グローバル化は設計・製造の仕組みを見直すチャンス | 第28回 | P3 |

更新日 2016-01-20 | 作成日 2007-12-03

コラム


グローバル化は設計・製造の仕組みを見直すチャンス

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

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


2010.01.21

設計工程をあらわしている図80LinkIconを見ると、Depth 設計とはもう一つ別の設計作業が必要になることに気づくと思います。工程ごとの設計要素を結びつけることです。要求定義、基本設計、詳細設計、テスト設計と順々に設計工程を進めて行くことで設計が進むわけですが、設計工程ごとに設計要素が変わるので、先に進むときには設計要素を変換する必要があります。

column_20100121_5.JPG

たとえば、要求定義工程から基本設計工程に移行する場合、図81 にあるように、要求定義工程では要件、基本設計工程では機能と、設計要素(設計対象)はそれぞれ違っているため、要件を機能に変換する必要があります。また、基本設計工程において、機能の設計中に問題が起きたときには、要求定義工程までさかのぼって要件の変更を行う場合があります。この場合は、機能を要件に変換する必要があります。したがって、要求定義と基本設計の工程間では、要件と機能が相互に変換できるような設計を行い、それを設計文書として残しておく必要があります。要件の各項目に対してどの機能が関係しているのか、反対に、機能の各項目に対してどの要件が関係しているのかがわかる、要件と機能のマッピングが必要になるということです。

同じように、基本設計工程と詳細設計工程間では機能とモジュールのマッピング、詳細設計工程とテスト設計工程間ではモジュールとテストケースのマッピングが必要になります。これらのマッピングが設計文書に記載されることによって、設計の工程移行の際に、設計要素が変わっても抜けや漏れがないことが確認できるわけです。

ハードウェア設計の場合も、要件と回路ブロックの仕様(スペック)、回路ブロックのスペックと部品のスペックなどの設計要素間のマッピングが必要になりますし、回路ブロックについては、設計根拠となるシミュレーション結果や実験結果、部品の信頼性データなどとのマッピングも必要になります。ハードウェア設計の場合はソフトウェア設計ほど工程間で明確に分離されていませんが、設計要素間の関連づけを明確にすることの必要性に変わりはありません。

このように、開発工程間の設計要素のマッピングを明確にして、設計要素の網羅性、整合性を確保する設計作業を「Breadth 設計(広がり方向設計)」と呼びましょう。 Breadth 設計は当たり前のことのように感じるかもしれませんが、実施できている開発現場は少ないのが現実です。個別の設計や記述はあるものの、設計要素すべてについて(つまり広さ方向全部について)検討し、その結果を記述することはおろそかになりがちです。たとえば、基本設計工程から詳細設計工程への移行の際、機能とモジュールが1対1に対応していれば問題ないのですが、通常は1つの機能を複数のモジュールで実装したり、複数の機能を1つのモジュールで実装したりする複雑なケースが存在します。このような場合でも、設計文書に記載されているのは、モジュールごとに実装している機能を説明しているだけで、モジュール全体でどのような機能の割り当てにしたのかや、ある機能について他のモジュールとの関連がどのようになっているのかなど、モジュール全体の一覧性やモジュールをまたがった関係などは設計文書に明確に記載されていないことが多いものです。