Club-Zコラム第27回

【第27回】システム設計はサブシステムの開発目標を与える

株式会社RDPi　　代表取締役　石橋　良造

2009.12.17

執筆者プロフィール
九州大学卒業後、日本HP入社（入社当時はYHP）。電子計測器、半導体計 測システムの研究・開発に従事した後、社内の開発製造革新プロジェクトで、 電気・電子設計およびソフトウェア開発のための統合システムを企画，開発。
この間に、日本HPにおけるソフトウェア・プロダクティビティ・マネジャー を兼務。日本HPの会社分割によりアジレント・テクノロジーに移籍した後、 この経験をもとに社外に対してコンサルティングを実施。その後、株式会社 RDPi を設立。 これまでに、家電、通信、電子機器、自動車業界に数十社の実績を持つ。ビジネスコンサル系とは一味違った開発現場やツールにも精通するコンサルタント。
著書（共著）に「デザイン プロセス イノベーション」「ザ・チェンジ」（どちらも日経BP）。また「日経ものづくり」での連載や「ソフトウェア開発環境展」専門セミナーなどのセミナーも多数実施している。

●Email　：　 ishibashi@rdpi.jp
●株式会社 RDPi　：　http://www.rdpi.jp/
●著書　：　

前回までで、化粧品の自販機についてシステムの内部構造を決めました（このコラムでは製品もシステムと呼んでいます）。システム内部構造は、システムを独立したサブシステムにブレークダウンしたもので、ブロックやモジュールなどチームや技術者が扱える単位まで繰り返します。そして、このブレークダウンは本質的に試行錯誤からなる作業であり、ブレークダウンした結果を評価することができる仕組みを持っていることが重要だとお伝えしました。FURPS+ を使って作成したシステム要件はサブシステムへのブレークダウン結果を評価するために必要だったわけです。

システム設計というのは、このブレークダウンを繰り返し実行して適切な開発単位にすることです。では、システム設計ではいったいどこまでブレークダウンするのでしょうか。それは、その開発プロジェクトのメンバーあるいはサブチームが自分たちで開発を進めることができると思えるところまでです。

システム設計の後はほとんどの場合、ボードや機構やソフトに分かれて、あるいは、機能ブロックごとに分かれて、それぞれの担当者やサブチームで同時並行に開発作業が進められます。このとき、どのようなサブチームで分かれるのか、どのようなスキルのメンバーがいるのかなど様々で、だからこそ、システム設計者は、サブチームやメンバーの実力・能力に合ったアウトプットにするところまでを自分の仕事とする必要があります。

したがって、システム設計は、エンジニアリングの責任者、つまり、プロジェクトの中で技術的な中心人物が担当することが大切です。一人ではなく数人ということもあるでしょうが、開発プロジェクトメンバーの中でトップレベルのシステム設計スキルを持ち、製品全体の設計に責任を持つことができる人たちが、一元的にシステム設計を行う体制になっていることが要求されます。

サブシステムと呼ぶのか、ブロックと呼ぶのか、モジュールと呼ぶのかはいろいろでしょうが、システム設計によりサブチームあるいは技術者が開発作業を行うことができる単位にブレークダウンしたものを、ここではサブシステムと呼ぶことにします。また、開発を進めるのはサブチームとしましょう。サブチームは、サブシステムが何を作ればよいのかが明確に把握できる状態になっていないと開発作業を進めることができません。作るもののゴールを明確にするということことです。

それでは、自販機の例を使って実際にやってみましょう。