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

   続きを読むには・・・


この記事の著者

石橋 良造

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

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


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

もっと見る
関係性の種類、重複とは 普通の組織をイノベーティブにする処方箋(その95)

   現在、KETICモデルの中の「知識・経験を関係性で整理する」を解説しています。今回は、下記の(4)重複(一部を共有)について解説しま...

   現在、KETICモデルの中の「知識・経験を関係性で整理する」を解説しています。今回は、下記の(4)重複(一部を共有)について解説しま...


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

  【この連載の前回へのリンク】 現在「切り取った知識の重要部分を発想するフレームワークを使って、イノベーションを発想する」にむけて、日...

  【この連載の前回へのリンク】 現在「切り取った知識の重要部分を発想するフレームワークを使って、イノベーションを発想する」にむけて、日...


短期開発プロセスのしくみづくり(その3)

【短期開発プロセスのしくみづくり 連載目次】 1. リードタイムが長くなる理由 2. 短期開発プロセスのしくみ構築を進めていく方法 3. 短期開...

【短期開発プロセスのしくみづくり 連載目次】 1. リードタイムが長くなる理由 2. 短期開発プロセスのしくみ構築を進めていく方法 3. 短期開...


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

もっと見る
研究開発の進め方とは

     1. 研究・開発の流れ  私の行っている技術分野では以下のような流れで商品化されます。 材料研究 ...

     1. 研究・開発の流れ  私の行っている技術分野では以下のような流れで商品化されます。 材料研究 ...


品質の仕組みとは2 プロジェクト管理の仕組み (その28)

 品質の仕組み、前回に続いて解説します。今回は、品質計画についてです。    計画の重要性は ISO9001でも「品質計画」として強調されて...

 品質の仕組み、前回に続いて解説します。今回は、品質計画についてです。    計画の重要性は ISO9001でも「品質計画」として強調されて...


技術資源の有効活用: 事例紹介 (その1)

 今回から2回に分けて、TRMによる活動の事例紹介をいたします。TRM(Technical Resource Management)は自社が保有する潜在的...

 今回から2回に分けて、TRMによる活動の事例紹介をいたします。TRM(Technical Resource Management)は自社が保有する潜在的...