MILTERMでは、2021年に2020年11月公開の「米国防総省のミッション・エンジニアリング・ガイド」を紹介してきたところである。その際、この文書でいうところの「ミッション」を記述した「統合レベルや各軍種レベルのコンセプトやドクトリン文書」の重要性にも触れたところである。その後、米国をはじめとする西側の軍事組織では、ロシア・ウクライナ戦争をはじめとする実際の戦争や紛争から得られた教訓に基づき作戦コンセプトや軍事ドクトリンの検討進化が進んでいると思われる。第1版のミッション・エンジニアリング・ガイドは、デジタル・エンジニアリングを活用しながら、効果的な装備品等の開発に大いに活用されていると推察するところである。

米国防総省は、昨年10月に「第1版のミッション・エンジニアリング・ガイド」を更新している。

「Office of the Under Secretary of Defense for Research and Engineering」のHP（Mission Engineering – ASD(MC) (cto.mil)）には以下の記述がある。

「本書の第2版は、国防総省ミッション・エンジニアリング・ガイド（MEG）バージョン1.0（2020年11月）に代わるものである。ミッション・エンジニアリング・ガイド（MEG）バージョン2.0は、ミッション・エンジニアリングの原則、方法論、および特性を理解する上で、現在および将来の実務者を支援するためのリソースとして機能する。ミッション・エンジニアリング・ガイド（MEG）は国防総省のマニュアル、指示、または指令ではなく、むしろミッション・エンジニアリング・ガイド（MEG）はミッション・エンジニアリングの学際的プロセスを記述するものである。この拡張可能で拡張性のあるプロセスは、ミッションの文脈の中でシステムやシステム・オブ・システム（SoS）を評価することに関連する質問に答えるのに役立ち、望ましいミッションの成果をもたらすために、現行および創発的な能力のデザインと統合に情報を提供する。2020年11月の初版発行以来、ミッション・エンジニアリング・ガイド（MEG）は、省内外の多様なミッション・エンジニアのコミュニティによる実践的な検討と実施を経てきた。今回の改訂では、ミッション・エンジニアリング・プロセスの本質的な方法論と基本的な要素は維持されている。ミッション・エンジニアリング・ガイド（MEG）バージョン2.0では、ミッション・エンジニアリングのベストプラクティス、用語、活動、成果物について明確化し、それを拡張することで、ミッション・エンジニアリング・プロセスの目的、適用、利点について、初心者と熟練者の双方が明確に理解できるようにしている」

限られた防衛費の中で、有効な装備品を開発していこうとする中で、ミッション・エンジニアリングの意味合いを再認識して、更にその普及を図っていることが読み取れる。米国の取組みであるが、大いに参考になる文書と言えるのではないか。（軍治）

米国防総省

ミッション・エンジニアリング・ガイド

第2版

Department of Defense

Mission Engineering Guide

Version 2.0

October 1, 2023

研究・エンジニアリング担当 国防次官室

ミッション能力

Office of the Under Secretary of Defense for Research and Engineering

Mission Capabilities

 

1.0 導入：INTRODUCTION

1.1 背景：Background

国防総省が統合部隊に対し、ミッションを成功裏に遂行するために必要な能力、技術、およびシステムを提供すべく取り組んでいる中、ミッション・エンジニアリングの実務者は、本ガイドに記載されているプロセスを活用することで、ギャップの特定と分析に役立つだけでなく、どの能力、技術、およびシステムがミッションの成果を向上させることができるかを判断することもできる。

米国防総省は、組織的到達目標（organizational goals）の達成に向けた資源配分を確実にするため、作戦と支援活動に対するミッション重視のアプローチをますます重視するようになっている。ミッション・エンジニアリングは、システム、脅威、作戦コンセプト、環境、ミッション・アーキテクチャの変更に基づくミッションの成果への影響をよりよく理解し、評価するためのプロセスである。

ミッションに基づくデータ主導のアウトプットは、取得、研究開発、作戦コンセプトに情報を与えるだけでなく、「重要なミッション要件の実行に必要なシステムズ・オブ・システムズ（SoS）の統合（一体化）性と相互運用性の評価」にも役立つ[1]。ソフトウェア・ツールを使用してデジタル・エンジニアリングを行うことにより、国防総省は、意思決定のための情報の質と堅牢性を向上させる定量的な結果を提供することができる[2]。

国防長官室と軍事部門は、軍事的ニーズとソリューションを特定し、ミッション全体にわたる取引を模索し、作戦コンセプトを成熟させ、要件と資源の計画策定を導き、実験に情報を提供し、プロトタイプの選定やプログラムの決定を行うために、ミッション・エンジニアリングを利用している[3]。ミッション・インテグレーション管理（MIM）を可能にする技術的サブ要素として、ミッション・エンジニアリング・プロセスはまた、ポートフォリオ管理の意思決定に情報を提供する[4]。

1.2 ミッション・エンジニアリング・ガイドの目的：Purpose of the Mission Engineering Guide

国防総省のミッション・エンジニアリング・ガイド（MEG）は、実務者や専門家に対し、ミッション・エンジニアリングの概要と理解を深めるための重要な文書である。このガイドには、学際的なミッション・エンジニアリングのプロセス、その重要な要素、および関連する用語の詳細な説明が含まれている。

ミッション・エンジニアリング・ガイド（MEG）は、ミッション・エンジニアリングの実施方法に関するステップ・バイ・ステップのハンドブックではない。むしろ、ミッション・エンジニアリング・ガイド（MEG）は、範囲、複雑さ、時間に基づいて様々な問題に対処するために調整できる、拡張可能で適応可能な方法論の概要を示している。具体的には、ミッション・エンジニアリング・ガイド（MEG）は次のようなものである。

▪ ミッション・エンジニアリングの方法論とその主な特徴を説明する。

▪ ミッション・エンジニアリングを実行し、厳密な分析成果物を開発するための指針を提供する。

▪ ミッション・エンジニアリングを実施する際のベスト・プラクティスと留意点をアドバイスする。

▪ さまざまな習熟レベル、さまざまな専門分野の背景を持つミッション・エンジニアリング実務者に、ミッション・エンジニアリング活動の実施プロセスについて情報を提供する。

▪ ミッション・エンジニアリング用語を定義する。

2.0 ミッション・エンジニアリング：MISSION ENGINEERING

2.1 概要：Overview

ミッション・エンジニアリング・プロセスは、ミッションを構成要素に分解し、エンド・ツー・エンドのミッション遂行における関係や影響を調査、評価するものである。ミッション・エンジニアリングは、ミッション全体のギャップ、問題、機会を特定、定量化するために使用され、潜在的な能力ソリューション（物資（materiel）、または、非物資（non-materiel））の有効性を評価することにより、ミッションの成果を向上させ、これらの問題に対処しようとするものである[5]。

ミッション・エンジニアリングの結果は、軍事的要求、取得、研究、開発に関する意思決定に役立つだけでなく、定性的分析から定量的分析への早期の移行を可能にする。この方法論は、戦闘員が定義した脅威情報に基づく作戦状況の中で、測定可能な要素を含むエンド・ツー・エンドのミッション・アプローチを評価するものである。

ミッション・エンジニアリングは、ミッションへの影響に基づき、システムまたはシステムズ・オブ・システムズ（SoS）のデザインと統合（一体化）に関する検討事項、作戦コンセプト、および、ドクトリン、組織、訓練、資材、リーダーシップ・教育、人事、施設、政策（DOTMLPF－P）におけるトレードオフに情報を提供するため、ミッションの文脈の中で、物資（materiel）および非物資（non-materiel）を問わず、さまざまな潜在的ソリューションを評価することができる。

ミッション・エンジニアリングは、ミッションの成果に影響を与えるシステムやシステムズ・オブ・システムズ（SoS）の特性、パフォーマンス・パラメータ、機能、特徴についての理解を深めることにより、システムズ・エンジニアリングのプロセスに直接応用することができる。ミッション・エンジニアリングの到達目標（goal）は、意図したミッションの成果を達成するために適切なものを特定する（すなわち、技術、システム、システムズ・オブ・システムズ（SoS）、またはプロセス）ことによってミッションを工学的にデザイン（to engineer missions）し、ミッションに基づいたインプットをシステム・エンジニアリング・プロセスに提供、国防総省が物事を正しく構築するのを援助する。

