システム設計1 プロジェクト管理の仕組み (その33)

更新日

投稿日

 コンサルタントとして多くの開発現場に入ると、普段使っている単語、もしくは意味しているものが開発現場によって想像以上に違うことを実感します。たとえば、「レビュー」という基本的な単語ひとつとっても、開発工程ごとに完了確認を行うための公式な会議を意味する開発現場もあれば、技術者同士が議論しながら設計を確認することを意味する開発現場もあります。そうすると、「レビューはきちんとやっています」と話してくれたとしても、開発工程ごとに適切な中間成果物が作成されたことを、組織として客観的に確認していると言うことなのか、技術者が行う設計作業の一貫として他の技術者に自分の設計結果を見てもらうと言うことなのか、その発言が意味する内容は大きく違ってしまいます。
 
 「システム設計」も、開発現場によってその位置づけや作業内容が想像以上に違う言葉のひとつです。そもそも、開発の上流工程が明確になっていないと言うこともあるのですが、開発現場によって対象となる領域が、ハードウェアだけなのかソフトウェアだけなのか、それともハードとソフトを併せた製品あるいはシステム全体なのかも違いますし、仕様や顧客要求を詳細化することを指すのか、仕様や顧客要求を製品やシステムの構造に変換(マッピング)することを指すのかという開発工程上の位置づけも違います。
 
 ここでは、システム設計を図67 のように定義したいと思います。図67 は開発の上流工程を記述したものですが少し解説しておきます。一番左にあるのがエンドユーザや顧客の要望、ニーズですが、それらはエンドユーザの言葉で記述されたものですから整合性や一貫性は保証されていません。これをハードウェア、ソフトウェア、その他いくつかのサブシステムに分けて、相互に不整合がないように要件を整理する作業を「システムエンジニアリング」工程と定義しています。さらに、システムエンジニアリングで明確になったハードウェア要件は「ハードウェアエンジニアリング」により、ハードウェアの仕様や内部構造、必要な開発作業などに分解(展開)されます。同様にソフトウェア要件は「ソフトウェアエンジニアリング」によりソフトウェア仕様、ソフト内部構造、必要な開発作業などに分解(展開)されます。
 
 このように開発工程を定義したとき、「システムエンジニアリング」と「ハードウェアエンジニアリング」「ソフトウェアエンジニアリング」などのサブシステムごとのエン...
 コンサルタントとして多くの開発現場に入ると、普段使っている単語、もしくは意味しているものが開発現場によって想像以上に違うことを実感します。たとえば、「レビュー」という基本的な単語ひとつとっても、開発工程ごとに完了確認を行うための公式な会議を意味する開発現場もあれば、技術者同士が議論しながら設計を確認することを意味する開発現場もあります。そうすると、「レビューはきちんとやっています」と話してくれたとしても、開発工程ごとに適切な中間成果物が作成されたことを、組織として客観的に確認していると言うことなのか、技術者が行う設計作業の一貫として他の技術者に自分の設計結果を見てもらうと言うことなのか、その発言が意味する内容は大きく違ってしまいます。
 
 「システム設計」も、開発現場によってその位置づけや作業内容が想像以上に違う言葉のひとつです。そもそも、開発の上流工程が明確になっていないと言うこともあるのですが、開発現場によって対象となる領域が、ハードウェアだけなのかソフトウェアだけなのか、それともハードとソフトを併せた製品あるいはシステム全体なのかも違いますし、仕様や顧客要求を詳細化することを指すのか、仕様や顧客要求を製品やシステムの構造に変換(マッピング)することを指すのかという開発工程上の位置づけも違います。
 
 ここでは、システム設計を図67 のように定義したいと思います。図67 は開発の上流工程を記述したものですが少し解説しておきます。一番左にあるのがエンドユーザや顧客の要望、ニーズですが、それらはエンドユーザの言葉で記述されたものですから整合性や一貫性は保証されていません。これをハードウェア、ソフトウェア、その他いくつかのサブシステムに分けて、相互に不整合がないように要件を整理する作業を「システムエンジニアリング」工程と定義しています。さらに、システムエンジニアリングで明確になったハードウェア要件は「ハードウェアエンジニアリング」により、ハードウェアの仕様や内部構造、必要な開発作業などに分解(展開)されます。同様にソフトウェア要件は「ソフトウェアエンジニアリング」によりソフトウェア仕様、ソフト内部構造、必要な開発作業などに分解(展開)されます。
 
 このように開発工程を定義したとき、「システムエンジニアリング」と「ハードウェアエンジニアリング」「ソフトウェアエンジニアリング」などのサブシステムごとのエンジニアリングを「システム設計」と定義します。したがって、システム設計の対象領域は製品(システム)全体、および、そのサブシステムであるハードウェア全体やソフトウェア全体となります。また、開発工程としては、仕様を詳細化する工程も、仕様から内部構造に変換(マッピング)する工程も含まれます。
 
R&D
図67. システム設計とは
 
 次回は、開発現場で起きているシステム設計の問題について解説します。
 
 

   続きを読むには・・・


この記事の著者

石橋 良造

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

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


関連する他の活用事例

もっと見る
イノベーションに取り組む第1歩はR&D

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

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


スペック追及は技術開発の目標ではない

 技術開発には必ず目標があります。すなわち、いつまでに何を達成するかを決めて技術開発プロジェクトは進められます。技術開発前の探索プロジェクト以外は、できる...

 技術開発には必ず目標があります。すなわち、いつまでに何を達成するかを決めて技術開発プロジェクトは進められます。技術開発前の探索プロジェクト以外は、できる...


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

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

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