---
title: NASAに学ぶシステム工学_研修デッキ_20260701
tags:  #システム工学 #お金をかけない  
author: [Yukiko](https://www.docswell.com/user/yukiko_it)
site: [Docswell](https://www.docswell.com/)
thumbnail: https://bcdn.docswell.com/page/9J29628MER.jpg?width=480
description: NASAに学ぶシステム工学_研修デッキ_20260701 by Yukiko
published: July 01, 26
canonical: https://www.docswell.com/s/yukiko_it/K4NNW8-2026-07-01-073249
---
# Page. 1

![Page Image](https://bcdn.docswell.com/page/9J29628MER.jpg)

CORPORATE TRAINING DECK ｜ うさうさ研修工房
NASAに学ぶシステム工学
商用プロダクト開発者が必ず押さえるべき基礎体系
NASA Systems Engineering Handbook（SP-2016-6105 Rev2）と INCOSE の知見を、
ハードウェア／ソフトウェア問わず商用プロダクト開発に応用するための研修教材
ライフサイクル管理
要求定義と検証
出典：NASA/SP-2016-6105 Rev2、INCOSE Systems Engineering Handbook、Mankins (1995) ほか査読済み文献 Yukiko
リスクと意思決定


# Page. 2

![Page Image](https://bcdn.docswell.com/page/DEY49Y6PJM.jpg)

WHY SYSTEMS ENGINEERING
なぜ「システム工学」が必須なのか
上流の意思決定が下流コストの大半を縛る
ライフサイクルコストの作り込み構造
NASAの実証データでは、初期フェーズ（構想・予備設計）の決定が、ライフサイク
ル全体コストの約 7〜8割を“コミット”してしまうとされる。だが実際にコストが「発
生」するのは製造・運用フェーズに偏る。
コスト
コミットされるコスト（≒後戻りの効かない決定）
後工程での手戻りは指数関数的に高くつく
実際に発生するコスト
要求の取り違えや設計の見落としは、発見が遅れるほど修正コストが跳ね上が
る。商用プロダクトでも、要件定義・アーキテクチャ段階の品質が事業全体の ROI
を左右する。
だからこそ体系的なプロセスが要る
属人的な勘や場当たり的な開発ではなく、 NASAが半世紀かけて磨いた「再現性
のある技術プロセス」を、商用プロダクト開発のスケールに合わせて取り入れ
る。
構想 → 設計 → 製造/実装 → 運用
参照: NASA SP-2016-6105 Rev2, Fig.2.5-1 “Life-Cycle Cost Impacts from Early Phase Decision-Making”
02


# Page. 3

![Page Image](https://bcdn.docswell.com/page/VJNYLPZM78.jpg)

DEFINITION
システム工学（ Systems Engineering）とは
NASAの定義
ハードウェア
／ソフトウェア
人・プロセス
・手順
「システム」とはハードウェア・ソフトウェア・設備・人員・プロセス・手順など、必要
な能力を生み出すために機能し合うすべての要素の組み合わせ。システム工学
はその設計・実現・運用・廃却を技術的に統合管理する規律。
部分最適ではなく全体最適
運用環境・
施設・設備
個々の要素（モジュール・機能）を最高性能にしても、相互作用が噛み合わなけ
ればシステムは成立しない。 SEは要素間のトレードオフを横断的に扱う “統合す
る技術”。
商用プロダクトでの読み替え
「システム」＝目的の能力を生み出すために
機能し合う要素の組み合わせ全体
参照: NASA SP-2016-6105 Rev2, §1.0–2.0; INCOSE Systems Engineering Handbook, 4th/5th ed.
宇宙機を「製品」、ミッションを「事業目的」、サブシステムを「機能モジュール／
チーム」と読み替えれば、スタートアップの一プロダクトにもそのまま応用できる。
03


# Page. 4

![Page Image](https://bcdn.docswell.com/page/YE9P43ZWJ3.jpg)

THE SE VEE MODEL
システムズエンジニアリングの「 Vモデル」
分解・定義（左脚）
左脚＝要求を分解していく工程
統合・検証（右脚）
コンセプト／
ミッション要求
妥当性確認・
運用移行
システム要求定義
システム検証
サブシステム
統合・検証
サブシステム設計
ミッション全体の要求を、システム →サブシステム →コンポーネントへと
段階的に分解・具体化する。各段階で「何を満たせば成功か」を定義
する。
右脚＝下から積み上げて確認する工程
実装したコンポーネントを統合しながら、対になる左脚の要求に対して
「正しく作ったか（検証）」「正しい物を作ったか（妥当性確認）」を確認し
ていく。
商用開発での意味
コンポーネント
設計・実装
コンポーネント検
証
参照: NASA SP-2016-6105 Rev2, Fig.2.1-1 “The Systems Engineering Engine” / INCOSE SE Handbook, Vee model
要件定義と受け入れテストを “対”として最初から設計しておくことが核
心。後工程でテスト観点を後付けすると、 Vの対応関係が崩れ手戻りが
激増する。
04


# Page. 5

![Page Image](https://bcdn.docswell.com/page/GE8DQM1RED.jpg)

PROJECT LIFE CYCLE
NASA プロジェクトライフサイクルの 7フェーズ
Pre-A
構想
スタディ
A
コンセプト・
技術開発
B
予備設計
Formulation（構想段階）
C
詳細設計・
製造
D
統合・試験・
打上げ
E
運用・維持
F
終結
Implementation（実装段階）
各フェーズの境界に「主要意思決定ポイント（ KDP）」を設け、次フェーズ移行の可否をレビューで判定する
商用プロダクト開発フェーズへの読み替え例
Pre-A/A 市場仮説検証・コンセプト実証
（PoC）
B/C MVP設計・詳細仕様・実装
参照: NASA SP-2016-6105 Rev2, §3.0 “NASA Program/Project Life Cycle”, Fig.3.0-1（NPR 7120.5E）
D 結合テスト・受け入れ試験・リリース
E/F 運用・グロース・EOL（提供終了）判断
05


# Page. 6

![Page Image](https://bcdn.docswell.com/page/LELMX3Q27R.jpg)

THE 17 TECHNICAL PROCESSES
システム工学エンジンを構成する 17プロセス
① システム設計
(4プロセス)
② プロダクト実現
(5プロセス)
③ 技術マネジメント
(8プロセス)
ステークホルダー要求定義
プロダクト実装
技術計画
技術要求定義
プロダクト統合
要求管理
論理分解
プロダクト検証
インターフェース管理
設計解定義
プロダクト妥当性確認
技術リスク管理
プロダクト移管
コンフィグレーション管理
技術データ管理
技術アセスメント
意思決定分析
①〜③のプロセスを、プロジェクトのライフサイクル全体で反復的・再帰的に回し続けるのが「SEエンジン」
参照: NASA SP-2016-6105 Rev2, §2.1 “The Common Technical Processes and the SE Engine”（17プロセス, NPR 7123.1準拠）
06


# Page. 7

![Page Image](https://bcdn.docswell.com/page/4JMYLD19JW.jpg)

STAKEHOLDER EXPECTATIONS
ステークホルダー要求定義プロセス
1. ステークホルダーの特定
ConOps（運用概念）が出発点
誰が・どんな場面で・なぜそのシステムを使うのかという「運用のシナリオ」を先
に固める。技術要求はこの ConOpsから導出される。
2. ミッション／運用概念（ ConOps）の収集
“欲しいもの ”と“必要なもの ”を分けて聞く
3. 期待値（ needs/wants）の引き出し
4. 制約条件の明確化
ステークホルダーの言葉をそのまま要求にすると、実現不能・過剰仕様になり
がち。インタビューでは背景にある真のニーズを掘り下げる。
商用開発での適用
顧客インタビュー・カスタマージャーニー・ペルソナ設計はこのプロセスの実践
形。ここでの精度が PMF（プロダクトマーケットフィット）の精度を決める。
5. ステークホルダー要求としての文書化・合意
参照: NASA SP-2016-6105 Rev2, §4.1 “Stakeholder Expectations Definition Process”, Fig.4.1-1
07


# Page. 8

![Page Image](https://bcdn.docswell.com/page/PJR9K4L979.jpg)

WRITING GOOD REQUIREMENTS
「良い要求」を書くための 7原則
1. 明確・一意
曖昧な形容詞を避け、一通りにしか解釈できない表現にす
る
4. 単一機能
1つの要求文に複数の要求を詰め込まない（AND禁止）
2. 検証可能
「検査・分析・試験・実証」のいずれかで真偽を判定できる
5. トレース可能
上位要求・下位要求と紐付け、出所を追跡できる
3. 実現可能
現実の技術・予算・スケジュールの範囲内で達成できる
6. 手段でなく目的
“How”ではなく“What”を記述し、設計の自由度を残す
良い要求の例：「システムは、外気温 -10〜 45℃の環境下で起動から 3秒以内に応答すること」
参照: NASA SP-2016-6105 Rev2, Appendix C “How to Write a Good Requirement—Checklist”; Hooks & Farry, Customer-Centered Products
08


# Page. 9

![Page Image](https://bcdn.docswell.com/page/PEXQL2W3JX.jpg)

REQUIREMENTS FLOWDOWN
要求のフローダウンと検証可能性
親と子は “契約”の関係
ミッション要求
上位要求を満たすために下位要求が存在する。下位要求をすべて満たせば上
位要求が満たされる、という構造を意図的に設計する。
システム要求
要求検証マトリクス（ RVM）で管理
サブシステム A要求
サブシステム B要求
コンポーネント要求
コンポーネント要求
各階層で「親要求 ⇄ 子要求」を一対一にトレースし、
検証手段（試験／分析／検査／実証）を要求ごとに割り当てる
要求ID・検証方法（試験 /分析/検査/実証）・合格基準・担当・ステータスを一覧
化し、すべての要求に検証手段が紐づいているかを常に監査する。
商用開発での適用
ユーザーストーリー → 受け入れ基準 → テストケースのトレーサビリティが同じ
構造。要求IDのないユーザーストーリーは検証不能リスクを抱える。
参照: NASA SP-2016-6105 Rev2, Fig.4.2-2/4.2-3 “Flow, Type and Ownership of Requirements”; Appendix D “Requirements Verification Matrix”
09


# Page. 10

![Page Image](https://bcdn.docswell.com/page/3EK9LMVNED.jpg)

VERIFICATION vs VALIDATION
「検証」と「妥当性確認」の違い
Verification（検証）
Validation（妥当性確認）
“Did we build the system right?”
仕様通りに作ったか
“Did we build the right system?”
本当に必要な物を作ったか
•
対象：技術要求（仕様書）
•
対象：ステークホルダーの期待・ニーズ
•
問い：要求文書に適合しているか
•
問い：利用環境で実際の目的を満たすか
•
手段：試験／分析／検査／実証
•
手段：実環境試験／ユーザー評価／実証運用
•
実施時期：各階層の実装直後
•
実施時期：統合後・実際の利用文脈で
例：「応答時間3秒以内」という仕様に対し、実測が2.8秒だったので合格
参照: NASA SP-2016-6105 Rev2, §2.4 “Distinctions between Product Verification and Product Validation”; §5.3–5.4
例：仕様は満たしたが、実際の利用者には“遅い”と感じられ目的を達成できない
10


# Page. 11

![Page Image](https://bcdn.docswell.com/page/L73W3YMZ75.jpg)

TECHNOLOGY READINESS LEVEL
技術成熟度レベル（ TRL）9段階
TRL9
実運用での実証
TRL8
実システム完成・適格性確認済
TRL7
実環境でのシステム実証
TRL6
関連環境でのシステム実証
TRL5
関連環境での要素実証
TRL4
実験室環境での要素実証
TRL3
概念実証（ PoC）
TRL2
技術コンセプトの定式化
TRL1
基礎原理の観測・報告
参照: Mankins, J.C. (1995) “Technology Readiness Levels: A White Paper,” NASA; NASA SP-2016-6105 Rev2, Appendix G, Fig.G.4-1
1995年 NASA Mankins論文が起点
John C. Mankins（NASA）がTRLを体系化した白書を発表。以後、 ESA・DoD・
各国宇宙機関、さらに製造業や政策評価にも世界的に普及した。
投資判断・予算配分の共通言語
「どれだけ枯れた技術か」を関係者間で一致させることで、過度に楽観的
なスケジュール見積りや技術的負債の見落としを防ぐ。
商用プロダクトでの活用
TRL1-3＝研究・PoC段階、4-6＝検証環境でのプロトタイプ、 7-9＝量産・実
運用。投資家への説明や社内の優先順位付けに転用しやすい。
11


# Page. 12

![Page Image](https://bcdn.docswell.com/page/87DK4564JG.jpg)

TECHNICAL RISK MANAGEMENT
継続的リスクマネジメント（ CRM）サイクル
リスク＝「シナリオ × 確率 × 影響」のトリプレット
識別
(Identify)
「もし〜が起きたら（シナリオ）／その確率は〜／結果として〜の影響が出る」と
いう3点セットで定義し、感覚論ではなく構造化して扱う。
一度作って終わりではなく回し続ける
対応
(Control)
分析
(Analyze)
継続的に
反復
Identify→Analyze→Plan→Track→Controlの5ステップを、プロジェクト期間中ずっ
と反復するのが CRM（Continuous Risk Management）の核心。
リスク情報に基づく意思決定（ RIDM）と対
CRMが実行中のリスク管理なら、 RIDMは重要な意思決定の入口でリスクを織り
込む仕組み。両輪で機能してはじめてリスクが「見える化」される。
追跡
(Track)
計画
(Plan)
参照: NASA SP-2016-6105 Rev2, §6.4 “Technical Risk Management”, Fig.6.4-3/6.4-4（NASA/SP-2011-3422 ベース）
12


# Page. 13

![Page Image](https://bcdn.docswell.com/page/VJPKMGYVE8.jpg)

CONFIGURATION MANAGEMENT
コンフィグレーション管理の 5要素
CM計画／マネジメント
誰が・何を・どう管理するかの統治ルール
「今のシステムが何でできているか」を常に知る
ハードウェア部品、ソフトウェアのバージョン、ドキュメントが正確に対応していな
ければ、不具合の再現も改修の影響範囲特定もできない。
構成識別
何が「製品の一部」か、バージョン・部品表を定義
ベースラインの段階的な凍結
変更管理
機能ベースライン →割当ベースライン →プロダクトベースラインと段階的に確定
し、それ以降の変更には正式な変更管理プロセスを通す。
変更要求の評価・承認・記録のプロセス
ステータス記録
現在の構成状態を常に追跡可能にする
商用開発での適用
Gitのバージョン管理、リリースノート、変更管理委員会（ CAB）、SBOM（部品表）管
理はすべてこの考え方の実装。 CMが弱いと障害対応が長期化する。
構成監査
実体が文書・要求と一致しているか定期検証
参照: NASA SP-2016-6105 Rev2, §6.5 “Configuration Management”, Fig.6.5-2 “Five Elements of Configuration Management”
13


# Page. 14

![Page Image](https://bcdn.docswell.com/page/2EVV96GREQ.jpg)

DECISION ANALYSIS
トレードスタディと意思決定分析プロセス
「なんとなく」を排除する仕組み
1. 課題・目的の明確化
重要な技術的決定ほど、評価基準を先に固定してから代替案を比較する。後
出しで基準を調整すると、結論ありきの正当化に陥る。
2. 評価基準の設定と重み付け
意思決定の “記録”自体が資産になる
3. 代替案の洗い出し
4. 代替案ごとのリスク・効果分析
5. 比較・トレードオフの可視化
なぜその選択をしたか、何を捨てたかを文書化しておくことで、後任者や将来の
自分が同じ議論を繰り返さずに済む。
商用開発での適用
技術選定（自社開発 vs 外部API）、アーキテクチャ選択、優先順位付けなど、影
響範囲が大きい意思決定ほどこのプロセスを簡易版でも回す価値がある。
6. 決定と根拠の記録（Decision Report）
参照: NASA SP-2016-6105 Rev2, §6.8 “Decision Analysis”, Fig.6.8-1; Table 6.8-1 “Typical Information to Capture in a Decision Report”
14


# Page. 15

![Page Image](https://bcdn.docswell.com/page/57GLZN86EL.jpg)

SUMMARY
商用プロダクト開発への適用ロードマップ
要求工学
ConOps→要求→検証手段を一気通貫でトレースする
Vモデル思考
受け入れ基準を実装より先に定義する
継続的リスク管理
リスク登録簿を作り、定例で回し続ける
規模に応じてテーラリング（簡略化）してよい。重要なのは
コンフィグレーション管理
「今の構成」を常に追跡可能にする
TRLゲート
PoC→プロトタイプ→量産の節目で技術成熟度を評価
意思決定の記録
重要判断の根拠を後から追跡できるようにする
“型 ”を知った上で意図的に省略すること。
参照: NASA SP-2016-6105 Rev2, §3.11 “Tailoring and Customization of NPR 7123.1 Requirements”
15


# Page. 16

![Page Image](https://bcdn.docswell.com/page/4EQYLQ92JP.jpg)

REFERENCES
参考文献一覧
1.
NASA (2016). NASA Systems Engineering Handbook, NASA/SP-2016-6105 Rev2. NASA Headquarters, Office of the Chief Engineer.
2.
International Council on Systems Engineering (INCOSE). Systems Engineering Handbook: A Guide for System Life Cycle Processes and Activities.
3.
Mankins, J. C. (1995). Technology Readiness Levels: A White Paper. Advanced Concepts Office, NASA Office of Space Access and Technology.
4.
NASA (2011). NASA Risk Management Handbook, NASA/SP-2011-3422; Continuous Risk Management Guidebook, NASA/SP-2011-3421.
5.
Hooks, I. F., & Farry, K. A. (2001). Customer-Centered Products: Creating Successful Products through Smart Requirements. AMACOM.
6.
NPR 7123.1: NASA Systems Engineering Processes and Requirements. NASA Procedural Requirements.
7.
NPR 7120.5E: NASA Space Flight Program and Project Management Requirements.
8.
Rehberg, M. et al. (2025). Bridging the Gap: Linking Prototyping and Technology Readiness Levels for Integrative Product Development. Creativity and Innovation Management.
本資料は上記の査読済み公式文献・NASA一次資料に基づき、商用プロダクト開発向けに再構成した法人研修用教材です。
16