Club-Zコラム第26回

印刷用表示 | テキストサイズ 小 | 中 | 大 |


clubZ_info_renewal.jpg

| HOME | コラム | グローバル化は設計・製造の仕組みを見直すチャンス | 第26回 | P1 |

更新日 2016-01-20 | 作成日 2007-12-03

コラム


グローバル化は設計・製造の仕組みを見直すチャンス

【第26回】システム設計は仮説と検証の繰り返し

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


2009.10.29

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

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


前回は、システム(ここでは製品も含めてシステムと呼ぶことにします)に必要とされる要件を漏れなくリストアップする方法について解説しました。化粧品の自販機を例題にして、漏れなく要件を考えるための手法として FURPS+ を紹介し、品質特性に注目して要件をリストアップすることや、その品質特性は形を変えながらブレークダウンされるものであることなどを説明しました。これにより、そのままでは曖昧な顧客や企画部門からの要求やニーズが、製品開発におけるシステム設計の入力として適切なレベルの要件となったわけです。

次に行うことは、開発すべきシステムをハードウェアやソフトウェアといったサブシステムに分けて、それぞれの要件を明確にすることです。サブシステムは、ハードやソフトという単位に分かれることもあれば、ユーザインタフェース・サブシステム、処理エンジンサブシステム、出力サブシステムというように、ハードやソフトを含む機能単位に分かれることもあります。今のところ、どのようなサブシステムにするのかについては、これまでの製品開発の流れや開発者の経験などにより決まるものと考えておきましょう。また、サブシステムではなく、ブロックと呼んでいたりモジュールと呼んでいたり、開発現場によって様々だと思いますが、ここではサブシステムで統一したいと思います。

まず、わかっていただきたいことは、サブシステムに分ける作業は本質的に試行錯誤となる作業だということです。仮説と検証を繰り返しながら徐々にサブシステム構成を改善することが、適切なサブシステム構成を作るための確実な方法なのです。そして、この試行錯誤のために必要となるのが、仮説として考えたサブシステム構成の良し悪しを検証する手段、手法が確立していることです。仮説を評価できなければよりよいものにすることはできません。

この検証作業の基本は、作成したシステム要件を実現するためにサブシステムがどのような処理の流れ、データ・信号の流れとなるのかを明らかにし、どのようなサブシステム間のやりとりになっているのかを確認することです。複雑な処理ややりとりになっている場合は、サブシステムを見直してより簡単なやりとりにできないかを考えます。この試行錯誤が適切にできるかどうかがカギとなります。経験を積んでいる人やセンスが良い人というのは、最初の仮説のレベルが高かったり、少ない試行錯誤でシンプルなやりとりにすることができるということなのですが、このような人であっても、頭の中でこの試行錯誤をやっているのであって、試行錯誤なしにはシステム設計を行うことはできません。ましてや、システム設計経験が浅かったり、飛び抜けたセンスを持っていない場合は、この試行錯誤がどれだけできるのかがシステム設計の良し悪しに直結します。今回紹介するサブシステム構成の検証方法を確立・定着させ、試行錯誤の時間をできるだけ確保することにエネルギーを使うことができるような仕組みを作ってほしいと思います。