ミッション・エンジニアリングの結果は、様々な目的に利用される。例えば、得られた知見は、技術投資への情報提供、現行システムの代替利用方法の提案、ミッション・ギャップの特定、および、これらのギャップに対処するための望ましいアプローチの特定、能力ギャップを満たすための新規取得開始のきっかけとなる。

ミッション・エンジニアリングの結果は、能力ベース分析[6]の要件を満たすこともあれば、代替案分析[7]の出発点となることもある。図2ー1は、コンセプトから能力開発、取得に至るまで、ミッション・エンジニアリング成果物の様々な消費者を示している。

図2ー1.ミッション・エンジニアリング・アウトプットの消費者

2.2　ミッション・エンジニアリングの方法論：Mission Engineering Methodology

ミッション（Missions）とは、特定の目標を達成するために実施される作業や行動のことである[8]。ミッション・エンジニアリング・プロセスは、ミッションの複雑さ、機能的ミッション・レベル（すなわち、戦略的、作戦的、戦術的）、データの利用可能性、およびミッション・エンジニアリング活動の意思決定上の必要性に基づいて、範囲を設定することができる。

この方法論は、リスクと変革の機会を事前に特定する、ミッション全体で特定された問題を解決する、あるいは、ミッションとその活動環境に対する潜在的な「もしや（what if?）」の変化を探るなど、実務者の到達目標（goals）に応じて適応させることができる。

図2－2に示されるプロセスは、必ずしも個別のステップの連続ではなく、プロセスを通じてより多くの情報が得られるにつれて、反復的に実行することができる。この方法論は、意思決定者に助言するための正当な証拠を提供することができる、反復可能で追跡可能な結果と成果物を生み出すべきであり、後続の分析に情報を提供するために活用されるべきである。

図2－2.ミッション・エンジニアリング・プロセスの要素

2.3 考慮事項：Considerations

2.3.1 ミッション・エンジニアリングにおけるデジタル・エンジニアリング：Digital Engineering in Mission Engineering

デジタル・エンジニアリング（digital engineering）の原則は、ミッション・エンジニアリング・プロセスに適用することで、モデルとデータの一貫性と再利用を可能にする連続性をサポートする[9]。デジタル表現と成果物の使用は、多様な利害関係者間でコミュニケーションを図る技術的手段と、データに基づいた定量的なアウトプットを提供する手段の両方を提供し、より良い情報に基づいた意思決定をもたらす。

デジタル・ツールやモデル・ベース・エンジニアリング・アプローチを使用することで、ミッション・アーキテクチャを特定のシナリオ内でデジタル・ミッション・モデル（digital mission models）として表現することができる。これらのツールやアプローチを使用することで、ミッション・タスクからソリューションまでの追跡可能性（traceability）が可能になる。また、これらのツールは、成果物の再利用を可能にし、必要に応じた更新や変更を容易にする。デジタル・リンクと追跡可能性（traceability）により、ミッション・エンジニアリングの入力と成果物の強力な構成管理が可能になる。

さらに、汎用目的モデリング言語、オーバーレイ、スタイル、およびフレームワーク－例えば、システム・モデリング言語（SysML）、ビジネス・プロセス・モデルおよび表記法（BPMN）、統一アーキテクチャ・フレームワーク・モデリング言語（UAFML）、統一モデリング言語（UML）－の使用により、企業全体で共通の理解、共有、および成果物の再利用が可能になる。

必要な範囲、成果物、および忠実度に応じて、ミッション・エンジニアリングの実施に使用できるさまざまなデジタル・ツールがある。デジタル・ツールの例としては、物理ベース、振舞いベース、効果ベースのシミュレーションや、モデルベース、エンタープライズ・アーキテクチャ・ソフトウェアなどがある。これらのツールは、エンド・ツー・エンド・ミッションに影響を与える様々な要因を追跡、分析、評価するための定量的手段、すなわち計算および論理的手段を提供する。

2.3.2 ミッション・エンジニアリング・プロセス全体の堅牢性と透明性：Robustness and Transparency Across the Mission Engineering Process

ミッション・エンジニアリングの方法論は、ミッションの課題に対処するため、あるいはミッション全体の技術の統合（一体化）の機会を捉えるための複数の選択肢を検討するためにデザインされたものである。この方法論は、さまざまな不確定要素に対応した代替のミッション手法や感度の有効性を比較する手段を提供し、ミッション空間を探査して、能力の交換や投資のバランスを図るための選択肢を提供するものである。

ミッション・エンジニアリング・プロセスに透明性を持たせるため、実務者は、分析結果を左右する前提条件、制約条件、使用データ・ソース、およびその他の要因を文書化すべきである。データ、手法、インプット、および分析デザインに影響を及ぼす要因の可視性を高めることで、利害関係者および意思決定者は、活動のアウトプットと所見についてよりよく理解し、信頼性を得ることができる。

併せて、ミッション・エンジニアリングの方法論の堅牢性と透明性により、実務者は互いの研究をよりよく理解し、結果の信頼性を高めることができる。

2.3.3 再利用－データと成果物のキュレーション：Reuse––Curation of Data and Products

適切で信頼できるデータ・ソースがなければ、ミッション・エンジニアリングのプロセスを完了することすら不可能になりかねない。ミッションの複雑さと範囲に基づいて、ミッションを特徴付け、ミッション・エンジニアリング（ミッション・アーキテクチャの策定とミッション・エンジニアリング分析の実施）に必要なモデルを開発するためには、大規模なデータセットが必要となる場合がある。

ミッション・エンジニアリング分析を支援するデータセットには、ミッションと活動コンセプト、活動環境と地理的地域、赤部隊（red-force）と青部隊（blue-force）の構造と戦闘序列（orders of battle）、システムまたはシステムズ・オブ・システムズ（SoS）のパラメータと運用コンセプトに関する詳細が含まれる。また、類似または関連するトピックを扱った、他の完成済み分析（例えば、エンジニアリングレベルの分析）の記録も貴重である。

実務者は、国防総省、その他の米国政府パートナー、学界、産業界、および国立研究所に可能な限り広く網を張り、関連するソース・データを収集すべきである。評価の対象となる活動や代替的なミッション・アプローチが異なれば、より多くの情報が必要となるため、データの収集と保存はミッション・エンジニアリング全体を通じた反復プロセスとなる。

データ・ソースは、開発された成果物の妥当性を確保し、適切な忠実性、すなわち正確性、精度、統計的信頼性の結果が得られるよう、信頼できるものでなければならない。必要なデータセットが入手できない場合は、合理的な仮定が必要となる。

実務者は、ミッション・エンジニアリングのためのデータセットを開発する際、以下の要素を考慮すべきである：

▪ 適時性––データが最後に更新されたのはいつか?

▪ 系統－データのソースは何か?ソースは信頼できるものか?

▪ 忠実度－データの品質に対する信頼度はどの程度か?

▪ 妥当性－データは完全か?データは合意された定義とどのように一致するか?

▪ リンケージ－データはどのように生成、変換、または収集されたか?データはどのようなミッション・エンジニアリング活動と関連付けられたか?

▪ ストレージ－データをカタログ化して取得するにはどうすればよいか？他のどのようなデータセットと局所的に関連しているか?

ミッション・エンジニアリングは、現在および過去のミッション・エンジニアリング活動から得られたデータ成果物の保存と維持、すなわちキュレーション[10]を促進することにより、同省のエンジニアリング、取得、作戦の各事業に付加価値を与える。

プロダクト・キュレーションとは、特定の分析の結果と推奨事項だけでなく、仮定、制約、情報源、モデル、および収集したデータを記録することを指す。これらの要素のキュレーションは、その後のミッション・エンジニアリング活動の出発点として役立つ。

データを保持する場合、実務者はそのデータが最初に使用された背景を明確に説明すべきである。そうすることで、将来の利用者が新たな文脈でデータを再利用することが適切かどうかを評価するのに十分な情報を提供することができる。

実務者は、ミッション・エンジニアリング活動全体を通じて開発・使用されるモデルとデータセットのライブラリを作成し、データ・ソースを文書化することを検討すべきである。新しい情報が開発され、収集されれば、脅威、作戦コンセプト（CONOPS）、およびシステムのパフォーマンス・データの変化を反映するために、モデル内のデータを更新することができる。

