システム設計プロセスがモジュール化を実現

これまでの連載で、組み込み製品の品質を高める、3つのプラクティスを紹介してきた。

• システム要件の整理／共有
• システム・モデルの作成
• システム構造の可視化と改善

今回は、これら3つのプラクティスの内容を総括し、相互の関係を明らかにしたうえで、システム設計プロセスとして提示する。

システム設計プロセスは、大ざっぱに言えば、ユーザーや技術者が抱くさまざまな思いや要望を基に、これらの期待に応える製品案を検討するプロセスである。同プロセスのアウトプット（成果物）はシステム設計案であり、これは前回までの記事で示した、モジュールで構成されたシステム・モデルである。

良いシステム設計を実現するためには、まずインプットとなるシステム要件の整理／共有から始める必要がある。システム要件の整理とは、具体的には以下の3つを実施することである。

1. 製品コンセプトを明確にする。
2. 明確にしたコンセプトを実現する要件フレームワークを設定する。
3. 要件フレームワークに従って要件の背景・理由を明示しながら、機能・性能・仕様を詳細化・構造化する。

システム要件をひととおり整理したら、次に製品構造を明らかにする。この作業がまさにシステム設計の中核の作業といえる。ここでは「広くて浅いモデル」と「狭くて深いモデル」の2つのモデルを使いながら、システム・モデルを作成していく。その手順は以下の通りとなる。

4. 構造化されたシステム要件をもとに「広くて浅いモデル」を作成し、主要なサブシステムを洗い出す。
5. 主要なサブシステムで実現する中核となる機能について、「狭くて深いモデル」を作成する。
6. 「狭くて深いモデル」の作成過程で、中核となる機能を構成する詳細なモジュールを見つける。仕様と個々のモジュールの振る舞いを明確にし、要件を詳細化する。
7. 明らかにした詳細な要件を「システム要件の整理／共有」の成果物に反映し、各設計者に対してフィードバックする。

4～7の作業を繰り返すことにより、システム・モデルの精度を向上させていく。

このときにポイントとなるのは、ソフトウエア構造の定義である。標準的な部品が存在しないソフトウエアは、構造を定義するうえで自由度がかなり高い。これは柔軟な開発が可能なことを意味するが、この反面でソフトウエア構造の品質があまり重要視されず、結果的に動けばよいとの風潮を生んでしまっている。

ソフトウエアの構造を定義する場合、システム全体の振る舞いをある程度詳細に検討する必要がある。つまり、システム設計時にシステムの振る舞いをメカ・エレキ・ソフトの担当者間で詳細に検討し、ソフトウエア構造を含めた設計案を検討すべきである。結果として、設計案の品質確保につなげたい。

システム設計とは、全体的な検討と詳細検討を相互に繰り返しながら設計案を練り上げていくものである。このとき、要件と製品構造の関係の強弱を表形式で表現することで、設計変更の影響範囲を可視化できる（図2）。

この表は、一般的にQFD（品質機能展開）と呼ばれる。システム・モデルが一通り完成した後に、要件と製品構造の関係をあらためて整理するものである。QFDの作成により、要件とその実現手段の関係を明確にすることができ、実現手段が確定していない点を技術課題として洗い出すことができる。洗い出した技術課題を解決することで、システム・モデルの精度が向上する。

通常のシステム設計では、ここまでの手順を踏んで終了する。しかし、筆者は、さらにひと手間加えることを推奨している。つまり、現状のシステム構造を評価／監視し、現実の姿をあるべき姿に近づける活動を、システム設計に組み込むのである。その手順は、下記の通りである。

8. システム・モデルを作成した段階で、検討結果をツールなどで可視化する。
9. これまで解説してきた分離・交換の原則にのっとっているかどうかなど、システムの複雑度や独立性をチェックし、作成したシステム・モデルの品質を測定する。
10. システム・モデルの品質測定結果を基に、原則に反している部分を改善する。

8～10の手順を踏むことで、システム設計のアウトプットを、分離・交換の原則にのっとってモジュール化されたシステム設計案、つまり、良いシステム構造を持ったシステム設計案へと洗練させていくことができる。

以上が、組み込み製品の品質を高めるための、システム設計プロセスである。