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

更新日

投稿日

◆システム設計は仮説と検証の繰り返し 

 
 前回は、システム(ここでは製品も含めてシステムと呼ぶことにします)に必要とされる要件を漏れなくリストアップする方法について解説しました。化粧品の自販機を例題にして、漏れなく要件を考えるための手法として FURPS+ を紹介し、品質特性に注目して要件をリストアップすることや、その品質特性は形を変えながらブレークダウンされるものであることなどを説明しました。これにより、そのままでは曖昧な顧客や企画部門からの要求やニーズが、製品開発におけるシステム設計の入力として適切なレベルの要件となったわけです。
 
 次に行うことは、開発すべきシステムをハードウェアやソフトウェアといったサブシステムに分けて、それぞれの要件を明確にすることです。サブシステムは、ハードやソフトという単位に分かれることもあれば、ユーザインタフェース・サブシステム、処理エンジンサブシステム、出力サブシステムというように、ハードやソフトを含む機能単位に分かれることもあります。
 
 今のところ、どのようなサブシステムにするのかについては、これまでの製品開発の流れや開発者の経験などにより決まるものと考えておきましょう。また、サブシステムではなく、ブロックと呼んでいたりモジュールと呼んでいたり、開発現場によって様々だと思いますが、ここではサブシステムで統一したいと思います。
 
 まず、わかっていただきたいことは、サブシステムに分ける作業は本質的に試行錯誤となる作業だということです。仮説と検証を繰り返しながら徐々にサブシステム構成を改善することが、適切なサブシステム構成を作るための確実な方法なのです。そして、この試行錯誤のために必要となるのが、仮説として考えたサブシステム構成の良し悪しを検証する手段、手法が確立していることです。仮説を評価できなければよりよいものにすることはできません。
 
 この検証作業の基本は、作成したシステム要件を実現するためにサブシステムがどのような処理の流れ、データ・信号の流れとなるのかを明らかにし、どのようなサブシステム間のやりとりになっているのかを確認することです。複雑な処理ややりとりになっている場合は、サブシステムを見直してより簡単なやりとりにできないかを考えます。この試行錯誤が適切にできるかどうかがカギとなります。経験を積んでいる人やセンスが良い人というのは、最初の仮説のレベルが高かったり、少ない試行錯誤でシンプルなやりとりにすることができるということなのですが、このような人であっても、頭の中でこの試行錯誤をやっているのであって、試行錯誤なしにはシステム設計を行うことはできません。
 
 システム設計経験が浅かったり、飛び抜けたセンスを持っていない場合は、この試行錯誤がどれだけできるのかがシステム設計の良し悪しに直結します。今回紹介するサブシステム構成の検証方法を確立・定着させ、試行錯誤の時間をできるだけ確保することにエネルギーを使うことができるような仕組みを作ってほしいと思います。
 
 それでは、例題である化粧品の自販機についてサブシステムへのブレークダウンをやってみましょう。開発の制約のひとつに「既存の缶ジュース自販機を流用して開発作業を最小限に抑える」というものがありましたので、既存のサブシス...