データセットは、ウォーゲーム、演習、開発・運用試験、実験、実証から生成・収集することができる。例えば、実験から得られたデータや結果は、潜在的なドクトリン、組織、訓練、資材、リーダーシップ・教育、人事、施設、政策（DOTMLPF－P）ソリューションが実装可能かどうか、あるいは関連するライブ（物理的）、バーチャル、またはコンストラクティブな場において主張されたパフォーマンスを有するかどうかに関する貴重な情報を提供する。時間の経過とともに、適切に管理されたデータセットは、ミッション・エンジニアリング活動から得られるモデルや結果の忠実度を高める。

3.0 ミッションの問題または機会：MISSION PROBLEM OR OPPORTUNITY

ミッション・エンジニアリング・プロセスを効果的なものにするためには、ミッション・エンジニアリングの取組みの明確な範囲を策定し、それに合意することに重点を置いた綿密な計画策定が必要である。綿密な計画により、ミッション・エンジニアリング・プロセス全体を通じて決定されたオプション、パラメータ、および制約の整合性が保たれ、取組みの意図に遡ることができるようになる。

加えて、十分に構造化された計画によって、長期的なリードタイムを要する要素が即座に開始され、ミッション・エンジニアリング活動の全体的な実施と実行が集中して成功するようになる。

したがって、ミッション・エンジニアリングは、その目的を明確に理解することから始めなければならない。専門家は、ミッションのギャップ、問題点、機会など、その取組みの原動力となるものを要約した文言で、その目的をとらえなければならない。この目的を明確にすることで、ミッション・エンジニアリング活動の焦点をさらに絞り込み、その範囲を拡大する一連の明確な質問を導き出すことができる。

3.1 ミッションとミッション・エンジニアリングの目的の特定：Identify Mission and Mission Engineering Purpose

ミッション・エンジニアリングは、次の2つの基本要素－ミッションは何か？そのミッションについて何を調査すべきか？－を特定することから始まる。これらの要素は、その後に続くミッション・エンジニアリング活動の計画を立てる上で極めて重要である。

ミッション・エンジニアリングの目的、つまり何を調査するかは、次の4つの形式のいずれかになる。

▪ 潜在的なギャップを特定し、望ましいミッション結果を達成する能力の不足を定量化する。

▪ ミッションの因果関係、つまり感度分析を調べて、ミッションの結果に影響を与える要因をより深く理解する。

▪ ミッション内の既知のギャップを解決するために、潜在的なソリューションのトレードスペースを評価する。

▪ 新しい技術、能力または作戦コンセプトの変更または統合（一体化）を含む、新しい機会のミッションへの影響を調査する

当初から、どのような到達目標（goal）や決心に対して情報を提供するのかを明確に理解することが重要である。意思決定の必要性を理解することで、ミッション・エンジニアリング調査の「だから何なのか（So What）」に対処する取組みが集中する。これらの決定は、活動のための具体的な質問と、結果、所見、結論から必要とされる忠実性の程度と分析的厳密性のレベルを導くものである。

3.2 調査の質問の決定：Determine Investigative Questions

目的文（purpose statement）は、ミッション・エンジニアリングの作業範囲を狭める1つ以上の重要な質問を提起することによって、さらに深められる。ミッション・エンジニアリングの方法論の後続の活動は、これらの質問に答えるために遡る。質問は、活動の目的に対処するための分析的アウトプット、すなわち、意思決定、デザインに情報を与えるものでなければならない。

この質問は、分析デザインに使用する代替的なミッション・アプローチの選択の指針となり、主要な尺度（measure）と指標（metrics）の開発への道筋を示すものでなければならない。このように、これらの質問は、忠実性、すなわち、分析アウトプットとデータ・インプットの正確性、精度、信頼性にさらに磨きをかけるべきである。表3－1に、目的文（purpose statements）に沿った調査項目の例を示す。

表 3-1.問題や機会の範囲を絞り込むための目的文（purpose statements）と質問の例。

例 1: 能力のギャップを特定する: 西島嶼地域に焦点を当てた2040年基地防衛シナリオでは、統合部隊は基地防衛ミッションを遂行する予定であり、ミッション目標を達成する必要がある。（この例では、ミッション能力の不足を明らかにすることが目的である） 現在予想されるアセットの利用可能性と弾薬在庫に基づき、統合部隊はそのミッション目標を達成できるのか？ もしそうでないなら、なぜか？統合部隊がそのミッション目標を達成するのを妨げている制限要因やギャップは何か？

例 2: 原因と結果を探る: 西島嶼地域に焦点を当てた2040年基地防衛シナリオにおいて、青のミッション・アセットの25％が利用できない場合の統合部隊の基地防衛ミッション遂行能力を評価する。（すなわち、目的は、統合部隊がミッション目標をどの程度達成できるかを問うことである） 青のアセットが 25% 削減されると、ミッションの成果はどのように変化するか? 青のアセットの数が変化（減少または増加）するにつれて赤が消耗することに対する感度はどの程度か? 青のアセットの数を変更すると、青のアセットの全体的な残存性が向上するか? 消費される兵器や弾薬の総数に変更はあるか?

例 3: ギャップに対する取引ソリューション: 西島嶼地域に焦点を当てた2040年の基地防衛シナリオでは、統合部隊は、紛争環境での基地防衛ミッションを遂行するための位置・航法・タイミング（PNT）能力を欠いている。（この例では、ギャップを埋め、ミッションの成果を向上させる潜在的なソリューションを評価することが目的である） 代替の位置・航法・タイミング（PNT）技術の使用は、基地防衛ミッションの成功にどのような影響を与えるか？ 悪環境下での代替の位置・航法・タイミング（PNT）技術のパフォーマンスはどの程度か?

例 4: 機会の調査: 西島嶼地域に焦点を当てた2040年の基地防衛シナリオでは、基地防衛ミッションを支援するための新しい能力が配備される。（この例では、目的は、新しい能力を統合（一体化）する際のミッションの影響を評価することである） 統合部隊は、ベースラインのミッション・アプローチと比較して、この能力を活用することにより、その目標を達成する上でより効果的であるか。（ミッション・エンジニアリングの取組みに対処するために、ミッションをどのように遂行するかについて合意された出発点－ミッション、シナリオ、エポックによって決定される－） ミッションの成功は、兵器の消費を抑えて達成できるのか?プラットフォームの残存性は向上しているか? この能力のソリューションを採用するために追加の能力又は技術が必要か?

3.3 利害関係者の特定と関与：Identify and Engage with Stakeholders

ミッション・エンジニアリングの目的を策定する際、実務者はその活動を支援する主要な利害関係者を特定すべきである。利害関係者とは、ミッション・エンジニアリングの結果によって情報を得る者、また、ミッション・エンジニアリングの結果を利用して取組みを支援したり、十分な情報に基づいた意思決定を行ったりする者のことである。利害関係者には、エンドユーザー、スポンサー、リーダー、意思決定者などが含まれる。

新たなミッション能力を特定するためには、重要なスキルセット、専門分野、および人的リソースの開発と調整が必要になることがある。事業体全体のリーダーと実務者は、このようなニーズを認識し、できる限り早期にそのニーズを満たすよう調整すべきである。効果的な利害関係者の関与により、データ、情報、および仮定の検証・妥当性確認によってミッション・エンジニアリングの取組みを支援できる専門家を特定することができる。

4.0 ミッションの特徴付け：ISSION CHARACTERIZATION

目的の文と調査項目は、分析のために特定のミッションの文脈に置かれる。ミッション（missions）とは、特定の目標を達成するための目的を特定したタスクと行動のことである[11]。

ミッションの情報源の例としては、統合用兵コンセプト（Joint Warfighting Concepts）、作戦コンセプト（CONOPS）、および作戦計画がある。ミッションの文脈は非常に重要である。文脈は、ミッションの成果や意思決定に影響を与えうる重要な変数を提供する。ミッションを特徴づけるこれらの変数には、目標、作戦に関連する要因、および環境の状態が含まれる。

また、ミッションの文脈には、目的の文の調査事項に対応するミッションの尺度（measure）と指標（metrics）を導き出すのに十分な情報を含めるべきである。さらに、ミッションの文脈は、ミッションを遂行することで、どの程度、望ましい結果（desired outcomes）と最終状態（end-state）が達成できたかを評価するのに役立つべきである。

軍隊のドクトリンは、戦いの3つのレベルを次のように定義している。

