トレーサビリティの保証 プロジェクト管理の仕組み (その44)

更新日

投稿日

 前回のその43に続いて解説します。
 
 ハードウェア設計も、ソフトウェア設計ほど明確ではありませんが、同じように開発工程ごとに関連する設計要素を詳細化するのが主要な設計作業です。基本設計工程は、機能ブロックの中の基本回路や部品を詳細化する工程ですし、詳細設計工程は回路モジュールのクロックや信号レベル、部品の細かなスペックなどを詳細化する工程だということができます。
 
 このように、設計工程においてその設計要素を詳細化・具体化する作業を、設計要素をより深く具体化・詳細化するという意味で「Depth 設計(深さ方向設計)」と呼びましょう。 Depth 設計は先を見通しやすい設計作業であり、設計文書を残すことも、設計文書を見て担当者でなくても間違いや考慮漏れなどを指摘することも、比較的容易です。実際、Depth 設計の設計文書作成やレビューがしっかりと実施できている組織は多いと思います。
 
R&D
図80. 開発工程とDepth設計
 
 設計工程をあらわしている図80を見ると、Depth 設計とはもう一つ別の設計作業が必要になることに気づくと思います。工程ごとの設計要素を結びつけることです。要求定義、基本設計、詳細設計、テスト設計と順々に設計工程を進めて行くことで設計が進むわけですが、設計工程ごとに設計要素が変わるので、先に進むときには設計要素を変換する必要があります。
 
R&D
図81.開発工程とBreadth設計
 
 たとえば、要求定義工程から基本設計工程に移行する場合、図81 にあるように、要求定義工程では要件、基本設計工程では機能と、設計要素(設計対象)はそれぞれ違っているため、要件を機能に変換する必要があります。また、基本設計工程において、機能の設計中に問題が起きたときには、要求定義工程までさかのぼって要件の変更を行う場合があります。この場合は、機能を要件に変換する必要があります。したがって、要求定義と基本設計の工程間では、要件と機能が相互に変換できるような設計を行い、それを設計文書として残しておく必要があります。要件の各項目に対してどの機能が関係しているのか、反対に、機能の各項目に対してどの要件が関係しているのかがわかる、要件と機能のマッピングが必要になるということです。
 
 同じように、基本設計工程と...
 前回のその43に続いて解説します。
 
 ハードウェア設計も、ソフトウェア設計ほど明確ではありませんが、同じように開発工程ごとに関連する設計要素を詳細化するのが主要な設計作業です。基本設計工程は、機能ブロックの中の基本回路や部品を詳細化する工程ですし、詳細設計工程は回路モジュールのクロックや信号レベル、部品の細かなスペックなどを詳細化する工程だということができます。
 
 このように、設計工程においてその設計要素を詳細化・具体化する作業を、設計要素をより深く具体化・詳細化するという意味で「Depth 設計(深さ方向設計)」と呼びましょう。 Depth 設計は先を見通しやすい設計作業であり、設計文書を残すことも、設計文書を見て担当者でなくても間違いや考慮漏れなどを指摘することも、比較的容易です。実際、Depth 設計の設計文書作成やレビューがしっかりと実施できている組織は多いと思います。
 
R&D
図80. 開発工程とDepth設計
 
 設計工程をあらわしている図80を見ると、Depth 設計とはもう一つ別の設計作業が必要になることに気づくと思います。工程ごとの設計要素を結びつけることです。要求定義、基本設計、詳細設計、テスト設計と順々に設計工程を進めて行くことで設計が進むわけですが、設計工程ごとに設計要素が変わるので、先に進むときには設計要素を変換する必要があります。
 
R&D
図81.開発工程とBreadth設計
 
 たとえば、要求定義工程から基本設計工程に移行する場合、図81 にあるように、要求定義工程では要件、基本設計工程では機能と、設計要素(設計対象)はそれぞれ違っているため、要件を機能に変換する必要があります。また、基本設計工程において、機能の設計中に問題が起きたときには、要求定義工程までさかのぼって要件の変更を行う場合があります。この場合は、機能を要件に変換する必要があります。したがって、要求定義と基本設計の工程間では、要件と機能が相互に変換できるような設計を行い、それを設計文書として残しておく必要があります。要件の各項目に対してどの機能が関係しているのか、反対に、機能の各項目に対してどの要件が関係しているのかがわかる、要件と機能のマッピングが必要になるということです。
 
 同じように、基本設計工程と詳細設計工程間では機能とモジュールのマッピング、詳細設計工程とテスト設計工程間ではモジュールとテストケースのマッピングが必要になります。これらのマッピングが設計文書に記載されることによって、設計の工程移行の際に、設計要素が変わっても抜けや漏れがないことが確認できるわけです。
 
 次回も、トレーサビリティの保証についての解説を続けます。
 
 

   続きを読むには・・・


この記事の著者

石橋 良造

組織のしくみと個人の意識を同時に改革・改善することで、パフォーマンス・エクセレンスを追求し、実現する開発組織に変えます!

組織のしくみと個人の意識を同時に改革・改善することで、パフォーマンス・エクセレンスを追求し、実現する開発組織に変えます!


「技術マネジメント総合」の他のキーワード解説記事

もっと見る
顧客の声を聴くとは 新規事業・新商品を生み出す技術戦略(その49)

        今回は一部に賛否両輪がささやかれる「顧客の声を聴く」がテーマです。    売れ...

        今回は一部に賛否両輪がささやかれる「顧客の声を聴く」がテーマです。    売れ...


イノベーション 普通の組織をイノベーティブにする処方箋 (その139)

  今回は、現在の「イノベーションを起こすためには」の解説から、ちょっと逸脱して、「イノベーションとは」の再考をしてみたいと思います。 ...

  今回は、現在の「イノベーションを起こすためには」の解説から、ちょっと逸脱して、「イノベーションとは」の再考をしてみたいと思います。 ...


1400件の顧客特許を読んだらどうなるか~技術企業の高収益化:実践的な技術戦略の立て方(その17)

【目次】 今回は、ある技術者の変身のお話です。半年前まで営業の下請け的に開発するのが仕事だと思っていた技術者が、顧客の潜在ニーズを先...

【目次】 今回は、ある技術者の変身のお話です。半年前まで営業の下請け的に開発するのが仕事だと思っていた技術者が、顧客の潜在ニーズを先...


「技術マネジメント総合」の活用事例

もっと見る
製品設計におけるトレードオフのコントロールとは

        今回は、次のような想定で、製品設計におけるトレードオフのコントロールをどう考えればよいかを解...

        今回は、次のような想定で、製品設計におけるトレードオフのコントロールをどう考えればよいかを解...


擦り合わせ能力を活かすマネジメントとは(その1)

  前回は、「擦り合わせ型開発」と「組み合わせ型開発」のモデルを使って、開発体制について考察しました。擦り合わせ型開発と組み合わせ型開発それぞれ...

  前回は、「擦り合わせ型開発」と「組み合わせ型開発」のモデルを使って、開発体制について考察しました。擦り合わせ型開発と組み合わせ型開発それぞれ...


設計部門の仕組み改革(その2)

【設計部門の仕組み改革 連載目次】 1. システムやツールの導入を伴う設計部門の仕組み改革の進め方 2. 設計部門の仕組み改革、事例解説 3. ...

【設計部門の仕組み改革 連載目次】 1. システムやツールの導入を伴う設計部門の仕組み改革の進め方 2. 設計部門の仕組み改革、事例解説 3. ...