◆システム設計は仮説と検証の繰り返し 

 
 前回は、システム(ここでは製品も含めてシステムと呼ぶことにします)に必要とされる要件を漏れなくリストアップする方法について解説しました。化粧品の自販機を例題にして、漏れなく要件を考えるための手法として FURPS+ を紹介し、品質特性に注目して要件をリストアップすることや、その品質特性は形を変えながらブレークダウンされるものであることなどを説明しました。これにより、そのままでは曖昧な顧客や企画部門からの要求やニーズが、製品開発におけるシステム設計の入力として適切なレベルの要件となったわけです。
 
 次に行うことは、開発すべきシステムをハードウェアやソフトウェアといったサブシステムに分けて、それぞれの要件を明確にすることです。サブシステムは、ハードやソフトという単位に分かれることもあれば、ユーザインタフェース・サブシステム、処理エンジンサブシステム、出力サブシステムというように、ハードやソフトを含む機能単位に分かれることもあります。
 
 今のところ、どのようなサブシステムにするのかについては、これまでの製品開発の流れや開発者の経験などにより決まるものと考えておきましょう。また、サブシステムではなく、ブロックと呼んでいたりモジュールと呼んでいたり、開発現場によって様々だと思いますが、ここではサブシステムで統一したいと思います。
 
 まず、わかっていただきたいことは、サブシステムに分ける作業は本質的に試行錯誤となる作業だということです。仮説と検証を繰り返しながら徐々にサブシステム構成を改善することが、適切なサブシステム構成を作るための確実な方法なのです。そして、この試行錯誤のために必要となるのが、仮説として考えたサブシステム構成の良し悪しを検証する手段、手法が確立していることです。仮説を評価できなければよりよいものにすることはできません。
 
 この検証作業の基本は、作成したシステム要件を実現するためにサブシステムがどのような処理の流れ、データ・信号の流れとなるのかを明らかにし、どのようなサブシステム間のやりとりになっているのかを確認することです。複雑な処理ややりとりになっている場合は、サブシステムを見直してより簡単なやりとりにできないかを考えます。この試行錯誤が適切にできるかどうかがカギとなります。経験を積んでいる人やセンスが良い人というのは、最初の仮説のレベルが高かったり、少ない試行錯誤でシンプルなやりとりにすることができるということなのですが、このような人であっても、頭の中でこの試行錯誤をやっているのであって、試行錯誤なしにはシステム設計を行うことはできません。
 
 システム設計経験が浅かったり、飛び抜けたセンスを持っていない場合は、この試行錯誤がどれだけできるのかがシステム設計の良し悪しに直結します。今回紹介するサブシステム構成の検証方法を確立・定着させ、試行錯誤の時間をできるだけ確保することにエネルギーを使うことができるような仕組みを作ってほしいと思います。
 
 それでは、例題である化粧品の自販機についてサブシステムへのブレークダウンをやってみましょう。開発の制約のひとつに「既存の缶ジュース自販機を流用して開発作業を最小限に抑える」というものがありましたので、既存のサブシステム構成を活かしたものをサブシステム構成の第1版としました。これを図74 に示します。
 
R&D
図74.サブシステム構成(第1版)
 
 図74 では、サブシステムとして「金銭管理」「商品管理」「操作管理」「状態管理」の4つとしています。既存の自販機システムが金銭、商品、ユーザインタフェース(操作)のブロックに別れており、それぞれを流用することができるだろうという目論見です。繰り返しになりますが、大切なのは、考えたサブシステム構成を検証し、よりよい構成にできる余地があるかどうかを検討できる仕組みです。次回では、実際の検証作業を解説します。
 
 

   続きを読むには・・・


この記事の著者

石橋 良造

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

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


関連する他の活用事例

もっと見る
トレーサビリティの保証 プロジェクト管理の仕組み (その45)

 前回のその44に続いて解説します。    ハードウェア設計の場合も、要件と回路ブロックの仕様(スペック)、回路ブロックのスペックと部品のス...

 前回のその44に続いて解説します。    ハードウェア設計の場合も、要件と回路ブロックの仕様(スペック)、回路ブロックのスペックと部品のス...


‐技能と技術の融合化によるITを応用した技術開発‐  製品・技術開発力強化策の事例(その4)

 前回の事例その3に続いて解説します。ITの普及と共に技術者や技能者の質的内容が大きく変化しつつあります。今まで何回もの練習と経験を積む必要性が高かった業...

 前回の事例その3に続いて解説します。ITの普及と共に技術者や技能者の質的内容が大きく変化しつつあります。今まで何回もの練習と経験を積む必要性が高かった業...


開発工数メトリクス1 プロジェクト管理の仕組み (その21)

 前回のプロジェクト管理の仕組み (その20)に続いて解説します。    進捗管理のための基本メトリクスセットについての解説を続けています。...

 前回のプロジェクト管理の仕組み (その20)に続いて解説します。    進捗管理のための基本メトリクスセットについての解説を続けています。...