システム設計プロセスがモジュール化を実現
現在の開発プロセスは、本連載でこれまで説明してきたように、メカ主導型のプロセスになっていることが多い。これを変えて、メカ・エレキ・ソフトが同時に設計を始め、全体を俯瞰(ふかん)しながら詳細な議論を行い、全員で検証するプロセスにすることで、製品アーキテクチャの品質が高まり、組み込み製品の品質が向上するのである。
最後に、どのようにすればこのプロセスを実現できるのかを考えてみたい。
ここでは、ルール・ツール・スキルという3つのフレームワークを用いて、このプロセスを実現することを考える。
図3: プロセス変革を実現するフレームワーク |
ルール面では、「要件の整理/共有」、「システム・モデルの作成」、「構造の可視化と改善」、という3つのプラクティスを実装したシステム設計プロセスを確立する。開発の現場で活用できるよう、各プラクティスのトライアルを通して運用方法をルール化する。レビューする内容、検討の深さ、タイミング、レビュー担当者などを明確にするとよい。
ツール面では、各プラクティスに対応したツールを利用して、ルールの順守や定着を図りたい。どのツールが適しているのかは組織の状況にも依存するが、いずれにしても、ツールから入るのではなく、プラクティスを導入して定着させる手段として、ツールを活用するべきである。ツール選びでは、設計者の負担にならず、効率化に寄与するものがよい。筆者が推奨するツールは、以下の通りである。
表1: 各プラクティスで利用できるツール
プラクティス | ツールの名称 | 開発会社 |
---|---|---|
システム要件の整理/共有 | iPrime(注: リンク先はPDF) | 電通国際情報サービス |
システム・モデルの作成 | Enterprise Architect | オーストラリアのSparxSystems |
システム構造の可視化 | Lattix | 米Lattix |
スキル面では、システム設計作業をコーディネートする技術者として、エンジニアリング・ファシリテータを育成する。品質の高いシステム設計を行うのは、ツールでもルールでもなく、技術者自身だからである。要件を整理/共有してシステム・モデルを作成するためには、チームを作り、技術や課題を見える化し、技術者同士のコミュニケーションを促進する必要がある。このため、プラクティスやツールの導入だけで終わらず、開発プロセスを実行できる人材を同時に育成する必要がある。
連載の冒頭で解説したように、組み込み製品の開発現場では、製品機能の高度化という要求に対し、ソフトウエアやネットワークを活用して機能を実現することが加速している。このため、従来のメカニクス中心の開発プロセスにおいては、特にソフトウエアの開発が立ち行かなくなりかねない。このように、開発プロセスの変革が必要になっている状況が散見される。
今回紹介した3つのプラクティス、「システム要件の整理/共有」、「システム・モデルの作成」、「システム構造の可視化と改善」が、プロセス変革の促進や、組み込み製品の品質を高める一助となることを願っている。