最終回となる今回は，初心者には少々とっつきにくいシステム・デザインを，もっと手軽に始める方法について解説する。新しい製品開発ではなく，現在の製品を題材にシステム・デザインを実践してみるというやり方だ。
アジレント・テクノロジー 電子計測本部 R&D プロセスコンサルティング
多田 昌人
既存の製品を題材にシステム・デザインを実施することを「リキャプチャリング」という＊1。これは，文字通り製品の考え方・情報を「とり直す」こと。設計資料がしっかり残っていない企業や部門は，再度それを「とる」必要があるし，「とる」必要はなくとも「直す」必要がある場合もあるだろう。
つまり，リキャプチャリングの目的は（1）現状の製品の構造を明確にすること（2）最適な設計にすること--の二つだ。一口に最適な設計といっても「性能が出る設計」「品質の良い設計」「再利用性の高い設計」…といろいろだが，どれを目的にしてもよい。要は，製品や組織が抱えている問題を明確に認識してリキャプチャリングすることが重要だ。
＊1 リバース・エンジニアリングと言ってもよいが，一般にリバース・エンジニアリングという単語が持つイメージほど仰々しいものではない。製品を分解して調べるというわけでもない。自分たちの製品を対象に，関係者が集まって明るく，わいわいがやがやと議論を進めるイメージに近い。
リキャプチャリングを説明する前に，これまでに解説したシステム・デザインの流れをおさらいしておこう。システム・デザインは，はじめにマーケットモデルを定義し，続いて顧客モデル，製品モデルへと展開，最後にシステムモデルを構築するという流れだった（図1）。どのモデルでも，要求や機能（F）に対する定義と品質特性（URPS＋）を必ずセットで考え，機能はユース・ケースとして，操作手順はユース・シナリオとして定義。そして，ユース・シナリオを下位のモデルのユース・ケースとして展開する。中でもシステムモデルは，再利用性を高めるために定義すべき論理モデルと，実装可能な設計結果である物理モデルの二つのモデルを内包している。
図1 フォーマルなシステム・デザインの流れ
通常の手順と逆に
リキャプチャリングの最初の段階では，この流れを遡る。最終的には，適切で理解可能なシステムモデルを得るのが目的だが，まず，製品の中身がどうなっているか---から始めるのだ（図2）。しかし，曖昧な記憶で直接製品を調べたり，不十分な資料をあたっていてもシステム内部の見える化や最適化はおぼつかない。情報を「とる」ためには，実際の製品と，その製品のシステム仕様書やサブシステム仕様書，モジュール仕様書などの情報が要る。これらを基に現在の製品のアーキテクチャを「見える化」するのだ。
図2 リキャプチャリングの流れ初めは製品マニュアルのように手軽に用意できて，製品の使い方が網羅できる物を使うのがよいだろう（製品マニュアルでなくとも，販売店向けのトレーニング資料などでも可）。これを基に顧客モデルと製品モデルを定義するのだ。このとき，ある機能（F）に対しては，必ず非機能要件（URPS＋）をセットで定義するようにする（Step 1）。そして，機能を実現するための具体的な手順をユース・シナリオに落とす（Step 2）。
マニュアルの範囲内だけで十分とは限らないので，漏れがないようにさまざまな機能を検討しよう（マニュアルで不足していたユース・ケースは，マニュアルにフィードバックする）。特に保守機能や製造検査のための機能などは忘れがちなので気を付けたい。思いつく限りのFURPS＋を定義したら，システムモデルを検討する準備が整ったということだ。
Step 3では，ユース・ケースから物理モデルを明らかにする。Step 2の顧客モデル，製品モデルを物理モデルにマッピングするということだ。検討対象のユース・シナリオがシステムの中でどのように振る舞うのかを一つひとつ検証していく。
この検証過程で，上位のFURPS＋が，システムの中に実在する要素モジュール （エレ，メカ，ソフト） のFURPS＋に適切に割り振られていることを確認し，文書化しておこう。要素モジュール間のインタフェースも同様だ。作業していく中で，設計上問題がありそうな部分に気付くこともあるだろう。その場合は，しっかりとメモしておこう。今後の最適設計に役立てられる。Step 2で用意したユース・シナリオをすべて検討すればStep 3は完了。この段階で，現在の製品の構造が明確になっているはず。ここまでが，リキャプチャリングの「とる」という作業だ。
