前回までで、化粧品の自販機についてシステムの内部構造を決めました。システム内部構造は、システムを独立したサブシステムにブレークダウンしたもので、ブロックやモジュールなどチームや技術者が扱える単位まで繰り返します。そして、このブレークダウンは本質的に試行錯誤からなる作業であり、ブレークダウンした結果を評価することができる仕組みを持っていることが重要だとお伝えしました。FURPS+ を使って作成したシステム要件はサブシステムへのブレークダウン結果を評価するために必要だったわけです。
システム設計というのは、このブレークダウンを繰り返し実行して適切な開発単位にすることです。では、システム設計ではいったいどこまでブレークダウンするのでしょうか。それは、その開発プロジェクトのメンバーあるいはサブチームが自分たちで開発を進めることができると思えるところまでです。
システム設計の後はほとんどの場合、ボードや機構やソフトに分かれて、あるいは、機能ブロックごとに分かれて、それぞれの担当者やサブチームで同時並行に開発作業が進められます。このとき、どのようなサブチームで分かれるのか、どのようなスキルのメンバーがいるのかなど様々で、だからこそ、システム設計者は、サブチームやメンバーの実力・能力に合ったアウトプットにするところまでを自分の仕事とする必要があります。
したがって、システム設計は、エンジニアリングの責任者、つまり、プロジェクトの中で技術的な中心人物が担当することが大切です。一人ではなく数人ということもあるでしょうが、開発プロジェクトメンバーの中でトップレベルのシステム設計スキルを持ち、製品全体の設計に責任を持つことができる人たちが、一元的にシステム設計を行う体制になっていることが要求されます。
サブシステムと呼ぶのか、ブロックと呼ぶのか、モジュールと呼ぶのかはいろいろでしょうが、システム設計によりサブチームあるいは技術者が開発作業を行うことができる単位にブレークダウンしたものを、ここではサブシステムと呼ぶことにします。また、開発を進めるのはサブチームとしましょう。サブチームは、サブシステムが何を作ればよいのかが明確に把握できる状態になっていないと開発作業を進めることができません。作るもののゴールを明確にするということことです。それでは、自販機の例を使って実際にやってみましょう。
図77はサブシステムにブレークダウンしたシステムの内部構造です。システム要件一つひとつについて動作を検証したもので、サブシステム間にその一部を記載しています。細かなと...
