米国防総省のミッション・エンジニアリング・ガイド
軍隊が使用する兵器はどのようにして作られてきたのか？という問いの答えるのが、軍事マクレガー・ノックス, ウィリアムソン・マーレーが著した「軍事革命とRMAの戦略史 : 軍事革命の史的変遷1300～2050年」の書籍かもしれない。
その時代の国家の安全保障上の脅威は何か？その脅威を生んでいる技術・産業は何か？国益を支える資源はどこに依存しているのか？等々を、軍事革命という観点から著されたものである。
「戦い方とそれを支える技術」と「新しい技術とそれを使用した戦い方」という表現について、どちらなのかということはあまり意味をなさないかもしれないが、近代的にはその考え方の根源には国家安全保障の戦略があるというが一般的な見方だといえるのであろう。
2021年3月3日に米国のバイデン大統領が暫定的な国家安全保障戦略の指針「Interim National Security Strategic Guidance」を公表した。国の安全保障全般の態勢・体制は国家最上位の安全保障戦略を頂点にして、下位の各分野での戦略の策定等が行われていくものである。米統合参謀本部では、新たな統合用兵コンセプト（ドクトリン）（Joint Warfighting Concept (Doctrine)）を検討中と言われているが、これらも最上位の国家安全保障との一貫性が問われるものであり、暫定的な指針文書の重要性は言うまでもないであろう。
一方、一兵器の視点から上流を眺めた時に、米国各軍種等の機関が取り組んでいる各種装備品等も国家安全保障戦略からの糸がしっかりと繋がるように修正がなされていくと理解している。作戦環境の変化や科学技術の進展は、マルチドメインという言葉が表しているように、各軍種が単独で戦うことは想像しがたいくらいに複雑になってきているといえる。火力の超長射程化や、戦闘空間での速度の重要性、監視・偵察能力の向上、無人兵器の出現、各軍種を跨る情報の重要性は高まっている。このように、ますます複雑になる各種兵器の開発環境の中、米国防総省は、部隊等に与えられるミッションと兵器の関係のつながりを明確にした、構想策定から開発・評価にあたる実務者が研究や分析に使用するための工学的な指導書を、昨年11月に、「ミッション・エンジニアリング・ガイド」として公表した。これらの方法論が可能となるのは、統合レベルや各軍種レベルのコンセプトやドクトリンが明文化されているからともいえる。
日本の防衛省も、防衛技術戦略、中長期技術見積り、研究開発ビジョン（将来無人装備）の全体概要に見られるように、平成２５年１２月に閣議決定された「国家安全保障戦略」を契機として防衛装備に関わる戦略文書を策定している。また、その後「平成31 年度以降に係る防衛計画の大綱」が策定されると新たな要求に応じるための防衛技術戦略文書を策定しているところであり、上位の戦略との一貫性は保たれているといえる。更に個別の装備品の開発にあたっては、それぞれの装備品の機能・性能を運用上のニーズから分析・評価しているところであろうが、統合の視点で分析・評価するうえでは、米国防総省の本「ミッション・エンジニアリング・ガイド」は、統合レベルや各軍種レベルのコンセプトやドクトリン文書の重要性の認識も含めて、参考になるのではないかと考えるところである。
以下、「ミッション・エンジニアリング・ガイド」の一部を紹介する。（軍治）
ミッション・エンジニアリング・ガイド （抜粋）
Mission Engineering Guide
2020年11月
エンジニアリング副所長室
研究・エンジニアリング担当 国防次官室
ワシントン D.C.
配布区分「Ａ」：公開承認 配布制限無
1.2 ミッション・エンジニアリングの概要：Mission Engineering Overview
2 ミッション・エンジニアリングのアプローチと方法論：MISSION ENGINEERING APPROACH AND METHODOLOGY
2.1 問題の提起–重要な質問の特定：Problem Statement – Identifying the Key Questions
2.2 ミッションの定義と特徴づけ：Mission Definition and Characterization
2.3 ミッション指標（成功と効果の尺度）：Mission Metrics (Measures of Success and Effectiveness)
2.4 分析のデザイン：Design of Analysis
2.5 分析の実行/モデルの実行：Perform Analysis/Run Models
2.6 研究と結論を文書化する：Document the Study and Conclusions
1 導入：INTRODUCTION
1.1 ガイドの目標：Guide Objectives
このガイドでは、国防総省（DoD）のミッション・エンジニアリング（ME）の基本的な要素と全体的な方法論について説明する。これには、すでに受け入れられている情報源に基づいて、研究と分析の一般的なエンジニアリング用語の一部となるミッション・エンジニアリング（ME）の用語と定義のセットが含まれる。国防総省内部部局（OSD）、統合参謀本部、各軍種、および各戦闘軍（Combatant Commands）で、すでに受け入れられている情報源と利害関係者コミュニティからの文書に基づいている。ガイドは次のことを行う。
- 国防総省（DoD）のミッション・エンジニアリング（ME）の主な属性と、それらを適用してミッション・エンジニアリング（ME）分析プロセスに技術的および工学的厳密さを追加する方法を説明する。
- 実務者が問題を定式化し、ミッションの文脈で分析を実行することに関連する主な原則の理解を構築できるようにする。そして
- 重要な決定を通知するのに役立つ一連の成果（product）で結果または結論を文書化および描写する方法に関する洞察をユーザーに提供する。
国防次官（研究、エンジニアリング担当）（OUSD（R＆E））は、国防総省と業界全体の初心者と経験豊富な実務者の両方のためのガイドを作成した。このガイドは、エンジニアリングのベストプラクティスと並行して進化する生きた文書である。ツールとインフラストラクチャがミッション・エンジニアリング（ME）をサポートするように進化するにつれて、著者はガイドを継続的に成熟させて、新しい統合用兵コンセプト（joint warfighting concepts）、戦闘員の一体化（warfighter integration）、およびシステム・オブ・システムズ（SoS）の相互運用性の成熟をサポートするミッションに焦点を当てた分析と研究を実施するための関連情報を含める。
1.2 ミッション・エンジニアリングの概要：Mission Engineering Overview
2017会計年度の国防権限法（NDAA）、セクション855は、国防総省に対し、取得、エンジニアリング、および作戦コミュニティ内のコア活動としてミッション統合管理（MIM）を確立し、すべてがミッションの周りの中心となる要素の統合に焦点を当てるよう指示した。国防総省（DoD）統合出版物JP 3-0「統合作戦「Joint Operations）」は、ミッションを目的（purpose）とともに、実行するアクションとその理由を明確に示すタスクとして定義している。より簡単に言えば、ミッションは個人または部隊に割り当てられた義務である。
国防次官（研究、エンジニアリング担当）（OUSD（R＆E））は、ミッション統合管理（MIM）を、エンド・ツー・エンドのミッションに焦点を当てた重要な決定を導くためのコンセプト、活動、技術、要件、プログラム、および予算計画の同期、管理、および調整として定義している。ミッション・エンジニアリング（ME）は、要件プロセスにデザインされたミッションベースの出力を提供し、プロトタイプをガイドし、デザイン・オプションを提供し、投資決定を通知する手段としてのミッション統合管理（MIM）の技術サブ要素である。
ミッション統合管理（MIM）に関する議会への国防総省（DoD）レポート（2018年3月）および国防総省取得ガイドブック（DAG）は、ミッション・エンジニアリング（ME）を、望ましい用兵ミッション効果を達成するための現在および新たな作戦およびシステム能力の計画作成、分析、編成、および一体化として定義している。ミッション・エンジニアリング（ME）はトップダウンのアプローチであり、エンジニアリング結果を提供して、拡張能力、技術、システムの相互依存性、およびアーキテクチャを特定し、開発、プロトタイプ、実験、およびシステム・オブ・システムズ（SoS）をガイドして、参照ミッションを達成し、ミッション能力のギャップを埋める。ミッション・エンジニアリング（ME）は、作戦上のミッションの文脈でシステムとシステム・オブ・システムズ（SoS）を使用して、戦闘員（warfighter）のミッションのニーズに対応するために能力の成熟を導くことにより、正しいものを構築するだけでなく、正しいものを構築することについて利害関係者に通知する。図1-1は、コンセプトから能力開発、取得まで、ミッション・エンジニアリング（ME）成果（product）のさまざまな使用者（consumers）を示している。
図1-1。ミッション・エンジニアリング出力の使用者 |
ミッション・エンジニアリング（ME）は、検証済みのミッション定義と信頼できる厳選されたデータセットを分析の基礎として使用して、一連の作戦的質問または戦術的質問に回答する。結論の共有評価と分析入力の理解は、リーダーシップが戦闘員（warfighter）と統合ミッションを支援する決定のための最善の行動方針を追求するのに役立つ。
ミッション・エンジニアリング（ME）プロセスの主な質問は次のとおりである。
- ミッションは何か？
- その境界は何か、そしてそれは他のミッションとどのように相互作用しなければならないか？
- そのパフォーマンス尺度は何か？
- ミッション能力のギャップは何か？
- 新しい能力は我々の闘い方をどのように変えることができるか？
- 能力やシステムの変更は、ミッションやアーキテクチャにとってどのような意味があるか？
- 構成技術、成果（product）、および能力のパフォーマンスに対するミッションパフォーマンスの感度はどのくらいか？
- 新しい能力は、レガシーシステムとどのように最適に一体化または置き換えられるか？
- そして、そのバランスをどのように最適化して、特定のミッションに最も致命的で手頃な一体化した能力を提供するのか。
ミッション・エンジニアリング（ME）分析の主な成果（products）は次のとおりである。
（1）継続的な再利用とさらなる分析のための分析レポート、厳選されたデータ、およびモデルの形式で文書化された結果。
（2）重要な決定についてリーダーシップに通知するための視覚化とブリーフィング。そして
（3）政府の参照アーキテクチャ（GRA）（ミッションの図解およびミッションと能力に関連する要素間の相互作用の形式）。
これらの成果（products）を組み合わせることで、ミッション能力のギャップを特定して定量化し、将来のミッションニーズに対応し、要件を通知し、能力ポートフォリオ管理をサポートするための技術ソリューションに注目することができる。
ミッション・エンジニアリング（ME）分析は、定期的に、またはソースの更新に基づいて必要に応じて厳選され、それ自体の内部と、同じシナリオ、仮定、制約、システム属性、およびデータを使用した以前の関連研究の両方で一貫していることが不可欠である。また、データのソースと分析の入力として使用される要件を追跡することも不可欠である。
デジタル・エンジニアリング（DE）の原則は、ミッション・エンジニアリング（ME）分析全体でのデジタルツールの識別と利用に加えて、厳選されたデータとモデルの効果的な使用と再利用を通じてミッション・エンジニアリング（ME）プロセスの一貫性を促進するのに役立つため、ミッション・エンジニアリング（ME）を実施する際に使用する必要がある。デジタル・エンジニアリング（DE）は、ミッション・スレッド（MT）とアーキテクチャ、一体化された分析能力、共通のミッション表現、および拡張可能なツールセットの維持を可能にする、ミッション・エンジニアリング（ME）の重要な基本要素である。
図1-2に示すように、ミッション・エンジニアリング（ME）は、時間枠、使用する分析の厳密さ、および対処する問題の複雑さの間のバランスを取る行為である。50年先の結果を予測したり、取り組むべきミッションの複雑さを増したりするなど、1つ以上の側面で行き過ぎた場合、ミッション・エンジニアリング（ME）成果（products）に期待できる信頼水準（confidence-level）に影響を与える。また、データの可用性とアクセス可能性に基づく分析の厳密さと妥当性にも影響を与える可能性がある。
図1‐2。ミッション・エンジニアリングの3つの軸 |
2 ミッション・エンジニアリングのアプローチと方法論：MISSION ENGINEERING APPROACH AND METHODOLOGY
ミッション・エンジニアリング（ME）は、測定可能なトレードオフを特定し、結論を導き出すために、ミッションの構成要素を分解および分析するための分析およびデータ駆動型のアプローチである。尋ねられた質問、および特定のシナリオと関連する文脈の理解のレベルに基づいて、ミッション・エンジニアリング（ME）分析（研究の一部）は、将来の軍事作戦の優れた「価値」を生み出す可能性のある新しいコンセプト、システム、技術、または戦術を仮定する場合がある。次に、ミッション・エンジニアリング（ME）実務者は、ベースラインアプローチを測定および比較して、各代替ケース（トライアルケースとも呼ばれる）へのミッションを完了するための分析実験をデザインする。
ミッションの貢献する側面の数は無限であるため、ミッション・エンジニアリング（ME）の大部分は経験的な調査である。したがって、入力と最終効果の間の意味のある関係を発見するには、実務者が完全に文書化し、完全に理解することが重要である：ミッションの定義、基礎となる仮定と制約、ミッションの成功の尺度（指標（metrics））、およびモデルへの入力として使用されるソースデータ。これらの要素は、提案されたアプローチのメリットを分離するための定量分析にとって重要である。十分な試行が行われると、ミッションドライバーが出現し、特定のパラメータの感度分析（sensitivity analysis）の基礎を形成する可能性がある。たとえば、多くのミッショントライアルで兵器の速度だけを分離して変更することで、速度とミッションの成功の感度の関係を表すことができる。
図2-1に示すように、ミッション・エンジニアリング（ME）プロセスは、最終状態（end）を念頭に置いて、慎重に明確化された問題ステートメント、ミッションの特性評価と指標（metrics）の識別、およびミッションの分析と出力結果の文書化に必要なデータとモデルの収集を通じて開始する。
図2-1。ミッション・エンジニアリングのアプローチと方法論 |
問題の説明、ミッションの特性、およびミッションの指標を事前に特定して明確に理解し、文書化する必要がある。このレベルの詳細で計画を作成すると、徹底的なエンジニアリング分析の実行が大幅に容易になり、ミッション・アプローチの結果を調査し、その後の推奨事項に関するコラボレーションをサポートする。
2.1 問題の提起–重要な質問の特定：Problem Statement – Identifying the Key Questions
分析が正しくデザインされていることを確認するには、目的（purpose）を明確にし、回答する関心のある質問を作成することによってミッション・エンジニアリング（ME）研究を開始することが不可欠である。この情報は、利害関係者の特定、適切なデータとモデルの収集、意味のある測定可能な指標（metrics）の特定など、ミッション・エンジニアリング（ME）分析全体で他の要因を推進するため、重要である。これらはすべて、重要な決定に役立つ結果を取得するために使用される質問を作成するときは、次のことを考慮する必要がある。正確に何を知りたいか。何を学びたいか？ リーダーシップはどのような決定を求めているか？ さらに、問題の説明では、関心のあるミッションまたは技術分野と、求められている望ましい回答を完全に明確にする必要がある。
以下は、実務者が研究の質問を特定するのに役立つ例である。
- 我々が探求したいミッションやコンセプトは何か？
- どの技術または能力を評価する必要があるか？
- どのようなミッション能力のギャップが疑われる/仮説を立てるか？
- どのような技術、成果（products）、能力がミッションをサポートしているか？
- 構成技術、成果（products）、および能力の成熟度、デモンストレーション、およびフィールド化のタイムラインについて何が想定されているか？
- 構成成果（products）はどのように相互作用するか？
- 相互作用のための既存のインターフェイスと標準は適切か、それとも更新（または潜在的に新しい標準）が必要か？
いくつかの具体的な研究の質問は次のとおりである。
- 長距離火力の最適な部隊の組み合わせは何か？
- 指向性エネルギーを使用することのミッションは何か？
- 新たな技術（つまり、人工知能）をミッション・スレッドに最適に一体化するにはどうすればよいか？
2.2 ミッションの定義と特徴づけ：Mission Definition and Characterization
ミッションの定義と特性評価は、調査対象の問題の分析の入力として使用される適切な作戦ミッションの文脈と仮定を提供する。「問題」の記述は、我々が調査したいことを説明するが、「ミッション」の定義と特性は、作戦環境や、特定のミッションに対する指揮官の望ましい意図や目標など、侵入条件と境界の両方を説明する。
ミッション・エンジニアリング（ME）分析が効果的であるためには、ミッションの定義は、試行および評価されるすべての代替アプローチを通じて同一である必要がある。一度設定すると、ミッション定義はミッション・エンジニアリング（ME）分析全体で変更されるべきではなく、ミッション・エンジニアリング（ME）メソッドから得られるすべての成果（products）に含まれる必要がある。この一貫性がなければ、研究者はオプションの有効性を正確に比較することはできない。
ミッションの定義と特性評価は、次の情報に対処する演劇の舞台と考えることができる。
〇ミッション（The Mission）
ミッションの定義は、国防戦略、防衛計画作成ガイダンス、戦役計画、戦闘軍作戦計画、統合用兵コンセプト（Joint Warfighting Concept）、または軍事的機能（military functions）、作戦の地政学的文脈、ミッションの成功またはミッションの目標の全体的な定義、または作戦の利害関係者の入力を提供する他の同様の作戦目的文書（operational purpose documents）にリンクして指揮官の意図を定義することから始まる。これらの包括的な計画作成文書へのミッション定義の根拠は、関心のある必要な詳細を導き出すための一貫した基礎を提供する。問題ステートメントで定義するか、計画作成文書の全体的な文脈から導き出す必要があるミッション定義の重要な要素は、意図した作戦の時間枠である（つまり、将来何年調査する予定か？）。
〇作戦環境（Operational Environment）
防衛計画作成シナリオまたはその他の軍事/国防総省（DoD）の参照へのリンク。地理的領域、紛争、脅威のレイダウン、赤と青の軍隊、戦闘序列（Order of Battle: OOB）、および全体的な活動規則を含む、ミッションシナリオと関心のあるビネットの詳細な側面を含むミッションの特定の設定 。主な参考資料は、青の部隊と敵対者または赤の部隊の作戦コンセプト（CONOPS）と部隊運用のコンセプト（Concept of Employment）である。
〇作戦上の仮定と制約（「条件の入力」）（Operational Assumptions and Constraints (“Entering Conditions”)）
仮定または導出された環境条件とリソースまたは力の制限は、ミッションの文脈に対するストレス要因であるか、利害関係者が特に関心を持っているものである（たとえば、競合する環境、天候、後方支援の制約（たとえば、 航空機アセットへのアクセス）、静止または移動するターゲット、および作戦上の制約[例：放出統制（EMCON）状態]）。これらの仮定を体系的に文書化することは、あるミッション・エンジニアリング（ME）研究の結果を他のミッション・エンジニアリング（ME）研究の結果と比較できるようにし、分析を更新する必要があるときに将来の追跡可能性を可能にし、リーダーシップが正確で情報に基づいた決定を下せるようにするために不可欠である。
ミッションと問題空間を定義する際には、ミッションの「何」をソリューションの「方法」から明確に分離することが重要である。ミッション・エンジニアリング（ME）の到達目標（goal）は、代替のミッション実行のコンセプト、バリエーション、およびトレードスペースを公正に評価することにより、ミッション能力のギャップと最適なソリューションセットを特定することである。ミッションの定義を過度に制約すると、必ずしも最適ではない潜在的なソリューションに人為的に影響を及ぼす。
図2-2に示すように、ミッションには、使用する作戦上のアプローチとシステムに影響を与える目標、作戦環境、前提条件、および制約を組み立てるために必要なすべての詳細が含まれる。
図2-2。ミッションの特徴付けとミッション指標 |
2.2.1 時間の枠：Time Frame
ミッション定義の重要な要素は、ミッション・アプローチが評価される時間枠である。時間枠は、ミッションが行われる特定の年を反映する必要がある。「現在」の日（現在または現在）または「将来」の日（今後の時間–近くまたは遠く）の場合がある。ほとんどの場合、時間枠は、特定の計画作成時間枠で設定された戦域の競合とチャレンジ・シナリオの可能性をすでに定義しているシナリオの複数軍種部隊配置（MSFD）ファミリーに基づいている。
ミッション・エンジニアリング（ME）は、事前定義された国家防衛戦略、国防計画作成ガイダンス、国家軍事戦略、複数軍種部隊配置（MSFD）、および将来の防衛プログラム（FYDP）の時間枠を使用して投資決定をサポートすることに重点を置いているため、一貫性を提供し、同じ時間枠で、異なるミッションセット間の取引を可能にするのに役立つ。選択した時間枠は、回答または擁護されている問題の説明/仮説に関連している必要がある。たとえば、調達の決定には、システムの初期運用能力または最終運用能力の時間枠が含まれる可能性がある。同様に、エポック技術の変更は数十年先に設定される可能性がある。特定の時間枠から、予想される脅威能力、青部隊の予想されるパフォーマンス、技術の成熟度など、他の多くのミッションの詳細を導き出すことができる。したがって、敵の能力は継続的に進化および時間とともに変化するため、シナリオには時間枠が関連付けられる。
2.2.2 ミッション上のシナリオとビネット：Mission Scenarios and Vignettes
ミッションは、戦略的から戦術的まで階層的である。ミッション・エンジニアリング（ME）の目的（purpose）のために、適切な要素（または変数）がミッション定義に含まれるように、ミッション設定の2つの広いカテゴリー、シナリオとビネットを定義する。
このシナリオは、ミッション・エンジニアリング（ME）分析の全体的な文脈を提供し、戦役計画、防衛計画作成ガイダンス、複数軍種部隊配置（MSFD）、または一連の統合作戦コンセプトから導き出すことができる。それは、作戦の地理的位置と全体的な紛争の時間枠を提供する。これには、脅威と友好的な地政学的な状況と背景、仮定、制約、制限、戦略的目標、およびその他の計画作成上の考慮事項などの情報を含める必要がある。さらに、シナリオでは、米国の作戦の全体的なミッションの目標またはミッションの成功基準を定義および説明する。
ビネットは、シナリオのより狭いフレームのサブセットを表す。1つのシナリオ内に多くのビネットが存在する可能性がある。ビネットは、シナリオの1つの側面だけを見ている虫眼鏡と考えることができる。ビネットの目的（purpose）は、特定のシステムセットのイベント、動作、相互作用の順序付けられたセットなど、分析と必要な詳細情報に焦点を当てることである。ビネットには、分析への入力または変数として、作戦環境内の青い能力と赤い脅威（脅威のレイダウンと予想されるシステムおよび敵対者の能力）が含まれている。一部のミッション・エンジニアリング（ME）分析では、戦役またはミッションレベルで回答を求める場合があるが、このレベルの分析は、研究者がビネットの詳細を理解して説明した後でのみ実行できる。
ミッションシナリオとビネットは、分析が関心のある質問と懸念に焦点を合わせていることを確認するために、問題ステートメントのニーズに一致するように適切に選択および改良する必要がある。シナリオの選択された入力パラメータは、分析結果と出力にさまざまな影響を与えるため、注意する必要がある。たとえば、「最も可能性が高く、代表的な、現実の」シナリオと「最も」または「最も少ない」ことを強調するシナリオなどである。
図2-3は、ミッション定義、シナリオ、ビネット、およびミッション指標（metrics）間の相互依存性を示している（指標（metrics）は以下のセクション2.3で定義されている）。ミッション・エンジニアリング（ME）のこれらの重要な要素の詳細が関心のある質問と一致していない場合、結果は質問が通知することを意図している決定に適していない。
図2‐3。 ミッション定義要素と特定された指標 |
2.2.3 仮定事項と制約事項：Assumptions and Constraints
ミッション・エンジニアリング（ME）研究は、検討中の問題に対処するために慎重に組み立てられる必要がある。実務者がいくつかの限られた変数を除いてすべてを制御したいという、焦点を絞ったミッション・エンジニアリング（ME）研究を実施することが適切な場合がある。研究者が具体的に知らない、または有効な情報源がない分析への入力がある場合がある。または、リソースと範囲が限られているため、分析では特定の一連の質問に限定する必要がある場合がある。実務者が仮定と制約を徹底的に文書化することは非常に重要である。
仮定と制約は、有用な結果を確実に得るために現実的かつ合理的でなければならない。初期条件とミッション文脈（作戦上の活動、タスク活動、リソース、戦闘序列（OOB）など）を設定するシナリオまたはビネットについて、または分析内の技術、システム、または能力のパフォーマンス特性について、仮定と制約を設けることができる。仮定は制約された変数であり、完全ではないデータが利用可能な場合に分析エクスカーションを実行するためのベースラインを設定するためにトレードすることができる。
ベースラインの仮定と制約を明確に特定することは、後で初期入力とその結果への影響に関する感度分析（sensitivity analysis）を容易にするのに役立つ可能性がある。たとえば、分析内では、「競合する環境」の定義は、結果を比較できるようにするために、検討中のすべてのアプローチで一貫している必要がある。このような場合、「競合する環境」は「通信が利用できない」と定義される可能性があり、各試行アプローチはこの仮定の影響を反映している。
要約すると、ミッション・エンジニアリング（ME）分析では、次のことを行う必要がある。
- 仮定、それらがどのように検証されるか、そしてそれらが分析を通じて伝播する変数にどのように変換されるかを特定して理解し、
- 考慮する必要のある制約などの制限を特定して理解し、
- 仮定と制約に関連するリスクを特定して詳しく説明し、
- ミッション定義の不確実な領域を特定して調査する。
2.2.4 ミッションの定義の要約：Mission Definition Summary
ミッションの定義は、表2-1にリストされているカテゴリーを考慮して文書化する必要がある。この表は、分析または研究の範囲を定めるために必要となる可能性のある情報および特別な考慮事項の概要として役立つはずである。
表2－1 ミッションの定義のカテゴリー
|
「戦略的」構成へのリンク |
| - 国防戦略（NDS）
- 国防計画策定ガイダンス（DPG） - 国家軍事戦略（NMS） - 国防計画策定シナリオ（DPS） （戦略的シナリオ） - 複数軍種部隊配置（MSFD） （DPSから派生した作戦シナリオ） - ミッションエリア - 戦役の目標 - 統合または軍種の作戦コンセプト（CONOPS）および戦術、技術、手順（TTP） |
| シナリオとビネットの詳細 |
| ミッション設定
- 時間枠（年） - 紛争の段階 - 利用可能な時間 - 戦域/設定 - 目標と指揮官の意図 - 地政学的考察 - 環境（争われている、ほこり、天気、地形、昼/夜、天気、月、太陽など） - 同盟部隊、商業勢力、中立勢力 - 民事上の考慮事項 脅威（赤）部隊 - 脅威/能力/インテリジェンス - ベースライン部隊と戦闘序列（OOB） - 脅威のCONOPS、交戦規定（ROE）、教義、またはTTP 青（連合を含む）はベースライン能力を強制する（関心のある時間枠で） - システム/能力/パフォーマンス - 作戦コンセプト（CONOPS）、投資収益率、教義など。 - 作戦上のタスクのベースラインフレームワーク |
| ミッションの仮定と制約 |
| - システムのパフォーマンスまたは能力
- 戦闘序列（OOB）と展開、移動、および維持を強制する（事前配置）。兵站上の考慮事項 - ミッションの構成要素と、他のミッション領域とどのように相互作用する必要があるか |
2.3 ミッション指標（成功と効果の尺度）：Mission Metrics (Measures of Success and Effectiveness)
指標（metrics）は、ミッションまたはシステムのパフォーマンスを評価、比較、および追跡するために一般的に使用される定量的評価の尺度である。測定可能な出力は、指揮官が何が機能しているか、何が機能していないかを判断し、ミッションをより適切に達成する方法についての洞察を提供するのに役立つ。ミッション・エンジニアリング（ME）の実務者は、ミッションを可能にする活動のコンポーネントの完全性と有効性を評価するために使用できる、確立された一連の指標（metrics）を特定する必要がある。ミッション指標（metrics）は、ミッションを実施する際の代替アプローチのそれぞれを評価するために使用される基準を表す。
分析文書では、成功の尺度、適合性の尺度、有用性の尺度、有効性の尺度、有効性の尺度（MOE）、パフォーマンスの尺度（MOP）など、ミッションの指標を指すためにいくつかの同様の用語を使用している。用語を単純化するために、このガイドでは2つの広いカテゴリーの測定値を使用する。有効性の尺度（MOE）は、ミッション全体で成功するための測定可能な属性と目標値を示す。ミッションの実行に使用される個々のシステムのパフォーマンス特性を示すパフォーマンスの尺度（MOP）。図2-4は、メジャーのタイプ間の関係を示している。
図2－4 指標の関係図 |
ミッションの有効性は、望ましい結果または効果を生み出す実力（ability）であり、有効性の尺度（MOE）の形式の基準を通じて測定される有効性の尺度（MOE）は、タスクが意図した結果を達成しているかどうかを判断するのに役立つ。有効性の尺度（MOE）は、システムの振舞い、能力、または作戦環境の変化を評価するために使用される基準であり、最終状態の達成、目標の達成、または効果の作成の測定に関連付けられている。
有効性の尺度（MOE）は、「資本アセットを失うことなく達成する」など、プラスとマイナスの両方の条件の変化を測定するのに役立つ。有効性の尺度（MOE）は、「システムは正しいことを行っているか？」という質問に答えるのに役立つ。「安全で安心な環境を提供する」ことを目標とした有効性の尺度（MOE）の例としては、（1）反乱軍の活動の減少、（2）ホスト国の治安部隊の人口信頼の増加などがある。
パフォーマンスの尺度（MOP）は、システムタスクの達成度を測定するのに役立つ。彼らは「行動はとられたか？」などの質問に答える。または「システムは正しく動作しているか？」 パフォーマンスの尺度（MOP）については、ミッション・スレッド（MT）またはミッション・エンジニアリング・スレッド（MET）で採用されているシステムに関連して説明する。これについては、以下の2.4.1項で詳しく説明する。
このガイドでは、有効性の尺度（MOE）はパフォーマンスの尺度（MOP）に貢献する機能と見なされる表2-2に、ミッション・エンジニアリング（ME）分析で使用できる有効性の尺度（MOE）とパフォーマンスの尺度（MOP）の例を示す。図2-5に、階層関係の例を示す。表2－2：有効性の尺度（MOE）とパフォーマンスの尺度（MOP）の例
| 有効性の尺度（MOE）は、ミッションの目標（指揮官の意図）に関連する望ましい測定可能な結果を定義する。例： |
| · 影響を受けたターゲットの数/パーセンテージ（殺された/混乱した/なりすまし）：到達目標（goal）70％
· 殺害の確率 · 危険にさらされているターゲット · ターゲットを倒す時間：90分未満の到達目標 · ターゲットを倒すために必要な兵器：4未満の到達目標 · 失われたアセット：目標の最小化、10％未満 · 破壊されたターゲットあたりの作戦上のコスト：目標$ 100,000 /ターゲット · 次の紛争の姿勢：目標を最大化し、部隊の50％が紛争前の配置から移動する必要がなかった |
| パフォーマンスの尺度（MOP）は、ミッションがどの程度達成されているかを測定する。例： |
| · 追跡する確率
· IDの確率 · 範囲 · 兵器の精度 · おそらく検出を避けるため |
図2-5．階層化した有効性の尺度（MOE）とパフォーマンスの尺度（MOP）の例 |
2.3.1 有効性の尺度の選択：Selecting Measures of Effectiveness
ミッション定義のシナリオまたはビネットの全体的な目標から始めて、関係者の関心のある質問に答えるために、ミッション有効性の尺度（MOE）を詳細に定義する必要がある。指標は、分析のレベル（つまり、戦役レベルまたはミッションレベル）によって異なる。
有効性の尺度（MOE）が有用であるためには、それらは定量化可能で関連性のあるものでなければならない。ミッション・エンジニアリング（ME）の重要な信条は、ミッションの実施における代替アプローチの有効性を定量化することである。そのため、有効性の尺度（MOE）は指揮官の意図と目標を反映し、分析または研究の質問に答えるための測定可能な基準を含める必要がある。たとえば、指揮官のミッションの目標は、トラックの護送船団を無効にすることであり、その目標から導き出される定量化可能な尺度は、破壊されたトラックの数または1台のトラックの撃破/殺傷の確率である可能性がある。
有効性の尺度（MOE）は、成功または好ましい結果（しきい値または客観的）の目標値を示す必要がある。可能な場合は常に、到達目標（goal）に対して範囲または特定の値を設定する必要がある。定量化可能性に対処する際、有効性の尺度（MOE）は、「勝ち」タイプの尺度（最大化される指標（metrics））、「損失」タイプの尺度（最小化または回避される指標（metrics））、および比率（2つの値または指標（metrics）の比較）に対処する必要がある。
有効性の尺度（MOE）が関連するためには、分析対象のミッションに明確にリンクしている必要がある。有効性の尺度（MOE）は、2つの主な要因に基づいている。（1）ミッションの目標（つまり、指揮官の意図）を表すミッション定義を介した問題ステートメントからのトップダウンの導出と（2）構成要素のアプローチを特徴付けるボトムアップの説明と ミッション（赤、青、アーキテクチャなど）を実行するために提案されたシステム、およびモデリングと分析の関連する可用性。
有効性の尺度（MOE）は、ミッションの目標を達成するためにシステム、システムのシステム、または能力がどのように使用されるかを適切に反映するために、パフォーマンスの尺度（MOP）と密接にリンクされている。図2-6に示すように、関連する有効性の尺度（MOE）の開発は、関心のレベルに一致するようにトップダウン入力とボトムアップ入力の、入力のバランスをとる必要がある反復プロセスである。
図2－6. 尺度の継承 |
有効性の尺度（MOE）は各シナリオまたはビネットに固有であるが、有効性の尺度（MOE）のいくつかの普遍的なカテゴリーを考慮することができる。
- ミッションの満足度–最終目標の達成
- 損失–敵の行動に対する装備品、人員の損失
- 支出–作戦中に消耗した消耗品。たとえば、メッセージを中継したり、ターゲットを破棄したりするために使用されたアセットの数。
- コスト（ドル）–a．作戦上の代替案で使用されるシステム/技術/コンセプトの開発コスト、b．作戦コスト
- 時間–作戦のミッションの期間
- 繰り返し–許容可能なミッション満足度を達成するためのミッションパスの数
- 準備–容易に交戦する部隊の態勢
- 不確実性–上記の尺度の不確実性
- ミッションの投資収益率（ROI）–ある指標（metrics）/尺度（measure）と別の指標（metrics）/尺度（measure）の比率。ミッション投資収益率（ROI）は、1つ以上の異なる有効性の尺度（MOE）の成功を達成するための効率を評価する。たとえば、破壊されたターゲットの数と消費されたアセットの数などである。投資収益率（ROI）比は、使用される兵器の種類と数、およびそれぞれの（償却された）コストに基づいて費用便益効果を解決するのに特に役立つ。ミッション・エンジニアリング（ME）分析を実施する主な目的（purpose）は、計画作成、プログラミング、および予算編成の実行（PPBE）プロセスに通知することである。コストタイプの投資収益率（ROI）は、装備または非装備ソリューションとして、調達または技術投資の決定を通知するのに役立つ。
2.3.2 指標の追跡可能性：Traceability of Metrics
代替アプローチのそれぞれが開発されるにつれて、指標（metrics）が繰り返し進化するのは自然なことである。有用な尺度は、回答する質問、ミッション（つまり、目標）、および評価中の活動、タスク、およびシステムを理解した場合にのみ出現する。ミッション・エンジニアリング（ME）では、回答する質問は問題ステートメントに含まれている。ただし、最初にミッション定義から抽出された評価中の要素は、分析をデザインし（パラグラフ2.4）、代替（または試行）ミッション・アプローチ（またはミッション・スレッド（MT）またはミッション・エンジニアリング・スレッド（MET）（で定義されている）を開発するときに、さらに拡張および検証できる。セクション2.4.2））評価する。
代替アプローチ（さまざまなシステム）のそれぞれが開発および改良されると、有効性の尺度（MOE）を再検討して、選択され尺度が研究の質問に答えるのに適切であることを確認できる。全体的なミッションの目標にとって重要な活動、タスク、およびシステム内の潜在的な取引を明らかにするための尺度を選択する必要がある。図2-7は、ミッション・スレッド（MT）およびミッション・エンジニアリング・スレッド（MET）（つまり、タスクから機能（function）、システム）への指標（metrics）（つまり、有効性の尺度（MOE）およびパフォーマンスの尺度（MOP））の系統を示している。このバランスにより、分析で適切な有効性の尺度（MOE）が使用されていることが保証される（上記のセクション2.3.1で詳細に説明されている）。
図2-7．ミッション・エンジニアリング・スレッドと関連する有効性の尺度（MOE）とパフォーマンスの尺度（MOP）の例 |
2.4 分析のデザイン：Design of Analysis
最も単純な形式では、ミッション・エンジニアリング（ME）分析は、作戦環境、脅威、活動/タスク、および現在（現在）または将来のミッションで使用される能力/システム間の相互作用を調べることによってミッションを評価する。ミッション・アーキテクチャは、ミッションの実施の詳細な構造を表している。すべての場合において、アーキテクチャは、他の要素、活動、脅威、および全体的な状況の文脈に関連して、すべてのミッション要素を完全に文書化する手段である。
分析とミッション・アーキテクチャのための信頼できるデータを取得することは不可欠であり、ミッション定義（つまり、作戦環境、脅威のレイダウン、赤の特性評価など）からの情報と、評価する主な関心のある青部隊の能力を含める必要がある。回答する質問にリンクされている。図2-7に示すように、青い活動/タスクのエンド・ツー・エンドのシーケンスは、ミッション・スレッド（MT）を介して表すことができる。
レベルを分解して、エンド・ツー・エンドのミッションを実行するための関連するシステムや能力を含めると、ミッション・スレッド（MT）はミッション・エンジニアリング・スレッド（MET）と呼ばれ、描かれる。これらの活動/タスクおよびシステム/能力は、実行および試行を通じて代替アプローチを開発するために変更できる。さらに、ミッション・スレッド（MT）とミッション・エンジニアリング・スレッド（MET）が特定され、十分なデータが収集されると、適切な分析が実行されて結果が取得および文書化され、問題に答えるための結論が導き出されるミッション・エンジニアリング（ME）の目的（purpose）では、このプロセスは「分析のデザイン」と呼ばれる。
2.4.1 ミッションのアーキテクチャ：Mission Architectures
ミッション・アーキテクチャは、ミッションを実施するための「ビジネスモデル」と見なすことができる。そのため、選択したアーキテクチャは、シナリオ、部隊の展開、および戦役のレベルで、ミッションのより大きな構成に収まる必要がある。各アプローチについて、「現状」および仮想の「将来」のスレッドは、ミッション要素のアーキテクチャ用語（単に「ビュー」と呼ばれる）（作戦上のビュー、システム・ビュー、および/または技術ビュー）で記述でき、 ミッション構成の各主要要素間の通信層とノードのリンク。
ビューとそれらの関係を系統的に描写することで、必要なデータ、追加の仮定と制約、および分析に適したモデルを特定できる。このように、ミッション・アーキテクチャは、シナリオの制約内で作戦、システム、およびデータフローを定義するための徹底的かつ系統的な方法を提供する。図2-8に示すように、選択されたミッション・アーキテクチャは、ミッションの実施の詳細な構造を示している。これには、アセット、組織、機能（functions）、相互作用、およびミッション運用アプローチの順序付けに関する一連の相互依存するビューを含める必要がある。
ミッション・アーキテクチャは、システムのコンセプト、アプローチ、およびシステムのコンセプトモデリングであり、プロセスフロー、タイミング、相互作用、データ、能力、およびパフォーマンスの詳細を、ミッションの目標を達成するために貢献する他のプロセス、エンティティ、およびシステムとの関連で調べることができる。これにより、部門全体で組織化された情報共有が可能になる。 ミッション・アーキテクチャは、多くの同時プロセスとエンティティのキャンペーン全体に対処することも、1つのエンティティとフローのみに焦点を絞ることもできる。 ミッション・アーキテクチャは、特定の詳細を説明/強調するための一連の「ビュー」で表される。たとえば、一般的な図は、装備品と人員の全体的な意図された軍事作戦を示す作戦上の外観図である。もう1つのビューは、これらの作戦を実行するための各タスクと活動のシーケンスフローである。もう1つは、これらのタスクと活動を有効にしてトリガーするための情報交換の概略図である。 図2-8。ミッション・アーキテクチャの信条 |
2.4.2 ミッション・スレッドとミッション・エンジニアリング・スレッドを定義する：Define Mission Thread and Mission Engineering Thread
ミッション・アーキテクチャのサブ要素はミッション・スレッド（MT）であり、シナリオまたはビネット内でミッションを達成するためのエンド・ツー・エンドのタスクまたは活動で構成される単に「ミッション・アプローチ」と呼ぶことができる。これには、定義された目標を満たすためにミッションを実行または実行するために実行されるタスクが含まれる。スレッドは、システム、人、データ、メソッド、戦術、タイミング、およびインターフェイスが相互作用して、脅威やその他の変数に対して必要なタスクを完了し、ミッションの目標を達成する一連のイベントでタスク実行シーケンスを定義する。このエンド・ツー・エンドのミッション構成の例は、キルチェーン（キネティック）またはエフェクトチェーン（非キネティック）である。シナリオまたはビネット内でミッションを実行するために、時間の経過とともに複数のミッション・スレッド（MT）がリンクされる場合がある。図2-9は、選択したミッション・スレッド（MT）をミッション・エンジニアリング・スレッド（MET）開発の構成要素と見なす方法を示している。
図2-9．ミッション・スレッドのアーキテクチャ |
特定のシステム、技術、または人に関連する詳細が追加されると、汎用ミッション・スレッド（MT）はミッション・エンジニアリング・スレッド（MET）になる。統合参謀本部の計画作成文書には、ユニバーサル・ジョイント・タスク・リスト（UJTL）の計画作成の構成として事前定義された汎用ミッション・スレッド（MT）があるため、ミッション・スレッド（MT）とミッション・エンジニアリング・スレッド（MET）のこの区別は重要である。ミッション・エンジニアリング（ME）分析に役立つためには、ミッション・スレッド（MT）からミッション・エンジニアリング・スレッド（MET）への分解、およびシステムを機能（functions）にマッピングする下位層が必要である。
ミッション・アプローチは、研究中の変数を特徴づけ、定義するナラティブ（narrative）の説明とアーキテクチャ成果物（artifacts）（ビュー）で構築する必要がある。これには、現在の作戦の実行方法と、仮想的または将来の代替アプローチが含まれる。分析で調査する対象の変数を特定することが重要である。これは、問題の説明とミッションの定義から導き出すことができる。変数が特定されたら、1つまたは複数の変数を変更して、ミッションの出力への影響を観察および調査することを選択できる。
変更できる変数は、ミッション・スレッド（MT）またはミッション・エンジニアリング・スレッド（MET）内のタスク、能力、技術、またはシステムのいずれかである。そうすることで、入力変数が出力にどのように影響し、変化するかを調べることができる（ミッションの成功）。理想的には、ミッションの実行に関与する最も重要な関心のある変数を特定して、何が機能するかを判断する。分析には、関心のある質問に答えるのに役立つ指標（metrics）を出力するアプローチを含める必要がある。問題の説明は、ミッション、シナリオ、および/またはビネット（ミッションの特性評価）の具体的な詳細とともに、「代替」アプローチ全体で変化する入力（つまり、タスクおよび/またはシステム）を推進する。代替ミッション・アプローチは、能力、技術、戦術、システム、ドクトリン、組織、訓練、装備、リーダーシップと教育、人事、施設（DOTMLPF）、および評価されるコンセプトの特定の取引によって推進されるこれは、最終的な到達目標（goal）である「ミッションをより適切に達成して実行するにはどうすればよいか」につながるのに役立つ。
一般に「As-Is」のミッション・アプローチとして定義される「ベースライン」ミッション・アプローチは、特定のシナリオ内でミッションを実行する方法に関する現在の考え方を表し、分析と評価の基準点を提供する。変数（つまり、システム、パフォーマンス、戦術など）を変更すると、評価対象の代替アプローチである潜在的な「To-Be」ミッション・アプローチと呼ばれる代替アプローチにつながる。これらの変更にはまったく新しいミッション定義が必要になるため、環境、脅威、またはシナリオの変更は考慮されない。代替案が評価および分析されると、ミッション・エンジニアリング（ME）実務者は、「優先」アプローチと呼ばれる、より「最適な」アプローチを特定できる。これは、将来の分析のための新しい参照を形成できる。
注：「As-Is」という用語は、必ずしも現在の運用を意味するものではない。これは、分析を開始するための単なるベースラインである。
2.4.3 サポートするモデル、データ、分析を定義して収集する：Define and Gather Supporting Models, Data, and Analytics
ミッション・エンジニアリング（ME）は、ミッションを実行するための作戦的および技術的手段の表現を支援する分析および計算ベースのモデルの使用によって促進されるモデルを使用すると、ミッション・エンジニアリング（ME）の実務者間で分析構造の一貫性と再利用が可能になる。重要なのは、ミッション・エンジニアリング（ME）の実務者は、データ要素、仮設の実現、および仮定が信頼できるソースへの追跡可能性でキャプチャおよびアーカイブされるように、採用するモデルを厳選する、または管理するように注意する必要がある。
モデルは、コンセプトから廃棄まで、データの追跡可能性を含むように構築する必要がある。国防総省（DoD）モデリングおよびシミュレーション標準に従って、関連するすべてのリスクを理解するために、実務者は、研究用に開発されたモデルが、検証、妥当性確認、および認定プロセスを受けて、分析の特定の意図した使用をサポートすることを指定するように注意する必要がある。
モデルは、従来のシミュレーションであるだけでなく、数学的表現、論理式、コンセプト的なプロセスステップ、またはこれらの要素の1つまたはすべての組み合わせも含まれる。たとえば、モデルまたは表現を使用して、システムがさまざまな条件下またはさまざまな環境でどのように実行または存続するか、またはシステムが相互作用してミッションを実行する方法を予測できる。モデルは、さまざまな分析と研究（たとえば、貿易スペース、感度、ギャップ、または軍事ユーティリティ分析）をサポートするための有用な視覚化を提供する。
図2-10は、ミッション・エンジニアリング（ME）の一部として開発、収集、統合、および使用されるモデルのタイプの例を表している。
図2-10。ミッション・エンジニアリングで使用するモデルの例 ミッション・エンジニアリング（ME）をサポートするデジタルモデルは、データの表現と分析に最も適したアプローチのタイプ（つまり、物理ベースのモンテカルロ）によって駆動される |
モデルは、忠実度（fidelity）のレベル（つまり、「現実性（realism）」）とそれに関連する不確実性が異なる。ミッション・エンジニアリング（ME）分析では、分析の質問に答え、各研究の時間、コスト、および不確実性のバランスを取るために、どのモデルをまとめるべきかを決定する必要がある。ミッション・エンジニアリング（ME）の利害関係者は、分析と結果として生じる意思決定プロセスへの影響を適切に判断するために、選択したモデルの基礎となる忠実度（fidelity）と信頼性（confidence）を理解して明確にする必要がある。
モデルは非常に複雑になる可能性があり、その結果、入力と出力の関係が十分に理解されていない可能性がある。このような場合、モデルはブラックボックスと見なすことができる。つまり、出力は入力の「不透明な」関数である。多くの場合、モデル入力の一部またはすべては、測定のエラー、情報の欠如、推進力とメカニズムの不十分または部分的な理解など、不確実性の原因になる。この不確実性は、モデルの応答または出力の信頼性（confidence）に制限を課す。不確実性を最小限に抑えるために分析が必要である（以下の分析セクション2.5.1で説明）。
モデルの開発、統合、使用、分析、およびキュレーションは、ミッション・エンジニアリング（ME）活動のコア要素である。セクション2.2で説明されているように、ミッション・エンジニアリング（ME）プロセスは、問題の説明/分析の質問から始まる。ミッション・エンジニアリング（ME）プロセスの初期段階では、デジタルエコシステム内にすでに存在するモデル、データ、およびツールを特定することが不可欠である。研究を開始する前の追加の考慮事項は次のとおりである。
- この研究にはどのドメイン（大気、地表、地下、宇宙、サイバーなど）が関係しているか？
- 問題の説明/分析の質問に適切に対応するために、モデルにどの程度の忠実度（fidelity）が必要か？
- 分析を行うにはどのようなモデルが必要か？ （例：6-DOF、物理ベース）
- どのモデルがすでにアクセス可能か？ 必要なモデルはすでに存在するか？
- モデルの系図（pedigree）は何か（検証、妥当性確認、認定など）？ 使用するのに適切なモデルを作成したか？
これらの質問への回答は、追加のモデル、データ、ツール、他のデジタルエコシステムへのアクセス、およびミッション・エンジニアリング（ME）デジタルエコシステムの更新の要求を引き金にする。ミッション・エンジニアリング（ME）プロセスのモデルを選択するときは、モデルが現実を表現していることを覚えておくことが重要である。ミッション・エンジニアリング（ME）の場合、現実は実際のシステムまたはコンセプト的なシステムである場合もあれば、システムが参加する作戦シナリオである場合もある。
ミッション・エンジニアリング（ME）活動は、デジタルエコシステム内で実行されるデジタルエコシステムの内容は次のとおりである。
- サイバー対応環境に以下を含める：
o十分なコンピュータパワー。必要に応じて、ハイパフォーマンスコンピューティングへのアクセス
o多層セキュリティ; 秘密区分なし、秘密、および/または秘密以上の作業スペース
o構成可能/適応可能なソフトウェアフレームワーク
- モデルとデータへのアクセスに以下を含める：
o分析または計算分析に必要なツールまたはソフトウェアアプリケーション
o技術データ（システムパフォーマンス、テスト結果など）
- ミッション・エンジニアリング（ME）プロセスを管理するためのハードウェアおよびソフトウェアインフラストラクチャ
2.5 分析の実行/モデルの実行：Perform Analysis/Run Models
ミッション・エンジニアリング（ME）分析には、データとモデルを使用した分析および計算手段による、ビネット、ビネット内のミッション・スレッド、またはビネット/スレッド全体のコンセプトの評価が含まれる。最も有利なタイプの分析の選択は、問題の説明、ミッション・エンジニアリング・スレッド（MET）、および対象の指標（metrics）によって決まる。出力は、ミッション能力のギャップを特定し、将来の戦いと戦うための新しい能力または新しい方法で投資決定を通知するための指標（metrics）を提供する。図2-11（図2-1の抜粋）は、ミッション・エンジニアリング（ME）の分析デザインに関する方法論を示している。
図2-11。ミッション・エンジニアリング分析 ミッション・エンジニアリング（ME）分析を実施するには、ミッションとシステムを表現およびモデル化するための適切で信頼できる（検証済みの）データが必要である。 |
以下は、ミッション・エンジニアリング（ME）の実務者が、研究に最も適切な分析を特定して実施する際に考慮すべき項目である。
- 実行する必要のある感度分析（sensitivity analysis）を特定する。入力に影響を与えるベースラインの仮定と、それらが出力にどのように影響するかについての感度を理解する。
- 仮定または入力の周りで最適化および/またはパラメータ化を実行する必要があるかどうかに対処する。
- 最も適切な分析方法を決定する。例としては、シミュレーションツール、モンテカルロ分析、マルコフ連鎖、回帰分析、費用便益分析などがある（図2-12）。
- モデルのシステム全体でのエラーと不確定性の伝播を特定して理解する。
o分析および分析結果で使用されるデータのエラー/信頼水準（confidence-level）を追跡および測定する。データとモデルの忠実度（fidelity）を理解する
o仮定、近似、使用されたモデル、忠実度（fidelity）などを理解する。
図2-12。例–分析の類型 回答する質問と必要な指標（metrics）または出力に応じて、さまざまな分析を使用できる。たとえば、最適化分析を使用して、特定の制約の下で1つ以上のターゲット変数の最適値を見つけることができる。 |
分析のすべてのレベルのさまざまな指標（metrics）に対して、エラーの伝播と結果の信頼度（levels of confidence）を追跡することが重要である。モデルの忠実度（fidelities）が異なるため、または異なるタイプのモデル（たとえば、パラメトリック (parametric)と統計）を使用するため、分析作業でエラーと不確実性が発生する可能性がある。ミッション・エンジニアリング（ME）研究チームにとって最も重要なタスクの中には、モデル間の関係、モデルを開発するための入力データ（つまり、ソース）、および分析全体でのエラーの伝播を理解して、チームが出力/結果の信頼水準（confidence-level）を適切に定義できるようにすることがある。
場合によっては、統計分析は、実務者が入力と出力の間の相関関係を決定するために使用できるツールである。統計的有意性のしきい値を決定する方法はいくつかある（たとえば、p値の使用）。しきい値は主観的なものかもしれないが、「一般的に受け入れられている」値がある（たとえば、0.05のp値または結果が偶然によるものである確率は5％）。
結果の信頼水準（confidence-level）を決定する別の方法は、主要なベースラインの仮定に対して感度分析（sensitivity analysis）を実行することである。実務者は、感度分析（sensitivity analysis）を採用して、入力変数のさまざまな値が特定の一連の仮定の下で特定の出力変数にどのように影響するかを判断し、ミッションの有効性の尺度（MOE）または成功の尺度（MOS）への影響を特定することを検討する必要がある。感度分析（sensitivity analysis）は、不確実性が存在する場合のモデルまたは方程式の結果の堅牢性（robustness）をテストし、入力変数と出力変数の間の1次または2次の関係を明らかにする。
モデルのシステムを実行するのではなく、パラメトリック (parametric)な手段で適切な感度分析（sensitivity analysis）を実行できる場合がある。（ケーススタディのように）境界ケースデータを使用して分析を推進することで、特定の分析条件のソリューション空間への洞察を得ることができる。方法論に関係なく、適切にデザインされた感度分析（sensitivity analysis）は、結果の忠実度（fidelity）への洞察を提供する。結果の信頼度（level of confidence）を特定することは、重要な決定を行う際にリーダーシップが特定の野外調査（excursion）または研究の結果を他の要因と比較検討するのに役立つミッション・エンジニアリング（ME）研究の重要な成果である。
2.6 研究と結論を文書化する：Document the Study and Conclusions
はじめにで述べたように、ミッション・エンジニアリング（ME）分析の主な成果（products）は次のとおりである。
- 分析レポートと意思決定ブリーフィングに文書化された結果、
- 参照または推奨されるミッション・アーキテクチャ、および
- 再利用のために厳選されたデータモデル（参照アーキテクチャから派生）。
これらのミッション・エンジニアリング（ME）成果（product）と成果物（artifacts）は、ミッション能力のギャップを特定して定量化し、将来のミッションのニーズを満たすための技術ソリューションに注意を集中するのに役立つ。要件、プロトタイプ、および取得を通知する。能力ポートフォリオ管理をサポートする。これらは、ミッションの成功に不可欠なシステム・オブ・システムズ（SoS）の関係属性を説明するのに役立つ。
分析の成果（product）が、尋ねられた元の質問と一致し、追加の作業または後続の分析の必要性を強調することが重要である。原則として、出力は、研究分析とデータ出力から結論を導き出し、観察された傾向と影響について議論し、結果から作成できる関係または相関について議論する必要がある。そのため、以下のサブセクションで詳細に説明するこれらの出力は、技術成熟計画、投資戦略、および用兵能力（warfighting capability）のギャップを埋めるための好ましい装備ソリューションについて国防総省（DoD）リーダーに通知するための基礎を形成する。
2.6.1 分析レポート/決定ブリーフィング：Analysis Report / Decisional Briefings
最終的な分析レポートおよび関連する決定的ブリーフィング資料では、研究の開始時に利害関係者によって定義された分析の全体的な目的（purpose）について説明する必要がある。レポートには、事前の計画作成（問題、ミッション定義、シナリオとビネット、ミッション・スレッド（MT） / ミッション・エンジニアリング・スレッド（MET）、指標（metrics）、分析のデザイン、および出力）を含め、分析フレームワーク、仮定、および実行に影響を与えた、または推進したものについて説明する必要がある。付録AおよびB（政府参照アーキテクチャ）は、推奨される詳細レベルを提供する。
レポートは次のことを実行する必要がある。
- 質問とミッションを定義する
- ミッション成功の指標を定義する–これには有効性の尺度（MOE）を含めることができる
- 脅威と作戦環境および情報源を特定する
- 隣接するミッションに対するミッション・アーキテクチャの依存関係と影響を特定する
- ミッション、技術、または能力に関する重要な前提条件を特定する
- 分析方法論を説明する
- アーキテクチャ成果（product）について説明する
- 分析から得られた結果を説明する
- 結果の問題や不確実性を特定する
- 結果が問題の説明にどのように適用されるかについて議論する
- 分析からの結論を説明する
- リーダーシップまたは意思決定者が取るべき行動を推奨する
- さらなる分析または次のステップを推奨する
2.6.2 参照アーキテクチャ：Reference Architecture
参照アーキテクチャ（RA）は、分析の結果として得られる好ましいミッション・アーキテクチャを示し、ミッションの定義、仮定、制約、方法論、信頼度（level of confidence）、不確実性、および結果を明確に伝えるためのその他の分析上の正当性について説明する。修飾語の「参照（reference）」は、分析の結果に基づいて、優先される1つの特定のアーキテクチャを強調するものである。参照アーキテクチャ（RA）とその正当化分析は、一体化された成果（product）と見なされ、ミッションの相互依存ビューで構成される1つ以上のミッション・スレッド（MT） / ミッション・エンジニアリング・スレッド（MET）の分析から発展する必要がある。アーキテクチャを使用すると、多くのミッション内およびミッション間でミッションの要素と属性を明示的に比較および対比する方法が提供されるたとえば、将来の技術をミッション全体で評価して、それらが提供する価値を明らかにし、投資の優先順位に関する決定を通知することができる。
政府が参照アーキテクチャ（RA）の所有権を維持している場合、これはさらに参照アーキテクチャ（RA）を政府参照アーキテクチャ（GRA）として指定する。ミッション・エンジニアリング（ME）では、他に2つのアーキテクチャ用語を定義する必要がある。
- 政府ミッション参照アーキテクチャ（Government Mission Reference Architecture ：GMRA）：単一のエンド・ツー・エンドミッションに適用可能。ミッション・エンジニアリング・スレッド（MET）を説明する優先または選択されたアーキテクチャ。
- 政府能力参照アーキテクチャ（Government Capability Reference Architecture GCRA）：複数のミッション・スレッドに適用可能で、複数のミッション・エンジニアリング・スレッド（MET）にまたがる共通の能力（機能（functions）またはタスク）と属性を最適化する。有効化能力にさらに焦点を絞る（たとえば、通信ネットワークを最適化して多くのミッション・エンジニアリング・スレッド（MET）を有効化しようとする）。
図2-13は、政府ミッション参照アーキテクチャ（GMRA）と政府能力参照アーキテクチャ（GCRA）の間のミッション・エンジニアリング・スレッド（MET）の関係を示している。付録AとBは、各GRAの内容と適用可能性を定義している。
図2-13。ミッション・スレッドと能力の一体化とトレード 政府の参照アーキテクチャは、ミッションの目標を達成するために必要な能力を示す結果を伝えるために使用されるリンクされた「分野横断的（cross-cutting）」アーキテクチャには、「能力」と「ミッション」の2種類の参照アーキテクチャがある。 |
2.6.3 厳選されたデータ、モデル、およびアーキテクチャ：Curated Data, Models, and Architectures
分析が開発および完了したら、データ、モデル、およびアーキテクチャを適切に収集および編成して、将来の分析のために保存、共有、および発見する必要がある。ミッション・エンジニアリング（ME）の目的（purpose）では、「データ」という用語は、シナリオまたはビネット、戦闘序列（OOB）、部隊の構造、システムパラメータまたはパフォーマンス、脅威、モデル、および分析結果に関連する情報を意味する。データは、モデル、ミッション・スレッド（MT） / ミッション・エンジニアリング・スレッド（MET）、および政府参照アーキテクチャ（GRA）の背後にある「ビルディングブロック」と「バックボーン」である。
データの価値が長期にわたって維持され、データが再利用および保存できるようにデータを厳選することは、各ミッション・エンジニアリング（ME）実務者の責任である。データキュレーションが不十分またはまったくないリスクには、事実上不正確な情報、不正確なガイドライン、知識のギャップなどがある。技術または能力のデザインと開発が成熟し、システムが演習と実験でテストおよび評価されると、システムのパフォーマンスと能力開発の取り組みをより信頼できる形で表す貴重なデータが収集されるミッション・エンジニアリング（ME）の実務者は、このデータを使用して分析をやり直したり繰り返したりして、開発された技術または能力がミッション目標（有効性の尺度（MOE））にプラスまたはマイナスの影響を与えるかどうか、ミッション能力を本当に閉じるかどうかを識別する「フィードバック」メカニズムがあることを確認する必要がある。ギャップ、またはそれが分析で使用されるミッション・アーキテクチャまたは仮定を変更する場合。このフィードバックにより、ミッション・エンジニアリング（ME）は、より信頼性の高い結果を出力する反復可能なプロセスになることができる。
当初、データのキュレーションと標準化は、即時の再利用の質問に答える際の即時の同僚のアナリストとのコラボレーションに基づいている。次の分析を最も容易にするために、データと結果にどのようにラベルを付けて整理する必要があるか？ ミッション・エンジニアリング（ME）が進化するにつれて、軍種横断のワーキンググループ、国防総省内部部局（OSD）、および統合参謀本部は、より厳格なガイドラインを公開する。いくつかの一般的なルールとベストプラクティスが適用されるが、データキュレーターは、どのデータアセットを使用するのが適切かについて、知識に基づいた決定を下す必要がある。使用または生成されるすべてのデータについて、少なくとも次の点に対処する必要がある。
- 適時性（Timeliness）：データが最後に更新されたのはいつか？
- 系統（Lineage）：データはどこから来たのか？ ソース？
- 妥当性（Validity）：データの品質にどの程度自信があるか？
- 精度（Accuracy）：データは完全であり、合意された定義とどのように一致するか？
- リンケージ（Linkage）：データはどのように生成、変換、または収集されたか？ ミッション・エンジニアリング（ME）の使用に関連付けられていたか？
- プロファイル（Profile）：後で取得するためにデータをどのようにカタログ化するか？それは他のどのミッション・エンジニアリング（ME）データに局所的に関連付けられているか？
付録A：政府ミッション参照アーキテクチャ（GMRA）（テンプレート）=Appendix A: Government Mission Reference Architecture (GMRA) (Template)
目的：Purpose
政府ミッション参照アーキテクチャ（GMRA）を使用して、作戦的ミッションまたは戦術的ミッションを実行するために必要なシステムのシステムをガイドおよび制約する必要がある。
定義：Definitions
ミッション：特定の作戦環境で達成される一連の目標と到達目標（goal）。例としては、時間に敏感な目標、近接航空支援、敵の防空の抑制、空中給油、潜水艦戦などがある。
アーキテクチャ：コンポーネントの統一または一貫した形式または構造、およびいずれかの関係。単に描写またはビュー。
ミッション・スレッド：「ミッション・アーキテクチャ」と同義であり、エンド・ツー・エンドのミッションを実行するための活動またはシステムの一貫した形式または構造である。ミッション・スレッドまたはミッション・アーキテクチャは、コンポーネントとタスク、およびそれらの関係を示す。
政府参照アーキテクチャ：複数のミッション・アーキテクチャとソリューションのインスタンス化をガイドおよび制約する、特定のサブジェクト領域に関する政府所有の信頼できる情報源。
概観：Outline
要旨：Executive Summary
- ミッションのタイトルを含める。
- シナリオを含めるためのミッションの簡単な概要、ミッション要件の起源とサポート参照文書、提案されたミッション・アーキテクチャの説明、主要な仮定、およびそれらの仮定に関する感度分析（sensitivity analysis）を含める。
- 実装の潜在的な次のステップの概要を説明する。
- 所有者／構成管理者を特定する。政府ミッション参照アーキテクチャ（GMRA）の更新を推進する可能性のある更新サイクルと決定ポイント/イベントについて議論する。
ミッションの定義Mission Definition：
- ミッションの説明
oミッションの目標を定義する
o全体の作戦コンセプトとその運用を説明する
o必要に応じて、時間枠、ドメイン、戦域、またはその他の詳細を含める
oシナリオを説明する
oミッション・スレッドおよび/またはミッション・エンジニアリング・スレッドを特定する
・活動/タスクおよび/またはシステムを含める
- ミッションの利害関係者を特定する。
例：各軍種、各機関、ミッションの一部である同盟国。ミッションによっては、他の不可欠な非伝統的な組織が存在する可能性がある
- 有効性の尺度（MOE）を含む、ミッションの成功の指標を定義する。
- 統合作戦の関連する家族のコンセプトまたは指揮官の意図（該当する場合）を特定する。
oミッションを定義するために使用されている統合作戦コンセプト（JWC）などの特定のコンセプトを一覧表示する
基本的な仮定と依存関係：Foundational Assumptions and Dependencies
- 脅威と作戦環境および情報源を特定する。
- 隣接するミッション（政府ミッション参照アーキテクチャ（GMRA））に対するミッション・アーキテクチャの依存関係と影響を特定する。
- ミッション、技術、または能力に関する重要な前提条件を特定する。
o研究チームがこれらの仮定をどのように決定したか、そしてなぜそれらが現実的/合理的であるかを説明する
- 該当する場合は、変数を使用して仮定を説明する
分析方法論：Analytical Methodology
- メソッドのタイプ（パラメトリック (parametric)、確率論、物理学ベース、対象分野の専門家、卓上など）を含め、使用された分析および計算ツールについて説明する。
- 使用したモデルを説明し、系図（pedigree）と忠実度（fidelity）を特定する。
- 収集され、モデルにデータを取り込むために使用されるデータを特定し、ソースを含める。
- モデリング環境全体にわたる一体化された不確実性と、回答の精度/精度への影響について説明する。。
- トレードスペース分析の定義–どのパラメータまたは変数が一定に保たれ、どのパラメータまたは変数が変更されたか。
- ベースラインの仮定に関する感度分析（sensitivity analysis）を説明する。
- 必要に応じて、コスト分析の手法/方法を含める。
- ギャップ分析を実行して、ミッションを成功させるための問題やリスクがあるかどうかを判断する。
アーキテクチャ概観：Architecture Overview
- GMRAを導き制約するアーキテクチャ成果（product）について説明する。。
oミッションの現状とミッションの将来の状態を説明する
oアーキテクチャ内のギャップを描く
o該当する場合は、OV-1ビューを含める。これは、ミッション・スレッドまたはミッション・エンジニアリング・スレッドとして表すことができる
oコンポーネントとその技術的およびパフォーマンス属性を一覧表示する
o コンポーネントまたはシステムがどのように相互にインターフェイス/通信するかを含める
o取引または代替案について議論する（感度分析（sensitivity analysis）/不確実性に関連）
ミッション能力のギャップを埋めることができる能力ソリューションを特定する
結論：Conclusions
- 成功のための政府ミッション参照アーキテクチャ（GMRA）指標を説明する。
o分析から得られた結果を説明する
o結果の問題や不確実性を特定する
- 政府ミッション参照アーキテクチャ（GMRA）をインスタンス化するために必要な次のステップを特定する。
- 推奨される後続の研究を特定する。
付録B：政府能力参照アーキテクチャ（GCRA）（テンプレート）=Appendix B: Government Capability Reference Architecture (GCRA) (Template)
目的：Purpose
政府能力参照アーキテクチャ（GCRA）を使用して、特定のドメイン（たとえば、宇宙、電磁スペクトラム、サイバースペース）または技術的な機能（functions）とプロセス（たとえば、コマンドアンドコントロール、通信またはポジショニング、ナビゲーションおよびタイミング）内の一連の共通能力をガイドおよび制約する必要がある。これらの能力は、ドメイン固有または技術的な機能（functions）/プロセスによって、複数の作戦的ミッションまたは戦術的ミッションを実行するために必要になる。政府能力参照アーキテクチャ（GCRA）は、現在および将来のアーキテクチャを描写して、ミッション能力のギャップが存在する場所を特定し、新しいゲームを変える能力に対する将来の投資決定を導き、米国が将来の戦いで敵に対抗または打ち負かすことができるようにする。戦闘員（warfighter）は、最も穏やかな作戦環境から極端な作戦環境（低い環境から非常に競争の激しい環境）で動作する能力を必要とする。脅威は絶えず変化するため、シナリオと進化する脅威に基づいて政府能力参照アーキテクチャ（GCRA）を更新できる必要がある。
定義：Definitions
アーキテクチャ：コンポーネントの統一または一貫した形式または構造、およびいずれかの関係。単に描写またはビュー。政府能力参照アーキテクチャ（GCRA）の目的（purpose）のために、アーキテクチャは、現在および将来の一連のミッションまたは能力と、それらのデザインおよび時間の経過に伴う進化を示す。
能力アーキテクチャ（Capability Architecture）：コンポーネント、関係、および原則を含むさまざまな能力オプション/代替案を示す、統一された、または一貫性のある形式または構造。
政府参照アーキテクチャ（Government Reference Architecture）：能力アーキテクチャとソリューションのインスタンス化をガイドおよび制約する、特定のサブジェクト領域に関する政府所有の信頼できる情報源。
概観：Outline
要旨：Executive Summary
- GCRAが説明する能力領域の概要を含める。
o 政府参照アーキテクチャ（GRA）の目的（purpose）の背景、政府能力参照アーキテクチャ（GCRA）の開発を通知するために使用されるさまざまなミッションのリスト、主要な前提条件、およびその他の参照文書を含める。
- GCRAの全体的な作戦コンセプトを説明する。
- 実装の潜在的な次のステップの概要を説明する。
- 所有者/構成管理者を特定する。更新サイクルと決定について議論する。政府能力参照アーキテクチャ（GCRA）の更新を促進する可能性のあるポイント/イベント。
能力分野の定義：Capability Area Definition
- 能力領域について説明する。
o 目標を定義する
o 全体の作戦と運用の文脈を説明する
o 必要に応じて、時間枠、ドメイン、戦域、またはその他の詳細を含める
o シナリオを説明する
o 政府能力参照アーキテクチャ（GCRA）の作成時に分析されたすべてのミッションを定義または参照する
- ミッション・スレッドおよび/またはミッション・エンジニアリング・スレッドを特定する。
o 活動/タスクおよび/またはシステムを含める
- 利害関係者を特定する。
o 例：ミッションの一部である各軍種、各機関、同盟国。ミッションによっては、ミッションに不可欠な他の非伝統的な組織が存在する場合がある。
- ミッションの成功の指標を定義する–これにはミッションの有効性の尺度（MOE）を含めることができる。
基本的な仮定と依存関係：Foundational Assumptions and Dependencies
- 脅威とミッション環境、および定義のソースを特定する。
- さまざまなミッション（政府ミッション参照アーキテクチャ（GMRA））に対する能力アーキテクチャ（政府能力参照アーキテクチャ（GCRA））の依存関係と影響を特定する。
- ミッション、技術、または能力に関する重要な前提条件を特定する。
o アナリストがこれらの仮定をどのように決定したか、および仮定が現実的/合理的である理由を説明する
- 該当する場合は、変数を使用して仮定を説明する。
分析の方法論：Analytical Methodology
- メソッドのタイプ（パラメトリック (parametric)、確率論、物理学ベース、対象分野の専門家、卓上など）を含め、使用された分析および計算ツールについて説明する。
- 使用したモデルを説明し、系図（pedigree）と忠実度（fidelity）を特定する。
- ソースを含め収集され、モデルの取り込みに使用されるデータを特定する。
- モデリング環境全体にわたる一体化された不確実性と、回答の精度/精度への影響について説明する。。
- トレードスペース分析を定義する–どのパラメータまたは変数が一定に保たれ、どのパラメータまたは変数が変更されたか。
- ベースラインの仮定に関する感度分析（sensitivity analysis）を説明する。
- 必要に応じて、コスト分析の手法/方法を含める。
- ギャップ分析を実行して、ミッションを成功させるための問題やリスクがあるかどうかを判断する。
アーキテキチャの外観：Architecture Overview
- GCRAをガイドおよび制約するアーキテクチャ成果（product）について説明する。
o 能力アーキテクチャの現状の状態と能力アーキテクチャの将来の状態を説明する
o 能力のリストとその技術的およびパフォーマンス属性を含める
o 技術の準備レベル、機関の責任、各能力/技術、および展開予定日を説明する。
- 各能力、システム、技術などを成熟または開発するためのアプローチを説明する。
- 各能力に関連するリスクを説明する。
o リスクは、データ交換、相互運用性、脅威に対するシステムパフォーマンス、または動作環境、スケジュールに関連している可能性がある
- 次の表は、コンセプト的な政府能力参照アーキテクチャ（GCRA）成果物（artifacts）を示している。
注：米国防省アーキテクチャ・フレームワーク（DoDAF）成果（product）は、政府能力参照アーキテクチャ（GCRA）に必要となる可能性のあるさまざまなアーキテクチャ成果物（artifacts）の例を説明するためにのみ使用される。
GCRA成果物（artifacts）の例
| 内容 | ビュー／モデルの例 | |
| 目的（purpose）：はじめに、概要、文脈、範囲、到達目標（goals）、目的（purpose）、必要な理由、およびいつどのように使用されるか | • AV‐1 概観と要約した情報
• CV‐1: ビジョンー全体的な戦略的コンセプトと高レベルの範囲 • OV‐1 高レベルの作戦コンセプトの図示‐推奨される代替（ソリューション）アーキテクチャが実行することを意図していることと、それらがどのように実行することになっているのかについてのエグゼクティブ運用サマリーレベル |
|
| 技術的立場と方針 | • StdV‐1 標準プロファイル –推奨される代替（ソリューション）アーキテクチャの要素に適用される標準、仕様、ガイダンス、ポリシー | |
| アーキテクチャパターン：活動の一般化されたパターン、システム機能（functions）とそのリソース、プロバイダー、情報/データリソースフロー
同期/非同期の時限イベントに対する活動、サービス、およびシステム機能（functions）（およびそれらのリソース）によるシーケンス（順次/同時）応答の一般化されたシナリオパターン |
作戦上のパターン
• OV‐2 (複数) 作戦リソースのフロー • OV‐5 {a, b}活動ダイアグラム • OV‐6cイベントトレースの説明 |
システムパターン
• SV‐1 (複数)システムインターフェイス • SV‐2システムのリソースのフロー • SV‐4 システム機能（functions） • SV‐10bシステム状態遷移 • SV‐10cシステムイベントトレースの説明 |
| 動的振舞いのイベントベースのシナリオパターン
• OV‐6c システムイベントトレースの説明 • SvcV‐10cサービスイベントトレースの説明 • SV‐10c システムイベントトレースの説明 |
||
結論：Conclusions
- 成功のための政府能力参照アーキテクチャ（GCRA）指標（metrics）を説明する。
o 分析から得られた結果を説明する
o 結果の問題や不確実性を特定する
- 政府能力参照アーキテクチャ（GCRA）をインスタンス化するために必要な次のステップを特定する。
- 研究で推奨されるフォローを特定する。
GRAの完全性と品質を評価する方法：Method to Evaluate Completeness and Quality of a GRA
このセクションは、実務者のためのより自由な評価基準を提供し、政府参照アーキテクチャ（GRA）を評価するための有効性の尺度/パフォーマンスの尺度の開発を促すことを意図している。
政府参照アーキテクチャ（GRA）は、特定のシナリオでさまざまな分析に適用してその有効性を評価できるベースライン構造を形成するツールである必要がある。そのため、ミッション・エンジニアリング（ME）の実務者は、（1）政府参照アーキテクチャ（GRA）自体の品質、および（2）分析中のシナリオに対する政府参照アーキテクチャ（GRA）の妥当性の関連性を評価するために、いくつかの一般的な有効性の尺度を適用する必要がある。
- 政府参照アーキテクチャ（GRA）は、機能的（functional）とう作戦的（operational）の両方の構成要素に対応しているか？
- 政府参照アーキテクチャ（GRA）は、シナリオ、時間枠、作戦環境、および脅威を説明しているか？
- 政府の参照アーキテクチャが満たす要件（インターフェイス要件、データ交換要件など）を説明する明確で文書化された一連の成果物（artifacts）はあるか？
- 機能的（functional）コンポーネントとインフラストラクチャコンポーネントの両方、およびそれらの関係を説明する、明確で文書化されたアーキテクチャモデルはあるか？
- アーキテクチャは、各軍種とその作戦を実現するためにコンポーネントを構築する方法を説明しているか？
- 政府の参照アーキテクチャは、装備ソリューションのデザイン、選択、および開発をガイドするための定量化された尺度を提供するか？
- 政府の参照アーキテクチャをインスタンス化する方法と、追加の分析または調査が必要かどうかを特定する明確な手順はあるか？
