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

更新日

投稿日

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

   続きを読むには・・・


この記事の著者

石橋 良造

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

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


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

もっと見る
研究開発部門がとるべきリーダーシップの型、新規事業・新商品を生み出す技術戦略(その97)

【この連載の前回、事業アイディアの企画を後押しする要素、新規事業・新商品を生み出す技術戦略(その96)へのリンク】 ▼さらに深く学ぶなら!「技術マネ...

【この連載の前回、事業アイディアの企画を後押しする要素、新規事業・新商品を生み出す技術戦略(その96)へのリンク】 ▼さらに深く学ぶなら!「技術マネ...


リスクベース設計とは

 今回は、潜在不良流出を防止するリスクベースの設計手法について解説します。設計終了後の評価テストや、製造工程の試験、検査で発見できない不具合が市場で発生す...

 今回は、潜在不良流出を防止するリスクベースの設計手法について解説します。設計終了後の評価テストや、製造工程の試験、検査で発見できない不具合が市場で発生す...


クレーム率シングルppmをゼロに(8) 【快年童子の豆鉄砲】(その63)

  【連関図法で把握した原因に対する対策実施】(前弾からの続き) 【この連載の前回:【快年童子の豆鉄砲】(その62)へのリンク】 【連...

  【連関図法で把握した原因に対する対策実施】(前弾からの続き) 【この連載の前回:【快年童子の豆鉄砲】(その62)へのリンク】 【連...


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

もっと見る
進捗管理の精度を上げる:第1回 プロジェクト管理の仕組み (その13)

 前回は進捗管理の基本的な考え方を紹介しました。今回は、この考え方にしたがってどのような方法で実際に進捗を把握できるのかを紹介したいと思います。具体的な話...

 前回は進捗管理の基本的な考え方を紹介しました。今回は、この考え方にしたがってどのような方法で実際に進捗を把握できるのかを紹介したいと思います。具体的な話...


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

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

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


スーパーマンではなくプロフェッショナルな技術者に(その1)

【プロフェッショナルな技術者 連載目次】 1. 製品開発現場が抱えている問題 2. プロフェッショナルによる製品開発 3. 設計組織がねらい通り...

【プロフェッショナルな技術者 連載目次】 1. 製品開発現場が抱えている問題 2. プロフェッショナルによる製品開発 3. 設計組織がねらい通り...