戦略的、作戦的、戦術的－戦術的行動を国家目標の達成に結びつけるものである。これらのレベル間には明確な限界や境界線はないが、指揮官が作戦を立案し、同期させ、資源を配分し、ミッションを適切な指揮に割り当てるのに役立つ。戦略的、作戦的、または戦術的な運用目的は、目標、ミッション、またはタスクの本質に依存する[12]。

これらのレベルは重複する傾向があるが、一般的に、シナリオとヴィネットによって定義される目標とミッションの両方の文脈に沿ったものである。図4－1を参照。

図4-1.戦いのレベル、ミッションのタイプ、および文脈の特徴付けの間の一般化された階層的かつ重複した関係。

4.1 ミッションの文脈の開発：Develop Mission Context

ミッションの文脈とは、ミッション・エンジニアリングの焦点となる背景設定、条件、時間枠、作戦戦略、ミッションの目標であり、重要な質問に答えるためのものである。この情報の集合がシナリオであり、戦役から派生したものである。

シナリオは、ミッションの具体的な記述と意図、すなわちその目標と作戦コンセプト（CONOPS）を、関連するエポックと関連する作戦・環境条件とともに把握する。条件とは、環境と軍事作戦の記述的変数であり、割り当てられたミッションの文脈におけるタスクの実行に影響を与えるものである。条件は次のように分類できる。

▪ 物理的環境（例えば、海の状態、地形、天候）

▪ 作戦的環境（例えば、能力の運用に影響を与え、指揮官の決心に影響を及ぼす条件、状況、影響）

▪ 機能的要素とそれらの関係（例えば、割り当てられた部隊、脅威、指揮・統制、行動のタイミング）

▪ 情報的環境

これら一連の条件は、実行とミッションの結果に影響を及ぼしうる。シナリオは、ヴィネット（Vignettes）と呼ばれる、より小さな要因のサブセットに分解することができる。ヴィネットは、シナリオの最も重要な側面、すなわち、調査項目への取組みに関連するフェーズまたはセグメントに集中するため、より狭いフレーム化される。国防計画シナリオと統合部隊作戦シナリオは、シナリオとヴィネットの作成に活用できるソース文書の一例である。

以下は、ミッションを特徴づける際の一般的な考慮事項である。

ミッションの目的は何か？ミッション目標は、指揮官の意図と、成功を構成する条件、状況、および事象を記述するものである。ミッションの目的は、多くの場合、戦略的到達目標（strategic goal）から始まり、作戦目標に細分化され、さらに、与えられたシナリオやヴィネットの戦術的効果に洗練される、という階層的なものである。

ミッションが発生するのはいつか（すなわち、どのエポックまたはタイムフレームか）。ミッションの時間枠は、戦力の配置（実戦配備され、展開され、利用可能となる能力、技術、またはシステム）、および、作戦計画と政策上の意味合いを理解する上で重要である。

ミッションはどこで行われるのか？ミッションに関連する地理的、地政学的環境とは何か。ミッションの実施場所は、ミッションの実施場所（戦域、作戦地域など）だけでなく、ミッションの実施に関連する地政学的な考慮事項についても記述する。

関与しているのは誰か（戦闘員と非戦闘員、友軍、敵対部隊、中立部隊など）。使用可能な兵力については、青（米軍）、緑（同盟国）、白（非戦闘員または中立国）、赤（敵対者）の兵力と戦闘序列（orders of battle）を記載する。

ミッションはどのように実行されるか？エンド・ツー・エンドのミッションを遂行するために行われる一連の作戦上の出来事（すなわち、ミッションのアプローチ）。

図4-2.ミッションの特徴付けの概要

4.2 ミッションの尺度と指標の定義：Define Mission Measures and Metrics

ミッションの尺度（measure）と指標（metrics）は、与えられたミッションのアプローチの最終状態（end-state）または到達目標（goals）を評価し、ミッションの成果に寄与する要素を評価するための手段である。尺度（measure）と指標（metrics）は、反復可能で曖昧さのない客観的な目標値と閾値から選択され、目的文（purpose statement）が扱うべき調査上の質問と決定を最も直接的に知らせる。

成功の尺度（MOSs）－作戦環境における全体的なミッションの中で成功するための測定可能な属性またはターゲット値であり、通常、青部隊のミッション目標によって推進される。

効果の尺度（MOEs）－成功の尺度（MOS）を達成するためのタスクや活動を実行することによって得られる、測定可能な軍事的効果や成功のターゲット値。

パフォーマンスの尺度（MOPs）－ミッション・タスクまたは軍事効果を遂行するために使用されるシステムまたは行為主体の測定可能なパフォーマンス特性またはターゲット・パラメータ。

ミッション・エンジニアリングの目的には、全体的なミッション目標とそれに関連するタスクを達成するための目的と手段の論理的分解を提供する尺度（measure）と指標（metrics）の階層がある。通常、ミッションが成功したか否かを判断するために評価すべき全体的な作戦目標がある。

成功の尺度は、この目標を定量化し、目的文（purpose statement）を支え、調査上の質問に答えるのに役立つ。これらの尺度は、ミッションの成果または最終状態（end-state）への影響を定量化するのに役立つはずである。成功の尺度は、国防計画シナリオのような、特定のミッションやシナリオを記述した資料から導き出すことができる。成功の尺度（MOS）の例としては、統合部隊は5日以内に敵対者の艦隊の70%を撃破しなければならない、というものがある。

一つ以上の効果の尺度（MOE）は、成功の尺度（MOS）を特徴付けるのに役立つ。効果の尺度（MOE）は、様々な行為主体のタスク遂行を評価する手段を提供する。効果の尺度（MOE）の変更（例えば、所定の能力の向上）は、観測結果をもたらし、成功の尺度（MOS）に関連する感度の理解を深めるのに役立つ。効果の尺度（MOE）の例としては、破壊された赤色アセットの数と追跡されたターゲットの数がある。

成功の尺度（MOS）、効果の尺度（MOE）、パフォーマンスの尺度（MOP）の例 敵の大規模な地上攻勢を阻止する統合部隊のミッションでは、（成功の尺度（MOS）によって定義された）ミッションの成功は、友軍の支配下にある戦域の面積を測定することによって評価することができる。その面積に変化がなければ、敵の攻勢は阻止され、ミッションは成功したことになる。 統合部隊航空構成部隊指揮官（JFACC）は、（効果の尺度（MOE）によって定義された）ミッションの有効性を、 ターゲットとした敵部隊のうち、まとまった小隊サイズ以上の編隊で友軍と接触した数を測定することによって 評価することができる。その数が少なく、友軍を守り、敵の攻勢を効果的に鈍らせることができれば、統合部隊航空構成部隊指揮官（JFACC）は青部隊の取組みは効果的であり、正しいことをしたと結論づけることができる。 統合部隊航空構成部隊指揮官（JFACC）は、敵の後続部隊に対して成功裏に飛行した阻止出撃の回数を測定することで、（パフォーマンスの尺度（MOP）によって定義された）「青の」部隊のパフォーマンスを評価することができる。青部隊が損失なしに予定された出撃回数以上を飛行した場合、統合部隊航空構成部隊指揮官（JFACC）は青部隊が正しいことを行っていると評価できる[13]。

各行為主体（すなわち、ミッション・アプローチにおける能力、技術、システム、および要員）の具体的なパフォーマンスを特徴づける属性は、1つまたは複数のパフォーマンスの尺度（MOP）を表す。一般に、パフォーマンスの尺度（MOP）は測定可能なデータ・ポイントであり、ミッション・エンジニアリング活動の開発および実行を支援するためのインプットとして収集される。パフォーマンスの尺度（MOP）が追跡されるにつれて、効果の尺度（MOE）や成功の尺度（MOS）にも相関的な変化が生じる可能性がある。パフォーマンスの尺度（MOP）の例としては、ミサイル速度、射程距離、機動性、弾頭サイズ、致死性、残存性などがある。

尺度（measure）と指標（metrics）は、目的文（statement of purpose）に沿って選択され、適用範囲が定められるべきである。尺度（measure）と指標（metrics）は、ミッション全体の要因がより完全に理解され、さまざまな潜在的ソリューションが調査されるにつれて進化する。関連する尺度（measure）と指標（metrics）は、以下を特定した後に現れる：1） 目的文（purpose statement）、調査上の質問、意思決定の必要性、2）ミッションとその目標、3）ミッション・アプローチのタスク、割り当てられた行為主体。

