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