MILTERMでは米国防総省の「国防次官室：研究・エンジニアリング担当（OUSD （R&E） ）」が取り組んでいるミッション・エンジニアリングについて「米国防総省のミッション・エンジニアリング・ガイド」、「米国防総省のミッション・エンジニアリング・ガイド第2版」そして理解の参考となる記事「ミッション・エンジニアリング　（International Test and Evaluation Association）」を紹介してきたところである。ここで紹介するのは、今年1月初旬に公開されたミッション・エンジニアリング・ガイド第2版の付録として位置づけられている「ミッション・アーキテクチャ・スタイル・ガイド」の初版である。この文書は、米国の防衛装備品等の開発に用いられてきたアーキテクチャのフレームワークとの関係の理解に役立つとともに、ミッション・エンジニアリングを適用する際に「ミッション・アーキテクチャ」をどのように記述していけばよいのかを示す正に「スタイル・ガイド」である。あまりにも専門的な文書であるが、この分野に取り組まれている方々には有益な情報であろうと考えて投稿したところである。（軍治）

ミッション・アーキテクチャ・スタイル・ガイド 第1版

Mission Architecture Style Guide Version 1.0

2025年1月6日

CLEARED

For Open Publication

Jan 06, 2025

Department of Defense

OFFICE OF PREPUBLICATION AND SECURITY REVIEW

Office of the Under Secretary of Defense for Research and Engineering

Mission Capabilities

Washington, D.C.

覚書

件名：ミッション・エンジニアリング・ガイド第2版の付録「ミッション・アーキテクチャ・スタイル・ガイド」のリリース

この覚書は、ニアリング・ガイド第2版（MEG 2.0）の付録として、国防総省（DoD）ミッション・アーキテクチャ・スタイル・ガイド（MASG）のリリースを発表するものである。本ガイドの作成は、国防次官室：研究・エンジニアリング担当／ミッション能力担当（OUSD （R&E／MC））内のミッション統合（MI）局次官補（DASD）が主導し、国防総省ミッション・エンジニアリング実務者フォーラム（Department of Defense Mission Engineering Practitioners Forum）及び外部のミッション・エンジニアリング（ME）利害関係者の支援を受けた。

ミッション・アーキテクチャ・スタイル・ガイド（MASG）は、モデル・ベースのシステム・エンジニアやアーキテクトが、モデル・ベースのミッション・アーキテクチャを作成、提示、分析する際に役立つものである。このスタイル・ガイドは、国防総省（DoD）全体でミッション・アーキテクチャの作成と共有を相乗的に進めるために開発された。ミッション・アーキテクチャ・スタイル・ガイド（MASG）は、ミッション・エンジニアリング・ガイド第2版（MEG 2.0）で定義されたミッション・エンジニアリングの基本要素としてのミッション・アーキテクチャ開発に焦点を当てている。

この文書は、2023年デジタル・ミッション・アーキテクチャ・ワークショップと、それに続くミッション統合担当国防副次官補の指針の直接的な成果である。ミッション・アーキテクチャ・スタイル・ガイド（MASG）は、ミッション・アーキテクトが統合ミッション領域（Joint mission area）分析のためのモデルを開発するための基礎的要素であり、国防総省（DoD）全体の主題専門家からのインプットを活用し、ミッション・アーキテクチャの内容に関する一般的なコンセンサスを文書化するものである。ミッション・アーキテクチャ・スタイル・ガイド（MASG）は、国防総省（DoD）全体にわたって、統合のモデル・ベースのミッション・アーキテクチャを促進する。

ミッション・エンジニアリング・ガイド第2版（MEG 2.0）とそのミッション・アーキテクチャ・スタイル・ガイド（MASG）付録は、国防総省（DoD）の最高技術責任者のウェブサイト（https://ac.cto.mil/mission-engineering）からオンラインで入手できる。国防次官補：ミッション能力担当（（ASD（MC））ミッション統合チームは、ミッション・エンジニアリングアーキテクチャの応用とベスト・プラクティスを明確にし、拡大するために、このガイドの将来のバージョンのリリースを調整する。

ミッション統合担当国防副次官補 エルマー・L・ローマン

目次

1. はじめに

1.1.   背景

1.2.   ミッション・アーキテクチャ・スタイル・ガイドの目的

2. ミッション・エンジニアリング・プロセスにおけるアーキテクチャ

2.1.   概観

2.2.  考慮事項

2.3.  連合（モジュラー）アーキテクチャの重要性

2.4.  ミッション・アーキテクチャ・モデルとミッション・アーキテクチャ・ビュー

3. ミッションの問題と機会
4. ミッションの特徴付け

4.1.   ミッションの文脈の開発

4.2.  ミッションの尺度と評価指標を定義する

5. ミッション・アーキテクチャ

5.1.   ミッション・スレッドの開発

5.2.  戦闘序列の理解

5.3.  ミッション・エンジニアリング・スレッドの開発

5.4.  ミッション・エンジニアリング・スレッドのエンド・ツー・エンド・ビューの開発

6. ミッション・エンジニアリング分析

6.1.   試験と評価の支援

7. 結果と推奨事項

7.1.   リーダーシップへのミッション・エンジニアリング・アーキテクチャのプレゼンテーション

8. まとめ
9. 付録

9.1.   デジタル・エンジニアリング・ツールにおけるアーキテクチャ・ビューの規約

9.2.  用語集

9.3.  略語リスト

10. 文献

1.      はじめに

1.1.           背景

ミッション・エンジニアリング（Mission engineering ：ME）は、望ましいミッションの成果を達成するために、現在および将来の作戦上のニーズと能力を分析、デザイン、統合するための技術的努力全体を包含する学際的プロセスである[1]。このスタイル・ガイドは、ミッション・アーキテクトがモデル・ベース・システム・エンジニアリング（Model-Based Systems Engineering ：MBSE）のアプローチと、国防次官室：研究・エンジニアリング担当（OUSD（R&E））に概説されている原則を適用するのを支援することを目的としている。ミッション・エンジニアリング・ガイド第2版（Mission Engineering Guide version 2.0：MEG 2.0）で概説されている原則を適用し、国防総省（DoD）の意思決定に情報を提供するミッション・アーキテクチャ（Mission architectures）を作成するためのものである。

ミッション・アーキテクチャは、ミッション空間と関連する問題領域に関する利害関係者の理解を深める図式的表現を通じて、ミッションの成果、要求、能力を体系的に調整するものである。成果物は、利害関係者が完了した研究を活用したり、追加的なエクスカーションを実行したり、より大きな範囲に対処するために研究を拡張したりできるように構築される。

ミッション・アーキテクチャは、リーダーシップと利害関係者が情報に基づいた意思決定を行うために使用できるように、問題と潜在的ソリューション（potential solutions）の両方が体系的に分解されていることを保証する。ミッション・アーキテクチャ・モデリングは、特性化、構築、分析、更新の反復プロセスを通じて、ミッション・エンジニアリング分析をサポートする。デジタル・モデリング・ツールは、情報の共有リポジトリを提供することでデザイン・サイクルを加速し、モデル成果物の再利用を可能にし、代替案を評価するためのモデルの迅速な再構成を可能にする。ミッション・アーキテクチャは、オブジェクト指向システム・エンジニアリングの実現を支援し、デジタル・ライフ・サイクルの表現を可能にする。本ガイドは、様々な利害関係者の意図を満たすミッション・アーキテクチャを開発するための例を示している。

1.2.           ミッション・アーキテクチャ・スタイル・ガイドの目的

ミッション・エンジニアリング・アーキテクチャ・スタイル・ガイド（Mission Engineering Architecture Style Guide ：MASG）は、統合参謀、各戦闘軍、国防次官室（OUSD）、戦闘支援機関、各軍種を支援するモデル・ベースのシステム・エンジニアやアーキテクトの使用を対象としている。このガイドは、国防総省（DoD）内でのミッション・アーキテクチャ開発を標準化し、モデル・フェデレーションとモジュール化を促進し、モデルを定義するために使用される要素や関係の適用や表現における差異を減らすことによって、モデル開発を支援するものである。

防衛の事業体（enterprise）におけるモデリングの標準化は、ミッション・エンジニアリング・コミュニティ全体で共有されるモデルの理解と使用を強化する。この統合の取組み（joint effort）により、協力が可能になり、労力の重複が削減される。事業体を通した専門知識を活用することで、モデルの忠実度が向上する。このガイドの目標は、国防総省（DoD）全体が採用できるモデル・ベース・システム・エンジニアリング（MBSE）モデルの集団的作成を促進することである。

この中で述べられているアプローチは広範に適用できるはずであるが、これらは国防次官室：研究・エンジニアリング担当（OUSD（R&E））のミッション統合部門が通常実施するタイプのミッション・エンジニアリング研究を対象としている。これらの研究は、従来から国防総省（DoD）のミッションへの挿入オプションとしての技術やシステムの評価を含んでいる。これは特注のアプローチ（tailored approach）であるにもかかわらず、多くの側面と実践は、他のモデリングの取組みにさらに調整することができる。

モデリング・プロセスの一環として、ミッション統合（Mission Integration ：MI）のユース・ケースに効果的な特定のアプローチ、構文、表現技法が発見され、これらはガイドに記述されている。ミッション・エンジニアリング・エグゼクティブ・ステアリング・カウンシルのためのFY24メモランダムに沿って、ミッション統合（MI）と本ガイドは、統一アーキテクチャ・フレームワーク（UAF：Unified Architecture Framework）がミッション・エンジニアリング・ガイド第2版（MEG 2.0）に記述されているミッション・スレッドのスタイルにどのように適合できるかを評価した[2]。定義されたアプローチ例は、UAFを使用する場合のアーキテクチャへのアプローチ方法の一例であり、参考となることを意図している。このスタイル・ガイドは、UAF標準の一部として提供されるUAFのためのエンタープライズ・アーキテクチャ（EA）ガイドと共に使用されるべきである[3]。

本ガイドを通じてモデリング例を提供する目的で、オープン・ソースの「砂漠の嵐作戦（Operation DESERT STORM）」の例を使用してアーキテクチャを作成し、モデルの可読性と理解度を高めるために簡略化した。これらの例は、Cameo System Modeler 2021xの「統一アーキテクチャ・フレームワーク・モデリング言語（Unified Architecture Framework Modeling Language ：UAFML）1.2版」を使用して作成したが、全体的なアプローチはソフトウェア・ツールや言語にとらわれないことを意図している。UAFMLはシステム・モデリング言語（SysML）をベースにしており、さらに能力とエンタープライズ・モデリングの概念を提供するエンタープライズ・レベルのビューを含んでいる。

ミッション・アーキテクチャ・スタイル・ガイド（MASG）は、ミッション・アーキテクチャの作成方法に関するステップ・バイ・ステップのハンドブックではなく、ミッション・アーキテクチャの共有と協力を促進するためのスケーラブルなアプローチを概説するものである。ミッション・アーキテクチャ・スタイル・ガイド（MASG）は、以下を可能にする。

1. ライフ・サイクルを通じて能力開発の様々な側面を支援する、国防総省（DoD）モデル・ベースのミッション・アーキテクチャの開発において、ミッション・アーキテクトを指導する。
2. 国際的なオブジェクト管理グループ（OMG）標準との整合性を保ちつつ、国防総省（DoD）コミュニティ全体が採用できる権威あるアーキテクチャの集団的な作成と共有を促進する。
3. 技術開発を推進する重要な政策および投資決定について、政府および国防総省（DoD）の上級指導者に情報を提供するための見解およびプレゼンテーション資料の作成において、ミッション・アーキテクトに助言する。

2.     ミッション・エンジニアリング・プロセスにおけるアーキテクチャ

2.1.           概観

ミッション・エンジニアリング・ガイド第2版（MEG 2.0）では、ミッション・エンジニアリングを図1に示す5段階のプロセスとして記述している。「ミッション・アーキテクチャ（Mission Architectures）」のための明確なステップがあり、他の各ステップがミッション・アーキテクチャに影響を与える、及び／又は、ミッション・アーキテクチャを活用するようになっている[4]。この文書では、ミッション・エンジニアリング・ガイド第2版（MEG 2.0）の各プロセス・ステップに1つの条を設け、アーキテクチャの役割を説明し、アーキテクチャを支援する側面の開発方法に関するガイダンスを提供する。この文書に記述されているミッション・アーキテクチャ開発ガイドラインは、ミッション・エンジニアリング・プロセスに沿ったものである。

下図は一連のプロセス・フローを強調したものであるが、ミッション・アーキテクチャは、インテリジェンス情報の収集、分析結果、実験フィードバック、実戦テスト、推奨など、ミッション・エンジニアリング（ME）プロセスのすべてのステップをサポートするために作成される。その結果は、モデル・ベースのアーキテクチャと構成的シミュレーションを更新するために使用される。ミッション・エンジニアリング（ME）方法論の詳細については、ミッション・エンジニアリング・ガイド第2版（MEG 2.0）の第2.2節を参照。

図1. ミッション・エンジニアリング・プロセス（出典：MEG v2.0）

2.2.          考慮事項

2.2.1.       アーキテクチャの種類と重要な用語

アーキテクチャのカテゴリーと関連する定義[5]は以下の通り。

エンタープライズ・アーキテクチャ（Enterprise Architecture）： アーキテクチャの基本定義（構造、動作、グローバル・ルール）を、組織全体またはビジネス・プロセスの機能を果たすために協働するノード、システム、要素、またはその他のリソースの一群の最上位レベルに適用する。[出典：Borky and Bradley, Effective Model-Based Systems Engineering, 2019].