質の高い成功の尺度（MOS）は、目的文（purpose statement）に関連する興味あるミッションと調査上の疑問に沿ったものである。効果の尺度（MOE）とパフォーマンスの尺度（MOP）は、成功の尺度（MOS）に直接貢献するように定義され、必要に応じて収集される。効果の尺度（MOE）とパフォーマンスの尺度（MOP）は、成功の尺度（MOS）が達成されているかどうか、および達成に寄与する要因を説明するのに役立つ。

選択された尺度（measure）と指標（metrics）の取得によって得られたデータと観測結果は、将来の分析のために保存しておくべきであり、改訂されたベースライン・ミッションのアプローチに情報を提供したり、これまでに得られた知見に基づいて後続の取組みを加速するのに役立てたりすることができる。質の高い尺度（measure）と指標（metrics）には、次のような特徴がある。

▪ 一貫性と再現性－後続の反復、取引、代替的なミッション・アプローチにまたがって採点する。

▪ 関連性と必要性－目的文（purpose statement）に対処する。

▪ ソリューションにとらわれない－特定のミッション・アプローチやソリューションに偏らない。

▪ 測定可能－直接観測された、あるいは導き出されたスケールを表す。

図4－3は、システム・レベルからミッション目標までの尺度（measure）と指標（metrics）の関連を示している。効果の尺度（MOE）とパフォーマンスの尺度（MOP）は、タスクからシステム、そして成功の尺度（MOS）に至るまで、ミッション・アーキテクチャを通じてつながっている。このバランスにより、分析において有効な尺度（measure）と指標（metrics）を使用することができる。

図4-3 システムまたはシステム・オブ・システムからミッション・レベルへの尺度（measure）と指標（metrics）のリンク

5.0 ミッション・アーキテクチャ：MISSION ARCHITECTURES

ミッションのアーキテクチャは、どのような活動、タスク、イベントがミッションにとって不可欠であり、これらの活動がエンド・ツー・エンドのミッション目標を達成するためにどのように実行されるかという構造をとらえたものである。ミッション・アーキテクチャは、ミッション内の要素の関係、順序、実行、情報交換、ドクトリン、組織、訓練、資材、リーダーシップ・教育、人事、施設、政策（DOTMLPF－P）の考慮事項、および結節点のつながりを示すものである。

ミッション・アーキテクチャは、一方における軍事作戦と、他方における機能性との架け橋となるものである。さらに、ミッション・アーキテクチャには、ミッション目標を達成するために必要なタスクを完了するための戦術とタイミングを反映させるべきである。

ミッション・エンジニアリングでは、ミッション・アーキテクチャには2つの重要な要素がある。すなわち、1）ミッション・スレッド、所定のミッション・アプローチ・アクティビティを捕捉するもの、2）ミッション・エンジニアリング・スレッド（METs）である。これらの要素は、行為主体、システム、および組織に関連するミッション活動が、シナリオおよび関連するヴィネットでとらえた特定のミッションの文脈でどのように実行されるかをとらえるものである（図5－1参照）。ミッション・アーキテクチャは、多くのミッション・スレッドとミッション・エンジニアリング・スレッド（METs）で構成される、織り込まれたエフェクト・ウェブ、またはキル・ウェブと考えることができる。

ミッション・アーキテクチャは、あるミッションを実施するための代替のミッション・アプローチを、ベースラインのミッション・アプローチと比較する手段を提供するものである。ミッション・アーキテクチャをデジタル的に表現するために使用するモデルやデータは、目的文（purpose statement）、調査上の質問、および特定のミッションの状況に対処するために必要な詳細レベルに合わせて調整する必要がある。ミッション・スレッドとミッション・エンジニアリング・スレッド（METs）の作成は反復プロセスである。

ミッション・アーキテクチャを文書化する方法は複数あり、ビジネス・プロセス・モデルおよび表記法（BPMN）、統一モデリング言語（UML）、システム・モデリング言語（SysML）、統一アーキテクチャ・フレームワーク・モデリング言語（UAFML）、その他の国防総省標準アーキテクチャ・ビューなど、ミッション・スレッドやミッション・エンジニアリング・スレッド（METs）を記述するために使用できる表記法もいくつかある。

図5-1.作戦上の視点（上、シナリオ）からアプローチ（中央、ミッション・スレッド）を経て、行為主体とシステムの割り当て（下、MET）に至るミッション・アーキテクチャの要素の関係。

5.1 ミッション・スレッド：Mission Threads

ミッション・スレッドは、作戦上のミッション目標を達成するためのエンド・ツー・エンドのミッション・アプローチにおける一連の出来事、活動、決定、相互作用を特徴づけるものである。ミッション・スレッドは、イベントの連鎖におけるタスクの実行順序を記述するものであり、フロー内の各活動を誰がどのように達成するのかを記述するものではない。

ミッション・スレッドは、ミッションを遂行するためのアプローチにおける一連のタスク、活動、イベントを記述する。 ミッション・エンジニアリング・スレッドは、ミッションを遂行するためのアプローチにおいて、タスク、活動、イベントを実行する行為主体（人、システム、組織など）を割り当てる。 実務者は、利害関係者や専門家とともに、導き出されたミッション・スレッドを検証すべきである。

しかし、統合参謀、各軍種、戦闘軍には十分な資源が存在する。これらの組織の利害関係者や専門家との話し合いは極めて重要であり、ミッション・エンジニアがミッションを適切に特性化し、ミッション・スレッドを策定するのに役立つ。

ミッション・スレッド開発のためのインプットとして、実務者は、統合ミッション・エッセンシャル・タスク・リスト（JMETL）、統一統合タスクリスト（UJTL）、統合共通システム機能リスト（JCSFL）、およびサービス固有のタスクリストのようなリソースを考慮することができる。

具体的なシナリオに即して言えば、ミッション・スレッドには、ドクトリン、戦術、技法、手順、および関連する意思決定サイクルだけでなく、統合タスク・リストや軍種のタスク・リストからの逸脱を活用して、実行すべきミッションが記述されている。

タスクを整理して、ミッションのアプローチを順序立てて記述することは有用である。例えば、長距離射撃（キネティック）ミッション・スレッドのタスクフローは、発見：Find－固定：Fix－追跡：Track－ターゲット：Target－交戦：Engage－評価：Assess（F2T2EA）の形をとる。

例えば、サイバー（ノン・キネティック）・ミッション・スレッドは、偵察、兵器化、配布のタスク・フロー、すなわち、探査－設置－指揮・統制（C2）－目標に対する行動、に従うことができる。

5.2 ミッション・エンジニアリング・スレッド：Mission Engineering Threads

一つ以上のミッション・エンジニアリング・スレッド（METs）を開発することで、ミッション・タスクの達成に必要なシステム、技術、組織、人員などの行為主体に関する詳細が追加され、与えられたミッション・アプローチの表現が完成する。ミッション・エンジニアリング・スレッド（METs）は、システムやシステムズ・オブ・システムズ（SoS）の工学デザインや開発検討事項に情報を与える洞察を提供する。

ミッション・エンジニアリング・スレッド（MET）で提供される詳細のレベルは、目的文（purpose statement）に合わせるべきである。ミッション・スレッドのすべてのタスクに行為主体を割り当てる必要はない。そのような仮定が明示的に文書化されている限りにおいて、実務者は調査対象の質問の中心的なものではない活動や事象について、いくつかの仮定をすることができる。ミッション・スレッドと同様、実務者は利害関係者や専門家と一緒にミッション・エンジニアリング・スレッド（METs）を検証すべきである。

図5－2は個々のミッション・スレッドとミッション・エンジニアリング・スレッド（MET）の関係を示している。実際には、特定のシナリオにおけるミッションの遂行には、複数のミッション・スレッドとミッション・エンジニアリング・スレッド（METs）をエフェクト・ウェブまたはキル・ウェブとして統合（一体化）することが含まれる。実務者は、ミッション・エンジニアリングの目的と範囲に基づいて、ミッション・アーキテクチャにスレッド一式とそれに関連する関係が表現されていることを確認すべきである。

図 5-2.デジタル・エンジニアリング・ツールでモデル化された単一のミッション・スレッドと関連するミッション・エンジニアリング・スレッド（MET）の例。

5.3 ベースラインおよび代替のミッション・スレッドとミッション・エンジニアリング・スレッドの開発：Develop Baseline and Alternative Mission Threads and Mission Engineering Threads

