（1）システム要件の整理

組み込み製品開発における仕事のやり方として、iTiDコンサルティングとビズモは、関係者間で情報を共有しながらシステムを設計する開発スタイルを提唱する。1つの設計を複数の開発者が創造していけるように、製品の全体像を全員で理解したうえで、それぞれの開発者の知識と労力を共有プール化し、それぞれの開発者へと分割するのである（図3）。

知識と労力の分割手法としては、モジュール化が有効である。モジュール化とは、システム全体を独立性の高い設計領域に「分離・分割」し、複数の設計者が設計したモジュールを組み合わせ、システム全体として機能の実現を保証することである。

モジュール化には、「分離」と「交換」という原則がある。この原則に従って、システム全体の複雑度を下げ、設計変更による影響を最小限にする。つまり、設計要素を、互いに依存関係のない独立したモジュールに分離し、設計要素間の依存関係を減らす。これにより、仕様が同一のモジュールであれば、交換しても、ほかの機能に影響を与えずに済む。これを保証する。

この分割のルールを決めたものが、製品アーキテクチャである。

良い製品アーキテクチャは、メカ、エレキ、ソフトを、同じレベルでモジュール化する。このうえで、構造面での独立性と機能面での統合を管理するための枠組みを提供する。この枠組みに従うことで、設計のモジュール化が可能になり、相互に独立して作業する専門集団を設計できるようになる。

つまり、あらかじめ「デザイン・ルール」を決め、このルールに従って設計する。これにより、各モジュール同士が結合可能で、なおかつ継ぎ目なく動作することを保障する。モジュール化の原則に従ったデザイン・ルールを可視化し、設計者全員で共有することによって、1つのシステムを複数の設計者で設計できるようにする。

本連載では、このためのプラクティス（実践手法）として、（a）「システム要件の整理」、（b）「システム・モデルの作成」、（c）「システム構造の可視化と改善」、を紹介する。以下では、このうち、「システム要件の整理」について解説する。

（1）システム要件の整理

メカ、エレキ、ソフトと、担当の異なる技術者が協調して設計を進めるにあたって、最初に重要となるのは、インプットとなる要件の整理である。

技術者に製品要件を尋ねると、「サイズ・重量」「スピード」「通信の仕組み」「利用するテクノロジ」といった、カタログ・スペックのレベルの製品仕様を提示されることが多い。これは、メカ主導型の開発スタイルをとる開発組織において、特に顕著である。というのも、メカは、これらの情報があれば開発可能だからである。

本稿での製品要件の定義は、「製品で実現する、ユーザー・ニーズや開発者のアイデアを、解釈して体系化したもの。製品の使われ方や利用イメージも含まれる」とする。そして、製品仕様は、これらの要件を根拠とし、合理的に決定される（図4）。

今、われわれが目指そうとしているのは、かつてのプロセス（要件を、メカからエレキへ、エレキからソフトへ、リレー方式で受け渡すタイプ）から、新たなプロセス（全員で情報を共有し、メカ、エレキ、ソフトが同時に設計を開始する、多方向連携タイプ）への変革である。この際に重要となるのが、整理された要件を同時に共有することである。

従来の開発では、「ソフト設計は、開発の終盤にならないと実施できない」という思い込みがあったため、ソフト設計に必要な操作仕様の確定が、開発の後半にずれこむことが多かった。これでは、ソフトウエアの役割が高まっているにもかかわらず、開発後半までQCD（Quality:品質、Cost: コスト、Delivery: 納期）における失敗リスクを抱え込むことにつながる。こうならないように、開発初期から要件を整理し、共有するのである。

開発初期から要件を整理し、共有するためのポイントは、3つある。（1）製品コンセプトの共有、（2）要件を整理するフレームワークの設定、（3）要件の詳細化と構造化、である。以下では、これらについて具体的に解説する。