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

   続きを読むには・・・


この記事の著者

石橋 良造

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

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


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

もっと見る
環境 普通の組織をイノベーティブにする処方箋 (その42)

        現在、この連載ではマクロ環境分析の解説をしていますが、今回は、PESTEL(Politica...

        現在、この連載ではマクロ環境分析の解説をしていますが、今回は、PESTEL(Politica...


関係性の種類、並列とは 普通の組織をイノベーティブにする処方箋(その96)

   現在、KETICモデルの中の「知識・経験を関係性で整理する」を解説しています。今回は、下記(5)の並列について解説します。 ◆関連...

   現在、KETICモデルの中の「知識・経験を関係性で整理する」を解説しています。今回は、下記(5)の並列について解説します。 ◆関連...


自社コア技術の強化のための技術 普通の組織をイノベーティブにする処方箋 (その33)

        前回までは自社のコア技術を拠り所にして外部技術を活用する方法として、「その1:自社のコア技術...

        前回までは自社のコア技術を拠り所にして外部技術を活用する方法として、「その1:自社のコア技術...


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

もっと見る
女性視点の製品アイデア発想事例

 「女性活躍推進」に優れた「なでしこ銘柄」と呼ばれる上場企業が、平成25年度で26社存在します。しかし、私もソニー時代からハードウェアエンジニアですが、モ...

 「女性活躍推進」に優れた「なでしこ銘柄」と呼ばれる上場企業が、平成25年度で26社存在します。しかし、私もソニー時代からハードウェアエンジニアですが、モ...


設計部門とリスク管理(その1)

【設計部門とリスク管理 連載目次】 1. リスク管理とは目標達成までのシナリオ作成 2. コンティンジェンシープランの注意事項 3. リスク管理...

【設計部門とリスク管理 連載目次】 1. リスク管理とは目標達成までのシナリオ作成 2. コンティンジェンシープランの注意事項 3. リスク管理...


グループシンクとチームダイナミクスの境界線

1. イノベーション戦略    私は、ものづくり企業のR&Dにおける技術力・価値創造力を向上するための取り組みを「イノベーション戦略...

1. イノベーション戦略    私は、ものづくり企業のR&Dにおける技術力・価値創造力を向上するための取り組みを「イノベーション戦略...