代替のミッション・アプローチを評価するためのミッション・スレッドとミッション・エンジニアリング・スレッド（METs）は、ベースライン・ミッション・アプローチ（baseline mission approach）と呼ばれる。通常、ベースラインは出発点、すなわち、対象エポック（現在または近未来）のミッションに対する初期アプローチである。ミッションの成果を向上させる新たな方法を検討する場合、その変更は、変更後の活動をミッション・スレッドに追加するか、または、新技術やシステムをミッション・エンジニアリング・スレッド（METs）に統合（一体化）することによって表すべきである。

これらの変更は、代替のミッション・アプローチとなる。これらの代替案は、ベースラインのミッション・アプローチからの逸脱（excursions）であり、目的文（purpose statement）と調査項目から直接導き出されたものである。例えば、ミッション・エンジニアリングの目的が因果関係を探ることであれば、代替案は特定のパラメータに対する感度によって決定される。

目的が潜在的なソリューションや新たな機会に取り組むことであれば、代替案は、それらの機会の背景にある原動力（driving forces）の実施をモデル化することができる。さらに、ベースラインから特定された既知の問題やギャップに基づいて代替案を選択することもできる。各代替案について、実務者は個別のミッション・エンジニアリング・スレッド（METs）（場合によってはミッション・スレッド）を策定し、検証する必要があるかもしれない。

各ベースライン及び代替のミッション・エンジニアリング・スレッド（MET）は、管理されたコンフィギュレーションを用いて明確に文書化されるべきである。文書化には、追跡可能（traceable）な情報源や参考文献を含め、関連する変更を反映させなければならない。

ミッション・エンジニアリング活動の結果を最も効果的に解釈するためには、実務者は、ベースライン・ミッション・アプローチと代替のミッション・アプローチとの間の変更点を明確に理解し、把握する必要がある。ミッション・エンジニアリング活動の範囲によっては、ベースライン内の単一システムやシステムズ・オブ・システムズ（SoS）に焦点を絞った変更もありうる。代替のミッション・アプローチが、その後のミッション・エンジニアリング活動の新たなベースラインとなる可能性もある。

説明のため、表5ー1は、新兵器システムと関連する拡張機能およびイネーブラを統合（一体化）することによるミッションへの影響を理解することに重点を置いた機会文を検討する場合の、基本ミッション・アプローチと代替のミッション・アプローチの例を示している。

表5-1.検討すべきアプローチ

識別子	簡単な説明
ベースライン・アプローチ
A. 従来型のアプローチ	全地球測位システム（GPS）による青部隊の爆撃機からの誘導スタンドオフミサイルを、妨害装置と空中給油の支援を受けて、赤部隊の航空機を攻撃する
代替アプローチと逸脱
B1. GPS搭載爆撃機発進滑空機	新しい爆撃機発射滑空体兵器（GPS誘導型）の代替
B2. GPS搭載地上発射滑空機	逸脱：B1アプローチと同じ滑空体兵器を使用するための代替発射プラットフォーム、 しかし、水上艦艇からGPS誘導で射程を延長して発射される。
C. GPS搭載爆撃機発射型亜音速巡行ミサイル	新型爆撃機発射型亜音速巡航ミサイル（GPS誘導型）の代替

すでに述べたように、ミッション・アーキテクチャにはミッション・スレッドと特定のミッションの文脈で実行されるミッション・エンジニアリング・スレッド（METs）が含まれる。このミッション・アーキテクチャ全体で明らかになった相互依存関係は、シナリオ内で適用されるすべてのミッション・エンジニアリング・スレッド（METs）を反映することの重要性を強調している。この統合（一体化）されたミッション・エンジニアリング・スレッド（METs）の集合はミッション・エンジニアリング分析に追跡可能（traceable）であるべきであり、図5－3に描かれているように、さらなるミッション・エンジニアリング活動の青写真となることができる。

図5-3. ミッション・アーキテクチャはミッション・エンジニアリング分析に追跡可能（traceable）である。

6.0 ミッション・エンジニアリング分析：MISSION ENGINEERING ANALYSIS

ミッション・エンジニアリング分析の中核的機能は、特定のシナリオに基づくミッションの状況の中でミッション・アーキテクチャを評価し、ミッションの成功を探る定量的アウトプット（すなわち、尺度（measure）と指標（metrics））を提供することである。この分析では、ミッションの影響を評価するために、潜在的な条件の変化がある中で、ベースライン・アプローチと代替のミッション・アプローチというミッションを実行した場合の振舞いと効果をシミュレートすることに重点が置かれる。

ミッション・アーキテクチャの分析を実施する際、システム工学（信頼性工学やリスクマネジメントなど）や、故障モード影響分析などの関連プロセスの専門知識を活用することで、システムやタスクの故障がミッション全体に及ぼす影響を評価することができる。コンストラクティブ・シミュレーション（constructive simulations）を活用し、オペレーションズ・リサーチを基礎とするミッション・エンジニアリング分析は、ミッションの実行に基づく定量的尺度（measure）と指標（metrics）を提供する。その結果は、ミッション・アーキテクチャの改良や修正に反映される。

6.1 完全な分析デザイン：Complete Design of Analysis

ミッション・エンジニアリングの分析は、そのアウトプットが目的文（purpose statement）に対応し、調査上の疑問に答えるようにデザインされなければならない。分析デザインの重要な側面には、以下のようなものがある。

▪ ラン・マトリックスの開発

▪ 適切な計算およびシミュレーション分析ツールの特定

▪ データセットの精緻化

6.1.1 評価フレームワークの開発と整理（ラン・マトリックス（Run Matrix））：Develop and Organize Evaluation Framework (Run Matrix)

ラン・マトリックス（Run Matrix）とは、ミッション・エンジニアリング分析のために、指定されたミッション・シナリオまたはヴィネットで分析されるミッション・アプローチを構造化したものである。マトリックスには、ミッションの基本アプローチと、比較のための様々な代替案を含める必要がある。取り組むべき問題に基づき、ミッションの状況やベースライン・ミッション・アプローチにおける様々な検討事項や変化する変数を反映した逸脱（excursions）が必要である。

実務者は、ベースラインから特定された既知の問題点やギャップに基づいて、検討すべき代替アプローチを特定することを検討してもよい。これらの代替案は、5.3節で説明するミッション・エンジニアリング・スレッド（METs）の変更である。ラン・マトリックス（run matrix）は、分析を計画し、分析アプローチの選択に情報を提供する有用な方法である。

ラン・マトリックス（run matrix）の主な要素は、評価すべきミッション・アプローチと、パフォーマンスに影響を与えうる運用条件である。ラン・マトリックス（run matrix）の各項目について、実務者はデータセットの利用可能性、モデルやシミュレーションから必要とされる忠実度や統計量を考慮する必要がある。ランに課される仮定、制限、境界条件も含めるべきである。実務者はまた、意味のある結果を得るために適切な分析手法とモデリング・ツールを検討すべきである。

ラン・マトリックス（run matrix）は、ベースライン・アプローチに関連する試行、または、逸脱（excursions）から始まる。実務者は、利害関係者や専門家とともにラン・マトリックス（run matrix）の検証を行うべきである。実施された各試行に関連する境界条件、制約、及び制限を把握する必要がある。実務者は、図6－1に示すような表形式が、ラン・マトリックス（run matrix）から得られる関連情報を要約し、整理するのに有用であることに気付くかもしれない。

図6-1.ケースとセットアップ条件の例示的なグループ分け[14]

6.1.2 計算手法とシミュレーションツールの特定：Identify Computational Methodology and Simulation Tools

ラン・マトリックス（run matrix）における様々なミッション・アプローチを評価するための分析手法は数多くある。実務者は、ミッション・エンジニアリングの目的と調査課題に最も適した手法を選択すべきである。可能性のある手法には、以下のものがある。

▪ ベイズ分析

▪ マルコフ連鎖

▪ モンテ・カルロ・シミュレーション

▪ 回帰分析

▪ 最適化解析

▪ 感度分析

▪ 費用便益分析確率的モデリング

▪ 確率的モデリング

▪ 経験的モデリング

▪ パラメータ化

