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

更新日

投稿日

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

   続きを読むには・・・


この記事の著者

石橋 良造

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

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


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

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

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

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


技術営業とは 【連載記事紹介】

  技術営業とはの連載記事が無料でお読みいただけます!   ◆技術営業とは メーカーにおいて製品・事業を構想する際に、技術...

  技術営業とはの連載記事が無料でお読みいただけます!   ◆技術営業とは メーカーにおいて製品・事業を構想する際に、技術...


体制について 技術企業の高収益化:実践的な技術戦略の立て方(その1)

   2020年、新型コロナウイルスの影響下、このような時期なのですが、中長期の技術戦略を立てたいという会社からの問い合わせを頂いています...

   2020年、新型コロナウイルスの影響下、このような時期なのですが、中長期の技術戦略を立てたいという会社からの問い合わせを頂いています...


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

もっと見る
追求するのは擦り合わせ能力を活かすマネジメント(その3)

 前回のその2に続いて解説します。図15は製品開発(設計)における調整の仕組みを詳細化したものです。「可視化」「分析」「視点切り替え」3つの要素から成り立...

 前回のその2に続いて解説します。図15は製品開発(設計)における調整の仕組みを詳細化したものです。「可視化」「分析」「視点切り替え」3つの要素から成り立...


プロジェクトの問題を見極める1 プロジェクト管理の仕組み (その23)

 進捗管理のための基本メトリクスセットのひとつである開発工数メトリクスについて解説していますが、前回は、プロジェクト構造(WBS)軸とアクティビティ軸のそ...

 進捗管理のための基本メトリクスセットのひとつである開発工数メトリクスについて解説していますが、前回は、プロジェクト構造(WBS)軸とアクティビティ軸のそ...


海外と積極コミュニケートを!

 ものづくりの世界において、大企業の製品はもちろんのこと、海外Makersの新製品情報も早々に目に入ってくるようになりました。KickStarter等のク...

 ものづくりの世界において、大企業の製品はもちろんのこと、海外Makersの新製品情報も早々に目に入ってくるようになりました。KickStarter等のク...