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

更新日

投稿日

 前回はシステム設計を、開発工程上はシステムエンジニアリングと、ハードやソフトなどのサブシステムのエンジニアリングの両方と定義しました。ここで、システムエンジニアリングとは、顧客の要望やニーズを整合性や一貫性を保証、あるいは、補完してハードウェアやソフトウェアなどのいくつかのサブシステムにブレークダウンする工程で、これにより、ハードウェア・サブシステムやソフトウェア・サブシステムの要件を明確にする作業です。そして、ハードウェア・エンジニアリングとは、システムエンジニアリングにより明確になったハードウェア・サブシステムの要件をそれを実現するための内部構造や各ブロック仕様、必要な開発作業などにブレークダウンする作業です。ソフトウェア・エンジニアリングなど他のサブシステムのエンジニアリング作業も同様です。今回は、実際にシステム設計の進め方について話をしたいと思います。説明のために自動販売機を開発すると仮定して話を進めたいと思います。
 
 システム設計の最初のステップは、ハードやソフトを含んだシステムに対する要件を明確にすることです。まずは、顧客の要望やニーズを整理します。ここでは、顧客からは以下のような要求があったとします。
 
  【自販機で扱う商品は化粧品】
  【商品は続けていくつも購入することができる】
  【既存の缶ジュース自販機を流用して開発作業を最小限に抑える】
 
 このリストを見てわかるように、顧客からは今までとは違う機能や他社とは違う特徴を伝えられるだけであることが普通です。したがって、ユーザの要望をベースに、システム(製品)として必要な要件を漏れなくリストアップするのは製品開発者の仕事となります。この化粧品の自販機の場合は次のようになります。今回はあくまでも説明のための例として取り上げているので、実際に製品を作るレベルにまでの完成度にはなっていないことにご注意ください。
 
R&D
図69. 主要なシステム要件
 
 図69を見ると、システム(製品)としてユーザに提供するサービスや機能の一覧になっていることがわかると思います。これで十分と考える人もいるでしょうが製品開発としては不十分です。製品としてはもっと細かなところまで詰めておく必要があります。それでは、図70に図69をさらに詳細化してみます。
 
R&D
図70. システム要件
 
 図69と比較して「取り扱い商品の確認」などの6つの大分類は変わらないものの、一つひとつが詳細になっていることがわかると思います。また、今まではユーザを主語にした表現にしていましたが、システムを主語にした表現に変えています。このように、システム(製品)がユーザに...
 前回はシステム設計を、開発工程上はシステムエンジニアリングと、ハードやソフトなどのサブシステムのエンジニアリングの両方と定義しました。ここで、システムエンジニアリングとは、顧客の要望やニーズを整合性や一貫性を保証、あるいは、補完してハードウェアやソフトウェアなどのいくつかのサブシステムにブレークダウンする工程で、これにより、ハードウェア・サブシステムやソフトウェア・サブシステムの要件を明確にする作業です。そして、ハードウェア・エンジニアリングとは、システムエンジニアリングにより明確になったハードウェア・サブシステムの要件をそれを実現するための内部構造や各ブロック仕様、必要な開発作業などにブレークダウンする作業です。ソフトウェア・エンジニアリングなど他のサブシステムのエンジニアリング作業も同様です。今回は、実際にシステム設計の進め方について話をしたいと思います。説明のために自動販売機を開発すると仮定して話を進めたいと思います。
 
 システム設計の最初のステップは、ハードやソフトを含んだシステムに対する要件を明確にすることです。まずは、顧客の要望やニーズを整理します。ここでは、顧客からは以下のような要求があったとします。
 
  【自販機で扱う商品は化粧品】
  【商品は続けていくつも購入することができる】
  【既存の缶ジュース自販機を流用して開発作業を最小限に抑える】
 
 このリストを見てわかるように、顧客からは今までとは違う機能や他社とは違う特徴を伝えられるだけであることが普通です。したがって、ユーザの要望をベースに、システム(製品)として必要な要件を漏れなくリストアップするのは製品開発者の仕事となります。この化粧品の自販機の場合は次のようになります。今回はあくまでも説明のための例として取り上げているので、実際に製品を作るレベルにまでの完成度にはなっていないことにご注意ください。
 
R&D
図69. 主要なシステム要件
 
 図69を見ると、システム(製品)としてユーザに提供するサービスや機能の一覧になっていることがわかると思います。これで十分と考える人もいるでしょうが製品開発としては不十分です。製品としてはもっと細かなところまで詰めておく必要があります。それでは、図70に図69をさらに詳細化してみます。
 
R&D
図70. システム要件
 
 図69と比較して「取り扱い商品の確認」などの6つの大分類は変わらないものの、一つひとつが詳細になっていることがわかると思います。また、今まではユーザを主語にした表現にしていましたが、システムを主語にした表現に変えています。このように、システム(製品)がユーザに提供するサービス/機能を漏れなくリストアップしたものがシステム要件です。このレベルまで詳細化できれば十分だと考える人も多いと思います。しかし、このシステム要件は問題を抱えています。機能にしか注目していないからです。実際、システム設計きちんとやっていて十分に整理しているといっている開発現場であっても、注目しているのが機能だけとなっていることは少なくありません。次回は、「機能以外に注目してシステム要件をリストアップする」を、解説します。
 
 

   続きを読むには・・・


この記事の著者

石橋 良造

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

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


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

もっと見る
改善活動のポイント 開発生産性向上(その4)

【開発生産性向上 連載目次】 1. 生産性向上の必要性 2. ビジネスの質的変化への対応 3. 開発生産性向上施策 4. 改善活動のポイント ...

【開発生産性向上 連載目次】 1. 生産性向上の必要性 2. ビジネスの質的変化への対応 3. 開発生産性向上施策 4. 改善活動のポイント ...


『価値づくり』の研究開発マネジメント (その15)

     今回も、前回から引き続きオープンイノベーションの経済学の6つ目、「オープンイノベーションによる不確実性への対処」です...

     今回も、前回から引き続きオープンイノベーションの経済学の6つ目、「オープンイノベーションによる不確実性への対処」です...


設計部門の仕組み構築 【連載記事紹介】おすすめセミナーのご紹介 

     設計部門の仕組み構築の連載記事が無料でお読みいただけます!   ◆設計部門と製造部門 製造部門における設...

     設計部門の仕組み構築の連載記事が無料でお読みいただけます!   ◆設計部門と製造部門 製造部門における設...


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

もっと見る
設計部門の課題と原因分析(その2)

【設計部門の課題と原因分析 連載目次】 1. 設計部門の現状を正確に特定する 2. 課題分析と課題の根本原因除去 3. 設計部門用に用意したコン...

【設計部門の課題と原因分析 連載目次】 1. 設計部門の現状を正確に特定する 2. 課題分析と課題の根本原因除去 3. 設計部門用に用意したコン...


設計部門の仕組み改革(その1)

【設計部門の仕組み改革 連載目次】 1. システムやツールの導入を伴う設計部門の仕組み改革の進め方 2. 設計部門の仕組み改革、事例解説 3. ...

【設計部門の仕組み改革 連載目次】 1. システムやツールの導入を伴う設計部門の仕組み改革の進め方 2. 設計部門の仕組み改革、事例解説 3. ...


技術経営を考える

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

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