ミッション・エンジニアリングの実施にこれらの手法を適用する場合の例としては、ある制約の下で1つまたは複数の変数の最適値を見つけるのに役立つ最適化分析の使用、他の変数の変化によって変数がどのような影響を受けるかを判断する感度分析の使用、システム、プロセス、またはモデルの状態を独立変数の関数として表現するパラメータ化の使用などがある。これらの手法を適用することで、1つ以上の変数が未知の場合、仮定や入力を洗練させることができる。

調査の質問、尺度（measure）と指標（metrics）、および選択した分析の種類によって、実務者は、ミッションの影響を評価するためのモデリングとラン・マトリックス（run matrix）の計算に適切な分析ツールを選択することになる。分析手法の選択と同様に、実務者はミッション・エンジニアリング活動を最もよく支援するツールを選択すべきである。ツールを選択する際、実務者は、ミッション・エンジニアリング分析に割り当てられる総時間に対して、モデルと分析の複雑さによって決定される各試行の計算時間を考慮すべきである。

ミッション・エンジニアリングに応用できる可能性のあるツールには、政府所有のものと市販のモデリング、シミュレーション、およびアーキテクチャ・ソフトウェアの両方がある。これらのツールは、戦略、作戦、戦術の各レベルで、また、さまざまなドメイン（海上、空中、陸上、宇宙など）で、モデルの開発と分析の実行を可能にする。また、これらのツールは、電磁、サイバー、通信、妨害、ノン・キネティックな作戦とキネティックな作戦など、さまざまな作戦を、さまざまな度合いで、計算の厳密性、忠実度、または複雑性をもって分析することもできる。

ツールの選択は、シナリオ、ヴィネット、ミッション・スレッドの複雑さによって決定される。ツールの選択に影響を与えるその他の要因には、ミッションの期間と計算タイムステップ、データの忠実度要件、および尺度（measure）と指標（metrics）に与える変数の数が含まれる。選択したツールセットから導かれるモデルは、誤差伝播（例えば、ランダムとシステマティック）や不確実性の扱いが異なる。実務者は、ツールを理解し、モデルとそのモデルを効果的に使用するために必要なソース・データの系統との関係を理解する必要がある。

6.1.3 データセットの整理と確認：Organize and Review Datasets

分析に必要なデータの多くは、ミッションの特徴付け（mission characterization）とミッション・アーキテクチャの開発からこれまでに収集されている。ラン・マトリックス内のさまざまなベースラインと代替オプションによって分析が構成されるため、シミュレーションと分析のためのモデルを開発するための追加データが必要となる可能性がある。したがって、収集したデータを整理し、レビューすることは、ミッション・エンジニアリングの取組みに必要な追加データの評価に役立つ。データセットは信頼できるデータ・ソースから入手し、モデル、シミュレーション、および結果の信頼性を高めるために、専門家によるレビューを受けるべきである。

6.2 モデル、シミュレーション、分析の実行：Execute Models, Simulations, and Analysis

開発したラン・マトリックス（run matrix）を使用して、実務者はベースライン・ミッション・アプローチと代替のミッション・アプローチのシミュレーションを実行し、その結果（ミッションの尺度（measure）と指標（metrics））を出力しなければならない。ミッション・エンジニアリング活動の範囲にもよるが、ラン・マトリックス（run matrix）を完全に定義する前に、代替案を重点的に検討すべきギャップやミッション領域を特定するために、ベースライン・ミッション・アプローチを実行することもできる。この結果を処理、検証することで、各アプローチがミッションの成果に与える影響を定量的に把握することができる。

実務者は、モデリング実行の際に以下を考慮すべきである。

▪ ベースライン・ミッション・アプローチの実行と分析

▪ 必要に応じて、ラン・マトリックスを調整

▪ 代替のミッション・アプローチの実行と分析

▪ 分析結果の検証

6.2.1 ベースラインの実行と分析：Execute and Analyze the Baseline

実務者は、ミッションをシミュレートし実行するためのツールを使用して、シナリオとヴィネットの文脈内でベースライン・ミッション・エンジニアリング・スレッド（MET）をモデル化すべきである。関連するすべての人々や組織、システム属性、振舞い、影響を表現する必要がある。実務者は、ラン・マトリックス（run matrix）で計画されたとおり、ベースライン試行を実施すべきである。

モデル化されたミッション・エンジニアリング・スレッド（MET）が既知の作戦的振舞いを捕捉していること、およびシミュレーション結果が専門家の判断と一致していることを確認するため、ベースラインの実行を批評的に検討する必要がある。たいていの場合、ベースラインについては、提案された代替のミッション・アプローチよりも多くの情報が知られているため、実務者はモデルや分析ツールが期待に沿った結果を出すかどうかを、より容易にチェックすることができる。実務者は、ミッションの尺度（measure）と指標（metrics）、観察結果、および仮定を文書化すべきである。

6.2.2 ラン・マトリックスの調整（必要な場合）：Adjust the Run Matrix (as Needed)

ベースライン出力で予期せぬ結果や新たなギャップが発見された場合、実務者は適切な代替のミッション・エンジニアリング・スレッド（METs）でラン・マトリックス（run matrix）を調整することを検討すべきである。全ての試行が実施されるまで待つよりも、この段階でラン・マトリックス（run matrix）を調整する方が効率的である。調整が完了したら、実務者は対象分野の専門家とともにラン・マトリックス（run matrix）の再検証を行うべきである。

6.2.3 代替のミッション・アプローチの実行と分析：Execute and Analyze the Alternative Mission Approaches

実務者は、選択したツールを用いて、シナリオとヴィネットの文脈の中で代替のミッション・エンジニアリング・スレッド（METs）をモデル化し、ミッションのシミュレーションと実行を行うべきである。実行が予測通りにいかなかったり、統計的収束が達成されなかったり、モデルやシミュレーションが予期せずクラッシュしたり、興味深い特異点が生じたりした場合など、特殊なケースに注意すべきである。

実務者は、必要に応じて試行を再実行し、遭遇した異常や実行中に発生した事象をすべて記録すること。実務者は、ミッションの尺度（measure）と指標（metrics）、および観察結果や仮定を記録すること。興味深い予期せぬ結果は、逸脱（excursions）、ミッション・スレッドやミッション・エンジニアリング・スレッド（METs）のバリエーション、あるいは特定のパラメータに関する更なる感度分析の源となり得る。最後に、実務者はラン・マトリックス（run matrix）の全エントリーの結果を文書化する必要がある。

6.2.4 分析結果の忠実度の検証：Validate the Fidelity of Analytic Results

どのようなミッション・エンジニアリング分析においても、3つの重要な考慮事項がある。

▪ 正確性－系統誤差、ランダム誤差、異常、人工物

▪ 精度－誤差分析と統計的回帰

▪ 信頼度－一組のデータに基づく、あるパラメータの区間、または可能な値の範囲。例えば、シミュレーション結果と、その区間がパラメータの値を含むレベルまたは確率。

追加分析を実施する前に、実務者はまず、最初の試行で得られた結果が、調査対象の質問に答えるために必要な忠実度（正確度、精度、信頼度）をもたらすかどうかを評価すべきである。実際の値を確認できるようになった今、分析のデザインにおいて重要であると特定された尺度（measure）と指標（metrics）は、当初考えられていたほど衝撃的なものではないかもしれない。

その他の重要な尺度（measure）と指標（metrics）が見落とされているかもしれない。利害関係者や意思決定者に情報を提供する結論の裏付けとなるよう、尺度（measure）と指標（metrics）の集計を見直す必要がある。

実務者は、分析結果を利害関係者や専門家と検討すべきである。

実務者は、分析手法の適切な実行と結果の健全性の両方について、結果を批評すべきである。結果をグラフ化または視覚化し、アウトプットを点検すべきである。実務者は、ベースラインと代替のミッション・アプローチの比較に意味があるかどうかを評価し、ミッションの成果に対する変更の影響に関する洞察力を得るべきである。実務者が自信を持って答えるべき質問例には、以下のようなものがある。

▪ ベースライン試行と代替のミッション・アプローチ試行の結果の比較により、調査対象の質問に答えるのに十分な質の高いデータが得られるか？

▪ これらの試行の結果、すなわち、ミッション・アプローチの測定されたパフォーマンスは、正当化可能であり、ナラティブとして説明可能であり、専門家および作戦運用の専門家からのインプットと整合しているか？

▪ 分析の前提条件や制約は、結果の解釈にどのような影響を与えるか？

