トレーサビリティの保証 プロジェクト管理の仕組み (その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 にあるように、要求定義工程では要件、基本設計工程では機能と、設計要素(設計対象)はそれぞれ違っているため、要件を機能に変換する必要があります。また、基本設計工程において、機能の設計中に問題が起きたときには、要求定義工程までさかのぼって要件の変更を行う場合があります。この場合は、機能を要件に変換する必要があります。したがって、要求定義と基本設計の工程間では、要件と機能が相互に変換できるような設計を行い、それを設計文書として残しておく必要があります。要件の各項目に対してどの機能が関係しているのか、反対に、機能の各項目に対してどの要件が関係しているのかがわかる、要件と機能のマッピングが必要になるということです。
 
 同じように、基本設計工程と詳細設計工程間では機能とモジュールのマッピング、詳細設計工程とテスト設計工程間ではモジュールとテストケースのマッピングが必要になります。これらのマッピングが設計文書に記載されることによって、設計の工程移行の際に、設計要素が変わっても抜けや漏れがないことが確認できるわけです。
 
 次回も、トレーサビリティの保証についての解説を続けます。
 
 

   続きを読むには・・・


この記事の著者

石橋 良造

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

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


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

もっと見る
普通の組織をイノベーティブにする処方箋 (その185) 図書館を活用する

  ・見出しの番号は、前回からの連番です。 【目次】 ▼さらに深く学ぶなら!「技術マネジメント」に関するセミナーはこちら!...

  ・見出しの番号は、前回からの連番です。 【目次】 ▼さらに深く学ぶなら!「技術マネジメント」に関するセミナーはこちら!...


MVPの活用 新規事業・新商品を生み出す技術戦略(その82)

  ◆ 研究開発にMVPを活用する  今回は「研究開発にMVPを活用する」をテーマに解説します。  MVPとは、Minimum Via...

  ◆ 研究開発にMVPを活用する  今回は「研究開発にMVPを活用する」をテーマに解説します。  MVPとは、Minimum Via...


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

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

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


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

もっと見る
技術高度化の5戦略

【ものづくり企業のR&Dと経営機能 記事目次】 管理力より技術力を磨け 技術プラットフォームの重要性 手段としてのオープンイノベーション...

【ものづくり企業のR&Dと経営機能 記事目次】 管理力より技術力を磨け 技術プラットフォームの重要性 手段としてのオープンイノベーション...


‐技能と技術の融合化によるITを応用した技術開発‐  製品・技術開発力強化策の事例(その4)

 前回の事例その3に続いて解説します。ITの普及と共に技術者や技能者の質的内容が大きく変化しつつあります。今まで何回もの練習と経験を積む必要性が高かった業...

 前回の事例その3に続いて解説します。ITの普及と共に技術者や技能者の質的内容が大きく変化しつつあります。今まで何回もの練習と経験を積む必要性が高かった業...


作業要素の進捗分析3 プロジェクト管理の仕組み (その20)

 前回のその19:作業要素の進捗分析2に続いて解説します。    一つひとつの作業要素の完了判断は、明確になっている必要があります。改めて作...

 前回のその19:作業要素の進捗分析2に続いて解説します。    一つひとつの作業要素の完了判断は、明確になっている必要があります。改めて作...