図4　合衆国および同盟軍の航空、海上、地上設備と衛星間の軍事ネットワークを管理するSystem of Systemsの例（クリックで拡大）出典：マサチューセッツ工科大学「The Evolution of Systems Engineering in the US Department of Defense」

　このような上位／下位システムの構造および機械工学、電子工学、制御工学、ソフトウェア工学、さらに物理、化学などを複合領域として開発し、また自社開発以外の要素（自動運転であれば走行道路環境など）のライフサイクルを考慮して、反復性のある開発プロセスを実現するためには「システムズエンジニアリング」手法を用いることが有効です。

　日本の製造業は、長年このような領域間のすり合わせ開発を得意としてきましたが、今後開発対象の構造がますます複雑化すると、設計変更に対する影響分析や対策が困難となる、つまり要求に対する追跡性（トレーサビリティー）が問題になるでしょう。システムズエンジニアリングはその問題への解となります。

　複数の領域の人が共通の理解のもと開発を進めるとどうしても恣意（しい）性が入り込んでしまい、またドキュメントベースでは要素間の関係性がつかみにくいため、概念的なモデルをベースとして開発を進めていく手法が理想的です。

　この2つの要素を組み合わせたアプローチが「モデルベースシステムズエンジニアリング（MBSE）」と呼ばれ、昨今のデジタル技術による革新的な製品のための開発基盤として有効と考えられています。

　共通理解のため、モデルは異なる業務領域間で利用できる標準言語で表現される方がよいでしょう。標準言語は何種類かありますが、統合的なシステムのために開発された言語SysMLを例にとって説明します。

　SysMLで表現されたモデルは、「構造」「要求」「振る舞い」「パラメータ制約」という視点で図示されます（図5）。パラメータ制約では物理現象を表現する方程式を扱うことができるため、機械要素や制御のモデル化に適しています。そしてそれらのモデル間の関係性情報が保持されるため、要求など設計変更の際は影響分析を行い、対策を講じることができます。

図5　システムズエンジニアリング言語であるSysMLの4つの要素（クリックで拡大）出典：アクセンチュア

　モデルの関係性と物理的な特性が決まれば、システム全体の振る舞い、性能をシミュレーションすることが可能になります。システムの全体構成が定義できれば、その後サブシステム、各部品／領域単位（機械、電子、制御、ソフトウェア）の詳細設計に移っていきます。それぞれの単位で要求を満たす設計を行い、要求が満たされているかをシミュレーションなどで検証します。その後、サブシステム単位の検証、システム全体の検証が行われます。この全体のプロセスをV字型開発モデルと呼びます（図6）。

図6　V字開発モデル（クリックで拡大）出典：アクセンチュア

　設計が詳細化し、その後また統合した形で検証する上で「もともとどのような要求、性能を実現すべきだったのか？」ということを追跡することは難しいのですが、V字型開発モデルでは、常に大本の要求へつながる追跡性（トレーサビリティー）が保持されています。

　個々の要素の関連性は非常に複雑なため、人ではなくITシステムの活用が適切な解であることが上記フレームワークからお分かりいただけると思います。ITシステムを使う場合も、大きく分けて2つのやり方があります。

業務設計からオーダーメイドでのシステム構築と運用：構想／要件定義から運用まで時間やコストを要しますが、ToBeの姿をそのまま実現できます。ただし、将来の外的要因によって発生が想定されるコスト（ハードウェア老朽化対応、OS更新対応など）も考慮すべきです
専用パッケージを使っての迅速な導入：近年はPLMあるいはソフトウェア開発ツールのベンダーから、システムズエンジニアリング手法を支援するツールが販売されています。ToBeの姿が近いのであればこれらを活用することも選択肢の1つです

業務領域ごとに存在する部品表（BOM）

前のページへ 1|2|3|4 次のページへ