▪ 結果は、有意義な結論を導き出すことができる方法で調査の質問に対処している？

6.3 ミッション・スレッドとミッション・エンジニアリング・スレッドの調整：Adjust Mission Threads and Mission Engineering Threads

これらの質問に対する回答が不十分な場合、または関心のある他の振舞いが観察された場合、実務者はミッション・スレッドとミッション・エンジニアリング・スレッド（MET）開発のサイクルを再検討する必要がある。ラン・マトリックスと試行をさらに調整する必要がある場合がある。このサイクルは、次のパターンに従う。

▪ ミッションを観察する。

▪ その観察の理由を推測する。

▪ その推測を評価するための代替のミッション・アプローチを生成する。

▪ 推測されたケースが観測を裏付けるかどうかを評価する。

▪ もし、その観察結果を確認できない場合は、このサイクルを繰り返す。

7.0 結果と提言：RESULTS AND RECOMMENDATIONS

ミッション・エンジニアリング・プロセスの最終段階は、次の3つの要素から構成される。1）ミッション・エンジニアリング分析から得られたミッションの影響と成果の合成と文書化、2）推奨ミッション・アーキテクチャの収集と提示、3）将来の使用のためのミッション・エンジニアリング成果物の管理である。

ミッション・エンジニアリングの成果物は、目的文（purpose statement）と調査質問に関連する一連の提言に注意を集中させるのに役立つ。提言は、指導層への情報提供、要件の策定、プロトタイピング作業への助言、および取得決定の立証に使用される。提言は、推奨されるミッション・アーキテクチャの特性を説明し、当初の質問に沿った成功の尺度（MOS）を反映し、さらなる分析の必要性を強調するのに役立つ。

主なミッション・エンジニアリング成果物は以下の通り。

▪ ミッション・アーキテクチャのデジタル・モデル－ミッション・スレッドとミッション・エンジニアリング・スレッド（METs）

▪ ミッション、シナリオ、現在および将来の能力に関する情報の収集

▪ データセット－システム・パフォーマンス・パラメータ、モデル、指標、尺度

▪ 結果、所見、提言の文書化－視覚化、報告書、概要、デジタル成果物

図7-1.ミッション・エンジニアリング分析結果の視覚化例。

ミッション・エンジニアリングの成果物は、最低限、分析の全体的な目的とその計画を文書化したものでなければならない。また、前提条件や制約条件、ツール、モデル、尺度（measure）と指標（metrics）、および得られた結果など、分析フレームワークの選択に影響を及ぼした要因も文書に含めるべきである。実務者は、成功の尺度（MOS）に対する利益または損失、および目的文（purpose statement）に対処するのに役立つその他の主要な尺度（measure）と指標（metrics）を定量化すべきである。

二次的な、または新たなミッション・ギャップが発見された場合、あるいは実施されたソリューションから生じる可能性がある場合は、それを特定する。観察された傾向や意味合い、およびデータから推測される関係や相関関係も含める。ミッション・エンジニアリングの全体的な取組みを文書化する場合、実務者は以下の望ましい点の概要を考慮すべきである。

▪ 問題や機会、質問、使命を述べる。

▪ 作戦環境の説明を含むシナリオとヴィネットの説明

▪ 青（米軍）、赤（敵対者）、緑またはその他の非敵対者部隊、およびドクトリン、組織、訓練、資材、リーダーシップ・教育、人事、施設、政策（DOTMLPF－P）の考慮事項を特定する。

▪ ミッションの尺度（measure）と指標（metrics）の明確化（成功の尺度（MOS）、効果の尺度（MOE））

▪ ミッション・アーキテクチャ（ベースライン、代替のミッション・スレッド、ミッション・エンジニアリング・スレッド（METs）について説明すること。

▪ ミッション、技術、能力に関する主要な仮定と制約を特定する。

▪ ベースライン・ミッションのアプローチと関連するコンディション・ケースの詳細を文書化する。

▪ 分析的方法論の説明

▪ 分析から得られた結果について、モデル、データ、結果の忠実性と信頼性を挙げて説明する。

▪ エラーが伝播しない不確実性や、結果に関するその他の問題を特定する。

▪ 統計的根拠をもって、結果の忠実性を正当化または説明する。

▪ 分析から得られた結論を記述し、その結果が問題または機会に関する記述にどのように対処するかを論じる。

▪ 各ミッション・アーキテクチャにおけるリスクの特定と把握

▪ 意思決定者に行動を提言する

▪ さらなる分析と次のステップを推奨する

8.0 まとめ：SUMMARY

ミッション・エンジニアリング・プロセスは、実務者がミッションを構成要素に分解し、エンド・ツー・エンドのミッション遂行を分析するのに役立つ。このプロセスは、能力ギャップの特定と解決、および代替的ミッション手法の影響の定量化を支援する。このプロセスは、ミッションの文脈の中でシステムやシステムズ・オブ・システムズ（SoS）を評価し、ミッション全体にわたるトレード・スペースの機会を探ることを可能にする。

ミッション・エンジニアリング・プロセスは、最も有望な潜在的な物資（materiel）ソリューション、または、非物資（non-materiel）ソリューションと機会を特定することにより、意思決定者が所期のミッション成果にリソースを調整できるよう支援することができる。ミッション・エンジニアリングの到達目標（goal）は、ミッションの成果を達成するために必要な技術、システム、システムズ・オブ・システムズ（SoS）、またはプロセスの正しいことを特定することにより、ミッションを工学的にデザインする（to engineer missions）ことである。そして、システム・エンジニアリング・プロセスにミッションに基づいたインプットを提供し、国防総省が物事を正しく構築するのを援助する。

ミッション・エンジニアリング・プロセスは、評価対象の問題や機会、利用可能なデータ、および意思決定の必要性に応じて拡張可能である。この柔軟で反復的な方法論により、モデリングとシミュレーションの実行を通じて得られる情報に応じて分析を改善し、データ・ソース、前提条件、制約条件に対する追跡可能性（traceability）を提供することができる。

ミッション・エンジニアリングは、ミッション・アーキテクチャを使用して、特定の作戦シナリオやヴィネットの文脈の中で、システム、システムズ・オブ・システムズ（SoS）、創発的能力のデザインと統合（一体化）を分析し、望ましいミッション成果をもたらすものである。ミッション・エンジニアリングの分析結果は、戦闘員がミッションを成功裏に遂行するために必要な能力、技術、システムを確保するための資源配分における潜在的なトレード・スペースについて、意思決定者に情報を提供する。同時に、ミッション・エンジニアリングは、パフォーマンス尺度を通じて、要求、システム・デザイン、能力開発の進展にも情報を提供する。

ノート

[1] Department of Defense Directive 5000.01, Section 1b, “The Defense Acquisition System,” September 9, 2020

[2] 筆者注：ツールの例としては、物理ベースやエフェクト・ベースのシミュレーション、モデル・ベースやエンタープライズ・アーキテクチャ、その他のデジタル・モデリング・ソフトウェアなどがある。

[3] Department of Defense Instruction 5000.88, Section 3.3, “Mission Engineering and Concept Development,” November 18, 2020

[4] Public Law 114-328, Section 855, “National Defense Authorization Act for Fiscal Year 2017,” December 23, 2016

[5] Author’s note: in accordance with CJCSI 5123.01I, “Charter of the Joint Requirements Oversight Council and Implementation of the Joint Capabilities Integration and Development System,” October 30, 2021

[6] Office of the Chairman of the Joint Chiefs of Staff, “Manual for the Operation of the Joint Capabilities Integration and Development System,” current edition

[7] DoDI 5000.02, “Operation of the Defense Acquisition System,” January 7, 2015

[8] Department of Defense Dictionary of Military and Associated Terms (formerly Joint Publication 1-02)

[9] Department of Defense Chief Technology Officer website, “Digital Engineering,” https://ac.cto.mil/digital_engineering/

[10] Office of the Undersecretary of Defense for Research and Engineering, “Department of Defense Digital Engineering Strategy,” June 2018

[11] Department of Defense Dictionary of Military and Associated Terms (formerly Joint Publication 1-02)

[12] Joint Publication 1, “Doctrine of the Armed forces of the United States,” March 25, 2013

[13] Air Force Doctrine Publication 3-0, “Operations and Planning,” p. 89, November 4, 2016

[14] Author’s note: depending on the mission engineering effort, not all cases may need to be executed.