ミッション・アーキテクチャ（Mission Architecture）： 特定のエンド・ツー・エンドのミッションを遂行するための方法と手段を、ミッション要素間の関係や依存関係とともに描いたもの。これには、ミッション活動（mission activities）、アプローチ、システム、システム・オブ・システム、組織、能力などの要素が含まれる。[出典：OUSD（R&E） MEG 2.0］

システム・アーキテクチャ（System Architecture）： ノードまたはシステムに割り当てられた定義された要件を満たすために協働する要素（最終的にはハードウェアとソフトウェアの構成要素）の一群に基本定義を適用する（明確なシステム境界とユーザー・インターフェースが定義されていることを意味する）。[出典：Borky and Bradley, Effective Model-Based Systems Engineering, 2019].

ソフトウェア・アーキテクチャ（Software Architecture）： フレームワーク、ソフトウェア要件、アプリケーション・プログラム、インフラストラクチャー・プログラム、ワークフロー管理、ネットワークとメッセージング、インターフェース、その他コンピュータ・プログラミングの側面に焦点を当て、基本定義をソフトウェアに適用する。[出典：Borky and Bradley, Effective Model-Based Systems Engineering, 2019].

ハードウェア・アーキテクチャ（Hardware Architecture）： 基本定義をハードウェアに適用し、プロセッサ、ストレージ、相互接続、オペレータ・ステーション、通信、センサ、エフェクタ、その他のハードウェア要素に焦点を当てる。[出典：Borky and Bradley, Effective Model-Based Systems Engineering, 2019].

参照アーキテクチャ（Reference Architecture）： ドメインまたはエンティティのクラスに共通する特徴と動作を定義する論理的／機能的抽象化。参照アーキテクチャ（RA）は、ドメイン内の特定の一連の要件を満たす物理的なアーキテクチャを実現するために、関連する詳細を追加することによってインスタンス化される。[出典：Borky and Bradley, Effective Model-Based Systems Engineering, 2019].

実行可能なアーキテクチャ（Executable Architecture）： 振舞いをシミュレートし、コードの自動生成、デザインの正しさの検証などのために実行可能なコンピュータ・モデルの形でアーキテクチャを表現する。実行可能なアーキテクチャは、アーキテクチャを記述するために使用されるさまざまな抽象化レベルで存在する。[出典：Borky and Bradley, Effective Model-Based Systems Engineering, 2019].

2.2.2.       オブジェクト管理グループのUAFのためのミッション・エンジニアリング・ガイド

オブジェクト管理グループ（OMG）は、UAFメタモデルの基本要素を拡張し、ミッション・エンジニアリング・モデル要素を含む「UAFのためのミッション・エンジニアリング（ME）ガイド」を発行する予定である。発行後、オブジェクト管理グループ（OMG）の「UAFのためのミッション・エンジニアリング（ME）ガイド」は、UAF第1.3版の更新に含まれ、ミッション・アーキテクチャを策定するために、このミッション・アーキテクチャ・スタイル・ガイド（MASG）およびミッション・エンジニアリング・ガイド第2版（MEG 2.0）とともに使用することができる。

エンタープライズ・システム・エンジニアリングとミッション・エンジニアリングの両分野は、資材、システム重視のソリューション、および非資材（DOTMLPF-P）ソリューションを包含する、事業体のさまざまな見解と考察をモデル化する。これらのアプローチには、従来のシステム境界（システム、構成要素、機能）を超えた戦略、プログラム、人材、プロセス、能力が組み込まれている。国防総省（DoD）は、事業体の中の事業体として、時間とともに進化する複雑な論理的・物理的アーキテクチャを持っている。UAFMLはSysMLをベースに、アーキテクチャの時間的、非物質的側面を考慮したものである。

エンタープライズ・アーキテクチャ（EA）とミッション・アーキテクチャ・モデリングは、複雑な問題を管理可能な構成要素に分解する。図2は、エンタープライズ・モデリングに関わる主要なエンティティと関係に焦点を当てた概念モデルを示している。エンタープライズ・モデリング・プロセスを開始するために、アーキテクトは、UAFの戦略的視点において、ミッションのニーズ、必要な能力、望ましい効果、および成果を定義し、把握することができる。

次に、作戦上の視点（Operational viewpoint）を使用して、ソリューションにとらわれない視点からミッション・レベルの振舞いを定義することができる。次に、リソースの視点（Resources viewpoint）を使用して、能力の必要性をどのように満たすかを成文化することができる。最後に、要員（Personnel）とプロジェクト（Projects）の視点を用いて、ミッションの「誰が（Who）」「いつ（When）」「どこで（Where）」の側面をモデル化することができる。

図2. UAFにおける行動とエージェントの主な関係[6]

2.2.3.       DoDAFとの関連

国防総省アーキテクチャ・フレームワーク（Department of Defense Architecture Framework ：DoDAF）とUAFは、事業体の戦略的、作戦的、および人事的視点のハイレベルな特徴付けという共通の基盤を持っている。これらの視点は、事業体の重要な非物資の側面の多くを捉えている。UAFの戦略的視点は、事業体にとっての主要な推進要因と課題、事業体が追求すべき重要な機会、事業体の目標を達成するために必要なミッションとビジネス能力（WHY）を概説する。

（UAFとDoDAFにおける）作戦上の視点（Operational viewpoint）は、主要な作戦の実行者と、事業体の能力をサポートするために実行される活動（activities）（WHAT）を扱う。このようにして定義された能力と作戦に対応して、必要なサービス、要員、リソースが定義され、ミッションとビジネス能力に具体化された事業体の目標を達成するために事業体（HOW）に装備される。

図3. DoDAFからUAFへの進化[7]

図3は、DoDAFからUAFへの進化を示している。UAFはDoDAFの基礎の上に構築され、ミッション・アーキテクチャとエンタープライズ・システム・エンジニアリングに合わせた、より洗練された分析を提供する。UAFビューのDoDAF第2.02版への詳細なマッピングについては、UAF第1.2版の仕様の付録A[8]表2.1を参照のこと。この仕様には、最終的にDoDAF第2.02版に取って代わる同等のUAFビューの直接のクロスウォークが含まれている。このリソースは、このガイドで説明するものを補完するDoDAFビューを開発するためのガイダンスを提供する。

2.2.4.       UAFMLとSysMLの活用

UAFMLはSysMLと統一モデリング言語（Unified Modeling Language ：UML）から派生したものであり、両者は連携することを意図している。UAFMLとSysMLを使用することで、それぞれエンタープライズ・ミッション・レベルとシステム・レベルのモデリングが可能になり、利害関係者の懸念に情報を提供するために必要な詳細レベルを提供することができる。SysMLとUAFMLは、エンタープライズ・モデリングに不可欠な、多くの構成を持つシステムやシステム・オブ・システムをモデリングするための標準的な表記法（notation）と意味論（semantic）を提供することで、モデル・ベース・システム・エンジニアリング（MBSE）のアプローチを可能にする。

UAFは、エンタープライズ・モデリングに不可欠な、多くの構成を持つシステム・オブ・システムを描写するために使用されるフレームワークである。エンタープライズ・アーキテクチャ（EA）は、組織をビジネス戦略と到達目標（goals）に整合させるために使用される。エンタープライズ・アーキテクチャ（EA）は、テクノロジー・インフラストラクチャーがビジネス・プロセスを効果的にサポートすることを確実にするために、組織の相互依存関係を全体的にとらえる。逆に、システム・アーキテクチャは、個々のシステムのデザインと統合に焦点を当て、各システムが作戦上およびプログラム上の要件を満たすようにデザインされることを保証する[9]。

UAFMLはもともとソフトウェア・アーキテクチャを視覚的にモデリングするためのものであったため、SysMLがシステムのモデリングをサポートするためにUMLを拡張したのと同様に、UAFMLも事業体のモデリングを効果的にサポートするためにSysMLを拡張したものである。UAFMLは、UAFドメイン・メタモデルの実装をUMLとSysMLの観点から規定している。UAFドメイン・メタモデル（Domain Metamodel ：DMM）を特徴付けるUMLの拡張（いわゆるステレオタイプ）を定義している。また、UMLのもう1つの拡張であるSysMLプロファイルにも依存している。これは、SysMLを使用したシステム・モデリングとのシームレスな統合を実現し、UAFMLでSysMLの機能を十分に活用できるようにすることを目的としている（図4）。

図4. UML、SysML、UAFMLの関連図

UAFMLは、連邦政府機関、防衛組織、商業産業におけるアーキテクチャ記述の開発を支援する国際的なオブジェクト管理グループ（OMG）標準である。UAFMLはエンタープライズやミッションのアーキテクチャからサイバーフィジカルシステム・エンジニアリングまで様々なユース・ケースをサポートしている。UAFは、国防省アーキテクチャ・フレームワーク（MoDAF）、DoDAF、NATOアーキテクチャ・フレームワーク（NAF）、およびさまざまなフレームワークから発展したもので、ライフ・サイクル全体を通して組織間のコラボレーションを評価・支援する際のステークホルダー間の標準オントロジーを定義し、ミッション・アーキテクチャのコラボレーションを支援することができる。

UAFMLは、一貫性のあるエンタープライズ・アーキテクチャやミッション・アーキテクチャをデジタル・モデルとして作成するための、拡張されたステレオタイプとルールのセットを提供する。これらのモデル・ベース・システム・エンジニアリング（MBSE）モデルはリポジトリとなり、そこから様々なビューを抽出することで、依存関係やトレーサビリティを強調し、シニアリーダーやミッション・アーキテクトの重要な質問に答えることができる。

UAF第1.2版付録Aには、「UAF第1.2版からDoDAF第2.02版」と「UAFMLステレオタイプからSysMLおよびUMLメタクラスへ」のマッピング・テーブルがある[10]。

2.2.5.       ミッション・アーキテクチャに対するUAFML

ミッション・アーキテクチャを文書化する方法は複数ある。本ガイドは、国防次官室：研究・エンジニアリング担当（OUSD（R&E））ミッション統合（MI）がミッション・アーキテクチャを作成するためにUAF仕様を適用したものである。UAFMLは事業体をモデル化するようにデザインされており、大規模なミッション・アーキテクチャをモデル化するのに適している。ミッション・アーキテクチャは、システム、サービス、人材、プロセスなど、実戦配備された能力を実現するための主要な要素を表現することにより、能力の計画策定やポートフォリオ管理を支援することができる。UAFモデルは、組織、作戦、システム、およびサービス間に存在する複雑な関係を理解するための手段を提供するとともに、ユーザー・コミュニティの期待を確実に実現するための分析を可能にする[11]。

図5は、ミッション・エンジニアリング（ME）プロセスをサポートするために活用できる様々なビューを強調したUAFグリッドのオーバーレイを示している。UAFグリッドの視点（行）と側面（列）は、合わせてモデル内の情報を表している。戦略的視点は通常、能力管理プロセスを支援するために利用され、ミッションの文脈、到達目標、能力、脅威を定義する。作戦上の視点は、ミッション・スレッド・レベルにマッピングされ、ソリューションにとらわれないミッションのビューを提供する。リソース（Resources）の視点は、ミッション・エンジニアリング・スレッドを通じて、ミッションに対するよりソリューションに特化した視点を示す。

ミッション・エンジニアリング・スレッド・レベルでは、組織、技術、システム等を、それらが実行する様々な機能に割り当てる。すべての視点において、成功の尺度（MOS）、効果の尺度（MOE）、性能の尺度（MOP）など、アーキテクチャを評価するために使用される尺度や測定は、パラメータの側面で捉えることができる。このガイドで示され、図5で強調されているビューは、ミッション・エンジニアリング・プロセスをサポートするために作成できるものの出発点であることに注意しされたい。

各軍種（Services）、人員（Personnel）、セキュリティ（Security）、プロジェクト（Projects）、および標準（Standards）の各視点は、モデル情報に追加的な視点を提供し、特に非物資の要素について、完全なミッションを表現するのに有益である。UAFプロファイルは、DoDAFやビジネス・プロセス・モデリング表記法（Business Process Modeling Notation ：BPMN）のような他のアーキテクチャ・モデリングのフレームワークや言語から移行する際に活用できる補完的なビューを含んでいる。ビジネス・プロセス・モデリング表記法（BPMN）を利用して活動シーケンス（activity sequences）や関係する人間や組織を描写するオフィスでは、UAFの人員-プロセス・フロー（Ps-Pr）ダイアグラムを使用することが望ましい。

図5. UAF第1.2版のミッション・エンジニアリング・ビュー[12]

2.3.          連合（モジュラー）アーキテクチャの重要性

ミッション・エンジニアリング（ME）モデルを再利用可能な情報とケース固有の情報に分離する方法は無限にあるが、UAFはすでにモデル情報をセグメント化しており、トップレベルのパッケージに基づいて別々のモデルを作成することができる。戦略、作戦、各軍種、人事、リソース、セキュリティ、プロジェクト、標準、実際のリソースである。フェデレーションのニーズをできるだけ早い段階で検討し、モデルを分割して構築することで、省内のアーキテクチャ管理とガバナンスを容易にすることができる。このアプローチは、モデルのクエリにかかる時間を短縮し、チーム・メンバー間のモデル・アクセスの競合を減らし、権威あるモデル・ライブラリの再利用を促進し、モデルの変更と構成管理をより詳細に制御するのに役立つ。

共通のアーキテクチャ・モデリングのフレームワークとガバナンス構造を持つことは、相互運用性、再利用、成熟を可能にする厳密性と柔軟性を示すバランスの取れた基盤として機能する。

フェデレーションは実行するのは複雑だが、本質的には役に立つ。モジュール化は、アーキテクチャの効果的な信条を採用することを促進する。モジュール性、相互運用性、オープン性、疎結合（loose coupling）、複合性、標準準拠、明確性、適応性、スケーラビリティは、単一の組織のためではなく、多くの人々やより大きな国防総省（DoD）チームのために使用できるアーキテクチャを作成するために協力することの利点である。ここで言及した信条（tenet）の定義は、本ガイドの用語集を参照することで、さらに理解を深めることができる。

連合モデルまたはモジュール・モデルにより、モデルとその要素を再利用し、対象システムのアーキテクチャを完全に定義することができる。これにより、さまざまな利害関係者（軍種の構成部隊、国防長官室、連邦政府研究開発センター（FFRDC）、大学附属研究センター（UARC））、および他の信頼される組織が、アーキテクチャを作成する際に共通の真理源を所有し、関連するモデル要素およびビューのみを見ることができる。共通要素ライブラリ、プロファイル、および言語は、アーキテクチャ・モデル間の基本的な互換性のための標準アーキテクチャ・フレームワークを提供する。権威あるアーキテクチャ情報は、各軍種によって提供され、検証される。

ミッション統合は、各軍種からのインプットを用いて統合ライブラリの検証を行う。権威ある情報が特定できない、または見つからない場合は、将来調査する可能性のある分野として、モデル内に文書化するか、付属のモデル文書に含める必要がある。

統合出版物、普遍的統合タスク・リスト（Universal Joint Task List ：JTL）、統合共通システム機能リスト（Joint Common System Function List ：CSFL）、統合能力領域（JCA）、および軍事部門からのインプットを使用して、共通ライブラリが作成され、ミッション・アーキテクチャの作成のために活用される。特定のソリューションに合わせるために、共通要素ライブラリ（例えば、システム、組織、役割、施設、政策、ドクトリン）は、ドメインの専門知識を持つものによって起草され、国防総省（DoD）コミュニティ内で共有される。この共同作業により、作成されるアーキテクチャの忠実度を高める共通の真実の情報源（バージョニング付き）が可能となる。

図6は、シナリオ・レイヤーからプラットフォームとシステムレイヤーに至るまで、提案されている情報のモデル編成の概要を表している。最もソリューションにとらわれないレベルでは、ドクトリンとインテルがミッションに情報を提供する。最初の2つの層（プラットフォームとシステム、およびプラットフォーム・コンフィギュレーション）は、ミッションを達成するために必要な貢献者の組み合わせを開発する際に再利用するための、基本的な開始テンプレートで構成される。これらのモデルは維持され、可能なオプションのライブラリとして提供される。赤い破線の上方では、情報はますますミッションに特化したものになるが、代替案やエクスカーションを検討する際には、ある程度の再利用性は維持される。情報は最下層から上にのみ流れる。

モデル要素を必要とする可能性のある他のモデルから見えるように、モデル要素を定義する場所を決める際には、重要な考慮が必要である。既存のモデル要素に情報のレイヤーを追加するために、特殊化することは常に可能である。

図6. 連合アーキテクチャ・モデルの構成

最終的なビジョンは、米国オリンピックチームのような全体的なモデル統合チームでの役割を助けることができるサービス利害関係者リエゾンを導入することによって、努力の統一を可能にすることであるが、その一方で、主として所属する組織（例えば、米国空軍、米国海兵隊）に所属することに変わりはない。図7は、ミッション・アーキテクチャとそれに対応するライブラリの中央ハブとして、ミッション統合担当国防副次官補室（ODASD（MI））を持つハブ・アンド・スポーク・モデルを描いている。ミッション統合担当国防副次官補室（ODASD（MI））、軍種構成部隊、統合参謀、国防次官室：取得・維持担当（OUSD（A&S））、およびその他の組織の間のスポークは、すべての「ハブとスポーク」ユニットを行き来するアーキテクチャ情報の双方向の流れである。航空会社に例えると、情報は中央のハブへと流れ、省庁の取り組みを同期化させる。これらのミッション・アーキテクチャは、様々な利害関係者が参照アーキテクチャ、参照パターン、および全体的な情報源として使用することもできる。

 

図7. アーキテクチャ・ハブ＆スポーク・モデルの例

ハブ・アンド・スポーク・ミッション・アーキテクチャの模範には、次のような優位性がある。

・  洞察力とコネクティビティの向上（Increased Insight and Connectivity）： ハブ・アンド・スポークの作戦により、関係者は組織間の双方向接続を促進し、洞察と透明性を提供できる。

・  集中型アーキテクチャ統合と分散型アーキテクチャ（Centralized Architecture Integration and Decentralized Architecting）： ミッション統合担当国防副次官補室（ODASD（MI））は、ガバナンスの実行、重複の防止、リソースの集中、情報共有メカニズムの確立、利害関係者とのアーキテクチャ構成の共有のための中心的ハブとしての役割を果たすことができる。これは、中央ハブが必ずしもモデルを管理するという意味ではない。ミッション統合（MI）は、洞察と監視を選択し、利害関係者に分散型アーキテクチャを実行させる。

2.4.          ミッション・アーキテクチャ・モデルとミッション・アーキテクチャ・ビュー

2.4.1.       ミッション・エンジニアリング・モデルの構成

覚えておくべき重要な点は、モデルとはデータ/情報と要素間の関係であるということである。ビューはモデル要素のスライスを提供する。図8は、デジタル・エンジニアリング・ツールで作成されたプレゼンテーション・フロー・ビューを示している。これにより、ユーザーはビューをエクスポートすることなく、PowerPointのブリーフィングを最初から最後までナビゲートするように、異なるビュー間でモデルをナビゲートすることができる。

図8. 要約と概要のプレゼンテーションの流れ

よく構造化されたモデルを持つことは、ミッション・エンジニアリングのビューに表示される情報を整理するために非常に重要である。PowerPointやその他のテキスト表現ではなく、モデルを作成することの主な利点の一つは、要素を異なるビューで表現し、動的につながりを示すことができることである。スタイル・ガイドの以下の節では、いくつかのビューと、それらがどのようにミッション・エンジニアリング・プロセスと整合するかを示す。

2.4.2.       ミッション・エンジニアリング・アーキクチャ・ビュー

図5に示すように、UAFをミッション・エンジニアリングに適用する方法は数多くある。このスタイル・ガイドでは、ミッション・エンジニアリングの取り組みを支援するために、ミッション・エンジニアリングアーキテクチャの要素とビューの主要なセットを特定する。この主要なセットは網羅的なものではないが、国防次官室：研究・エンジニアリング担当（OUSD（R&E））のミッション統合（MI）が実行するミッション要素（タスクを実行する人、組織、プラットフォーム、および／またはシステム）、関係、およびプロセスを捕捉するための出発点を示すものである。これらには以下が含まれる。

表1. 主要なミッション・エンジニアリング・アーキテクチャの成果物
主な成果物	目的	UAFビュー
シナリオの到達目標	到達目標にマッピングされたシナリオと作戦のビュー	戦略的語彙（St-Tx）
シナリオの内訳	シナリオからヴィネット、ミッション、ミッション・スレッド、ミッション・エンジニアリング・スレッドへのトレーサビリティ/内訳を表示する。	戦略的語彙（St-Tx）
ミッション・スレッド（MT）	ドクトリンに基づき、ソリューションに依存しない。ミッションを遂行するためのアプローチにおける一連のタスク、活動、イベントを説明する。	作戦プロセス・フロー（Op-Pr）
戦闘序列（OB）／アセット・リスト	シナリオ、作戦、ヴィネットの全ミッション要素の表示	リソース構造（Rs-Sr）
ミッション・エンジニアリング・スレッド（MET）	ミッション遂行のアプローチにおいて、タスク、活動、イベントを実行する機能にアクターを割り当てる。	リソース・プロセス・フロー（Rs-Pr）
ミッション・エンジニアリング・スレッド・エンド・ツー・エンド（E2E）ビュー	ミッション要素間の接続と、その間の交換。シニア・リーダーシップへのプレゼンテーションに推奨の資料	リソース内部接続性（Rs-Cn）

組織、システム、システム・オブ・システムズ（SoS）の間に存在する追加的な関係を強調するために、ミッション・エンジニアリングの問題範囲に基づいて、追加のアーキテクチャ成果物を捕捉することができる。これらのダイアグラムには以下のものが含まれるが、これらに限定されるものではない。

表2. ミッション・エンジニアリング・アーキテクチャの追加の成果物
追加の成果物	目的	UAFビュー
普遍的統合タスク・リスト（UJTL）タスクからミッション・スレッド（MT）タスクへのマッピング	ミッション・スレッド（MT）の活動（タスク）をドクトリンまで遡る	作戦プロセス（Op-Pr）
普遍的統合タスク・リスト（UJTL）タスクからミッション・エンジニアリング・スレッド（MET）機能へのマッピング	ミッション・エンジニアリング・スレッド（MET）の機能をミッション・スレッド（MT）のタスクにトレースし、完全な会戦計画を確認する	リソース・プロセス（Rs-Pr）
測定表	シナリオ／作戦／ヴィネットの測定値（成功の尺度（MOS）、効果の尺度（MOE）、性能の尺度（MOP））を表す。	典型的な測定マトリックス（Pm-Me）

3.     ミッションの問題と機会

ミッション・エンジニアリング（ME）プロセスの最初のステップは、ミッションの問題を特定し理解することである。事業体レベルでは、アーキテクトは主要な利害関係者と協力して、ミッション・エンジニアリング研究のミッションの文脈を理解する。アーキテクトは、関連する既存のアーキテクチャやソースとなる成果物を収集しレビューすることで、問題空間の理解を助ける。これらのミッション・アーキテクチャは、時間の経過とともに更新、再利用される生きたデジタル成果物である。

これには、統合参謀の有効なミッション・スレッド（MT）などを通じて、過去に問題や類似の問題がどのように記述されたかについての情報が含まれる。研究方法論に情報を提供するためには、ミッション問題のニーズと範囲を理解することが不可欠である。ミッションの問題と機会を特定することに関する追加的な詳細については、ミッション・エンジニアリング・ガイド第2版（MEG 2.0）の第3節を参照のこと。

ミッション・エンジニアリング・ガイド第2版（MEG 2.0）で論じたように、ミッション・エンジニアリングの目的は、能力ギャップの特定、原因と結果の探求、潜在的ソリューション（potential solutions）のトレードスペースの評価、新たな機会のミッションインパクトの投資という4つの形態のいずれかを取ることができる。以下の「砂漠の嵐作戦」の例では、「能力ギャップを特定する（identify capability gaps）」ミッション目的と、それに関連する問題範囲の質問を示している。

ミッションの問題の例：砂漠の嵐作戦 ミッションの問題：1991年、イラクのクウェート侵攻とその後の撤退拒否に対して、米国を中心とする連合軍は、クウェートを解放しサダム・フセインの戦争遂行能力を解体するために軍事力を行使することを選択した。イラクは、世界で最も強固な統合防空システムのひとつを実戦配備していた。この主要な課題によって、連合軍は、さらなる軍事行動を促進するために、制空権を握る機会を作り出す方法を特定しなければならない。 能力ギャップを特定する（Identify capability gaps）： 研究の到達目標、およびアーキテクチャをモデル化する目的は、ミッションの成功に影響を及ぼす可能性のある計画上の潜在的ギャップを特定し、そのギャップに対処するための潜在的ソリューションを評価することである。 1. 計画されたミッションは、イラクにおけるさらなる軍事的移動と行動のためのルートを開く連合軍の能力を支援するか？ 2. 連合軍がミッションの目標を達成するのを妨げる要因やギャップは何か。 注：この例は、国防総省（DoD）の志向する顧客に関連するデモンストレーションを目的として、本文書ではさらに簡略化されている。作成されたアーキテクチャは、問題セットに基づいて拡張することができる。

UAFの戦略的語彙（St-Tx）ダイアグラムは、ミッションの到達目標と目標を示すために作成することができる。

ミッションの問題または機会の例： 砂漠の嵐作戦の到達目標の特定 図9のUAF戦略分類法は、「砂漠の嵐作戦」のミッションとその4つの主要な到達目標を表している。（1）イラクのクウェートからの無条件撤退、（2）クウェートの合法的政府の回復、（3）在外米国民の生命保護、（4）ペルシャ湾の安全と安定の促進である。 図9. 砂漠の嵐作戦の到達目標（UAF戦略分類法） 注：この想定例は、デモンストレーションのためにさらに簡略化されている。ロジスティクスと計画段階の目標は含まれていない。

4.     ミッションの特徴付け

ミッション・スレッド（MT）とミッション・エンジニアリング・スレッド（MET）を計画策定する前に、ミッションの到達目標が定義される。ミッション・エンジニアリングは2つの基礎的要素を特定することから始まる。

1．ミッションとは何か？

2．ミッションについて何を調査するのか？

これらの要素は、その後に続くミッション・エンジニアリング活動のスコーピングに極めて重要である。当初から、どのような到達目標や意思決定が通知されるかを明確に理解することが重要である。意思決定の必要性を理解することで、ミッション・エンジニアリング調査の「だから何（So What）」に取り組むための取組みに焦点が絞られる。

ミッションの特性評価に関する詳細は、ミッション・エンジニアリング・ガイド第2版（MEG 2.0）の第4節を参照のこと。

4.1.           ミッションの文脈の開発

ミッションの特徴づけのステップでは、ミッションの文脈を理解することに重点を置く。ミッションの文脈とは、背景設定、条件、時間枠、作戦戦略、および、ミッション・エンジニアリング（ME）の取組みの焦点となり、重要な質問に答えることに特有なミッションの目標である。

統合条件ライブラリは、条件を定義するための出発点である。統合条件は、ミッション・デザイナーが、選択されたミッションの作戦状況を記述するために使用できる物理的、軍事的、および市民的条件を定義する方法のフレームワークみとして使用できる共通リストを提供する。

ミッションの特徴付に関するさまざまな情報源としては、国防計画シナリオ、作戦計画（O-Plans）、運用のコンセプト（Concept of Employment ：CONEMP）、作戦コンセプト（Concept of Operations ：CONOPS）、戦術的運用指針（tactical employment guides）などがある。このスタイル・ガイドの例は、青（米国）の視点からのミッション特性を記述することに重点を置いているが、ミッション特性は緑（連合軍）や赤（敵）の部隊についても完成させることができる。これには、シナリオ、作戦、およびヴィネットに関与する各当事者のミッションの文脈を定義することも含まれる。

まず、シナリオ、作戦、ヴィネットの内訳を示す初期ビューを作成する。シナリオは、ミッションの具体的な説明と意図を、関連するエポックとともに捉えたものである。シナリオは、作戦とヴィネットに分解することができる。ヴィネットとは、行動、プレイヤー、システムといった一連の出来事に集中するように組み立てられた、シナリオの小さなサブセットである。

シナリオ、作戦、およびヴィネットの間の内訳を明確に理解することで、問題セットのスコーピングが可能になり、どのようなアーキテクチャを作成するかがわかる。研究を支援し、研究の疑問に包括的に答えるアーキテクチャを選択する。ほとんどのソース文書は、シナリオ、作戦、およびヴィネットをモデル化するのに十分なほどきれいにレイアウトしていないことに注意しされたい。

その代わりに、アーキテクトはソース文書から推論を行い、関連するミッションやドメインの専門家とレビューし、更新する必要がある[13]。

ミッションの特徴付の例：「砂漠の嵐」作戦のシナリオとヴィネット 砂漠の嵐作戦でクウェートを解放するためには、連合軍は制空権を獲得し、バグダッドへの移動の自由を獲得する必要があった。連合軍はまず、イラクの強固な防空システム、あるいはその一部を排除する必要があった。 シナリオ（Scenario） :米国中央軍（CENTCOM）1991年、砂漠の嵐作戦: 可能なヴィネット ・　航空優勢の確立 ・　中央集権的な指揮統制（C2）を破壊する 図10は、シナリオをヴィネット、ミッション、ミッション・スレッド（MT）、ミッション・エンジニアリング・スレッド（MET）に分解したものである。本ガイドでは、「航空優勢の確立」ヴィネットをより詳細にモデル化している。この例は、敵防空制圧（SEAD）ミッション・スレッド（MT）の制圧を使用してイラクの早期警戒能力を否定するミッションを中心としている。この例では、赤軍は独自の能力、条件、手段、実行者を持つ統合防空ミッションを遂行する。この図は、赤（red）と青（blue）のミッション間の相互作用を表す方法の一例を示している。 図10. 「砂漠の嵐作戦」のシナリオ内訳（UAF戦略的語彙） 注：この例は、国防総省（DoD）の指向する顧客に関連する実証を目的として、本文書ではさらに簡略化されている。作成されたアーキテクチャは、問題セットに基づいて拡張することができる。このミッションを支援するため、代替案やエクスカーション・ミッションのアプローチを表す追加ミッション・エンジニアリング・スレッド（MET）を作成することができる。

4.2.          ミッションの尺度と評価指標を定義する

よく定義されたモデルには、成功のための定量化可能な測定値が含まれ、システムの選択に先立ち、状況の分析に基づいて定義される。シナリオ、作戦、ヴィネット、そしてミッションが、アーキテクチャに取り込まれる測定値を推進する。成功の尺度（MOS）は評価すべき目的を定量化し、ミッションが成功したかどうかを判断する。

効果の尺度（MOE）は、一連のタスクの実行を評価する手段を提供する。効果の尺度（MOE）は、一連のタスクの実行を評価する手段を提供するものである。効果の尺度（MOE）は、主にミッション・スレッド（MT）レベルでミッションを定量化し、我々は正しいことを行っているのか、あるいは代替の行動が必要なのかを回答するのに役立つ。ミッション・エンジニアリング・スレッド（MET）レベルでは、性能の尺度（MOP）は、ミッション機能または軍事効果を遂行するために使用されるシステムまたはアクターの目標パラメータまたは性能特性を定量化する。性能の尺度（MOP）は、タスクが標準通りに完了したかどうかを判断するのに役立つ。

対策は、普遍的統合タスク・リスト（UJTL）のようなソース文書から導き出すことができる。普遍的統合タスク・リスト（UJTL）の各タスクは、その有効性とタスクの成功を定量化するために、関連する尺度とともにリストアップされている。ヴィネット・レベルの成功の尺度（MOS）からシステム・レベルの性能の尺度（MOP）まで、尺度は論理的に分解される。シナリオの成功の尺度（MOS）は、1対多の効果の尺度（MOE）に関連付けることができる。普遍的統合タスク・リスト（UJTL）と統合共通システム機能リスト（JCSFL）の使用とともに、軍種固有のタスク・リストのタスクは、統合ミッション・スレッドやミッション・エンジニアリング・スレッドを作成する際に文脈を提供するために使用することができる、サービスが保持する関連する効果の尺度（MOE）を持っている。

性能の尺度（MOP）は、戦術的な普遍的統合タスク・リスト（UJTL）タスクや統合共通システム機能リスト（JCSFL）の機能を出発点として導き出すことができ、建設的なシミュレーション、演習、デモンストレーション、実験の結果を通じて、基準をアーキテクチャに遡及的に追加することができる。作戦の有効性、適合性、生存性、致死性（適切な場合）などの作戦の性能指標は、作戦上の試験・評価（DOT&E）によりすべてのプログラムで評価される。よく形成されたモデルでは、望ましい効果について測定基準が定義され、ミッション・スレッド（MT）内のシステム必須タスクの配分に対して結果が評価される。タスクの成功、有効性、または性能の特定の尺度に関連する最低許容レベルとして定義される基準は、普遍的統合タスク・リスト（UJTL）によって定義されないことに注意されたい。シナリオとその条件が基準を定義する。

砂漠の嵐作戦での成功の尺度（MOS）、効果の尺度（MOE）、性能の尺度（MOP）の例 「砂漠の嵐作戦」の敵防空制圧（SEAD）作戦において、タスク部隊ノルマンディの目標は、イラクの防空システムの一部を目くらましにすることだった。 図 11は、「砂漠の嵐作戦」の成功の尺度（MOS）、効果の尺度（MOE）、および成功の尺度（MOS）の想定例と、航空優越確立のヴィネットである。 図11. 砂漠の嵐作戦の成功の尺度（MOS）、効果の尺度（MOE）、性能の尺度（MOP）（UAFの代表的な測定マトリックス）

5.     ミッション・アーキテクチャ

問題セットとそれに答えるべき質問を十分に理解した上で、次のステップはミッション・アーキテクチャを開発することである。このプロセスは、シナリオとヴィネットをインプットとして開始し、以下のステップを含む。

1. ミッションの文脈と対策、必要な能力を理解するための情報収集を行う。成功の尺度（MOS）と効果の尺度（MOE）を完全に理解することで、望ましい最終状態に対するヴィネットの正確な評価と定量化が可能となる。
2. 既存のミッション・スレッド（MT）を活用する。存在しない場合は、望ましい効果を分析することにより、関連するミッション・スレッド（MT）を新たに開発する。
3. 米国、同盟国の戦闘員、敵対勢力のために、関連するすべてのミッション要素を捕捉する。
4. ミッション・スレッド（MT）の活動（タスク）にミッション要素を割り当ててミッション・エンジニアリング・スレッド（MET）を作成する。
5. アーキテクチャの一部として、ミッション要素間の関連する通信、情報、情報の流れを表現する。

これらのステップを最初に通過することで、初期アーキテクチャが得られる。ベースライン・ミッション・アプローチ・アーキテクチャは、ミッション・エンジニアリングの取り組みにおいて、ミッションの実行方法について合意された出発点を示すものである。これは、各コンセプトのアーキテクチャに加えられる変更、追加、削除と比較するための基礎となる。代替アーキテクチャは、ミッションの実行方法に関するベースライン・ミッション・アプローチに対する変更を示すものである。

砂漠の嵐作戦のタスク部隊ノルマンディのベースライン・代替、エクスカーション タスク部隊ノルマンディの例でいえば、ベースライン・ミッション・アプローチ（baseline mission approach）は、視界と天候が明瞭で、すべてのミッション要素がフラッグ通りに配置されたと仮定して、ミッションを完了させるものである。 代替ミッション・アプローチ（alternative mission approach）は、視界が良好で天候要因がないことを前提として通信中継を実行するための新しいコンセプトであるMC-130Eを導入することを意味する。 エクスカーション・ミッション・アプローチ（excursion mission approach）では、タスク部隊ノルマンディのミッションは、砂嵐の中で実行される（条件はさまざま）。砂嵐は視界を悪くし、ミッションの成功に新たなリスクをもたらす。エクスカーション・アーキテクチャは、MH-53ヘリコプターがAH-64ヘリコプターの較正ポイントを示すためにライトスティックを投下するベースラインとは異なる実行アプローチを示す。 エクスカーションによる代替のミッション・アプローチ（alternative mission approach with an excursion）では、砂嵐の中で通信中継を行う新しいコンセプトのMC-130Eを導入する。 注：MC-130Eは「砂漠の嵐作戦」で使用され、2013年に退役した実在の機体であるが、デモンストレーション目的のため、既存の機体に新たなテクノロジー・コンセプトを搭載した機体として表現している。

ベースライン・アーキテクチャと代替アーキテクチャは、この研究が何を分析しようとしているかを正確に説明するものである。各代替アーキテクチャは、ベースライン・アーキテクチャのバリエーションである。各ミッション・エンジニアリングスタディでは、開始時の代替案を定義する。代替案とは異なり、エクスカーションはベースラインの前提、ミッション要素、および動作の変更を表すためにモデル化される。

代替とエクスカーションの違いに注意することが重要である。代替案とは、ベースライン・アーキテクチャに新しい技術やコンセプトを導入することであるのに対し、エクスカーションとは、ベースライン・アーキテクチャのミッションの文脈、ミッション要素、動作、および関連する前提を変更することである（図12）。エクスカーションの例としては、ベースライン・アーキテクチャの既存技術の入れ替え、アセットの場所の変更、シナリオに関与する国やプレイヤーの変更などがある。

図12.       ベースライン、代替、エクスカーションの説明

通常、新しい、あるいは異なる方法でミッションを遂行する場合（例えば、新しいドクトリンや新技術が新しいやり方を可能にする）には、ベースライン、エクスカーション、代替ケースの間で各ミッション・エンジニアリング・スレッド（MET）アーキテクチャに違いがあるが、各ミッション・スレッド（MT）は同じ効果と対策を含むように抽象化されるべきである。ミッション・アーキテクチャに関連する詳細については、ミッション・エンジニアリング・ガイド第2版（MEG 2.0）の第5章を参照されたい。

5.1.           ミッション・スレッドの開発

シナリオ、作戦、ヴィネット、ミッションの望ましい効果に基づいてミッション・スレッド（MT）を開発する。国防総省（DoD）は、ミッションを「目的とともに、取るべき行動とその理由を明確に示すタスク」と定義している[14]。その結果、ミッションは重要なタスクと関連付けられることになる。

到達目標は、特定された各ミッションに1つのミッション・スレッド（MT）を開発することである。

各ミッション・スレッド（MT）はソリューションにとらわれないようにデザインされていることに留意してほしい。利用可能かつ適切な場合には、普遍的統合タスク・リスト（UJTL）、統合共通システム機能リスト（JCSFL）、軍種固有のタスク・リスト、および統合ミッション・エッセンシャル・タスク・リスト（JMETL）のようなドクトリン・ベースのスレッドやリソースは、ミッション・スレッド（MT）のための好ましい出発点を提供する。

タスクを組織化して、ミッションのアプローチを順次記述することは有用である。この例では、国防次官室：研究・エンジニアリング担当（OUSD（R&E））のミッション統合（MI）内で一貫した表示形式を提供するため、目標発見－対象特定－追尾－ターゲット設定－交戦－効果評価（Find-Fix-Track-Target-Engage-Assess ：F2T2EA）キル・チェーンを使用している。あるいは、他の支援ミッションでは別の構成がとられることもあるため、ミッション・スレッド（MT）またはミッション・エンジニアリング・スレッド（MET）のフレームワークみには、航空ミサイル防衛の探知から交戦までのシークエンスのような、適切なキネティックな効果のチェーン（kinetic effects chain）またはノン・キネティックな効果のチェーン（kinetic effects chain）を使用する。このガイダンスは、キネティック、ノン・キネティック、サイバー、および後方支援の各用途に適用される。

ミッション・スレッド（MT）は作戦的な観点からモデル化される。作戦の実行者は、機能的・論理的カテゴリーへの解を抽象化するために使用できる。作戦の実行者の導入は、UAFの観点と一致するが、同時に特定のミッション要素には不可知論的である。

ミッション・スレッドの例: 砂漠の嵐作戦のタスク部隊ノルマンディ タスク部隊ノルマンディの目標、あるいは望ましい効果は、イラク防空システムの早期警戒能力を否定し、航空攻撃のための無防備な通路を作り出すことであった。この目的を達成するため、連合軍はイラク防空システムに対する敵防空制圧（SEAD）作戦を実施した。トップレベルの敵防空制圧（SEAD）ミッション・スレッド（MT）は、UAFMLの作戦プロセス・フローを使って作成できる（図13）。 図13. 敵防空制圧ミッション・スレッド（UAF作戦プロセス・フロー） 図 13のタスクは、JP 3-01、普遍的統合タスク・リスト（UJTL）、統合共通システム機能リスト（JCSFL）など、さまざまなソース文書を使用して導き出された。共通の語彙を確保するため、ミッション・スレッド（MT）タスクは普遍的統合タスク・リスト（UJTL）タスクと比較され、トレースされた（図14）。普遍的統合タスク・リスト（UJTL）だけでは、ミッション・スレッド（MT）で実行される活動に関連付けられるすべてのタスクが含まれているとは限らないことに注意されたい。さらなる詳細については、統合共通システム機能リスト（JCSFL）や、ドメインや軍種固有のタスク・リストを共通言語として参照する必要がある。 図14. 普遍的統合タスク・リスト（UJTL）トレーサビリティによる敵防空ミッション・スレッドの制圧

普遍的統合タスク・リスト（UJTL）は、統合参謀によって維持される戦略的、作戦的、および戦術的レベルでの統合軍事タスクのリストである。各普遍的統合タスク・リスト（UJTL）タスクは、その有効性、および/またはタスクの成功を定量化するための関連する尺度とともにリストされている。これらの尺度のための基準またはしきい値は、普遍的統合タスク・リスト（UJTL）で指定されていないとシナリオとその指定された条件を決定する必要があることに注意しされたい。統合共通システム機能リスト（JCSFL）は、統合参謀によって維持されるシステム機能の共通辞書である。

統合共通システム機能リスト（JCSFL）の機能は、国防総省（DoD）のシステムやシステム・オブ・システム（SoS）の能力や機能を、異なるドメインや分野にまたがって記述し評価するために使用される。統合共通システム機能リスト（JCSFL）は、指揮統制、通信、インテリジェンス・監視・偵察（ISR）などの機能カテゴリーで構成されている。統合共通システム機能リスト（JCSFL）の機能は、各ミッション・エンジニアリング・スレッド（MET）における活動を定義するための出発点として、他の情報源と併せて使用されるべきである。

CAMEOのUAFプロファイルには、普遍的統合タスク・リスト（UJTL）の秘区分無しの作戦活動（タスク）から構成される要素ライブラリが含まれている。しかし、CAMEOモデリング・ツールの普遍的統合タスク・リスト（UJTL）ライブラリは秘区分無しであり、最新の更新が反映されていない可能性があることに注意しされたい。アーキテクトは、権威ある普遍的統合タスク・リスト（UJTL）ライブラリ[15]でタスクを検証し、必要に応じて、より高い分類の普遍的統合タスク・リスト（UJTL）ライブラリを確認する必要がある。ミッション・スレッド（MT）ステップは、1つ以上の普遍的統合タスク・リスト（UJTL）タスクに対して、分解、一般化、その他適切な関係を持つことができる。ミッション・スレッド（MT）のステップを普遍的統合タスク・リスト（UJTL）タスクにマッピングすることで、アーキテクトはドクトリンへの直接的なリンクを確立し、モデルの血統を強化することができる（図 15）。

ミッション・スレッドの普遍的統合タスク・リスト（UJTL）へのマッピングの例:砂漠の嵐作戦のタスク部隊ノルマンディ 敵防空制圧（SEAD）ミッション・スレッド（図14）に示された個々のステップは、UAFの作戦プロセス（Op-Pr）ダイアグラムを使用して図 15の普遍的統合タスク・リスト（UJTL）にマッピングされ、モデル内でドクトリンへのトレーサビリティを示す。 図15. ミッション・スレッド（MT）タスクと普遍的統合タスク・リスト（UJTL）タスクのマッピング（UAF作戦プロセス）

ミッション・スレッド（MT）にとって重要なポイント

適切であれば、既存のミッション・スレッド（MT）を使用してもよい。必要であれば、更新や修正を適用して、現在のヴィネットに適合させる。

ミッション・スレッド（MT）はソリューションにとらわれない。ミッション・スレッド（MT）は、フロー内の各活動がどのように、あるいは誰によって達成されるかではなく、イベントの連鎖におけるタスクの実行順序を記述するという点で区別される。

ミッション・スレッド（MT）は必要な情報の流れに焦点を当てる。アーキテクチャの初期作業には、ソース文書を研究し、それらの認可されたソースをモデリング言語要素に翻訳することが含まれる。これらのソースが不完全であったり曖昧であったりする場合は、主題専門家（SME）やユーザー・コミュニティと協議し、アーキテクチャ内の情報を検証する。実践においては、作戦戦術がドクトリンに記述されている領域を拡大する可能性があることを認識する。

トップレベルのミッション・スレッド（MT）はソリューションに依存しないため、ドクトリン、戦術、技術、手順（TTPs）、交戦規則、普遍的統合タスク・リスト（UJTL）タスク、および統合共通システム機能リスト（JCSFL）機能に要求される忠実度を十分に扱うためには、ドリル分解するのが賢明である。さらに分解を進めると、デザイン上の制約が早まる危険性がある。適切な情報源であれば、利害関係者の要求に応えるために詳細を追加することができる。

ミッション・スレッド（MT）が開発されるにつれて、シナリオ、作戦、ヴィネットにおいて、追加的な問題、能力ギャップ、関連情報が特定されるかもしれない。これらの問題に対処するためには、これらの成果物の明確化と更新が必要となる。未解決の問題は、システムに特定する必要のあるギャップや脆弱性があることを示す指標となる。

各ヴィネットとミッションについて、1つから多数のミッション・スレッド（MT）が特定される。ミッション・スレッド（MT）は、統合および各軍種固有のドクトリンに基づいて、青部隊（blue forces）のために作成される。グリーン部隊のミッションは、米国と直接連携している場合には、青部隊（blue forces）のミッション・スレッド（MT）内で表現することができ、同じ全体の到達目標を支援する別個のミッションを遂行する場合には、ドクトリンなどに基づいて別個に表現することができる。赤部隊（Red force）のミッションとミッション・スレッド（MT）は一般に、情報機関から提供された情報に基づく。

複雑なシナリオの場合、すべてを説明するような複雑なダイアグラムを使うのは控えられたい。これでは、主題の専門家がレビューするのが難しくなる。ダイアグラムは必要に応じて分解し、入れ子にする。ミッション・スレッド（MT）を作成するときは、公称フローをマップする。これは、既知の／現実的な脅威と状況を考慮する。公称フローや前提からの顕著な逸脱は、メモやコメントとして記録し、後の分析で考慮できるようにする。さらに分析を進めることで、独自のミッション・スレッド（MT）を開発することができる。

ミッション・スレッド（MT）はヴィネット内の特定のミッションの実行を表すが、システムに依存しない。ミッション・スレッド（MT）のフローロジックは可能な限り完全であるべきだが、それでもモデルの実行可能性の要件を満たさない可能性がある。

5.1.1.       デジタル・エンジニアリング・ツールでのUAF作戦プロセス・フローを使用したミッション・スレッド（MT）

UAFMLでミッション・スレッド（MT）を開発するには、作戦プロセス・フロー・ダイアグラムを利用する。SysMLでは、活動ダイアグラムを利用する。

・  作戦プロセス・フロー・ダイアグラムを作成する。

・  垂直スイムレーン（Vertical Swimlanes）： 垂直スイムレーンは、タスクを連続したフェーズに整理するために使用される。ミッション・スレッド（MT）を構成するために、実施されるミッションに関連する適切な効果のチェーンを使用する。

・  水平スイムレーン（Horizontal Swimlanes）： 水平スイムレーンは、特定のミッション要素にとらわれず、ミッション・スレッド（MT）の作戦の実行者に活動（タスク）を割り当てるために使用できる。活動を実施するアセットのタイプを示す必要がある場合は、抽象化されたレベルの水平スイムレーンを使用することができる。スイムレーンは、複雑なフローを節に整理して表示する目的で使用することができる。

・  初期ノード（Initial Node）： ミッション・スレッド（MT）の開始条件を示す。

・  作戦活動行動（Operational Activity Action）： フロー内の活動（タスク）を表す。作戦活動行動を作成することで、異なるミッション・エンジニアリングの視点間のトレーサビリティを示すことができる。

・  出力ピン（Output Pin）：各作戦活動行動には、「タイプ」が割り当てられた出力ピンが必要である。これらのピンは、ミッション・スレッド（MT）内の活動（タスク）間で転送される作戦情報の流れ（キー情報、リソースなど）を示すために使用される。各出力ピンの「タイプ」を示すこと。

–  各ピンには「タイプ」の作戦情報（Operational Information）が割り当てられ、活動（タスク）間を流れる情報（例えば、一般的には名詞や名詞状態のペア）がラベル付けされる。UAFでは、作戦情報は、実行された作戦活動（タスク）を介して交換可能な情報を示すために使用される。

・  入力ピン（Input Pin）： 入力ピン： 出力ピンと同様に、入力ピンも ミッション・スレッド（MT） 内の活動間の作戦情報の流れを示す。入力ピンは、前の出力ピンと同じタイプでなければならない。各入力ピンの「タイプ（Type）」と「名前（Name）」は非表示にすること。

・  作戦オブジェクト・フロー（Operational Object Flow）：ソース活動によって生成または送信され、ターゲット活動によって消費される情報を表す作戦活動行動間の接続。オブジェクト・フローは伝達される情報を表し、制御フローはアクティビティの操作順序を決定する。

・  活動パラメータ・ノード（Activity Parameter Node）または活動最終ノード（Activity Final Node）： 終了を表し、プロセスの出力/終了を示す。

・  ミッション要素、活動（タスク）、または機能の所有国を視覚的に示すため、すべてのダイアグラムに「凡例（Legend）」を使用する。デジタル・エンジニアリング・ツールに基づき、凡例は手動で適用することも、凡例項目の自動割り当てを可能にするパラメータを設定して適用することもできる。

CAMEOシステム・モデラー（Cameo System Modeler）のようなデジタル・エンジニアリング・ツールにおける、命名規則、ダイアグラムのフォーマット、標準化された色、凡例に関するより詳細なガイダンスについては、本ミッション・アーキテクチャ・スタイル・ガイド（MASG）第1版の付録9.1を参照のこと。

5.2.          戦闘序列の理解

戦闘序列（OB）は、「軍隊の人員、部隊、装備の識別、強さ、指揮構造、配置」[16]と定義される。戦闘序列（OB）アーキテクチャは、シナリオに含まれるミッション要素の全体的なラインアップを示し、リソース構造（Rs-Sr）ダイアグラムを使用してモデル化される。このビューでは、国別に既知のミッション要素とアクターの所有権が示される。

このアーキテクチャは、各ミッション・エンジニアリング・スレッド（MET）とエンド・ツー・エンド（E2E）ビューですべてのミッション要素が説明されていることを確認するために使用される。すべてのミッション要素を簡単に見ることができるようにすることに加え、すべてのミッション要素がビューとモデル全体で表現されていることを確認するためのチェックリストとしても機能する。これらのミッション要素は、ミッション・エンジニアリング・スレッド（MET）（UAFMLリソースのプロセス・フロー）とエンド・ツー・エンド（E2E）ビュー（UAFMLリソースの内部接続性）に表示される。

戦闘序列（OB）の例:「砂漠の嵐作戦」でのタスク部隊ノルマンディを焦点に 図16は「砂漠の嵐作戦」のUAFMLリソース構造（Rs-Sr）である。この図は、各プレイヤーのカテゴリーごとに、「砂漠の嵐作戦」の特定されたヴィネットに関与するミッション要素を示している。米国（青）の場合、これには様々なヘリコプター、武器、指揮統制、航空作戦センターが含まれる。この想定例では、イラク側の早期警戒レーダー・サイトは赤で表されている。連合軍はタスクフォース・ノルマンディには参加していないが、より大規模な作戦の構成要素であり、緑色で表している。戦闘序列（OB）のテストコンセプトを識別するために、オレンジ・ゴールドを使用する。この例では、プラットフォーム（AH-64）が武器（30mmキャノン砲、AGM-114ヘルファイアミサイル、Hydra-70）を装備していることを表現する一つの方法を示しているが、この関係を示す方法は他にもある。 図16. 「砂漠の嵐作戦」の戦闘序列（OB）アーキテクチャ（UAFのリソース構造）

5.2.1.       デジタル・エンジニアリング・ツールにおけるUAFリソース構造を利用した戦闘序列

UAFMLで戦闘序列（OB）を開発するには、図15に示すようにリソース構造ダイアグラムを利用する。SysMLでは、ブロック定義ダイアグラム（BDD）ダイアグラムを使用し、各ミッション要素をSysMLブロックとして表現する。

・  リソース構造ダイアグラムを作成する。

・  リソース・アーキテクチャ（Resource Architecture）： プロジェクトまたは研究の全体を表す。リソース・アーキテクチャは、ミッション・エンジニアリング・スレッド（MET）のステップが割り当てられるリソースの集合を表すために使用される。

・  能力構成（Capability Configuration）： 上記の例では、能力構成（capability configurations）は、所有国やカテゴリーに基づいて戦闘序列（OB）を分けるために使用される。能力構成は、ヴィネットの戦闘序列（OB）やミッションの戦闘序列（OB）を表現したり、システムの特定の構成や変異（variants）を示すために使用することもできる。また、シナリオ内で、どのミッション要素がベースラインまたは代替の一連の実行者の一部であるかを定義するために、別の能力構成を作成すべきである。

・  システム（System）： 定義された目的を達成する要素、サブシステム、またはアセンブリの統合された集合として定義される。システムは、オーダー・オブ・バトルにおけるミッション要素を表すために使用される。各システムまたはサブシステムは、1つ以上の能力構成（Capability Configurations）に接続されなければならない。

– 時には、複数の国が同じタイプのミッション要素を使用することもある。そのような場合は、国ごとに個別のミッション要素を作成する。

– システムは、研究対象の他のアーキテクチャに使用できる共通のシステム・ライブラリに由来するものでなければならない。

– 各ミッション要素の個々のプロパティとパラメータには、所有国を含める必要がある。アーキテクトは、記述モデルを完成させるために割り当てられる時間と、システムの定義に必要な可能な情報すべてを収集することの間でバランスを取りながら、取り込む情報がミッションモデルと分析の目的にかなうようにしなければならない。アーキテクチャに示されていない追加的な詳細情報は、アーキテクチャにおける重要なギャップを強調するコメントによって注釈を付けることができ、派生シミュレーションに反映させることができる。

・ 指示されたコンポジション（Directed Composition）: リソース・アーキテクチャと各能力構成間の接続は、このプロジェクトまたは研究の文脈でこれらの戦闘序列（OB）が存在するため、混合として表される。

・ ダイレクト・アグリゲーション（Directed Aggregation）： 各ミッション要素は戦闘序列（OB）の一部として含まれることなく独立して存在することができるため、能力構成とシステム間の接続は集約として表現される。

・ すべてのダイアグラムに「凡例（Legend）」を使用し、ミッション要素、活動、または機能の所有国を視覚的に示す。デジタル・エンジニアリング・ツールに基づき、凡例は手動で適用することも、凡例項目の自動割り当てを可能にするパラメータを設定して適用することもできる。

CAMEOシステム・モデラー（Cameo System Modeler）のようなデジタル・エンジニアリング・ツールにおける、命名規則、ダイアグラムのフォーマット、標準化された色、凡例に関するより詳細なガイダンスについては、本ミッション・アーキテクチャ・スタイル・ガイド（MASG）第1版の付録9.1を参照のこと。

5.3.          ミッション・エンジニアリング・スレッドの開発

ミッション・エンジニアリング・スレッド（MET）は、ミッション・スレッド（MT）の実装固有バージョンである。ミッション・エンジニアリング・スレッド（MET）を開発するには、前のプロセス・ステップから各ミッション・スレッド（MT）を取り出し、それを実行する各システム、組織、またはアクターを割り当てる。そのための公称プロセスは次のとおりである。

1. ミッション・スレッド（MT）の各活動（タスク）を実行するミッション要素（システムまたはアクター）を特定する。
2. 活動を実行するミッション要素ごとにスイムレーンを作成する。
3. それを実行するシステムのスイムレーンに活動を移動する。統合共通システム機能リスト（JCSFL）（統合参謀/J6/AIDによって維持）、作戦的普遍的統合タスク・リスト（UJTL）、およびミッション・エンジニアリング・スレッド（MET）の活動のための参照点として戦術的普遍的統合タスク・リスト（UJTL）を見直し、彼らはシステム機能を定義するための標準的な語彙が含まれている。これらのリソースは、ミッション・エンジニアリング・スレッド（MET）の意図が完了されている活動のための詳細を提供するために明確であることを確認するために調整されるべきである出発点である。
4. スイムレーンの境界を横断するフローに注目することで、ミッション要素間に必要なインターフェースを特定。

ミッション・エンジニアリング・スレッド（MET）を開発する場合、上記のプロセスは逐次的なものではなく、ミッション・スレッド（MT）、戦闘序列（OB）、ミッション・エンジニアリング・スレッド（MET）の間で行ったり来たりを繰り返す必要がある。

ベースラインのミッション・エンジニアリング・スレッド（MET）の例:「砂漠の嵐作戦」でのタスク部隊ノルマンディの敵防空（SEAD）ミッション 以下のベースラインミッション・エンジニアリング・スレッド（MET）（図17）は、米国が対象地域のイラク早期警戒レーダー・サイトにどのように対抗するつもりかを描いている。MTからの活動は、ベースラインで特定されたミッション要素に割り当てられていることに注意。戦闘序列（OB）からは、AH-64が採用する3種類の兵器がある： AGM-114ヘルファイアミサイル、30mmキャノン砲射撃、Hydra-70ロケットである。ミッション・エンジニアリング・スレッド（MET）では、これらは抽象化され、「兵器（Weapons）」という一つのスイムレーンで表現される。最初の交戦が成功しなかった場合、AH-64はターゲットに再交戦し、ターゲットが破壊されるまでプロセスを経る。 図17. 「砂漠の嵐作戦」のタスク部隊ノルマンディの敵防空（SEAD）ミッションのベースラインのミッション・エンジニアリング・スレッド（UAFリソース・プロセス・フロー）

ベースラインのすべてのミッション・スレッド（MT）についてこのプロセスを繰り返す。代替ミッション・エンジニアリング・スレッド（MET）も同様のプロセスを踏むが、ベースライン・アーキテクチャ全体が完成した後に構築される。代替ミッション・エンジニアリング・スレッド（MET）は通常、完全に新しいスレッドではなく、ベースラインミッション・エンジニアリング・スレッド（MET）の変形である。

代替のミッション・エンジニアリング・スレッド（MET）の例:「砂漠の嵐作戦」でのタスク部隊ノルマンディの敵防空（SEAD）ミッション 以下の代替ミッション・エンジニアリング・スレッド（MET）（図18）は、通信中継を行うためにMC-130のコンセプトをベースラインミッション・エンジニアリング・スレッド（MET）に挿入したものである。 図18. 「砂漠の嵐作戦」のタスク部隊ノルマンディの敵防空（SEAD）ミッションの代替のミッション・エンジニアリング・スレッド（UAFリソース・プロセス・フロー）

機能とタスクのマッピングは、どのミッション・エンジニアリング・スレッド（MET）機能がミッション・スレッド（MT）の作戦活動を実施するかを示すために行うことができる。このマッピングは、完全に実施されたバトルプランを保証するために不可欠である。ミッション・スレッド（MT）のすべてのステップをミッション・エンジニアリング・スレッド（MET）の活動にマッピングすることで、戦闘計画がドクトリンや普遍的統合タスク・リスト（UJTL）のタスクで定義されていることに従っていることを確認することができる。シナリオの条件によって、ミッション・スレッド（MT）とミッション・エンジニアリング・スレッド（MET）の測定基準は変化する。異なるミッション要素は、異なる方法でミッション・スレッド（MT）タスクを達成するかもしれない。状況によって、ミッション・エンジニアリング・スレッド（MET）のバリエーションがいくつ存在するかが決まる。

ミッション・エンジニアリング・スレッド（MET）からミッション・スレッド（MT）へのマッピングの例：タスク部隊ノルマンディの敵防空（SEAD）ミッション リソース機能と作戦活動マップ（図19）は、敵防空（SEAD）のミッション・スレッド（MT）活動とミッション・エンジニアリング・スレッド（MET）機能の関係を示している。各ミッション・エンジニアリング・スレッド（MET）機能はミッション・スレッド（MT）タスクを実行する。 図19. ミッション・エンジニアリング・スレッド（MET）機能とミッション・スレッド（MT）タスクのマッピング（UAFリソース・プロセス） このマッピングは、デジタル・エンジニアリング・ツールで作成したマトリックスビューに表示することもできる。これにより、同じ情報を別の視点から見ることができる（図20）。 図 20. ミッション・エンジニアリング・スレッド（MET）機能からミッション・スレッド（MT）タスクへのマトリックス

ミッション・エンジニアリング・スレッド（MET）開発における重要なポイント：

戦闘序列（OB）に示されたミッション要素とミッション・スレッド（MT）の活動（タスク）を組み合わせることで、ミッション・エンジニアリング・スレッド（MET）は関係する活動とミッション要素のソリューション固有のビューを提供する。ミッション・エンジニアリング・スレッド（MET）を作成するには、対応するミッション・スレッド（MT）から始める。ミッション・スレッド（MT）の活動ダイアグラムと関連するすべての活動は、ミッション・エンジニアリング・スレッド（MET）を作成する際の重要な参考資料となる。ミッション・スレッド（MT）の他の実装のような既存のアーキテクチャの作業は、最初の出発点としては良い資料であるが、現在のアプリケーションのためにリーダーシップをとって検証する必要がある。

ミッション・エンジニアリング・スレッド（MET）を開発する主な利点は、情報収集プロセスを推進することである。ソースプランでは考慮されなかったギャップ、冗長性、異常な活動が特定されるかもしれない。ミッション・エンジニアリング・スレッド（MET）の活動とフローは、関連するミッション・スレッド（MT）のフローを基礎として使用しながら、現実の実施ニーズを考慮している。ミッション・エンジニアリング・スレッド（MET）の特定の部分は、他の部分よりも関連性が高い。重要な領域については、必要に応じて、より低い詳細レベルまでドリルダウンする。アーキテクチャに描かなければならない詳細レベルは、表現するシナリオ、作戦、ヴィネット、及びミッションと、それを支えるドクトリンに依存する。特定のシナリオにおけるミッションの遂行には、エフェクト・ウェブ（effects webs）やキル・ウェブ（kill webs）として、複数のミッション・スレッド（MT）やミッション・エンジニアリング・スレッド（MET）の統合が含まれることがある。

ヴィネットやミッションに基づき、ミッション・スレッド（MT）ごとに1つから多数のミッション・エンジニアリング・スレッド（MET）を作成することができる。ミッション・エンジニアリング・スレッド（MET）に割り当てられるミッション要素は条件によって異なる。ミッション・エンジニアリング・スレッド（MET）のバリエーションがいくつ存在するかは条件によって決まる。青部隊（blue forces）のミッション・エンジニアリング・スレッド（MET）は、ベースライン、エクスカーション、または代替案を表すために作成される。緑部隊のミッションは、米国と直接協力する場合には青（blue）のミッション・エンジニアリング・スレッド（MET）内で表現することができるが、情報が入手可能な場合には個別に表現することもできる。赤部隊（Red force）のミッション・エンジニアリング・スレッド（MET）は通常、情報機関から提供された情報に基づいている。

ミッション・エンジニアリング・スレッド（MET）で提供される詳細のレベルは、目的文に合わせて調整する必要がある。アーキテクトは、調査事項の中心ではない活動や事象に関して、いくつかの前提をたてることがある。これらの前提は、コメントや付随するモデル文書によって、アーキテクチャ内で明示的に文書化されなければならない。ミッション・スレッド（MT）と同様、アーキテクトは利害関係者や主題専門家（SME）とともにミッション・エンジニアリング・スレッド（MET）を検証すべきである[17]。

複雑なシナリオの場合、すべてを説明するような複雑なダイアグラムは使わないこと。これでは、主題専門家（SME）がレビューするのが難しくなる。必要に応じてダイアグラムを分解し、入れ子にする。後続の分析で考慮する必要のある、公称フローからの重要な逸脱のロジックを含める。結合ノード、マージノード、および決定ノードを使用して、同時に発生する活動や、プロセス内の代替案を表すことができる。

ミッション・エンジニアリング・スレッド（MET）開発の到達目標のひとつは、システム間の具体的なインターフェースと、システム間を流れるものを特定することである。特定された各システムまたはアクターについて、関連するサブシステム、能力、主要なパフォーマンス特性を適切に特定するために、権威ある情報源を収集する。

5.3.1.       デジタル・エンジニアリング・ツールにおけるUAFリソース・プロセス・フローを使用したミッション・エンジニアリング・スレッド（MET）

UAFMLでミッション・エンジニアリング・スレッド（MET）を作成するには、リソース・プロセス・ダイアグラムを利用する。図16は、CAMEOシステム・モデラー（Cameo System Modeler）の「リソース・プロセス・フロー」ビューを使って作成したミッション・エンジニアリング・スレッド（MET）である。SysMLでは、アクティビティ・ダイアグラムを利用する。ブロックを使用してシステム/ミッション要素を定義する。

・リソース・プロセス・フロー・ダイアグラムを作成する。

・  多次元スイムレーン（Multidimensional Swimlanes）： 大きなプロセスを縦列のフェーズやステージ、横列のスイムレーンのミッション要素で視覚的に分割するために利用される。

– 垂直スイムレーン（Vertical Swimlanes）： 選択されたドクトリンに基づくスレッド（例：F2T2EA、Exploitation-Installation-Command and Control （C2）-Action on Objective）を垂直スイムレーンのラベルとして表現する。

– 水平スイムレーン（Horizontal Swimlanes）： 活動をミッション要素（リソース、システム、アクター）に割り当てるには、水平スイムレーンを使用する。スイムレーンは、戦闘序列（Order of Battle）に示されているミッション要素（リソース成果物／システム（Resource Artifact/System））のリストから引き出されたミッション要素を表している。

・  初期ノード（Initial Node）： モデルの初期項目を表し、ミッション・エンジニアリング・スレッド（MET）の開始条件がラベル付けされている。ミッション・スレッド（MT）とミッション・エンジニアリング・スレッド（MET）の開始条件はシナリオとミッションに依存する。

・  機能アクション（Function Action）： フロー内の活動を表し、ダイアグラム内のすべての呼び出し動作が定義された活動を参照するようにする。この機能アクションは、モデル内の接続や割り当てを示すために、さまざまなビューで再利用することができる。

・  機能オブジェクト・フロー（Function Object Flow）：情報が流れる機能間の接続。ミッション・エンジニアリング・スレッド（MET）レベルでは、オブジェクト・フローはミッション・スレッド（MT）よりも頻繁に使用される。ミッション・エンジニアリング・スレッド（MET）開発の到達目標の一つは、特定のインターフェースとその間を流れるものを特定することである。

・  出力ピン（Output Pin）：各活動には「タイプ」が割り当てられた出力ピンが必要である。これらのピンは、ミッション・エンジニアリング・スレッド（MET）内の活動間で転送されるオブジェクト・フロー（キー情報、リソースなど）を示すために使用される。各出力ピンの「タイプ」を示す必要がある。

– 各ピンにはタイプが割り当てられる。タイプはリソース情報として作成され、活動間を流れる情報（名詞や名詞状態のペアなど）でラベル付けされる。モジュール化により、共通のリソース情報のライブラリが用意され、タイプとして割り当てることができるようになる。

・  入力ピン（Input Pin）： 入力ピン：出力ピンと同様に、入力ピンもミッション・エンジニアリング・スレッド（MET）内の活動間のオブジェクト・フローを示す。入力ピンの「タイプ（Type）」と「名前（Name）」は、乱雑にならないように隠す必要がある。各出力ピンは、一致する入力ピンで終端しなければならない。入力ピンは、前の出力ピンと同じタイプでなければならない。

・  活動パラメータ・ノードまたは活動ファイナル・ノード： ミッション・エンジニアリング・スレッド（MET）フローの終わりを表す。

・  すべてのダイアグラムに「凡例（Legend）」を使用し、ミッション要素または活動／機能の所有国を視覚的に示す。

CAMEOシステム・モデラー（Cameo System Modeler）のようなデジタル・エンジニアリング・ツールにおける、命名規則、ダイアグラムのフォーマット、標準化された色、凡例に関するより詳細なガイダンスについては、本ミッション・アーキテクチャ・スタイル・ガイド（MASG）第1版の付録9.1を参照のこと。

5.4.          ミッション・エンジニアリング・スレッドのエンド・ツー・エンド・ビューの開発

ミッション・エンジニアリング・スレッドのエンド・ツー・エンド（E2E）ビューは、ミッション要素間の接続と情報交換を示す。エンド・ツー・エンド（E2E）ビュー（UAFリソース内部接続性）は、ミッション・エンジニアリング・スレッド（MET）に描かれた選択された雇用の中に存在する潜在的なギャップや脆弱性を特定するために使用することができる。例えば、通信アーキテクチャを開発する場合、技術文書や主題に関する協議が必要になることが多い。このようなタイプのギャップを特定することは、モデリング・プロセスと実際のミッション採用プロセスの両方に関連する。アーキテクチャ開発のこの側面には、ミッション・エンジニアリング・スレッド（MET）を解消することが不可能であることを研究の後半で発見するのではなく、低忠実度のファースト・パス・アセスメントを通じてミッション・エンジニアリング研究の早い段階で情報収集を推進できるという利点がある。

エンド・ツー・エンド（E2E）開発における重要なポイント：

青と緑のミッション要素を左に、すべての赤のミッション要素を右に並べて目標を示す。赤部隊（Red force）モデルを描くときは、このガイダンスを逆にする。この流れは、読者の自然な左から右への読み方に合わせる。左から右へ、ミッション要素をその機能を果たす順番に大まかに並べる。一般的には、センサから指揮統制、兵器プラットフォーム、兵器/弾薬の順に並べる。

ミッション要素をミッションまたは機能別にグループ化する。グループの例： 作戦センター、通信中継、戦闘管理指揮統制（BMC2）、阻止、攻撃的対空、対地戦、宇宙ベースのISRなど。

ミッション・エンジニアリング・スレッドのエンド・ツー・エンド（E2E）ビューのアーキテクト・ビューの例：「砂漠の嵐作戦」タスク部隊ノルマンディ 図 21は、「砂漠の嵐作戦」（Task Force Normandy）のアーキテクトのエンド・ツー・エンド（E2E）ビューを示している。これは、データを交換するミッション要素が、通信に適切なポート・タイプ／メカニズム（Link-16、ファイバー、UHF無線など）を備えていることを確認するために、アーキテクチャ・チームが使用する作業ビューである。この「作業」ビューは、モデラーを支援するために使用されるものであり、モデリング環境の外部でダイアグラムを表示することを意図したものではない。 図21. 「砂漠の嵐作戦」タスク部隊ノルマンディのエンド・ツー・エンド（E2E）ビューのワーキング・ビュー

エンド・ツー・エンド（E2E）ビューは、主に国防次官室：研究・エンジニアリング担当（OUSD（R&E））のリーダーシップと利害関係者に提示する際に使用されるビューである。一貫したプレゼンテーション形式を提供するため、エンド・ツー・エンド（E2E）ビューではミッション要素の画像を表示し、ミッションまたは機能別にグループ化する。

ミッション・エンジニアリング・スレッドのエンド・ツー・エンド（E2E）ビューのアーキテクト・ビューの例：「砂漠の嵐作戦」タスク部隊ノルマンディ 図 22はタスクフォース・ノルマンディのエンド・ツー・エンド（E2E）ビューである。この論理的なビューは、ミッション・エンジニアリング・スレッド（MET）に関係するすべてのミッション要素と、それらの間の情報の流れを最上位レベルで示している。ミッション要素はミッションまたは機能ごとにグループ化されている。例えば、MH-53とAH-64はヘリコプターであるが、このヴィネットとミッション・エンジニアリング・スレッド（MET）の文脈では、そのミッションは打撃である。 図 22. 「砂漠の嵐作戦」タスク部隊ノルマンディのエンド・ツー・エンド（E2E）ビュー このミッションでは、E-3が必要不可欠なC2中継ノードであり、その不在が潜在的なギャップ、すなわち必要な通信中継の単一障害点を示していると仮定する。この例は、コンセプトを実証するために、過去のデータから独創的に発散させたものである。これらの見解は、ミッションの長所と短所を明らかにするものである。

5.4.1.       デジタル・エンジニアリング・ツールにおけるUAFリソース内部接続を利用したエンド・ツー・エンド（E2E）ビュー

UAFMLでエンド・ツー・エンド（E2E）を開発するには、リソース接続ダイアグラムを利用する。カメオ・システム・モデラーには、図 21の例を作成する際に使用した「リソース内部接続性」という視点がある。SysMLでは、ブロック定義ダイアグラムを利用する。戦闘序列（OB）で定義されたSysMLブロックを使用して、各システム・オブ・システムズ（SoS）アーキテクチャを定義する。各システム・オブ・システムズ（SoS）アーキテクチャの内部ブロックダイアグラム（IBD）を定義する。インターフェース・ブロックで型付けされたプロキシ・ポートを使用してインターフェースを定義する。

・  リソース内部接続（Resources Internal Connectivity）ダイアグラムを作成する。

・  システム/リソースの役割（System/Resource Role）： ミッション・エンジニアリング・スレッド（MET）におけるミッション要素を表す。ミッション要素は「Resource Role」を用いて表現され、戦闘序列（OB）とミッション・エンジニアリング・スレッド（MET）で使用されるミッション要素と一致する必要がある。エレメントはステレオタイプのラベルとアイコンを非表示にする。

・  リソース・アーキテクチャ（Resource Architecture）： エンド・ツー・エンド（E2E）ビューの場合、リソース・アーキテクチャを使用して、能力または機能を集団的に実行するミッション要素（システム）をグループ化することができる。リソース・アーキテクチャはアーキテクチャのモデルを示し、システムまたは能力構成で構築することができる。

・  リソース・ポート（Resource Port:）: ミッション要素間の接続を作成するために、各リソース・ロールはタイプに割り当てられたリソース・ポートを持つ必要がある。

・  ポートは、使用される伝送媒体（例えば、SATCOM、ファイバー、Link-16、UHF無線、VHF無線など）を示すリソース・インターフェース（Resource Interface）によってタイプされる。ミッション要素に複数の伝送メカニズムがある場合は、それぞれに新しいポートを作成する必要がある。

– また、各リソース・ポートには、情報伝送メカニズムの種類（例えば、音声、データリンク）を表す一般的なカテゴリーを表す「名前（Name）」を割り当てるべきである。ポート名は、ダイアグラムが完成すると、表示が煩雑になるため表示されないが、ダイアグラムを作成する際には便利である。

・  このガイドで示すアーキテクチャでは、武器プラットフォームと武器の間のポートには、名前として「指揮（Command）」、タイプとして「射撃統制（Fire Control）」が割り当てられている。青／緑のミッション要素（武器）と赤のミッション要素（ターゲット）の間のポートには、名前として「誘導（Guidance）」、タイプとして「Gravity」または「Heat Signature」が割り当てられる。

– 機能間のフローがミッション・エンジニアリング・スレッド（MET）のミッション要素の水平スイムレーンを横切るシステム/アクター（リソース・ポート）間のエンド・ツー・エンド（E2E）にリソース・コネクションを作成し、2つのシステム/アクター間のインターフェースを示す。

– エンド・ツー・エンド（E2E）ダイアグラムでコネクションを作成する場合、コネクションはミッション要素間レベルのみで作成すること。ミッション要素は抽象化されたミッション要素グループに分類されるが、これは主に可視化の目的がある。

・  ノード間の関係を示すには、ノード間にコネクションを描く。リソース交換を作成し、リソース情報で入力された伝達項目を追加する。

– ミッション要素間に双方向のつながりがある場合、ミッション要素間に新たな線を引かないこと。

– ミッション要素・グループのシステム内とシステム間の両方において、伝達される情報の名称を方向矢印（realized Resource Exchanges）とともに表示する。

– 青、緑、赤のミッション要素を含むすべてのミッション要素に、ポートまたはリソース・エクスチェンジが存在すべきである。

– ミッション要素または活動／機能のいずれかの所有国を視覚的に示すため、すべてのダイアグラムに「凡例（Legend）」を使用すべきである。

・  アーキテクチャを読む際の助けとなるよう、各ミッション要素の画像または一般的な画像を使用して、各ミッション要素を構成するものを容易に識別できるようにすることができる。画像は仕様ウィンドウに追加できる。これらをモデルに表示するには、「Shape Properties」で「Show Stereotype」のオプションとして「Shape Image」を選択する。

CAMEOシステム・モデラー（Cameo System Modeler）のようなデジタル・エンジニアリング・ツールにおける、命名規則、ダイアグラムのフォーマット、標準化された色、凡例に関するより詳細なガイダンスについては、本ミッション・アーキテクチャ・スタイル・ガイド（MASG）第1.0版の付録 9.1を参照のこと。

6.     ミッション・エンジニアリング分析

ミッション・エンジニアリング・アーキテクチャとミッション・エンジニアリング分析の間には双方向の関係がある。ミッション・エンジニアリング分析の中核的な機能は、特定のシナリオに基づくミッションの文脈の中でミッション・アーキテクチャを評価することである。原則として、研究実験デザインで考慮される主要なバリアントごとに1つのアーキテクチャを定義することができる。

アーキテクチャの目的は、各シナリオで何を分析するかを正確に定義し、すべての利害関係者の合意を確保することである。このミッション・エンジニアリング分析の段階で発見された事項により、研究デザインが変更され、ミッション・エンジニアリング・アーキテクチャを更新する必要が生じることがある。また、主要な前提や分析に対応するための変更点を示すアーキテクチャの特殊版を作成することも有用である。見解からの逸脱は、その根拠とともに示すべきである。

ミッション・エンジニアリング・アーキテクチャは、構成的モデリングとシミュレーションのための記述的モデリング基盤である。ミッション・エンジニアリング分析は、1つまたは複数のシミュレーション・ツール、実験、またはモンテカルロシミュレーションやノード分析のような他の分析手法によって実行される。ほとんどの分析技法は、シミュレーションであろうとなかろうと、モデルがそれ自身の方法論的前提に適合することを要求することに注意すること。

ミッション・エンジニアリング・プロセスにおけるミッション・アーキテクチャの検証と妥当性確認（V&V）には、二つの側面がある。すなわち、ミッション情報の検証と妥当性確認（V&V）とモデル・ベース・システム・エンジニアリング（MBSE）モデル要素の検証と妥当性確認（V&V）である。モデルの検証は、一貫性を確保し、モデル要素のリンク切れを回避するために、モデルの開発全体を通じて最も重要である。ほとんどのモデリング・ツールにはこの機能が組み込まれており、モデル開発中にモデラーを支援するために使用されるべきである。

モデル・プロファイルは、モデル検証プロセスを強化するために開発することもできる。不確実性の定量化は、記述的アーキテクチャと、ユーザーが最適化の実行を可能にする数学的分析ソルバーとをリンクさせるために組み込むことができる。これにより、確率的不確実性の統合が促進され、規範的な意思決定が可能になる。具体的な分析手法については、さらなる検討が進められている。

ミッション・エンジニアリング分析と様々な計算およびシミュレーション・ツールに関する追加情報については、ミッション・エンジニアリング・ガイド第2版（MEG 2.0）の第6節を参照されたい。

6.1.           試験と評価の支援

統合即応性（Joint Readiness）の優位性と包括性を確保することは、従来の試験・評価（T&E）能力をこれまで以上に伸ばすことになる。システム・ライフ・サイクルを通じて、試験対象システムがどのような作戦上の文脈とミッションの文脈の中で性能を発揮することが期待されるかが、重視されるようになっている。複雑なミッション・ウェブと統合システム・オブ・システムズ（SoS）と一直線に並んだシステム性能と、どのように試験・評価（T&E）が施策と成果の全体的な評価に貢献するかについて考える方法を転換することが最も重要である。試験・評価（T&E）は、意思決定支援ツールによって強化されたミッション・アーキテクチャを使用することができ、実地試験と仮想構築環境によって支援され、物質的および非物質的ソリューションの性能、相互運用性、軍種および統合ミッション遂行への影響を評価することができる。

試験・評価（T&E）を支援するためにミッション・スレッド（MT）とミッション・エンジニアリング・スレッド（MET）を使用するというこの強調は、ユーザー、オペレーター、取得者、試験担当者、および維持者を、望ましいミッションと能力の結果に一致させる。ミッション・アーキテクティングとエンジニアリングは本来学際的なものであり、ミッション・スレッド（MT）が作戦、取得、およびエンジニアリングの要員を集結させるための連携を生み出すことは付加価値である。

ミッション・アーキテクチャは、インターフェースのテスト、テストシナリオの視覚化、および「テスト対象システム・スレッド」をより大きなミッション・エンジニアリング・スレッドに上流からマッピングすることを可能にし、テスト対象システムがより大きな統合ミッション、全のドメインの文脈においてどのように使用されるかを実証する。この方法論は、ユーザー・オペレーターが正しいシステムが構築されたことを確認すると同時に、現実的な統合ミッションの設定においてシステムが正しく構築されたことを確認するエンジニアによる性能測定値の検証を可能にする検証を促進する。実試験イベントや現実世界の作戦に沿った試験・評価（T&E）指標やモデルは、システム性能とミッション・エンジニアリング・モデルの両方へのインプットとなる。

モデル・ベース・システム・エンジニアリング（MBSE）は、統合および全ドメインにおけるシステム性能、相互運用性、ミッション遂行への影響の理解を深める。モデル・ベース・システム・エンジニアリング（MBSE）は、要件、対策、テストセンター、およびテストを完了するために必要なその他の重要な要素へのトレーサビリティ、リンク、および情報ストレージを作成するための重要なツールである。モデル・ベース・システム・エンジニアリング（MBSE）が可能にするミッション・エンジニアリング（ME）を活用することで、システムのライフ・サイクル全体をデジタル環境でモデル化することができ、各構成部隊がどのように相互作用し、ミッション全体の成功に寄与するかを理解することができる。

モデル・ベース・システム・エンジニアリング（MBSE）の主な利点の1つは、システムとその要求を視覚的に表現できることである。これは、利害関係者間のコミュニケーションを助けるだけでなく、システムのある側面への変更が他の側面にどのような影響を与えるかをより明確に理解することを可能にする。機能要件、性能要件、およびシステム技術要件をモデルに直接リンクすることで、開発およびテストプロセス全体を通じてトレーサビリティが維持され、必要なすべての基準が満たされることが保証される。

テストと評価は、検証と妥当性確認の両方を考慮する。検証については、作戦上の要員や試験要員は、性能の尺度（MOP）を用いて模擬された作戦環境においてシステムがどのように機能するかを調べることができる。検証に関しては、システム利用者は、効果の尺度（MOE）をトレースすることにより、システムの有用性を検証することができる。モデルで採用されている尺度と測定のセット（Measures and Measurement Sets）は、実験と試験の両方の取り組みに有益な定量的属性を提供する。

機能的接続性から手段への例：タスク部隊ノルマンディの敵防空（SEAD）ミッション 図 23は、AH-64とMH-53Jのトレーサビリティと敵防空制圧（SEAD）のミッション・エンジニアリング・スレッド（MET）における機能の想定例を示している。この例では、AH-64とMH-53Jの性能は、航空機の性能の尺度（MOP）（致死性、生存性、回復率、展開までの時間）に対して評価される。 図23. 性能の尺度（MOP）へのミッション・エンジニアリング・スレッド（MET）機能の接続例（UAF Resources Parametric）

7.     結果と推奨事項

完成したミッション・アーキテクチャは、国防総省（DoD）内の適切な安全保障構造の中で、承認されたさまざまな方法で利用できるようにすべきである。これには、ナレッジ・マネジメントのウェブページや統合ドクトリン出版物の補遺といった方法が含まれる。アーキテクトがミッション・アーキテクチャを把握するために使用するダイアグラムは、利害関係者に提示するには詳細すぎることが多い。プレゼンテーションのためには、焦点を絞った注釈付きのアーキテクチャ・ビューを作成する必要がある。

プレゼンテーション・ビューでは、アーキテクチャの低レベルの技術的な詳細を非表示にすることをお勧めする。ダイアグラム上の要素と関係の表現を削除しても、それらはモデルから削除されない。つまり、ビューを簡素化するためにダイアグラムから削除された文脈は、まだモデルに取り込まれたままであり、モデル内の他のダイアグラムにアクセスして表現することができる。この機能は、静的なアーキテクチャ・ビューのセットではなく、動的なモデルを使用する主な利点の1つを浮き彫りにする。ビューは、モデルに格納された情報から必要に応じて作成することができる。

7.1.           リーダーシップへのミッション・エンジニアリング・アーキテクチャのプレゼンテーション

リーダーシップにプレゼンする場合、プレゼンされるアーキテクチャを完全に理解するために、すべての開始の前提と依存関係を文書化することが重要である。ベスト・プラクティスは、前提条件と開始条件をモデル自体に取り込むことであるが、簡単にアクセスできるようにスライドやテキスト形式で情報を提示することも重要である。スタディ文書は、各スタディの最後に提出され、開始条件、前提、依存関係、アーキテクチャ、およびその他の関連項目に関連する詳細な情報が含まれる。

アーキテクチャを提示する適切な方法は、ミッションの問題と利害関係者が見る必要のある情報によって異なる。国防次官室：研究・エンジニアリング担当（OUSD（R&E））のミッション統合組織が、リーダーシップに提示する際に効果的であると判断した主なビューは、エンド・ツー・エンド（E2E）ビューと呼ばれるものである。エンド・ツー・エンド（E2E）ビューは、UAFMLリソース内部接続アーキテクチャであり、ミッション・アーキテクチャ内の対象システムと、それらがミッション遂行のためにどのように論理的に情報を共有しているかを表示する。このエンド・ツー・エンド（E2E）ビューは、関係者へのプレゼンテーションのために、システム・オブ・システムズ（SoS）アーキテクチャの主要部分を強調するように整理され、注釈が付けられる。図24は、エンド・ツー・エンド（E2E）ビューの表示方法の例を示している。

利害関係者にアーキテクチャを提示する際の主な考慮事項

システムは、ミッション・エンジニアリング・スレッド（MET）の実行中に使用される順序に沿うように、左から右へと整理される。ミッション・エンジニアリング・スレッド（MET）のトップレベルのステップ（例えば、キル・チェーン（kill chain）／効果のチェーン（effects chain））は、ダイアグラムの上部に沿って明示的にラベル付けすることができる。これは、アーキテクト以外の人にとって、高レベルのステップを多数の低レベルの活動に分解して割り当てるスイムレーン・ダイアグラムよりも、はるかに解釈しやすいことがよくある。

エンド・ツー・エンド（E2E）ビューは、PowerPointスライドのような他のプレゼンテーション・フォーマットに配置すると、表示や読み取りが困難になることがよくある。そのような場合は、図24に示すように、ダイアグラムの主要な特徴にテキストとアウトラインをオーバーレイして注釈を付けることが望ましい。場合によっては、同じシステムを複数の活動に使用することができる。この場合、ダイアグラムの内容と文脈に過度の負荷をかけないことが重要である。できるだけ曖昧さを排除して、エンド・ツー・エンド（E2E）ビューを表現することを目指す。

このシステムが実行する最初の活動または最も重要な活動を選択するか、アーキテクチャの重要な要素を強調する別のプレゼンテーション・ビューを作成する。

主要なインターフェースが存在することを確認する。利害関係者はミッション・エンジニアリング・スレッド（MET）がどのようにクローズされるかをある程度理解したいと思うだろう。しかし、表示されるインターフェースの数が多くて見づらい場合は、一部を非表示にして、関連するインターフェースを強調表示した方がよいかもしれない。これは、ミッション・スレッド（MT）を閉じる可能性のある通信経路が多数ある場合に起こり得る。

提示されたビューに通信アーキテクチャ全体を含めることは推奨されないが、理解のために重要な通信スタックの低レイヤーのターゲット部分を描くことは有用であろう。エンド・ツー・エンド（E2E）ビューは完全なモデルから派生したものであるため、カスタマイズされたビューでこれを実現するのは容易であり、かつ技術的に正しいはずである。

・　システム内の主要部分を戦略的に表示する。キーパーツは、目下のミッションの問題によって異なる。各システムのすべての部品を表示しないこと。無関係な情報で表示が乱雑になる。例えば、ISRプラットフォームで使用されるセンサが研究にとって重要である場合、プラットフォーム上のセンサを表示するが、エンド・ツー・エンド（E2E）ビューでは他の部分を隠す。

重要なミッション要素については、プレゼンテーション・ソフト（PowerPointなど）の描画ツールを使用してボックスやラベルを付け、ミッション要素を強調するとともに、読みやすくすることができる。アーキテクチャを提示する際の一貫性を保つため、PowerPointでは次のガイドラインを使用する。

・　塗りつぶしなしの矩形を作成し、輪郭を紺色（RGB（47 82 143））、線の太さを3ポイントとする。

・　提示されるメッセージに基づき、エンド・ツー・エンド（E2E）ビューを線でオーバーレイし、ベースライン・ビューと代替ビューのナラティブを見せやすくする。

・　複数のミッション要素・グループによって実施されるアセスやその他のステップについては、それぞれに緑の円（RGB（146 208 80）、縦横0.2インチ、1ポイントに黒の輪郭）を追加する。

・　図24に示すように、ボックスの色と矢印の凡例を追加する。

アーキテクチャの読みやすい説明と、ビューに表示されるトップレベルのミッション・エンジニアリング・スレッド（MET）実行を含める。この情報もアーキテクチャ・モデル内のより低い詳細レベルで格納されるべきですが、プレゼンテーションソフトウェアを使用して要約し、非アーキテクトがより読みやすく解釈できるようにすることは有用である。

図24. ベースライン・アーキテクチャのエンド・ツー・エンド（E2E）ビューのプレゼンテーション例

一般的に、1つのエンド・ツー・エンド（E2E）ビューは、研究実験デザインの主要なケース（ベースライン、代替案/コンセプト1、代替案/コンセプト2など）ごとに作成される。図25に示すように、ベースラインに対する各オルタナティブビューの違いを色分けして強調すると便利である。

図25.代替アーキテクチャのエンド・ツー・エンド（E2E）ビュープレゼンテーション例

ベースラインと代替ケースの間で、エンド・ツー・エンド（E2E）アーキテクチャに複数の調整がある場合、オーディエンスがその変更を迅速に理解することは難しい。スライド間を行ったり来たりするのを避けるため、ベースラインと代替アーキテクチャの比較ビュー（図26参照）を横に並べて作成するのも有効である。

図26. ベースラインと代替案アーキテクチャのエンド・ツー・エンド（E2E）比較のプレゼンテーション例

8.     まとめ

本ガイドでは、ミッション・エンジニアリング方法論で定義されたミッション・エンジニアリングの実行において、アーキテクチャ・モデリングがどのように使用されるかを簡単に説明した。本ガイドでは、ミッション・アーキテクチャが方法論のすべてのステップを横断し、ミッション・エンジニアリング研究またはイニシアティブで取り上げられる基本計画および代替案の正確な記述を提供する方法について記述している。

これらのビューを作成するために、PowerPoint、Visio、その他のダイアグラム・ツールではなく、モデルを利用することは、ミッション・スレッド（MT）、ミッション・エンジニアリング・スレッド（MET）、および大規模なミッション・アーキテクチャを、照会可能かつ標準化された方法で作成し、伝達するための、より効率的かつ効果的な方法である。モデルにより、ミッション・アーキテクチャを一元化された権威ある情報源に収集し、デジタルで表現することができる。

モデルは再利用と努力の統一を促進するためにモジュール化することができる。本ガイドブックは、MEGのように、その後のバージョンリリースで反復されることが期待される、生きた文書であることを意図している。そして最後に、上級指導者に提示されるミッション・エンジニアリング・プロセスの結果の主要な成果物である、望ましいエンド・ツー・エンド（E2E）ビューの表現のレイアウトを提供する。

9.     付録

9.1.           デジタル・エンジニアリング・ツールにおけるアーキテクチャ・ビューの規約

以下は、国防総省（DoD）のアーキテクチャの一貫性を維持するための一連のベスト・プラクティスである。アーキテクチャはどのようなデジタル・エンジニアリング・ツールでも作成することができるが、このドキュメントの指示はCAMEOシステム・モデラー（Cameo System Modeler）を使用して作成されている。各組織グループは、ベスト・プラクティスと考え、このミッション・アーキテクチャ・スタイル・ガイド（MASG）第1.0版を含む既存のスタイル・ガイドに準拠しながら、独自のスタイル・ガイドを定義し、文書化することが推奨される。

9.1.1.       ダイアグラム規約

・　ダイアグラムのタイトルは、以下の命名スキーマに従うこと。

– ［ダイアグラムのタイプ］ ［短いヴィネットID］ ［実行者のISO国コード[18]または非国家主体の3文字表現］ ［短い名前 – 20文字未満］ －［ベースラインまたはコンセプト名］

– ダイアグラムのタイプ

>  リソース・構造の対する戦闘序列（OB）／アセット・リスト

>  ミッション・スレッド（MT）/オペレーショナル・プロセス（Op-Pr）フロー用ミッション・スレッド（MT）

>  ミッション・エンジニアリング・スレッド（MET）/リソース・プロセス（Rs-Pr）のフローのミッション・エンジニアリング・スレッド（MET）

＞ エンド・ツー・エンド（E2E）/リソース内部接続用（Rs-Cn）エンド・ツー・エンド（E2E）

– 国コードは、青部隊（blue forces）のアルファベット順、緑字のアルファベット順、赤部隊（Red force）のアルファベット順で記載する。

・　ダイアグラムのタイトル（Diagram Titles）は、上記の特別な場合を除き、ダイアグラムの目的に関する情報を簡潔に示すものでなければならない。経験則では、タイトルは20文字未満にし、UAFMLのダイアグラム・タイプを含めないようにする。

・　ダイアグラムにコメント（Comments）を追加して、読者が理解するために重要な情報を含めることができる。どのダイアグラムにも、読みやすさによって制限されるだけで、いくつでもコメントを付けることができる。コメントを追加するには、ダイアグラム・パレットの「ノート」の下にある「コメント」を選択する。

・　ダイアグラムのフレーム（Diagram Frames）は、ダイアグラムのタイプ（省略せず完全な名称）、タイプアイコン、名称を表示する。パラメータは非表示にする。

・　ダイアグラム情報（Diagram Information）は、すべてのダイアグラムに表示する必要がある。このペインをカスタマイズして、起草者、レビューア、承認者、分類レベル、アーキテクチャの簡単な説明、バージョンなどの情報を含めることができる（図 27参照）。エンジニアリング・ダイアグラムと同様に、国防次官室：研究・エンジニアリング担当（OUSD（R&E））のアーキテクチャでは、ダイアグラムの右下隅がダイアグラム情報ペインの推奨位置である。各組織グループは、ダイアグラム情報ペインの位置の基準を設定し、すべてのビューで一貫性を保つべきである。

承認者	B. Jaime	プロジェクト：「ミッション・アーキテクチャ・スタイル・ガイド」	国防次官室：研究・エンジニアリング担当（OUSD（R&E））	5/30/24, 8:58 PM
受領者	M. Rock	ダイアグラム： 戦闘序列（米軍、イラク、有志連合	秘区分無し	Version 0.1
起案者	K. Dina	「砂漠の嵐作戦」タスク部隊ノルマンディのミッション要素

図27. カスタム・ダイアグラム情報

・　秘密区分（Classification）： セキュリティの秘密区分マーク

– モデル内の各要素とビューに対して、セキュリティの秘密区分マークを付けるべきである。機密情報に適切なマークを付け、識別し、保護する固有の機能を持つモデリング・ツールがないにもかかわらず、すべてのモデルに適切なマークを付ける必要がある。例えば、Dassault Cameo Enterprise Architect 2022x の「Data Marking and Classification」プラグイン（No Magic, Inc.）あるいは、ユーザーはプロファイルを作成したり、他の拡張機能を構築して、モデルを部分的にマーキングしたり、ビューやモデルの大量のモデルデータ更新を完了するような機能に対応することができる。

・　CAMEOでは、特定の要素に情報を追加することもできる。「Specification Window」の「Documentation/Comments」グループでは、オブジェクトに関連する追加情報、関連する軍務（陸軍、海軍、空軍、海兵隊、宇宙軍など）、その他の関連する背景情報を追加することができる。

– コメントはモデル内の要素であり、ノートはダイアグラムの装飾である。コメントを使用すると、ダイアグラムの単一ビューに存在するだけでなく、モデル自体に存在するため、よりシンプルな追跡方法が可能になる。

・　用語集は、略語をスペルアウトして使用すること。

・　各ダイアグラムには、「ドキュメント/コメント」または「ダイアグラム情報」ペインを通じて、以下の情報を含める必要がある。

– ダイアグラムの秘密区分（Diagram Classification） ダイアグラムの分類： 読み取り専用形式で表示されるダイアグラムの秘密区分。

– ミッション（Mission）： 図の中でモデル化されているミッションの名前。

– 目的（Purpose）：ダイアグラムの目的の説明

– ナラティブ（Narrative）： ダイアグラムが示していることを文章で説明すること。

– 著者（Authors）： このダイアグラムの作成に貢献した個人名。このダイアグラムの作成に貢献したモデラーやサブジェクト・マター・エキスパートが含まれるが、これに限定されるものではない。

– 作成日（Date Created）： ダイアグラムが最初に作成された日、月、および年。

– レビューされた日付とPOC（Date Reviewed and POC）： 日、月、年、ダイアグラムをレビューした個人名および／または組織名。ダイアグラムが以前のバージョンで最後にレビューされた場合、このフィールドの値は「Review Required」に設定する必要がある。

– バージョン（Version）： 標準のメジャー/マイナー更新スキーマを使用して、現在のダイアグラムに関連付けられたバージョン。メジャー・アップデートは、ダイアグラムの内容や構成に重要な変更を加えるもので、マイナー・アップデートは、軽微な、あるいは管理的な性質のものを含む（例えば、スペルミスを修正するために要素の名前を変更する）。

– 条件・前提（Conditions/ Assumptions）： ダイアグラムのすべての前提と条件のテキスト記述。

・　ソース（Sources）はモデル内に取り込むべきである。これは、コメント、ソーシング・プロファイル、または各ダイアグラムに付随するソーシング・マトリックスによって行うことができる。ダイアグラムに記載された情報を生成するために使用されたすべてのソースの具体的な名前、場所、日付、および全体的な分類を、モデルで把握する必要がある。アーキテクトは、ダイアグラムのどの部分が各ソースに由来するかを具体的に示し、関連するセキュリティ秘密区分ガイド（SCG）やMIL-STDを参照する。アーキテクチャを作成する際には、MIL-STDおよび該当する場合には国防総省（DoD）の上位ガイダンスに従うこと。

・　各ミッション要素には、「国（Country）」という値のプロパティを追加する。デフォルト値にはISOの3桁の国コードを設定する[19]。これは、［仕様］メニューの［属性］タブで行うことができる。

・　米国の各ミッション要素には、「軍種構成部隊（Service Component）」という名前の値プロパティ（Value Property）を追加すべきである。デフォルト値（Default Value）には、所属する兵科（陸軍、海軍、空軍、海兵隊、宇宙軍など）を設定する。これは、「特定メニュー（Specification Menu）」の「属性（Attribute）」タブで行うことができる。

– デジタル・エンジニアリング・ツールを使用して、米国（USA）のミッション要素と関連する所有権を表すモデルの情報とプロパティを使用して、表を作成することができる（図28）。

図28. ミッション要素、軍種の構成、およびインターフェースの表の例

9.1.2.       ダイアグラムの書式設定

・　テキストを折り返したり、必要に応じて画像のサイズを変更するなどして、空きスペースをできるだけ少なくする。

・　フォント・サイズの提案

– 要素名： Arialフォント、サイズ22

– フロー： Arialフォント、サイズ14

– ポートとピン： Arialフォント、サイズ16

・　フォント、ワード・ラップ、表示名/タイプなど、ダイアグラムの外観に関するプロパティは、要素を右クリックして「シンボルのプロパティ」を選択することで確認できる（図29）。

図29. シンボルのプロパティ例

9.1.3.       凡例

・　凡例（Legend）は、色を使って特定の概念を視覚的にコード化するために使用できる。すべてのダイアグラムに凡例を使用し、ミッション要素または活動／機能の所有国を視覚的に示す。デジタル・エンジニアリング・ツールに基づき、凡例は手動で適用することも、凡例項目の自動割り当てを可能にするパラメータを設定して適用することもできる。

・　アーキテクチャ・モデルでは、青（blue）が米軍、緑（green）が連合国戦闘員、赤（red）が敵対国軍を表す。代替アーキテクチャでは、「コンセプト（concepts）」を表すために金色を用いる。図 30のような凡例は、すべてのアーキテクチャで使用されるべきである。部隊呼称の事業体間の一貫性を保つため、以下のRGBコードを使用する。

– 米国（USA）の青部隊（Blue Force）のミッション要素： RGB（214 255 255）

– 敵対者の赤部隊（Red Force）のミッション要素： RGB（237 124 123）

– 連合国戦闘員／有志連合の緑部隊（Green Force）のミッション要素： RGB（162 255 162）

– 代替／コンセプトは金色のミッション要素： RGB（255 153 0）

・　アーキテクチャのすべての要素は、凡例項目に割り当てられていなければならない。

・　ダイアグラム内で、凡例を適用したい要素の形状を右クリックし、ドロップダウン・メニューから凡例項目（Legend Item）を選択する。

図 30. 凡例の例

9.2.          用語集

信用性（Accreditability）： 機密情報の取り扱い、安全性、その他の重要な要件に対する認定をサポートするために必要な機能を有すること。[Source: Borky and Bradley, Effective Model-Based Systems Engineering, 2019]

適応性（Adaptability）： 一群とその要素が、新たな到達目標を達成するためにその能力を最大限に活用する方法で、新たなタスクや予期せぬ出来事に対応することを可能にする機能によって、構成可能性の考え方を拡張したアーキテクチャの考え方。[Source: Borky and Bradley, Effective Model-Based Systems Engineering, 2019]

代替ミッション・アプローチ（Alternative Mission Approach）： ミッションの遂行方法について、ベースライン・ミッション・アプローチを変更すること。[Source: OUSD（R&E） MEG 2.0]

アーキクチャ（Architecture）： 環境におけるエンティティの基本的なコンセプトまたはプロパティ、およびこのエンティティの実現と進化、および関連するライフ・サイクル・プロセスを管轄する原則。

前提（Assumption）： 肯定的な証拠がない場合、作戦環境の特定の仮定を真実と仮定し、計画を継続するために不可欠なもの。[Source: JP 5-0, Department of Defense Dictionary]

ベースライン・ミッション・アプローチ（Baseline Mission Approach）： ミッション・エンジニアリングの取り組みに対処するためにミッションを実行する方法について合意された開始点。ミッション、シナリオ、エポックによって駆動される。[Source: OUSD（R&E） MEG 2.0]

青部隊（Blue Force）：米国の戦闘員。[Source: OUSD（R&E） MEG 2.0]

能力領域（Capability Area）： 統合能力領域（JCA） – 機能的に能力分析、戦略開発、投資の意思決定、能力ポートフォリオ管理、および能力ベースの戦力開発や作戦計画策定をサポートするためにグループ化された国防総省（DoD）のような能力のコレクション。[Source: JCIDS Manual, DAU Glossary 13^th Edition, DMO Model Developers Guide]

能力構成（Capability Configuration）： 能力を満たすために組み立てられた、事業体内の物理的および人的リソース（およびそれらの相互作用）を表す複合構造。[Source: Enterprise Architecture Guide for UAF v1.2 Specification]

能力ギャップ（Capability Gap）：能力要件を満たすことができない、またはそれを超えることができないため、解決または軽減されるまで関連する作戦上のリスクが発生する。[Source: JCIDS Manual, DAU Glossary 13^th Edition]

能力レベルの要件（Capability Level Requirement）： 特定の製品またはサービスがどうあるべきか、またはどうあるべきかを文書化した唯一のニーズ。[Source: DM2, DMO Model Developers Guide]

能力要件（Capability Requirement）： 現在または将来の作戦において、組織の役割、機能、ミッションを満たすために必要とされる能力。[Source: JCIDS Manual, DAU Glossary 13^th Edition]

能力ソリューション（Capability Solution）： 1つ以上の能力要件を満たし、1つ以上の能力ギャップを削減または解消するための物資的ソリューションまたは非物資的ソリューション。「ソリューション（solution）」とも呼ばれる。[Source: JCIDS Manual, DAU Glossary 13^th Edition]

能力の時間枠（Capability Timeframe）： フェーズまたはフェーズにおける能力の終了/開始のMM/YYYY。[Source: DM2, DMO Model Developers Guide]

能力（Capability）： 指定された条件や性能のレベルの下で、タスクを完了したり、行動方針（course of action）を実行したりする能力。[Source: MEG 2.0, CJCSI 5123.01H, DAU Glossary]；特定の[性能]基準と条件下で、一連の活動を実行するための方法と手段[活動とリソース]の組み合わせによって、望ましい効果を達成する能力。[Source: DM2, DMO Model Developers Guide]

明瞭性（Clarity）： アーキクチャとそのモデルの重要な特性を扱い、理解しやすく適用しやすくするアーキクチャの信条。これはアーキクチャの美的側面の中心をなす。[Source: DM2, DMO Model Developers Guide]

構成可能性（Composability）: 特に垂直的・水平的な統合を促進するインターフェースを通じて、特定のタスクや状況に合わせた能力パッケージを作成するために、下位の要素を迅速に組み立て、統合することを可能にする機能をさまざまなレベルで提供するアーキテクチャ・テント。[Source: Borky and Bradley, Effective Model-Based Systems Engineering, 2019]

作戦コンセプト（Concept of Operations ：CONOPS）： 指揮官が何を達成するつもりで、利用可能なリソースを使ってどのようにそれを行うかを明確かつ簡潔に表現した口頭または図による声明。[Source: JP 5-0, Department of Defense Dictionary]

懸念（Concern）： 懸念とは、システムに対するあらゆる関心を指す。懸念の例：（システムの）目的、機能、構造、動作、コスト、サポート性、安全性、相互運用性。[Source: ISO/IEC/IEEE 42010]

条件（Condition）： 1. 部隊、システム、または個人が活動する作戦環境または状況の変数で、パフォーマンスに影響する可能性のあるもの。2. 目標を達成するために必要な、システムの物理的状態または振舞い上の状態。[Source: JP 3-0, Department of Defense Dictionary]；実行者が実行する、または実行する傾向がある環境または状況の状態。[Source: DM2, DMO Model Developers Guide]

制約（Constraint）： 計画策定の文脈では、上位の指揮官から指揮官に課された要件で、行動を指示し、行動の自由（freedom of action）を制限するもの。[Source: JP 5-0, Department of Defense Dictionary]制約とは、ある物体の許容される状態の範囲を指すこともある。[Source: Department of Defense CIO Architecture Framework]

基準（Criteria）： タスクの成功、有効性、または性能の特定の尺度に関連する、性能の最低許容レベル。多くの場合、時間、日数、パーセンテージ、発生数、分、マイル、またはその他のコマンドで指定された尺度で表される。[Source: CJCSI 3500.1 Series]

データ・キュレーション（Data Curation）： データのライフ・サイクルを通じて、長期的なアクセス可能性、共有、保存を確保するための継続的なデータの処理と維持管理[Source: OUSD（R&E） MEG 2.0, National Library of Medicine]

ドライバー（Driver）： 事業体の活動や到達目標に大きな影響を与える要因。[Source: UAFML Version 1.2 Specification]

効果（Effect）： 1. 行動、一連の行動、または別の効果によって生じる、システムの物理的状態または振舞いの状態。2. 行動の結果（result）、成果（outcome）、または帰結（consequence）。3. 条件、振舞い、または自由度に対する変化。[Source: JP 3-0, Department of Defense Dictionary]

効果のチェーン（Effects Chain）： 利害関係者のニーズを満たすために、望ましい効果をもたらすために成功裏に達成されなければならない一連の行動。例としては、文民当局の防衛支援や安定化作戦を提供する場合の人道支援／災害対応などがある。その他の例としては、敵の降伏を促すための情報作戦無線放送や電子戦能力の使用など、ノン・キネティックな行動が挙げられる。[Source: OUSD（R&E） MEG 1.0, 2023 DoD Electromagnetic Spectrum Superiority Strategy, Air Force Doctrine Publication 3-0]

事業体（Enterprise）： ビジネス上および作戦上の到達目標を達成するために相互に作用し合う、相互依存的なリソースの目的意識をもった組み合わせ。[Source: INCOSE SE Handbook, 5^th edition, 2023]

エンタープライズ・アーキテクチャ（Enterprise Architecture）： アーキテクチャの基本定義（構造、動作、グローバルルール）を、組織全体またはビジネス・プロセスの機能を果たすために協働するノード、システム、要素、またはその他のリソースの一群の最上位レベルに適用する。[Source: Borky and Bradley, Effective Model-Based Systems Engineering, 2019]

エクスカーション・ミッション・アプローチ（Excursion Mission Approach）： ベースライン・ミッション・アプローチにおける前提、ミッション要素、及び／又は振舞いの変更。[Source: OUSD（R&E）]

エンタープライズ・システムズ・エンジニアリング（Enterprise Systems Engineering）：システムズ・エンジニアリングの原則、コンセプト、手法を事業体の計画策定、デザイン、改善、作戦に適用すること。

機能（Function）： 人間や機械がそれを実行することができるという文脈で特定される活動。[Source: UAFML Version 1.2 Specification]

緑部隊（Green Force）： 連合国戦闘員。[Source: OUSD（R&E） MEG 2.0]

ハードウェア・アーキテクチャ（Hardware Architecture）： 基本定義をハードウェアに適用し、プロセッサ、ストレージ、相互接続、オペレータ・ステーション、通信、センサ、エフェクタ、その他のハードウェア要素に焦点を当てる。[Source: Borky and Bradley, Effective Model-Based Systems Engineering, 2019]

相互運用性（Interoperability）： 事業体の他のシステムやノードとの情報共有、共通理解、協調行動をサポートする機能を提供するアーキテクチャの要点であり、エンタープライズ・サービスとデータ戦略を実装する。[Source: Borky and Bradley, Effective Model-Based Systems Engineering, 2019]

統合（Joint）： 2つ以上の軍部が参加する活動、作戦、組織などを指す。この「統合（Joint）」の定義は、複数の国防総省（DoD）に適用される能力要件文書および能力ソリューションに適用されることに留意されたい。

統合性能要件（Joint Performance Requirement ：JPR）： 国防総省（DoD）の複数の軍隊、防衛機関、その他の組織の相互運用性を確保したり、能力ギャップを満たしたりするために重要または不可欠な性能要件であり、兵站などの他の方法で統合部隊に影響を与えるもの。[Source: JCIDS Manual, DAU Glossary 13^th Edition]

キル・チェーン（Kill Chain）： キネティックな成果（outcome）を伴うミッション・スレッド。航と海の構成部隊では「目標発見（Find）－対象特定（Fix）－追尾（Track）－ターゲット設定（Target）－交戦（Engage）－効果評価（Assess） ：F2T2EA）」、陸の構成部隊では「決心（Decide）、検知（Detect）、配送（Deliver）、評価（Assess）」方法論と呼ばれる動的なターゲッティング手順。[Source: OUSD（R&E） MEG 2.0, JP 3-09]

キル・ウェブ（Kill Web）： 適用されるシナリオまたはヴィットのミッション・スレッドとミッション・エンジニアリング・スレッドを統合（一体化）したもの。[Source: OUSD（R&E） MEG 2.0, OUSD（R&E）]

疎結合（Loose Coupling）： ある要素が他の要素との連携、情報交換、サービス提供のために必要とする詳細な知識を最小限に抑えるアーキテクチャの考え方。サービス指向に密接に関係する、インターフェースを介してアクセスされる機能やサービスの実装とは独立したインターフェース定義を維持する。[Source: Borky and Bradley, Effective Model-Based Systems Engineering, 2019]

効果の尺度（Measure of Effectiveness ：MOE）： 成功の尺度（MOS）を達成するためのタスクや活動の実行から得られる、測定可能な軍事的効果または成功のターゲット値。[Source: OUSD（R&E） MEG 2.0]

性能の尺度（Measure of Performance ：MOP）： ミッション・タスクまたは軍事効果を遂行するために使用されるシステムまたは行為者の測定可能な性能特性またはターゲットのパラメータ。[Source: OUSD（R&E） MEG 2.0]

成功の尺度（Measure of Success ：MOS）： 作戦環境における全体的ミッションの中で、成功のための測定可能な属性またはターゲット値。成功の尺度は、通常、青部隊（blue force）のミッション目標によって決定される。[Source: OUSD（R&E） MEG 2.0]

尺度（Measure）：個々のある属性の大きさ。[Source: DM2, DMO Model Developers Guide]

ミッション（Mission）： 実行すべき行動と行動の理由を明確に示す、目的を伴う不可欠なタスクまたはタスク。[Source: JP 3-0, Department of Defense Dictionary]

ミッション・アーキテクチャ（Mission Architecture）： 特定のエンド・ツー・エンド・ミッションを遂行するための方法と手段を、ミッション要素間の関係や依存関係とともに描いた見解または表現。これには、ミッション活動、アプローチ、システム、システム・オブ・システム、組織、能力などの要素が含まれる。[Source: OUSD（R&E） MEG 2.0]

ミッション・アーキテクチャ管理（Mission Architecture Management）： ミッション・アーキテクチャを計画策定、運営、統制、統合すること。ミッション・アーキテクチャ管理は、通常、大規模組織のミッション・アーキテクトが担当する。

ミッション領域（Mission Area）： ミッション領域は、複数の軍隊と複数のプログラムに関わるものであり、その例としては最低限以下のものがある。（1） 近接航空支援 （2） 防空および対空攻撃と対空防御 （3） 阻止 （4） インテリジェンス、監視、偵察 （5） 国防副長官と統合参謀本部副議長とが、本章の目的上、統合で指定した、重要で重複するその他のミッション領域。ミッション領域は通常、影響を受ける利害関係者 （利用者、運用者、取得者、試験実施者、維持者）を、望ましいミッションと能力の成果に一致させる。[Source: 2017 NDAA, Section 855]

ミッションの特徴付け（Mission Characterization）： 軍事目標と作戦に関連する諸要因の総体。これには、特定の時期と場所において達成されるべきミッション、成功の尺度、脅威、および制約が含まれる。ミッションの特徴付けのいずれかの要素に変更が生じた場合、ミッションは再定義されることがある。[Source: OUSD（R&E） MEG 2.0]

ミッションの文脈（Mission Context）： 誰が、何を、いつ、どこで、なぜ、達成すべきミッションの要素を説明する要素。ミッションの文脈のいずれかの要素に変更が生じた場合、ミッションを再定義することがある。[Source: OUSD（R&E） MEG 2.0]

ミッション要素（Mission Element）：  タスクを実行する人、組織、プラットフォーム、システム。[Source: OUSD（R&E） MEG 2.0]

ミッション・エンジニアリング分析（Mission Engineering Analysis）： 特定のシナリオに基づくミッションの文脈の中でミッシ ョン・アーキテクチャを評価し、ミッションの影響を探る定量的なアウトプットを提供するアプローチ。[Source: OUSD（R&E） MEG 2.0]

ミッション・エンジニアリング・スレッド（Mission Engineering Thread ：MET）： ミッションの実行に必要な能力、技術、システム、組織の詳細を含むミッション・スレッド。[Source: OUSD（R&E） MEG 2.0]

ミッション・エンジニアリング（Mission Engineering）： 現在および将来の作戦上のニーズと能力を分析、デザイン、統合し、望ましいミッション成果を達成するための技法的取組み全体を包含する学際的プロセス。[Source: OUSD（R&E） MEG 2.0]

ミッション統合管理（Mission Integration Management）：取得、エンジニアリング、作戦の各コミュニティにおける中核的活動で、ミッションを中心とした要素の統合（一体化）に焦点を当てる。[Source: 2017 NDAA, Section 855]

ミッション目標（Mission Objective）： 明確に定義され、決定的で、達成可能な最終目的（end）であり、それに向かってすべての作戦が行われること。目標とは、事業体がその到達目標を達成するために達成しようとする、具体的で、ターゲットした時間で、測定可能で、達成可能なターゲットである。[Source: DM2, DMO Model Developers Guide]

ミッション要件（Mission Requirements）： システムそのものではなく、スーパー・システムの文脈で定義される利害関係者の目標に関連する要件。[Source: The Engineering Design of Systems, Models and Methods, by Dennis M. Buede, 2009]

ミッション・タスク（Mission Tasks）： システム、個人または組織に特に割り当てられ、完了しなければならない明確に定義された行動または活動。[Source: Adapted from JP-01]

ミッション・スレッド（Mission Thread）： ミッションを達成するための一連の手順として提示される、エンド・ツー・エンドのミッション・タスク、活動、イベントの順序付けられたもの。[Source: OUSD（R&E） MEG 2.0]

モデル・フェデレーション（Model Federation）： エンタープライズなシステム・オブ・システムズ（SoS）エンジニアリングの指針となる システム・オブ・システムズ・モデルを作成するために、異なる組織のシステム・モデルを連結するコンセプト。モデル・フェデレーションは、モデル開発の取組みを総労働力全体に分散させることを可能にし、相乗効果を促進する。さらに、モデル・フェデレーションは、組織間で使用可能な、高レベルで事前定義された共通要素のライブラリに依存する。[Source: OUSD（R&E）]

モデル（Model）： システム、エンティティ、現象、またはプロセスの物理的、数学的、またはその他の論理的表現。[Source: DoDI 5000.61, DoDI 5000.70]。システムズ・エンジニアリング知識体系によると、モデルはしばしば記述的、分析的などに分類される。[Source: Systems Engineering Body of Knowledge] 他の情報源によると、モデルとは現実の不完全な表現、抽象化である。モデルの本質は、モデルが我々のために確実に答えることができる質問、または一連の質問である。[Source: The Engineering Design of Systems, Models and Methods, by Dennis M. Buede, 2009]

モジュール性（Modularity）： 次のような方法で階層的に分割されたアーキテクチャの信条。1） 関連する機能と情報をグループ化し、境界を越えた必要な相互作用を最小化する。2） アップグレードと技術刷新を可能にする。3） 構成要素ベースのデザイン手法の適用を容易にする。[Source: Borky and Bradley, Effective Model-Based Systems Engineering, 2019]

目標（Objective）：1.作戦が指向される、明確に定義され、決定的で、達成可能な到達目標。2. 指揮官の計画に不可欠な、行動の具体的な到達目標。ターゲットも参照。[Source: JP 5-0, Department of Defense Dictionary]

オープン性（Openness）： 以下に説明するオープン・システムの特徴を実現することを助けるデザインされたアーキテクチャの信条。1） モジュール性と標準への準拠 2） 内部および外部インターフェースの完全で明確な定義 3） 独占的または限定的な製品や機能への依存がないこと。[Source: Borky and Bradley, Effective Model-Based Systems Engineering, 2019]

作戦（Operation）： 1. 共通の目的または統一テーマを持った一連の戦術的行動。[Source: JP 1 Vol 1, Department of Defense Dictionary]； 2. 軍事行動または軍事ミッションの遂行。[Source: JP 3-0, Department of Defense Dictionary]

作戦レベル要件（Operational Level Requirement）： 作戦上の要件とは、「ミッション領域の欠陥、進化する用途や脅威、新たな技術、またはシステム・コストの改善に対処するために、必要不可欠な能力、関連する要件、性能の尺度、および、望ましい結果をもたらすために取るべき必要のあるプロセスまたは一連の行動を特定する」記述である。作戦上の要件評価は、作戦概念（CONOPS）から始まり、ミッション性能の仮定と制約、作戦とミッション成功のために必要な現在の欠陥や機能強化の特定において、より詳細なレベルまで踏み込む。作戦上の要件はシステム要件の基礎となる。[Source: MITRE, DMO Model Developers Guide]

作戦論理アーキテクチャ（Operational Logical Architecture）: 通常はミッション・スレッドとしてモデル化される、振舞いと構造を含むソリューションに依存しない形式でエンタープライズ・アーキテクチャを定義する。[Source: DMO Model Developers Guide]

作戦の実行者（Operational Performer）： タスクを実行する論理的実体（人間、自動化、または人間および／または自動化の集合体）。[Source: DM2, DMO Model Developers Guide]

作戦の視点（Operational Viewpoint）： UAFにおける視点は、作戦上の役割、活動、実行者によって能力がどのように実現されるかに焦点を当てたものである。[Source: Enterprise Architecture Guide for UAF v1.2 Specification]

戦闘序列（Order of Battle ：OB）： あらゆる軍事部隊の人員、部隊、装備の識別、兵力、指揮構造、配置。OBとも呼ばれる。[Source: JP 2-0, Department of Defense Dictionary]

人員の視点（Personnel Viewpoint）： UAFの視点は、作戦コンセプトが人員を通じてどのように実装されるかに焦点を当てたものである。[Source: Enterprise Architecture Guide for UAF v1.2 Specification]

プロジェクトの視点（Project Viewpoint）： UAFの視点は、プロジェクト活動とマイルストーンに従って、計画がどのようにリソースを提供するかに焦点を当てている。[Source: Enterprise Architecture Guide for UAF v1.2 Specification]

赤部隊（Red Force）： 敵対者の戦闘員。[Source: OUSD（R&E） MEG 2.0]

参照アーキテクチャ（Reference Architecture）： ドメインまたはエンティティのクラスに共通する特徴と振舞いを定義する論理的／機能的抽象化。参照アーキテクチャ（RA）は、ドメイン内の特定の一連の要件を満たす物理的なアーキテクチャを達成するために、関連する詳細を追加することによってインスタンス化される。[Source: Borky and Bradley, Effective Model-Based Systems Engineering, 2019]

リソース・アーキテクチャ（Resource Architecture）： リソース・アーキテクチャと含まれるシステムは作戦アーキテクチャを実装し、両者は実際のミッションにマッピングされる。[Source: Enterprise Architecture Guide for UAF v1.2 Specification]

リソースの視点（Resources Viewpoint）： UAFにおける視点は、リソース／ミッション要素を通じて、作戦コンセプトがどのように実装されるかに焦点を当てたものである。[Source: Enterprise Architecture Guide for UAF v1.2 Specification]

スケーラビリティ（Scalability）： 設置されたリソースに見合った全体的な性能を持ちながら、比較的小さなハードウェアやソフトウェアのユニットを追加することで性能や能力容量を向上させることができる。[Source: Borky and Bradley, Effective Model-Based Systems Engineering, 2019]

シナリオ（Scenario）： 紛争全体の地理的位置と時間枠の説明。シナリオには、脅威と味方の政治的・軍事的文脈、背景、前提、制約、限界、戦略的目標、その他の計画策定上の考慮事項などの情報が含まれる。[Source: OUSD（R&E） MEG 2.0]

ソフトウェア・アーキテクチャ（Software Architecture）： フレームワーク、ソフトウェア要件、アプリケーション・プログラム、インフラストラクチャー・プログラム、ワークフロー管理、ネットワークとメッセージング、インターフェースなど、コンピュータ・プログラミングの様々な側面に焦点を当てながら、基本的な定義をソフトウェアに適用する。[Source: Borky and Bradley, Effective Model-Based Systems Engineering, 2019]

利害関係者（Stakeholder）： 事業体によって生み出される、あるいは影響を受ける成果や中間効果に関心を持つ、あるいはその影響を受ける個人組織リソース、あるいは組織リソースの種類（事業体の内部と外部の両方）。[Source: UAFML Version 1.2 Specification]； 利害関係者とは、関心のあるシステムに対する懸念を持つ個人、グループ、または組織である。利害関係者の例：顧客、所有者、ユーザー、消費者、供給者、デザイナー、保守者、監査人、最高経営責任者（CEO）、認証機関、アーキテクト。[Source: ISO/IEC/IEEE 42010]

標準の遵守（Standards Compliance）： 成熟し、一般に公開され、コンセンサスに基づく標準を、適用される方針に従って、アーキテクチャ要素、サービス、およびインターフェースに適用する。[Source: Borky and Bradley, Effective Model-Based Systems Engineering, 2019]

戦略的視点（Strategic Viewpoint）： UAFの視点は、戦略、目標、望ましい能力、段階的構造、効果の尺度（MOE）、ロードマップに焦点を当てたもの。戦略計画は、ギャップや不足に対処するために段階的に能力を配備する。[Source: Enterprise Architecture Guide for UAF v1.2 Specification]

システム・アーキテクチャ（System Architecture）： ノードまたはシステムに割り当てられた定義された要件を満たすために協働する要素（最終的にはハードウェアとソフトウェアの構成要素）の一群に基本定義を適用する（明確なシステム境界とユーザー・インターフェースが定義されていることを意味する）。[Source: Borky and Bradley, Effective Model-Based Systems Engineering, 2019]

システム機能（System Function）： システムによって実行される機能。ITシステム内の活動の自動化、データ変換、情報交換を指すのが一般的だが、軍事能力の提供についても言及される。[Source: DM2, DMO Model Developers Guide]

システム・レベル要件（System Level Requirement）： 特定の製品またはサービスがどうあるべきか、何をすべきか、という、唯一の文書化されたニーズ。[Source: DM2, DMO Model Developers Guide]

システム（System）： 機能的、物理的、および／または振舞いに関連する、規則的に相互作用または相互依存する物理的要素のグループ。[Source: DM2, DMO Model Developers Guide]

ターゲット（Target）： 交戦またはその他の行動の可能性があると考えられる脅威の機能を果たす実体または物体。[Source: JP 3-60, Department of Defense Dictionary]

タスク（Task）： 適切な権限から個人または組織に特に割り当てられた、あるいはミッション分析中に導き出された、達成しなければならない明確に定義された行動または活動。[Source: JP 1, Vol 1, Department of Defense Dictionary]

試験計画と手順（Test Plan and Procedure）： 試験・評価（T&E）プログラムの全体的な構造と目標を文書化したもの。これは、詳細な試験・評価（T&E）計画を作成するためのフレームワークみを提供し、試験・評価（T&E）プログラムに関連するスケジュールとリソースの意味を文書化する。試験・評価マスター計画（TEMP） は、必要な開発試験・評価（DT&E）、作戦上の試験・評価（OT&E）、および実射試験・評価（LFT&E）活動を特定する。これは、プログラムのスケジュール、試験管理戦略と構造、および必要なリソースに関連する重要作戦上の課題（COI）、重要技術パラメータ（CTP）、能力開発文書（CDD）に文書化された目標と閾値、評価基準、およびマイルストーンの決心点。複数の軍種または統合プログラムの場合、単一の統合 試験・評価マスター計画（TEMP）が必要である。[Source: DAU Glossary 13th Edition]

脅威（Threat）： 米国のミッション達成を制限し、部隊、システム、または装備品の有効性を低下させうる敵対者の潜在的な強さ、能力、および戦略的目標の総和。これには、（a） システムの機能またはミッション遂行支援する能力に影響を及ぼす自然または環境的要因、（b） 敵対者の行動による場合を除き、ミッション遂行に影響を及ぼす機械的または部品的故障、 （c） 予算編成、再編、または事業の中止に関する事業化の問題は含まれない。[Source: DAU Glossary, CJCSI 5123.01H]

検証（Validation）： モデルまたはシミュレーションとその関連データが、モデルの意図された用途の観点から、現実世界を正確に表現している度合いを決定するプロセス。明示されたユーザー・ニーズに適用可能で、事業の作戦コンセプトと整合していること。[Source: Space and Missile Systems Center Mission Engineering Primer and Handbook]

妥当性確認（Verification）： モデルまたはシミュレーションの実装とその関連データが、開発者のコンセプト上の記述と仕様を正確に表しているかどうかを判断するプロセス。[Source: JP 3-13.1, Department of Defense Dictionary]

ビュー（View）：  アーキテクチャの視点（Architecture Viewpoint）によって管轄され、アーキテクチャ記述の一部を構成し、アーキテクチャのある側面を伝える情報提供項目。[Source: UAFML Version 1.2 Specification] ； アーキテクチャ説明（AD）のアーキテクチャ・ビューは、特定の懸念事項に対応するために、1人または複数の利害関係者の視点から、その視点によって確立された規約を用いて、対象システムのアーキテクチャを表現する。[Source: ISO/IEC/IEEE 42010]

視点（Viewpoint）： ビューの作成を管轄する1つ以上の懸念事項をフレーム化するためのアーキテクチャ・ ビューの作成、解釈、および使用に関する規則。[Source: UAFML Version 1.2 Specification]； アーキテクチャの視点（Architecture Viewpoint）とは、1種類のアーキテクチャ・ビューを構築、解釈、使用、分析するための規約の集合である。[Source: ISO/IEC/IEEE 42010]

ヴィネット（Vignette）： 作戦環境内の青部隊（blue force）の能力と赤部隊（red force）（脅威）を含む、特定のシステム群に関する、狭く具体的な順序付けられた一連の事象、振舞い、相互作用。ヴィネットはシナリオの小さな、理想的には自己完結した部分を表すことができる。[Source: OUSD（R&E） MEG 2.0]

白部隊（White Force、（White Units）： 非戦闘員または中立化の部隊。[Source: OUSD（R&E） MEG 2.0]

9.3.          略語リスト

AFTTP                    Air Force Tactics, Techniques, and Procedures

AMD                       Air and Missile Defense

BDD                       Block Definition Diagram

BMC2                      Battle Management Command & Control

BPMN                     Business Process Modeling Notation

C2                           Command and Control

CJCSI                      Chairman of the Joint Chiefs of Staff Instruction

CONOPS                Concept of Operations

DAU                       Defense Acquisition University

DMA                       Digital Mission Architecture (OUSD(R&E) MI)

DoD                        Department of Defense

DoDI                      Department of Defense Instruction

DoDAF                   Department of Defense Architecture Framework

DOT&E                  Director, Operational Test & Evaluation

DOTMLPF-P          Doctrine, Organization, Training, Materiel, Leadership and Education, Personnel, and Facilities

DTE&A                  Development Test, Evaluation, and Assessment

E2E                         End-to-End

EA                          Enterprise Architecture

ESE                         Enterprise Systems Engineering

F2T2EA                  Find, Fix, Track, Target, Engage, Assess

FFRDC                   Federally Funded Research & Development Centers

IBD                         Internal Block Diagram

ISO                         International Organization for Standardization

ISR                          Intelligence, surveillance, and reconnaissance

JCA                         Joint Capability Areas

JCSFL                     Joint Common System Function List

JICO                     Joint Interface Control Officer

JMETL                    Joint Mission Essential Task List

JP                            Joint Publication

JTC                         Joint Test Concept

M&S                       Modeling and Simulation

MASG                     Mission Architecture Style Guide

MBSE                     Model-Based Systems Engineering

MC                          Mission Capabilities

MCI                        Mission Concept Integration (OUSD(R&E)-MI)

ME                          Mission Engineering

MEA                       Mission Engineering Analysis (OUSD(R&E)-MI)

MEG                       Mission Engineering Guide

MET                       Mission Engineering Thread

MI                           Mission Integration (OUSD(R&E))

MIL-STD                Military standard

MoDAF                  Ministry of Defence Architecture Framework

MOE                       Measures of Effectiveness

MOP                       Measures of Performance

MOS                       Measures of Success

MT                          Mission Thread

NAF                        NATO Architecture Framework

OB                          Order of Battle

ODASD(MI)           Office of the Deputy Assistant Secretary of Defense for Mission Integration

OMG                      Object Management Group

O-Plan                     Operation Plan

Op-Pr                      Operational Processes

OSD                        Office of the Secretary of Defense

OUSD(A&S)           Office of the Under Secretary of Defense for Acquisition and Sustainment

OUSD(R&E)          Office of the Under Secretary of Defense for Research and Engineering

Rs-Cn                      Resources Connectivity

Rs-Pr                       Resources Processes

Rs-Sr                       Resources Structure

SA                           System Architecture

SCG                        Security Classification Guide

SE                           Systems Engineering

SEAD                     Suppression of Enemy Air Defense

SME                        Subject Matter Expert

SoS                          System of Systems

St-Sr                        Strategic Structure

St-Tx                       Strategic Taxonomy

SysML                     Systems Modeling Language

T&E                        Test and Evaluation

TLAMs                    Tomahawk Land Attack Missiles

TTP                         Tactics, Techniques, and Procedures

U.S.                         United States

UAF                        Unified Architecture Framework

UAFML                  Unified Architecture Framework Modeling Language

UARC                     University Affiliated Research Centers

UJTL                       Universal Joint Task List

UML                       Unified Modeling Language

USD(R&E)             Undersecretary of Defense for Research and Engineering

UTDT                     UJTL Task Development Tool

V&V                       Verification and Validation

10.   文献

• Berg, C. P., Tilley, K. E., & Kem, J. D. (2018). Deep Manuever Historical Case Studies of Manuever in Large-Scale Combat Operations. Army University Press. Retrieved from https://www.armyupress.army.mil/Books/Browse-Books/iBooks-and- EPUBs/Task_Force_Normandy/
• Borky, J. M., & Bradley, T. H. (2019). Effective Model-Based Systems Engineering. Springer. Curtis E. Lemay Center for Doctrine Development and Education. (2016). Air Force Doctrine Publication (AFDP) 3-0 Operations and Planning. Retrieved from https://www.doctrine.af.mil/Portals/61/documents/AFDP_3-0/3-0-D19-OPS-Effects- Based-Plan.pdf Data Markings and Classifications. (n.d.). Retrieved from Dassault Systemes: https://www.3ds.com/products/catia/no-magic/data-marking-classification-plugin
• Defense Acquisition Library (DAU). (2020, July 21). Retrieved from https://www.dau.edu/tools/dau-glossary
• Department of Defense OUSD(R&E). (2020). Department of Defense Mission Engineering Guide. Washington. DC.
• Department of Defense OUSD(R&E). (2023). Department of Defense Mission Engineering Guide 2.0. Washington, DC. Retrieved from https://ac.cto.mil/wp-content/uploads/2023/11/MEG_2_Oct2023.pdf
• Department of Defense OUSD(R&E). (2023, October 19). Memorandum for Mission Engineering Executive Steering Council. Enabling Digital Mission Architecture Integration Across the Department of Defense During Fiscal Year 2024. Washington, DC.
• Deptula, D. (2021, March 1). Desert Storm at 30: Aerospace Power and the U.S. Military.
• Retrieved from War on the Rocks: https://warontherocks.com/2021/03/desert-storm-at-30-aerospace-power-and-the-u-s-military/
• Desert Shield/ Desert Storm. (2023, September 21). Retrieved from Naval History and Heritage Command: https://www.history.navy.mil/browse-by-topic/wars-conflicts-and-operations/middle-east/shield-storm.html.
• Federal Aviation Administration. (n.d.). 14 CFR §§ 91.151 – 91.162-91.165 Visual Flight Rules.
• Washington, DC: FAA.
• Federal Aviation Administration. (n.d.). 14 CFR §§ 91.167 – 91.195-91.199 Instrument Flight Rules. Washington, DC: FAA.
• Hause, M. (2024, March 20). Darth Vader’s Secret Weapon: Implementing Mission Engineering with UAF. Retrieved from OMG UAF Summit: https://www.omg.org/events/2024Q1/special-events/UAF-presentations/1415-Hoth-Mission-Engineering-Slides-2024-03-20.pdf
• History.com Editors. (2022, November 1). Persian Gulf War. Retrieved from History.com: https://www.history.com/topics/middle-east/persian-gulf-war
• International Organization for Standardization (ISO). (n.d.). ISO 3166 Country Codes. Retrieved from https://www.iso.org/iso-3166-country-codes.html
• International Organization for Standardization (ISO). (n.d.). ISO/IEC/IEEE 15288 – System Life Cycle Processes.
• International Organization for Standardization (ISO). (n.d.). ISO/IEC/IEEE 42010 – Architecture Description.
• International Organization for Standardization (ISO). (n.d.). ISO/IEC/IEEE 42020 – Architecture Processes.
• International Organization for Standardization (ISO). (n.d.). ISO/IEC/IEEE 42030 – Architecture Evaluation Framework .
• International Organization for Standardization (ISO). (n.d.). ISO/IEC/IEEE 42042 – Reference Architecture.
• Joint Chiefs of Staff. (2015, March 19). UJT to JCA Mapping. Retrieved from https://jdeis.js.mil/jdeis/jel/training/jca_ujt_mapping.pdf
• Joint Chiefs of Staff. (2023, October 6). UJTL Task Development Tool (UTDT). Retrieved from https://utdt.js.mil/home
• Lange, K. (2018, January 9). 6 Things to Know About Operation Desert Storm. (DoD News, Defense Media Activity) Retrieved from Military.com: https://www.military.com/history/operation-desert-storm-6-things-know
• Martin, J. (2024, July). Enabling Enterprise Transformation Using Enterprise Architecture Principles and Concepts. 34th Annual INCOSE Symposium. Dublin.
• Martin, J., & Alvarez, K. (2023). Leveraging UAF for Mission Engineering. INCOSE Symposium.
• Martin, J., Fairley, D., & Lawson, B. (2024, May 06). Enterprise Systems Engineering. Retrieved from SEBoK Wiki: https://sebokwiki.org/wiki/Enterprise_Systems_Engineering
• No Magic, Inc. (2022, July 1). 2022x Version News. Retrieved from Cameo Enterprise Architecture 2022x: https://docs.nomagic.com/display/CEA2022x/2022x+Version+News
• No Magic, Inc. (n.d.). Using Libraries. Retrieved from UAF 1.2 Plug-In 2022x: https://docs.nomagic.com/display/UAF12P2022x/Using+libraries
• Object Management Group. (2021). United Architecture Framework (UAF) Version 1.2 Enterprise Architecture Guide for UAF. Retrieved from https://www.omg.org/spec/UAF/1.2
• Object Management Group. (2022). Unified Architecture Framework (UAF) Traceability Appendix A Version 1.2. Retrieved from https://www.omg.org/cgi-bin/doc?formal/22-07- 07.pdf
• Operation DESERT STORM. (n.d.). Retrieved from U.S. Army Center of Military History: https://history.army.mil/html/bookshelves/resmat/desert-storm/index.html
• Shreve, G. (2024, March 20). UAF or SysML – Yes? Retrieved from OMG UAF Summit: https://www.omg.org/events/2024Q1/special-events/UAF-presentations/1615-UAF_SysML_Yes_Updated-2024-UAF-Summit%20v2.pdf
• U.S. Air Force. (n.d.). 1991 – Operation Desert Shield/Desert Storm. Retrieved from Air Force Historical Support Division: https://www.afhistory.af.mil/FAQs/Fact-Sheets/Article/458965/1991-operation-desert-shielddesert-storm/
• U.S. Air Force. (2021). Air Force Doctrine Publication 3-60, Targeting. Maxwell AFB. Retrieved from https://www.doctrine.af.mil/Portals/61/documents/AFDP_3-60/3-60-AFDP- TARGETING.pdf
• U.S. Air Force. (2021). Air Force Doctrine Publication 3-70, Strategic Attack. Maxwell AFB. Retrieved from https://www.doctrine.af.mil/Portals/61/documents/AFDP_3-70/3-70- AFDP-STRATEGIC-ATTACK.pdf
• U.S. Department of Defense. (2012). Joint Publication 3-01, Countering Air and Missile Threats. Washington, DC: Joint Chiefs of Staff.
• U.S. Department of Defense. (2017). Joint Publication 5-0, Joint Planning. Washington, DC: Joint Chiefs of Staff.
• U.S. Department of Defense. (2019). Joint Publication 3-0, Joint Operations. Washington, DC: Joint Chiefs of Staff.
• U.S. Department of Defense. (2020). 2020 Department of Defense Electromagnetic Spectrum Superiority Strategy. Retrieved from https://media.defense.gov/2020/Oct/29/2002525927/-1/-1/0/electromagnetic_spectrum_superiority_strategy.pdf
• U.S. Department of Defense. (2022). Joint Publication 2-0, Intelligence. Washington, DC: Joint Chiefs of Staff.
• U.S. Department of the Navy. (2023, May 22). DMO Model Developers Guide Wiki.
• U.S. Department of the Navy. (2023, May 22). Naval Federated Architecture Reference Modelling Wiki.

ノート

[1] Department of Defense OUSD(R&E). (2023). Department of Defense Mission Engineering Guide 2.0. Washington, DC. Retrieved from https://ac.cto.mil/wp-content/uploads/2023/11/MEG_2_Oct2023.pdf.

[2] Department of Defense OUSD(R&E). (2023, October 19). Memorandum for Mission Engineering Executive Steering Council. Enabling Digital Mission Architecture Integration Across the Department of Defense During Fiscal Year 2024. Washington, DC.

[3] Object Management Group. (2021). United Architecture Framework (UAF) Version 1.2 Enterprise Architecture Guide for UAF. Retrieved from https://www.omg.org/spec/UAF/1.2

[4] Department of Defense OUSD(R&E). (2023). Department of Defense Mission Engineering Guide 2.0. Washington, DC. Retrieved from https://ac.cto.mil/wp-content/uploads/2023/11/MEG_2_Oct2023.pdf

[5] Borky, J. M., & Bradley, T. H. (2019). Effective Model-Based Systems Engineering. Springer.

[6] Copyright 2024 James Martin. Used with Permission.

[7] Martin, J. (2024, July). Enabling Enterprise Transformation Using Enterprise Architecture Principles and Concepts. 34th Annual INCOSE Symposium. Dublin. from https://www.omg.org/cgi-bin/doc?formal/22-07-07.pdf

[8] Object Management Group. (2022). Unified Architecture Framework (UAF) Traceability Appendix A Version 1.2. Retrieved

[9] Shreve, G. (2024, March 20). UAF or SysML – Yes? Retrieved from OMG UAF Summit: https://www.omg.org/events/2024Q1/special-events/UAF-presentations/1615-UAF_SysML_Yes_Updated-2024-UAF-Summit%20v2.pdf

[10] Object Management Group. (2022). Unified Architecture Framework (UAF) Traceability Appendix A Version 1.2. Retrieved

[11] Object Management Group. (2021). United Architecture Framework (UAF) Version 1.2 Enterprise Architecture Guide for UAF. Retrieved from https://www.omg.org/spec/UAF/1.2

[12] Copyright 2023 James Martin. Used with Permission.

[13] U.S. Air Force. (2021). Air Force Doctrine Publication 3-70, Strategic Attack. Maxwell AFB. Retrieved from https://www.doctrine.af.mil/Portals/61/documents/AFDP_3-70/3-70-AFDP-STRATEGIC-ATTACK.pdf U.S. Department of Defense. (2012). Joint Publication 3-01, Countering Air and Missile Threats. Washington, DC: Joint Chiefs of Staff.

[14] U.S. Department of Defense. (2019). Joint Publication 3-0, Joint Operations. Washington, DC: Joint Chiefs of Staff.

[15] Joint Chiefs of Staff. (2023, October 6). UJTL Task Development Tool (UTDT). Retrieved from https://utdt.js.mil/home

[16] U.S. Department of Defense. (2022). Joint Publication 2-0, Intelligence. Washington, DC: Joint Chiefs of Staff.

[17] Department of Defense OUSD(R&E). (2023). Department of Defense Mission Engineering Guide 2.0. Washington, DC. Retrieved from https://ac.cto.mil/wp-content/uploads/2023/11/MEG_2_Oct2023.pdf

[18] International Organization for Standardization (ISO). (n.d.). ISO 3166 Country Codes. Retrieved from https://www.iso.org/iso- 3166-country-codes.html

[19] International Organization for Standardization (ISO). (n.d.). ISO 3166 Country Codes. Retrieved from https://www.iso.org/iso- 3166-country-codes.html