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

   続きを読むには・・・


この記事の著者

石橋 良造

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

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


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

もっと見る
知識・経験を物理量で整理する 4要素 普通の組織をイノベーティブにする処方箋 (その68)

 前回から「知識・経験を物理量で整理する」解説を始めていますが、今回は前回の解説を整理します。 ◆関連解説記事『技術マネジメントとは』 1. 要素...

 前回から「知識・経験を物理量で整理する」解説を始めていますが、今回は前回の解説を整理します。 ◆関連解説記事『技術マネジメントとは』 1. 要素...


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

  ・見出しの番号は、前回からの連番です。 【目次】 国内最多のものづくりに関するセミナー掲載中! ものづく...

  ・見出しの番号は、前回からの連番です。 【目次】 国内最多のものづくりに関するセミナー掲載中! ものづく...


活動で考慮すべきこと 2 開発効率を上げる(その7)

     【開発効率向上の重要性 連載目次】 製造業の生産性 開発効率向上の重要性 開発効率向上活動の考え方 ...

     【開発効率向上の重要性 連載目次】 製造業の生産性 開発効率向上の重要性 開発効率向上活動の考え方 ...


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

もっと見る
進捗の見える化:第3回 プロジェクト管理の仕組み (その12)

 前回の進捗の見える化:第2回に続いて解説します。    最後は、プロジェクトの入力である開発工数です。これで、基本メトリクスセットすべてに...

 前回の進捗の見える化:第2回に続いて解説します。    最後は、プロジェクトの入力である開発工数です。これで、基本メトリクスセットすべてに...


技術者の創造性とモチベーションを引き出すマネジメントとは

◆ 技術者の創造性とモチベーションを引き出すマネジメントとは 失われた20年の間に日本はグローバルな競争力を著しく低下させてしまいました.日本の賃金...

◆ 技術者の創造性とモチベーションを引き出すマネジメントとは 失われた20年の間に日本はグローバルな競争力を著しく低下させてしまいました.日本の賃金...


手戻りのフィードバック・ループを小さくするとは プロジェクト管理の仕組み (その9)

 ソフトのモジュール作成(プログラム作成)は機能セット単位にスケジュールするのが基本となります。そして、機能セットごとのモジュール作成は、詳細設計、コーデ...

 ソフトのモジュール作成(プログラム作成)は機能セット単位にスケジュールするのが基本となります。そして、機能セットごとのモジュール作成は、詳細設計、コーデ...