この本に示されていることには、まだ不足していることがあります。
それを補う方法は下記を開くと見ることができます。
http://dtcn-wisdom.jp/00001-PMSE3.pdf
http://dtcn-wisdom.jp/J/1-wm-maegakiR1.pdf 即ち、ＳＥ（システムエンジニアリング）とＰＭ（プロジェクト管理）の明解な関係についての説明です。
ＮＡＳＡ
システムエンジニアリング・ハンドブック
SP−6105
1995 年 6 月
PPMI
Page
目次
ix
序文
xi
1992 年 9 月の草稿における序文
緒言
xiii
謝辞
xv
1．
1
概説
1.1
目的
1
1.2
適用範囲と詳細度
1
2．
3
システムエンジニアリングの基本
2.1
システム、スーパーシステム、およびサブシステム
3
2.2
システムエンジニアリングの定義
5
2.3
システムエンジニアリングの目的
5
2.4
システムエンジニアリングの関連分野
9
2.5
連続改良主義
3．
11
20
NASA 主要システムのプロジェクト・ライフサイクル
21
3.1
プリフェーズ A
−
最新研究段階
3.2
フェーズ A
−
予備解析段階
23
3.3
フェーズ B
−
定義段階
25
3.4
フェーズ C
−
設計段階
28
3.5
フェーズ D
−
開発段階
29
3.6
フェーズ E
−
運用段階
31
3.7
プロジェクト・ライフサイクルにおけるシステムエンジニアリングの役割
32
3.7.1
「V 形」チャート
32
3.7.2
NASA プログラム／プロジェクトのライフサイクル・プロセスフローチャート
35
予算サイクル
45
システムエンジニアリングのマネジメント問題
46
3.8
4．
資金調達：
46
4.1
目標、作業成果、および組織の調和
4.2
システムエンジニアリング・プロセスのマネジメント：
システムエンジニアリング・
47
マネジメント計画書（SEMP）
4.2.1
SEMP の役割
48
4.2.2
SEMP の内容
49
4.2.3
SEMP の作成
51
4.2.4
システムエンジニアリング・プロセスのマネジメント：
4.3
4.3.1
概要
52
53
作業明細構成（WBS）
56
WBS の役割
i
4.3.2
WSB 作成技法
56
4.3.3
WBS 作成時の共通エラー
58
4.4
58
スケジュール
4.4.1
スケジュールの役割
58
4.4.2
ネットワークスケジュールのデータとグラフィックフォーマット
59
4.4.3
ネットワークスケジュールの作成
61
4.4.4
報告技法
62
4.4.5
経営資源レベル
63
4.5
予算編成と経営資源計画
64
4.6
リスク・マネジメント
66
4.6.1
リスクのタイプ
70
4.6.2
リスク識別・特性表示技法
71
4.6.3
リスク分析技法
73
4.6.4
リスク軽減化および追跡調査技法
76
4.6.5
リスク・マネジメント：
78
4.7
まとめ
79
コンフィギュレーション・マネジメント
4.7.1
ベースラインの進展
80
4.7.2
コンフィギュレーション・マネジメント技法
82
4.7.3
データ・マネジメント
87
4.8
87
審査、監査、およびコントロール・ゲート
4.8.1
目的と定義
88
4.8.2
審査の一般原則
89
4.8.3
主なコントロール・ゲート
91
4.8.4
中間審査
99
4.9
106
状態報告と評価
4.9.1
コストおよびスケジュール管理対策
108
4.9.2
技術性能測定
110
4.9.3
システムエンジニアリング・プロセスの評価指標
116
5．
119
システム解析とモデル作成の問題点
5.1
119
トレード研究プロセス
5.1.1
トレード研究プロセスの管理
126
5.1.2
モデルの使用
127
5.1.3
選定規準の選定
130
5.1.4
トレード研究プロセス：
5.2
5.2.1
137
まとめ
138
コストの定義とモデル作成
139
ライフサイクル・コストとその他コストの算定
ii
5.2.2
ライフサイクル・コストの管理
142
5.2.3
コスト予測
144
5.3
149
効果の定義とモデル作成
5.3.1
システム効果測定のための戦略
149
5.3.2
NASA システム効果の測定
151
5.3.3
アベイラビリティ・モデルとロジスティック支援モデルの作成
153
5.4
158
コストと効果の確率論的処理
5.4.1
モデルの不確定性原因
158
5.4.2
不確定性を処理するためのモデル作成技法
159
6．
システムエンジニアリング・プロセスに対する専門工学分野の導入
163
6.1
専門工学分野の役割
163
6.2
信頼性
164
6.2.1
信頼性技術者の役割
164
6.2.2
信頼性プログラムの立案
166
6.2.3
信頼性のある宇宙用システムの設計
167
6.2.4
信頼性解析のツールと技法
169
6.3
170
品質保証
6.3.1
品質保証技術者の役割
170
6.3.2
品質保証のツールと技法
171
6.4
172
保全性
6.4.1
保全性技術者の役割
172
6.4.2
システム保守概念と保守計画
173
6.4.3
保全可能な宇宙用システムの設計
174
6.4.4
保全性解析のツールと技法
175
総合ロジスティック支援（ILS）
177
6.5
6.5.1
ILS 項目
178
6.5.2
ILS 計画の立案
178
6.5.3
ILS のツールと技法：
6.5.4
連続調達とライフサイクル支援
6.6
ロジスティック支援解析
180
184
186
検証
6.6.1
検証プロセスの概観
187
6.6.2
検証プログラムの立案
191
6.6.3
認定試験検証
196
6.6.4
受領試験検証
196
6.6.5
配備準備の検証
197
6.6.6
運用と廃棄の検証
198
iii
6.7
199
製造性
6.7.1
生産技術者の役割
199
6.7.2
製造性のツールと技法
200
6.8
201
社会の容認
6.8.1
環境への影響
201
6.8.2
原子力安全打上げ認可
205
6.8.3
惑星保護
207
添付資料 A
−
略語
209
添付資料 B
−
システムエンジニアリングのテンプレートと例
214
添付資料 B.1
−
SEMP の概要例
214
添付資料 B.2
−
搭載用望遠鏡の「テーラリング済み」WBS
216
添付資料 B.3
−
クラス A−D ペイロードに対する特性表示、ミッション成功度、
219
SRM＆QA コスト指針書
添付資料 B.4
−
リスクマネジメント計画書の概要例
220
添付資料 B.5
−
クリティカルアイテムリスト例
221
添付資料 B.6
−
コンフィギュレーション・マネジメント計画書の概要例
223
機能解析技法
224
B.7.1
機能流れブロック図
224
B.7.2
N 2 ダイヤグラム
225
B.7.3
タイムライン解析
227
添付資料 B.7
−
添付資料 B.8
−
宇宙ステーション「フリーダム」の運用に対する
230
ORU の MTBF 変更の影響
添付資料 B.9
−
添付資料 B.10 −
添付資料 C
−
検証要求事項マトリックスの例
234
検証マスタープランの概要例
236
237
メートル法の使用
C.1
NASA の方針
237
C.2
単位の定義
237
C.2.1
SI 単位の接頭辞
237
C.2.2
基本 SI 単位
238
C.2.3
補助 SI 単位
239
C.2.4
特殊名付き誘導単位
239
C.2.5
SI と併用する単位
241
C.3
243
換算係数
247
索引
iv
図面リスト
図 1
−
優先設計の包絡面
7
図 2
−
不確定性を伴う設計概念から得られる推定結果
7
図 3
−
連続改良主義
12
図 4
−
ライフサイクル・コストとすべての効果面に依存する定量的目的関数
17
図 5
−
NASA のプログラム／プロジェクト・ライフサイクル
24
図 6
−
フェーズ A と B が資金不足の場合は超過コストになる可能性が高い
25
図 7
−
NASA プロジェクトサイクル技術面の概観
34
図 8
−
NASA プログラム／プロジェクトのライフサイクル・プロセスフローチャート
38
図 9
−
標準的 NASA 予算サイクル
45
図 10
−
システム、製品明細構成、作業明細構成との関係
55
図 11
−
WBS 作成時のエラーの例
57
図 12
−
ネットワークスケジュールに使用する作業矢印図と順位図
60
図 13
−
ガントチャートの例
64
図 14
−
不均一な経営資源プロファイルの例
65
図 15
−
リスク・マネジメント構成図
67
図 16
−
発生確率と影響度によるリスクの特性表示
69
図 17
−
技術ベースラインの進展
82
図 18
−
コンフィギュレーション・マネジメント構成図
82
図 19
−
契約変更管理手続き
84
図 20
−
計画と状態報告のフィードバック・ループ
107
図 21
−
コスト偏差とスケジュール偏差
108
図 22
−
3 つの TPM（技術性能測定）評価方法
113
図 23
−
トレード研究プロセス
119
図 24
−
リスク・パターンを異にする設計概念の評価結果
131
図 25
−
ライフサイクル・コスト項目
139
図 26
−
システム効果項目（一般的なもの）
152
図 27
−
アベイラビリティ・モデルとロジスティックス支援性モデルの役割
158
図 28
−
3 つの不確定入力によるモンテカルロ・シミュレーション
161
図 29
−
信頼性の基本ブロック図
168
図 30
−
単純故障樹形図
169
図 31a −
ロジスティックス支援解析プロセスフローチャート（フェーズ A と B）
181
図 31b −
ロジスティックス支援解析プロセスフローチャート（フェーズ C／D と E）
181
図 32a −
検証プロセスフローチャート（フェーズ A／B と C）
186
図 32b −
検証プロセスフローチャート（フェーズ D）
187
図 B-1 −
赤外線天文学成層圏観測施設（SOFIA）の製品明細構成(PBS)
216
v
図 B-2 −
SOFIA プロジェクトの WBS（レベル 3）
217
図 B-3 −
SOFIA 観測システムの WBS（レベル 4）
217
図 B-4 −
SOFIA 搭載設備の WBS（レベル 5）
218
図 B-5 −
SOFIA 望遠鏡エレメントの WBS（レベル 6）
218
図 B-6 −
機能流れブロック図の展開
226
図 B-7 −
N 2 図の定義
227
図 B-8 −
N 2 図の主要特性
228
図 B-9 −
飛行ミッションのタイムライン
229
図 B-10 −
保全作業タイムライン・シート例
229
図 B-11 −
運用コストに対する MTBF の影響
231
図 B-12 −
乗組員の時間に対する MTBF の影響
231
図 B-13 −
アップマスに対する MTBF の影響
232
図 B-14 −
乗組員数に対する MTBF の影響（乗組員の使用可能時間を一定に維持）
232
図 B-15 −
STS の飛行回数に対する MTBF の影響（使用可能アップマスを一定に維持）
233
図 B-16 −
5 年間の運用コストに対する MTBF の影響（使用可能アップマスと乗組員の使用可能時間を
233
一定に維持した場合と維持しない場合）
vi
枠内補足記事
システムエンジニアリングに関する特定文献
2
階層的システム用語
3
システムエンジニアリングの実施上必要となる技術的精密度はプロジェクト次第
4
EIA/IS-632 によるシステムエンジニアリング
5
コスト、効果、コスト効果
6
システムエンジニアのジレンマ
8
連続改良方式の一例として、「アルファ」のようなスペースステーションの
12
高度選定過程の考察
単純なインターフェースほど望ましい
18
フリフェーズ A
−
22
フェーズ A
−
予備解析段階
23
フェーズ B
−
定義段階
26
最新研究段階
信頼性のある実現可能な設計
27
フェーズ C
−
設計段階
29
フェーズ D
−
開発段階
30
フェーズ E
−
運用段階
31
総合製品開発チーム
37
国防総省の経験から得た SEMP の教訓
52
クリティカルパスとフロート算定
60
ガントチャートの特徴
63
スケジュールずれの影響評価
66
リスク
67
確率的リスク評価の落とし穴
75
ロボット火星偵察ミッションの意思決定樹形図例
77
コンフィギュレーション管理委員会の運営
84
プロジェクトの停止
88
完成見積り（EAC）値の計算
109
惑星探査衛星と打上げロケットの高レベル TPM 例
112
リスク・マネジメント法による衛星質量追跡調査の例
115
システム解析
119
各種機能解析技法
120
火星用ロバーのトレードオフ樹形図例
125
トレード研究報告書
126
解析的階層プロセス
135
多属性有用性理論
136
vii
141
現行割引価格の算定方法
統計的コスト推定関連性：
145
事例と落とし穴
147
学習曲線理論
費用延べ払い関数例：
148
ベータ曲線
トレード研究にシステム効果測定値を使用する場合の実際の落とし穴
150
アベイラビリティの測定
155
ロジスティックス支援性モデル：2 例
157
コスト S 曲線
160
信頼性関係式
165
月探査船（LEM）の信頼性
167
バスタブ曲線
167
宇宙ステーション「アルファ」の各種保全レベル
174
HST 補修作業（STS−61）から得た保全性に関する教訓
176
MIL-STD 1388-1A／2B
183
NASA は CALS で経費節減を図れるか？
185
解析とモデル
190
検証報告書
192
試験準備審査
195
ソフトウェアの IV＆V
198
NEPA とは？
202
SI 単位の接頭辞
238
viii
序文
「料理書」通りにつくっても、おいしい料理がつくれるわけではない。それと同様に、純
粋な論理的思考に頼ることの危険性を示すために、数学者であり、哲学者でもあるカール・
ヘンペルは一つの逆説を提示した。「カラスはどれも黒い色をしている」という仮説を証明し
ようとすれば、多くのカラスを観察し、「どのカラスも黒い」という基準に適合しているかど
うかを調べればよい。ヘンペルは、その仮説を論理的に対偶する仮説に変えるのは簡単だと
言う。つまり、「黒くないものはすべてカラスではない」という新しい仮説になる。論理的思
考の法則に則ったこうした転換は、テストを非常にやりやすくするが、残念ながら笑止千万
なやり方だ。ヘンペルのカラスに関する逆説は、システムエンジニアリングのような複雑か
つ難解な問題に対しても、常識や適切な予備調査の重要性を指摘している。
1989 年、「ＮＡＳＡシステムエンジニアリング・ハンドブック」（NASA Systems Engineering
Handbook）の編纂作業に初めて着手した頃は、システムエンジニアリングに対するＮＡＳＡ
の包括的取り組み方を教示するこの書物に対してその危険性を危惧する声が多かった。ヘン
ペルのカラスのように、経験や常識を無視して論理という幻想を提示する「料理書」のよう
な書物の作成に対しては、かなりの懸念があった。ところが、このハンドブックの初稿（1992
年 9 月）に対して大変な反響（そのコピー請求とこの書物に対する賞賛）があったことから
見ると、当初の懸念はほとんど根拠のないもので、こうしたハンドブックに対する需要の大
きいことがうかがえる。
このハンドブックは、初稿の中で最良と思われたもののみを記載し、ＮＡＳＡ（米国航空
宇宙局＝National Aeronautics and Space Administration)内部から出された勧告や変更事
項に照らして必要な情報を更新したものである。また、ＮＡＳＡ全体からの最良の意見も若
干記載している。このようにして作成されたハンドブックには多くの専門家の意見も反映さ
れ、どんな意見や批判にも漏れなく考慮がなされている。それはまさにＮＡＳＡ全体の作品
であり、ＮＡＳＡのシステムエンジニアリングに関する適切な概説書ともなるものである。
このハンドブックは、ＮＡＳＡの視点から書かれた教育的手引書として編纂されたもので
ある。その主な読者は、まずシステムエンジニアリング講座を受ける人々であり、ＮＡＳＡ
のシステムエンジニアリングに関する手引書を求めている現場の専門家もまた、この書物の
読者となる。
草稿の点検中に、このハンドブックに対してＮＡＳＡ外部からも多くの関心が寄せられて
いることもわかった。諸外国からも翻訳の申し込みが来ている。このハンドブックの草稿を
大学で教材として使いたいという要望もあった。この初稿ハンドブックのコピーが払底した
のは、こうした事情すべてが重なったためであろう。
ix
「ＮＡＳＡシステムエンジニアリング・ハンドブック」（NASA Systems Engineering
Handbook）を編纂する主な目的は、
１） システムエンジニアやプロジェクトマネジャに有益な情報を提供すること
２） 各センター特有の文書と併用できるような、ＮＡＳＡのシステムエンジニアリングに関
する一般的説明書を提供すること
３） システムエンジニアリングのプロセスに関する共通の言語と共通の視点を提示すること
４）ＮＭＩ(NASA Management Instructions ＝ＮＡＳＡ管理手引書)7120.4 やＮＨＢ(NASA
Handbook＝ＮＡＳＡハンドブック)7120.5 とも矛盾しないような参考書を提供することで
ある
このハンドブックでは、ミッションのニーズや概念の検討から運用や処分に至るまですべ
て、システムの視点からシステムエンジニアリングに取り組んでいる。
編纂作業に直接関与された方々すべてにお礼を申し上げることは不可能だが、とりわけジ
ェット推進研究所（Jet Propulsion Laboratory)のロバート・シシュコ博士のご尽力にはお
礼の申し上げようもない。本書が完成したのは、ボブ（ロバートの愛称）の尽力によるとこ
ろが大きい。博士の技術的知識と即決力は、今回のプロジェクトに欠かせない成功要因であ
った。
Mihaly Csikzenthmihali は、最高の経験を「浮き立つような気分や深い喜びが長く心に留
まり、これぞ人生だというものの思い出の一里塚となる」ようなものだと定義している。こ
のハンドブックを編纂した経験がまさにこんな風だったかどうかはよくわからないが、そう
した思いにかなり近いように思われる。
エドワード・Ｊ・ホフマン博士
プログラム・マネジャ
ＮＡＳＡ本部
1995 年春
x
1992 年 9 月の草案における序文
ＮＡＳＡ（米国航空宇宙局）が局内全体に向けてシステムエンジニアリング講座を主催し
始めたころは、その受講者たちも半信半疑の思いであった。真っ先に関心を示したのは、ト
ップ・マネジメントの人々であった。「システムエンジニアリングをどう定義するかも決めら
れないでいる時に、当局全体のシステムエンジニアリングをどうやって教えることができる
のか？」と、元副局長が意見を述べるような状況だった。まさに的を得た質問だった。それ
こそ、当時我々がかなり心配していた点であることは、私も認めざるを得ない。このハンド
ブックが出版されるまでは、そうした疑問が付いて回った。
1989 年１月、ジョンソン宇宙センターにおいてシステムエンジニアリング教育会議が初め
て開催された。この会議には、他のセンターからも多数の代表が参加し、ニーズに合った適
切なシステムエンジニアリング講座の開催を支援する作業グループを結成する必要があると
いう決定が下された。この会議ではまた、マーシャル宇宙センター（ＭＳＦＣ）の代表が、
同センターを離れていくキープレーヤがこれ以上増えないうちにセンター自体のこれまでの
システムエンジニアリングのプロセスを文書化したいという強い要望を表明した。他のセン
ターからも、ＭＳＦＣほど差し迫ってはないにしても、こうしたプロセスを文書化したいと
いう要望が出された。
ＮＡＳＡのシステムエンジニアリングのプロセス全体を反映させ、さらに必要なトレーニ
ングを支援する最良の方法は、システムエンジニアリングの広範な定義、システムエンジニ
アリングのプロセスの広範な概要、標準的なツールと手順などを記載したトップレベル（レ
ベル０）の文書を作成することであると考えられた。一般的に、我々が求めていたのは、Ｎ
ＡＳＡのシステムエンジニアリングに関するトップレベルの概説書である。この文書には、
各センター特有のシステムエンジニアリング・マニュアルを添付する予定だった。作業グル
ープでも、各センターの相違点を十分認識していたが、こうしたやり方ならばまず受け入れ
られるだろうと考えた。
次の段階は、こうした骨の折れる作業過程の中でもとりわけむずかしい段階である、これ
から結成する作業グループの座長にふさわしい人材を見つけることだった。ＮＡＳＡにとっ
て幸運だったのは、ジェット推進研究所（ＪＰＬ）のドンナ・［ピビロット］・シャーレイ氏
がこの困難な任務を引き受けてくださったことである。同氏の努力、作業グループの奮闘、
献身的な熟練執筆者たちのおかげで、ユニークで、おそらく歴史的にも重要なものとなるで
あろう文書がここに作成されたのである。
このマニュアルの作成中、将来この文書を常時改良できるようにと、我々はレベル０の文
書に相当するものよりもはるかに多くのものをこの文書に盛り込むことにした。さらに重要
な点は、将来の普及に備えて、できる時に知識を吸収することだった。何らかの批判がある
とすれば、そのマニュアルに導入された詳細度についてだろうが、こうした詳細度は若い技
術者にとっては必要なものだ。現在の文書は、当初の趣旨をはるかに越えてはいるが、適切
xi
な教育的手引書として大いに役立つであろう。
したがって、本書は最終稿に近いものとみなすべきである。皆様からのご意見、ご指摘、
ご提案を大いに歓迎し、評価の上採択させていただくことになっている。下記宛てに皆様の
ご意見を直接お送りいただきたい。
Robert Shishko, NASA Systems Engineering Working Group, NASA/Jet Propulsion
Laboratory, California Institute of Technology, 4800 Oak Grove Drive, Pasadena, CA
91109-8099
フランシス・Ｔ・ホバン
プログラム・マネジャ
ＮＡＳＡ本部
xii
緒言
このハンドブックが作成されたのは、ＮＡＳＡのシステムの特質とＮＡＳＡの環境を認識
できるように、システムエンジニアリングの基本概念と技法をＮＡＳＡの職員に説明するた
めである。執筆者たちは、こうした目的が容易には達成されそうにないことを率直に認めて
いる。その一因は、システムエンジニアリングとはどんなものなのか、それをどのように実
施するのかという点についてすべての関係者の間に合意が得られていない点にある。基本的
定義、内容、技法に関しては、筋の通った意見の違いが認められる。システムエンジニアリ
ング自体は、多彩な側面を備えた幅広い学問である。この初版ハンドブックではそれらすべ
てを扱ってはいない（また扱うことはできない）。
このハンドブックの内容と形式は、教育の方向性を示すものである。このハンドブックは、
システムエンジニアリングに関するＮＡＳＡの正式トレーニング講座に使用するもので、Ｎ
ＡＳＡのシステムエンジニアリングに関する総合的概説書として単独に使用するものではな
かった。執筆者たちの意見によると、システムエンジニアリングは、明確に記載された序論
から始めて、課題から課題へと継ぎ目なく進むだけでは習得できるものではない。どちらか
といえば、多くの工学分野やその他の知識分野から派生した分野である。そのため、各分野
の境界線は必ずしもはっきりせず、興味深い知識の支脈も多い。そのようなわけで、このハ
ンドブックは、一学問分野としてのシステムエンジニアリングに関する「トップレベルの解
説書」として編纂されたものである。つまり、説明を簡潔にすることと、詳細については他
の書物や文書の参照指示を与えることが重要な指針と考えられている。
このハンドブックに使用した資料は、多種多様な源泉から得たものである。つまり、フィ
ールドセンターで採用している各種システムエンジニアリング・ハンドブック、ＮＡＳＡ管
理手引書（ＮＭＩ＝NASA Management Instructions）とＮＡＳＡハンドブック（ＮＨＢ＝NASA
Handbook)、システムエンジニアリングのプロセスに関する各フィールドセンターの概況説明
書、ＮＡＳＡ以外で採用しているシステムエンジニアリングに関する教科書や解説書、ＮＡ
ＳＡの受講生向けシステムエンジニアリング３講座などである。このハンドブックでは、こ
うした資料を駆使し、良好なシステムエンジニアリング業務遂行に必要なトップレベルの情
報と提言のみを提示している。だが、決して指導書として作成されたものではない。
編集上、このハンドブックでは、プロジェクトマネジメント／プログラムコントロール（Ｐ
Ｍ／ＰＣ＝Project Management/Program Control）講座でも教えるいくつかの課題も扱い、
こうした３分野の避けがたい関連性を反映させている。ＮＡＳＡのプロジェクト・ライフサ
イクルに関する資料は、1991 年と 1992 年に定期的に会合を持った全ＮＡＳＡシステムエンジ
ニアリング作業グループ（ＳＥＷＧ＝Systems Engineering Working Group)と、その後を継
ぎ、1993 年と 1994 年に会合を持ったシステムエンジニアリングプロセス改良作業（ＳＥＰＩ
Ｔ＝Systems Engineering Process Improvement Task)チームの作業から得たものである。こ
のハンドブックに記載されたプロジェクト・ライフサイクルは、ＳＥＰＩＴ（Systems
xiii
Engineering Process Improvement Task)報告書「プログラムやプロジェクトのためのＮＡＳ
Ａシステムエンジニアリングのプロセス」（NASA Systems Engineering Process for Programs
and Projects）(JSC-49040）に記載されたものと同じである。ＳＥＰＩＴのプロセス・ライ
フサイクルは、ＮＭＩ（NASA Management Instructions) 7120.4/ ＮＨＢ(NASA Handbook)
7120.5（主要システムのプログラムとプロジェクトのマネジメント）のプロセス・ライフサ
イクルと意図的に一致させているが、システムエンジニアリングの諸側面については一層詳
細なものになっている。
このハンドブックは主として次の５章からなる：
（１） システムエンジニアリングの知的プロセス
（２） ＮＡＳＡのプロジェクト・ライフサイクル
（３） システムエンジニアリングのマネジメント
（４） システムの解析およびモデル作成
（５） 技術の専門性の統合
この主要５章にはそれぞれ付録が添付され、各章の課題を説明するテンプレートと例に合
わせて拡大できる。このハンドブックでは、読者を主題からそらせないで主要５章に記載さ
れた各種概念の定義、改良、説明、拡張を行うために、枠内記事を多用している。脚注は使
用せず、その代わりに枠内記事を使用している。このハンドブックの構成は、今後必要な章
や条項を追加できるようになっている。
最後に、このハンドブックは出発点にすぎないとみなすべきものである。システムエンジ
ニアリング機関としてのＮＡＳＡも、一学問分野としてのシステムエンジニアリングも、急
速に進展している。今後５年間に多くの変化が生じるのは確実であり、すでに進歩している
ものもある。たとえば、ＮＡＳＡでは国際標準機構（ＩＳＯ＝International Standards
Organization）の規格 ISO9000 ファミリを採用する方向へ動いている。この規格は、今後シ
ステムエンジニアリングの多くの面に影響を及ぼす。学問分野としてのシステムエンジニア
リングでは、既存のシステムエンジニアリング規格をまず共通の「システムエンジニアリン
グの米国規格」と併合し、最終的には国際規格に併合する努力が進められている。このハン
ドブックを使用する際には、こうした点を念頭に置いていただきたい。
xiv
謝辞
今回の編纂作業は、ＮＡＳＡプログラム／プロジェクト・マネジメント構想（ＰＰＭＩ＝
Program/project Management Initiative)の一環として、まずＮＡＳＡ（米国航空宇宙局）
本部／コードＦＴのフランク・ホバン氏、次いでエド・ホフマン博士の総指揮の下で実施さ
れた。ＮＡＳＡ本部／コードＱＷのシャヒド・ハビブ博士も、全ＮＡＳＡシステムエンジニ
アリング作業グループ（Systems Engineering Working Group)とシステムエンジニアリング
プロセス改良作業（Systems Engineering Process Improvement Task）チームに追加的な財
政的支援をしてくださった。ＮＡＳＡの内部及び外部の多くの方々にも、資料提供や各種草
稿の点検をお引き受けいただき、このハンドブックに貴重なご意見をお寄せいただいた。ご
意見やご経験をお寄せくださったすべての方々を以下のリストにお載せできなかったことを、
誠に残念に思う。
主な寄稿者：
Dr. Robert Shishko, NASA/Jet Propulsion Laboratory
Mr. Robert G. Chamberlain, P.E., NASA/Jet Propulsion Laboratory
その他の寄稿者：
Mr. Robert Aster, NASA/Jet Propulsion Laboratory
Ms. Beth Bain, Lockheed Missiles and Space Company
Mr. Guy Beutelschies, NASA/Jet Propulsion Laboratory
Dr. Vincent Bilardo, NASA/Ames Research Center
Ms. Renee I. Cox, NASA/Marshall Space Flight Center
Dr. Kevin Forsberg, Center for Systems Management
Dr. Walter E. Hammond, Sverdrup Technology, Inc.
Mr. Patrick McDuffee, NASA/Marshall Space Flight Center
Mr. Harold Mooz, Center for Systems Management
Ms. Mary Beth Murrill, NASA/Jet Propulsion Laboratory
Dr. Les Pieniazek, Lockheed Engineering and Sciences Co.
Mr. Lou Polaski, Center for Systems Management
Mr. Neil Rainwater, NASA/Marshall Space Flight Center
Mr. Tom Rowell, NASA/Marshall Space Flight Center
Ms. Donna Shirley, NASA/Jet Propulsion Laboratory
Mr. Mark Sluka, Lockheed Engineering and Sciences Co.
Mr. Ron Wade, Center for Systems Management
xv
ＳＥＰＩＴチームのメンバー（上に挙げた以外の方）：
Mr. Randy Fleming, Lockheed Missiles and Space Co.
Dr. Frank Fogle, NASA/Marshall Space Flight Center
Mr. Tony Fragomeni, NASA/Goddard Space Flight Center
Dr. Shahid Habib, NASA Headquarters/Code QW
Mr. Henning Krome, NASA/Marshall Space Flight Center
Mr. Ray Lugo, NASA/Kennedy Space Center
Mr. William C. Morgan, NASA/Johnson Space Center
Dr. Mike Ryschkewitsch, NASA/Goddard Space Flight Center
Mr. Gerry Sadler, NASA/Lewis Research Center
Mr. Dick Smart, Sverdrup Technology, Inc.
Dr. James Wade, NASA/Johnson Space Center
Mr. Milam Walters, NASA/Langley Research Center
Mr. Don Woodruff, NASA/Marshall Space Flight Center
その他の協力者：
Mr. Dave Austin, NASA/Headquarters/Code DSS
Mr. Phillip R. Barela, NASA/Jet Propulsion Laboratory
Mr. J.W. Bott, NASA/Jet Propulsion Laboratory
Dr. Steven L. Cornford, NASA/Jet Propulsion Laboratory
Ms. Sandra Dawson, NASA/Jet Propulsion Laboratory
Dr. James W. Doane, NASA/Jet Propulsion Laboratory
Mr. William Edminston, NASA/Jet Propulsion Laboratory
Mr. Charles C. Gonzales, NASA/Jet Propulsion Laboratory
Dr. Jairus Hihn, NASA/Jet Propulsion Laboratory
Dr. Ed Jorgenson, NASA/Jet Propulsion Laboratory
Mr. Richard V. Morris, NASA/Jet Propulsion Laboratory
Mr. Tom Weber, Rockwell International/Space Systems
点検者：
Mr. Robert C. Baumann, NASA/Goddard Space Flight Center
Mr. Chris Carl, NASA/Jet Propulsion Laboratory
Dr. David S.C. Chu, Assistant Secretary of Defense/Program Analysis and Evaluation
Mr. M.J. Cork, NASA/Jet Propulsion Laboratory
Mr. James R. French, JRF Engineering Services
xvi
Mr. John L. Gasery, Jr., NASA/Stennis Space Center
Mr. Frederick D. Gregory, NASA Headquarters/Code Q
Mr. Don Hedgepeth, NASA/Langley Research Center
Mr. Jim Hines, Rockwell International/Space Systems
Mr. Keith L. Hudkins, NASA Headquarters/Code MZ
Dr. Jerry Lake, Defense Systems Management College
Mr. T.J. Lee, NASA/Marshall Space Flight Center
Mr. Jim Lloyd, NASA Headquarters/Code QS
Mr. Woody Lovelace, NASA/Langley Research Center
Dr. Brian Mar, Department of Civil Engineering, University of Washington
Dr. Ralph F. Miles, Jr., Center for Safety and System Management, University of
Southern California
Dr. Richard A. Montgomery, Montgomery and Associates
Mr. Bernard G. Morais, Synergistic Applications, Inc.
Mr. Ron Moyer, NASA Headquarters/Code QW
Mr. Rudy Naranjo, NASA Headquarters/Code MZ
Mr. Raymond L. Nieder, NASA/Johnson Space Center
Mr. James E. Pearson, United Technologies Research Center
Mr. Leo Perez, NASA Headquarters/Code QP
Mr. David Pine, NASA Headquarters/Code B
Mr. Glen D. Ritter, NASA/Marshall Space Flight Center
Dr. Arnold Ruskin, NASA/Jet Propulsion Laboratory and University of California at
Los Angeles
Mr. John G. Shirlaw, Massachusetts Institute of Technology
Mr. Richard E. Snyder, NASA/Langley Research Center
Mr. Don Sova, NASA Headquarters/Code AE
Mr. Marvin A. Stibich, USAF/Aeronautical Systems Center
Mr. Lanny Taliaferro, NASA/Marshall Space Flight Center
編集・グラフィック面の支援者：
Mr. Stephen Brewster, NASA/Jet Propulsion Laboratory
Mr. Randy Cassingham, NASA/Jet Propulsion Laboratory
Mr. John Matlock, NASA/Jet Propulsion Laboratory
ロバート・シシュコ博士
タスク・マネジャ
ＮＡＳＡ/ジェット推進研究所（Jet Propulsion Laboratory)
xvii
１．
序論
1.1
目的
このハンドブックは、ＮＡＳＡ（National Aeronautics and Space Administration ＝
米国航空宇宙局）のシステムエンジニア、特に新人のシステムエンジニアにとって役立つ
システムエンジニアリングの情報を提供する。本書の主な目的は、ＮＡＳＡ全体に「適用
すべき」システムエンジニアリングの一般的解説を行うことにある。各フィールドセンタ
ーのハンドブックは、各センター独自の実施面について詳細に説明するのが望ましい。
本書を手近に置いて使用するＮＡＳＡのシステムエンジニアにとっては、このハンドブ
ックが他では容易に見つからないような解答を提供してくれるはずである。つまり、この
ハンドブックは、ＮＡＳＡ独自の視点とＮＡＳＡ特有のデータを提供するものである。可
能であれば、ＮＡＳＡ管理手引書（ＮＭＩ＝NASA Management Instructions）も参照され
たい。
このハンドブックのもう一つの目的は、ＮＡＳＡ主催の各種システムエンジニアリング
講座すべてに役立つ参考書として使用することにある。
1.2
適用範囲と詳細度
システムエンジニアリングの内容は多岐にわたる。しかし、このハンドブックで扱うも
のは、一般的概念と、プロセス、ツール、技法に関する一般的説明に限定される。このハ
ンドブックでは、良好なシステムエンジニアリング業務遂行と回避すべき落とし穴に関す
る情報も提供する。詳細な指導を行う際に参照できる教科書は多数ある。
このハンドブックでは、ＮＡＳＡの主要システム開発に適用すべきシステムエンジニア
リングについて記述する。システムエンジニアリングでは、開発されるもののシステム（製
品システム）と開発を行うシステム（生産システム）の両方を扱う。したがって、このハ
ンドブックの適用範囲には、局内のシステムエンジニアリング組織、プログラム／プロジ
ェクト担当部署、システムの契約者のいずれが実施するにせよ、システムエンジニアリン
グの各種機能も当然含まれる。
生産システムの設計特性の多くは、システムエンジニアリングのツールと技法の特性に
応じて異なる。だが、それらの適用の制度化した手順を、ＮＡＳＡの全フィールドセンタ
ーで統一しなければならないというわけではない。
- 1 -
システムエンジニアリングに関する文献
全参考資料とその他推奨文献については、「参考文献」の項を参照されたい。
システムエンジニアリングの基礎：
"Systems Engineering and Analysis"（第２版）、B.S. Blanchard、W.J. Fabrycky 共著。
"Systems Engineering"、Andrew P. Sage 著。
"An Introduction to Systems Engineering"、J.E. Armstrong、Andrew P. Sage 共著。
システムエンジニアリングのマネジメント：
"Systems Engineering"、EIA/IS-632。
"IEEE Trial-Use Standard for Application and Management of the Systems Engineering
Process"
IEEE (Institute of Electrical and Electronics Engineers＝米国電気電子
学会）規格 1220-1994。
"Systems Engineering Management Guide"、Defense Systems Management College。
"Systems Engineering Management"、B.S. Blanchard 著。
"Systems Engineering Methods"、Harold Chestnut 著。
"Systems Concepts"、Ralph Miles, Jr.編。
"Successful Systems Engineering for Engineers and Managers"、Norman B. Reilly 著。
システムの解析とモデル作成：
"Systems Engineering Tools"、Harold Chestnut 著。
"Systems Analysis for Engineers and Managers"、R. de Neufville､ J.H. Stafford 共
著。
"Cost Considerations in Systems Analysis"、Gene H. Fisher 著。
宇宙システムの設計と運用：
"Space Vehicle Design"、Michael D. Griffin、James R. French 共著。
"Space Mission Analysis and Design"（第２版）、Wiley J. Larson､ James R. Wertz 共
編。
"Design of Geosynchronous Spacecraft"、Brij N. Agrawal 著。
"Spacecraft Systems Engineering"、Peter W.
Fortescue、John P.W. Stark 共編。
"Cost-Effective Space Mission Operations"、Daryl Boden､ Wiley J. Larson 共編。
"Reducing Space Mission Cost"、Wiley J. Larson､James R. Wertz 共編。
- 2 -
２.
2.1
システムエンジニアリングの基礎
システム、スーパーシステム、サブシステム
「システム」とは、共通の目的に向けて組織的に相互作用する１組の関連した構成要素
である。１つのシステムを構成する要素は多種多様であり、人間、組織、手順、ソフトウ
ェア、設備、施設などからなる。システムの目的は、宇宙機の電力の分配といった小さな
ものから火星表面の探査といった壮大なものまである。
階層的システム用語
全ＮＡＳＡシステムエンジニアリング作業グループ（SEWG=NASA-wide Systems Engineering
Working Group)とその後継グループであるシステムエンジニアリング・プロセス改良作業
（SEPIT=Systems Engineering Process Improvement Task）チームでは、順次細分化され
たものを示すために次のような階層的順位の用語を採用してきた。
システム(System)
セグメント(Segment)
エレメント(Element)
サブシステム(Subsystem)
アセンブリ(Assembly)
サブアセンブリ(Subassembly)
部品(Part)
特定のプロジェクトでは、これとは異なる一連の階層を必要とすることもある
−
１つ
の機器ではそれほど多くの階層を必要としないが、大規模な構想ではもっと多くの階層に
区分する必要がある。各プロジェクトでは、それぞれ独自の用語を設定すべきである。本
文に明記したように、ＮＡＳＡ（米国航空宇宙局）内部では「システム」という用語を一
般名として使用することもある。このハンドブックでも、通常、「システム」という用語を
一般名として使用している。
各システムは、もっと大きな「スーパーシステム」、つまり関連システムの集合体の中に
存在する。各システムはその集合体の中で判断しなければならない。したがって、そうし
たスーパーシステムの中で、管理者たちはシステムの方針を立て、システムの目的を設定
し、システムの制約を決め、適切なコストを定める。多くの場合、このような管理者はシ
ステムの設計や運用上の決定事項に対する監視権限を持つ。
ＮＡＳＡ（米国航空宇宙局）のほとんどのシステムは、サブシステムといういくつもの
構成要素からなる極めて複雑なものであり、システムがその目標を達成するためには、こ
れらのサブシステムが一定の秩序を整えるよう機能しなければならない。システムエンジ
- 3 -
ニアリングの視点から見ると、各サブシステムも本来１つのシステムである
−
つまり、
階層組織上の次の上位レベルにおいて方針、要求事項、目的、関連コスト項目などが設定
される。宇宙機システムは、たいてい「推進」、「姿勢制御」、「通信」、「電力」といったサ
ブシステムによって構成される。大型プロジェクトでは、サブシステム自体を「システム」
という傾向がある。上に明記したように、ＮＡＳＡ内部では「システム」という用語を一
般名として使用することもある。このハンドブックでも、通常、「システム」という用語を
一般名として使用している。
「主要」システムの取得に関するＮＡＳＡ管理手引書(NASA Management Instructions) (Ｎ
ＭＩ 7120.4)では、「プログラム」を「焦点を合わせた科学的または技術的な目標を追求す
るか支援するために立案され、特定期間（通常は数年間）継続する、システムの設計、開
発、運用を特徴とする一連の引き受けた仕事」と定義している。プログラムはＮＡＳＡ本
部により管理されるが、数件のプロジェクトを伴うこともある。
ＮＡＳＡでは、「プロジェクト」は、１つまたは２つ以上のシステムの設計、開発、運用
からなり、通常はＮＡＳＡのフィールドセンターにより管理される。
ＮＡＳＡ本部のマネジメントは、各システムのエンジニアリングはもとより、希望の目
標を達成するために必要なその他すべての活動に関与する。プログラムやプロジェクトの
重要性を議会に説明したり、国際協力を得ることも、その他の活動に入る。「ミッション」
という用語は、プログラムやプロジェクトの目的上よく使用される。この語が情熱という
意味を暗示させるため、この用語の情緒的語感が好まれる政治的活動には特に適している。
日常会話では、「プロジェクト」、「ミッション」、「システム」という用語はしばしば互換的
に使用されている。正確な用法ではないが、問題となることは滅多にない。
システムエンジニアリングの実施上必要となる技術的精密度はプロジェクト次第である
・ システムの目標は単純で、特定や評価がしやすいことがある。また、技術的に複雑で、
システムを運用する環境や技術に対する深い洞察力を必要とする場合もある。
・ システムの目標が１つしかない場合もあれば、多数ある場合もある。多数の目標の相
対価値を評価できる技法はいくつかあるが、時にはそうした目標を比較することも定
量化することもできない場合もある。
・ 対立する目的を持つ党派の代表者がシステムのユーザーになる場合もある。目的が対
立する場合は、交渉により妥協することも必要である。
・ システムの設計概念案が多数ある場合もあれば、その開発のために創造性のある天才
を必要とする場合もある。
・ 目標を達成するために各設計概念案がどの程度役立つかを予測するには、「封筒の
裏」を使って簡単な計算を行うだけですむ場合もあれば、ハードウェアやソフトウェ
アのモデルを作成して試験を行うことで信頼性を評価する場合もある。
・ 希望の目的には、通常、「ライフサイクル・コストをできるかぎり削減する」とか「得
られたデータの価値をできるかぎり高める」といった最適化という目的も含まれる。
そのため、最適設計の選定が生易しい業務とはならないこともある。
- 4 -
2.2
システムエンジニアリングの定義
「システムエンジニアリング」は、システムの設計、製作、運用を行うためのロバスト
なアプローチである。端的に言えば、このアプローチは、システムの目標の特定と定量化、
システム設計概念案の創案、設計トレードの実施、最適設計の選定と実施、設計が適正に
構築され、完成したかどうかを調べる検証、システムが目標にどの程度適合する（または
適合している）かどうかを調べる実施後評価などからなる。通常、このアプローチは繰り
返し何度も実行され、システム・ベースライン（要求事項、設計細部、検証手順と検証基
準、コストと性能の予測などを含む）の解決策がいくつか増えることになる。
EIA/IS-632 によるシステムエンジニアリング
システムエンジニアリングとは、「顧客のニーズを満たすために、システムの関係者、製
品、そのプロセスに対するライフサイクル全体にわたりバランスの取れた総合的な一連の
解決策を展開し検証するための技術的活動全体を網羅する学際的アプローチである。
システムエンジニアリングとしては、
（ａ）システム製品とそのプロセスに関する開発、製造、検証、展開、運用、支援、
廃棄、ユーザー・トレーニングに関連のある技術的活動
（ｂ）システムコンフィギュレーションの定義とマネジメント
（ｃ）作業明細構成(WBS)へシステムの定義を移す作業
（ｄ）マネジメントの意思決定に必要な情報の開発などがある。」
システムエンジニアリングは、システムマネジメントと協力して実施する。システムエ
ンジニアの主な役割は、システムマネジャが正しい決定を下せるような情報を提供するこ
とである。この役割には、システムマネジャが最初に設計概念案を選定し、次にそれらを
抜け目なく採用できるように、設計概念案を特定し、その設計概念案の特性表示を行うこ
とも含まれる。この役割の重要な側面は、コスト、性能、リスクなど、さまざまな次元か
らそうした設計概念案の評価を行いやすくするようなシステム・モデルを作成することで
ある。
このアプローチの適用としては、開発中のコンフィギュレーションに対するコントロー
ルの継続や各サブシステムの統合化に対する監督など、一部の委託マネジメント業務が含
まれる。
2.3
システムエンジニアリングの目的
システムエンジニアリングの目的は、性能、コスト、スケジュール、リスクを考慮した
上で、できるかぎりコスト効果のある方法でシステムの目的を達成するように、システム
- 5 -
が設計、製造、運用されることを確かめることである。
コスト効果のあるシステムとは、効果とコストの間である種のバランスを保つものでな
ければならない。つまり、使用された資源に対して最大の効果をもたらすもの、同等に得
られた効果に対して最低の費用ですむものでなければならない。通常多くの設計はこれら
の条件を満たしているので、この条件は決して厳しいものではない。ここで、効果とコス
トのトレード（兼ね合い）空間の中の１点として、各設計案を考えてみよう。コストの関
数としての現在の技術で得られる設計の「最大」到達効果を示すグラフは、一般的には、
図１に示すような曲線になるであろう。（この図では、あらゆる効果面を縦座標で示し、あ
らゆるコスト面を横座標で示している）。別の言い方をすると、この曲線は、現在利用でき
る技術の範囲をコスト効果で示すものと言えよう。
コスト
システムのコストとは、システムの設計、製造、運用に必要となる経営資源にかかった価
額である。そうした経営資源はいろいろな形（ＮＡＳＡの職員や契約相手方が実施する作
業、原材料、動力、さらに風洞、工場、事務室、コンピュータなどの施設と設備の使用）
で投入されるので、経営資源の価額を何れかの通貨単位（ドルなど）によって共通の条件
として表記する方が便利な場合が多い。
効果
システムの効果とは、システムの目的がどの程度達成されたかを示す量的尺度である。効
果の尺度は、通常、システムの性能に左右される面が大きい。たとえば、打ち上げロケッ
トの効果は、ペイロードを使用可能な軌道上にうまく投入できる確率に左右される。それ
に関連のあるシステムの性能特性としては、特定のノミナル軌道へ乗せられる質量、投入
質量と打ち上げ速度のトレード（兼ね合い）、打ち上げの可能性などがある。
コスト効果
システムのコスト効果とは、システムの対象に応じてシステムのコストと効果を組み合わ
すものである。コストと効果のいずれか一方または両方をいくつかの数値で評価する必要
がある場合もあれば、設計を最適条件で使用するためにこの両要素を組み合わせて有意の
単一値からなる「目的関数」を形成できる場合もある。コストと効果の兼ね合いをどう図
るかわからなくても、低コストで高い効果をあげられる設計はつねに望ましいものである。
曲線より上にある点（設計）は、在来の技術では達成できないものである
−
つまり、
実行可能な設計を示すものではない。（ただし、「将来」技術がもっと進歩すれば、こうし
た点のいくつかは実行可能なものとなろう）。包絡線の内側にある点は実行可能なものだが、
包絡線上にあるコストと効果を合わせ持つ設計が優位を占める。包絡線上の点で示される
設計は、コスト効果のある（または効率的、非支配的）解決策と呼ばれる。
- 6 -
トレード空間のこの部分
にある設計は、成果を生
まないものである
効果
トレード空間のこの部分に
ある設計は、在来型技術で
成果を生むものである
コスト
図１
優先的設計の包絡面
システムエンジニアリングのプロセスの重要部分となる設計トレード研究では、コスト
と効果のさまざまな面からより良い組み合わせとなる設計を見つけようとする場合が多い。
設計トレード研究の出発点が包絡線の内側にある場合は、何らかの効果面を低下させずに
コストを引き下げる設計案や、コストも引き上げず、他の効果面も低下させずに何らかの
効果面を高める設計案がいくつかある。その場合は、システムマネジャやシステムエンジ
ニアも決定を行いやすい。そうした「両方とも満足のいく」設計トレードは、サブシステ
ムのサイズを決定する作業以外には普通見られないが、決して珍しくはない。しかし、設
計トレード研究においてコストと効果のトレードや、同一コストで一方の効果面と他方の
効果面のトレードを行う必要がある設計案の場合は、決定がむずかしくなる。
効
果
Ａ
Ｂ
Ａ、Ｂ、Ｃはリス
クパターンを異
にする設計概念。
Ｃ
コスト
図２
不確実性を伴う設計概念から
得られる推定結果
コスト効果が最も高い設計を見つけ出すプロセスは、不確実性により一層複雑化する。
それを、図１の変形である図２に示す。特定のシステム設計からどんな結果が正確に得ら
れるかは、確実に予測することはできない。そのため、設計の予測コストと予測効果は、
座標点を使うよりも確率分布を使う方が、より正しく示すことができる。この確率分布は、
- 7 -
図２に設計概念Ａとして示すように、確率の最も高い値が一番濃く、その点から離れるほ
ど薄くなるという一つの雲（cloud)と考えられる。不確実性をほとんど伴わない設計から
得られる確率分布は、設計概念Ｂで示すように、濃くかつ非常にコンパクトである。「リス
クの高い」設計に関する確率分布は、設計概念Ｃとして低効果・高コストの雲模様が付加
して存在するように、非常に望ましくない結果を生む確率が高いと思われる。（もちろん、
そうした雲模様の包絡線は図に示すような鮮明な線にならず、どちらかというと「ぼやけ
た」線にならざるを得ない。その場合の包絡線は、設定した信頼度水準
の効果を達成する確率ｘ
−
−
つまり、そ
における包絡線を示すものと考えられる）。
「効果」も「コスト」も、いくつかのその性質を示すキーワード（descriptors）を必要
とする場合がある。「エコー」のバルーンでさえ、通信衛星としての主要ミッションの他に、
電磁環境と大気の空気抵抗に関する科学データを収集している。さらに、「エコー」自体は、
定量化できない（しかし、認識されないものではない）効果面である肉眼でも見えるとい
う最初の衛星であった。コストという限られた経営資源の経費は、資金、人材、施設の使
用などいくつかの面から評価することもできる。「スケジュール」は効果やコストの属性と
して、また一つの制約として示すこともできる。たとえば「スプートニク」は、「最初の」
人工衛星だという事からその効果の多くを引き出した。火星探査ミッションは打ち上げ時
間帯を逃すと次の機会まで２年ほど待つ必要がある
−
これは、明らかなスケジュール
上の制約である。「リスク」は、実現される効果、コスト、適時性、予算に伴う不確実性か
ら生じる。
システムエンジニアのジレンマ
各コスト効果の解決では、
・リスクを一定にしてコストを引き下げるには、性能を落とさなければならない
・コストを一定にしてリスクを低下させるには、性能を落とさなければならない
・性能を一定にしてコストを引き下げるには、高いリスクも受け入れなければならない
・性能を一定にしてリスクを低下させるには、高いコストも受け入れなければならない
こうした情況においては、スケジュール上の時間がしばしば重要な経営資源となるため、
「スケジュール」が一種のコストのような働きをする
時には、効果／コスト比の最も高いシステムが最も望ましいという場合もある。しかし、
効果／コスト比が意味を持たないか、（さらに悪いことに）誤った方向へ導くこともありう
る。効果／コスト比を有効かつ意味のあるものにするには、それをシステムのコストとは
別に単独に算定しなければならない。さらに、その場合には、効果の単一尺度とコストの
単一尺度しか必要でない。そうした単一評価から得られた数値が確率分布により不明確な
ものになれば、その効果／コスト比も不確実なものとなり、２つの数値の比という単純な
単一値がもたらした実効性が失われる。
- 8 -
所定の予算内でできるかぎり高い効果を求める方がよい場合もあれば、特定の効果のた
めにできるだけ低コストを求める方がよい場合もある。こうした場合には、どの程度の効
果を指定すべきか、どの程度のコストを設定すべきかという問題が生じる。実際上、この
効果やコストは、要求性能や要求コストという形で指定できる。その場合は、これらの要
求を多少ゆるめるだけでシステムをかなり安く生産できるのかどうか、資源をもう少し増
やせばずっと効果的なシステムを生産できるのかどうかという点を考慮するのが適切であ
る。
通常、システムマネジャは、多くの属性面を異にするいくつかの設計から選択しなけれ
ばならない。そうしたマネジャたちがいくつかの属性から好ましいものを選び出し、相対
価値に対する主観的評価を定量化する方法が、各種開発されている。そのような方法が採
用できれば、属性間のトレードも定量的な評価ができる。しかし、属性の定量的評価がで
きない場合も多い。その場合でも、マネジャたちは、属性の数が多くとも決定を下さなけ
ればならない。
2.4
システムエンジニアリングの関連分野
第 2.2 項で行ったシステムエンジニアリングの定義は、橋の設計者や無線技師、さらに
委員会の議長が対処するような設計業務にも適用できよう。システムエンジニアリングの
プロセスは、こうしたすべての業務の一部にはなりうるが、業務全体となることはない
−
橋の設計者はコンクリートや鉄鋼の特性を知らなければならない。無線技師はマックスウ
ェルの方程式を適用しなければならない。委員会の議長は委員たちの個性を理解していな
ければならない。実際のシステム最適化では、さまざまな学問分野の専門家たちと協力し
なければならない。この項の残りでは、そうした分野の一部をシステムエンジニアリング
と対比する。
システム「エンジニアリング」の役割は、システム「マネジメント」の役割とは異なる。
エンジニアリングは解析、勧告、企画を行う機能であるが、マネジメントは意思決定を行
う機能である。同じ人物がこの両方の役割を果たすこともあるので、このような区分が無
意味な場合も非常に多い。解析を必要としないで、いかなる要素も意思決定の過程に導入
しない場合は、システムマネジメントでは管理責任の一部をシステムエンジニアリングの
職務に委託することもできる。
「システム」エンジニアリングは、「設計」エンジニアリングと呼ばれるものとも異なる。
システムエンジニアリングでは、その対象をどのように達成すべきかという問題の詳細な
内容を扱うよりもむしろ、設計されるもの（システム）とそのスーパーシステム（環境）
やサブシステムとの関係を扱う。システムという視点は、深いというよりもむしろ広いも
のである。それは、機能的にはシステムの端から端まで、時間的には概念から廃棄までを
包含するものである。
- 9 -
機能面の専門知識や専門的な解析方法に関しては、システムエンジニアは、従来の設計
分野はもとより、「専門工学」分野からの寄与に頼らなければならない。こうした専門工学
分野としては通常、信頼性、保全性、ロジスティックス、試験、製造、輸送、ヒューマン・
ファクター、品質保証、安全工学などがある。専門技術者たちは、システムエンジニアリ
ンクのプロセス全体にわたり貢献する。システムエンジニアの仕事の一部は、これらの機
能がプロジェクトの中へ適時に統一をとって導入され、それぞれの担当問題に取り組んで
いるかどうかを監視することである。第６章の対象の一つは、こうした専門技術者がシス
テムエンジニアリングの対象にどのように寄与するかという点を明らかにすることである。
システム「解析」とシステム「エンジニアリング」の両分野では、システムの創造に利
用できる経営資源の量と種類を想定し、決定すべき事項に加える。システムエンジニアリ
ングでは、ハードウェアとソフトウェアの構成と、サブシステム間のインタフェースの開
発とマネジメントに集中し、一方数学的モデルの作成と、設計案の評価や実際の設計のト
レード研究の実施に必要なデータの解析はシステム解析に頼る。システム解析では、オペ
レーションズ・リサーチ、経済学、その他の「意思決定学」からのツールを使用する必要
がある。システム解析の教科課程としては、通常、確率、統計、意思決定理論、待ち行列
理論、ゲーム理論、線形および非線形計画法などがある。多くのシステムエンジニアは、
実際には、意思決定学よりもむしろ工学分野の学識の方が豊かである。そのため、システ
ムエンジニアたちは往々にして、システム解析の生産者になるよりもむしろ消費者になる
傾向がある。第５章の対象の一つは、システム解析の最新技法に関する解説と評価を行う
ことである。
「オペレーションズ・リサーチ」と「オペレーションズ・エンジニアリング」では、構
成要素は全く変えられないと思われるシステムのみに目を向ける。つまり、システムの運
用に必要な経営資源は変えられないが、その使用方法は最適化すべきであると想定されて
いる。オペレーションズ・リサーチ技法は、システム設計の最適化においてしばしば強力
なツールとなる。
ＮＡＳＡ（米国航空宇宙局）内部では、プロジェクトのミッションを何にすべきか、ど
う実施すべきかという問題解決に関係のあるすべての研究や設計作業を表わすのに、「ミ
ッション解析」や「エンジニアリング」といった用語を使うことが多い。この用語の適用
範囲が、未来のプロジェクトに関する研究に限定されることもある。また、そうした名称
を持つ組織の設立許可には、システムの可能性の監視、重要事項の見落としがなかったか
どうかの確認、主要システム間のトレードの監視などが記載されることもある
−
つま
り、オペレーションズ・リサーチ、システム解析、システムエンジニアリングの全活動が
網羅されている。
総合的品質マネジメント（ＴＱＭ＝Total Quality Management）とは、作業環境に対し
てシステムエンジニアリングを適用することである。すなわち総合的品質マネジメント（Ｔ
- 10 -
ＱＭ）のパラダイムの一部は、運用組織はある種のシステムで、システムとして工学的に
扱われるべきであることの実現である。この適用領域に対しては、多彩な専門ツールが開
発されている。その多くは確立したシステムエンジニアリング用ツールとして認められて
いるが、それぞれ異なった名前がついている。たとえば、顧客のニーズを満たすことに集
中せよという指示は、同じようないくつかの用語で表わされる。統計的プロセスコントロ
ールを採用することは、技術的性能と収得した価値を測定することによく似ている。もう
一つの方法である品質機能展開（ＱＦＤ＝Quality Function Deployment）は、システムエ
ンジニアリングにおいてしばしば使用される要求解析技法である。
「システムアプローチ」は、すべてのこれらの関連分野で使用されるものである。シス
テムアプローチに欠かせない重要な点は、あるシステムが存在すること、そのシステムが
何らかのスーパーシステムの一部となり、それに影響を及ぼすこと、そのシステムがいく
つかのサブシステムにより構成されていること、そのシステムの対象を理解されているこ
と
−
2.5
できれば明確に特定されていること。
連続改良主義
ライフサイクル全体にわたるシステムの実現は、さまざまな行動方針案からの一連の意
思決定から得られる。各種の行動方針案が明確に設定されており、しかも完全に理解され、
コスト効果空間の中で十分差異が認められる場合は、システムマネジャも自信を持ってそ
れらの中から最適案を選択できる。
システムエンジニアリングのプロセスとは、そうした選択を支援するために各種設計案
を明確化し、理解すると共に、決定事項の実施状況を監視することと連結することである
と考えられる。適正な決定を行いやすくする明快な評価を得るためには、図３に示すよう
に、すでに完了した設計よりもこれから作成する設計案の方をより深く徹底的に調べる必
要がしばしばある。
- 11 -
ニーズ／機会
の認識
目標の特定
と定量化
目標の特定
と定量化
分解度
の増大
分 解 度
の増大
概念の
創出
概念の
創出
設計の
選択
トレード
研究
設計の
選択
決定事項
の実施
概 念 の
創出
目標の特定
と定量化
概念の創
出
分解度
の増大
目標の特定
と定量化
設計の
選択
トレード
研究
トレード
研究
トレード
研究
設計の
選択
ミッション
実施
図３
連的改良主義
しかし、図３のうず巻図は、システムの着想から廃棄に至るプロジェクトのライフサイ
クル、またはそのプロジェクト・ライフサイクルのフェーズＣとフェーズＤ（第３章を参
照）におきるシステム設計の開発と実施という製品開発プロセスを示していないことに留
意すべきである。むしろ、システムエンジニアリングの知的過程として、このうず巻図の
方が上記の両者に必然的に反映されていると言える。
連続改良プロセスの一例として、「アルファ」の場合のスペースステーションの
高度の選定を考える。
・ まず最初の問題は一般的投入位置の選択である。その選択肢としては、地球周回軌道、
地球・月のラグランジュ点の一つ、太陽周回軌道などがある。現段階の技術では、コ
ストとリスクを考慮すると、「アルファ」にとっては地球周回軌道が容易な選択であ
る。
・ 地球周回軌道を選択した場合、軌道領域を選択する必要がある。その選択肢としては、
低地球周回軌道（ＬＥＯ＝Low Earth Orbit)、高地球周回軌道、静止軌道などがある。
また、軌道傾斜角と軌道離心率も選択する必要がある。「アルファ」の軌道として低
地球周回軌道を選択した場合に考慮される多くの評価基準の一つは、バンアレン帯通
過に関連する設計の複雑さである。
・ システム設計における次の選定段階は、高度維持の戦略の選択である
−
これは、
「再突入までに少なくともＴＢＤ(To be determined）日が常にあるような高度を維
持する」、「衝突回避操縦では常に高度を増やす必要がある」、「燃料を運搬した再補
給飛行後のみ再推進を行う」、「ＴＢＤ日ごとに搭乗員を交代させる」といった、再推
- 12 -
進の時期、場所、理由を暗黙裡に決定する規則を決める。
・ 次は、高度仕様を書く段階である。これらの選定段階には、高度の戦略における高度
ＴＢＤを明確な数値に書き換える作業を含めることもできよう。
・ 月別運用計画は、最終的に完全なシステム設計の一部に組み込まれる。これらの計画
は、抗力の累積効果による予測や機上の微小重力実験の詳細に基づく再推進の燃焼ス
ケジュールを記載する。
・ 実際の燃焼の決定は、それ以前の燃焼により実際に追加された運動量の結果である軌
道、実際に直面した大気密度のばらつきなどに基づいて下される。
各段階での決定は、利用可能な技術から得られる可能性も考慮する
−
当初は必
要と思われたよりもさらに詳細な設計レベルにおいてしばしばその必要がある。
図３は、実際には二重うず巻図となる
−
反対方向へ移動する可能性定義のうず巻を
始める設計エンジニアリングのレベルではそれぞれのうず巻が設計概念段階を創出する。
こうした設計概念が事実無根で創出されることは決してない。むしろ、絶えず変動する技
術から得られる潜在的な可能性を統合化して創出される。より低レベルの要素の統合化に
よるこのような設計概念の開発過程は、システムエンジニアリング・プロセスの一環とな
るものである。実際には、トップダウンのプロセスがボトムアップのプロセスと歩調を合
わせられない危険が常に伴う。
多くの場合、信頼できるトレード研究を行えるような十分に現実的なシステム・モデル
を作成できるよう、（例えばシステム構成のような）問題を早期に解決する必要がある。
いくつかある設計案の一つを実施するために経営資源を使用した場合、その設計案の実
施完了までに必要な経営資源は（当然）減少するが、選定されなかった設計案に必要とな
る経営資源には少しまたはまったく変化はない。その結果、選定された設計案は、選定さ
れなかった設計案に比べ一層魅力的になるというわけである。
したがって、時の経過と共にますます適正な分解度でシステムの定義が行われると期待
するのは理にかなっている。こうした傾向は、「ベースライン」システムの定義が明確化す
ることによりある時点（フェーズＢ）で承認される。通常は、目標、目的、制約がベース
ラインの「要求事項」部分としてベースライン化される。次に、連続した変化が実際に改
良化となるように努力することを企てるためベースライン全体をコンフィギュレーション
管理（コントロール）の下に置く。
システムが実現化されるに伴い、その特性がますます明確になり、そのため変更しにく
くなる。前述したように、システムエンジニアリングの目的は、コスト効果の最も高い最
終システムが得られるような開発プロセスを生むことである。その基本理念は、取り消し
にくい決定を下す前に、代替設計案を慎重に評価するという点にある。
- 13 -
システムエンジニアリングのプロセスは、システムが開発される途中で、何度もくり返
し適用される。システムの実現化に伴い、取り組むべき問題も変わり、活動の特性も変わ
る。
主なシステム決定事項のほとんど（目標、構成、許容できるライフサイクルのコストな
ど）は、プロジェクトの初期段階に決定される。そのため、うず巻の巻き数（つまり「連
続改良」）がシステム・ライフサイクルの段階数と厳密に一致することはない。システム構
成の大部分は初期段階から「見る」ことができるので、うず巻の巻き数が構成階層の開発
とも正確に一致することはない。むしろシステムを定義する連続的に高まる分解度にその
巻き数が一致する。
システムエンジニアリングのプロセスの各段階について以後検討する。
ニーズ／機会の認識：
この段階は、実際にはうず巻の一部ではなく、その発端であるの
で、図３には１回しか示されていない。新しいシステムに対するニーズや機会を認識する
ことは、エンジニアリング活動というよりもむしろ起業家的な活動と言える。
この段階の最終結果はシステムの目標発見とその画定である。その目標は通常、システ
ムの最終ユーザーのニーズと必要条件を示すものである。ＮＡＳＡ（米国航空宇宙局）の
場合は、システムの目標が納税者である国民の長期的利益をも示すものでなければならな
い。
目標の特定と定量化：
システムの各種設計概念案をコスト効果の面から比較検討する前
に、そのシステムを使って実施するミッションの範囲を画定する必要がある。設定すべき
目標は、効果、コスト、スケジュール、リスクという関連面すべてを考慮し、スーパーシ
ステムの目標を踏襲できるものでなければならない。さまざまの設計概念案から最適のも
のを選定しやすくするためには、そうすることが可能で意味がある限り、目標を定量化か
つ検証できる形に明記する必要がある。
また、適用できる各種制約を評価することも望ましい。システムの設計概念を創出また
は変更する時には、その時の技術水準から何らかの制約が課せられる。その他の設計概念
には制約が課せられないとしても、より高いマネジメント・レベルにより変更されること
もある。制約がゆるんだ場合に得られる便益を予測できるように、そうした制約の土台と
なる想定やその他関連情報は常に記録しておく必要がある。
うず巻の１巻きごとに、より高いレベルの目標を分析する。このような分析では、次の
高位レベルの目標を踏襲できるような下位の達成可能目標を特定すべきである。システム
エンジニアリング・プロセスが進むにつれて、こうした目標は「機能」要求（次の高位レ
ベルの目標を達成するために実施する必要のあるもの）や「性能」要求（機能要求を満た
す方法に関する量的記述）として文書化される。機能要求と性能要求の両方を最終的に当
初のニーズや機会に関係づけられるような要求解析に的を絞るには、明確な「オペレーシ
- 14 -
ョンズ概念」が役立つことが多い。うず巻の後半部では、さらに綿密に仕上げたものを詳
細な機能仕様書や性能仕様書として文書化することもできる。
各種設計概念案の創出：
システムで達成すべき目標が明らかになったら、こうした目標
を達成できる各種の方法を案出することができる。時には、各種の機能配分案を検討し、
使用できるサブシステム設計案を統合した結果、これらの方法が案出されることもある。
理想的には、連続改良過程の現段階を念頭に置いて、設計団体の設立許可書にあるような
もっともらしい方法案を多数案出するのが良い。ボトムアップ方式が使用されている時は、
システムエンジニアにとっては一つの問題が生じる。設計者が自分の設計に愛着を持つよ
うになり、客観性を失うという問題である。システムエンジニアとしては、常に「部外者」
としての立場を守り、客観性を高めるようにしなければならない。
図３に示すうず巻図の第１段階では、しばしば一般的方法や戦略、時にはアーキテクチ
ャー概念が課題となる。次の段階では機能設計、その次には詳細設計....となることが予
想される。
早期に一つの設計に的を絞るのは避けるべきである。その理由は、真の最適設計を発見
するためである。システムエンジニアの仕事の一つは、各種設計概念の比較検討において
必要なインタフェースをすべて考慮に入れることである。「ケーブルを入れたか？」という
質問は、まさにその点を突いたものだ。できれば、各設計概念を調節可能な「設計パラメ
ータ」で記述し、各パラメータでできる限り幅広い分類の設計を表わせるようにすべきで
ある。その場合、システムエンジニアとしては、組織構造、スケジュール、手続き、さら
に「システム」を構成するその他のものも変化要因となることを念頭に置くべきである。
できれば、各種制約もパラメータで記述すべきである。
「アポロ」宇宙船計画の元部長で、現在はスペースシャトルのシステムエンジニアリン
グ部長であるオーエン・モリスは、「あらゆるシステム機能を大いに重視し、あらゆる設計
で達成できるような『設計標準ミッション(design reference missions)』を策定すれば大
いに役立つ」と指摘していた。そのようなミッションの目的は、設計スペースを開放型に
することである。したがって、そのミッションをシステム仕様書に記載すると、非常に危
険な場合もある。そのようなミッションは逆効果を及ぼすこともあるからだ。
トレード研究：
トレード研究では、最初に、各設計案がシステムの各種目標（効果、コ
スト、スケジュール、リスクの定量化されたものと定量化されないもの）をどの程度満た
しているかを評価する。設計パラメータとそうした評価結果の関係を示すシステム・モデ
ルを開発すれば、その研究の実施能力は向上する
−
だが、そのモデルに左右されるこ
とはない。
そうしたシステム・モデルと共に、設計概念の変更と開発を管理すれば、正式の最適化
技法を採用して、さらに研究を必要とする設計スペース領域
- 15 -
−
図１に示す最適包絡面
に近い領域
−
を見つけられる機会も多くなる。
システム・モデルを使用してもしなくても、設計概念の開発、変更、再評価は行える。
また、閉ループ方式により競合する設計概念案との比較検討も行え、さらに開発すべき最
適案を見つけることもできる。トレード研究時には、システムとサブシステムのサイズも
算定される。その最終結果として、定量化されたシステム目標を評価した上で、各種設計
案の相対的コスト効果の限界も算定される。（最終詳細設計の決定は意図的に延期される
ので、最終値ではなく、限界だけが算定可能である。そうした限界は確率密度関数から算
定できる）。分解度の連続的向上に関係のある細分化は、プロセスが進むにつれて上限と下
限の開きを縮小する。
設計概念の選定：
さまざまな設計概念案から最適案を選定するのは、システムマネジャ
の任務である。システムマネジャは、その設計概念案が定量化された目標（および効果、
コスト、スケジュール、リスク、その他の制約）にどの程度適合しているかという予測の
他に、システムエンジニアが定量化できないような主観的要素も考慮に入れなければなら
ない。
できれば、「目的関数」という数学式を開発することも骨折り甲斐が十分にある。この関
数は、たとえコストと効果を２つ以上の評価値で示す必要があっても、図４に示すように、
いくつかの予測評価結果のいろいろな組み合わせに対する値を唯一のコスト効果値で表わ
したものである。各種目標の達成結果をそのような目的関数により量的に表記できる場合
は、各種設計案をそれらの値から比較検討できる。設計概念に伴うリスクにより、これら
の評価結果が多少不確定なものになることもある（リスクは本来不確定なものであり、リ
スクを最も良く表わすのは確率分布であるからだ）。図４では、設計概念Ａのリスクが比較
的高い。設計概念Ｂの場合は、効果面でもコスト面でもほとんどリスクがない。他方、設
計概念Ｃの場合は、コストのかかる失敗によるリスクが高い。つまり、図からも明らかな
ように、確率を示す雲模様（cloud）がＸ軸に近く、コストは高いが、効果がないというわ
けである。効果値、コスト値、リスク分布には、スケジュール要因が影響を及ぼすことも
ある。
- 16 -
特定効果面（量的単位で示す）
ダッシュ線は、目的関数（コスト効果）の
一定値を示す。左上方向へ移動するほど値
が高くなる
Ａ
Ｂ
Ａ、Ｂ、Ｃはそれ
ぞれリスクパター
ンの異なる設計概
念
Ｃ
ライフサイクル・コスト（固定ドル価格で示す）
図４
定量的目的関数。ライフサイクル・
コストとすべての効果面に依存
システムの成功基準はミッションによって大幅に異なる。効果目標がその他の目標より
もはるかに重要な場合もある。また、プロジェクトのなかには、低コスト化が必要なもの、
スケジュールが変わらないもの、ある種のリスクをできるだけ低減化する必要のあるもの
もある。たとえいくつかの要素を持つベクトルで表わされるとしても、重要要素「すべて」
を表わせる連結定量評価値が得られることは（たとえあっても）滅多にない。
それが可能であっても、そのような連結評価値の土台となる諸要素や関係がシステムマ
ネジャに完全に明らかにされ、理解されることが不可欠である。システムマネジャは、シ
ステムエンジニアから提供された定量データと共に、定量化できない要素の重要度も比較
考量しなければならない。
データの技術的審査と解析は、システムマネジャ向けに作成された「決定支援パッケー
ジ」（decision support packages）の重要な一部となる。通常、新たな決定事項は、シス
テム・ベースラインに対する変更事項（または改良事項）としてコンフィギュレーション
マネジメントシステムに導入される。それを支援するトレード研究結果は、将来使用する
ために記録保管所に保管される。システムエンジニアリング・プロセスの極めて重要な特
性は、決定を下す「前に」トレード研究を実施する点である。そうすれば、トレード研究
結果を確実にベースラインに導入できる。
システムエンジニアリング・プロセスのこの時点には、論理的分岐点がある。何らかの
問題に対する連続改良プロセスがかなり進んだ場合、次の段階がその分解度レベルでの決
定事項を実施する（つまり、循環プロセスを巻き戻す）。問題がまだ十分解決されていない
場合は、さらに改良開発を続ける必要がある。
- 17 -
単純なインタフェースほど望ましい
モリスによると、ＮＡＳＡ（米国航空宇宙局）のジョージ・ロウ元局長代理は、「アポロ計
画が成功した理由」（What Made Apollo a Success）というタイトルで 1971 年に発表した
論文において、「アポロ宇宙船を打ち上げロケット『サターン』につなぐ配線は、たった 100
本ですんだ」と指摘している。彼が強調したかったのは、インタフェースのことを完全に
理解し、インタフェースの片側に生じた変化による影響すべてに取り組むことができたの
は、たった１人の人間だったという点である。
設計の分解度増大：
まず取り組むべき問題の一つは、システムをどのようにサブシステ
ムに細分化すべきかという点である。（その問題を解決すれば、焦点が変わり、「サブシス
テム」が「システム」となる
−
システムエンジニアの視点から見た場合。サブシステ
ムが単純で、全体的に処理できる場合は、区分プロセスは不要である）。モリスが指摘した
ように、「インタフェースの数と複雑度を最低限に抑えられるように計画事業を分割すれ
ば、計画の総経費とスケジュール順守力にも強い影響を及ぼす。」
チャールズ・リーシングとアーノルド・ラスキンは（それぞれ別々に）、「何かを区分す
ることは科学というよりも技術であり、適用できる指針もある。インタフェースをすっき
りと単純なものにするには、同じような機能、設計、技術を一つにまとめることだ」と指
摘している。その場合は、各作業部分は個別に検証できるように区分すべきである。部品
類は便利なように組織的な構造に組み立てるべきである。設計全体に必要となる機能（「電
力」など）や組織全体に必要となる業務（「購買」など）の一部は集中化できる。部品リス
トや報告書の書式などは、規格化する方が良い場合が多い。会計方式は、（システムアーキ
テクチャを従わせるのではなく）システムアーキテクチャに従ったものにすべきである。
幅を区分する場合は一挙に実施することが肝要である。システム設計選定の場合と同様、
実施する前にさまざまの区分計画案を比較検討すべきである。
システムアーキテクチャの開発において要求に基づく設計例を使用する場合は、細心の
注意を払って適用しなければならない。なぜならば、「しなければならない」という語句を
使用すると、そうした要求が目的の代わりというよりもむしろ侵すべからざる制約として
扱われる傾向があるからだ。目標、目的、希望事項は、そのコストが明らかになり、買い
手がそれを支払う気になるまでは、「要求」として扱うべきではない。「定量化された目標」
に対する低レベルの決定の影響を算定する機能は、区分プロセス全体にわたって維持すべ
きである。つまり、要求配分プロセスへ組み込まれる目標の「フローダウン」が必要であ
る。
そのプロセスは、次の分解度レベルの各種設計概念案の創出、そうした設計概念案が定
量化された目標をどの程度達成するかを予測できるモデルの作成、．．．と続く。区分プロセ
ス全体にわたりその後の統合化計画を立てることも絶対に必要である。統合化計画には当
- 18 -
然、検証と妥当性確認という作業も含まれる。
選定された設計の決定事項実施：
連続改良プロセスがかなり進むと、次は区分プロセス
を逆行する段階となる。システムアーキテクチャに適用される場合、この区分プロセスの
「巻き戻し」のことを「システム統合化」という。「概念」システムの統合化は、プロジェ
クト・ライフサイクルの全段階で実施される。つまり、何らかの設計方法が選定されると、
その方法は「プロセスを巻き戻して」検証され、各物理的レベルの概念が期待事項と要求
事項に適合しているかどうかが試験される。「物理的」統合化が達成されるのはＤ段階であ
る。より微細な分解レベルの部品は、試験、組み立て、統合化を行った後、再び試験を行
う必要がある。システムエンジニアの役割には、コンフィギュレーション・コントロール
や、統合化・検証・認証プロセスの監視など、委託マネジメント業務の実施も含まれる。
サブシステム統合化を「検証」する目的は、機械的連結部、重心と慣性乗積に対する影
響、電磁インタフェース、コネクタのインピーダンスと電圧、消費電力、データフローと
いったすべての重要な点に関して、サブシステムが設計通りのものか、予想通り相互に接
続されているかどうかを確認することである。「妥当性確認」では、相互に接続されたサブ
システムが所期の目的を達成するかどうかを確認する。検証よりも妥当性確認の方がはる
かに重要だが、格段にむずかしいプロセスである。
ミッションの実施：
最終的に、システムはニーズを満たし、機会を捕らえることを求め
られる。システムが設計され、構築されたのはまさにそのためである。
システムエンジニアは引き続き、ミッションの種類と期間に応じて各種の支援業務を実
施する。スペースステーション「アルファ」のような大型プロジェクトの場合、こうした
継続業務としては、作業現場におけるシステムの有効性（効果）検証、コンフィギュレー
ションとロジスティックス関係の文書保管、継続エンジニアリング作業の監視、開発と運
用関係の「教訓」文書の編集、さらに専門工学分野の協力を得て実施する製品改良の機会
特定などがある。「スペースラブ」のペイロードのような小型システムでは、最後の２業務
だけが求められるであろう。
- 19 -
３． ＮＡＳＡ主要システムのプロジェクト・ライフサイクル
ＮＡＳＡ（米国航空宇宙局）内部において主要システムのマネジメントに採用している
基本概念の一つは、「プログラム／プロジェクト・ライフサイクル」である。これは、プロ
ジェクトで実施すべきすべてのものを、「コントロール・ゲート」（関門）によりいくつか
の明確な「段階」（フェーズ）に分類したものである。各段階の境界では、「進むか、停止
するか」（go/no-go）を多少自然に決定できる点が設けられられるようになっている。「進
む」という決定は「優先権」を付与されるが、その優先権はしかるべき時間内に取り除か
れなければならない。コントロール・ゲートを通過できないが、資源が十分あるプロジェ
クトは、「振り出しへもどる」ことを許されるか、それで終結となるか、そのいずれかであ
る。
すべてのシステムは、ニーズの認識か機会の発見から始まり、さまざまの開発段階を経
て最終処分まで達する。システムエンジニアリングに関連のある解析・最適化作業による
最も劇的な影響は、初期段階に得られる。他方、数百万ドルもの価額やコストにかかわる
決定には、システムが耐用期限に近づいてもなお、システム方式が適用される。
プロジェクト・ライフサイクルをいくつかの段階（フェーズ）に区分することは、その
プロセス全体をもっと処理しやすいパートに分割することである。プロジェクト・ライフ
サイクルは、マネジメントや予算の状況に合致する時点で、マネジャたちにとってプロジ
ェクトの進捗状況がますます見えやすくなるようなものでなければならない。主要システ
ムの取得に適用されるＮＡＳＡ文書［ＮＭＩ（NASA Management Instructions＝ＮＡＳＡ
管理手引書）7120.4 とＮＨＢ（NASA Handbook ＝ＮＡＳＡハンドブック）7120.5］では、
プロジェクト・ライフサイクルの全段階を次のように定義している。
・
プリフェーズ（予備段階）Ａ
−
最新研究（「適切なプロジェクトを見つける」）
段階。
・ フェーズ（段階）Ａ
−
予備解析（「プロジェクトが実施価値のあるものかどうか
−
定義（「プロジェクトを定義し、予備設計を行う」）段階。
を確認する」）段階。
・ フェーズ（段階）Ｂ
・
フェーズ（段階）Ｃ
・ フェーズ（段階）Ｄ
−
−
設計（「システム設計を完成させる」）段階。
開発（「システムの構築、統合化、検証、運用準備を行う」）
段階。
・
フェーズ（段階）Ｅ
−
運用（「システムを運用し、適正に廃棄する」）段階。
フェーズＡの作業は、ＮＡＳＡのフィールドセンターが実施する。しかし、これらの作
業は、プリフェーズＡにおいてＮＡＳＡ内部と外注により実施された最新研究に基づいて
行われることになろう。フェーズＢにおける大半の作業は通常、ＮＡＳＡと契約した企業
が実施するが、外注作業を検証し、買い手としての情報を得るために、ＮＡＳＡのフィー
- 20 -
ルドセンターでも並行して内部研究を実施する。ＮＡＳＡでは通常、フェーズＣとフェー
ズＤにおいて企業と契約し、フェーズＥにおいてもしばしばそうする。フェーズＣとフェ
ーズＤは連結されるのが通例だが、大量生産計画がある時は個別に扱われる。
産業界や他の政府機関にも、上述のプロジェクト段階とは異なるさまざまの代替区分が
見られる。一般的に、技術開発のライフサイクルは開発されるものの技術的特性に左右さ
れ、それに応じてプロジェクト・ライフサイクルを調整する必要がある。バリー・Ｗ・ボ
エームは、現在ソフトウェア開発プロセスがどのように進められているかを説明している。
こうした開発プロセスの中には、開発作業と構築作業が並行して進められる場合もある。
そのため、タイムライン上の関連段階を分離しようとするのは望ましくない。ボエームは
一種のうず巻図についても説明している。ボエームのうず巻は、図３に示す連続改良主義
を反映させたものだが、特にソフトウェアの開発プロセスを示すものである。だが、ボエ
ームの理論は、ソフトウェアだけでなく、ハードウェアの開発にも適用できる。その他の
代 替 プ ロ セ ス と し て は 、 "rapid prototyping"( 迅 速 原 型 製 作 ） プ ロ セ ス や "rapid
development"(迅速開発）プロセスがある。最適製品開発プロセスの選定は、システムエン
ジニアの判断と経験に基づいて、それぞれのケースに応じて決定しなければならない。
時には、リードタイム（製品の立案から実際の製造までの期間）の長い事業を早期に実
施する方が良い場合もある。リードタイムの長い事業は、技術開発、原型製品の製作と試
験からなることもあれば、むずかしい部品組み立てからなることもある。通常の手順でこ
うした作業を行えば、不要な事業か不適切な事業としてこれらの事業が失敗するリスクも
増大する。他方、クリティカルパス（臨界経路）からそうした事業を排除すれば、総合的
リスクが低下する場合もある。
図５は、ＮＭＩ（NASA Management Instructions＝ＮＡＳＡ管理手引書）7120.4 および
ＮＨＢ（NASA Handbook ＝ＮＡＳＡハンドブック）7120.5 に記載された諸段階（フェーズ）
の特徴となるマネジメント、システムエンジニアリングの主な成果、コントロール・ゲー
トなどを示す詳細図である。第 3.1 項から第 3.6 項では、ＮＡＳＡプロジェクト・ライフ
サイクルの各段階（フェーズ）の目的、主要作業、成果、コントロール・ゲートについて
概説する。第 3.7 項では、このプロセスにおけるシステムエンジニアリングの役割につい
てさらに集中的に説明する。第 3.8 項では、プログラム／プロジェクトマネジャとシステ
ムエンジニアが業務を行う場合のＮＡＳＡ予算サイクルについて概説する。
3.1
プリフェーズＡ
−
最新研究段階
この段階の作業は、通常、「最新プロジェクト」グループにより多少継続的に実施される。
その目的は、新規プロジェクト（プログラム）を選定するために、さまざまなアイデアや
ミッション案を探索、案出、創出、立案、考案することである。通例、こうした作業では、
多数の新しいアイデアを審査する。その審査は、余り組織化されていないもので、通常は
- 21 -
本部による管理もなく、たいていは小規模の研究になる傾向がある。この段階から得られ
るその主な成果は、一連のプロジェクト案である。それらは、ＮＡＳＡのミッション、能
力、優先事項、資源に一致するようなニーズの特定と機会の発見に基いたものである。
プリフェーズＡ
目的：
−
最新研究段階
新規プログラム／プロジェクトを選定するために、さまざまなアイデアとミッ
ション案を創出する。
主な作業とその成果：
「許可を得られるようなミッション」を特定する。
ユーザーを特定し、関与させる。
ミッション案の「予備評価」を実施する。
「プログラム／プロジェクト提案書を作成し、以下の事項を記載する。
・
ミッションの正当化理由と目的
・
運用概念案
・
システムアーキテクチャー案
・
コスト、スケジュール、リスクの予測
現行計画領域のマスタープランを作成する。
ベースライン化情報：
（なし）
コントロール・ゲート：
ミッション概念の審査
非公式提案の審査
ＮＡＳＡ環境では、新システムに対するニーズがいくつか発生している。最大のニーズ
は、搭載機器類やその他装置を宇宙へ投入する際に直面する地球上の問題を解決する機会
である。その例としては、気象予測と衛星通信の２つがある。宇宙用技術の全面的改良開
発を進めれば、今後も引き続き新しい可能性が開かれるだろう。そのような「機会」は、
その価値の大きさがひとたび理解されると、一気に「ニーズ」として認められるようにな
る。
技術の進歩は、かつては不可能であったミッションをも可能にする。月への有人飛行や
惑星やその他天体の高解像度写真は、この種の機会がすでに実現されたことを示す。わが
国の技術力が伸びるに伴い、今後も新しい機会が次々と出現するであろう。
科学の進歩はＮＡＳＡシステムに対するニーズをも生み出す。我々を取り巻く世界に対
する理解が深まるにつれ、我々はますます的確な疑問を新たに抱くようになる。こうした
疑問に答えられるかどうかは、変動する技術水準に左右される。
最新の研究は数年にわたることもあれば、多少関連があるにすぎない論文を生み出すこ
とが続く場合もある。こうした研究では、通常、ミッションの目標設定、トップレベルの
- 22 -
システム要求事項やシステム運用概念が中心になる。実現性を実証し、計画上の予測を裏
づけるために、各種の概念設計が提示されることも多い。その場合には、最適性よりもむ
しろ、実現性と希求性が重視される。解析と設計では、それに応じて選択肢の数とその詳
細度が限定される。
3.2
フェーズＡ
−
予備解析段階
この段階の目的は、莫大な資金を調達する前に、新しい主要システム案の実現性と希求
性についてさらに審査することである。ＮＨＢ(NASA Handbook＝ＮＡＳＡハンドブック）
7120.5 によると、この段階から得られる成果は、正式のミッション・ニーズ報告書（ＭＮ
Ｓ＝Mission Needs Statement）、それに信頼性のある実現可能な設計概念と運用概念であ
る。ジョン・ホッジは、この段階を「前段階を組織化したもの」と評している。
フェーズＡ
目的：
−
予備解析段階
新しい主要システム案の実現性と希求性、ＮＡＳＡの戦略計画との適合性を調
べる。
主な作業とその成果：
「ミッション・ニーズ報告書」（ＭＮＳ＝Mission Needs Statement)を作成する。
トップレベルの「要求事項」を設定する。
対応する「評価基準／測定基準」を設定する。
各種の「運用概念とロジスティックス概念」を特定する。
「プロジェクトの制約とシステムの境界」を特定する。
「実現性研究とリスク研究の結果、コストとスケジュールの予測、必要な最新技術」な
ど、「各種設計概念案」を検討する。
「信頼性のある実現可能な設計」が存在するかどうかを実証する。
「システムエンジニアリングのツールとモデル」を確保する。
「環境影響調査」を開始する。
フェーズＢに必要な「プロジェクト定義計画書」（Project Definition Plan)を作成する。
ベースライン化情報：
（なし）。
コントロール・ゲート：
ミッション定義審査
非支持者予備審査
プログラム／プロジェクト予備承認審査
- 23 -
図５
プロジェクト
段階
ＮＡＳＡプログラム／プロジェクト・ライフサイクル
形成
プリフェーズＡ：
最新研究
実
フェーズＡ：
予備解析
フェーズＢ：
定義
フェーズＣ：
設計
局長
ＣＦＯ／会計検査官
プログラムＡＡ
ＭＮＳ承認 ▲
フェーズＡ承認▲
AO
予備ＩＰＳ
リスクマネジメント計画書
プログラム
マネジャ
MNS
プロジェクト定義計画書
フェーズＢ／Ｃ／ＤＲＦＰ
プロジェクト
マネジャ
技術的成果
▼:主要審査
▽:中間審査
▲:作業
取消し審査（必要な場合のみ）
自主準備審査（必要に応じて実施）
複数単位生産認可（適用される場合のみ）
▼
PCA承認
▲
▲搭載機器選定決定
予備ＰＣＡ
ＰＣＡ草案書
ＩＰＳ
最終プログラム計画書
総合プログラム
マスタースケジュール
予備プロジェクト計画書
システム仕様書
フェーズＥ：
運用
ＭＮＳ再承認
▲
ＩＡＲ報告書
ＮＥＰＡ決定記録
再承認ずみＭＮＳ
年次認証ＰＣＡ
承認ずみＰＣＡ
契約相手方選定決定
ＰＤＲベースライン
プロジェクト計画書
ＩＡＲ報告書
年次認証ＰＣＡ
半期ＰＳＲ
年次認証ＰＣＡ
半期ＰＳＲ
四半期ＣＭＲ
四半期ＱＳＲ報告書
ＣＤＲ仕様書／ベースライン
四半期ＣＭＲ
四半期ＱＳＲ報告書
（必要に応じて−ＩＲＲ報告書も含む）
運用システム・
ＮＡＲ報告書
予備ＮＡＲ報告書
非支持者
技術管理の成果
PPAR
ＩＡＲ報告書
予備プログラム計画書
主な審査
▼
NAR
フェーズＤ：
開発
自主年次審査
四半期状態審査
契約者測定基準審査
当局の審査
予備 NAR ▼
予備-PPAR ▼
行
ミッションの実現性
MCR▼
−研究計画書
−継続計画書
−ミッションの目標と
目的
−概念／設計評価基準
−ミッション概念
−運用概念
−ライフサイクル・コス
ト予測
−実現性評価
:文書
− 成果または文書
ＡＡ＝副局長（Associate Administrator)
ＡＯ＝機会公告状（Announcement of Opportunity)
ＣＤＲ＝詳細設計審査（Critical Design Review）
ＣＦＯ＝主任財務官（Chief Financial Officer）
ミッションの定義
MDR ▼
−システムエンジニアリン
グマネジメント計画書
−情報マネジメント計画書
−技術マスタープラン／マ
スタースケジュール
−リスクマネジメント計画
書
−ミッション・ニーズ報告書
−ミッション機能概念
−予備システム仕様書
−科学的要求事項
−トレードオフ・分析結果
−技術開発計画書
−ＰＤ／ＮＳＣ-25 データブ
ック
システムの定義
SRR ▽ SDR
基本設計
▼
−プログラム／プロジェクト管理
（マネージメント）計画書
−開発計画書
−作業報告書
−システム安全計画書
−コンフィギュレーション管理
（マネージメント）計画書
−文書樹形図
−システム概念とアーキテクチャ
−システム仕様書
−インタフェース要求条件書
−環境仕様書
−人間向けシステム規格
−概念／設計評価基準
−開発試験計画書
−工学単位
−ハードウェア／ソフトウェア・
リスト
−リスク解析
−開発試験結果
−技術開発要求条件書
ＣＭＲ＝契約相手方測定基準報告書（Contractor
ＩＰＳ＝総合プログラム／プロジェクト概要書
Metrics Report)
（Integrated Program/Project Summary）
ＤＲ＝デコミッショニング審査（Decommissioning
ＩＲＲ＝自主準備審査（Independent Readiness
Review）
Review）
ＦＲＲ＝飛行準備審査（Flight Readiness Review) ＭＣＲ＝ミッション概念審査（Mission Concept
ＩＡＲ＝自主年次審査（Independent Annual Review)
Review）
ＭＤＲ＝ミッション定義審査（Mission Definition
Review)
最終設計
PDR ▼
−作業明細構成書
−技術性能測定計画書
−コンタムネーションコント
ロール計画書、
−ＥＥＥ部品マネジメント
計画書
−部品コントロール計画書
−環境コントロール計画書
−総合ロジスティックス支援
計画書
−ＥＭＩ／ＥＭＣ（電磁干渉
／電磁適合性）コントロー
ル計画書
−生産性／製造性プログラム
計画書
−信頼性プログラム計画書
−品質保証計画書
−適用規格、
−Design-To 仕様書
−販売者側ハードウェアと
ソフトウェア仕様書
−廃棄要求書
−仕様樹形図
−図面樹形図／技術図面リス
ト
−インタフェースコントロー
ル文書
−ペイロード・キャリア統合
化計画書
−検証計画書
−検証要求マトリックス
−環境影響報告書
組立と統合化
CDR ▼
−製造計画書
−技術性能測定報告書
−材料と工程コントロー
ル計画書
−総合ロジスティックス
支援計画書
配備準備
SAR ▼
−運用計画書
FRR ▼
配備と運用検証、 ミッションへの運用
廃棄
DR ▼
ORR ▼
−飛行／打ち上げ準備
証明書
−廃棄また
はデコミッ
ショニング
アイテム
−Build-To 仕様書
−製造工程要求書
−設計開示
−運用制限・制約条件書
−総合設計図
−予備部品供給リスト
−認定試験項目書
−打ち上げ作業計画書
−運用計画書へ転換
−廃棄計画書
−受領計画書
−受領基準書
−検証要求書・仕様書
−検証要領書
−統合化・組立計画書
−搭載機器プログラム／
コマンド・リスト
−運用要領書
−トレーニング計画書
−使用説明書
−飛行状態点検計画書
−コンピュータ資源総
合支援書
−検証データ
−ウエーバー
ＮＳＣ＝国家安全保障会議（National Security
ＭＮＳ＝ミッション・ニーズ報告書（Mission Need
Statement）
Council)
ＭＲ＝ミッション審査（Mission Review）
ＯＲＲ＝運用準備審査（Operational Readiness
ＮＡＲ＝非支持者審査（Non-Advocate Review)
Review）
ＮＥＰＡ＝米国環境政策法（National Environmental ＰＣＡ＝プログラム参画同意書（Program Commitment
Policy Act)
Agreement）
ＰＤ＝大統領令（Presidential Directive）
−ハードウェア／ソフ
トウェア最終アイテ
ム
−運用データ
−打ち上げ施設点検結
果
− 進 行 ／ 停 止
（Go/No-Go）基準
−運用評価結果
−問題／故障報告書
−技術説明書及びデ
ータ
−訓練ずみ要員
−ミッショ
ン成果
−連続生産
−交換品及
び改良品
ＰＤＲ＝基本設計審査（PreliminaryDesignReview)、 ＲＦＰ＝提案要求書（Request for Proposal）
ＰＰＡＲ＝プログラム／プロジェクト承認審査
ＳＡＲ＝システム受領審査（System Acceptance
Review）
（Program/Project Approval Review)、
ＰＳＲ＝プロジェクト状況報告書（Project Status ＳＤＲ＝システム定義審査（System Definition
Reports）
Review）
ＱＳＲ＝四半期状況審査（Quarterly Status Review) ＳＲＲ＝システム要求審査（System Requirements
Review）
フェーズＡでは、たいてい特別プログラム／プロジェクト課に所属する大型チームがミッ
ション概念に再び取り組み、プロジェクトの正当理由や実効性がＮＡＳＡ予算の配分を受
けるに足るものであるかどうかを確認する。そのチームの作業は、ミッション要求事項の
解析と、ミッション・アーキテクチャの確立が中心となる。その作業は公式のものとなり、
実現性よりも最適性の確認へと重点が移る。作業は一層徹底したものとなり、多くの選択
案を検討する。目標と目的は確実なものとなり、システム要求事項、トップレベルのシス
テム・アーキテクチャ、運用概念を一層明確化する。各種概念設計を開発し、最新研究よ
りも詳細な技術特性を示すものにする。技術的リスクを一層詳細に特定し、技術開発ニー
ズに焦点を移す。
「ミッション・ニーズ報告書」（Mission Needs Statement）は、プロジェクトのコンフ
ィギュレーション・コントロールを受けないので、枠内補足記事にはベースライン化され
たものとして示していない。この報告書がコンフィギュレーション・コントロールを受け
るのは、プログラム要求書や「予備プログラム計画書」（Preliminary Program Plan）の場
合と同様、プログラム・レベルにおいてである。
フェーズＣの初期投入費に対する超過分と
しての最終コスト
200
出所： Wemer Gruhl, Office of the
Comptroller, NASA HQ, 1985
100
0
-20
0
15
30
開発費に対する比率（％）で示すフェーズＡとＢのコスト
図６
3.3
フェーズＢ
−
フェーズＡとＢが資金不足の場合は、超過
コストになる可能性が高い
定義段階
この段階の目的は、最初のプロジェクト・ベースラインを設定することである。（ＮＨＢ
［NASA Handbook ＝ＮＡＳＡハンドブック］7120.5 によると）、このプロジェクト・ベース
ラインは、「飛行及び地上要素に対するプロジェクト・レベルの性能要求事項を１組の完全
なシステムとサブシステム設計仕様へと公式にフローダウンしたもの」と「それに対応す
- 25 -
る基本設計」からなる。その技術要求書は、プロジェクトのスケジュールとコスト予測を
確実に行えるくらい詳細に作成する必要がある。
実際には、フェーズＢの「その」ベースラインは、プロジェクトの技術面とビジネス面
を扱った進展的ベースラインの集まりからなる。つまり、ベースラインの技術部分はシス
テム（およびサブシステム）の要求事項と仕様、設計、検証計画と運用計画などからなり、
ビジネス部分はスケジュール、コスト予測、マネジメント計画からなる。ベースラインの
設定は、コンフィギュレーションマネジメント手続きの実施を意味する。（第 4.7 項を参
照）。
フェーズＢ
−
目的：
定義段階
ミッションのニーズを満たすような初期ベースラインを設定できるくらい詳細
にプロジェクトの定義を行う。
主な作業とその成果：
「システムエンジニアリングマネジメント計画書」（Systems Engineering Management
Plan)を作成する。
「リスクマネジメント計画書」（Risk Management Plan）を作成する。
「コンフィギュレーションマネジメント」を開始する。
「工学専門プログラム計画書」（Engineering Specialty Program Plans)を作成する。
「システム・レベルのコスト効果モデル」を開発する。
ミッションのニーズを「機能要求書」に再記載する。
「科学的ペイロード」を特定する。
初期「システム要求条件及び検証要求条件マトリックス」を作成する。
「トレードオフ研究」を実施し、その結果を記録保管所に保管する。
ベースラインの「設計解決策」と「運用概念」を選定する。
「内部及び外部インタフェース要求事項」を設定する。
（"design-to" 仕様書及び図面、検証計画書、インタフェース文書を得るための連続改
良過程を必要な低レベルまでくり返す）。
「作業明細構成」を定義する。
「検証方式と検証方針」を設定する。
「総合ロジスティックス支援要求条件」を特定する。
「技術的資源予測」と確実な「ライフサイクル・コスト予測」をたてる。
「作業報告書」（statement(s) of work）を作成する。
「最新技術開発」を開始する。
「プロジェクト計画書」（Project Plan）を改訂して発行する。
「ミッション・ニーズ報告書」（Mission Needs Statement）を再確認する。
「プログラム確約同意書」（Program Commitment Agreement）を作成する。
ベースライン化情報：
システム要求条件・検証要求条件マトリックス
システム・アーキテクチャと作業明細構成
運用概念
あらゆるレベルの "design-to"仕様
スケジュール、経営資源、調達戦略、リスクマネジメントなどを記載したプロジェクト
計画書
コントロール・ゲート：
非支持者審査
プログラム／プロジェクト承認審査
システム要求審査
システム定義審査
システム・レベル基本設計審査
低レベル基本設計審査
安全性審査
- 26 -
信頼性のある実現可能な設計
実現可能なシステム設計とは、設計された通りに採用でき、財政・運営環境から課せられ
た制約の下でシステムの目標を達成できる設計である。信頼性のある設計を行うには、偶
発的な最新技術の大進歩に頼ってはならない。信頼性のある設計には最新の改良技術を導
入できる「見込み」もあるが、そうした設計は最新の改良技術を導入しないものに比べリ
スクが高い。
フェーズＢの前半では、ハードウェア、ソフトウェア、要員などの特定項目に対する役
割配分が作業の中心となる。コスト効果の高い設計を模索して、システムのトレードとサ
ブシステムのトレードを何度もくり返すうちに、システムの機能要求事項と性能要求事項
ならびにアーキテクチャと設計が確実なものとなる。（トレード研究は、システム設計の定
義後ではなく、その前に実施すべきである。Chamberlain､ Fox、Duquette は、そうしたト
レード研究で最適システム設計に至る効率的な方法として分散化方式について説明してい
る）。この時点までに得られる主な成果は、システムとその最終アイテムに関する承認ずみ
「機能」ベースラインと予備"design-to" ベースラインである。このような作業からは、
各種の技術計画書とマネジメント計画書が得られる。この計画書は、検証や運用といった
プロジェクトの下流段階の管理や、工学専門プログラムの実施に必要なものである。
このような成果を得るまでに、プロジェクトは「非支持者審査」（ＮＡＲ＝Non-Advocate
Review)を受けなければならない。この審査では、プロジェクトの目的の明確性と、技術・
マネジメント計画、技術文書、代替案探索、トレード研究などの徹底性という面からプロ
ジェクトの定義状態を評価することが狙いである。ＮＡＲでは、コスト予測とスケジュー
ル予測や、この予測における偶発的損失準備金をも評価する。この審査の時期は、連邦予
算サイクルに左右されることが多い。連邦予算サイクルでは、大統領行政管理予算局（Ｏ
ＭＢ＝Office of Management and Budget)に提出するＮＡＳＡ（米国航空宇宙局）予算案
の作成から新規プロジェクト発足に対する連邦議会の資金供与までに少なくとも 16 カ月は
かかる。（第 3.8 項を参照）。そのため、ＮＡＲの時までにプロジェクトを煮詰めたいとい
う願望と最終設計と開発まで効率的に進めたいという願望の間に当然拮抗した緊張が生じ
る。
フェーズＢの後半では、ミッションの目標と目的を達成できる機能的に完全な設計解決
策（つまり、"design-to" ベースライン）を設定するという作業へと移る。トレード研究
も継続される。主要最終アイテム間のインタフェースも定義される。技術試験項目も設定
され、その後の設計作業に必要なデータを得るために使用される。技術開発とその実証実
験が成功すれば、プロジェクトのリスクは低下する。フェーズＢの最後を飾るのは、一連
の「基本設計審査」（ＰＤＲ＝Preliminary Design Review)である。この審査は、システム・
レベルのＰＤＲ、低レベル最終アイテムのＰＤＲなどからなる。こうしたＰＤＲは設計に
- 27 -
導入された要求事項の連続改良化を反映したものである。ＰＤＲで明らかになった設計上
の問題点は、明確な"design-to" 仕様で最終設計を開始できるように解決すべきである。
この時点から、ベースラインに加えられるほとんどすべての変更事項は、基本的変更では
なく、連続改良を加味したものとなろう。ベースライン化に先立ち、システム・アーキテ
クチャ、基本設計、運用概念を十分な技術解析と設計作業により認証し、フェーズＡより
も低レベルの詳細度で「信頼性のある実現可能な」設計を確定しておかなければならない。
3.4
フェーズＣ
−
設計段階
この段階の目的は、組み立て（またはコード化）、統合化、検証などが行いやすい完全な
設計（"build-to"ベースライン）を確定することである。トレード研究は継続される。実
際のハードウェアに最も近い技術試験用ユニットを製造して試験し、その設計が予定環境
内でうまく機能するという確証を得る。工学専門解析の結果を設計に導入し、製造工程と
コントロールの定義と検証を行う。インタフェースが詳細に定義されるに伴い、コンフィ
ギュレーションマネジメントにより設計変更を探索し調節する。最終設計の連続改良プロ
セスの各段階では、統合化・検証作業計画を更に詳細に策定する。フェーズＣでは、技術
パラメータ、スケジュール、予算を探索し、望ましくない傾向（予想外の衛星重量の増大
やそのコスト上昇など）を早期に認識し、補正対策を講じる。（第 4.9 項を参照）。
フ ェ ー ズ Ｃ の 最 後 を 飾 る の は 、 一 連 の 「 詳 細 設 計 審 査 」（ＣＤＲ＝Critical Design
Reviews）である。この審査は、システム・レベルのＣＤＲやシステム階層の各種レベルに
対応するＣＤＲなどからなる。ＣＤＲは、ハードウェア最終アイテムの組み立てや生産の
前または引き渡し可能ソフトウェア製品のコード化開始前に実施する。通例、こうした一
連のＣＤＲでは、次のフェーズＤで実施される統合化プロセス
ＤＲからシステム・レベルＣＤＲまでのプロセス
−
−
つまり、低レベルＣ
を反映させる。しかし、各プロジ
ェクトでは、それぞれのニーズに合わせてこのような審査の順序を調整すべきである。こ
のフェーズＣから得られる最終結果は、実際に生産を進められるくらい詳細な"build-to"
ベースラインである。
- 28 -
フェーズＣ
−
設計段階
システム（およびその関連サブシステムと運用向けシステム）の詳細設計を完成さ
せる。
主な作業とその成果：
システム・アーキテクチャに残りの「低レベル設計仕様」を加える。
「要求文書」を改良する。
「検証計画書」を改良する。
「インタフェース文書」を作成する。
（連続改良プロセスをくり返して、あらゆるレベルの「"build-to"仕様書と図面」、
「検証計画書」、「インタフェース文書」を得る）。
「システム・アーキテクチャ」、「検証要求条件マトリックス」、「作業明細構成書」、
「プロジェクト計画書」など、システムの成熟度向上を反映させたベースライン文書を
増やす。
プロジェクト計画書に照らしてプロジェクトの進捗状態を監視する。
「システム統合化計画書」と「システム運用計画書」を作成する。
「トレード研究」を実施し、その結果を記録保管所に保管する。
「製造計画書」を完成させる。
「End-to-end 情報システム設計」を開発する。
「総合ロジスティックス支援計画書」（Integrated Logistics Support Plan)を改良する。
計画製品を改良する機会を特定する。
「科学ペイロードの選定」を確認する。
ベースライン化情報：
残りの低レベル要求事項と設計すべてと高レベルまでのトレーサビリティ。
あらゆるレベルの"Build-to"仕様。
コントロール・ゲート：
サブシステム（および低レベル）の基本設計審査。
システム・レベルの基本設計審査。
目的：
3.5
フェーズＤ
−
開発段階
この段階の目的は、前段階で設計したシステムの構築と検証を行い、そのシステムを配備
し、その運用準備を行うことである。その作業としては、ハードウェアの組み立てとソフ
トウェアのコード化、システムの統合化と検証を行う。その他の作業としては、操作担当
員のトレーニングと「総合ロジスティックス支援計画」（Integrated Logistics Support
Plan)の実施がある。飛行プロジェクトでは、次の作業の中心が飛行前の統合と打ち上げへ
移行する。大型飛行プロジェクトでは、軌道投入、組み立て、初回シェークダウン（飛行
試験）の作業期間が延長されることもある。このフェーズＤの主な成果は、開発目的を達
成できることを実証したシステムである。
- 29 -
フェーズＤ
目的：
−
開発段階
サブシステム（および運用向けシステム）を構築し、システム要求事項に適合
するように信頼性を向上させながら、その要求を統合化してシステムを構築す
る。さらに、システムを配備し、その運用準備を整える。
主な作業とその成果：
「部品」（つまり、システム・アーキテクチャにおける最低レベルアイテム）の組み立て
（またはコード化）を行う。
統合化計画に従ってそれらのアイテムの統合化と検証を行い、「検証済みの構成部品と
サブシステム」を得る。
（連続統合化プロセスをくり返して「検証済みシステム」を得る）。
あらゆるレベルの「検証要領書」を作成する。
「システム認定試験」を実施する。
「システム受領試験」を実施する。
プロジェクト計画書に照らしてプロジェクトの進捗状況を監視する。
実施した「検証」関係の文書を記録保管所に保管する。
「完成状態」（"as built"）コンフィギュレーションを監査する。
「教訓」文書を作成する。
「運用説明書」を作成する。
「保全説明書」を作成する。
「第１期のシステム・オペレータと保全整備要員」のトレーニングを実施する。
「総合ロジスティックス支援計画」を完成させ、それを実施する。
打ち上げロケットとの統合、打ち上げ、軌道投入などを実施し、「システムの配備」を完
了する。
「運用試験」を実施する。
ベースライン化情報：
「完成状態」と「配備状態」のコンフィギュレーション・データ。
総合ロジスティックス支援計画書（Integrated Logistics Support Plan）。
End-to-end コマンド、テレメトリバリデーション、地上データ処理向けのコマンド列。
運用説明書。
保全説明書。
コントロール・ゲート：
試験準備審査（全レベル）。
システム受領審査。
システムの機能的・物理的コンフィギュレーション監査。
飛行準備審査。
運用準備審査。
安全性審査。
- 30 -
3.6
フェーズＥ
−
運用段階
この段階の目的は、当初特定したニーズを満たすか、当初特定した機会を捉えることで
ある。この段階から得られる成果は、ミッションの結果である。システム・アーキテクチ
ャに重要な変更を加えない限り、つまり、そうした変更が新しい「ニーズ」となり、プロ
ジェクト・ライフサイクルを最初からやり直すことがない限り、この段階ではシステムの
進展も扱う。
フェーズＥ
目的：
−
運用段階
当初特定したニーズを満たすか、機会を捉えた後、妥当な方法でシステムを廃
棄する。
主な作業とその成果：
交代制の「オペレータと保全整備要員」のトレーニングを行う。
「ミッション」を実施する。
「システム」の保全とグレードアップを行う。
システムとその支援プロセスを処分する。
「教訓」文書を作成する。
ベースライン化情報：
次のようなミッションの成果：
・
システム、サブシステム、材料の性能に関する技術データ
・
回収された科学データ
・
軌道上から撮影された高解像度写真
・
業績記録（「最初のもの」）
・
バンアレン帯の発見
・
木星の第１惑星「イオ」の火山発見
運用・保全整備経時記録。
問題／故障報告書。
コントロール・ゲート：
システム運用準備定期審査
システム改良審査
安全性審査
デコミッショニング審査
フェーズＥでは、ミッション完了時のシステム廃棄問題も扱う。そうした廃棄時期は、
多くの要因に左右される。「スペースラブ」のペイロードのような、ミッション期間の短い
飛行システムの場合、その廃棄はハードウェアの分解とその所有者への返却ぐらいですむ。
- 31 -
長期間の大型飛行プロジェクトの場合は、長年採用されている計画に基づいて廃棄作業を
進めることもあれば、事故のような不測の事態によって処分が行われる場合もある。また、
技術が進歩したために、在来型やそれに改良を加えた構成でシステムを運用すると経済性
がなくなる場合もある。
システムの安全なデコミッショニングと廃棄に関連のある作業は、その開始時期が不確
定な上に、時間もかかり複雑になる場合もある。したがって、各種設計のコストとリスク
は、プロジェクトの初期段階に検討しておくべきである。
3.7
プロジェクト・ライフサイクルにおけるシステムエンジニアリングの役割
この項では、プロジェクト・ライフサイクルにおける一連のシステムエンジニアリング
作業に関する「理想化した」説明図を２例示す。その一つは Forsberg と Mooz の「Ｖ形」
チャートであり、ＮＡＳＡ（米国航空宇宙局）のプログラム／プロジェクトマネジメント
講座でも教えている。もう一つは、ＮＡＳＡプログラム／プロジェクトのライフサイクル・
プロセスフローチャートで、全ＮＡＳＡシステムエンジニアリング・プロセス改良作業
(NASA-wide Systems Engineering Process Improvement Task)チームが 1993／94 年に開発
したものである。
3.7.1 「Ｖ形」チャート
Forsberg と Mooz は、「プロジェクト・サイクルの技術面」というものをＶ形チャートを
使って説明している。このＶ形チャートは、左上に示すユーザーのニーズから始まり、右
上のユーザー検証システムで終わる。図７では、こうした作業の概観を示す。Ｖ形チャー
トの左側では、分解・定義作業でシステム・アーキテクチャを分解し、設計の細部を形成
する。高レベルのサブシステムが順次検証されるに従い、統合化・検証作業は右側を上方
へ流れ、システム・レベルまで達する。この概略図は、ソフトウェア管理保証プログラム
（ＳＭＡＰ＝Software Management and Assurance Program）の一部としてＮＡＳＡが開発
したＶ形チャートの基本的概要を踏襲したものである。（図にある「ＣＩ」という用語は、
コンフィギュレーションマネジメントシステム（Configuration Management System）によ
り管理されるハードウェアとソフトウェアの「コンフィギュレーション（形態）アイテム」
（Configuration Items)を指す）。
分解と定義
図７には示されていないが、Ｖ形チャートにある各枠は多数の枠列からなり、その分解
レベルにおいてシステムを構成するサブシステムが多数あることを示唆している。左最上
部の枠を構成する多数の枠列は、最初に評価される多数の設計概念案を表わす。
- 32 -
製品開発が進むにつれて、一連のベースラインが徐々に設定される。その各ベースライ
ンは、承認されると同時に正式にコンフィギュレーション管理下に置かれる。コンフィギ
ュレーション管理の基本目的は、要求事項の「クリーピング」（徐々に増加すること）を防
止することにある。
Ｖ形の中心から左側は、製品開発プロセスの「滝型」または「要求誘因型設計」モデル
と呼ばれるものに似ている。コントロール・ゲートは、そのプロセスにおける重要な決定
時点を明確にする。その時点で承認された決定事項を記載した文書をプロジェクトマネジ
ャが公表し管理する準備態勢ができるまでは、いかなる作業も進めることはできない。
しかし、プロセスの初期に細目作業を実施することを禁止するものはない。実際には、
ユーザーのニーズを明確にするとか、信頼性を確立して実現の可能性を主張するために、
ごく初期の段階で詳細なハードウェアやソフトウェアが必要になることもある。初期にお
いて関連技術分野や支援分野を採用することは、このプロセスに欠かせない重要部分とな
る。これは実際には「コンカレントエンジニアリング」（concurrent engineering）の採用
ということになる。
Ｖ形チャートの各レベルにおけるシステムエンジニアリング作業には、システム設計、
先端技術開発、トレード研究、リスクマネジメント、専門技術解析、モデル作成といった
非中核プロセスも含まれる。この点は、図７（ｂ）のチャートに直交プロセスとして示さ
れている。これらの作業は各レベルで実施され、フェーズ内で何度もくり返し実施される
こともある。多くの研究や決定ではこのような非中核作業も伴うが、中核レベルの決定だ
けは各種コントロール・ゲートにおけるコンフィギュレーション管理下に置かれる。非中
核作業、解析、モデルは、そのような中核決定の代わりに使用されるか、リスクを軽減し
たり、許容範囲内に抑えたりするために使用される。非中核作業は正式に管理されること
はないが、解析方法、データ、解析結果は記録保管所に保管すべきである。そうすれば、
適時に適当な詳細度レベルで複写してベースラインに導入しやすくなる。
実現性を確立し、リスクの特定と定量化を行うためには、十分な下降反復を行うことも
でき、またそうすべきである。要求報告書（および中間文書）による上昇反復も可能だが、
ユーザーがさらに要求を出さない（または変更しない）限り、最低限にとどめるべきであ
る。ソフトウェア・プロジェクトでは、ユーザーによる解決策に対する上昇方向の確認が
必要になる場合も多い。なぜならば、プロジェクト開始時にはユーザーの要求を十分明確
にできないからである。しかし、ソフトウェア・プロジェクトでも、ユーザーの要求の反
復はＰＤＲ（Preliminary Design Review ＝基本設計審査）で停止すべきである。さもな
ければ、コストとスケジュールを管理できなくなる恐れがある。
基本設計審査（ＰＤＲ）後にユーザーの要求を変更するのは、新型製品の開発まで待つ
べきである。基本設計審査後にユーザーの要求に重大な変更が加えられたら、プロジェク
トを停止して新たにＶ形プロセスを再開し、そのプロセス全体をくり返すべきである。初
回のプロセスから教訓が得られるので、新規プロセスを迅速化することもできる。それで
- 33 -
も、すべての段階をくり返すことに変わりはない。
時間とプロジェクトの成熟度は、Ｖ形チャートの左側から右側へと流れる。コントロー
ル・ゲートをひとたび通過すると、下降反復は不可能となる。たとえばユーザーの要求に
よる反復は、Ｖ形チャートに示すように、垂直方向にしか実施できない。
ユーザー認証計画書に従
ってシステムの実証試験
と検証を実施する
ユーザーの要求を理解し、
システム概念を開発し、検
証計画書を作成する
(b)
システム解
析・設計プロ
セス
性能仕様書に従ってシス
テムの統合化とシステム
の検証を行う
性能仕様書をＣＩ
"Design-to" 仕様書と
検査計画書にまで拡
張する
分解・定義シーケンス
"Design-to" 仕様書を
"Build-to"文書と検査計
画書にまで発展させる
ＣＩ"Design-to" 仕様書に
従ってＣＩの組み立てと
ＣＩの検証を実施する
システム検
証・統合化プ
ロセス
"Build-to"文書に従って
検査する
"Build-to"文書に従って製
造、組み立て、コード化を
行う
統合化・検証シーケンス
システム性能仕様書と
システム検証計画書を
作成する
(a)
図７
(c)
ＮＡＳＡプロジェクトサイクル技術面の概観
統合化と検証
Ｖ形チャートの右側を上昇するプロセスは「統合化・検証」プロセスである。各レベル
では、Ｖ形チャートの左側と右側の作業の間に対応関係があるもので、これは作為的なも
のである。各レベルにおいて要求が「出され、文書化される」に従って、検証方法を決定
しなければならない。そうすれば、測定も検証もできないような要求が仕様書に記載され
る機会は少なくなる。
最高レベルでも、ユーザーの要求がシステム要求書に転記されることによって、そのシ
ステムがその要求を実行するかどうかを実証するシステム検証方式を決定しなければなら
ない。第７（ｃ）図に直交プロセスとして示されている検証プロセスの技術的要求は、コ
ストとスケジュールの決定要因となり、実際には各種設計概念間を区別する要因となるこ
ともある。たとえば、検証や妥当性確認にエンジニアリングモデルを採用する場合は、そ
の仕様も指定し、そのコストも試算し、その特性も定義しなければならず、その開発時間
を初めからスケジュールに組み込まなければならない。
- 34 -
漸進的開発
ユーザーの要求がはっきりしないため、ＰＤＲ（Preliminary Design Review ＝基本設
計審査）において最終定義を行えない場合は、所定の公表分ずつ漸進的にプロジェクトの
開発を進めるという方法がある。最初の開発段階ではユーザーの最低要求件数を満たすこ
とを優先し、その後の段階では機能性と性能を徐々に加える。これはソフトウェア開発で
一般的に採用されている方法である。
漸進的開発方式はＶ形チャートを使えば説明しやすい。第１回基本設計審査（ＰＤＲ）
までのすべての漸進的開発分には、共通して引き継がれるものがある。製品開発プロセス
の残りの段階には、ずれてオーバーラップした一連のＶ形が各公表分に１つづつある。
3.7.2
ＮＡＳＡプログラム／プロジェクトのライフサイクル・プロセスフローチャート
ＮＡＳＡプロジェクトのライフサイクル中に実施される一連の技術的作業に関するもう
一つの理想化した説明は、図８に示すものである。この図では、ＮＡＳＡプロジェクトの
ライフサイクルが 10 個の流れのブロックに区分されている。このハンドブックでは、その
各ブロックを「段階」(stage）という。各段階は、システムの成熟度に応じて実施する必
要がある作業の変化を反映している。このような段階は時間的、論理的に相互関連がある。
連続した段階は、徐々に向上するシステムの改良度と成熟度を示し、その入力情報として
前段階の成果を必要とする。新しい段階への移行時には、技術的作業の種類や範囲の大き
な転換を伴う。コントロール・ゲートでは、ある段階から次の段階へ進むのが賢明かどう
かを評価する。（特定審査の合格基準については、第 4.8.3 項を参照）。システムの技術的
進歩を監視しなければならないシステムエンジニアの視点から見ると、図８はＮＡＳＡの
プロジェクト・ライフサイクルにおいて必要となる実際の作業をかなり完全に説明したも
のと言える。
実際には、このような段階が必ずしも連続的に起こるわけではない。次々と起こる事象
が目標や想定を無効にしたり変更させたりすることもある。その結果、前段階の結果に立
ち戻ったり、それらを変更したりする必要も生じる。システムを構成する各種最終アイテ
ムは、それぞれ異なった開発スケジュールや制約を持つことも多い。この点がとりわけ顕
著に見られるのは、一部のサブシステムが最終設計中で、その他のサブシステムが製造・
組み立て中であるフェーズＣとＤである。
技術的作業の成果は、システムエンジニアリング作業（たとえば要求と仕様、トレード
研究、専門工学的解析、検証結果など）を支援し、各種コントロール・ゲートの入力情報
として役立つ。システムエンジニアリングから得られた詳細データベース、データベース・
ディクショナリ、成熟度指針書については、「プログラムとプロジェクトのＮＡＳＡシステ
ムエンジニアリング・プロセス」（NASA Systems Engineering Process for Programs and
Projects）ＪＳＣ-49040 を参照されたい。
- 35 -
図７と図８からは、特に重視すべき価値あるいくつかの問題が提示される。これらの問
題としては、コンカレントエンジニアリング、技術導入、検証と妥当性確認の区別などが
ある。
コンカレントエンジニアリング
プロジェクトが未成熟のまま前半のコントロール・ゲートを通過すると、開発プロセス
の後半で要求と設計を何回もくり返す必要が生じがちである。このくり返しが起こる一因
は、初期の段階に適格な技術専門家を介入させなかったためであり、そのために到底満た
せないような要求を受け入れ、構築、試験、保全、運用を行えないような設計概念を選定
するという結果になったことである。
コンカレントエンジニアリングとは、多くの学問分野のチームが製品と製法に対する下
流部門の要求を同時に検討することである。最終的に製品に導入されるあらゆる専門技術
の分野（信頼性、保全性、人的要因、安全性、ロジスティックスなど）から集められた専
門技術者たちは、システムのライフサイクル全体にわたって重要な貢献を果たす。こうし
た専門技術者たちを各段階のプロジェクトチームに加えるのは、システムエンジニアの責
務である。大型プロジェクトでは、多くの総合「製品開発チーム」（Product Development
Team＝ＰＤＴ）が必要になることもある。これらの各チームは、プロジェクトにおける次
の高位レベルのＰＤＴに代表を出すことになる。しかし、小型プロジェクトでは、システ
ムエンジニアが必要な技術分野やビジネス分野の専門家だけでよいと主張すれば、小型チ
ームで十分間に合うことも多い。
コンカレントエンジニアリングを実施する際の情報条件は厳しい。コンカレントエンジ
ニアリングの専門家たちが負担を軽減できると考える一つの方法は、自動化環境によるも
のである。そうした環境では、システムエンジニアリング、設計、解析用のツールでデー
タの交換を行いやすく、計算環境が相互に関連し合い、正確な製品データを入手しやすく
なる。自動化環境の特徴については、たとえば 1992 年に出版された Carter、Baker 共著
"Concurrent Engineering"（コンカレントエンジニアリング）を参照されたい。
- 36 -
総合製品開発チーム
製品と製法の実現性に関する詳細評価と重要な不確定要因（システムの各種リスク）の
特定は、さまざまな分野の専門家によって実施されなければならない。従来効果的とみな
される方法は、あらゆる関連分野と関連製法の代表によって製品開発のためのチームを結
成することである。こうした総合製品開発チームは、多分野（技術とビジネス）のメンバ
ーで構成されることが多い。生産、検証、配備、支援、訓練、運用、廃棄を実施できるか
どうかといった問題すべてを設計段階で検討するには、技術者が必要である。さらに、ビ
ジネス業界（たとえば調達など）の代表も、必要に応じてチームに加えられる。システム
のライフサイクル全体にわたってこのような専門分野の団体から継続的に支援を得ること
が極めて望ましい。しかし、システムがフェーズからフェーズへ進むにつれて、チームの
構成とリーダーは変わっていくものと思われる。
技術の導入
プロジェクト発足の動機が在来型の技術不足にある場合もあれば、大幅な製品改良をもた
らす新技術の出現にある場合もある。技術開発はプロジェクトの進行と並行して実施する
ことができ、その導入をＰＤＲ（Preliminary Design Review ＝基本設計審査）まで遅ら
せることもできる。高リスクを受け入れられない場合は、新技術の開発に依存し「ない」
並行方式を実施する必要がある。技術開発事業はリスク事業として、プロジェクトマネジ
ャとシステムエンジニアが管理すべきである。
検証と妥当性確認
検証と妥当性確認を区別することは重要である。「検証」は、仕様書に準拠しているかど
うかを証明することであり、試験、解析、実証試験、検査などによって判定を行うことが
できる。（第 6.6 項を参照）。「妥当性確認」は、システムがその目的を達成したか（少し控
えめに言うと、達成できるか）どうかを証明することである。通常、システムの検証より
も妥当性確認の方がはるかに困難で（しかも重要で）ある。厳密に言えば、妥当性確認は
システム・レベルでしか実施できないが、検証はシステム・アーキテクチャの全階層にわ
たって実施しなければならない。
- 37 -
図 8 NASA プログラム／プロジェクトライフサイクル フローチャート
ミッションの実現性
・
・
・
マネージメント
決定
ミッションの目的とトップレベルの機能・性能要求を定義する。
ミッションの技術的実現性とプログラム的実現性を確証する。
ミッションに対する顧客のニーズを確認する。
ミッション
概念審査
要求と概念のくり返しにより実現性を確定する
開 始
ミッションのニーズ、
目標と目的、計画方針
実現可能な各種代替案を特定する
顧客を理解する
1.3 トップレベル
のミッション
要求を設定す
る
1.1 ユーザーのニ
ーズと目的を
改良する
ミッションのニー
ズ、目標、目的
科学的要求、
ミッ
ション要求
1.8 要求事項を配
分する
1.2 制約と想定を
改良する
評価基準、標準ミッショ
ン、ＴＰＭ
配分済み要求事項、
ＴＰＭ予算とマージン
1.9 分析と評価を
行う
1.7 実現可能なシ
ステム概念を
設定する
1.4 ミッションのト
ップレベル機能
概念を設定する
コスト／効果分析、環境評価、実
現性評価、専門技術研究、ライフ
サイクル・コスト予測、トレード・
分析結果
システム概念とシステム・ア
ーキテクチャー、設計開示、
製品明細構成、運用概念
ミッションの機能概念
1.12 ツールと方法を設定
する
報告書／提案書、
システム仕様書
システム／セグメント要求
1.5 評価基準を設
定する
想定、指針、制約
1.10 統合化と
ダウンセレク
ト
1.6 トップレベルの
システム要求事
項をフローダウ
ンする
分析モデル、システムエンジニアリング
用ツール
分析モデル、システムエンジニアリング
用ツール
1.11 技術計画とマネジメント
教 訓
プログラム／プロジェクトマネジメント計画書、エンジニア
リング・マスタープラン／マスタースケジュール
ＴＰＭ（Technical Performance Measurement ＝技術的性能測定）
システムの成熟度
実現可能概念
凡例
要求事項
説計
要求／設計
概念
HW とSW
エンジニアリングアイテム
基本
認定試験アイテム
最終／承認済み
最終アイテム
−実現性に重点を置く。
システム
−概念の範囲を制限する。
−オプション数を制限する。 セグメント
−詳細度を制限する。
−主要サブシステム。 エレメント
−技術的実現性。
サブシステム
アセンブリ
調達段階
ＮＡＳＡ
プリフェーズＡ：最新研究段階
フェーズＡ承認
国防総省
プリマイルストーン０
- 38 -
2.1 へ
ミッションの定義
・
・
・
・
マネージメント
決定
ミッションの目的に適合する（セグメント・レベルの）
妥当性確認済み要求を確定する。
アーキテクチャーとトップレベルの運用概念を確定する。
技術リスクとその軽減対策を特定する。
プログラム経営資源需要予測を改良する。
ミッション
定義審査
要求と概念をくり返して最適システム要求事項とトップレベル・アーキテクチ
ャを確定する
ミッション
要求条件審査
最適アーキテクチャーを確定する
ミッション要求事項を分析する
2.1 ミッションのト
ップレベル要求
事項を詳細する
ミッションのニー
ズ、目標と目的、科
学的要求事項、ミッ
ション要求事項、想
定・指針・制約
2.4 システム要求
事項を定義・改良
する
2.3 評価基準を設
定・詳細する
システム要求事項、
科学的要求事項、
廃棄要求事項、
検証要求事項
2.6 セグメント／エ
レメントに要求
事項を配分する
評価基準、標準ミッショ
ン、ＴＰＭ
性能要求事項、
ＴＰＭ予算とマージン
2.5 各種システム・アー
キテクチャー案とシ
ステム概念案を設定
する
2.2 ミッション概
念と運用を改良
する
システム仕様書、技術開発要求書
2.8 統合化とダウ
ンセレクト
３．１へ
2.7 アーキテクチ
ャーと概念を分
析・評価する
コスト／効果分析、環境評価、実現性評
価、専門技術研究、ライフサイクル・コ
スト予測、トレードオフ・分析結果
システムの概念とアーキテクチャ、
設計開示、製品明細構成、運用概念
ミッション概念、運用概念
2.10 ツールと方法を設定する
解析モデル、システムエンジニアリング
用ツール、試験施設と試験設備
2.9 技術計画と技術管理
プログラム／プロジェクト管理計画、システムエンジニ
アリング管理計画、エンジニアリング・マスタープラン
／マスタースケジュール
技術開発計画書、総合ロジスティックス支援プログラ
ム計画書、リスク管理計画書、コンフィギュレーショ
ン管理計画書、情報管理計画書
教訓
トップレベル・アーキテクチャ
各種アーキテクチャー案
システム
−最適化トップレベル・
アーキテクチャ
−クリティカル技術の
オプションとリスク。
−最適性に重点を置く。
−概念の範囲を広くする。
−多数のオプションを
セグメント
検討する。
−詳細度を高める。
−サブシステム概念 エレメント
−クリティカル
サブシステム
技術
シシ
スス
テテ
ムム
セグ
グメ
メン
ント
ト
セ
エレメント
サブシステム
アセンブリ
アセンブリ
フェーズＡ：予備解析段階
機会の公告
概念の探索と定義
- 39 -
プリＰＰＡＲ
プリＮＡＲ
ＭＮＳ承認
フェーズB/C/D ＲＦＰ
搭載機器選定
システムの定義
・
・
・
・
・
・
最終品目の妥当性確認された要求（完全機能ベースライン）
を確定する。
「アーキテクチャ」レベルの設計を完了する。
技術リスク：クリティカルリスク、長いリードタイムを
軽減する。
プログラム資源と技術資源の予測を確定する。
プログラムリスクを軽減する。
コスト、スケジュール、性能上の制約内でシステムを構築で
きることを実証する。
マネージメント
決定
シ
ス
テテ
ムム
要求
シ
ス
審審
査査
定義
3.8 統合化する
経営資源バランス、分析的統合
セグメントＣ
シ
ス
テム
ム要
要求
求
シ
ス
テ
セグメントＢ
審査
査
審
セグメントＡ
システム要求事項を分析する
3.1 ミッション
と要求の分析
最適システム設計を確定する
3.3 要求事項をフ
ローダウン
し、改良する
3.5 最終アイテム
に要求事項を
配分する
改良ミッション要求、シス
テム要求、検証要求、適用
規格
3.2 システム評価
基準を設定す
る
評価基準、標準ミッション、
ＴＰＭ、合格基準
低レベル要求書、検証要
求事項マトリックス、想
定・指針・制約
システム仕様書、
"Design-to" 仕様書、検証
マトリックス、インターフ
ェース要求書、ＴＰＭ予算
3.4 基本／主要アイ
設計開示、打ち上げ作業、運
テム概念を設
用、インターフェース制御文
定・改良する
書、統合化と組み立て、総合
ロジスティックス支援
3.6 システム最終
アイテム概念を
評価・分析する
4.1 へ
コスト／効果、ロジステ
ィックス支援、生産性、
信頼性と保守整備性、安
全性／ハザード解析、専
門技術、ライフサイク
ル・コスト、トレードオ
フ・分析結果
3.7 統合化して最
適オプション
を選定する
要求と概念をくり返して最適"design-to" ベースラインを確定する
開発試験結果、技術アイテム
3.9 技術を開発する
3.11 ツールと方法を開発・改良する
分析方法、システムエンジニアリン
グ用ツール、試験施設と試験設備
教 訓
3.10 技術管理と技術計画
プログラム／プロジェクトマネジメント
計画書、
システムエンジニアリングマネジ
メント計画書、エンジニアリング・マスタ
ープラン／マスタースケジュール
検証計画書、統合化・組立計画書、製造
計画書、品質保証計画書、ＥＭＩ／ＥＭ
Ｃコントロールプラン、ペイロード・キ
ャリア統合化計画書、
システム安全生計
画書、技術開発計画書
総合ロジスティックス支援プログラム計画書、
信頼性プログラム計画書、コンフィギュレーシ
ョンマネジメント計画書、文書樹形図、図面樹
形図／技術図面リスト、情報マネジメント計画
書、仕様書樹形図、リスクマネジメント計画書、
作業報告書
機能ベースライン
−エレメント・レベル
への配分。
−技術とリスク軽減。
−実証試験。
−概念の実証結果。
−原型ソフトウェア。
システム
セグメント
エレメント
サブシステム
アセンブリ
フェーズＢ：定義段階
ＰＰＡＲ
ＮＡＲ
ＰＣＡ承認
実証試験と検証
- 40 -
最終設計
初期設計
・
・
・
・
・
・
・
・
ミッション要求を完全に満足する設計解決
の確立
試験および検証計画の完成
設計依存の要求とインタフェースの確立
設計の「実行」レベルの完成
安全で妥当性確認された詳細設計
全ての設計専門家監査の完了
製造プロセスとコントロールの確立
インタフェースの最終化と統合化
マネージメント
決定
マネージメント
決定
4.8 システム、セグメント、エレメントの統合
5.7 システム、セグメント、エレメントの統合
システム要求
基本設計
審査
経営資源バランス
分析的統合
経営資源バランス
分析的統合
審査
システム
詳細設計
受領審査
審査
セ
セ
グ
グ
メ
メ
ン
ン
ト
ト
Ｃ
Ｃ
セグメントＢ
セグメントＡ
初期設定
4.1 初期設計
要求の分析と
精緻化
設計解析要求
トレード、
解析結果
仕様更新
フローダウン要求
廃棄要求
インタフェース要求
検証要求
インタフェースコントロール文書
最終設計
ペイロードツーキャリヤー統合計画
コスト／効果
5.1 詳細インタ
環境、原子力、故障モードおよび
フェースの
効果、ロジスティック支援、
定義とコント
製造性、信頼性および保全性
ロール
安全／ハザード、特別な工学、
ライフサイクルコスト
4.6 設計の評価、
検証及び
妥当性確認
コスト／効果
環境、原子力、故障モード
及び効果、ロジスティック
支援、特別な工学、製造性、
信頼性及び保全性、安全／
ハザード、ライフサイクル
コスト
4.2 設計分析
の実施
4.3 エンジニア
リング
開発試験の
実施
5.2 詳細設計の
実施
4.5 初期設計
の実施
設計発表
材料および工程データ
統合および組立て
設計発表
電子部品リスト
ハードウェア／
ソフトウェアリスト
搭載機器プログラム
及びコマンドリスト
開発試験結果
エンジニアング
項目
4.4 インター
フェース
定義
5.6 詳細設計
および
生産計画
5.3 エンジニア
リング試験
の実施
製造仕様
検証要求および仕様
開発試験結果
エンジニアリング項目
4.7 認定項目の
計画と文書化
の完了
統合スケマチック
インタフェース
コントロール文書
5.5 設計の評価、
検証および
妥当性確認
5.4 製造／試験
認定項目
認定項目計画
認定項目
認定結果
教訓
4.9 技術マネージメントと計画
プログラム／プロジェクト マネジメント
計画、システムズエンジニアリング マネ
ジメント計画、エンジニアリング マスター
計画／マスタースケジュール
検証計画
統合ロジスティック支援計画
統合および組立て計画
材料および工程コントロール計画
製造計画、品質保証計画
EMI／EMC コントロール計画
ペイロードツーキャリアー
統合計画、システム安全計画
信頼性プログラム計画
コンフィギュレーション マネー
ジメント計画
文書ツリー、図面ツリー／リスト
情報マネージメント計画
仕様ツリー
リスクマネージメント計画
ステートメントオブワーク
プログラム／プロジェクト計画
エンジニアリングマスター計画
／マスタースケジュール
−設計の実現化完了
−認定項目
システム
システム
セグメント
セグメント
エレメント
エレメント
サブシステム
サブシステム
アセンブリ
アセンブリ
フェーズＢ：定義
PPAR
NAR
PCA の承認
改訂／更新された計画
教訓
「製造」ベースライン
「設計」ベースライン
−機能的に設計完了
−コンポネント構成と実行
−技術実証と試験
−モックアップとモデル
−ソフトウェアプロトタイプ
5.8 技術マネージメントと計画
フェーズＣ：設計
MNS の再承認
契約相手方選定決定
エンジニアリングと製造開発
- 41 -
生産と統合化
・
・
・
・
・
マ
マネ
ネー
ージ
ジメ
メン
ント
ト
決
決定
定
仕様書と受領基準に適合するアイテムを製造する。
システムの組立と統合化を行う。
システムの検証と妥当性確認を行う。
ミッションを実施するシステムを使用できる機能を開発する。
生産、保全、運用向け施設を用意する。
マネージメント
決定
6.11 システムを統合化し、インターフェースのコントロールと検証を行う
システム
システム
受領審査
受領審査
生産準備
審査
試験準備
審査
6.1 生産施設を
用意する
6.3 最終アイテム
の検証試験準
備を完了する
6.6 システムの
組立と物理的
統合化を行う
6.5 最終アイテ
ムの試験／
検証を行う
最終アイテム、支援アイテム、
予備アイテム、品質保証結果
6.9 システムの
試験／検証
を行う
検証要求事項適合
書、検証及び妥当性
確認評価結果、試験
済みシステム
統合化システム、
支援設備
検証済みハードウェ
ア／ソフトウェア、
検証及び認証済みハ
ードウェア／ソフト
ウェア、検証要求書、
適合性
検証要領書と検証データ、
試験施設と試験設備
6.4 最終アイテム
の計画書／文
書を完成する
検
検証
証と
と受
受領
領
統合化と試験
製造と組立
6.2 最終アイテム
の生産と組み
立てを行う
6.7 システムの試
験計画書と文
書を完成する
7.1 へ
6.10 受領試験
を実施する
検証要領書とデータ、飛行中点検計画書
引き渡し可能システム、
合格データ
6.8 システムの計
画書と文書を
完成する
「完成状態」関係文書、
技術説明書とデータ、
使用説明書
「完成状態」最終文書、運用要領書
訓練済み要員、トレーニング用施設・設
備・教材
6.12 トレーニングを行う
6.13 技術マネジメントと技術計画
プログラム／プロジェクトマネジメント計画書、
エンジニ
アリング・マスタープラン／マスタースケジュール
問題／故障報告書、権利放
棄書
改訂／更新計画書
教訓
「完成状態」ベースライン
−組立・試験
システム
済み飛行ユニット。
−システムとセグ
セグメント
メントの試験。
エレメント
サブシステム
アセンブリ
フェーズＤ：開発段階
自主準備審査
生産と開発
- 42 -
配備準備
・
・
配備及び運用検証
打ち上げ／配備用システムを構成する。
打ち上げ／配備態勢を整える。
・
・
・
システムの打ち上げ／配備を行う。
システムの運用範囲を確定する。
システムのロジスティックスを確定する。
マネージメント
決定
飛行準備
審査
配備準備をする
運用準備
審査
配備及び運用検証
7.2 打ち上げ用ハ
ードウェアを
構成する
8.1 打ち上げ／配
備を行う
7.1 システムの引
き渡し／設置
を行う
引き渡し／設置済みシ
ステム、最終システム
文書
7.3 打ち上げ用ソ
フトウェアを
構成する
7.4 打ち上げ用支
援システムを
構成する
7.5 要員の配備準
備をする
7.7 打ち上げ前総
点検を完了す
る
8.2 点検と運用向
けコンフィギュ
レーションを行
う
準備報告書、インシデン
ト報告書、問題／故障報
告書
9.1 へ
8.3 運用機能の実
証試験を行う
訓練済み要員
7.6 ミッション運
用計画書及び運
用要領書を更新
する
運用評価結果、
飛行中点検結果
運用データ、進行／停止
（Go/No-Go）基準、
運用準備基準
配備通りのベースライン
−配備・統合化・
検証済みシステム。
−運用の認証と妥当性確認。
システム
セグメント
エレメント
サブシステム
アセンブリ
フェーズＤ：開発段階
進
フェーズＥ：運用段階
生産と開発
運用と支援
- 43 -
展
ミッション運用
・
・
・
廃棄
ミッションを実施する。
システムを維持する。
システムを改良／増設する。
・
システムアイテムのデコミッシ
ョニング／廃棄を行う。
マ
マネ
ネー
ージ
ジメ
メン
ント
ト
決
決定
定
デシステム
コミッショニ
ン受領審査
グ審査
運用
9.1 運用向けのコ
ンフィギュレ
ーションを行
う
9.6 ミッション
の成果を分配
する
9.10
連続生産
9.8 設計と文書を
更新する
連続生産
9.2 ミッション
を実施する
9.9 改良、ブロック
変更
廃棄
ミッションの成果
製品改良要求書、変更書
9.3 要員を訓練
する
9.7 動向を評価
する
訓練済み要員
9.4 システムを
維持する
10.1 デコミッシ
ョニング／廃
棄を行う
廃棄アイテム、
デコミッシ
ョニングアイテム、
リサイ
クルアイテム、廃棄物
問題／故障報告書、準備報告書、
教訓
10.2 貯蔵／監視
する
9.5 システムを
支援する
予備
進
展
フェーズＥ：運用段階
運用と支援
- 44 -
作成者： L. Pleniazek、 Lockheed
Engineering & Sciences 社。
95 年 4 月17 日改訂−Jet Propulsion
Laboratory
3.8
資金調達：
予算サイクル
NASA（米国航空宇宙局）は、連邦議会から年間資金の供与を受けている。しかし、この
資金供与は、予算編成、予算制定、予算実施からなる 3 年サイクルの回転方式で実施され
る。標準的予算サイクルを非常に単純化したものを図 9 に示す。
NASA では、毎年 1 月に予算編成
ｎ財政年度予算のマイルストーン：
1991財政年度予算
①
②
③
④
⑤
⑥
1992財政年度予
n-2
n-2
n-2
n-1
n
n
１月
３-6月
９月
１月
１０月１日
９月３０日
を開始する。それには、大統領府
ＯＭＢの予測と指針
ＰＯＰ／ＩＯＰ（試行）
ＯＭＢ）へ予算案提出
議会へ提出する大統領予算
議会へ提出する大統領予算
ｎ財政年度終了（研究開発と施設
建設は継続）
の行政管理予算局（OMB＝Office of
Management and Budget）から提供
された経済予測書と一般指針書が
利用される。5 月初旬、NASA では
1993財政年度予算
OMB に対する NASA 予算案提出に備
93年度支出
（ド
ル）
え、そのプログラム運用計画（POP
＝Program Operating Plan）と機
ＯＭＢ
1994財政年度予算
議会の審議と
決議
④
関運用計画（IOP＝Institutional
⑤
ＯＭＢ
1995財政年度予算
ＮＡＳＡ
①
94年度支出
（ド
ル）
②
1996財政年度予算
②
暦
1994
ＯＭＢ
1993
95年度支出
（ド
ル）
⑤
ＮＡＳＡ
①
最終予算案は、9 月に OMB に提出さ
議会の審議と
決議
③ ④
Operating Plan）を試行する。NASA
⑥
れ、大統領予算案に盛り込まれる。
議会の審議と
決議
③ ④
その大統領予算案は通常 1 月に議
⑥
⑤
年
会へ提出される。その後、この予
96年度支出
（ド
ル）
1995
算案は議会審議と採決に付され、
⑥
1996
最終的に資金の充当を NASA に認可
する法案とそれらの資金を NASA に
充当する法案が議会規則に従って
図９ 標準ＮＡＳＡ予算サイクル
可決される。通常、議会手続きは
夏の間続く。しかし近年は、最終法案の可決が 10 月 1 日の財政年度開始期日よりも遅れて
いる。そのため、NASA では議会の審議継続中に事業計画を発足させている。
年次予算に関しては、各財政年度開始時に資金供与に対する暗黙のコントロール・ゲー
トが設けられている。これらのゲートではプロジェクトに対していくつかの計画要求を課
すが、それは正規のシステムエンジニアリング・プロセスには導入されない。むしろ、プ
ロジェクトのリスクに関連する不確定要因の一つとみなされるが、プロジェクトの企画段
階において検討すべきものである。
- 45 -
4.
システムエンジニアリングのマネジメント問題
本章では、前章で述べたプロジェクト・ライフサイクルに採用されるシステムエンジニ
アリングの各種成果と各種方法についてさらに詳細に説明する。こうした成果と方法は、
プロジェクト・マネジメントに対してシステムエンジニアが寄与するもので、1 連の複雑な
作業に対する組織的管理方法を助成するようになっている。
4.1
目標、作業結果、組織の調和
連続改良主義を何らかのシステムに適用すると、それは「分割征服」戦略となる。複雑
なシステムを複雑度のより低い部品に次々と分割すると、征服しやすい非常に簡単なもの
になる。この分割化を行うと、「製品システム」と「生産システム」（「システムを生産す
るシステム」）を示すいくつかの構成が得られる。これらの構成は、システムエンジニアリ
ングとプロジェクト・マネジメントにおいて重要な役割を果たす。本章の多くの項では、
このような主要構成のいくつかについて説明する。
製品システムを示す構成としては、要求事項樹形図、システムアーキテクチャー、さら
にシステム図、図表、データベースのような特定の記号情報などがある。生産システムを
示す構成としては、プロジェクトの作業明細、スケジュール、コスト計算、組織などがあ
る。これらの構成は、希望の製品システムという共通の目標（レーゾンデートル）に対し
てそれぞれ異なった視点を提供する。これらの構成の間に基本的調和を生み出すことは、
システムエンジニアリングとプロジェクト・マネジメントを成功させる鍵となる。2 つの構
成の間での 1 対 1 の対応関係によって調和を確立する必要がある場合もあれば、いくつか
の構成を結ぶリンクによって調和を確立する必要がある場合もある。ここでは、このよう
な基本原則について若干説明する必要があろう。
システムエンジニアリング・プロセスにおいて、システム要求書を使用する目的は 2 つ
ある。まず第一に、要求書は、製品開発チーム（PDT＝Product Development Team）が理解
できるように、買い手が希望する製品システムを階層的に記述することである。買い手と
システムエンジニアが協力してこうした要求書を作成するのも、「買い手の声」を聞く一つ
の方法である。適正な要求
もの
−
−
つまり、情報に通じた買い手が進んで金を払おうとする
の判定は、システムエンジニアの仕事の重要な一部である。第二に、システム
要求書は、設計かつ構築（またはコード化）すべきものを設計技術者に伝えることでもあ
る。これらの要求書にある各種要求がシステムに割り当てられると、それらは、システム、
セグメント、エレメント、サブシステムなどの階層からなるシステムアーキテクチャーや
製品明細構成と緊密にリンクしたものになる。（原文 3 頁の枠内補足記事「階層的システム
用語」を参照）。
作業明細構成（WBS＝Work Breakdown Structure）も、プロジェクトの完了に必要な作業
- 46 -
区分からなる樹形図型の構成である。WBS の各業務は、1 つまたは 2 つ以上のシステム要求
事項に起因したものでなければならない。いくつかのネットワークに構成されたスケジュ
ールは、WBS において製品システムを生み出す時間区分の作業を示すものである。コスト計
算構成は、WBS の作業とその作業を実施するためのスケジュールに直接関連づける必要があ
る。（第 4.3 項−第 4.5 項を参照）。
プロジェクトの組織構成は、作業を実施するために任命された数組の要員を示すもので
ある。この組織構成は通常、樹形図型のものであり、2 つの樹形図が組み合わされたマトリ
ックスとして表わされることもある。この場合、一方の樹形図はラインの責任体制を示し、
もう一方はプロジェクトの責任体制を示す。いかなる場合にも、組織構成は各 WBS 業務の
責任の所在を特定できるものとすべきである。
特定の WBS 業務から得られるものは、プロジェクト文書である。プロジェクト文書には、
基本的にベースライン文書と保管文書という 2 つの種類がある。それぞれの文書には、製
品システムと生産システムに関する情報が記載される。確立されたベースライン文書には、
さまざまの意思決定から得られた製品システムと生産システムの現状を示す情報が記載さ
れる。通常、この文書は階層的樹形構成図の集まりとして構成され、かなりの量の相互参
照リンクを示すものとなる。保管文書には、その他のプロジェクト情報で、たとえ一時的
にせよ記憶する価値のあるものすべてが記載される。保管文書に記載すべき情報は、過去、
現在、将来の意思決定に関係のあるすべての想定事項、データ、裏付け分析である。保管
文書の構成（およびコントロール）がベースライン文書に比べはるかにルーズになるのは
避けがたいが、相互参照はできるかぎり維持すべきである。（第 4.7 項を参照）。
審査（およびその関連コントロール・ゲート）の構成は、製品明細構成から製品システ
ムを実現するために必要な時間区分の作業を反映させたものである。状態報告・評価構成
は、それらの同一時間区分における作業の進捗状態に関する情報を提供する。状態報告・
評価構成の財務側は、WBS（Work Breakdown Structure＝作業明細構成）、スケジュール、
コスト計算と直接リンクさせる必要がある。その技術業務側は、製品明細構成や要求樹形
図とリンクさせる必要がある。（第 4.8 項と第 4.9 項を参照）。
4.2
システムエンジニアリング・プロセスのマネジメント：
システムエンジニアリング・マネジメント計画
システムエンジニアリング・マネジメントは、システムエンジニアリングとその他すべ
ての技術業務を正しく実施するための一つの技術業務、技術分野である。
各プロジェクトのマネジメントは、そのプロジェクトのリスクに応じて慎重に調整した
プロジェクト・ライフサイクルに従って実施すべきである。プロジェクトマネジャはプロ
ジェクト・ライフサイクル全体のマネジメントに専念するが、プロジェクト・レベルや主
任のシステムエンジニアはそのプロジェクトの技術面のマネジメントに専念する。（図 7 ま
- 47 -
たは図 8 を参照）。そのため、システムエンジニアは、適切に共同エンジニアリングを編成
かつ導入しながら、システムの分解、定義、統合、検証、妥当性確認という幾重もの必要
業務を実施する必要がある。このようなシステムエンジニアリングの各業務には、技術分
析の技能と技法が必要になる。
システムエンジニアリング・マネジメントに採用する技法としては、作業明細構成、ネ
ットワーク・スケジュール、リスク・マネジメント、要求トレーサビリティ、要求審査、
ベースライン、コンフィギュレーション・マネジメント、データ・マネジメント、専門工
学プログラム計画、定義審査、準備審査、監査、設計確認、状態報告、状態評価などがあ
る。
プロジェクト計画書（Project Plan）は、所定の制約の下でプロジェクトの目標と目的
を達成するにはプロジェクトマネジメントをどう行うかという点を明確に定めた文書であ
る 。 シ ス テ ム エ ン ジ ニ ア リ ン グ ・ マ ネ ジ メ ン ト 計 画 書 （ SEMP ＝ Systems Engineering
Management Plan)は、プロジェクト計画書により設定された制約の下でプロジェクトを技
術的にどうマネジメントするかという点を、すべてのプロジェクト参画者向けに明確に定
めた付属文書である。SEMP では、予定のマネジメント作業にどう対応するかという点をす
べての参画者に伝える。たとえば、SEMP には、内部と外部（プロジェクトに対して）の両
インターフェースコントロール方法についても記載すべきである。SEMP では、また、上に
挙げたシステムエンジニアリング・マネジメント技法をどのように適用するかという点も
伝える。
4.2.1
SEMP の役割
SEMP（Systems Engineering Management Plan ＝システムエンジニアリング・マネジメ
ント計画書）は、プロジェクトを技術的にどう管理するかという点をすべての参画者向け
に説明したルールブック（規則書）である。NASA フィールドセンターでも、技術マネジメ
ントをどう実施するかという点を SEMP に記載すべきである。また、各契約者も、その契約
と NASA の技術マネジメント慣行に従ってどう管理するかという点を SEMP に記載すべきで
ある。SEMP はプロジェクト特有かつ契約特有のものであるので、計画上重大な変更がある
たびに更新しなければならない。さもなければ、SEMP 自体が時代遅れのものとなり使用で
きなくなり、プロジェクトも無管理状態に陥る恐れもある。NASA フィールドセンターでは、
初めてコスト予測書を作成する際には、技術リスク削減化など、コストのかかる諸作業を
事前に特定かつ説明する必要があるので、まず SEMP を作成すべきである。契約者も、（費
用と価格の決定前の）見積書作成段階に SEMP を作成すべきである。その SEMP には、プロ
ジェクトの技術的内容、費用のかかりそうなリスクマネジメント業務、採用すべき検証・
妥当性確認技法について説明し、それらすべてをプロジェクトのコスト予測書に盛り込ま
なければならない。
- 48 -
プロジェクトの SEMP は、そのプロジェクトの上級技術マネジメント文書である。つまり、
インターフェース管理計画書（Interface Control Plan）、変更管理計画書（Change Control
Plan)、製造・購入管理計画書（Make-or-Buy Control Plan）、設計審査計画書（Design Review
Plan）、技術監査計画書（Technical Audit Plan）といったその他すべての技術管理文書は
SEMP に左右されるので、SEMP に準拠したものでなければならない。したがって、SEMP は総
合的技術作業をどう管理し、どう実施するかという点を説明した包括的なものとすべきで
ある。
4.2.2
SEMP の内容
SEMP（Systems Engineering Management Plan)は、プロジェクトの種類、プロジェクト・
ライフサイクルでのフェーズ（段階）、技術開発リスクなどにより決定されるプロジェクト
の技術管理方式について説明したものである。そのため、SEMP は、各プロジェクトのこう
した状況や問題点に対処できるように書かなければならない。SEMP では特定の内容をプロ
ジェクトに合わせて調整するが、SEMP の推奨内容は以下に列記するとおりである。
第1部
−
プロジェクトの技術計画と技術管理（コントロール）
この第 1 部では、外注エンジニアリングの管理も含めたシステムエンジニアリング・マ
ネジメントの責任体制と権限、性能・設計要求事項に対する各種管理（コントロール）レ
ベル、使用する管理（コントロール）方法、技術的進捗保証方法、プログラム／プロジェ
クトの設計審査と技術審査の計画とスケジュール、文書管理（コントロール）などを特定
すべきである。
第 1 部には以下の事項について説明すべきである。
・
プロジェクト担当当局の役割
・
ユーザーの役割
・
契約担当局技術代表（COTR＝Contracting Office Technical Representative)の役
割
・
システムエンジニアリングの役割
・
設計工学の役割
・
専門工学の役割
・
適用される規格と基準
・
適用手続きとトレーニング
・
ベースライン管理（コントロール）方式
・
変更管理（コントロール）方式
・
インターフェース管理（コントロール）方式
・
外注（または下請け）エンジニアリングの管理（コントロール）
- 49 -
・
データ管理（コントロール）方式
・
製造・購入管理（コントロール）方式
・
部品・材料・プロセスの管理（コントロール）
・
品質管理（QC＝Quality Control)
・
安全管理（コントロール）
・
コンタミネーション管理（コントロール）
・ 電磁干渉と電磁適合性（EMI／EMC＝Electromagnetic Interference/Electromagnetic
Compatibility）
・
技術性能測定プロセス
・
コントロール・ゲート
・
内部技術審査
・
インテグレーション管理（コントロール）
・
検証管理（コントロール）
・
妥当性確認管理（コントロール）
第2部
−
システムエンジニアリング・プロセス
この第 2 部には、システムとプロジェクトの要求事項に合わせたシステムエンジニアリ
ング・プロセスの特定調整、システムエンジニアリング・プロセスの実施手続き、局内文
書作成、トレード研究方法、システムのコスト効果評価に採用する数学的・シミュレーシ
ョンモデルの種類、仕様書の作成など、採用するシステムエンジニアリング・プロセスに
関する詳細な説明を記載すべきである。
第 2 部には以下の事項について説明すべきである。
・
システム分解プロセス
・
システム分解フォーマット
・
システム定義プロセス
・
システム解析・設計プロセス
・
要求事項配分プロセス
・
トレード研究プロセス
・
システム統合化プロセス
・
システム検証プロセス
・
システム認定プロセス
・
システム受領プロセス
・
システム妥当性確認プロセス
・
リスク・マネジメントプロセス
・
ライフサイクルコスト・マネジメントプロセス
・
仕様書と図面の構成
- 50 -
・
コンフィギュレーション・マネジメントプロセス
・
データ・マネジメントプロセス
・
数学的モデルの採用
・
シミュレーションの採用
・
使用ツール
第3部
−
専門エンジニアリングの統合化
SEMP の第 3 部では、繰り返される各システムエンジニアリング・プロセスに対する専門
工学分野の作業の統合化と調整について説明すべきである。専門作業間でオーバーラップ
する可能性がある場合は、SEMP において各作業の責任と権限を明確にすべきである。
第 3 部には、必要に応じて以下の事項に対するプロジェクトの取り組み方を記載すべき
である。
・
コンカレントエンジニアリング
・
専門分野の作業段階化作業
・
専門分野の参画
・
専門分野の関与
・
専門分野の役割と責任
・
システム分割・定義プロセスに対する専門分野の参加
・
検証・妥当性確認プロセスにおける専門分野の役割
・
信頼性
・
保全性、
・
品質保証
・
総合ロジスティックス
・
人間工学
・
安全性
・
生産性
・
生存性／無防備性
・
環境評価
・
打ち上げ承認
4.2.3
SEMP の作成
SEMP（Systems Engineering Management Plan ＝システムエンジニアリング・マネジメ
ント計画書）は、プロジェクト計画書（Project Plan）と同時に作成しなければならない。
SEMP の作成時には、プロジェクトの技術的取り組み方、ひいてはプロジェクト・ライフサ
イクルの技術面が設定される。これが、プロジェクトの期間とコストを最終的に決定する
- 51 -
プロジェクトの屋台骨となる。計画と技術の管理方式を設定するには、プロジェクトの主
要スタッフが実施作業とその各種作業部分間の関係を理解しなければならない。（第 4.3
項「作業明細構成」と第 4.4 項「ネットワーク・スケジュール」を参照）。
SEMP の作成では、プロジェクトの結果に大きな影響を与えることができるプロジェクト
のあらゆる分野から集められた計画専門家と技術専門家の支援も必要である。プロジェク
トマネジャが頼れるような SEMP を作成し、プロジェクトチームを作業に専念させるために
は、しっかりした専門家を参加させる必要がある。
4.2.4
システムエンジニアリング・プロセスのマネジメント：
概要
プロジェクト・ライフサイクルの技術面を通してプロジェクトを管理する責任は、シス
テムエンジニアリング担当組織、特にプロジェクト・レベルのシステムエンジニアにある。
その責務としては、分解・定義シーケンスのマネジメント、統合化・検証・妥当性確認シ
ーケンスのマネジメントがある。このマネジメントには、プロジェクトの技術ベースライ
ン管理（コントロール）も付随する。通例、こうした技術ベースラインは、「機能」、
"design-to" 、 build-to"( ま た は "code-to") 、 "as-built" （ ま た は "as-coded" ）、
"as-deployed" ベースラインである。システムエンジニアリングは、これらのベースライ
ンを通して効率的かつ論理的に進めなければならない。
システムエンジニアリングは、まずあらゆる低レベル・コンフィギュレーションアイテ
ムの"design-to" 仕様書が完成するまでにシステムの分解と設計を行う。次に、設計工学
が、承認済み"design-to" ベースラインに準拠する"build-to"文書と"code-to" 文書の作
成を行う。システムエンジニアリングでは、設計・コード化プロセスと設計工学による解
決策がすべての高レベル・ベースラインに適合するかどうかを監査する。この責務を実施
する場合、システムエンジニアリングでは要求事項のトレーサビリティを保証し、文書化
しなければならない。
国防総省の経験から得た SEMP の教訓
・
プロジェクト・マネジメントを成功させるには、プロジェクト・サイクル全体を通
して使用されるシステムエンジニアリング・マネジメント計画書（SEMP＝Systems
Engineering Management Plan）を調整する必要がある。
・
SEMP は、プロジェクトが変更されるたびに更新され、常にプロジェクト計画書に適
合している生きた文書である。
・
有意義な SEMP を作成するには、プロジェクトのあらゆる分野から集めた専門家がそ
れを作成しなければならない。
・
システムエンジニアリングの導入が少ないか不十分なプロジェクトは、通常、大き
な問題を抱える。
- 52 -
・
システムエンジニアリング面が弱いとか、組織への導入が遅すぎると、必要な業務
を実施できない。
・
システムエンジニアリング作業は、適切な管理がなされ、すべてのプロジェクト参
画者に正確に伝えなければならない。
・
システムエンジニアリング作業は、顧客と契約者の利益に沿ったものでなければな
らない。
システムエンジニアリングは、統合化・検証・妥当性確認プロセスの総合的マネジメン
トも実施する。この役割として、システムエンジニアリングでは準備審査を実施し、検証
済みコンフィギュレーションアイテムだけを次の高位レベルのアセンブリに統合し、さら
に検証を行う。検証はシステムレベルまで続けられ、その後はユーザー要求書に適合する
かどうかを実証するためにシステムの検証が実施される。
システムエンジニアリングでは、必要な専門工学分野をも導入してプロジェクト・ライ
フサイクル全体にコンカレントエンジニアリングを正確に適用する。こうした作業では、
SEMP が手引書となる。
4.3
作業明細構成
作業明細構成（WBS＝Work Breakdown Structure）とは、プロジェクトの完了に必要な作
業を階層的に区分したものである。WBS は、引き渡し可能アイテムとその関連業務（サービ
ス）を製品別に階層的に区分したものとすべきである。したがって、WBS はプロジェクトの
製品明細構成（PBS＝Product Breakdown Structure)を含むものとし、特定主要製品をトッ
プレベルに、システム、セグメント、サブシステムなどを低いレベルに順次示すべきであ
る。最低レベルにはハードウェアアイテム、ソフトウェアアイテム、情報関係アイテム（文
書、データベースなど）を示し、それらを確認できる技術者やマネジャを配する。この階
層の分岐点は、PBS の各種要素をどう統合化するかを示すものとする。WBS は PBS から構築
し、PBS の各分岐点においてマネジメント、システムエンジニアリング、統合化と検証（I
＆ V ＝ Integration and Verification ）、総合ロジスティックス支援（ILS＝Integrated
Logistics Support）などの必要業務事項を加える。いくつかの WBS 要素が同じような機器
やソフトウェアを必要とする場合は、一括購入か開発作業を実施するために高レベルの WBS
要素を（たとえば「システム支援設備」（System Support Equipment））設定することもで
きる。図 10 には、システム、PBS、WBS の関係を示す。
プロジェクトの WBS は、リスク・マネジメントに適したコスト計算レベルまで含めたも
のとすべきである。コスト計算に適する詳細度レベルは、計画・報告コストに釣り合うコ
ストを知りたいというマネジメント側の願望により決定される。契約者も、コスト管理の
必要性に見合った契約 WBS（CWBS＝Contract Work Breakdown Structure）を作成すること
がある。通常は、契約組織にコストについて報告するために、完全 CWBS の高位レベルのみ
- 53 -
からなる概要 CWBS がプロジェクト WBS に組み込まれる。
WBS 要素は、そのタイトルと以下の役割を果たす番号づけ方式により識別される。
・
WBS 要素のレベルを識別する
・
WBS 要素が統合化される高位レベルの要素を識別する
・
その要素のコスト計算番号を示す
- 54 -
部分の集まりよりも統一体の方
が「より役に立つ」
システム
「接着剤」で
サブシステムＡ
（統合化で）
つなぎ合わせ
サブ
サブシステム た各種構成要
シス
Ｃ
素（サブシス
テム
Ｂ サブシステムＤ テム）
WBS は WBS ディクショナリも併用するべきで
ある。このディクショナリは、各要素のタ
イトル、識別番号、目的、説明、他の WBS
要素に依存するもの（たとえば他の WBS 要
素から受け取れるもの）などを記載したも
のである。また、プロジェクト番号やその
製品明細構成（PBS）
システムの構成要素を示す
他関係当事者を探索するのに役立つプロジ
ェクト構成説明図をも示す。
システム
この項では、WBS 作成のための技法例をい
くつか提示すると共に、回避すべきいくつ
かの誤りも指摘する。添付資料 B.2 では、
システムの
各構成要素
製品別 WBS 作成の原則に従った搭載用望遠
作業明細構成（WBS）
完全なシステムを生産する
ために必要なすべての作業
構成要素
鏡の WBS 例を示す。
システム
マネジ システム I＆V
メント エンジニ
アリング
ILS
システムの各構成
構成要素をシステムに統合化す
要素を生産するた
るための作業
めの作業
部分の集まりよりも統一体の方が
「多くの作業を必要とする」
図10 システム、製品明細構成、作業明細構成
との関係
- 55 -
4.3.1
WBS の役割
製品別 WBS（Work Breakdown Structure＝作業明細構成）は、以下の作業を組織的に構成
したものである。
・
プロジェクトとその技術面の計画とスケジュール作成
・ コスト予測と予算編成。（特に、製品別 WBS から収集したコストは、過去のデータと
比較できる。国防総省の WBS 規格では、これが主目的と特定されている）
・
契約作業に関する作業報告書と仕様書の範囲設定
・
スケジュール、コスト、労働力、技術性能、コスト／スケジュール総合データ（完
成時の「収益」と予測コストなど）を記載したプロジェクト状況報告書作成
・
SEMP（Systems Engineering Management Plan)などの計画書の作成と、仕様書や図
面などのその他文書の作成
製品別 WBS は、プロジェクト全体を説明する論理的概要と用語を示すと共に、いろいろ
な情報を一貫性のあるものに統合化する。WBS の 1 つの要素にスケジュールのずれがあると、
他のどの WBS 要素が最も影響を受けやすいかを知ることもできる。コストの影響はより正
確に予測できる。WBS の 1 つの要素に設計変更があれば、他のどの WBS 要素が最も影響を受
けやすいかを知ることもでき、潜在的悪影響を知るためにこうした要素を調べることもで
きる。
4.3.2
WBS の作成技法例
プロジェクトの WBS（Work Breakdown Structure＝作業明細構成）をうまく作成するには、
プロジェクト・ライフサイクルを数回くり返す必要がある。それは、作業の全範囲がどの
程度になるかが最初からはっきりしないからである。予備 WBS を作成する前には、予備 PBS
（Product Breakdown Structure ＝製品明細構成）を作成できる時点までにシステムアー
キテクチャーをある程度開発する必要がある。
それによって、PBS とその関連 WBS をトップダウン方式により 1 レベルずつ作成できる。
この方法では、プロジェクト・レベルのシステムエンジニアがプロジェクト・レベルで最
終 PBS を作成し、次の低位レベルの PBS 案を提示する。その後、マネジメントやシステム
エンジニアリングなどの適当な業務をその低レベルに加えて WBS を作成する。この手順を
何度もくり返すと、WBS は希望のコスト計算レベルまで達する。
もう一つの代替技法は、まず 1 回の設計作業において完全な PBS の全レベルを定義し、
次に完全な WBS を作成するという方法である。この方法を採用する時は、全製品が組み込
まれ、すべての組み立て／統合化および検証の分岐が正しくなるように、PBS の作成時に細
心の注意を払う必要がある。この場合は、低レベルの WBS 要素を担当する人々の参加を推
- 56 -
奨する。
分割引き渡しプロジェクトの WBS
迅速開発、迅速原型製作、漸進的引き渡しのような分割引き渡しを行うプロジェクトも
いくつかある。そうしたプロジェクトに関しては、個別に WBS を作成すべきであるが、WBS
階層における最終主要製品のすぐ下に、各引き渡しを識別するレベルが 1 つ付加される。
いかなる時点でも、WBS には活動要素と非活動要素が含まれる。
運用施設の WBS
フライトオペレーションセンターのような運用施設を管理するための WBS は、システム
開発のための WBS とほとんど変わりがない。相違点は、PBS にある全製品が一挙に完成され、
統合化されるのではなく、定期的に生産されるという点である。運用施設の PBS は、大部
分が外部顧客に提供する情報製品やサービス製品からなる。それでも、製品やサービスの
階層的明細という一般的概念は適用されるであろう。
開発用 WBS に適用される規則は、運用施設の WBS にも適用される。運用施設の WBS を作
成する技法も同じである。だが、保全やユーザー支援などのサービスは PBS に加えられる
が、システムエンジニアリング、統合化、検証などのサービスは不要になることもある。
エラー 1
製品なしの業務
このWBS は業務のみを示し、製品を示して
いない
適切な分岐
エラー 2 このWBS には、WBS 要素の統合化方法
に適合しない分岐点がある
分散型情報
システム
プロジェクト
マネジメント
エンジニアリング
製 造。
検証
ソフトウェア
ハードウェア
エラー3： PBS との不適合
PB このWBS は製品明細構成（PBS）と適合していない
サブシステム
サブシステム
送信機
送信機
TWT増幅器
TWT増幅器
作業明細構成
製品明細構成
図11 WBS 作成時のエラーの例
- 57 -
4.3.3
WBS 作成時の共通エラー
WBS（Work Breakdown Structure＝作業明細構成）に通常認められる共通の誤り（エラー）
は 3 つある。
・
エラー1：
WBS が業務のみを示し、製品を示していない。そのため、プロジェクト
マネジャだけが製品に対して正式に責任を負うことになる。
・
エラー2：
WBS の分岐点が、WBS 要素の統合化方法に適合していない。たとえば、
分散型アーキテクチャからなるフライトオペレーション・システムでは、通常、ハ
ードウェアアイテムと関連したソフトウェアがあり、それらは WBS の低レベルで統
合化と検証が行われる。システムレベルで統合化すべき個別システムであるかのよ
うに、ハードウェアとソフトウェアを分離するのはよくない。そうすると、統合化
責任を割り当てにくくなり、システム構成要素の統合化と試験にかかるコストも特
定しにくくなる。
・
エラー3：
WBS が PBS に適合していない。そのため、PBS を完全に採用できなくな
る恐れがあり、マネジメント・プロセスを複雑化する。
このようなエラー例を図 11 に示す。どのエラーが生じても、プロジェクトの計画と組織
化において WBS はその役割をうまく果たせなくなる。前で説明した WBS 作成技法を採用す
れば、こうしたエラーを回避できる。
4.4
スケジュール
WBS（Work Breakdown Structure＝作業明細構成）に示す製品は、完成までに時間のかか
る諸作業の結果によるものである。整然とした効率的なシステムエンジニアリング・プロ
セスを実施するには、こうした作業間の基本的な時間・順位関係を尊重するような方法で
これらの作業を実施する必要がある。それには、「ネットワーク・スケジュール」というも
のを作成する必要がある。これは、各作業が他の作業や外部に依存していること
（dependency）を考慮に入れたスケジュールである。本項では、スケジュールの役割と完
全なネットワーク・スケジュールの作成技法について検討する。
4.4.1
スケジュールの役割
スケジュールは、プロジェクト作業の計画と管理に欠かせない要素である。ネットワー
ク・スケジュールを作成すれば、何を実施する必要があるか、その実施にはどれくらいの
時間がかかるか、プロジェクト WBS の各要素がどのように他の要素に影響を与えるかとい
う点をよりよく理解できるようになる。完全なネットワーク・スケジュールを使用すれば、
プロジェクト完了までにかかる時間、その時間を決定する作業（つまり、クリティカルパ
- 58 -
ス作業）、プロジェクトにける他のすべての作業のために残された時間（つまりフロート）
を算定できる。（枠内記事「クリティカルパスとフロート算定」を参照）。プロジェクトの
予算編成を正確に行うには、プロジェクトのスケジュールを理解することが前提条件にな
る。
スケジュールの進行記録を取ることは、プロジェクト・コントロールに欠かせない要素
である。というのは、コスト問題や技術問題が最初にスケジュール問題として表面化する
場合が多いからである。ネットワーク・スケジュールは、各作業が他の作業にどんな影響
を与えるかを示すものなので、プロジェクト全体における一つの作業のスケジュールのず
れや迅速化の影響を予測する場合には欠かせないものである。ネットワーク・スケジュー
ル方式は、マネジャがプロジェクトのコストやスケジュールに対する技術と経営資源両方
の変更の影響を正しく評価する場合にも役に立つ。
4.4.2
ネットワーク・スケジュールのデータとグラフィックフォーマット
ネットワーク・スケジュールのデータは次のものからなる。
・
各種作業
・
各種作業間の依存関係（たとえば、受け取れるものがあるために、何らかの作業が
別の作業に左右される場合）
・
1 つまたは 2 つ以上の作業の結果として得られる製品またはマイルストーン、
・
各作業の所要時間
上に列記した最初の 3 つのデータ項目をグラフ表示したものがフローチャート（Work
Flow Diagram ＝WFD）である。ネットワーク・スケジュールには 4 つのデータ項目すべて
が含まれる。ネットワーク・スケジュールを作成する場合は、このデータのグラフィック
フォーマットが非常に役に立つ。図 12 に示す 2 種のグラフィックフォーマットが一般的に
使用されている。一つは「作業矢印」（activities-on-arrows）図というもので、矢印の初
めと終りに製品と依存関係が示される。これはプログラム評価・審査手法（PERT＝Program
Evaluation and Review Technique)図の標準的フォーマットである。もう一つは「順位図」
（Precedence diagram）と呼ばれるもので、枠内に各作業を示し、依存関係を矢印で示す。
見やすいフォーマットであり、コンピュータ・リソースに対する要求条件が少ないため、
近年は順位図の方が普及している。
順位図のフォーマットでは、次のような論理関係を簡単に示すことができる。
・
作業 A が開始すると、作業 B も開始する（Start-Start または SS）
・
作業 A が終了した後しか作業 B は開始しない（Finish-Start または FS）
・
作業 A が終了すると、作業 B も終了する（Finish-Finish または FF）
こうした各作業関係に「遅延」（＋または−）を付加すれば、図 12 に示すような関係に
変更することもできる
- 59 -
順位図にある多数の低レベル作業を一つの作業にまとめることも可能である。この手法
は通常「ハンモッキング」（Hammocking）と呼ばれている。最初の低レベル作業を選定し、
次に上に述べた最初の関係を使用してそれに一括(summary)作業を付加する。その後、上に
述べた 3 番目の関係を使用して、最終低レベル作業にその一括（summary）作業を付加する。
ハンモッキング手法を採用しない限り、順位図で最も採用される関係は上に述べた 2 番目
の関係である。「作業矢印図」のフォーマットでは、必要に応じて人為的に事象と作業を創
出することにより、同一の時間・順位論理を順位図として表わすこともできる。
作業矢印図
作業Aは「意識的に」
2つの個別作業に分割
されている
Ａ２
Ａ１
５
５
Ｂ１
５
Ｂ２
５
作業の説明
作業の所要時間
（たとえば日数）
順位図
作業の説明
Ａ
作業の所要時間
（たとえば日数）
10
ＳＳ５
Ｂ
注記：
各作業の説明に
は、
作業内容とそ
の目的を記入す
る必要がある
これは、
作業Aの開始5 10
日後に作業 B を開始で
きることを意味する
図12 ネットワークスケジュールに使用する作業矢
印図と順位図
クリティカルパスとフロート算定
「クリティカルパス」（critical path ＝臨界経路）とは、完了するまでに最も時間のか
かる一連の作業のことである。クリティカルパス上にない作業は、クリティカルパス上に
乗せるまでの時間をある程度遅らせることができる。この遅延時間を「フロート」（float)
という。フロートにはパスフロート（path float）とフリーフロート（free float）の 2
種類がある。パスフロートは、一連の作業全体がフロートをもっている場合である。この
一連の作業の一つに遅れが生じると、その後の全作業のパスフロートはその遅れ分だけ減
少する。何らかの作業の遅れが他のいかなる作業にも影響を与えない場合は、フリーフロ
ートとなる。たとえば、作業 A を 2 日後に終了でき、しかも作業 B の所要日数が 5 日で、
作業 A と B の完了後に作業 C が開始される場合、作業 A のフリーフロートは 3 日となる。
フロートは貴重なものである。パスフロートは、将来の作業のためにできるだけ保存す
べきである。フリーフロートの場合は、そうした保存はそれほど重要ではない。
クリティカルパスを算定する場合には、まず各作業の最も早い開始時点を算定する「フ
ォーワードパス」（forward pass）がある。最終作業を終了できる時点は、そのスケジュー
- 60 -
ルの終了時点となる。最終作業が算定ずみの最も遅い時点で終了すると仮定すれば、各作
業の最も遅い開始時点を算定する「バックワードパス」（backward pass)というものがある。
一つの作業の最も早い開始時点と最も遅い開始時点の時間差がフロートである。フロート
がゼロの場合、その作業は常にクリティカルパス上にある。
4.4.3
ネットワーク・スケジュールの作成
プロジェクトレベルのスケジュールでは、WBS（Work Breakdown Structure＝作業明細構
成）図の上位レベルに示された製品の引き渡し目的からスケジュールが始まる。プロジェ
クトの目的に合ったネットワーク・スケジュールを作成する場合は、WBS で使用できる最低
レベルの各コスト計算に対して以下の 6 段階（ステップ）の手順が適用される。
ステップ 1：
WBS の各要素を完成するのに必要となる作業と依存関係を特定する。作業と
他の WBS 要素間の依存関係をスケジュール上に正確に示せるように、十分な件数の作業を
特定すべきである。年に 10 仕事年を要する WBS 要素の初年度には、約 100 件の作業を特定
するのも珍しくない。通例は、現年度ほどスケジュールの詳細度は高くなり、その後続年
度ほど詳細度が低くなる。毎年、現年度のスケジュールは詳細事項が追加されて更新され
る。この第 1 ステップは、以下のことを行うことにより極めて容易に実施できるようにな
る。
・
各種文書、報告書、ハードウェアアイテム、ソフトウェアアイテムも含め、すべて
の重要製品を示すように、コスト計算の WBS を低レベルまで拡張する
・
各製品ごとに、その生成に必要な手順段階のリストを作成し、そのプロセスをフロ
ーチャートに示す
・
製品間の依存関係を示し、作業パッケージ内の統合化段階と検証段階を示す
ステップ 2：
外部依存事項を特定し、交渉により決める。外部依存事項とは、コスト計算
項目外から受け取れるものと、コスト計算項目外へ引き渡せるものである。コスト計算範
囲の境界を越えて移動する製品の内容、フォーマット、ラベルに関して合意が得られるよ
うに、非公式の交渉を行うべきである。このステップは、低レベルのスケジュールを導入
できるように設けられたものである。
ステップ 3： すべての作業の所要時間を予測する。この予測に採用する想定条件（労働力、
施設の稼働率など）は、将来参考にするために記録しておくべきである。
ステップ 4： 各 WBS 要素のスケジュールデータを適切なコンピュータプログラムに記入し、
- 61 -
その要素のネットワーク・スケジュールとクリティカルパス予測を得る。（この種の業務用
として、多くのソフトウェアパッケージが市販されている）。このステップでは、審査権限
のある技術者、チームリーダー、システムエンジニアがスケジュール論理を審査できる。
満足すべきスケジュールを得るには、この時点でステップ 1 から 4 をくり返す必要がある
が、それは決して特別のことではない。この WBS 要素に関するスケジュール規約を守るた
めに、クリティカルパス上の作業に予備作業を加えることも多く、しかもダミー作業の形
で加えることも多い。
ステップ 5： 適切なソフトウェアを使って、低レベル WBS 要素のスケジュールを統合化す
る。そうすることによって、WBS 要素間のすべての依存関係がプロジェクト・ネットワーク
内に正しく導入される。この時点までに、休日、週末などの影響を導入することも重要で
ある。プロジェクトのクリティカルパスは、このステップで明らかになる。
ステップ 6： 経時的な労働力レベルと資金調達プロファイルを審査し、それらが妥当なも
のになるように論理と所要時間への一連の最終調整を行う。プロジェクト・レベルで設定
したスケジュール目標（ターゲット）に照準を合わせるためには、論理と作業の所要時間
に合わせた調整が必要になる場合もある。この調整方法としては、何らかの WBS 要素にさ
らに多くの作業を加える、余分の作業を削除する、クリティカルパス上にある何らかの作
業の労働力を増強する、連続作業よりも並行作業を増やす方法を案出するなどがある。場
合によっては、プロジェクト・レベルのターゲットを調整したり、プロジェクト範囲を審
査したりする必要もある。このステップでも、リスク軽減化戦略の一環としてスケジュー
ルの余裕やフロートをある程度残しておくのが良い。
これらの最終（last）ステップから得られるのは、各 WBS 要素がその他すべての WBS 要
素と一貫性を持つことが実現可能なベースライン・スケジュールであり、各要素のスケジ
ュールすべてを統合化したものは、プロジェクトの技術範囲やスケジュール目標とも適合
する。スケジュールとその関連コストのリスクを、プロジェクトにもプロジェクトの顧客
にも受け入れられるようにするには、この統合化ずみのマスタースケジュールに十分なフ
ロートを設けておく必要がある。たとえそれが行われていても、多くの WBS 要素の推定時
間が過小評価されるとか、受け取るべきものの到着遅れにより何らかの WBS 要素に関する
作業が当初の予定時期に開始されないということも起こる。その結果、ほとんどの場合は
プロジェクト目標に合わせるために再計画が必要になる。
4.4.4
報告技法
スケジュールに関する概要データは、通常ガントチャート（Gantt chart)に示される。
ガントチャートの一例を図 13 に示す。（枠内補足記事「ガントチャートの特長」を参照）。
- 62 -
もう 1 種類の出力フォーマットとしては、主要作業のフロートと、そのフロートに対する
最近の変化を示す表がある。たとえば、クリティカルパス作業により消費されたスケジュ
ールの余裕がどれくらいあるか、最終報告期間中にスケジュールの余裕が消費されている
か保存されているかといった点をプロジェクトマネジャが正確に知りたい場合もある。こ
の表では、スケジュールの余裕の変動率に関する情報を提示する。
4.4.5
経営資源レベル
優れたスケジュール作成システムは、経時的な経営資源要求事項を示す機能や、経時的
な経営資源制約の下でスケジュールを実行可能にするような調整を加える機能を備えてい
る。経営資源としては、労働力レベル、資金調達プロファイル、重要施設などがある。図
14 では不均一な経営資源プロファイル例を示す。その目的は、フロートのある業務の開始
期日を経営資源プロファイル上の実行可能な時点まで移動させることである。フロートが
十分でなければ、経営資源集約作業の予定所要時間を再検討し、経営資源レベルを変更す
る必要がある。
ガントチャートの特長
図 13（下図）のガントチャートは、次のような特長を示している。
・
WBS 要素、責任マネジャ、ベースライン使用期日、状態報告期日を示す見出し部
・
チャート主要部のマイルストーン項目（第 1 行と第 2 行）
・
チャート主要部の作業欄。以下の作業データが示される
a．
WEB 要素（第 3、5、8、12、16、20 行）
b．
各種作業（WBS 要素から数桁下げて書かれている）
c．
現行計画（太い棒線で示す）
d．
ベースライン計画（現行計画と同じだが、異なる場合は太い棒線の下に細い棒線
で示す）
e．
適当な期日における状態を示す線
f．
各作業の遅れ（現行計画の太い棒線の上に示すダッシュ線）
g．
ベースラインからのスケジュールのずれ（第 12 行のマイルストーンの下に示す
ダッシュ線）
・
注記：チャート主要部にある記号を説明する
このガントチャートは 23 行しかないが、この WBS 要素のために現在実施されている各種
作業の概略表である。状態報告時に最も関連のある諸項目に従って細目数を調整するのが
よい。
- 63 -
SPACE SCIENCE & INSTRUMENTS 社
承認者：
レベル3 のマネジャ
作成者：
レベル4 のマネジャ
システム（レベル2）
サブシステム（レベル3）
4
レベル
アセンブリ（レベル4）
1990
作
1
2
3
4
マイルストーン
業
−サブシステム
−アセンブリ
OCT NOV DEC
SDR
5
6
7
1／2 頁
状況の期日：1991 年 1 月20 日現在
改訂期日：1990 年12 月23 日
1991
FY91
MAR APR MAY JUN
CDR
JAN FEB
PDR
PDR
マネージメント
4 四半期評価
システムエンジニアリング
アセンブリ設計
サブアセンブリ要求事項
スティックスキャット
プロジェクト
JUL
AUG SEP
DEL
CDR
F
F
8 サブアセンブリ＃１
9
設計
10
製造
11
試験
TO I&T
12 サブアセンブリ＃2
設計
13
製造
14
試験
15
16 サブアセンブリ＃3
設計
17
製造
18
試験
19
TO I&T
TO I&T
20 統合化と試験
計画書
21
要領書
22
統合化と試験
23
F
F
注記： 「フロート」
（プラスまたはマイナス）は、作業を示す棒線と
事象記号の上方に示す。
ベースライン」計画が現行計画と異なる場合、現行計画の下に
示す。
REC
ALL SUBASSY
FIXTURES
このアセンブリは、PFM（WBS 49801）のものである。
FM1（WBS 49802）とFM2（WBS 49803）のアセンブリは
2／2 頁に示す。
図13 ガントチャート例
4.5
予算編成と経営資源計画
予算編成と経営資源計画では、プロジェクトの妥当なベースライン予算を編成し、技術
やスケジュールの変更に起因するそのベースライン予算の変更を分析する。システムエン
ジニアとしては、プロジェクトの WBS（Work Breakdown Structure＝作業明細構成）、ベー
スライン・スケジュール、予算などを、プロジェクトの目標と目的に適合する技術的内容、
時間、コストを反映させた、相互に依存関係のあるものとみなすべきである。
予算編成手続きでは、固定コストキャップ（コスト上限）やコストプロファイルがある
かどうかを考慮に入れる必要がある。このコストキャップやコストプロファイルがないと
きは、WBS とネットワーク・スケジュールからベースライン予算を編成する。この予算編成
では、特にプロジェクトの労働力やその他経営資源のニーズを適切な労働力率およびその
他の財務要素や計画要素と結びつけて、いくつかのコスト項目の見積りを行う。これらの
コスト「項目」としては、次のものがある。
・
直接人件費
・
間接費
・
その他の直接費（旅費、データ処理費など）
- 64 -
・
下請契約費
・
原材料費
・
総務・管理費
・
金利（たとえば利息支払い金など。必要な場合のみ）
・
料金（Fee）（必要な場合のみ）
・
緊急対策費
コストキャップや固定コストプロ
注記：資源限界を越
えた作業は、スケジ
ュールを作成し直す
必要がある
15
ファイルがある場合は、論理ゲート
が追加される。システムエンジニア
が予算編成と経営資源計画を完了す
経営資源限界
る前には、そうした論理ゲートを満
10
たしておかなければならない。指定
されたコストキャップやコストプロ
フ ァ イ ル の 下 で WBS とネットワー
ク・スケジュールが実行可能かどう
5
かを判定する必要もある。実行可能
単位
でないならば、システムエンジニア
0
はプロジェクトを拡張する（通常は、
時間
10
20
30
図14 不均一な経営資源プロファイル例
総経費が増大する）か、プロジェク
トの目標と目的、要求事項、設計、
実施方法を削除するかどちらかの最
良策を推奨する必要がある。（枠内補足記事「スケジュールのずれ」を参照）。
コストキャップや固定コストプロファイルがあっても、コストのベースライン化後にコ
スト管理（コントロール）を行うことは重要である。プロジェクトのコストとスケジュー
ルの状態報告と評価も、コスト管理の重要な一面である。そうした報告方法と評価方法に
ついては、本ハンドブックの第 4.9.1 項で検討する。もう一つの重要なコスト管理面は、
リスク回避戦略やワークアラウンド戦略のようなコスト面とスケジュール面のリスク計画
の策定である。プロジェクト・レベルにおける予算編成と経営資源計画では、不測の事態
に対処するために十分なレベルの緊急用積立金を備えておく必要もある。リスク・マネジ
メント方法については、第 4.6 項で検討する。
- 65 -
スケジュールずれの影響評価
「固定コスト」の特定コスト項目は時間関係のものが多いが、「可変コスト」の場合は製
品関係のものが多い。プロジェクトのスケジュールにずれが生じると、プロジェクトの固
定コストは増大する。可変コストは（インフレ調整の場合を除き）総体的に増減しないが、
下図に示すように下流へ繰り越される。
これらの金額（ドル）は
ここへ繰り延べられる
可変コスト
現時点
固定コスト
これらの金額（ドル）は固定
コスト追加分である
スケジュールの単純なずれによる影響を手早く評価する方法は、次のとおりである。
・
ベースライン予算案を名目ドル（nominal dollars)金額（現年度）から固定ドル金
額へ換算する
・
ベースライン予算案を固定コストと可変コストに分割する
・
スケジュールのずれを導入する
・
労働力分割費も含めた新可変コストを算定する
・
許容しうる可変コストが得られるまで、最後の 2 段階をくり返す
・
新固定コストを算定する
・
新固定コストと新可変コストを合計する
・
その合計額を固定ドル金額から名目（現年度）ドル金額に換算する
4.6
リスク・マネジメント
リスク・マネジメントは、リスクの発生源、大きさ、軽減化に対する慎重な予測と、バ
ランスのとれたリスク削減対策からなる。したがって、リスク・マネジメントはプロジェ
クト・マネジメントの重要な一環であり、システムエンジニアリングの目的に直接寄与す
る。
NASA（米国航空宇宙局）のプロジェクト・リスク政策の諸目的は、NMI（NASA Management
Instructions＝NASA 管理手引書）8070.4A 「リスク管理政策」（Risk Management Policy）
に示されている。
その目的は次のとおりである。
- 66 -
・
プロジェクト・ライフサイクル全体に適用できる整備された実証済みリスク・マネ
ジメント方法を提示する
・
管理職の意思決定を支援するために、総合的リスク評価方法（つまり、コスト、ス
ケジュール、性能、安全性上の諸問題を考慮に入れたもの）を提示する
・
評価結果のリスクレベルとそれらに関する決定事項の重要性を NASA 管理職に伝える
リスク・マネジメント
リスク計画
リスクの識別と
特性表示
リスク分析
リスク軽減化と
リスク追跡
図15 リスク・マネジメント構成図
システムエンジニアがこうした目的達成のために採択すべき対策は多数ある。とりわけ
重要な対策は、適切な「リスク・マネジメント計画」(Risk Management Program）を策定
し実施することである。このような計画には、システムエンジニアリング・プロセスにお
いて実施するいくつかの関連作業も含まれる。この作業の構成図を図 15 に示す。
リスク
「リスク」という用語は、状況に応じて異なった意味を持つ。単に特定活動から得られ
た結果の変動度を指す場合もある。システムエンジニアリング・プロセスにおけるリスク・
マネジメントの場合、「リスク」という用語はさまざまな結果が生じる可能性とそうした結
果による目立った影響を組み合わせたものを指す。しかも、技術的失敗のリスク、コスト
目標を超えるリスクといった望ましくない不利な結果に重点が置かれるのが通例である。
第一に、リスク・マネジメント計画を策定する。この計画は、「リスク・マネジメントプ
ログラム計画書」（Risk Management Program Plan）として文書化する必要がある。この計
画書は、SEMP（Systems Engineering Management Plan ＝システムエンジニアリング・マ
ネジメント計画書）を練り上げたもので、次のような内容である。
・
プロジェクトの総合リスク政策とその目的
・ リスク・マネジメント作業の計画面（つまり、責任体制、経営資源、スケジュール、
マイルストーンなど）
- 67 -
・
リスクの識別と特性表示、リスク分析、リスク軽減化対策と追跡調査などに採用す
べき各種の方法、手続き、ツールの説明
・
信頼性解析、公式審査、状態報告および評価などにおけるリスク・マネジメントの
役割に関する説明
・
リスク・マネジメントを必要とする各製品と各作業に関する文書化要件
リスク・マネジメント作業面は、NASA 本部の計画担当部署と共同で策定したプロジェク
トの総合リスク政策に適合したものとすべきである。現在、正式な総合リスク政策関係の
プロジェクト分類指針書はまだない。現在あるのは、NASA ペイロードに関する指針書だけ
である。それは、NMI（NASA Management Instructions＝NASA 管理手引書）8010.1A 「NASA
ペイロードの分類、付属書 A」（Classification of NASA Payloads, Attachment A）で、
添付資料 B.3 に転載してある。
リスク・マネジメント作業の「結果」を記載したデータ表をいくつか付け加えれば、リ
スク・マネジメントプログラム計画書はプロジェクトのリスク・マネジメント計画書（RMP
＝Risk Management Plan）になる。これらのデータ表には、プロジェクトにおいて特定さ
れた意味のあるリスクを記載すべきである。さらにこのデータ表には、各リスクごとの関
連特性表示と解析結果、関連軽減化計画と追跡調査計画（範囲縮小(de-scope)オプション
や必要な技術開発も含む）の説明も記載すべきである。RMP（リスク・マネジメント計画書）
の概要例を添付資料 B.4 に示す。
リスク・マネジメントの技術部分は、プロジェクトのリスクを識別し、その特性を表示
する段階から始まる。この段階の目的は、プロジェクトがどんな不確定要因に直面するの
か、そうした不確定要因のうちのどれに最も着目すべきかといった問題を解明することに
ある。これらの問題を解明するには、発生確率（たとえば高、中、低レベル）別と影響の
重大度別に不確定要因を（矛盾のないように）分類する必要がある。この分類は、不確定
要因をリスク度順にランク付けするための基盤となる。図 16 に示すように、発生確率も高
く、悪影響の重大度も高い不確定要因は、そうした特性を持たないものよりも高位にラン
クされる。この評価に使用される主な方法は定性的評価方法である。したがって、システ
ム エ ン ジ ニ ア リ ン グ 文 献 で は 、 こ の 段 階 を 「 定 性 的 リ ス ク 評 価 」（ qualitative risk
assessment)段階ということもある。この段階からは、特定のマネジメントで注目すべき有
意リスクのリスト（フェーズ別）が得られる。
プロジェクトの中には、定性的評価方法をリスク・マネジメント関係の意思決定に十分
利用できるものもあれば、問題の大きさを理解したり、乏しいリスク削減化資源を配分し
たりする上で精度的に不十分なためにこの方法を採用できないものもある。リスク解析と
は、将来起こりそうな事象（一部の文書では「自然の状態」ともいう）が発生する可能性
とその影響を「定量化」する過程である。システムエンジニアとしては、リスクの識別と
その特性表示が適正かどうか、特定の不確定要因に対してはリスク解析の精度を高める必
- 68 -
要があるかどうかを判定する必要がある。その判定を行う場合、リスク分析の（通常認め
られる）高コスト化と追加情報の価値との間にバランスを取る必要もある。
リスク等高曲線は、発生確率と影響の
重大度を組み合わせて同一リスク・レ
ベルを示すものだが、右方向と下方へ
傾斜しなければならない。
1.0
リスク軽減化対策とは、リスクを経済
的に削減化する戦略を立案、選定、実施
することである。特定のリスクを許容で
きないものと考える場合は、リスク分析
確 率
高リスク
とリスク軽減化対策を何度も実施し、各
種軽減化戦略案の予測結果を調べあげて
中リスク
最適案を選定することが多い。これらの
低リスク
0.0
軽減化戦略の有効性を追跡調査すること
影響の重大度
は、リスク軽減化対策と密接な関係があ
図16 発生確率と影響度によるリスクの
特性表示
る。リスク軽減化対策は、しばしば重大
な問題となる。ある種のリスクを削減化
する努力と費用が別種のリスクを増大させかねないからである。（こうした点を、量子力学
におけるハイゼンベルクの不確定性原理をシステムエンジニアリングに応用したものとい
う者もいる）。ある種のリスクと別種のリスクをトレードする可能性（または必要性）があ
るならば、プロジェクトマネジャとシステムエンジニアとしては、資源の合理的配分を行
うためにシステム全体にわたる各種戦略の影響を解明する必要がある。
表1
リスク・マネジメント技法
リスクの識別と特性表示
リスク解析
リスク軽減化と追跡調査
専門家インタビュー
意思決定解析
独立評価（コスト、スケジュー
ル、技術）
リスク・テンプレート
（例：DoD 4245.7-M）
過去のプロジェクトから得た教
訓ファイル
FMECAs、FMEAs 、ダイグラフ、
故障樹形図(FT)
確率的リスク評価（PRA）
ウォッチリスト／マイルストー
ン
緊急対策計画／範囲縮小計画／
並行開発
重要アイテム／問題リスト
確率的ネットワーク・スケジュ
ール（例：PERT）
確率的コスト・効果モデル
（例：モンテカルロ・モデル）
コスト／スケジュールコントロ
ールシステムと技術性能測定
（TPM）追跡調査
このようなリスク・マネジメント作業に対しては、いくつかの技法がすでに開発されて
いる。表 1 に示すような主な技法については、第 4.6.2 項から第 4.6.4 項で検討する。シ
ステムエンジニアとしては、各プロジェクト特有の要求事項に最も適合する技法を選定す
る必要がある。
プロジェクト・ライフサイクル全体にわたってリスク・マネジメント計画が必要になる。
しかし、連続改良主義を堅持しながらも、プロジェクト・ライフサイクルの初期段階（フ
- 69 -
ェーズ A と B）における「大きな展望」から設計・開発段階（フェーズ C と D）に関する特
定問題へと重点を移す必要がある。運用段階（フェーズ E）でも、重点を変える必要がある。
優れたリスク・マネジメント計画は常に前向きなものである。つまり、リスク・マネジメ
ント計画では、現在のリスク問題と将来の不確定要因に同時に取り組まなければならない。
したがって、リスク・マネジメント計画は、当然コンカレントエンジニアリングの一環と
いうことになる。リスク・マネジメント計画書（RMP＝Risk Management Plan)は、プロジ
ェクト・ライフサイクル全体にわたって絶えず更新されなければならない。
4.6.1
リスクのタイプ
プロジェクトマネジャやシステムエンジニアはさまざまなリスクに直面するが、そうし
た各種リスクを説明する方法はいくつかある。従来、プロジェクトマネジャとシステムエ
ンジニアは、各種リスクを 3 種か 4 種
−
性（またはハザード）上のリスク
に大別する傾向があった。ごく最近では、組織、
−
つまり、コスト、スケジュール、技術、安全
マネジメント、調達、支援性、政治、プログラム上のリスクなどもリスク目録に加える者
もいる。このような新しい種類のリスクは、現在の NASA 環境の下で業務を行うプロジェク
トマネジャやシステムエンジニアの関心の範囲が広がったことを反映している。新リスク
のなかには、その他のリスクのスーパーセットを表わすものもある。たとえば、Defense
Systems Management College（DSMC）の「システムエンジニアリング・マネジメント手引
書」（Systems Engineering Management Guide）では、「資金調達、スケジュール、契約交
渉、政治上のリスク」をまとめて広義のプログラムリスクに入れている。これらの用語は
非公式の議論では役に立つが、あいまいさを排した公式の分類法とは思えない。その第一
の理由は、上に言及したように、しばしばある種のリスクを別のリスクと交換できる点に
ある。第二の理由は、これらの種類のリスクのなかには、たとえばコスト上のリスクと政
治的リスク（たとえば、プロジェクトの取り消しによるリスク）のように、一緒に変化す
るものもあるという点である。
もう一つのリスク分類方法としては、基本的不確定性に対する数学的予測度による方法
もある。既知または予測パラメータを持つ既知の確率分布がある不確定要因と、基本的確
率分布がまだわからないか、またはそのパラメータを客観的に定量化できない不確定要因
との間では、すでに区別されている。
最初の不確定要因例としては、宇宙ステーション「アルファ」の各種設計案に対する予
備品重量増大要求の予測不能がある。その要求は特定のロジスティックス・サイクルにお
いて確率的に予測されるが、その確率分布は信頼性理論と経験的データから各設計ごとに
試算される。もう一つの不確定要因例は、スペースシャトルの事故が x カ月を超える期間
の間「アルファ」に対する補給を不可能にするかどうか、火星に生命が存在するかどうか
などを予測しようとする場合に見られる。
- 70 -
近代的主観論者（ベイズともいう）の確率理論では、事象の確率とは、ある人が自分の
保有する情報に基づいてその事象が起こると信ずるその確信度であると主張する。その情
報が（たとえばデータの収集や経験により）改良されるに伴い、主観論者の予測確率は、
確率分布が既知の場合に予測された確率に近づく。前段落の例との相違点は、確率予測者
が認識した情報の状態だけである。そのため、主観論者は 2 種の不確定要因を区別するの
は実際上ほとんどまたはまったく意味がないとみなす。リスク・マネジメントに関する主
観論者の見解が示唆していることは、データがほとんどまたはまったくなくても、システ
ムエンジニアの主観的予測確率がリスクに関する意思決定の有効な基盤になるという点で
ある。
4.6.2
リスク識別・特性表示技法
リスクの識別とその特性表示には、さまざまな技法が利用できる。この段階を徹底的に
実施することは、リスク・マネジメント計画を成功させる重要な鍵となる。
専門家インタビュー
適正に実施すれば、専門家インタビューは、専門家の知識分野におけるプロジェクトの
リスクに対する見識や情報の重要な発信源となる。インタビューを成功させる一つの秘訣
は、リスク問題に十分精通しているだけでなく、同時に一歩下がって確率と結果に対して
客観的見方を取れる（または取ろうとする）専門家を見極めることである。もう一つの秘
訣は、インタビューを行う側の事前準備である。つまり、インタビューで扱うリスク問題
のリストを作成し、こうした問題に役立ち、しかもプロジェクトに適用すべき知識を増や
し、インタビューから情報を収集するための方法を開発することである。
最初のインタビューからは定性的な情報しか得られないが、この情報も追跡調査段階で
検証する必要がある。専門家インタビューでは、定量的に高位にランクされるリスク問題
に関する定量的なデータや情報を得ることもできる。このようなインタビューは、第 4.6.3
項に述べる技法を使って構築されたリスク解析モデルに導入する情報の重要な発信源とも
なる。
独立評価
この技法はいくつかの形をとることができる。作業報告書（Statements of Work）、調達
計画書、検証計画書、製造計画書といったプロジェクト関係文書の審査という形で実施す
ることもできる。また、プロジェクト・スケジュールとの適合性や一貫性に関する WBS（Work
Breakdown Structure＝作業明細構成）の評価という形でも実施できる。自主評価としては、
さらに、外部組織から得る別個のコスト（及びスケジュール）予測という場合もある。
- 71 -
リスク・テンプレート
この技法は、開発済みのリスク・テンプレートを審査して現行プロジェクトに適用する
方法である。各テンプレートは通常特定のリスク問題を扱い、そのリスクを回避または削
減する方法を説明する。最も広く認識されている一連のテンプレートは、DoD（国防総省）
4245.7-M 「 開 発 か ら 生 産 へ の 移 行 .... リ ス ク 方 程 式 の 解 答 方 法 」（ Transition from
Development to Production ....Solving the Risk Equation)に見られるものである。そ
こに述べられているリスクとリスク対策の多くは、国防総省（DoD）の諸計画から得た教訓
に基づいたものだが、NASA（航空宇宙局）にも適用できるほど一般的なものである。一般
的注意として、リスク・テンプレートは全てのプロジェクトに通用するリスク問題を網羅
したリストを提示するものではなく、リスクの識別に役立つ入力情報にすぎない。
教訓
過去の同種プロジェクトから得た教訓ファイル、データ、報告書などを再検討すれば、
新規プロジェクトのリスクの識別に必要な見解や情報を得ることもできる。たとえば技術
的リスクの識別では、機能、アーキテクチャ、技術的方法などが類似している過去のプロ
ジェクトを調べるのが良い。赤外線天文衛星（IRAS＝Infrared Astronomical Satellite)
プロジェクトから学んだ教訓は、たとえ大幅に複雑化しても、宇宙赤外線望遠鏡装置（SIRTF
＝Space Infrared Telescope Facility)プロジェクトにも役立つものと思われる。この技
法をうまく採用する鍵は、両プロジェクトの類似点は何か、新規プロジェクトに必要なデ
ータは何かを十分認識することである。過去のプロジェクトから得た実証済みの教訓がシ
ステムレベルに適用できないものであっても、サブシステムや構成要素のレベルに適用で
きる貴重なデータがあるかもしれない。
FMECAs、FMEAs、ダイグラフ、故障樹形図
故障モード、影響及び致命度解析（FMECA＝Failure Modes, Effects, and Criticality
Analysis）、故障モード及び影響解析（FMEA＝Failure Modes and Effects Analysis）、ダ
イグラフ、故障樹形図は、安全性（またはハザード）リスクの識別とその特性表示に採用
できる専門技法である。これらの技法では、システムを構成するハードウェア要素に重点
を置く。MIL-STD（Military Standard ＝米国陸軍標準規格）-1629A によると、FMECA は、
「システムに発生する恐れのある潜在的故障を分析し、システムに生じるその結果や影響
を予測すると共に、各潜在的故障モードをその重大度に応じて分類する現行手順」である
という。その故障は次の 4 種に大別されている。
・
カテゴリーI
−
・
カテゴリーII
・
カテゴリーIII −
重大事故（軽傷やミッションの有効性低下を伴う）
・
カテゴリーIV
軽微故障（システムの保全を必要とするが、人的災害やミッシ
−
−
破局的故障（死亡やシステムの損失を伴う）
臨界故障（重傷やシステムの破損を伴う）
- 72 -
ョンの有効性低下を伴うものではない）
完全な FMECA は、各潜在的故障の発生確率予測も含む。通常、この確率は、最初は同種
のハードウェア構成要素から得た主観的判断や経験に基づいたものであるが、システムの
開発が進むにつれて、信頼性データに基づいて精度を高めることができる。FMEA は FMECA
とほとんど変わらないが、重大度に応じた故障分類に重点を置いたものではない。
ダイグラフ解析は、相互に接続した複数の大型システムにおける故障許容限界、故障の
伝ぱ、信頼性などを算定する際の補助的手法である。ダイグラフはネットワーク構成から
なる概略線図のようなものである。ダイグラフ技法では、多数の FMECA や FMEA から得たデ
ータを統合化でき、定量的確率予測が必要な場合には、第 6.2 項で説明するような故障樹
形図に表わすこともできる。
4.6.3
リスク分析技法
リスク分析のツールと技法は、確率という概念と確率の「法則」（実際には公理と定理）
に大きく依存したものである。システムエンジニアとしては、この技法の威力と限界点を
認識するためにも、こうした法則にも精通する必要がある。リスク解析から通常得られる
成果は、各種結果に関する確率と影響の定量的予測、主要リスクの詳細な解明、リスク削
減化資源配分方法の改良などである。
意思決定解析
意思決定解析は、一連の複雑な不確定要因を処理する各意思決定者を支援するための一
つの技法である。多くのシステムエンジニアリングに共通する「分割征服」
(divide-and-conquer)方式を採用すれば、複雑な不確定要因をいくつかの単純なものに分
割し、個別に処理できる。その分割化は、確実な情報が得られるレベルや、直観を効果的
に働かせることができるレベルに達するまで続けられる。この分割化の過程は、意思決定
樹形図（decision tree)として図示できる。意思決定樹形図にあるノードという分岐点は、
意思決定時点や偶発事象を表わす。樹形図の最終点は、潜在的結果（得られる見込みのあ
る結果）である。（枠内補足記事「火星探査の意思決定樹形図例」を参照）。
意思決定解析のほとんどの適用例では、こうした結果が通常割当てドル価額になる。各
偶発事象ノードに割り当てられた確率と各結果のドル価額からは、一連の意思決定ごとに
ドル価額の配分方法（つまり影響）を引き出すことができる。大型の複雑な意思決定樹形
図でも、現在入手できる意思決定解析ソフトウェアに図示できる。このようなソフトウェ
アでは各種のリスク評価値も算定できる。
端的に言えば、意思決定解析とは、以下のことができる技法である。
・
不確定要因の組織的目録を作成し、その確率と結果をコード化する
・
「リスク嫌い」という、リスクに対する意思決定者の姿勢の特徴を明示する
- 73 -
・
「完全な情報」の価値を算定し、情報収集費の標準的上限を設定する
・
確率予測値とその結果のドル価額に対する感度試験を行う
確率的リスク評価（PRA）
確率的リスク評価（PRA＝Probabilistic Risk Assessment)は、各種の予想事故系列とそ
の影響が発生する可能性を定量化して、システムの設計と運用に伴うリスクを評価しよう
とするものである。代表的な PRA 適用例は、特定された原子力発電所に伴うリスクの算定
である。NASA（米国航空宇宙局）部内では、たとえば RTG（Radioisotope Thermoelectric
Generators ＝ラジオアイソトープ熱電子発生器）を搭載した衛星の打ち上げに関する相対
的安全性を実証するために PRA を採用している。
事象樹形図（Event tree）と故障樹形図（Fault tree）を採用すれば、事故系列の探索
が容易になる。事象樹形図は、初期事象ならびにシステムの成功例と失敗例を組み合わせ
たものを図示したものである。故障樹形図は、事象樹形図に示されたシステムの故障がど
のようにして起こったかを示すものである。事象樹形図とその関連故障樹形図を組み合わ
せて使用すると、各事故系列の発生確率を算定することができる。この樹形図の構成と計
算法は意思決定樹形図の場合とほとんど変わりがない。各事故系列の影響は、通常、直接
的な経済的損失と公衆の健康に対する影響として評価されている。（枠内補足記事「確率的
リスク評価の落とし穴」を参照）。
確率的リスク評価（PRA）を行うことは、信頼できる技術者や人間工学技術者の専門的技
能の他に、多くの専門的技能を必要とするので、それ自体大変なことである。PRA ではさら
に、構成要素レベルのシステム設計データと運用手順データが大量に必要となる。確率的
リスク評価について、システムエンジニアの参考になるものとしては、アメリカ原子力学
会（American Nuclear Society）と電気電子学会（IEEE＝Institute of Electrical and
Electronic Engineers）が共同出版した"PRA Procedures Guide"（PRA 手順書）（1983 年）
がある。
- 74 -
確率的リスク評価の落とし穴
確率的リスク評価（PRA）においては、リスクを次のような影響関数から得られる予測値と
定義している。
R＝Σ Ps Cs
s
この場合、Ps は結果 s の確率、Cs は結果 s の影響である。結果に確率を結びつけるため
に、事象樹形図と故障樹形図が開発されている。この技法は 1953 年から採用されてきたが、
1970 年代後半には PRA の実施者から批判を受けるようになった。
その理由としては、以下の点を挙げることができる。
・
あらゆる故障を定義することはできないので、故障樹形図には限界がある
・
共通原因の故障を適正に収集することはできそうにない。共通原因の故障例として
は、システムのすべての弁が共通の欠陥を持つため、そのすべての弁の故障は真に
独立したものではないという場合がある？
・ PRA の結果は、事象樹形図の想定条件に加えられた簡単な変更に左右されやすいこと
もある
・
所定のリスク許容基準はリスクの種類に応じて異なることが多いので、リスク削減
化資源の配分には適用できない
・
リスク関係の多くの意思決定は意思決定者の認識に左右され、必ずしも上記方程式
により定義された客観的リスクに基づくものではない。影響に対する認識は、影響
自体よりも速く波及する傾向がある
−
つまり、致死率が同一であっても、数件
の小事故は 1 件の大事故ほど痛切に認識されることはない
・
たとえば生命とドルのように、比較できないものを処理するには難点がある
確率的ネットワーク・スケジュール
PERT（Program Evaluation and Review Technique ＝プログラム評価及び審査手法）の
ような確率的ネットワーク・スケジュール技法では、各作業の所要時間を確率変数として
処理できる。各作業の最短所要時間、最長所要時間、最適所要時間を使用して PERT を実施
すると、プロジェクト完了時期の確率分布を算定することができる。
しかし、この確率分布の下では、唯一のクリティカルパスというものは存在し得ない。
この技法の実施者のなかには、確率的ネットワーク・スケジュール向けに有意の入力デー
タを取得しにくい点を挙げる者もいる。完全な確率的ネットワーク・スケジュールに代わ
る簡単な技法は、プロジェクトのクリティカルパスに沿って作業所要時間のモンテカル
ロ・シミュレーションを実施することである。（第 5.4.2 項を参照）。
- 75 -
確率的コスト・効果モデル
こうしたモデルは、プロジェクトのコスト・効果算定結果を確率的に示すものである。（図
2 を参照）。この技法からは、こうした変数に対する単一点の値だけでプロジェクト特有の
リスク条件を十分示し切れないことがはっきりと認められる。この種のモデルについては、
第 5.4 項においてさらに徹底的に検討する。
4.6.4
リスク軽減化および追跡調査技法
リスクの識別とその特性表示ならびにリスク分析からは、マネジメント部門による注目
や対策を必要とする重大なプロジェクト・リスクのリストが得られる。リスク軽減化対策
は通常コストがかかるので、システムエンジニアとしては、プロジェクトマネジャに対し
て勧告を与えるにしても、そのような対策のコスト（経営資源と時間）とプロジェクトに
対する対策の価値とのバランスを考慮する必要がある。特定のリスクに対する対応策とし
ては、通常以下の 4 つを採用できる：（1）故意に何もせず、リスクを受け入れる。（2）共
同参画者とリスクを分担する。（3）リスクを回避または削減する予防策を講じる。（4）緊
急対策を講じる。
第一の対応策は、このリスクを意識的に受け入れることである。（この対応策はリスク情
報の収集と評価を伴うことがある）。第二の対応策では、共同参画者（つまり国際提携者や
契約者）とリスクを分担することもできる。この場合の目標は、リスク全体がどうなるか、
リスクが高まるか低下するかという点とは関係なく、NASA のリスクを削減することである。
リスク、特にコスト面のリスクを契約者と分担する方法は多数ある。このような方法とし
ては、各種の優遇契約や保証契約などがある。第三と第四の対応策では、特定の計画や対
策を追加実施する必要がある。
代表的な技術的リスク軽減化対策としては、サブシステムとシステムの試験追加（通常
コストがかかる）、冗長型設計の実施、完全なエンジニアリング・モデルの作成などがある。
コスト面の代表的なリスク軽減化対策としては、既製ハードウェアの利用、図 6 に示すよ
うなフェーズ A と B への十分な資金供与などがある。主な支援リスク軽減化対策としては、
システムのアベイラビリティ目標に合わせた十分な初期予備アイテムの提供、しっかりし
た補給体制の確立（この場合は輸送力が重要な要素となる）などがある。設計対策や管理
対策だけではリスクを軽減化できない場合、システムエンジニアとしては、財政面とスケ
ジュール面におけるしかるべき緊急体制の確立と技術的余裕を勧告すべきである。
特定のリスクに対してどんな戦略が選定されるにせよ、その戦略とその基本的根拠をリス
ク軽減化計画書に明記し、NMI（NASA Management Instructions＝NASA 管理手引書）8070.4A
に規定されているように、プロジェクト・ライフサイクルを通じて追跡調査を行うべきで
ある。リスクの（好適）軽減化戦略の選定方法については第 5 章でも検討するが、この章
の本題はトレード研究とシステム・モデル作成の役割拡大である。いくつかの計画方法と
- 76 -
追跡調査方法については、ここで簡単に述べるにとどめる。
ロボット火星偵察ミッションの意思決定樹形図例
1990 年、JSC（Johnson Space Center＝ジョンソン宇宙センター）の月／火星探査計画局
（Lunar/Mars Exploration Program Office)（LMEPO）では、ロボット火星偵察ミッション
が有人火星探査ミッションのリスクをどの程度削減できるかという問題を解明しようとし
た。この問題を意思決定樹形図に表わせば、各種ミッションと偶発事象の結果を組織的に
定量評価できる。ここに示す意思決定樹形図の一部は、3 つの個別結果に対する確率の算定
方法を図示したものである。その 3 つの結果とは、大気圏または現地偵察のロボット予備
ミッションを実施せず、その後有人ミッションのために火星でのエアロキャプチャを選定
した場合に予想される結果で、（A）火星着陸に成功、（B）着陸せずに安全に帰還、（C）大
惨事によるミッション失敗と搭乗員死亡である。新情報を入手することで、意思決定樹形
図のデータを審査、更新できる。
各結果の確率
A
B
＝8.635
＝0.600
C ＝0.765
変更着陸0.09
＝1.000
着陸0.9
墜落0.01
大惨事による
宇宙機損失
0.04
成功 0.9
成功0.8
ゼロG（無重力）
不耐性 0.06
ΔV損失0.18
推進キャプチャ
現地偵察ミッション
なし
大気圏探査ミッションなし
エアロキャプチャ
墜落0.01
スキップア
ウト0.01
変更着陸0.03
着陸0.9
現地偵察
ミッション
意思決定ノード
墜落 0.07
偶発事象ノード
結果
0.00
確率
意思決定樹形図のすべての分岐経路に対して同じ計算をすると、以下の事項に応じた数
回のロボット偵察ミッションの最適総合結果を算定することができる：（a）有人ミッショ
ンのリスク削減化に対する各ロボット偵察ミッションの寄与率、（b）各ロボット偵察ミッ
ションのコスト、スケジュール、リスクの度合い、（c）有人ミッションの価値、（d）その
後有人ミッションが実施されない場合の各ロボット偵察ミッションの科学的価値。この定
量方式のもう一つの利点は、有人ミッションのアーキテクチャにおけるその他のリスク軽
減化戦略に対するロボット偵察のトレードを実施できることである。
意思決定解析の詳細については、De Neufville、Stafford 共著 "Systems Analysis for
Engineers and Managers"(技術者とマネジャのためのシステム解析）（1971 年）および
Barclay そ の 他 共 著 "Handbook for Decision Analysis"(意思決定解析ハンドブック）
（1977 年）を参照されたい。
- 77 -
ウォッチリストとマイルストーン
「ウォッチリスト」は、特定のリスク、その影響予測、問題発生の初期指標を列記した
ものである。ウォッチリスト上に記載される各種リスクは、リスク・マネジメント作業を
完了した上で、マネジメント部門の注意を引くように選定されたものである。標準的ウォ
ッチリストでは、対応策に採用すべき引き金事象や見落としマイルストーン（たとえばリ
ードタイムの長いアイテムの納入遅れなど）、影響を受ける領域（生産スケジュール）、リ
スク軽減化戦略なども、特定リスクごとに示す。ウォッチリストは定期的に見直しを行い、
必要に応じて項目を追加、変更、削除する。引き金事象が発生した場合は、影響予測を更
新し、必要に応じてリスク軽減化戦略も改定すべきである。
緊急対策計画、特別計画、並行開発
これらの技法は、通常ウォッチリストと併用されるものである。この技法では、引き金
事象に対する確実な防護手段や次善策の開発に重点を置く。防護手段を確実なものにする
には、引き金事象が発生した場合しか効果がなくても、追加資源を費やす必要がある。こ
うした意味で、これらの技法と資源はプロジェクトの保険という役割を果たす。（「緊急対
策」（contingency)という用語は、NASA 部内でプロジェクトの緊急用準備金に対して使用し
ている同じ用語と混同してはならない）。
クリティカルアイテム／問題点リスト
クリティカルアイテム／問題点リスト（CIL＝Critical Items/Issues List）はウォッチ
リストと同じようなもので、「シャトル」計画ではシステムの安全性に重大な影響を及ぼす
アイテムを追跡調査する際に広く採用されてきた。その一例を添付資料 B.5 に示す。
C／SCS および TPM 追跡調査
この 2 つの非常に重要なリスク追跡調査技法
−
コスト／スケジュールコントロール
システム（C／SCS＝Cost and schedule control systems)と技術性能測定（TPM＝Technical
Performance Measure)の追跡調査技法
−
については、それぞれ第 4.9.1 項と第 4.9.2
項において検討する。
4.6.5
リスク・マネジメント：
まとめ
不確定性は、システムエンジニアリングにおいても避けがたいものである。それを効果
的に処理するには、リスクマネジャが的確な方法を採用する必要がある。プロジェクト環
境では、好ましい慣行として以下の作業が実施されている。
・
リスク・マネジメント計画を立案、文書化、実施する。
・
プロジェクトの各フェーズ（段階）ごとにリスクの識別とその特性表示を行う。発
- 78 -
生確率と影響の相乗効果が大きい高リスクに対しては、マネジメント部門の目を向
けさせる。プロジェクト・ライフサイクル全体を通して実施される審査も、リスク
問題解消の一助とする。
・
主要リスクを解明し、リスク削減化資源の配分方法を改善するために、定性的技法
と定量的技法を併用する。それには、意思決定樹形図のようなプロジェクト特有の
リスク分析モデルや PRA(Probabilistic Risk Assessment＝確率的リスク評価）技
法の開発も含める。
・
各リスクを処理する戦略を策定かつ実施し、必要に応じて財政面とスケジュール面
のしかるべき緊急対策と技術的余裕を設ける。
・
各リスク軽減化戦略の有効性を追跡調査する。
リスク・マネジメントを成功させるには、チームワークが不可欠である
−
つまり、
プロジェクトのあらゆるレベルのシステムエンジニアとマネジャを参加させる必要がある。
しかし、リスク・マネジメントの各種責務は、特定の個人に割り当てなければならない。
リスク・マネジメント業務の成功は、制度的な政策へ進展する場合も多い。
4.7
コンフィギュレーション・マネジメント
「コンフィギュレーション・マネジメント」とは、製品の各進展段階においてコンフィ
ギュレーションアイテムの機能的特性と物理的特性を識別し、形式化する分野である。そ
の目的は、製品システムの保全性を維持し、「ベースライン」に対する変更を管理すること
にある。プロジェクトに対するベースラインとしては、すべての技術的要求と、それらに
関連するコスト面とスケジュール面の要求があるが、それらの要求は NASA のプロジェクト
マネジャが受け入れてその変更管理下に置く位充分に煮詰めたものでなければならない。
プロジェクトのベースラインは、技術的ベースラインとビジネス・ベースラインに二分さ
れる。システムエンジニアは、技術的ベースラインを管理し、それをビジネス・ベースラ
インのコストとスケジュールに適合させる責任を負う。通例、ビジネス・ベースラインを
管理するのは、プロジェクト管理部署である。
コンフィギュレーション・マネジメントでは、最新のプロジェクト要求条件書（プロジ
ェクト・ライフサイクルのこの段階に存在するもの）に従って買い手と売り手の正式契約
を進め、正式のコンフィギュレーション・コントロール手続きに従ってベースラインの要
求事項を変更する必要がある。買い手が NASA プログラム部署になることもあれば、外部の
資金提供当局になることもある。たとえば、GOES（Geo-stationary Operational Environment
Satellite ＝静止実用環境観測衛星）プロジェクトの買い手が NOAA（National Oceanic and
Atmospheric Administration ＝アメリカ海洋大気局）で、売り手が NASA の GOES プロジェ
クト課になることもある。コンフィギュレーション・マネジメントは、あらゆるレベルで
実施しなければならない。これと同じ例で言えば、次のレベルでは、NASA の GOES プロジェ
- 79 -
クト課が買い手になり、売り手はその契約者であるローラル（Loral)社の GOES プロジェク
ト課になる。コンフィギュレーション・マネジメントは、プログラム／プロジェクト要求
条件書を通して、また必要に応じて契約の作業報告書を通して確認される。
コンフィギュレーション・マネジメントは、開発過程を適正に進めるためにも、既成の
設計を変更するためにも、また既成の設計を後に複写するためにも欠かせないものである。
コンフィギュレーション・マネジメントでは、プロジェクトのコンフィギュレーション文
書も管理するので、プロジェクトの技術的進捗状況を追跡する際に必要となる情報を提供
することも多い。（技術性能測定については、第 4.9.2 項を参照）。プロジェクトにおける
コンフィギュレーション・マネジメントへの取り組み方と採用方法は、プロジェクトのコ
ンフィギュレーション・マネジメント計画書（Configuration Management Plan)に明記す
べきである。この計画書の概要例は添付資料 B.6 に示すとおりである。この計画書は、各
プロジェクトのニーズに合わせて調整し、プロジェクトのライフサイクル全体を通して常
に最新のものでなければならない。
4.7.1
ベースラインの進展
プロジェクト・レベルのシステムエンジニアには、技術的ベースラインの完全性と技術
的保全性を保証する責任がある。技術的ベースラインとしては、次のものがある。
・
ハードウェア、ソフトウェア、情報アイテム、製造方法に関する機能および性能要
求事項（または仕様）
・
インターフェース要求事項
・
専門工学的要求事項
・
検証要求事項
・
データパッケージ、文書、図面樹形図
・
適用技術規格
プロジェクトのベースラインは、プロジェクト・ライフサイクル全体にわたって明確に
区分されたいくつかの段階を経由して進展する。「ミッション・ニーズ報告書」(Mission
Needs Statement) に明記されたトップレベルのユーザー要求事項がコンフィギュレーショ
ン管理（コントロール）下に置かれた時に、最初のベースラインが設定される。フェーズ
間のコントロール・ゲートごとに、より高い技術的詳細度が加えられてベースラインは徐々
に成熟化する。標準的プロジェクトでは、連続した 5 つの技術的ベースラインが採用され
る。
・
システム要求審査（SRR＝System Requirements Review）における機能ベースライン
・
基本設計審査（PDR＝Preliminary Design Review)における"design-to" ベースライ
ン
・ 詳細設計審査（CDR＝Critical Design Review）における"build-to"（または"code-to）
- 80 -
ベースライン
・
システム受領審査（SAR＝System Acceptance Review）における"as-built"（または
"as-coded"）ベースライン
・
運用準備審査（ORR＝Operational Readiness Review）における"as-deployed" ベー
スライン
この 5 つのベースラインの進展状態を図 17 に示す。第 3.7.1 項で述べたように、図 7 に
示した「V 形」チャートの中核部に沿って下された決定事項だけがコンフィギュレーション
管理（コントロール）下に置かれ、承認済みベースラインに導入される。システム解析、
リスク・マネジメント、開発試験などの作業（V 形チャートの中核部以外のもの）は、初期
段階から開始され、プロジェクト・ライフサイクルの分解プロセス全体にわたって継続さ
れ、中核レベルの決定事項が信頼できるものであることを立証しなければならない。こう
した初期の詳細研究と試験の結果は、文書化した上で、プロジェクト関係の記録保管所に
保管されなければならないが、技術的ベースラインを構成するものではない。
- 81 -
4.7.2
コンフィギュレーション・マネジメント技法
コンフィギュレーション・マネジメント技法としては、コンフィギュレーション（また
はベースライン）識別、コンフィギュレーション・コントロール、コンフィギュレーショ
ン検証、コンフィギュレーション・アカウンティングなどがある（図 18 を参照）。
ミッショ
ン・ニーズ
報告書
機能ベースライン
概念
MRR
MDR
システム
仕様書、
部分的な
解析
タイプA
設計の主要アーキテ
クチャー面完了
"Design-To"
ベースライン
設計の実施面完了
セグメント
仕様書
セグメント
仕様書
セグメント
仕様書
タイプA
タイプA
タイプA
SRR
プログラム
計画書
主要アイテム
"Design-To"
仕様書
タイプB
主要アイテム
"Design-To"
仕様書
タイプB
主要アイテム
"Design-To"
仕様書
タイプB
エンドアイテ
ム"Design-To"
仕様書
タイプB
エンドアイテ
ム"Design-To"
仕様書
タイプB
エンドアイテ
ム"Design-To"
仕様書
タイプB
"Built-To"
ベースライン
エンドアイテ
ム"Build-To"
仕様書
タイプC
製造及び試験完了
SDR
計画書
完全な解
析
PDR PDR
PDR
要領書
設計開示、−
図面
−線図
−その他
"As-Built"
ベースライン
エンジニアリング
アイテム
説明書
CDR CDR
CDR
認定試験
アイテム
エンドアイテム
SAR
機能ベースライン
"As-Deployed"
ベースライン
製品システム
ORR
運用の可能性実証
図17 技術的ベースラインの進展
コンフィギュレーション・
マネジメント
コンフィギュレーション
識別
コンフィギュレーション・
コントロール
コンフィギュレーション
検証
図18 コンフィギュレーション・マネジメント構成図
- 82 -
コンフィギュレーション・
アカウンティング
コンフィギュレーション識別
ベースラインのコンフィギュレーション識別を実施するには、使用するベースラインの
他に、そのベースラインに加える変更事項をどのように説明、管理、公表するかという点
について記載した文書を作成し、正式に公表する。それらの文書としては、各種要求書（製
品、製法、材料）、仕様書、図面、コード・リストなどがある。コンフィギュレーション文
書は、買い手のコントロール・ゲートにより承認されない限り、技術的ベースラインの一
部とは正式にみなされない。
コンフィギュレーション識別の重要な一面は、部品番号、製造番号、ロット番号、バー
ジョン番号、文書管理番号などを使用して各コンフィギュレーションアイテムを物理的に
識別することである。
コンフィギュレーション・コントロール
コンフィギュレーション・コントロールとは、コンフィギュレーション管理委員会
（CCB＝Configuration control Board)の正式手続きにより、承認済みベースラインに加え
られた変更事項を管理する過程である。コンフィギュレーション・マネジメントのこの部
分は、通常システムエンジニアに最もよく見える領域である。大型プログラム／プロジェ
クトでは、複数の管理レベルに対応するいくつかのコンフィギュレーション管理委員会か
らなる階層的管理体制によりコンフィギュレーション・コントロールが実施される。各コ
ンフィギュレーション管理委員会（CCB）は、コンフィギュレーション・マネジメント計画
書（CMP＝Configuration Management Plan)に明記されたそれぞれ独自の管理・責任領域を
担当する。
通常、コンフィギュレーション管理委員会は、プログラム／プロジェクトのビジネス・
ベースラインや技術的ベースラインに対する変更要求事項を審議する。この委員会では、
プログラム／プロジェクトマネジャが委員長であり、唯一の意思決定者となる。コンフィ
ギュレーション・マネジャは委員会の書記を勤め、議事を手際よく進め、公式議事内容を
記録する。コンフィギュレーション管理委員会の会議では、多くの問題を審議しなければ
ならない。
・
どんな変更事項が提案されたか？
・
その変更理由は何か？
・
設計へどんな影響を及ぼすか？
・
有効性や性能にどんな影響を及ぼすか？
・
スケジュールにどんな影響を及ぼすか？
・
プログラム／プロジェクトのライフサイクルコストにどんな影響を及ぼすか？
・
変更を行わない場合は、どんな影響があるか？
・
変更を行った場合は、どんなリスクがあるか？
・
運用にどんな影響を及ぼすか？
- 83 -
・
支援設備やサービスにどんな影響を及ぼすか？
・
予備アイテム要求事項にどんな影響を及ぼすか？
・
変更の有効性はどの程度か？
・
変更により影響を受ける文書は何か？
・
買い手は変更に賛成しているか？
コンフィギュレーション管理委員会の運営
目的：
評価事項を審議し、プロジェクトの技術的ベースラインやビジネス・ベース
ラインに対する変更提案を認否する。
参加者： プロジェクトマネジャ（委員長）、プロジェクトレベルのシステムエンジニア、
各関係団体のマネジャ、コンフィギュレーション・マネジャ（書記）、提案者。
審議方式：
提案者が推奨変更案を提示し、関連システムに対する影響について説明する。
その変更案は、提示される前にシステムエンジニアがその完全性を審査した
ものとする。
決議方法： コンフィギュレーション管理委員会（CCB）のメンバーが変更要求（CR＝Change
Request）を審議し、公式決定を下す。プロジェクトマネジャが認否を決める。
書記が変更要求の最終決定を記録し、それを指令する CCB 指令書を作成する。
否認
変更要求
売り手側
CCB
クラス1を
承認する
否認
予備ECP を
作成する
正式ECPを
要求する
買い手側
CCB
クラス2を
承認する
否認
ECPを作
成する
承認
買い手側の
決定
承認
いいえ
買い手が分類に
同意する
はい
変更状態を記
録する
買い手の行為
CCB＝Configuration Control Board(コンフィギュレー
ション管理委員会）
ECP＝Engineering Change Proposal(技術変更提案書）
変更を実行す
る
図19 契約変更管理手続き
これらの問題を審議すれば、十分な情報に基づいて決定を下すことができる。問題がコ
ンフィギュレーション管理委員会で審議されない場合は、根拠のない決定が下され、プロ
グラムやプロジェクトにマイナス影響を及ぼすことが多い。
- 84 -
あるベースラインがひとたびコンフィギュレーション管理下に置かれると、いかなる変
更もコンフィギュレーション管理委員会の承認を受けなければならない。プロジェクトマ
ネジャはコンフィギュレーション管理委員会の議長を勤める。他方、システムエンジニア
またはコンフィギュレーション・マネジャの責務は、委員会に提出するすべての資料が完
全なものであるかどうかを審査し、すべての関連団体がコンフィギュレーション管理委員
会の会議に代表を参加させているかどうかを確認することである。
また、システムエンジニアは、承認済みベースラインがそれを必要とする者すべてに適
時に伝えられているかどうかを確認する必要もある。その通告では、正式の変更管理下で
凍結されているものとコンフィギュレーション管理委員会の承認を得ずに決定できるもの
の区別について、プロジェクト・チームに知らせる。
コンフィギュレーション・コントロールは、契約者と NASA フィールドセンターの両レベ
ルにとって必要不可欠なものである。契約者にとってクラス 1 と判定された変更は、NASA
のプロジェクトマネジャに一任され、その承認を得なければならない。この手続きを図 19
に示す。審議される変更を事前に通告するために「予備」技術変更提案書（ECP＝Engineering
Change Proposal)を使用するので、プロジェクトマネジャは十分な予備情報を得た上で、
NASA の契約資金を契約者に使用させるべきかどうかを正式 ECP 上で決定することができる。
こうした技法は、契約価額を大幅に節約するためのものである。
クラス 1 の変更は、承認済みベースライン、ひいては製品バージョン識別番号にも影響
を及ぼす。クラス 2 の変更は編集上の変更であるか、外部インターフェースからは「見え
ない」内部変更である。クラス 2 の変更は、契約者側 CCB（コンフィギュレーション管理委
員会）で最終決定が出されるので、NASA 側プロジェクトマネジャの承認を必要としない。
余り堅苦しい手続きはわずらわしいものとなり、プロジェクト・チームのメンバーもそ
のような手続きを避けようとしがちである。各プロジェクトのニーズに合わせて変更手続
きの形式を調整することも重要である。しかし、どんなプロジェクトでも効果的なコンフ
ィギュレーション・コントロールが必要である。
ソフトウェア・プロジェクトでは、発表前と発表後の引き渡し可能システムに対してバ
ージョン管理を行うのが普通である。ハードウェアのみのシステムに対しても、バージョ
ン管理を続けることは重要である。
唯一の引き渡し可能アイテムを開発するプロジェクトの場合、承認済み変更はその唯一
の引き渡し可能アイテムのみに適用される。しかし、「同一」設計の引き渡し可能アイテム
を複数開発するプロジェクトの場合は、第 2 アイテム以降の生産アイテムに変更を加える
こともある。そのような場合、コンフィギュレーション管理委員会ではその変更の有効性
を判定しなければならず、コンフィギュレーション管理手続きにより各アイテムの「製品
完成状態」（"as-built）コンフィギュレーションのバージョン管理とバージョン識別を継
続しなければならない。製品や製法に対する周到な改良政策を備えたプロジェクトでは、
変更を漸進的に実施するのが普通である。たとえば、1972 年度のオリジナル計画ではスペ
- 85 -
ースシャトルの軌道船をすべて同一にする予定だったが、実際には軌道船をそれぞれ異な
った設計にしたという事例がある。その主な理由は、65,000 ポンドというオリジナル計画
のペイロード条件を達成したかったからである。そのため、実用フリートの予備品貯蔵、
現場作業、保全性にとっては、適正なバージョン管理文書が不可欠であった。
コンフィギュレーション検証
コンフィギュレーション検証とは、得られた製品（たとえばハードウェアアイテムやソ
フトウェアアイテム）が設計者の意図や、承認済みベースラインにより設定された規格に
適合しているかどうか、ベースライン文書が最新の正確なものであるかどうかを検証する
過程である。コンフィギュレーション検証は、監査と技術審査という 2 種類のコントロー
ル・ゲート作業により実施される。（2 つの重要な作業例の詳細については、第 4.8.4 項「物
理的コンフィギュレーション監査と設計確認審査」を参照）。この監査と技術審査の目的は、
提示されたデータを審査し、承認済みベースラインに対する適合性に疑問を呈することに
ある。
コンフィギュレーション・アカウンティング
コンフィギュレーション・アカウンティング（コンフィギュレーション状態アカウンテ
ィングともいう）とは、コンフィギュレーション・データの維持、相関化、公表、報告、
保管を行う業務である。特に、データ・マネジメントの一業務であるコンフィギュレーシ
ョン・アカウンティングでは、プロジェクトに使用される公式のベースライン・データが
保持されているか、利用可能か、その分配が管理されているかどうかなどを確認する。ま
た、提案から実施に至る各変更の状態を追跡調査するという重要な業務も実施する。プロ
ジェクトの変更状態システムは、独特の変更識別番号により各変更を識別し（たとえば ECR
（Engineering Change Request＝技術変更要求）、CR（Change Request＝変更要求）、RID
（Review Item Disposition ＝審査アイテム処置）、ウェーバー、デビエーション、モディ
フィケーションキットなど）、現在の変更状態を報告できるものとすべきである。
コンフィギュレーション・マネジャの役割
コンフィギュレーション・マネジャはこのような技法の適用を責務とし、以下の業務を
行う。
・
コンフィギュレーション・マネジメント・システムを立案かつ管理し、それをコン
フィギュレーション・マネジメント計画書に文書化する
・
コンフィギュレーション管理委員会（CCB）の書記を勤める（変更承認手続きをコン
トロールする）
・
ベースライン文書に加えた変更を管理する
・
ベースライン文書の公表を管理する
- 86 -
・
4.7.3
コンフィギュレーション検証監査を開始する
データ・マネジメント
いかなるプロジェクトでも、コンフィギュレーション・マネジメントをうまく行うには、
データマネジメントが不可欠である。プロジェクト・チームが有形（tangible）製品を生
産する前には、まず語句、図面、図表、番号（つまり記号情報）を使ってそのシステムの
説明書を作成しなければならない。このような記号情報に必要な主要特性はいくつかある。
第一に、この記号情報は「共通に使用できる」ものでなければならない。電子式のもので
あれ、紙に書かれたものであれ、そうしたデータは、プロジェクト・チームの全員が最新
の公認バージョンで容易に入手できるものでなければならない。
第二に、記号情報は「耐久性のある」ものでなければならない。つまり、いつでも正確
に読み出され、最新バージョンのベースラインを表わすものでなければならない。ベース
ライン情報は、データベースやペーパーファイルを何度使用しても変化や劣化することも
なく、また時間と共に劣化することもないものでなければならない。これは、決して軽視
されることではない。（たとえば誰かに文書や図面のコピーだけを貸す場合でも）データ・
マネジメント業務がずさんであると、管理されている情報が消失することもある。また、
そのような資料はプログラム／プロジェクト期間中（できればその後も）保管し、各ベー
スラインの変更に関する文書全部も保管しなければならない。
第三に、記号情報は上方へも下方へも「たどれる」ものでなければならない。何らかの
要求の出所を示すためには、データベースを作成して保管しておかなければならない。ま
た、データベースは、所定の要求から派生したあらゆる事項も表示できるものでなければ
ならない。最後に、要求事項のフローダウンにおいて重要な役割を果たしたトレードオフ
研究結果やその他の決定事項を文書化した報告書にも、トレーサビリティ（追跡可能性）
を付与しなければならない。したがって、データ・マネジメント業務には、裏付け解析結
果やトレード研究データを保管し、コンフィギュレーション・マネジメントやプロジェク
ト全般にそれらを使用しやすいようにしておくことも含まれる。
4.8
審査、監査、コントロール・ゲート
審査、監査、コントロール・ゲートの目的と基本方針は、フェーズ A において設定し、
プログラム／プロジェクト計画書の中に明記しておく必要がある。この作業は、本項で述
べる審査や監査の種類に適合するだけでなく、NASA プログラム／プロジェクト・ライフサ
イクルチャート（図 5 を参照）や NASA プログラム／プロジェクト・ライフサイクル・プロ
セスフローチャート（図 8 を参照）にも適合したものでなければならない。しかし、審査、
監査、コントロール・ゲートの時期は、各特定プロジェクトに応じて調整すべきである。
- 87 -
4.8.1
目的と定義
「審査」の目的は、最も満足できる方法、計画、設計が選定されていること、特定の要
求に適合したコンフィギュレーションアイテムが生産されていること、あるいはコンフィ
ギュレーションアイテムの運用準備が整っていることを NASA マネジメント部門とその契約
者に保証するための審議の場と手続きを提供することにある。審査（技術審査またはマネ
ジメント審査）のスケジュールは、何らかの方法を伝えたり、要求を満たせる能力を実証
したり、状態を確認したりできるように設定される。審査は、業務やプロジェクト参加者
の間の相互理解を深め、コミュニケーションの経路を開き、参加者とマネジャに問題を指
摘し、問題解決への道を開くための一助ともなる。
「監査」の目的は、NASA マネジメント部門とその契約者がプログラム／プロジェクトの
方針書、計画書、要求書、仕様書を順守しているかどうかを徹底的に検査することである。
監査は、審査中の作業や文書の妥当性、有効性、効果を示す有形証拠物件の組織的な検査
である。監査では、方針書や要領書を検査すると共に、それらの順守状態を検証すること
もある。
「コントロール・ゲート」の目的は、NASA マネジメント部門がプログラムやプロジェク
トの進行／停止（go/no-go）決定を下す際に採用する予定業務（審査または監査）を決め
ることである。コントロール・ゲートは、プロジェクト・ライフサイクルにおける一つの
マネジメント業務で、特定かつ明確化してプロジェクト・スケジュールに盛り込むべき重
要な業務である。プログラム／プロジェクト計画書に従って次のマネジメント業務へ進む
には、プロジェクトの状態を評価し、承認を得るための正式審査が必要になる。
プロジェクトの停止
プロジェクトの停止は、通常プロジェクト関係者を失望させる措置だが、外部条件の変
化や、システムのコスト・効果予測に関する理解向上に対する適切な措置ともなりうる点
に留意すべきである。
- 88 -
4.8.2
審査の一般原則
審査委員会
通常、委員会（Review Board）の委員長を任命するのは、審査される作業マネジャを監
督する委員会召集当局である。特別の技術的理由がない限り、委員長は審査中のプロジェ
クトや業務に直接関係のある者でなくてもよい。委員会召集当局は、審査委員会のメンバ
ーも指名する。委員の大半は、審査中のプログラムやプロジェクトに直接関係のある者で
なくてもよい。
内部審査
プロジェクトや業務の実施中には、グループ内で技術方法、トレード研究、問題領域な
どを提示し、メンバーの評価と意見を受けるという内部審査を実施する必要もある。この
ような内部審査の内容、時期、参加者は、通常プロジェクトマネジャまたは実施団体のマ
ネジャが決定する。コントロール・ゲートの正式審査に参加する前にも、内部審査が実施
される。
内部審査は、プロジェクトの技術的進捗状態を管理するための優れた手段となる。また、
すべての関係者が設計や開発過程の初期やその過程全体に参加しているかどうかを確認す
る場合も、内部審査を実施すべきである。したがって、製造部門や品質保証部門などの代
表者は、積極的に内部審査に参加すべきである。それによって、たとえば、設計が生産可
能なものか、プロジェクト・ライフサイクル全体を通して品質管理が行われているかとい
った点も確認できる。
さらに、「レッドチーム」（Red Team）を採用する団体もある。これは、提案要請書、提
案書、提案回答書、文書、プレゼンテーション資料にある何らかの欠陥をその公表前に指
摘するために実施するチーム内の独立審査である。プロジェクトマネジャまたは作業マネ
ジャは、レッドチームのメンバーを任命し、その推奨事項を実施すべきかどうか決定する
責務を負う。
審査用プレゼンテーション資料
仕様書、図面、解析書、報告書などの既成文書を使用してのプレゼンテーションで十分
事足りる場合もある。審査委員会や会議の出席者には、作成資料のコピー（表示グラフな
ど）を配布すべきである。委員に提供する予備情報や審査用プレゼンテーション資料は、
審査前に検討できるように早期に委員に配布すべきである。重要な審査の場合は、暦日で
審査の 30 日前に配布することもできる。
審査の運営
すべての審査では、適用できるプロジェクト要求事項と、これらの要求事項を満たす方
- 89 -
法、計画、設計を口頭で提示する。このプレゼンテーションは、普通、審査担当の設計技
術者かその直属の部下が実施する。
審査の参加者には、審査委員会のメンバーの他に、審査される設計に直接関係のないプ
ロジェクト関係者（NASA と契約者）も含めることを大いに推奨したい。設計の欠点を指摘
したり、設計の改良を勧告したりするには、このように他分野の専門知識を活用する必要
がある。審査の参加者としては、プロジェクトに参画していない審査領域の専門家や、生
産／製造、試験、品質保証、信頼性、安全性などの専門家も含めるべきである。また、審
査によっては、契約者と NASA の契約担当役員の参加が求められる場合もある。
審査前と審査中には、審査委員会のメンバーとその他審査参加者が、提示された方法、
計画、設計に関する問題点や推奨改良点を記載した対策要求書や技術変更要求書（ECR＝
Engineering Change Request）を提出することもできる。審査後、この要求書は審査委員
会により選別されて統合整理され、委員長と審査担当マネジャが要求書の真意を理解でき
るように編集される。各対策要求書に対する適切な最終回答書を得ることも、審査委員会
の責務である。
審査後報告
審査委員会の委員長は、必要に応じて、問題領域に関係のあるリスク評価も含め、委員
会の審査結果に対する合意を得るべく努力し、対策勧告書を作成する責任がある。委員長
は、適時に、対策勧告を記載した報告書を委員会召集当局に提出し、その写しを審査担当
マネジャにも提出する。
常設審査委員会
高レベルの作業、可視性、資源要求事項を必要とするプロジェクトや業務に関しては、
常任審査委員会が設立される。この委員会のメンバーは、委員会召集当局が選定するが、
通常は現場センターの上級技術者と上級マネジャによって構成される。情況しだいでは、
補助委員や顧問が委員会に加わることもある。プロジェクト期間後も審査委員会が必要な
場合は、委員を余分に選定し、ニーズを満たせるように実働委員を回転させるのが望まし
い。
- 90 -
4.8.3
主なコントロール・ゲート
この項では、NASA プロジェクトのライフサイクルにおける主なコントロール・ゲートの
意図、時期、目的、審査合格基準、結果について説明する。この情報は、プロジェクトマ
ネジャとシステムエンジニアに指針を与えると共に、審査作業とシステムエンジニアリン
グの成果を漸進的に成熟化させる手続きについて説明するものである。以下に列記するチ
ェックリストは、特定の審査の開始、完了の (entry and exit)基準の作成を助けるもので
はあるが、それに代わるものではない。余分な業務をできるだけ少なくするために、審査
用資料はプロジェクト文書に合わせて調整すべきである。
ミッション概念審査
意図
−
ミッション概念審査（MCR＝Mission Concept Review）では、ミッションのニ
ーズを確認し、提案されたミッションの目的と、その目的を達成するための概念を審査す
る。審査を行う NASA フィールドセンターでは、通常内部審査を実施する。
時期
−
ミッションの実現性研究の完了間近。
目的
−
審査の目的は次のとおりである。
・
ミッションの目的が完全なもので、理解できるものであるかどうかを実証する
・
ミッション概念が、ミッションの目的を達成できるという技術的及び計画的実現性
を実証するものであるかどうかを確認する
・
顧客のミッションニーズが明確で、達成可能なものかどうかを確認する
・
その後のミッション解析向けに評価基準の優先順位表が作成されているかどうかを
確認する
審査合格基準
−
以下のすべての項は、ミッション概念審査（MCR）による文書作成準
備を判定するための一助となるチェックリストである。
・
ミッションの目的は明確に設定かつ明記されているか？
それらはあいまいなもの
ではなく、一貫性のあるものか？
・
一連の予備要求事項を満たせば、ミッションの目的を達成するシステムが得られる
のか？
・
ミッションは実現可能なものか？
いるか？
・
技術的に実施可能な解決策がすでに特定されて
その概算予測コストは許容範囲内のものか？
システム評価案に採用する概念評価基準はすでに特定され、優先順位表が作成され
ているか？
・
ミッションの必要性は明確に特定されているか？
・
コスト予測とスケジュール予測は信頼できるものか？
・
ミッションまたはミッション各部の実施を可能にする現存資産または既成製品を特
定する技術探索は実施したか？
- 91 -
審査の結果
−
ミッション概念審査（MCR）に合格すれば、ミッション概念案が顧客の
ニーズを満たしているという根拠が得られ、フェーズ A の作業としてその後の研究を NASA
プログラム担当副局長（PAA＝NASA Program Associate Administrator）に提案するための
フィールドセンター・マネジメント部門の決定を裏づけるのに十分な品質とメリットを有
するという判定を下す根拠が得られる。
ミッション定義審査
意図
−
ミッション定義審査（MDR＝Mission Definition Review)では、システムと予
備プログラム／プロジェクト計画書のために設定した機能および性能要求事項を審査し、
それらの要求事項と選定ずみアーキテクチャ／設計がミッションの目的を満たすものかど
うかを確認する。
時期
−
ミッション定義段階の完了間近。
目的
−
審査の目的は次のとおりである。
・ システム機能要求事項の配分が、要求事項のトレードオフと内部 MCR(Mission Concept
Review ＝ミッション概念審査）で設定した評価基準の面でミッションの目的を満た
す最適なものであるかどうかを確認する
・
システム要求事項がミッションの目的を達成できるものかどうかを検証する
・
技術リスクとそのリスクの軽減化計画を特定する
・
コスト、スケジュール、人的資源の改良ずみ予測を提示する
審査合格基準
−
以下のすべての項目は、ミッション定義審査（MDR）による文書の作
成準備を判定するための一助となるチェックリストである。
・
設定されたシステム要求事項は、プログラム／プロジェクトの開始時に提示された
ミッションの目的を満たすものか？
・ システム・レベルの要求事項は完全で一貫性があり、しかも検証可能なものか？
低
レベルに対する予備配分はすでに実施したか？
・
要求事項のトレードは、一連の最適システム要求事項に集中したものか？
トレー
ドは、プログラム／プロジェクトのコストとスケジュール上の制約ならびにミッシ
ョンの技術的ニーズを対象としたものか？
いるのか？
トレードでは、広範な選択肢を持って
このような一連の作業を対象としたトレードを実施したか？
システ
ムの最終設計を選定するために、残りのトレードも特定したか？
・
システム PBS（Product Breakdown Structure ＝製品明細構成）の高レベルは完全に
定義されているか？
・
トレードの結果行った決定は、MCR（Mission Concept Review＝ミッション概念審査）
で設定した評価基準に適合しているか？
・
最適最終設計は少数の設計案にまで取捨選択がなされたものか？
・
技術リスクを特定し、その軽減化計画を策定したか？
- 92 -
審査の結果
−
ミッション定義審査（MDR）に合格すれば、システムのアーキテクチャ
や設計とミッションの実施に必要な技術等をさらに開発する決定を下す一つの根拠が得ら
れる。この審査結果はミッションのメリットを高め、システム調達戦略の基盤となる。
システム定義審査
意図
−
システム定義審査（SDR＝System Definition Review）では、システムのアー
キテクチャ案や設計案とシステムのあらゆる機能要素に対するフローダウンを審査する。
時期
−
システム定義段階の完了間近。つまり、システム要求事項の解析・配分作業
の最終段階である。
目的
・
−
システム定義審査（SDR）の目的は、次のとおりである。
システムのアーキテクチャや設計が許容し得るものか、その要求事項の配分が完全
なものか、ミッションの目的を達成するシステムを特定の制約の下で完成できるも
のかどうかを実証する
・
検証概念と予備検証計画が設定されているかどうかを確認する
・
エンドアイテムの合格基準を確定する
・
その後の開発作業や取得作業を開始するための詳細な情報が十分存在するかどうか
を確認する
審査合格基準
−
以下のすべての項目は、システム定義審査（SDR）による文書作成準
備を判定するための一助となるチェックリストである。
・
選定されたトップレベルのシステム設計は、システム要求事項に適合し、ミッショ
ンの目的を達成し、運用ニーズに対処し得るものか？
・
選定されたトップレベルのシステム設計は、コスト面の制約の下で適時に製作しう
るものか？
コスト予測とスケジュール予測は、システム要求事項と選定ずみアー
キテクチャの視点から有効なものか？
・ システム・レベルの要求事項は、1 つまたは 2 つ以上の低レベルまで配分されている
か？
・
エレメントとサブシステムに関する主要設計問題がすでに特定されているか？
主
要リスク領域とその軽減化計画はすでに特定されているか？
・
開発・設計プロセスの管理（コントロール）計画はすでに策定されているか？
・
開発検証／試験計画書は、情報を得て設計上の決定を行うためのデータを提供する
のに適したものか？
・
最終アイテム製品の最低性能は合格基準として文書化されているか？
・
提案業務を支援する十分な情報があるか？
コスト予測とスケジュール予測を支援
するのに必要なシステム定義のための一連の検証ずみ要求事項がすべて設定されて
いるか？
審査の結果
−
システム定義審査（SDR）に合格すれば、システムとその運用が十分解
- 93 -
明され、最終アイテムの設計と取得が保証されたことになる。システムとそのセグメント
の承認ずみ仕様書ならびに適切な機能要素の設計に関する予備仕様書を公表することがで
きるようになる。また、設計と要求事項の変更を管理（コントロール）するために、コン
フィギュレーション・マネジメント計画書も作成される。拡張された技術プロセスを管理、
統合化する計画書も作成される。
基本設計審査
基本設計審査（PDR＝Preliminary Design Review)は単一の審査ではなく、システム PDR
と特定のコンフィギュレーションアイテム（CI＝Configuration Item）に対する PDR も含
めた多数の審査からなる。
意図
−
基本設計審査（PDR）では、基本設計がすべてのシステム要求事項に適合し、
リスクも許容し得るものかどうかを実証する。この審査では、適正な設計案が選定され、
そのインターフェースも特定され、検証方法も十分説明されているかどうかを示す。また、
詳細設計を継続するための条件も設定する。
時期
−
機能設計完了後。
目的
−
基本設計審査（PDR）の目的は、次のとおりである。
・
すべてのシステム要求事項が完全なもので、すでに配分されており、そのフローダ
ウンがシステムの性能検証に十分適したものかどうかを確認する
・
提案された基本設計案がコンフィギュレーションアイテム（CI）レベルの機能およ
び性能要求事項を満たす見込みがあるかどうかを示す
・
予定設計方法が最終設計に着手できるくらい十分成熟したものかどうかを示す
・
設計が検証可能なものか、そのリスクの識別、特性表示、必要な軽減化が行われて
いるかどうかを示す。
審査合格基準
−
以下のすべての項目は、基本設計審査（PDR）による文書作成準備
を判定するための一助となるチェックリストである。
・
提案された基本設計案は、予定のコストとスケジュールの下ですべての要求事項を
満たす見込みがあるか？
・
すべての外部インターフェースがすでに特定されているか？
・
システムとセグメントのすべての要求事項が CI レベルまで配分されているか？
・
すべての CI "design-to" 仕様書が完全なもので、正式承認と公表の準備が完了して
いるか？
・
許容し得る運用概念がすでに開発されているか？
・
提案された基本設計案は、人的安全性とミッションの成功に欠かせない各種要求事
項を満たしているか？
・
基本設計案の人間工学的配慮は、予定末端ユーザーによるシステムの運用とミッシ
ョンの効果的実施を支援するものか？
- 94 -
・
生産組織、検証組織、運用組織、その他専門技術団体は、すでに基本設計を審査し
たか？
・
提案された基本設計案は生産可能なものか？
リードタイムの長いアイテムも検討
ずみか？
・
専門技術計画立案書と専門工学設計仕様書は、設計技術者が設計を行うために必要
な指針、制約、システム要求事項を十分提示しているか？
・
信頼性解析は健全な方法に基づいたもので、実情に即したロジスティックス計画と
ライフサイクル・コスト分析を見越したものか？
・
プロジェクトの準備金とスケジュールの余裕は、プロジェクトをさらに続行するの
に十分なものか？
審査の結果
−
基本設計審査（PDR）に合格すれば、"design-to" ベースラインが承認
される。また、プロジェクトを最終設計へ移行させる認可が下りる。
詳細設計審査
詳細設計審査（CDR＝Critical Design Review）は単一の審査ではなく、特定のコンフィ
ギュレーションアイテム（IC＝Configuration Item）の審査から詳細設計審査（CDR）に至
る多くの審査である。
意図
−
詳細設計審査（CDR）では、システム設計全体を詳細に開示し、技術的問題と
設計の異常が解消されているかどうかを確認し、ミッションのハードウェアとソフトウェ
アの組立／製造、統合化、検証を開始する決定を下せるくらい設計が十分成熟しているか
どうかを確認する。
時期
−
最終設計段階の完了間近。
目的
−
詳細設計審査（CDR）の目的は次のとおりである。
・
機能・性能要求事項を満たすハードウェアとソフトウェアの詳細仕様書が、
"build-to"ベースラインに含まれているかどうかを確認する
・
生産組織、検証組織、運用組織、その他専門技術組織により最終設計が十分監査さ
れているかどうかを確認する
・
生産プロセスとコントロールが製造段階へ移行できるほど十分なものかどうかを確
認する
・
予定の品質保証（QA）作業により、高品質製品の生産に必要な知覚力のある検証プ
ロセスとスクリーニングプロセスを確立できるかどうかを確認する
・
最終設計が基本設計審査（PDR）で確定された仕様に適合するかどうかを検証する
審査合格基準
−
以下のすべての項目は、詳細設計審査（CDR）による文書作成準備を
判定するための一助となるチェックリストである。
・
提案された最終設計案は、予定のコストとスケジュールの下ですべての要求事項を
満たす見込みがあるか？
- 95 -
・
最終設計は完全なものか？
図面は生産開始のために準備できているか？
ソフト
ウェア製品の定義は、コード化を開始できるほど十分成熟したものか？
・
"build-to"ベースラインは、無関係の要求事項がないことを確認できるくらい十分
追跡できるものか？
・
ソフトウェア原型アイテムおよびエンジニアリングアイテムの試験、シミュレーシ
ョン、解析等から得られた最終設計認定試験結果は、システムが要求事項を満たす
という推断を裏づけるものか？
・
すべての内部インターフェースは完全に定義され、相互に適合するものか？
外部
インターフェースは最新型のものか？
・
総合的安全解析は完全なものか？
その安全解析結果は、特定されたハザードがす
でに抑制されていること、もしくは抑制できずに残されたリスクが関係当局により
見送られたことを示すものか？
・
生産計画書は適切で妥当なものか？
・
生産工程には十分な品質検査点があるか？
・
ロジスティックス支援解析は、総合的ロジスティックス支援資源の要求事項を十分
識別できるものか？
・
総合的システム統合化・検証計画は完全なものか？
審査の結果
−
詳細設計審査（CDR）に合格すれば、"build-to"ベースライン、生産計
画書、検証計画書が承認される。承認ずみ図面は公表され、製造用として認可される。ま
た、引き渡し可能ソフトウェアのコード化（審査で提示された"build-to"ベースラインと
コード化規格に従ったもの）ならびにシステムの認定試験と統合化も認可される。すべて
の未解決問題は、最終対策とスケジュールにより解決すべきである。
システム受領審査
意図
−
システム受領審査（SAR＝System Acceptance Review）では、システムとその
エンドアイテムおよび文書、さらに検証に必要な試験データと解析結果を審査する。また、
射場や予定の運用施設まで出荷して設置する認可を下せるほど、システムが技術的に十分
成熟しているかどうかも確認する。
時期
−
システム製造・統合化段階の完了間近。
目的
−
システム受領審査（SAR）の目的は次のとおりである。
・
DD-250 の下でシステムの受渡しを行う準備が整っているかどうかを確認する
・
システムが、システム定義審査（SDR）で確定された受領基準に適合しているかどう
かを確認する
・
システムが要求事項を満たし、試験データ、実証試験結果、解析結果に示されてい
るように予定運用環境内で適正に機能するものであるかどうかを確認する
・
完成状態（as-built）のシステムの機能上や運用上の制約が理解されているか、シ
- 96 -
ステムと一緒に引き渡される文書が完全かつ最新のものであるかどうかを確認する
審査合格基準
−
以下のすべての項目は、システム受領審査（SAR）による文書作成準
備を判定するための一助となるチェックリストである。
・
試験と解析は完全なものか？
その試験と解析では、システムが予定の運用環境内
で適正に機能することを示しているか？
・
システムは受領納計画書に記載された判定基準に適合しているか？
・
システムの引き渡し準備は整っているか？（飛行アイテムは射場に、非飛行アイテ
ムは予定運用施設に引き渡して設置する）。
・
システム文書は完全で正確なものか？
・
そのシステムは確かに購入予定のものか？
審査の結果
−
システム受領審査に合格すれば、システムは買い手により受領され、
射場や運用施設へハードウェアを出荷し、ソフトウェアとハードウェアを運用向けに設置
する認可が下される。
飛行準備審査
意図
−
飛行準備審査（FRR＝Flight Readiness Review)では、システムの安全な打ち
上げ成功とその後のフライトオペレーションの準備が整っているかどうかを判定する試験、
実証試験、解析、監査を審査する。また、すべての飛行用と地上用ハードウェア、ソフト
ウェア、要員、要領書の運用準備が整っているかどうかも確認する。
時期
−
システムの打ち上げコンフィギュレーション完了後。
目的
−
飛行準備審査（FRR）の目的は次のとおりである。
・
フライトオペレーションを許容範囲内のリスクで安全に実施できるという認証を受
ける。
・
システムと支援エレメントのコンフィギュレーションが適正に実施され、打ち上げ
準備が整っているかどうかを確認する。
・ すべてのインターフェースが相互に適合し、予定通り機能するかどうかを確認する。
・ システムの状態が、進行／停止（go/no-go）基準に基づく打ち上げ「進行」（go）決
定を裏づけるものかどうかを確認する。
審査合格基準
−
以下のすべての項目は、飛行準備審査（FRR）による文書作成準備を
判定するための一助となるチェックリストである。
・
打ち上げロケットは発射準備が整っているか？
・
宇宙船のハードウェアは、安全な打ち上げと飛行の準備が整い、ミッションを成功
させる確率が高いか？
・
すべての飛行用および地上用ソフトウェア・エレメントは、打ち上げとフライトオ
ペレーションを支援する準備が整っているか？
・
すべてのインターフェースは点検され、良好に機能することが確認されているか？
- 97 -
・ すべての未決定アイテムとウェーバーは審査され、許容し得るものと判定されたか？
・
打ち上げと回収の環境要因は制約範囲内のものか？
審査の結果
−
飛行準備審査（FRR）に合格すれば、技術上と手続き上の成熟度はシス
テムの打ち上げ・飛行認可や場合によってはシステム運用開始に必要となるレベルに達し
ていることになる。
運用準備審査
意図
−
運用準備審査（ORR＝Operational Readiness Review）では、システムの実特
性とシステム運用要領書を審査し、すべての飛行用および地上用ハードウェア、ソフトウ
ェア、要員、要領書、ユーザー用文書がシステムの配備状態を正確に反映させたものかど
うかを確認する。
時期
−
システムとその運用・支援設備および要員が、ミッション開始準備を完了し
−
運用準備審査（ORR）の目的は次のとおりである。
た時。
目的
・
利用できる地上・飛行試験結果、解析結果、運用実証試験結果により、運用モード
へ移行するシステムの準備が整っているかどうかを確認する
・
あらゆる運用・支援モード（正規、緊急、計画外）も考慮して、システムの運用支
援とロジスィックス支援が十分行われているかどうかを確認する
・
運用文書が完全なもので、システムのコンフィギュレーションとその予定運用モー
ドを示しているかどうかを確認する
・
トレーニング業務が適切で、システムの保守整備、準備、運用、回収というあらゆ
る面を支援できることを実証ずみのものであるかどうかを確認する
審査合格基準
−
以下のすべての項目は、運用準備審査（ORR）による文書作成準備を
判定するための一助となるチェックリストである。
・
システムのハードウェア、ソフトウェア、要員、要領書は、運用支援に適するもの
か？
・
打ち上げ前、打ち上げ時、軌道飛行中に検出された異常はすべて解消され、文書化
されて既成の運用支援データに導入されたか？
・
システムを飛行試験から運用コンフィギュレーションへ移行させる場合に、必要と
なる変更を加える準備が整っているか？
・
すべてのウェーバーは解決しているか？
・
運用期間中のシステムを支援するすべての経営資源は適切なものか、つまりその財
政計画が策定され、承認されているか？
審査の結果
−
運用準備審査（ORR）に合格すれば、システムは正規運用の準備が整い、
打ち上げやフライトオペレーションによるいかなる潜在的ハザートも、冗長型設計や運用
要領書の変更により解消されたことになる。
- 98 -
デコミッショニング審査
意図
−
デコミッショニング審査（DR＝Decommissioning Review）では、デコミッシ
ョニングの理由に根拠があり、適切なものであるかどうかを確認すると共に、システムの
現状と廃棄計画を審査する。
時期
−
システム内部の主要アイテムがミッションの実施にもはや不要となった時。
目的
−
デコミッショニング審査（DR）の目的は次のとおりである。
・
ミッションやシステムの状態からデコミッショニング／廃棄が必要かどうかを確認
する。その可能性としては、ミッションの必要性がもはや無い、システム要素が破
損または劣化した、アップグレードが近いため現在のシステム資産の使用を段階的
に停止するなどの場合が考えられる
・
デコミッショニング、廃棄、転用などの計画が適正で、現状に即し、環境上の制約
やシステム・コンフィギュレーションに適しているかどうかを実証する
・
廃棄計画に使用される資源が適切かどうかを確認する
・
ミッションとプロジェクトに関する主要データの保管計画が確立されているかどう
かを確認する
審査合格基準
−
以下のすべての項目は、デコミッショニング審査（DR）による文書
作成準備を判定するための一助となるチェックリストである。
・
デコミッショニング／廃棄理由は、十分文書化されているか？
・
策定された処分計画は、地方、州、連邦の環境規制に準拠したものか？
・
廃棄計画では、既成ハードウェア、ソフトウェア、施設、プロセスの廃棄を扱って
いるか？
・
廃棄上のリスク問題を扱っているか？
・
データ保管計画が策定されているか？
・
廃棄計画の実施に十分な資源を利用できるか？
・
要員移転計画は適切なものか？
審査の結果
−
デコミッショニング審査（DR）に合格すると、システムアイテムとそ
の工程のデコミッショニングと廃棄が適切かつ効果的なものであることが保証される。
4.8.4
中間審査
中間審査を実施する理由は、計画上や NASA 本部のマイルストーンを主要審査だけでは必
ずしもカバーし切れないためである。この中間審査は、多数の審査手続きからなる場合が
多く、NASA の主要審査、計画上の決定、売買契約の履行義務などにとって重要な情報を提
供する。プログラム／プロジェクトを調整すると、これらの中間審査が必要となり、その
スケジュールも作成される。
- 99 -
要求審査
基本設計審査（PDR＝Preliminary Design Review)の前には、ミッションとシステムに関
する要求事項の解析、配分、検証を徹底的に実施し、プロジェクトがミッションの必要性
を十分理解し、その必要性を満たしうるものかどうかを確認しなければならない。中間要
求審査では、特に以下の点を確認する。
・
提案されたプロジェクト案が特定の NASA プログラムの欠陥を補足するものかどう
か。
・
プログラムの実施では、局内または産業界主導の作業を採用すべきかどうか。
・
提出された要求が目的に適合しているかどうか。
・
その要求がしかるべき解決策となるかどうか。
・
概念的方式とアーキテクチャが確実に実現可能で、余裕のあるものがどうか。
このような問題と要求の不明確さを解消するか、何らかの解決策を講じる必要がある。
中間要求審査には、ライフサイクルの先々まで考慮した過剰設計と過剰解析の重荷を軽減
化する利点がある。
安全性審査
安全性審査は、NHB（NASA Handbook ＝NASA ハンドブック）1700.1B 「NASA の安全政策・
要求書」（NASA Safety Policy and Requirements Document）を順守させるために実施し、
システム安全マネジャの勧告に基づいてプログラム／プロジェクトマネジャが承認する。
その意図、目的、一般スケジュールは、適切な安全管理計画書に記載される。安全性審査
では、システムの組み立て、試験、運用、支援関係の潜在的ハザードを扱う。核物質やそ
の他有毒物質の使用による運用上および環境上のハザードに対しては、特別の配慮を払う。
（第 6.8 項を参照）。現場センターの安全要員による初期審査では、問題領域を特定かつ解
明し、その問題を解消するための要求事項を指定すべきである。
ソフトウェア審査
ソフトウェア審査は、ソフトウェア仕様書と関連文書をプログラム／プロジェクト関係
者とユーザー側関係者に十分理解させるために実施し、プログラム／プロジェクトマネジ
ャがそのスケジュールを作成する。開発サイクル全体にわたって、引き渡される生産アイ
テムとコンピュータソフトウェア・コンフィギュレーションアイテム（CSCI＝Computer
Soft-ware Configuration Item）の系統、成熟度、限界点、スケジュールは、プロジェク
トの技術組織、運用組織、検証組織すべてにとって極めて重要な情報である。
- 100 -
準備審査
準備審査は、プログラム／プロジェクトの重要な経営資源がリスクを負うような重大事
象が起こらないうちに実施する。この審査では、リスク環境を定義し、その環境内で十分
運用できるかどうかを審査する。
ミッション要求審査
意図
−
ミッション要求審査（MRR＝Mission Requirements Review)では、トップレベ
ルの要求解析結果を審査してその正当性を立証すると共に、外部審査に対する準備態勢を
評価する。
時期
−
ミッション定義段階におけるミッション要求事項の成熟後（必要に応じて）
実施する。
目的
−
この審査の目的は次のとおりである。
・
ミッション概念が顧客のニーズを満たすものかどうかを確認する
・
ミッション要求事項が、リードタイムの長い外部支援要求事項（たとえば、国防総
省、国際機関、施設の資源など）の識別を支援するものかどうかを確認する
・
解析結果が、フェーズ B 予備承認パッケージの作成を十分支援するものかどうかを
判定する
審査合格基準
−
以下のすべての項目は、ミッション要求審査（MRR）による文書作成
準備を判定するための一助となるチェックリストである。
・
トップレベルのミッション要求事項は、ミッションの目的を測定可能パラメータで
表記できるくらい十分明確化されたものか？想定と制約は定義され、定量化されて
いるか？
・
ミッション概念と運用概念は、エンジニアリング・マスタープラン／スケジュール
書（Engineering Master Plan/Schedule）、フェーズ B プロジェクト定義計画書（Phase
B Project Definition Plan)、技術評価書、初期のフェーズ B／C／D 資源要求書、
取得戦略立案書などの予備プログラム／プロジェクト文書の作成を十分支援するも
のか？
・
評価基準は十分定義されているか？
・
効果（effectiveness)評価値が設定されているか？
・
開発コスト予測値とライフサイクル・コスト予測値は実情に即したものか？
・
高リスク・高コスト要因となる特定の要求事項も特定され、それらを解消または軽
減する各種対策案も記載されているか？
審査の結果
−
ミ ッ シ ョ ン 要 求 審 査 （ MRR ） に 合 格 す る と 、 予 備 非 支 持 者 審 査
（ Preliminary Non-Advocate Review) と ミ ッ シ ョ ン ニ ー ズ 報 告 書 （ Mission Needs
Statement）提出に必要な情報を提示して承認を得るという保証が与えられる。
- 101 -
システム要求審査
意図
−
システム要求審査（SRR＝System Requirements Review）では、製品開発チー
ムがミッションとシステム・レベルの要求事項を理解しているかどうかを判定する。
時期
−
チーム結成後（必要に応じて）実施する。
目的
−
この審査の目的は次のとおりである。
・
システム・レベルの要求事項がミッションの目的に適合しているかどうかを確認す
る
・
システムのシステム・レベル仕様がプロジェクトの目的に十分適合しているかどう
かを確認する
審査合格基準
−
以下のすべての項目は、システム要求審査（SRR）による文書作成準
備を判定するための一助となるチェックリストである。
・
システム仕様書に記載された配分方法はミッションの目的に十分適合したものか？
・
実情に即した評価基準が設定されているか？
・
実情に則した効果評価値が設定されているか？
・
実情に即したコスト予測値が設定されているか？
・
システム検証概念はすでに定義されているか？
・
システム開発マイルストーン案を支援する適切な計画が開始される予定か？
・
技術開発問題とその解決方法は特定されているか？
審査の結果
−
システム要求審査（SRR）に合格すると、プログラム／プロジェクト要
求事項は凍結され、審査担当のプログラム担当副局長（PAA＝Program Associate
Administrator)により正式決定が下され、プロジェクト実施に関する提案要求書の作成が
続行される。
システム安全性審査
意図
−
システム安全性審査（SSR＝System Safety Review）では、安全ハザードを早
期に特定し、そのハサード関係のリスク解消、削減、抑制対策が特定され、コスト効果の
ある方法で適時に実施されているかどうかを確認する。
時期
−
プロジェクト・サイクルの多くのフェーズで（必要に応じて）実施する。
目的
−
この審査の目的は次のとおりである。
・
安全性の視点から重要とみなされるアイテムを特定する
・
リスクとハザードを軽減または解消する各種対策案や推奨案を評価する
・
各種軽減／解消方法を検証できるかどうかを確認する
審査合格基準
−
以下のすべての項目は、システム安全性審査（SSR）による文書作成
準備を判定するための一助となるチェックリストである。
・
必要に応じてリスクの識別、特性表示、定量化が実施されているか？
・
意味の有るリスクを軽減する必要がある場合に、各種設計案や要領書案の解析と定
- 102 -
量化が実施されているか？
・
採用候補案に対する検証方法はすでに明確化されているか？
審査の結果
−
システム安全性審査（SSR）に合格すると、設計案と運用モード案に伴
うハザートとその原因ならびにそれらのハザードの解消・削減・抑制の特定の対策が識別
される。基本設計検査（PDR＝Preliminary Design Review)の前に安全性検証方法も明確化
される。詳細設計審査（CDR＝Critical Design Review）では、安全性ベースラインが設定
される。
ソフトウェア仕様審査
意図
−
ソフトウェア仕様審査（SoSR＝Software Specification Review)では、一連
のソフトウェア仕様が基本設計作業を支援できるくらい十分成熟したものかどうかを確認
する。
時期
−
目的−
・
基本設計開始直後に実施する。
この審査の目的は次のとおりである。
システム仕様に基づくすべてのソフトウェア要求事項が、各種コンピュータソフト
ウェアコンフィギュレーションアイテム（CSCI＝Computer Soft-ware Configuration
Item)に配分され、適切なソフトウェア仕様書に記載されているかどうかを検証する
・
各 CSCI に関する一連の機能、性能、インターフェース、検証要求事項すべてがすで
に開発されているかどうかを検証する
・
一連のソフトウェア要求事項が完全で、理解し得るものかどうかを確認する
審査合格基準
−
以下のすべての項目は、ソフトウェア仕様審査（SoSR）による文書
作成準備を判定するための一助となるチェックリストである。
・
CSCI の機能説明は完全かつ明確なものか？
・
ソフトウェア要求事項は、システム仕様までたどれるものか？
・
CSCI の性能要求事項は完全かつ明確なものか？
実行時間と保存に関する要求事項
は実情に即したものか？
・
CSCI 間の制御とデータの流れは定義されているか？
・
ソフトウェアとソフトウェア間およびソフトウェアとハードウェア間のインターフ
ェースはすべて定義されているか？
・ システムとその関連運用・支援環境のミッション要求事項は定義されているか？
マ
イルストーン・スケジュールと特殊引き渡し要求事項は、交渉により決定された完
全なものか？
・
CSCI 仕様は、設計上の制約、規格、品質保証、試験可能性、引き渡し準備の点で完
全なものか？
審査の結果
−
ソフトウェア仕様審査（SoSR）に合格すると、ソフトウェア開発要求
書とソフトウェア開発指針書に基づいて作成されたソフトウェア仕様書が発行され、基本
- 103 -
設計作業が開始される。
試験準備審査
意図
−
試験準備審査（TRR＝Test Readiness Review)では、試験項目のハードウェア
／ソフトウェア、試験施設、地上支援要員、試験要領書が、試験、データ収集、削減化、
管理（コントロール）のための準備を完了しているかどうかを確認する。
時期
−
正式試験開始前に実施する。試験準備審査（TRR）では、コンフィギュレーシ
ョンアイテム（CI＝Configuration Item）、サブシステム、システムの予定検証（認定およ
び受納）試験を続行するかどうかを決定する意思決定点を設定する。
目的
−
この審査の目的は次のとおりである。
・
所定試験計画が検証要求書と仕様書に適合しているかどうかを確認する
・
試験作業に十分な経営資源が配分されているかどうかを確認する
・
詳細試験手順の完全性と試験作業におけるその安全性を審査する
・
クリティカルな試験要員が試験と安全について認証されたかどうかを判定する
・
試験支援ソフトウェアが十分検証され適切なものかどうかを確認する
審査合格基準
−
以下のすべての項目は、試験準備審査（TRR）による文書作成準備を
判定するための一助となるチェックリストである。
・
予測結果を得るために、各テストケースの審査と分析をすでに実施したか？
その
予測結果は、試験計画とその目的に沿ったものか？
・
試験手順は「ドライラン」（dry run)として実施したか？
試験要領書は満足すべき
運用を示すものか？
・
試験要員は試験作業と安全手順のトレーニングを受けたか？
試験要員は認証され
たか？
・
試験用資源は、予定の試験や、ハードウェア交換の失敗などの不測の事態に十分対
処できるものか？
・
試験支援ソフトウェアは、試験用コンフィギュレーションの割り当てと、データの
収集、削減化、管理、保管を処理できることを実証済みのものか？
審査の結果
−
試験準備審査（TRR）に合格することは、試験技術者と安全技術者が試
験準備の完全であることを立証し、プロジェクトマネジャが公式な試験開始を承認したこ
とを意味する。
生産準備審査
意図
−
生産準備審査（ProRR＝Production Readiness Review)では、生産計画、生産
施設、生産要員が適切で、生産開始の準備が整っているかどうかを確認する。
時期
−
設計確認後と生産開始前。
目的
−
この審査の目的は次のとおりである。
- 104 -
・
開発中に生じた重大な生産技術問題がすべて解消されているかどうかを確認する
・
設計文書が製造／組立作業に十分役立つものであるかどうかを確認する。
・
生産計画と生産準備が、製造／組立を開始できるくらい十分適切なものかどうかを
確認する
・
最終アイテムの生産に必要な資源が十分配分されているかどうかを確認する
審査合格基準
−
以下のすべての項目は、生産準備審査（ProRR）による文書作成準備
を判定するための一助となるチェックリストである。
・
設計は確認済みのものか？
不完全な設計要素が識別されているか？
・
リスクの特定と特性表示が実施され、その軽減化対策も策定されているか？
・
材料明細書の審査が実施され、重要部品も特定されているか？
・
引き渡しスケジュールは検証済みか？
・
代替供給源が特定されているか？
・
十分な予備アイテムが計画書と予算に盛り込まれているか
・
生産施設とツールは、最終アイテムの生産に十分対処できるものか？
特殊なツー
ルと試験設備が適量指定されているか？
・
生産要員は資格のある者か？
・
図面は確認済みのものか？
・
生産技術と生産計画は、コスト効果のある生産に適するくらい成熟したものか？
・
生産工程と生産方法は、品質要求事項に適合したものか？
それらは、職業安全規
制、環境規制、省エネ規制に準拠したものか？
審査の結果
−
生産準備審査（ProRR）に合格すると、プロジェクトマネジャと関係専
門技術組織から生産準備の確認が得られる。すべての未解決問題は、最終対策とスケジュ
ールにより解決すべきである。
設計認証審査
意図
−
設計認証審査（DCR＝Design Certification Review)では、機能・性能要求事
項に対する設計の適合性が認定検証により実証されたかどうかを確認する。
時期
−
システムの詳細設計審査（CDR）後で、認定試験が完了し、認定試験後の是正
対策を実施する必要のあるすべての改良が実施された後。
目的
・
−
この審査の目的は次のとおりである。
検証結果が機能・性能要求事項を満たしているかどうか、試験計画と試験手順が特
定の環境内で正しく実施されたかどうかを確認する
・
名前、識別番号、最新の権利放棄書リストも含め、試験項目と生産項目間のトレー
サビリティが正しいことを確認する
・
試験開始後に加えられた設計変更や要求変更により必要となるまたは実施される漸
進的試験を特定し、その試験結果に関する問題点を解消する
- 105 -
審査合格基準
−
以下のすべての項目は、設計確認審査（DCR）による文書作成準備を
判定するための一助となるチェックリストである。
・
試験項目系統は生産ユニットまで直接追跡できるものか？
・
この試験項目に採用された検証計画書は承認済みの最新のものか？
・
試験手順と試験環境は、試験計画書に明記されたものに準拠するものか？
・
運用（as-run）試験の結果、試験項目のコンフィギュレーションや設計に何らかの
変更を加えたか？
その変更は、設計や仕様を変更するか、再試験を実施する必要
のあるものか？
・
設計書と仕様書は監査済みのものか？
・
検証結果は機能・性能要求事項を満たしているか？
・
検証文書、設計書、仕様書は相互に関連したものか？
審査の結果
−
設計認証審査（DCR）に合格すると、最終アイテムの設計は生産認可を
受ける。すべての未解決問題は、最終対策とスケジュールにより解決すべきである。
機能および物理的コンフィギュレーション監査
物理的コンフィギュレーション監査(Physical Configuration Audit)（コンフィギュレ
ーション検査ともいう）では、製品の物理的コンフィギュレーションが詳細設計審査（CDR）
で承認済みの"build-to"（または"code-to")文書通りであるかどうかを検証する。機能コ
ンフィギュレーション監査（Functional Configuration Audit）では、受領試験結果が基
本設計審査（PDR）と詳細設計審査（CDR）で承認済みの試験要求事項に適合しているかど
うかを検証する。また、試験結果が性能要求事項に適合し、試験計画と試験手順が正しく
実施されたかどうかも確認する。さらに、権利放棄も含め、試験ユニットと生産ユニット
の相違点を文書に明記すべきである。
4.9
状態報告と評価
システムエンジニアリング計画の重要な部分は、所期の目標と目的を達成するシステム
を実現するためには時間、経営資源、人員がどれだけ必要かを判断することである。作業
明細構成図（WBS＝Work Breakdown Structure）の作成、スケジュールの作成、資金要求計
画の策定などの計画業務については、第 4.3 項から第 4.5 項で検討した。しかし、プロジ
ェクト・マネジメントは計画だけで終わるのではない。プロジェクトマネジャとしては、
適正なマネジメント管理（コントロール）を実施するためにも、それらの諸計画の進捗状
態を実際に目で見ることができなければならない。それが状態報告と状態評価の目的であ
る。「状態報告」とは、プロジェクトが現在どこまで進んでいるかを、コスト、スケジュー
ル、技術的性能などの関係領域面から判定する過程である。「評価」とは、報告過程の結果
をプロジェクトマネジャの使いやすい形に転換する過程である
- 106 -
−
つまり、現在の動向
は将来どんな意味を持つのか？
最終的に、プロジェクトマネジャは、その将来を受け入
れられるかどうか、現行計画にどんな変更を実際に加える必要があるのかを判定しなけれ
ばならない。計画、状態報告、評価は、システムエンジニアリング業務やプログラム管理
（コントロール）業務の一環となるものである。意思決定はマネジメント業務の一つであ
る。
このような過程をまとめると、図 20 に示すフィードバック・ループが形成される。この
ループは、プロジェクト・ライフサイクル全体を通して連続的に発生する。
このループは、プロジェクトの各
状態非OK
（再）
計画
状態報告
状態報告
評価
評価
意思決定
意思決定
状態OK
レベルに適用できる。計画データ、
状態報告データ、評価結果は、プロ
ジェクト階層を上方へ流れ、各レベ
ルで集計される。他方、意思決定は
図20 計画と状態報告のフィードバック・ループ
各種対策をプロジェクト階層に沿っ
て下降させる。各レベルのマネジャ
は、（プロジェクト階層における次の高位レベルで策定された政策に従って）データ報告と
評価を何回、どんな形で実施すべきかを判定する。このような状態報告と評価の要求事項
を設定する際には、いくつかの慣行原則がある。
・
合意された一連の明確な状態報告変数を使用する
・
すべてのプロジェクト・レベルにおいてこのような中核変数を同一形式で報告する
・
トレンド識別とクロスプロジェクト解析のために経時的データを保管する
・
状態報告変数をロールアップするという論理的方法を奨励する（たとえば、債務や
コストの状態報告には作業明細構成図（WBS）を使用し、重量状態報告には製品明細
構成図（PBS）を使用する）。
・
評価には、定量的リスク評価方式を採用する
・
すべての中核報告変数にカラーコード（赤、黄、緑）警報帯域を使用し、プロジェ
クトの状態の概要を示す
中核状態報告変数を定期的（月別）に追跡するのが望ましいが、急激な変化や問題が発
生した時に追跡頻度を増やす必要がある状態報告変数もある。基本設計審査（PDR）や詳細
設計審査（CDR）のような主要審査では、状態報告測定値とそのトレンドを潜在的問題の初
期警戒兆候として綿密に検査すべきである。現在のトレンドが続きそうな場合に、そのト
レンドが不利な結果をもたらすという兆候が認められれば、できるだけ早急に再計画に着
手すべきである。
本項では、コストとスケジュール、技術的性能、システムエンジニアリングプロセス・
評価指標に関する状態報告技法と評価技法についてさらに詳細に説明する。
- 107 -
4.9.1
コストおよびスケジュール管理（コントロール）対策
コストとスケジュールに関する状態報告と評価により、プロジェクトマネジャとシステ
ムエンジニアは、コストとスケジュールの計画目標に対比してプロジェクトがどの程度進
んでいるかを見ることができる。マネジメントの視点から見ると、これらの目標達成はシ
ステムの技術的性能要求を満たすことと同じである。コストとスケジュールの状態報告と
評価については、「システムを生産するシステム」の性能測定とみなすのが良い。
NHB（NASA Handbook ＝NASA ハンドブック）9501.2B 「コストと性能データの相関関係に
関する契約者の報告方式」（Procedures for Contractor Reporting of Correlated Cost and
Performance Data)では、プロジェクトのドル価額と実施期間に基づくコストとスケジュー
ルの状態報告と評価に対する特定要求事項を提示している。通常、NASA 533 型書式の報告
書は、NASA のコスト型（つまり費用払戻し型および固定価格型優遇）契約に適用されてい
る。しかし、533P 型書式を必要とする大型契約(2,500 万ドルを超えるもの）については、
NHB 9501.2B でも、533P 型報告書の代わりに独自の報告書を採用することを契約者に許可
している。プロジェクトマネジャやシステムエンジニアは、その所属するフィールドセン
ターが設定した評価基準か、国防総省の「コスト／スケジュール・コストシステム評価基
準」（C／SCSC＝Cost/Schedule Cost System Criteria）に照らして、こうした報告書の完
全性と品質を評価することもできる。後者の評価基準は産業界と官界で広く受け入れられ、
それを採用するためのツールも各種ある。
各種評価方法
EAC
BCWS
従来のコスト・スケジュール管理
完成時のコス
ト偏差予測
予算
インのコスト計画とスケジュール計
累計額（ドル）
ACWP
当期日までのコスト
偏差（BCWP-ACWP）
（コントロール）方法とは、ベースラ
画をその実値と比較するという方法
当期日までのス
ケジュール偏差
（BCWP-BCWS）
である。プログラム・コントロールに
おける用語では、実績と計画コストや
計画スケジュール状態の差を「偏差」
BCWP（ま
たはEV）
現期日
BCWS＝Budgeted Cost of Work
Scheduled(計画作業予算原価）
ACWP＝Actual Cost of Work
Performed(達成作業実コスト）
BCWP＝Budgeted Cost of Work
Performed(計画作業予算原価）
EV＝Earned Value（収益額）
EAC＝Estimate at Completion
（完成見積り）
時間
という。
図 21 では、2 種の偏差といくつか
の関連概念を示す。適正に作成された
作業明細構成（WBS＝Work Breakdown
図21 コスト偏差とスケジュール偏差
Structure）では、プロジェクト事業
をいくつかの業務と製品に明確に分
割している。スケジュールと予算原価（つまり計画原価）は、各業務と各製品（WBS の何ら
かのレベルにおけるもの）に対するものである。1 組の WBS 要素における計画作業予算原価
- 108 -
（BCWSt ＝Budgeted Cost of Work scheduled)は、時間 t までに完了する予定の作業要素
における各種業務と各種製品に対する全作業の予算原価である。実績作業予算原価（BCWPt
＝Budgeted Cost of Work Performed)は、実績を示す統計値である。実績作業予算原価
（BCWPt)は、収益額（EVt ＝Earned Value）とも呼ばれるが、それらの WBS 要素のスケジ
ュールで時間 t に実際に生産された（完了または進行中の）各種業務と各種製品の予算原
価である。その差額 BCWPt −BCWSt は、時間 t におけるスケジュール偏差と呼ばれる。
達成作業実コスト（ACWPt ＝Actual Cost of Work Performed)は、時間 t までにその WBS
要素に費やされた資金を表わす第 3 の統計値である。予算原価と実原価の差額 BCWPt −
ACWPt は、時間 t におけるコスト偏差と呼ばれる。そのような偏差は、製品の完成見積り
（EACt ＝Estimate at Completion）コストが予算原価と異なることを示す。この偏差を算
定することにより、プログラム・アナリストはプロジェクト・ライフサイクルの何れかの
時点における完成見積り（EAC）コストを予測できる。（枠内補足記事「完成見積り値の計
算」を参照）。
コストおよびスケジュールのベースラインと作業の技術的範囲が十分統合化されていな
い場合でも、コスト偏差とスケジュール偏差を算定できるが、コスト・データとスケジュ
ール・データの関連性が不完全なため、プロジェクトの完成見積り（EAC）値を試算するの
は極めてむずかしい（または不可能である）。
完成見積り値の計算
完成見積り（EAC）値は、プロジェクトのどんな時点でも試算できる。それに適した公式
は、偏差を生じさせる原因によって異なる。事故のような 1 回限りの事象により偏差が生
じた場合は、EAC＝BUDGET＋ACWP−BCWP となる。この場合、BUDGET は当初の完成時計画原
価(original planned cost at completion）である。スケジュール期間の過小評価や要求
事項の定常的再定義のようなシステム上の理由で偏差が生じた場合は、偏差が経時的に増
大し続けると想定され、その方程式は EAC＝BUDGET ×（ACWP／BCWP）となる。
担保権、対策項目、重大問題が増加し続け、将来の作業を一層むずかしくする場合は、
完成見積り（EAC）値が上記方程式による試算値よりも高い伸び率で増大する恐れがある。
そのような要因に対しては、第 4.6 項で説明したリスク・マネジメント方法を使用して処
理できるであろう。
大型プロジェクトにおける完成見積り（EAC）値は、作業明細構成（WBS）のいろいろな
部分にこうした試算方法を組み合わせて使用できるような偏差解析方法から得られる。基
本的な偏差原因を究明せずに、機械的な公式を採用すべきではない。
- 109 -
偏差の管理とシステムエンジニアの役割
マイナス偏差が準備金を大幅に侵食するほど大きい場合は、その偏差を補正するか、プ
ロジェクトを計画し直すというマネジメント上の配慮を払う必要がある。何らかの対策が
必要となる偏差レベルを設定することも重要である。コストとスケジュールのベースライ
ンが収益額（EV＝Earned Value）算定値を維持できない場合は、そのレベルは通常低くな
る。
過大なマイナス偏差を抑制するために取るべき第 1 の対策は、担当のマネジャかシステ
ムエンジニアが問題を調査してその原因を究明し、何らかの推奨解決策を案出することで
ある。偏差問題が発生すると思われる原因は多数ある。
・
何らかの理由で、受け取るものが遅れるか、不十分な場合。
・ 業務が技術的に非常にむずかしく、当初の予定よりも多くの資源が必要になる場合。
・ 病気、火災、その他の災害など、不測の（再発の恐れのない）事態が発生した場合。
偏差の識別は、本来プログラム・コントロール業務だが、システムエンジニアリングの
役割も重要である。それは、マイナス偏差の発生原因を正しく評価すれば、管理（コント
ロール）対策の成功するチャンスが大幅に増えるからである。こうした評価では、コスト、
スケジュール、技術的状況に対する理解力を必要とする場合が多いが、それを提供できる
のはシステムエンジニアだけである。
4.9.2
技術的性能測定
システムの技術的性能測定（TPM＝Technical Performance Measure）の状態報告と評価
は、コスト・スケジュール管理（コントロール）を補足するものである。システムの技術
的性能測定（TPM）を追跡調査することで、プロジェクトマネジャは、納入システムが実際
に性能仕様（要求事項）に適合しているかどうかを確認できる。その上、TPM 追跡調査を実
施すれば、多数のシステムエンジニアリング基本作業を一つに結びつけることもできる
−
つまり、TPM 追跡計画は、システム解析、機能・性能要求の定義、検証と妥当性確認と
いった作業間に一つの関係を作り出す。
・
システム解析作業では、システムの有効性を決定する主要性能や技術的属性を特定
する。システム解析で実施するトレード研究は、システムの性能要求事項を定量化
する一助となる。
・
機能・性能要求定義作業は、検証・妥当性確認要求事項を特定する一助となる。
・
検証・妥当性確認作業では、技術的性能測定（TPM）の定量評価が得られる。
・
「限界外の」技術的性能測定（TPM）値は、資金、スケジュール、人材の計画を見直
すべき信号となる。時には、新規のシステム解析作業を開始する必要もある。
TPM 追跡調査は、フェーズ B の初期段階に実施されるベースライン設計の確定直後に開始
できる。TPM 追跡調査計画は、遅くともフェーズ C の開始前に着手すべきである。しかし、
- 110 -
一連の特定 TPM を裏づけるデータは、プロジェクト・ライフサイクルの後半にならないと
入手できないこともある。
TPM の選定
通常、技術的性能測定（TPM）は一般的なもの（質量や信頼性のように、製品明細構成（PBS
＝Product Breakdown Structure)の各要素に意味のある属性）と、特有のもの（製品明細
構成（PBS）の特定要素のみに意味のある属性）に分けられる。システムエンジニアは、PBS
の各レベルで追跡すべき TPM が一般的なものか、特有のものかを判定する必要がある。ま
た、システム有効性の測定（プロジェクトがそのような測定を維持している場合）ならび
にトップレベルの TPM としてその有効性を決定する主要性能や技術的属性も追跡調査すべ
きである。PBS の低レベルにおいて追跡する価値のある TPM は、各システム、各セグメント
などに対する機能・性能要求事項により特定できる。（枠内補足記事「高レベルの TPM 例」
を参照）。
TPM の選定では、システムエンジニアはプロジェクト・ライフサイクル中に客観的に測定
できるものに重点を置くべきである。この測定は、直接的には試験により、間接的には試
験と解析の併用により実施できる。システムの信頼性のような高レベルの TPM を算定でき
る唯一の方法は解析であるが、そのような解析に使用するデータはできるかぎり実証値に
基づいたものにすべきである。この解析では、トレード研究段階で採用したものと同じ測
定方法やモデルを使用できる。しかし、TPM 追跡調査では、性能や技術的属性の予測値（ま
たは希望値）ではなく、実証値を使用してモデルを作成する。プロジェクト・ライフサイ
クルがフェーズ C と D まで進むと、システムに関する「実」データを更に多く使用できる
ようになるので、TPM の測定もますます精度の高いものになる。
- 111 -
惑星探査衛星と打ち上げロケットの高レベル TPM 例
惑星探査衛星の高レベル技術的性能測定（TPM）例としては次のものがある。
・
ミッション終了（EOM＝End-of-Mission）時のドライ質量
・
軌道投入質量（EOM ドライ質量、ベースライン・ミッション＋予備推進剤の質量、そ
の他消耗品と上位段階のアダプタ質量も含む）
・
ミッション終了（EOM）時の消耗品
・
電力需要（対供給比）
・
搭載データ処理記憶装置の需要
・
搭載データ処理スループット時間
・
搭載データ伝送バス能力
・
総ポインティング・エラー
衛星サブシステムと科学用計測器の質量と電力需要は、個別に追跡することもできる。
打ち上げロケットの高レベル TPM 例としては、次のものがある。
・
発射時のロケット総重量
・
ペイロード質量（公称高度または軌道上）
・
ペイロード体積
・
軌道投入精度
・
打ち上げ時の信頼性
・
飛行時の信頼性
・
再使用可能ロケットの回収率
・
使い捨てロケットの場合には、n 号機の生産単価。（5.2.3 項の枠内補足記事「教訓
曲線理論」を参照）
最後に、システムエンジニアが選定する TPM は、システムの有効性やミッションの実行
性から見て明確な（定量的）限界内に入るものでなければならない。通常、このような限
界は確実な制約の上限または下限を表わす。衛星の場合、その TPM の代表例は軌道投入質
量であり、選定された打ち上げロケットの能力を越えることはできない。高レベル TPM と
して軌道投入質量を追跡調査するのは、ロケットの能力を超えないようにするためである。
評価方法
従来の TPM 評価方法は、TPM の経時的「計画プロファイル」（planned profile)を作成し、
次に実証値とそのプロファイルを比較する方法である。計画プロファイルは、多数の要素
を考慮に入れたその TPM の名目「軌道」を表わす。これらの要素としては、システムの技
術的成熟度、試験と実証試験のスケジュール、同種または関連システムによる
- 112 -
（a）計画プロファイル法
過去の経験などがある。たとえば衛星
のドライ質量は、フェーズ C と D にお
新規割当て値
いて 25％−30％ほど増大する傾向が
ある。衛星ドライ質量の計画プロファ
新計画プロファイル
元の割当て値
TPM 値
イルでは、この伸び率を当初の低い値
で補正しようとする場合もある。計画
余裕
元の計画
プロファ
イル
0
プロファイルの最終値は、通常、割当
て要求値（または仕様値）と交差する
現期日
実証値
ここで再計画実施
元の計画プロファイル
時間
ル法は、上述したコスト・スケジュー
ル管理対策における収益額（Earned
（b）余裕マネジメント法
Value）評価法の技術的性能測定（TPM）
＋
新規割当て値へ移
行したために生じ
た断絶
TPM 余裕
か、それに漸近する。計画プロファイ
版である。
これと密接な関係のある TPM 評価
余裕
方法は、TPM の経時的「余裕要求値」
元の余裕要求値
（margin requirement）を設定し、実
新余裕要求値
余裕値とその余裕要求値を比較検討
0
する方法である。その余裕値は、通常、
ここで再計画実施
TPM の実証値とその割当て要求値の差
現期日
−
と定義されている。余裕要求値は、割
で表わすこともできる。一般的に、余
時間
裕要求値はフェーズ C と D を通して低
（c）リスク・マネジメント法
下し、最終的にはゼロに達するか、ゼ
1.0
緑色警戒帯域
ロに近づく。
新規割当て値へ
移行したために
生じた断絶
選定した方法に応じて、システムエ
黄色警戒帯域
ンジニアは適切な計画プロファイル
か余裕要求値を提示し、担当マネジャ
赤色警戒帯域
の承認を得る必要がある。この両方法
注記：赤・黄・緑
警戒帯域は（c）に
しか示されていな
いが、
（a）と（b）
にも採用できる
の価値は、例外によるマネジメントが
可能になるという点にある
現期日
ここで再計画実施
確率
（最終TPM値≦割当て値）
当て要求値に対するパーセンテージ
0
−
つ
まり、計画プロファイルからの偏差や
要求値に満たない余裕値だけが、再計
画を必要とする将来の潜
時間
在的問題を指摘する。このような偏
図22 3 つのTPM 評価方法
- 113 -
差や余裕値が生じた時は、新しいコストやスケジュール、あるいは何らかの技術的変更を
提案する必要がある。技術的変更が新しい計画プロファイルを生むこともある。この点を
仮想 TPM の計画プロファイルとして図 22（a）に示す。この例では、システム設計・開発段
階における TPM 値の実証偏差が大きいため、時間 t に再計画が必要になる。その再計画は、
TPM の許可最終値（「割当て値」）の増大という形を取る。その結果、新しい計画プロファイ
ルが作成され、TPM 追跡調査計画の残りの全期間にわたって TPM の追跡調査が実施されるこ
とになる。
余裕マネジメント法という評価方法は、同じ例を使って図 22（b）に示すものである。TPM
値が余裕要求値を大幅に下回る場合は、時間 t において再計画が実施される。TPM の新しい
割当て値を高くすると、余裕要求値も高くなるが、余裕値がその要求値のすぐ上に接近す
ることになる。
この両方法からは、追跡される TPM の最終値がフェーズ C と D のほぼ全体を通して不確
定になることが認められる。余裕マネジメント法では、こうした不確定性をそれとなく処
理するために、最終値がその割当て値を越えて低い値、たとえば 5％以下になるチャンス
を減らすような余裕要求値を設定しようと試みる。第三の報告・評価方法では、このよう
なリスクを明確に処理する。リスク・マネジメント法は、同じ例を使って図 22（c）に示す
ものである。割当て値を下回る TPM の最終値の確率が赤色警戒領域内まで急落すると、時
間 t において再計画が実施される。TPM の新しい割当て値を高くすると、その確率は大幅に
高くなる。
リスク・マネジメント法では、TPM 最終値の確率分布を試算する必要がある（枠内補足記
事「衛星質量追跡調査例」を参照）。TPM 追跡調査計画の初期に実証値を間接的試算方法で
推定すると、その確率分布は、後期に試験結果などの測定データに基づいて推定した場合
に比べ、大きな統計的偏差を示す。TPM 値がその計画プロファイル上にある場合（同様に、
その余裕値が対応する余裕要求値を上回っている場合）は、統計的確率分布が狭くなるた
め、TPM 値はその伸び率にもかかわらず、（図 22（c）に示す）緑色計画領域内にとどまる
ことができる。この 3 つの方法はそれぞれ異なった TPM 評価方法を示し、その情報をマネ
ジメント部門に伝えるが、どの方法を選定しても、成功や失敗のパターンは同じになるは
ずである。
TPM 追跡調査計画と SEMP の関係
通 常 プ ロ ジ ェ ク ト の TPM 追 跡 調 査 計 画 に つ い て 記 載 す る 文 書 は 、 SEMP （ Systems
Engineering Management Plan ＝システムエンジニアリング・マネジメント計画書）であ
る。この計画書には、追跡調査すべき TPM のマスターリスト、採用すべき測定方法と評価
方法を記載すべきである。特定の高レベル TPM の測定に解析方法とモデルを使用する場合
は、その方法とモデルも特定する必要がある。報告回数と評価時期も明記すべきである。
それらを決定する際には、システムエンジニアとしては、精度の高い効果的な TPM 追跡を
- 114 -
適時に実施するというプロジェクトのニーズと、TPM 追跡調査計画のコストとのバランスを
考慮しなければならない。SEMP 上に詳記する TPM 追跡調査計画案は、選定した評価方法に
応じて TPM の各割当て値、経時的計画プロファイルまたは余裕要求値、警戒領域を指定し
たものとする。
リスク・マネジメント法による衛星質量追跡調査例
フェーズ C と D においては、衛星の軌道投入質量を不確定量とみなすことができる。し
かし、各衛星と各計測器の質量予測は、設計技術者により定期的に実施される。実際に部
品や構成要素が建造され、サブシステムや搭載機器に組み込まれるに伴い、この予測も変
化し、ますます精度が高まる。フェーズ C と D においては、ミッションの設計要求を満た
すために推進剤の量を微調整するので、軌道投入質量も変動することがある。したがって、
開発段階の各時点では、衛星の軌道投入質量を単一点ではなく、確率分布として表わす方
が良い。
軌道投入質量の確率分布を得る技法では、下限値と上限値、軌道投入質量「最適」値と
いう 3 点を試算する。この 3 つの値は、下図に示すような確率分布を算定するための各種
確率密度
パラメータの中に組み込める。
確率（軌道投入質
量≦ロケット仕様）
ロケット仕様
衛星の軌道投入質量（kg）
「LV 仕様」という打ち上げロケット（LV＝Launch Vehicle）の「保証」ペイロード能力
は、太い縦線で示されている。確率曲線の下、太い縦線の左にある領域は、衛星の軌道投
入質量が打ち上げロケットのペイロード能力を下回るか、それに等しくなる確率を示す。
軌道投入質量がリスク・マネジメント法により追跡される TPM（Technical Performance
Measure ＝技術的性能測定）対象であれば、この確率は図 22（c）と同じように作図できる。
この確率が 1 に近ければ、プロジェクトマネジャは、まだ「かなりの余裕」があるよう
に思うため、ミッションの目的をさらに追加しようと考えることもできる。しかし、上図
では、確率が 1 を大幅に下回っている。この場合、プロジェクトマネジャは、プロジェク
ト範囲を縮小するために、たとえば何れかの搭載機器を取り外すか、ミッションの目的を
減らすかを考えるであろう。また、もっと大型の打ち上げロケットを要求して問題解決を
図ることもできるであろう。
- 115 -
4.9.3
システムエンジニアリング・プロセスの評価指標
システムエンジニアリング・プロセスの評価指標の状態報告と評価により、「システムを
生産するシステム」の性能がさらに良く見えるようになる。したがって、この評価指標は、
第 4.9.1 項で述べたコスト・スケジュール管理対策を補足するものである。
システムエンジニアリング・プロセスの評価指標では、システムエンジニアリング・プ
ロセスとシステムエンジニアリング組織の有効性と生産性を定量化しようとする。各プロ
ジェクト内でこのような評価指標を追跡調査すると、システムエンジニアがそのプロジェ
クトの健全性と進捗状態を一層良く理解できるようになる。プロジェクト全体を通して（経
時的に）システムエンジニアリング・プロセスの評価指標を追跡調査すると、システムエ
ンジニアリング業務を実施するためのコストと所要時間をより適正に予測することができ
る。また、システムエンジニアリング組織としても、総合的品質マネジメント（TQM＝Total
Quality Management）の連続改良原則という契約義務の履行を実証することができる。
システムエンジニアリング・プロセスの評価指標の選定
通常、システムエンジニアリング・プロセスの評価指標は 3 種類に分類されている。つ
まり、システムエンジニアリング作業の進捗状態を測定するもの、その進捗状態の質を測
定するもの、その生産性を測定するものである。システムエンジニアリング・マネジメン
トの各レベルでは、それぞれ異なった評価指標に関心を示す。たとえば、プロジェクトマ
ネジャや主任システムエンジニアは、システムエンジニアリング要員の配備、プロジェク
トのリスク・マネジメントの進捗状態、主なトレード研究の進捗状態などを重視する。サ
ブシステム担当のシステムエンジニアは、サブシステム要求事項およびインタフェース定
義作業の進捗状態と検証手続きの進捗状態を重視する。各システムエンジニアとしては、
プロセス評価指標を少なくする方がよい。どの評価指標を追跡すべきかは、システムエン
ジニアリング作業全体における各システムエンジニアの役割によって異なってくる。その
ライフサイクルにおけるプロジェクトの進捗状態に応じて、追跡すべきシステムエンジニ
アリングプロセス評価指標も変わってくる。
システムエンジニアリング・プロセスに関するデータの収集と保管にはコストがかかる。
システムエンジニアリング・プロセス評価指標の状態報告と評価は、そのプロセス自体か
ら時間と労力を転用するものである。システムエンジニアとしては、各システムエンジニ
アリング・プロセス評価指標の価値とその収集コストとのバランスをとらなければならな
い。このような評価指標の価値は、コスト・スケジュール管理対策だけでは得られないよ
うなこのプロセスに対する洞察力が得られる点にある。また、この評価指標は常に生産性
のハードデータを提供する。このデータは、システムエンジニアリングのツールやトレー
ニングに対する投資から得られる潜在的収益を実証する上で極めて重要なものである。
- 116 -
評価指標例と評価方法
表 2 には、考慮すべきシステムエンジニアリング・プロセスの評価指標例をいくつか示
す。この表はあらゆる評価指標例を網羅したものではない。この評価指標のなかには別の
解釈ができるものもあるので、NASA（米国航空宇宙局）の各フィールドセンターではそれ
ぞれのプロセスに適した評価指標を常識的に定義する必要がある。たとえば、各フィール
ドセンターでは、「完成」要求対「承認」要求が何を意味するのか、これらの用語が適切か
どうかといった点を判断する必要がある。たとえばこの定義の中で重要な点は、必ずしも
あらゆる要求を一つにまとめる必要がないことを認識することである。種類の異なるいく
つかの要求に対して同じ評価指標を個別に追跡する方が有利なこともある。
表2
システムエンジニアリング・プロセスの評価指標
業務
要求書の作成と
管理（マネジメン
ト）
設計と開発
検証と妥当性確
認
（V＆V）
審査
システムエンジニアリング・プロセスの評価指標
要求の特定対完成対承認件数
分類
S
要求の可変性
Q
トレード研究の計画対完了件数
S
システムエンジニアリング 1 時間当たりの要求承認件数
仕様書の立案対完成件数
P
S
ECRs／ECOs（技術変更要求書／技術変更指令書）の処理
Q
エンジニアリング図面の作成対公表件数
V＆V 計画書の特定対承認件数
S
S
V＆V 要領書の立案対完成件数
S
機能要求の承認対検証件数
S
システムエンジニアリング 1 時間当たりの V＆V 計画書承認件数
P
問題／故障報告書の処理
審査項目不具合（RID＝Review Item Discrepancy)の処理
Q
Q
対策項目の処理
Q
S＝進捗状態またはスケジュール関係。Q＝品質関係。P＝生産性関係。
品質関係の評価指標は、システムエンジニアリング・プロセスの一部が過重や挫折寸前
の場合を指摘するのに役立つものとすべきである。この評価指標はいくつかの異なる方法
で定義、追跡することができる。たとえば、要求の可変性は新たに特定した要求件数や、
承認済み要求に加えた変更件数に定量化できる。また、技術変更要求書（ECR＝Engineering
Change Request）の処理に対する追跡調査は、処理を開始した ECR 累計件数と処理を終了
した ECR 累計件数の比較、処理を開始した ECR の経年プロファイル図の作成、前月に処理
を開始した ECR 件数と処理を開始した ECR 総数の対比などにより実施できる。状況報告方
法と評価方法の選定では、システムエンジニアが自分の判断力を活用すべきである。
生産性関係の評価指標では、システムエンジニアリングにおける投入量単位当たりの生
- 117 -
産量を示す。更に高度で複雑な投入量の測定単位もあるが、最も普及しているのは特定業
務や特定作業に向けられたシステムエンジニアリング時間数である。システムエンジニア
リングのどの 1 時間も同じコストになるわけではないので、システムエンジニアリング要
員各人の時間数を比較できるように適切な加重方法を開発すべきである。
スケジュール関係の評価指標は、計画量と実績量の表やグラフに表示できる。品質関係
と生産関係の評価指標を併用すれば、通常、個別評価指標の場合よりも重要な動向（トレ
ンド）が得られる。最も有効な評価方法では、現行プロジェクトの動向とそれと同じタイ
プの成功プロジェクトの動向を比較できる。つまり、後者のプロジェクト動向は、システ
ムエンジニアが自分の作業を判定するための基準となる。
- 118 -
5．
システム解析とモデル作成の問題点
システム解析とモデル作成の役割は、システムエンジニアリング・プロセスにおいてよ
り適正な意思決定を行うために一貫性のある厳正な評価を行うことである。最適設計を目
指したシステム設計を支援することにより、システム解析とモデル作成はシステムエンジ
ニアリングの目的にも寄与する。それには第一に、採用できそうな各種代替案のトレード
研究を実施する必要がある。本章では、トレード研究プロセス、トレード研究に採用する
システムの効果とコストの定量化方法、回避すべき落とし穴について概説する。
システム解析
Gene Fisher は、システム解析を次のように定義している：
「将来の適正方針を選択
する意思決定者を支援するために、（1）所定の目的と、その目的を達成するための各種政
策案と各種戦略案を組織的に審査かつ再審査し、（2）それらの各種代替案の経済的コスト、
効果、リスクをできるかぎり定量的に比較する研究」
5.1
トレード研究プロセス
トレード研究プロセスは、第 2 章で説明したシステムエンジニアリングうず巻図の重要
部分である。本項では、このプロセスの各種段階について詳細に説明する。トレード研究
は、各分解レベルに現れるシステムを定義する一助となるものである。この項で特に伝え
たい重要なメッセージは、このプロセスを効果的に実施するために、多くの技能と一連の
作業を最適システム設計に向けて結集させる必要があるという点である。
(*)
各種の目標／目的と制
約を設定／識別する
採用できそうな
代替案を設定す
る
選定規準を設定
する
機能解析を実施する
以下の事項に対する測定項目と測定
方法を設定する：
・ システム効果、
・ システム性能または技術的属性
・ システムのコスト
選定した測定方法による評
価に必要となる各代替案に
関するデータを収集する
次の質問も考慮すべきである：
・ 目標／目的と制約は満たされた
か？
・ 試験的選定は確実なものか？
・ 各種代替案を区別するには解析
方法をさらに改良する必要があ
るか？
・ 問題の主観的な面も検討した
か？
いいえ
・ システムの効果、性能または技術的属性、各代替案のコストを試
算する。
・ 不確定性の範囲を算定または試算する。
・ 感度分析を実施する
試験的選定
（決定）を
行う
トレード研究の解析部分
図23 トレード研究プロセス
- 119 -
はい
試験的選定は許
容し得るもの
か？(*)
システム設計の次段
階または採用への進
行
図 23 には、トレード研究のプロセスを最も簡単な形で示す。その第一段階は、「システム
の目標と目的を設定し、システムが満たすべき制約を特定する」段階である。プロジェク
ト・ライフサイクルの前半フェーズでは、通常そのような目標、目的、制約を一般に通用
する用語で明記する。プロジェクト・サイクルの後半フェーズでは、システムのアーキテ
クチャも、おそらくその設計のいくつかの面もすでに決定されているので、その目標と目
的はセグメントやサブシステムが満たすべき性能要求事項として明記できる。
システムの各分解レベルでは、システムエンジニアはシステムに関する適切な解決策を
案出するために、それらの目標、目的、制約のあらゆる側面を理解する必要がある。この
段階では、「機能解析を実施する」。機能解析は、システムがその目標と目的を達成するた
めに果たすべき各種機能を特定し、記述し、相互に関連づける組織的なプロセスである。
プロジェクト・ライフサイクルの前半フェーズにおける機能解析では、システムが果たす
べきトップレベルの機能、その機能を果たす必要のある場所、回数、運用概念と環境条件
などを扱う。この前半フェーズにおける機能解析では、トレード研究でシステム・アーキ
テクチャを定義できるような 1 つの分解レベルに進むだけでよい。プロジェクト・ライフ
サイクルの後半フェーズにおける機能解析では、システム設計と各種インタフェースをは
っきりと定義するために必要となる分解レベルすべてに進むことができる。（枠内補足記
事「各種機能解析技法」を参照）。
機能解析技法
機能解析とは、システムがその目標と目的を達成するために果たすべき各種機能を特定
し、記述し、相互に関連づける過程である。機能解析は、そうした機能をトップダウン式
に階層的に分解する技法として論理的に構成され、システムエンジニアリング・プロセス
においていくつかの重要な役割を果たす。
・
システムが満たすべきすべての要求事項を引き出す
・
あらゆるレベルにおけるシステム効果とシステムの基本的性能または技術的属性に
対する測定値を識別する一助となる
・
システムの目標と目的を満たすことができない代替案を、トレード研究の検討範囲
から除外する
・
トレード研究において各種代替案の評価に使用する数学的モデルを作成するシステ
ム・レベル（およびそれより低レベル）のモデル作成者に洞察力を与える
機能解析に利用できる技法はいくつかある。最も重要な機能解析技法は、機能流れブロ
ック図（ＦＦＢＤ＝Functional Flow Block Diagram)である。こうしたブロック図では、
何らかの機能を果たすまでの各種作業のネットワークを示す。ＦＦＢＤのネットワークで
は、実施すべき「こと」の論理的順序は示すが、各機能時間や機能間の時間間隔は示さな
- 120 -
い。「タイムクリティカル」要求事項を理解するには、タイムライン解析（ＴＬＡ＝Time Line
Analysis）を使用する。衛星コマンドの順序づけやロケット処理のような各種運用業務に
はＴＬＡを適用できる。第３の機能解析技法は、Ｎ 2 図である。この図は、特定階層レベル
における機能の相互作用やデータの流れをマトリックスの形で示した図である。添付資料
B.7 では、こうした各技法について詳細に説明すると共に、その例を示す。
目標と目的の設定と機能解析の実施に密接な関係がある段階は、システム効果（これが
実効的な場合）、システムの性能または技術的属性、システムのコストに対する「測定項目
と測定方法を設定する」段階である。（第 2.3 項の説明に従って、このような変数を「出力
変数」（outcome variables)と総称する。一部のシステムエンジニアリング書ではこのよう
な変数を「決定規準」と説明しているが、この用語を以下に述べる「選定規準」（selection
rule）と混同してはならない。第 5.2 項と第 5.3 項では、それぞれシステムのコストとシ
ステムの効果について詳細に検討する）。この段階では、定量化方法に精通している者の関
与を示唆するので、まずトレード研究の解析部分から始める。
各測定項目に関しては、その定量的測定項目をどのように算定するか、つまりどんな測
定方法を採用するかという質問に答えることが重要である。その理由の一つは、この段階
では次に、システムの目標と目的を達成する上で重要となる各種変数を明確に特定するか
らである。
実際の製造やプログラミング前に、システムの効果、基本的機能または技術的属性、コ
ストという面から各種代替案の予測結果を評価するには、数学的モデルや一連のシステ
ム・モデルを使用する必要がある。したがって、測定方法を指定するもう一つの理由は、
必要なモデルを識別できるという点にある。
これらのモデルは、過去の同じようなプロジェクトから入手できる場合もあれば、新た
に開発しなければならない場合もある。後者の場合は、測定方法を決定してから、必要な
システム・モデルの作成作業を開始すべきである。新モデルの開発にはかなりの時間と労
力が必要になるので、トレード研究に正式に使用できるように、モデルの特定は早期に実
施する必要がある。
「選定規準を設定する」段階では、出力変数を使用して好適代替案を（試験的に）選定
する方法を明確に決定する。たとえば、システム効果が最も高く、コストが x ドル未満で
（所定の確率で）、安全性要求事項を満たし、その他の政治上やスケジュール上の制約も満
たす代替案を 1 つ選定するという選定規準を設けることもできる。選定規準を設定するこ
とは、本来、どのように選択すべきかを決定することである。この段階は、システム効果、
システムの性能または技術的属性、システムのコストを実際に測定することとは関係ない。
多種多様な選定規準を設定することは可能である。特定のトレード研究における選定規
準は、そのトレード研究が実施されている状況、特に対象とするシステム設計の分解レベ
ルに応じて異なる。一般的に、システム設計の各レベルでは、次の高位レベルからの指針
- 121 -
のみに従って選定規準を選定すべきである。システム設計の低レベルにおけるトレード研
究の選定規準は、高レベルの選定規準と呼応するものでなければならない。
「採用できそうな代替案を設定する」段階では、システムの目標と目的を達成できそう
ないくつかの代替案を案出する。この段階では、システムの機能要求事項と運用概念を（し
かるべき詳細レベルまで）理解する必要がある。これらの要求事項を満たす見込みがある
かどうかを判定する実効的な方法は、何らかの運用タイムラインまたは「標準ミッション」
を通してその代替案を実施することである。（時には、特定の刺激や制御を加えた時や特定
の環境に遭遇した時にシステムがどのように反応するかを判定するために、個別行動モデ
ルを開発する必要もある。それによって、システムがタイムクリティカル要求事項や安全
性要求事項を満たす見込みがあるかどうかという点を洞察できる）。採用できそうな代替案
を設定するには、システムが必要となった時に利用できるまたは利用できそうな技術を十
分理解しておく必要がある。採用できそうな各代替案は、何らかの説明書にその特性を記
載しておくべきである。その説明書の書式としては、少なくとも、その代替案の低レベル・
アーキテクチャや設計構成要素（たとえばサブシステムなど）までの所要システム機能の
配分方法を明確にすべきである。
トレード研究で検討している各種代替案を示す一つの方法は、トレード樹形図である。
フェーズ A におけるトレード研究では、早期に一つの代替案のみに的を絞らないように、
高レベルのシステム・アーキテクチャ代替案をトレード樹形図に多数記入すべきである。
システムエンジニアリング・プロセスが進むにつれて、魅力のない代替案を記入したトレ
ード樹形図の分枝は「剪定」され、今後注目に値する分枝のみにシステム設計の詳細部が
加えられる。魅力のない初期代替案を「剪定」する過程は、「キラー・トレード」（killer
trade）と呼ばれることもある。（枠内補足記事「火星用ロバーのトレード樹形図例」を参
照）。
採用できそうな 1 組の代替案が与えられると、次は各代替案に関する「データを収集す
る」段階となる。このデータは、選定ずみ測定方法により測定項目を評価するのに必要な
ものである。このような測定項目の一部を算定するのにモデルを使用する場合、モデルの
入力データを取得すれば、データ収集作業に何らかの弾みと方向性を与える。信頼性、保
全性、生産性、総合ロジスティックス、ソフトウェア、試験、運用、コスト算定などの分
野の技術者は、データを提供することで、トレード研究において重要な補助的役割を果た
す。しかし、データ収集作業は、システムエンジニアが統括すべきである。この段階から
得られるものは、各代替案の定量的説明とそれに付随する定性的説明である。
各代替案の試験結果は、特に有用である。システムエンジニアリング・プロセスの初期
段階では、性能と技術的属性が全般的に不確定であるので、それらを予測しなければなら
ない。ブレッドボードおよびブラスボード試験台から得られたデータは、モデルの入力デ
ータとして使用される一連の値が適正であるというデータの信頼性を高める。以前開発さ
れた関連システムから収集したデータを利用すれば、そうした信頼性は一層高まる。
- 122 -
トレード研究プロセスの次の段階は、「システム効果、システムの基本的性能または技術
的属性、システムのコストを試算する」ことにより出力変数を定量化する段階である。も
し必要データが収集され、測定方法（たとえばモデル）が適切であれば、理論的にはこの
段階を機械的に実施できる。しかし実際には、有意の結果を得るためにはかなりの技能が
必要になる場合が多い。
すべての入力値が正確にわかっており、出力変数を完全に予測できるモデルがあれば、
理想的である。しかし、このような理想的なケースが望めなければ、システムエンジニア
が各代替案に対する出力変数の点推定値を算定するかまたは推定済み不確定範囲で補足す
べきである。不確定な各主要入力データごとに一連の値を推定すべきである。この一連の
入力値を使用すれば、出力変数の感度を測定でき、その不確定範囲も算定できる。システ
ムエンジニアとしては、モンテカルロ・シミュレーションを使ってそうした出力変数に関
する「有意な確率分布」を得ることもできる（第 5.4.2 項を参照）。それが不可能な場合は、
不確定範囲と感度だけで満足しなければならない。
本来ならば、これでトレード研究プロセスの解析部分は完了する。この後の諸段階は判
定部分と言えるものである。選定規準と解析作業結果を併用すれば、システムエンジニア
は各種代替案を適性の高い順に配列することができる。要するに、「試験的選定を行う」段
階である。
この試験的選定結果を盲目的に受け入れるべきではない。ほとんどのトレード研究では、
解析結果の「現実性検査」（reality check)を実施する必要がある。その検査では多数の質
問を行う。目標、目的、制約が本当に満たされているか？
試験的選定は、測定方法に応
じた一連の特定入力値に大幅に左右されるものか、それとも一連の妥当な入力値の下で実
施できるものか？ （後者の場合の試験的選定は、確実なものといえる）。試験的選定に必
要なデータが十分あるか？
測定方法は、試験的選定がその他の代替案よりも実際に優れ
ていることを確証できるほど十分な識別力を備えているか？
問題の主観的な面も十分検
討したか？
このような質問に対する回答が試験的選定を支援していれば、システムエンジニアはシ
ステム設計のさらなる分解に着手するか、その設計を採用するという勧告に一層強い自信
を持つことができる。トレード研究から得られたシステム効果、基本的システム性能また
は技術的属性、システム・コストの予測は、この設計分解の入力データとして利用される。
トレード研究プロセスの解析部分は、システムの低レベルが満たすべき性能または技術的
属性（およびコスト）を定量化する手段となる場合が多い。この性能または技術的属性は、
まとめて「性能要求事項」と表記することができる。
現実性検査に合格しなければ、トレード研究プロセスは 1 段階または数段階前の段階へ
戻ることになる。このように段階をくり返すことにより、トレード研究から得られた新情
報に基づいて、目標、目的、制約、新代替案に変更を加えたり、選定規準に変更を加えた
りすることもできる。現実性検査の結果、決定を下す代わりに、まず各種代替案の評価に
- 123 -
使用した測定項目と測定方法（たとえばモデル）を改良し、さらにトレード研究プロセス
の解析部分をくり返すことも時々ある。
- 124 -
火星用ロバーのトレード樹形図例
下図には、火星用ロバーというロボット・システムのトレード樹形図を一部分だけを示
す。このシステムの目標は、有人宇宙船の適当な着陸地を見つけることである。この図の
各層は、最適案を選定するためにトレード研究において扱う必要のあるシステムの諸側面
を表わしている。技術的実現性、打ち上げロケットの制約などを理由に、いくつかの代替
案はあらかじめ除外してある。代替案の総数は樹形図の最終点の数に相当する。層数はわ
ずかだが、代替案の件数はいくらでも増やせる。（この樹形図では、すでに分枝を剪定し、
低自律性の大型ロバーを排除してある）。システムエンジニアリング・プロセスが進むにつ
れて、不利なトレード研究結果が出た樹形図の分枝は排除される。実施に必要なより詳細
なトレードオフ研究を識別することにより、残りの分枝はさらに展開される。一連の（暗
黙の）代替案全体は、トレード樹形図上に連続変数として表記できる。この例では、ロバ
ーの速度や移動範囲も表記できる。変数をこのように処理すれば、数学的最適化技法も採
用できる。樹形図は本質的に偶発事象ノードのない意思決定樹形図である点に留意された
い。（枠内補足記事「意思決定樹形図」を参照）。
火星用ロバー
ロバーのサイズ
大型
中型
小型
(-1000kg）
（-100kg）
（-10kg）
機数
50
5
10
10
20
1
2
自律性
低 高
低
高
低
高
低
中 高
低 中
高
低
中
高
中
高
- 125 -
車輪
脚部
車輪
脚部
車輪
脚部
車輪
脚部
車輪
脚部
車輪
車輪
脚部
車輪
脚部
脚部
車輪
車輪
車輪
脚部
車輪
車輪
脚部
車輪
車輪
脚部
車輪
車輪
移動性
5.1.1
トレード研究プロセスの管理
トレード研究プロセスを管理（コントロール）する方法は多数ある。最も重要なものは、
システムエンジニアリング・マネジメント計画書（SEMP＝Systems Engineering Management
Plan)である。SEMP では、プロジェクト・ライフサイクルの各フェーズで実施すべき主要ト
レード研究を指定すると共に、トレード研究報告書の全容を正確に記載する。この報告書
は、「決定支援パッケージ」（decision support package）（つまり正式審査報告書と変更要
求書と共に提出する文書類）の一部を構成するものである。
トレード研究報告書
トレード研究報告書は、トレード研究ごとに作成すべきである。各トレード研究報告書
では、少なくとも以下の事項を特定すべきである。
・
解析中のシステム問題
・
システムの目標と目的（つまり、分解レベルに適した要求事項）および制約
・
採用する測定項目と測定方法（モデル）
・
採用するすべてのデータ・ソース
・
解析するために選定した代替案
・
不確定範囲や実施した感度分析も含めた算定結果
・
採用した選定規準
・
推奨案
トレード研究報告書は、システムエンジニアリング・プロセスを経て出された決定事項
をたどれるように、システム保管記録の一部として保管すべきである。これらの報告書に
対して一貫性のある書式を採用すれば、審査しやすく、また正式の変更管理プロセスに導
入しやすくなる。
トレード研究プロセスを管理するもう一つの方法は、研究チームのリーダーとメンバー
の選定である。「トレード研究は分担技術であり、分担科学であるので、チームの構成と経
験が研究の最終的な有用性を決定する重要な要因となる」。早期に特定の技術設計に的を絞
ることのないように、さまざまな技術分野の専門家を研究チームに加えるのが良い。
もう一つの方法は、研究対象とする代替案の件数を制限することである。追加代替案の
選定やそれら代替案に関する必要データの収集はかなり大変な作業となる。そのため、代
替案の件数は、通常、研究のために利用できる時間と資源によって決定される。しかし、
研究対象の代替案が少ないか、似すぎていると、トレード研究プロセスの目的は達成でき
ない。
トレード研究プロセスを管理する第四の方法は、モデルの使用（および誤用）によるも
- 126 -
のである。最後に、選定基準の選択もトレード研究プロセスの結果にかなりの影響を及ぼ
す。第 5.1.2 項と第 5.1.3 項ではこの最後の 2 つの問題点について検討する。
5.1.2
モデルの使用
システムエンジニアリングでは、モデルが重要かつ多彩な役割を果たす。モデルを定義
するには、次のようないくつかの方法を使うことができる。
・
現実の世界についての特定の疑問に答えるために実施する現実の抽象化
・
現実の世界におけるプロセスや構造の模倣、類似化、再現
・
意思決定者を支援する概念的、数学的、物理的ツール
これらの定義はすべて、システム設計の検証に使用される物理的エンジニアリング・モ
デルや、トレード研究プロセスで使用する機能流れブロック図や数学的（つまり定量的）
モデルのような図式モデルなども含めた広範なものである。本項では、特に最後の数学的
モデルを中心に検討する。
トレード研究において数学的モデルを使用する主な理由は、1 組の既知量や予測可能量か
らシステムの効果、性能または技術的属性、コストを試算するためである。通例、このよ
うな出力変数をすべて提示するには、多数の個別モデルが必要になる。数学的モデルの中
心部は、その入出力データの間に認められる一連の量的関係である。この関係は、構成要
素量を一つずつ加算して合計値を得るような簡単なものにもできるし、重力場における宇
宙機の軌道を示す 1 組の微分方程式のような複雑なものにすることもできる。理想的には、
このような関係が単なる相関関係ではなく、因果関係を示すことである。
モデルのタイプ
数学的モデルを実用的に分類できる方法は多数ある。その一つは、トレード研究プロセ
スにおけるモデルの目的（つまり、モデルが扱うシステム問題と詳細レベル、モデルが主
に処理する結果変数）に応じた方法である。数学的モデルの分類に通常採用されている他
の方法は、次のような特定のモデルの属性に的を絞ったものである。
・
静的なものか動的なものか
・
決定論的なものか確率論的なものか（又は推定統計学的）
・
記述的なものか最適化するものか
これらの用語を使用すれば、モデル作成者とモデル使用者は特定の解析やトレード研究
に採用するモデルのタイプについて互いに対話できるようになる。上記リストには、いか
なる階層も含まれていない。つまり、上述の各二分分類法はいずれも、他の分類法の上に
立つものではない。
もう一つの分類法は、解析での扱いやすさという尺度に基づいたものである。この扱い
やすさという尺度の一端にある「解析」モデルでは、モデルの入力データに応じて特定変
- 127 -
数の閉鎖型解答が得られる。その尺度の他の一端では、特定の出力変数の定量化モデルが
最良のものとなる。この両極端の中間には、多種多様な形の数学的シミュレーション・モ
デルがある。
トレード研究においては、「数学的シミュレーション」モデルが特に役立つ。この種のモ
デルは、複雑な大型システムに伴う製造、輸送、ロジスティックス上の諸問題を量的に処
理するのに使用され、成功してきた。これらの問題にシミュレーション・モデルを採用す
るのは、閉鎖型解答を得るためにシステムの方程式を解析により「解く」ことができなく
ても、現在使用しているコンピュータの計算力だけで所期の結果（通常、各種想定条件に
おけるシステムの行動）が比較的得やすいからである。
トレード研究におけるもう一つの重要なモデルのタイプは、「線形、非線形、整数、動的
プログラミング・モデル」などである。その理由は、あらゆる種類の予想代替案に対する
重要な出力変数（たとえばシステム効果など）を表わす目的関数を、このモデルで最適化
できる点にある。このようなモデルの能力が一番適する状況は、システムの目的関数と制
約が十分理解されている場合である。この制約は、1 組の等式と不等式として書くことがで
きる。
モデル使用時の落とし穴
モデルは、それで表わそうとする現実の世界に関する想定条件を常に具体的に示すが、
常に何かを除外する。さらに、モデルからは精度の高い算定結果を得ることができるが、
たとえば荷重動力学的解析や回路解析のように「物理的特性」が十分解明され、厳密に定
量化できる問題を扱っている場合に限る。
しかし、トップレベルのシステム問題を扱う場合は、そのようなケースは滅多にない。
システムの本質的コスト効果問題と、モデル作成の視点から数学的に処理できる問題との
間には、往々にして大きな違いがある。たとえば、プログラム／プロジェクトマネジャが
「現在の予算環境において建造できる最良の宇宙ステーションは、どのようなものか？」
という質問をすることがある。システムエンジニアは、その質問を「採用できそうな宇宙
ステーションの設計が数少ない場合、各設計はそのユーザーに何を提供し、どれだけのコ
ストになるのか？」という問題に転換して、その質問を処理しようとする。システムエン
ジニアがその回答を得るために 1 つ（またはいくつか）のモデルに着目した場合、そのモ
デルから得られる結果は、いくつかの概算コストと、数少ないエンジニアリング関係に基
づくいくつかのユーザー資源測定項目だけになるかもしれない。システムエンジニアの質
問をもっと限定しても、そのモデルがその質問に十分対処できなければ、プログラム／プ
ロジェクトマネジャの質問にはなおさら対処できなくなる。このような意味でのモデルの
不完全性を倍加するのは、実証済みの経験的有効性よりもむしろ、数学的利便性からモデ
ルの諸関係を選択することが多いという認識である。この場合、モデルはさまざまの識見
をもたらすことはできても、モデル自体に関する実質的質問に対する決定的回答を提示す
- 128 -
ることはできない。システムエンジニアとしては、モデルの算定結果に関して技術的解釈
を行い、元の質問内容の核心をとらえたやり方でその解釈をプロジェクトマネジャやその
他の意思決定者に伝えなければならない場合が余りにも多すぎる。
すでに言及したように、複雑で大きな問題の場合は、評価すべき各種システム・アーキ
テクチャ案（および設計案）の諸側面を扱う多数のモデルを必要とすることが多い。コス
ト効果を扱う個別モデルを採用することも、階層をなす各種モデル（つまり、低レベルの
技術問題を処理し、システム・レベルの数学的モデルに役立つような結果をもたらすモデ
ル）を採用することも珍しくはない。このような状況自体にも落とし穴が潜んでいること
がある。
そのような落とし穴の一つは、システムエンジニアの意図するまたは必要とする方向へ
すべてのモデルが一緒に進むという保証がない点である。一つのサブモデルの専門的想定
条件が、そのサブモデルを土台とする大型モデルに適合しないこともある。サブシステム・
レベルの最適化がシステム・レベルの最適化と適合しない場合もある。もう一つの落とし
穴は、コスト・モデルに重要な効果変数が表記されていない場合に認められる。たとえば、
システム効果方程式における重要変数が宇宙機の信頼性であるのに、その信頼性が宇宙機
のコスト・モデルに変数として示されていない場合は、重大な断絶が生じる。このような
断絶が生じるのは、そのコスト・モデルが、コストという「見かけの」ペナルティを払わ
ずに信頼性を高めて効果を上げることができると、宇宙機の設計者に信じ込ませたからで
ある。モデルがその重要な相互関係を認識しない時は、システムエンジニアとしては、他
の者がコストと効果に関して誤った結論に達しないようにしなければならない。
適正なモデルの特性
トレード研究向けのモデルを選定する際には、適正なモデルが持つ諸特性を認識するこ
とが重要である。これらの特性としては次のものがある。
・
実施されるトレード研究との関連性
・
意思決定者の目から見た信頼性
・
対応性
・
透明性
・
ユーザーにとって理解し易いこと（ユーザーフレンドリ）
トレード研究用モデルとして合格するには、関連性と信頼性が不可欠である。関連性は、
トレード研究においてモデルが実質的なコスト効果問題にどれほどうまく対処できるかと
いう点から判定される。モデルの信頼性は、その数学的関係の論理的一貫性と、過去の予
測成功（つまり的中）例から判定される。過去の予測成功例はモデルに信頼性を与えるが、
その予測に対する観測による裏付けが通常非常に乏しいため、十分な検証（モデルによる
予測が現実と一致するという実証）を得るのは非常にむずかしい。しばしば過去のプロジ
ェクトの遺産として残された実証済みの確実なモデルを使用する方が確かに有利だが、常
- 129 -
に採用できるとは限らない。新しい問題に対処すべきシステムの場合には、往々にしてそ
のトレード研究向けに新しいモデルを開発する必要がある。その場合は、完全な検証は問
題外となり、システムエンジニアとしては、論理的一貫性と、外部からの限られた形の独
立した確証を得るだけで満足しなければならない。
モデルの対応性とは、トレード研究で検討する各種代替案を識別する能力という測定項
目である。たとえば対応性のある月面基地コスト・モデルは、各種のシステム・アーキテ
クチャまたはシステム設計、運用概念、ロジスティックス戦略関係のコストをそれぞれ識
別することができる。
もう一つの望ましいモデル特性は透明性である。これは、モデルの数学的関係、アルゴ
リズム、パラメータ、支援データ、内部作用などがユーザーに公開されている場合に得ら
れる。この透明性の利点は、モデルの算定結果をたどれること（トレーサビリティ）にあ
る。誰もがモデルの算定結果に同意するわけではないが、少なくともそうした結果がどの
ようにして引き出されたかという点を誰もが知ることができる。透明性は受領過程にも役
立つ。モデル関係の文書が完全で、意見を求めるために公開された場合の方が、そのモデ
ルは受け入れられやすい。特許権付きモデルがしばしば受け入れられないのは、透明性に
欠けているからである。
最前線のユーザーにやさしいという特性は、システムエンジニアがモデルの使い方とそ
の入力データの準備のしかたを習得しやすいということと関係がある。末端ユーザーにや
さしい特性は、モデルの算定結果を解釈し、選定規準を採用して試験的に選定を行うため
トレード研究報告書を作成するという作業に関係がある。
5.1.3
選定規準の選定
トレード研究プロセスの解析部分は、数少ないシステム・アーキテクチャ（およびその
後のシステム設計）におけるシステムの効果、システムの基本的性能または技術的属性、
システムのコスト（ならびに不確定範囲）に関する特定情報を提供するという役割を果た
す。一つの代替案を選定するには、こうしたデータをまとめる必要がある。この段階では、
こうしたデータに選定規準を適用して各種代替案を好適順にランク付けする。
現実のシステムエンジニアリングにおける決定事項の構成と複雑さは、しばしばこのよ
うなランク付けの作業を困難なものにする。高い効果を得ることは、ほぼ常に高いコスト
を負担することや大きな不確定要因に直面することを意味する。効果とコストのレベルが
それぞれ異なる多くの代替案から最適案を選定するためには、システムエンジニアとして
は、一方が他方にどれだけ価値があるかを知っておかなければならない。明確なコスト効
果目的関数が選択決定を導く一助として使用できることは滅多にない。予算上システムの
縮小決定を下す必要のあったシステムエンジニアならば、まさにそう証言するであろう。
もう一つの重大な問題は、システムの基本的性能または技術的属性は容易に特定できて
- 130 -
も、システム効果の表記法または測定方法は案出できそうにないという点である。このよ
うな基本的属性は、製品開発プロセスにおいて、システム設計がその性能要求事項を満た
すかどうかを評価するために追跡調査する技術性能測定（TPM＝technical performance
measure)項目と同じ場合が多い。この場合、システム効果にはせいぜいいくつかの削減で
きない項目があるにすぎない。
どんな選定規準を採用すべきかという問題は、意思決定学
ン・リサーチ、経済学
−
−
経営学、オペレーショ
の多くの書物や論文の主題となってきた。NASA（米国航空宇
宙局）のトレード研究には、多くの選定規準が適用されている。特定のトレード研究にど
の選定規準を採用するかは、次のような多くの要因に左右される。
・
システム設計の分解レベル
・
プロジェクト・ライフサイクルにおけるフェーズ
・
プロジェクトがシステム効果モデル全体を維持しているかどうか
・
定量化しにくい主観的要因が選定にどれほど貢献するか
・
不確定性が極めて高いか、それとも付随問題として効果的に処理できるものか
・
各種代替案が量的に異なるアーキテクチャ／設計からなるものか、それともいくつ
かの量的な面が異なるにすぎない多くの類似したものからなるものか
このハンドブックでは、NASA のトレード研究向けにいくつかの選定規準と、各選定規準
を適用する場合のいくつかの一般的条件だけを提示する。つまり、あらゆるケースに適用
する試みも行われたことがない最終的指針を示すにすぎない。
表 3 ではまず、トレード研究におけ
る不確定性の重要度に応じて選定規準
Ａ
を分類している。この分類法は、2 種
効果
類の意思決定問題（確定条件下におけ
Ｂ
Ｃ
A、B、Cは、リスク・
パターンを異にす
る設計概念
る意思決定と不確定条件下における意
思決定）を反映したものである。不確
定性はシステムエンジニアリングの一
部として内在するものだが、図 2 を参
照すると、その区別は最も明確に説明
コスト
図24 リスク・パターンを異にする設計概念の
評価結果
できる。ここでは、図 2 を図 24 として
転載する。前者の意思決定では、トレ
ード研究における各種代替案のシステム効果、システム性能または技術的属性、システム・
コストの評価結果は、代替案 B のものに相当するように思われる。後者の意思決定では、
代替案 C のものに相当するように見える。代替案 A のものに相当するように見える場合は、
不確定条件が適用されるべきだが、そのように扱われない場合が多い。
表 3 では、上述の各種意思決定問題をさらに、システムエンジニアが最適案を選定でき
- 131 -
るようにコストと効果の評価結果を数量で表わした場合と、コストと効果を数量で表記で
きない場合という 2 つに細分化している。
表3
NASA のトレード研究に適用される選定規準例
効果とコスト
トレード研究における不確定性の重要度
確定性が付随的なものか又は考慮さ
不確定性が極めて重要な場合
れない場合
数量で表記できる場合
純益を最大にする。
期待有用性を最大にする。
コスト上の制約を受けるが、効果を最
大にする。
最大損失を最小にする（「ミニマ
ックス」）
効果上の制約を受けるが、コストを最
大にする。
数量で表記できない場合
コスト効果目的関数を最大にする。
価値関数（つまりメリット数）を最大
にする。
期待有用性を最大にする。
各目的上の制約を受けるが、価値関数
を最大にする。
性能要求上の制約を受けるが、コスト
を最小にする。
不確定性が付随的なものか又は考慮されない場合の選定規準
「純益（利益−コスト）を最大にする」代替案を選定するための規準は、ほとんどの費
用便益分析に使用されている。しかし、費用便益分析が採用されるのは、たとえば水資源
プロジェクトの評価という従来の適用対象のように、プロジェクトの収益をコストと同じ
単位で算定できる場合だけである。
もう一つの選定規準は、「所定のコスト・レベルで効果を最大にする」代替案を選択する
ことである。この規準を適用できるのは、システム効果とシステム・コストを的確に測定
でき、適切なコスト・レベルがわかっている場合である。この選定規準の目的は、各種代
替案を比較してランク付けを行うことである。したがって、この規準を実際に適用する場
合は、各種代替案を同等コストに基づいて評価する必要がある。ある種のトレード研究で
は、この点はまったく問題にならない。たとえば、システムのサイズや出力、プラットフ
ォームや搭載機器の基数を変更するだけですむ。しかし、その他のトレード研究では、こ
れが不可能となる場合もある。
それと関連のあるもう一つの選定規準は、「所定の効果レベルでコストを最小にする」代
替案を選択することである。この選定規準では、システム効果とシステム・コストを的確
に評価でき、適切な効果レベルがわかっていることが前提条件となる。この規準の場合も、
実際に適用するには、各種代替案を同等効果に基づいて評価する必要がある。この規準は、
次のような意味で上述の規準と対をなすものである。コスト・レベルが一定の場合は、両
- 132 -
方の規準により同じ代替案が選択されることがある。同様に、効果レベルが一定の場合も、
両方の規準により同じ代替案が選択されることがある。
競合する各種代替案のコストや効果を実際上同等にできず、コストの上限や効果の下限
により 1 件を除くすべての代替案が不適格になる場合は、図 4（第 2.5 項）に示すような
コスト効果目的関数を明示的または暗黙的に形成する必要がある。コスト効果の目的関数
は、コストと効果のすべての組み合わせにとって価値のある唯一の測定値を与える。この
選定規準を採用すると、コスト効果目的関数の最高値を持つ代替案が選択される。
コストや効果を数量で表記できない場合は、別種の選定規準が必要となる。最適案を選
定するには、「多目的」選定規準が必要である。多目的選定規準では、ある意味で、競合す
る各種目的の間で最もバランスの取れた目的を示す代替案を選択しようとする。このよう
な選択を行うには、各目的をどの程度達成するかという面から各代替案を（何らかの定量
方法により）測定する必要がある。たとえば、その目的が、国家の威信、改良や拡張の可
能性、科学データの回収、低コスト化、国際提携の可能性という場合もあろう。そのよう
な目的に関する各代替案の「評価点」すべてを価値関数に導入すると、その代替案の総合
示性数が得られる。そうした評価点の導入のしかたは、意思決定者の選択構成を反映した
ものとすべきである。それによって、「価値関数を最大にする」（つまり、メリット数が最
も高い）代替案が選択される。「要するに、この選択規準は、多目的の意思決定問題を、一
つの測定可能な目的をもつ問題に転換するものである。」
唯一の方法ではないが、各代替案のメリット数を形成する一つの方法は、各目的ごとに
算定した評価点すべてを線状に組み合わせる
−
つまり、その評価点の加重合計を算定
するという方法である。MSFC−HDBK（Marshall Space Flight Center−Handbook＝マーシ
ャル宇宙飛行センター・ハンドブック）−1912「システムエンジニアリング」（Systems
Engineering)（第 2 巻）でも、この選定規準を推奨している。メリット数の算定に使用す
る重みは、「事前に」指定するか、多属性有用性理論（MAUT＝Multi-Attribute Utility
Theory) を使って算定することができる。メリット数を形成するもう一つの技法は、解析
的階層プロセス（AHP＝Analytic Hierarchy Process）である。MAUT や AHP を自動化するに
は、市販のマイクロコンピュータ・ソフトウェアパッケージを利用することができる。い
ずれの技法においても、間違った重み、目的、属性を選定すると、最適案があいまいなも
のになる。また、どの技法を採用するにしても、各評価者には、その所属団体の先入観や
好みを反映させる傾向があるかもしれない。そのため、その算定結果が評価チームの構成
に左右されることもある。（枠内補足記事「解析的階層プロセス」と「多属性有用性理論」
を参照）。
もう一つの多目的選定規準は、指定された各目的に適合するものから最高メリット数を
示す代替案を選択することである。NASA の調達過程においては、多くのソース評価委員会
（SEB＝Source Evaluation Board)がこの選定規準を広く採用している。特定の技術的目的
（要求事項）に適合する各見積書に対しては、技術設計、価格、システムエンジニアリン
- 133 -
グ・プロセスの質といった各種属性に関する評価が行われる。この選定規準を適用する場
合は、SEB が評価する各種属性は入札者に知らさせるが、評価の重みは知らされないことも
ある。（NHB(NASA Handbook＝NASA ハンドブック）5103.6B を参照）。
トレード研究においてシステム効果の測定は行えないが、性能または技術的属性を定量
化できるという場合に採用できる選定規準は、「所定の性能または技術的属性レベルでコ
ストを最小にする」代替案を選択することである。この選定規準では、システム・コスト
を的確に測定でき、しかもそのコストが、制約とみなされる定量化済みの性能または技術
的属性すべてに関連があることが前提条件となる。この選定規準の場合も、実際に適用す
るには、すべての代替案を同等の性能または技術的属性に基づいて評価する必要がある。
トレード研究において各種代替案を一連の連続した数学的関係として記述できない場合は、
この選定規準も実際に採用できない。
- 134 -
解析的階層プロセス
解析的階層プロセス（AHP＝Analytic Hierarchy Process）は、一連の対比較を通して数
件の代替案それぞれに対するメリット数を算定する意思決定技法である。AHP の手順は通常
6 段階に分けられている。
（1）
検討中の各種代替案を一覧表に表わす。
（2）
たとえば、科学データの回収、国家の威信、技術の進歩といった 1 組の高レベル
評価目的を設定する。
（3）
各高レベル評価目的をいくつかの階層的評価属性に分解し、その目的の意味を明
確化する。
（4） 選定した人（「専門家」）に対して所定のインタビューを実施するか、その人に所
定の質問書に記入してもらい、評価目的と評価属性の相対的重要度を対比較によ
って算定する。
（5）
各評価属性に関する各種代替案の個別的対比較を各評価者に行わせる。こうした
主観的評価結果は、別に策定した AHP プログラムに対する生の入力データとな
り、各代替案のメリット数が得られる。このメリット数は、各評価者自身が算定
した相対加重に基づいた値である。
（6）
各種代替案のランク付けについて合意が得られるまで、質問書と AHP による評価
手順をくり返す。
AHP を採用すると、すぐ合意に達することもあれば、フィードバックを数回くり返す必要
がある場合もある。フィードバックでは、各オプションの算定値（各評価者と評価グルー
プ全体の算定値）、評価差が生じた理由、特定した論争点や不一致点などを報告する。各評
価者は属性の重みとその選択に関する主観的判定を変えることもある。この時点で、一致
しないさまざまな選択をより詳細な研究の対象とすることができる。
AHP では、対比較により明らかになった基本的選択「ベクトル」（量と方向を持つ）の存
在を想定する。これは強力な想定だが、参加した評価者にしか適用できないものである。
各代替案ごとに得られたメリット数は、評価グループ全体の主観的判定結果であり、必ず
しも再現可能な判定結果ではない。AHP の詳細については、Thomas L. Saaty 著"Analytic
Hierarchy Process"（1980 年）を参照されたい。
- 135 -
多属性有用性理論
多属性有用性理論（MAUT＝Multi-Attribute Utility Theory）は、単純な抽選により選
択を示すという一連の比較を通して数件の代替案それぞれのメリット数（または有用性）
を算定する意思決定技法である。MAUT による意思決定メカニズムを簡単に示すと、次の 6
段階からなる。
（1） 各代替案の特性を示す記述的だが定量化できる 1 組の属性を選択する。
（2） 検討中の各代替案ごとに、各属性の値をだす。属性値に伴う不確定性を明示的に処
理できる場合は、このような属性値を点推定値や確率分布で示すこともできる。
（3） 各属性に対する属性有用性関数を設定する。属性有用性関数は 0 から 1 の範囲とす
る。何らかの属性の最も低い希望値 xi0（採用できそうな値の範囲外）には有用性値
0 を割り当て、最も高い希望値 xi*には有用性値 1 を割り当てる。つまり、Ui(xi0）
＝0、Ui(xi*）＝1 である。属性値 xi の有用性値は最も低い希望値と最も高い希望値
の中間にあり、xi 値を確実に得ることと、確率 pi で xi0 または確率 1−p で xi*を
出す抽選との間で意思決定者が無関心となるような中間の値 xi を見つけることによ
り評価される。MAUT の計算から、Ui(xi)＝pi Ui(xi0）＋（1−pi)Ui(xi*）＝1−pi と
なる。
（4） 属性有用性連続関数の近似値となる離散点が十分得られるまで、無関心度を明らか
にするプロセスをくり返す。
（5） 各種属性有用性関数を組み合わせて多属性有用性関数を形成する。この場合も、単
純抽選方式を採用して、1 組の特定属性値を確実に得ることと属性値の抽選との間に
ある無関心度を明らかにする。最も単純な形で表わすと、得られた多属性有用性関
数は各種属性有用性関数の加重合計となる。
（6） 多属性有用性関数を使用して各代替案を評価する。
MAUT に伴う最大の難題は、意思決定者や評価者が抽選という点を考えなければならな
いことである。この点は、経験豊かなインタビュアーならたいてい克服できる。MAUT は、
不確定性に直面した時の個人の行動のしかたに関する 1 組の数学的公理に基づいたもので
ある。評価者がこの公理に従う限り、各種代替案のランク付けにおける論理的一貫性は確
保される。ただし、常にそうなるという保証は得られない。MAUT については、Keeney、
Raiffa 共著 "Decisions with Multiple Objectives: Preferences and Value Tradeoffs"（「多
目的事項に関する意思決定：選択と価値のトレードオフ」（1976 年）でさらに幅広く検討さ
れている。NASA 問題に対する MAUT の教科書的適用については、Jeffrey H. Smith その
他共著 "An Application of Multiattribute Decision Analysis to the Space Station
Freedom Program, Case Study: Automation and Robotics Technology Evaluation"(「スペ
ース・ステーション『フリーダム』計画に対する多属性意思決定解析の適用、ケーススタ
ディ：自動化及びロボット技術の評価」）（1990 年）に記載されている。
- 136 -
不確定性が極めて重要な場合の選定規準
トレード研究において、各種代替案のシステム効果、システム性能または技術的属性、
システム・コストの測定値が図 22 に示す代替案 C の測定値のようになる場合は、最適案の
選定を別の方法で処理する必要があるかもしれない。その理由は、コストや効果の評価結
果に認められる大きな格差を処理する時に、リスク回避行動を示すという意思決定者の一
般的な傾向が認められるからである。その場合、何らかの確率的結果変数の「期待値」は
その変数の満足すべき点測定値とはならない。
この種の意思決定問題を処理するために、システムエンジニアとしてはフォン・ノイマ
ン−モーゲンスターン（von Neumann-Morgenstern)選定規準を導入したいと思うであろう。
この場合、各種代替案は「賭博」（または抽選）のように処理される。通常、意思決定樹形
図を作成すれば、各結果の発生確率がわかるか、又は主観的に推定することもできる。フ
ォン・ノイマン−モーゲンスターン選定規準では、個別に設定した有用性関数を各結果に
適用し、「期待有用性を最大にする」代替案を選択する。抽選の結果をドル単位で算定でき
る場合には、この選定規準は適用しやすい。多属性の場合はもっと複雑になるが、原則は
変わらない。
フォン・ノイマン−モーゲンスターン選定規準の基盤となるのは、不確定性に直面した
時に個人はどのように行動すべきかという問題に対する 1 組の数学的公理である。この規
準を実際に適用する場合は、各代替案の「自然な状態」（以下においては単に「状態」と略
称する）を列挙できること、各代替案に関して列挙した各状態に関連のある結果に関する
知識、各種状態の確率、意思決定者の設定した有用性関数の数学式が必要になる。この選
定規準は、各種システム調達案の評価にも使用されている。意思決定解析、意思決定樹形
図、確率的リスク評価などの関連問題については、第 4.6.3 項を参照されたい。
この種の意思決定問題に対するもう一つの選定規準は、「ミニマックス規準」というもの
である。この規準を適用する場合、システムエンジニアは各代替案ごとに列挙したそれぞ
れの状態の損失関数を算定する。この規準では、「最大損失を最小にする」代替案を選択す
る。この規準を実際に適用する場合は、各状態を列挙し、その損失関数を設定できること
が前提となる。「最悪のケース」を処理することができるため、この規準は軍事システムに
ある程度適用されている。
5.1.4
トレード研究プロセス：
まとめ
システム・アーキテクチャと設計に関する決定を行う。トレード研究プロセスの目的は、
設計の最適化である。このプロセスの基本的手順は次のとおりである。
・
システムの目標、目的、制約は何か、その目標、目的、制約に適合するにはシステ
ムは何をすべきかという点を明らかにする
求事項を理解する
- 137 -
−
つまり、運用環境における機能要
・
機能要求事項を満たすための各種手段をいくつか案出する。プロジェクト・ライフ
サイクルの前半フェーズではシステム・アーキテクチャに的を絞り、後半フェーズ
ではシステム設計に重点を置く
・
各種結果変数（システム効果、システムの基本性能または技術的属性、システムの
コスト）という面から各種代替案を評価する。この段階では、各種結果変数間の関
係を認識させるだけではなく、性能要求事項をどんな定量値にすべきかを判定する
一助となるという点で、数学的モデルが役に立つ
・
適切な選定規準に従ってこれら代替案のランク付けを行う
・
有望性の低い代替案を落とし、必要に応じて次の分解レベルへ進む
このプロセスは単独作業として実施することはできない。このプロセスを効果的に実施
するには、それぞれ異なる技能を持つ人たち（システムエンジニア、設計技術者、各種専
門技術者、プログラム・アナリスト、意思決定科学者、プロジェクトマネジャ）が協力し
なければならない。適正な定量方法と選定規準を採用しなければならない。トレード研究
の想定条件、モデル、研究結果は、プロジェクト関係保管記録の一環として文書化する必
要がある。
5.2
コストの定義とモデル作成
この項では、システム解析におけるコストの役割、その算定方法、管理方法、予測方法
について述べる。システムエンジニアリングにおいては、コストとその予測が極めて重要
になる。その理由は、最もコスト効果の高いやり方でシステムの諸目標を達成するという
システムエンジニアリングの主目的にある。各代替案のコストは、システムエンジニアリ
ング・プロセス中に実施されるトレードオフ研究における最も重要な結果変数の一つとみ
なすべきである。
そうすることによって、各種代替案から最適案を合理的に選択する一助となることが、
コスト予測の役割の一つとなる。もう一つは、プロジェクト・ライフサイクルにおける一
つの管理方式としての役割である。プロジェクト・ライフサイクルにおける各種審査のた
めに得たコスト算定値は、システムの目標と目的がまだ有効かつ達成可能とみなされてい
るか、各種制約と境界は維持すべき価値があるかどうかを判定する場合に重要となる。シ
ステムの目標と目的が各種サブシステムまで正しく浸透しているかどうかを判定する場合
も、こうしたコスト算定値が役に立つ。
システム設計と運用概念が成熟するに従って、コスト予測も成熟化すべきである。各審
査では、コスト予測を提示して、プロジェクトの完成まで利用できそうな資金と比較する
必要がある。初期の審査で提示されたコスト予測は、通常プロジェクト続行の認可を下す
根拠となるので、特に注意を払う必要がある。システムエンジニアとしては、プロジェク
トマネジャに対して現実的なコスト予測を提示できなければならない。このコスト予測が
- 138 -
得られなければ、予算超過になりがちで、システム開発過程全体に対する内部と外部から
の信頼性も脅かされる。
5.2.1
ライフサイクル・コストとその他コストの算定
システム解析とシステムエンジニアリングにおいてコストを正しく処理するためには、
多くの問題に取り組まなければならない。そのような問題としては次のものがある。
・
計上すべきコスト項目は何か？
・
異なる時期に生じるコストはどのように処理すべきか？
・
ドル単位で算定しにくいコストについてはどう処理すべきか？
計上すべきコスト項目
一つの代替案のコストを最も包括的に算定したものは、ライフサイクル・コストである。
NHB(NASA Handbook＝NASA ハンドブック）7120.5 によると、システムのライフサイクル・
コストとは、「（システムの）計画耐用期間に（その）設計、開発、生産、運用、保全、支
援、完了にかかったか、又はかかると予測される直接費、間接費、再発費、非再発費、そ
の他関連費の総計」である。もっと平易に定義すると、システムのライフサイクル・コス
トとは、システムの耐用期間全体にわたりシステムの取得、所有、廃棄にかかる総経費と
いうことになる。システムのライフサイクル・コストは、トレード研究における各種代替
案の評価時に予測して使用すべきである。システムエンジニアとしては、行政事務の年間
仕事量（work-year)のように、プロジェクト費として明示する必要のなさそうな経営資源
も、ライフサイクル・コストに含めるべきである。正しく算定すれば、システムのライフ
サイクル・コストは、NASA にとって最良のシステム・コスト算定値となる。
ライフサイクル・コスト
システム調達費
運用・支援費
DDT＆E（設計、開発、試験、評価）
非再発費
システム運用費
システムHW／SW（ハードウェア／
ソフトウェア）再発調達費
総合ロジスティックス支援初期費
総合ロジスティックス支援費
計画済み製品改良費
施設初期費
打ち上げ・組立費
（必要な場合のみ）
図25 ライフサイクル・コスト項目
- 139 -
廃棄費
（必要な場合のみ）
ライフサイクル・コストは、図 25 に示すように、いくつかの項目に分割されている。上
述の非公式な定義を適用すると、ライフサイクル・コストは、（a）使用可能なシステムの
調達費、（b）耐用期間におけるシステムの運用・支援費、（c）耐用期限に達したシステム
の廃棄費という 3 項目からなる。システム調達費に含まれるのは、DDT＆E（設計、開発、
試験、評価）費とハードウェア・ソフトウェア調達費だけではない。その他に、要員の初
期トレーニング、初期予備品、システムの技術文書、支援設備、施設、さらに運用予定サ
イトにシステムを設置するために必要な打上げ業務などにかかる初期費も含まれる。
システムの運用・支援費には、運用要員費と支援作業費、現行の総合ロジスティックス
支援費、計画済み製品改良費などが含まれる。大型システムの場合、このような費用は年
間ベースで莫大な額にのぼることが多く、運用年数全体における累積はライフサイクル・
コストの大半を占めることもある。
プロジェクト・ライフサイクルの開始時には、このような費用すべてが将来支払うべき
ものとして存在する。だが、プロジェクト・ライフサイクルのどんな時点でも、何らかの
費用がすでに支出されている。この支出済み資金を「埋没費用」（sunk costs）という。ト
レード研究の目的上、検討中の代替案の埋没費用は、どんなに多額でも無視される。現行
の設計トレードに関係のある費用だけが、将来支払うべきものである。その論拠は簡単だ。
過去に費やした資金の支出方法はいまさら変更できないというわけである。決定を下せる
のは、将来の資金支出方法に関してだけである。埋没費用が、他の代替案に関連のある特
定代替案を継続させるためのコストを変えることもあるが、各種代替案から最適案を選択
する時は、将来支払うべき費用のみを計上すべきである。
耐用期限に達したシステムが、プラスの「残余価格または残存価格」をもっている場合
もある。こうした価格が生じるのは、システムの売却や物々交換を行える場合や、他のシ
ステムに転用できる場合である。ライフサイクル・コストには、この残余価格も計上する
必要があるが、通常は負のコストとして処理される。
期間コスト
ライフサイクル・コストには、通常数年間にわたって発生する費用も組み込まれる。い
ろいろな年に単発的に生じた費用は、社会にとっては実際上それぞれ異なる資金を表わす
ので、同じように扱うことはできない。賢明な方法で今日投資した 1 ドルは、翌年には 1
ドルを多少超える金額となって戻ってくる。今日の 1 ドルを翌年の 1 ドルと同じように扱
うと、このような取引の可能性を無視することになる。
- 140 -
現行割引価格の算定方法
現行割引価格（PDV＝Present Discounted Value）の算定は、各種費用の動向を明確に比較
できるように、各費用動向を唯一の数値にまとめる方法である。時間を個別変数として扱
うか連続変数として扱うか、製品の期限を有限とするかどうかによって、いくつかの PDV
式が使用されている。下に示す方程式は、費用を年額で推定した場合に各種システム案の
評価に使用できる。そのプロジェクトの予測耐用年数を T 年とする。システム案 i の場合
は、次式となる。
T
PVDi ＝ ∑ Cit (1+r)-t
t=0
この場合、r は年間割引率、Cit は t 年におけるシステム案 i の推定コストである。
年間費用が推定されると、評価に欠かせないのは割引率の選択である。割引率は、PDV に
対する支出費用の寄与率がどれほど多いか少ないかという点に最終的に関係してくる。数
年間にわたって発生する費用を処理する方法として、PDV の算定が一般に認められている。
しかし、システムエンジニアリングのトレード研究で採用すべき適切な割引率をめぐって
は、幾多の異論や混乱が認められる。行政管理予算局（OMB＝Office of Management and
Budget）では、上記方程式に固定ドル価格（何らかの特定時点における価格レベルに調整
したドル価格）を使用する場合、NASA システムには 7 パーセントの割引率を適用すること
を命じてきた。名目ドル価格（当年、現行、実年ドル価格ともいう）を使用した場合は、
OMB 指定の年間割引率を、その年の推定インフレ率分だけ引き上げる必要がある。いずれの
方法でも、本質的には同一の PDV が得られる。詳細については、行政管理予算局（OMB）の
回報 A−94 "Guidelines and Discount Rates for Benefit Cost Analysis of Federal
Programs"（「連邦プログラムの費用便益分析に関する指針及び割引率」）（1992 年 10 月）を
参照されたい。
いろいろな年の費用を同一基準で算定できるようにする一つの方法は、将来の費用を割
り引くことである。割引方式を将来の各種費用動向に適用すると、その各種費用動向の現
行割引価格（PDV＝Present Discounted value）が得られる。割引の効果は、短期的に発生
する費用に対する将来発生する費用の寄与率を引き下げることである。インフレがあって
もなくても、割引を実施すべきであるが、適正な割引率を採用できるように十分配慮を払
う必要がある。（枠内補足記事「現行割引価格の算定方法」を参照）。
トレード研究においては、各種代替案の各種費用動向が経時的に変動することが多い。
別の代替案に比べ取得費が高くても、運用・支援費が安い代替案は多い。割引を行わなけ
れば、どれがライフサイクル・コストの安い費用動向かがわかりにくくなる。トレード研
究では、各代替案に対するライフサイクル・コストの現行割引価格（PDV）を出力変数とし
て報告すべきである。
- 141 -
算定しにくい費用
実際には、特殊な問題を提起する費用項目もある。このような特殊問題は、NASA システ
ム特有のものではなく、通常次の場合に生じる：（a）各種代替案で削減できない予測死亡
事故件数に差がある場合、（b）外的要因が認められる場合。コストのかかる外的要因例と
しては、打上げシステムによる環境汚染と軌道周回廃棄物（orbital debris）の 2 つがあ
る。このような資金の使途はドル価額に換算しにくいので、その費用は通常「消耗品費」
と呼ばれている。トレード研究におけるこの種の費用の一般的処理方法は、その費用を無
視するのではなく、ドル費用と共に追跡するというものである。
5.2.2
ライフサイクル・コストの管理（コントロール）
プロジェクトマネジャやシステムエンジニアは、（フェーズ A の終了時に設定された）シ
ステムのライフサイクル・コストが当初から NASA の予算と戦略優先順位に適合しているか、
「プロジェクト・ライフサイクル全体を通して適合することが実証されている」かどうか
を確認しなければならない。NHB（NASA Handbook ＝NASA ハンドブック）7120.5 によれば、
NASA のプログラム／プロジェクトは以下の条件を満たさなければならない。
・
プロジェクトのライフサイクル全体にわたりそのライフサイクル・コストを予測、
評価、監視、管理（コントロール）できる効果的な手段を開発し、維持する
・
ライフサイクル・コストの予測を、適正に設定された技術ベースライン、詳細なプ
ロジェクト・スケジュール、一連のコスト予測用想定条件に関係づける
・
各種レベルのシステム要求案とシステム機能案のライフサイクル・コストを明確化
する
・
経時的調達コストと技術パラメータを NASA 本部に報告する
これらの目的を達成するためにシステムエンジニアが採用できる対策は多数ある。「シ
ステムエンジニアリング・プロセス初期段階の各種決定事項は、その結果生じるシステム
のライフサイクル・コストに最大の影響を与える傾向がある」。通例、好適システム・アー
キテクチャの選定時点までには、システムのライフサイクル・コストの 50−70 パーセント
がすでに「固定」されている。システム基本設計の選定時点までには、この率が 90 パーセ
ントに達することもある。このことは、こうした選定過程で中心的役割を果たすシステム
エンジニアにとっては大きなジレンマとなる。意思決定が極めて重要となる時点でも、そ
のような選択対象案に関する情報が極めて不確かな状態にある。各種費用に関する不確定
性は、システムエンジニアリング上の紛れもない事実である。
これは、プロジェクト・ライフサイクルの初期段階（フェーズ A と B）に各代替案のライ
フサイクル・コストに関する適正情報を得ようとする努力が、非常に大きな成果を生む可
能性を持っているという事を示唆している。システムエンジニアとしては、ライフサイク
- 142 -
ル・コストの主要誘因（drivers）が何かを十分理解する必要がある。その場合に考慮すべ
き主な問題点としては、次のものがある。各代替案が公知の技術にどの程度依存したもの
か？
のか？
在来型製法でシステムを製造できるのか、それとももっと精密な製法が必要となる
各システム設計案の検証と妥当性確認を行うには、どんな試験が必要か？
試験にはどの程度の費用がかかるのか？
その
各代替案には、どの程度の信頼性が必要か？
どんな環境基準や安全基準を満たさなければならないのか？
運用期間が長く、複雑な作業を伴うと思われるシステムの場合、そのライフサイクル・
コストは調達費をはるかに上回る可能性がある。そのため、このシステムの場合は、シス
テムエンジニアリング・プロセスの初期段階に信頼性、保全性、支援性、運用技術などの
専門分野の技術者を参加させることが特に重要となる。これらの専門技術者は、ライフサ
イクル・コストを適正に予測する上で欠かせない存在である。
各種代替案のコストに関する適正情報を収集するもう一つの方法は、プロジェクトにお
いて、比較を目的として「独立的に」コスト予測書を作成することである。
ライフサイクル・コストを管理するもう一つの方法は、プロジェクト・マネジメント方
法の一環として、「ライフサイクルコスト・マネジメント計画」を策定することである。（ラ
イフサイクルコスト・マネジメントは、従来「デザイン・ツウ・ライフサイクルコスト」
（design-to-life-cycle cost)と呼ばれてきた）。そうした計画では、ライフサイクル・コ
ストを設計目標として設定する。調達費や運用・支援費はおそらく準目標として設定する
ことになるであろう。ライフサイクルコスト・マネジメント計画の目的としては、特に次
の点を挙げることができる。
・
ライフサイクル・コストを予測するために、一連の一般的な基本原則と想定条件を
明確化する
・
ライフサイクル・コスト分析には慣行上最適な方法、ツール、モデルを使用する
・
プロジェクト・ライフサイクル全体を通して見積りライフサイクル・コストを追跡
調査する
・
「最も重要な点」として、トレード研究と正式の変更要求評価を通して設計・開発
過程にライフサイクル・コストの検討を導入する
トレード研究と正式の変更要求評価は、システムの効果とライフサイクル・コストのバ
ランスを保つ手段となる。設計・開発過程にライフサイクル・コストの検討を導入した場
合に避けがたい作業の複雑化を過小評価すべきではないが、コスト効果を高めるという利
点も過小評価すべきではない。ライフサイクル・コストのトレード項目が多くなると、こ
の複雑性は一層高まる。
宇宙ステーション「アルファ」計画からは、そうしたトレード項目例が多く得られる。
たとえば、「アルファ」の軌道交換ユニット（ORU＝Orbital Replacement Unit）の平均故
障間隔（MTBF＝Mean Time Between Failures）が増大したことによるライフサイクル・コ
ストへの影響を考えてみよう。この MTBF の増大は取得コストを引き上げる恐れがある上に、
- 143 -
宇宙ステーションの質量を増大させることもある。しかし、年間保守時間数と年間交換用
予備品の総重量は減少する。軌道上の予備品を少なくしても、宇宙ステーションのアベイ
ラビリティが変わらないこともある。しかも、予備品貯蔵用の貴重な内部容量を節約でき
る。軌道交換ユニット（ORU）が宇宙ステーションの外部にある場合は、船外作業量とその
関連ロジスティックス支援作業量も減少する。そのような複雑な相互関係があるため、最
適点がどこにあるかは実にわかりにくい。システムエンジニアとしては、少なくとも各代
替案のライフサイクル・コストを評価できなければならない。（軌道交換ユニットの平均故
障間隔（ORU
MTBF）による運用と運用費への影響については添付資料 B.8、総合ロジステ
ィックス支援については第 6.5 項を参照）。
5.2.3
コスト予測
通常、プロジェクト・ライフサイクルの進展に伴い、各ライフサイクル・コスト項目の
予測に採用する技法も変わってくる。フェーズ A における予算見積りとライフサイクル・
コストのトレードに採用する方法とツールは、フェーズ C や D におけるそうした作業を支
援できるくらい十分詳細なものではないこともある。さらに、プロジェクト・ライフサイ
クルが進むにつれて、要求事項やシステム設計も成熟化し、作業明細構成図（WBS＝Work
Breakdown Structure）にますます詳細に示されるようになる。そのため、コスト予測技法
もより高い分解度で適用できるようにすべきである。
以下においては、パラメータ型コスト・モデル法、類推法、積み上げ法という 3 つの予
測技法について概説する。通例、この技法の選択は、プロジェクト・ライフサイクルの各
時点におけるコスト・アナリストの情報収集状態に応じて異なってくる。表 4 ではこのよ
うな依存関係を示す。
表4
フェーズ別コスト予測技法
技法
パラメータ型コス
ト・モデル法
類推法
積み上げ法
プリフェーズ A と
フェーズ A
主要
フェーズ B
フェーズ C／D
採用可能
採用可能の場合もある。
採用可能
採用可能の場合もある
採用可能
採用可能
採用可能の場合もある。
主要
「パラメータ」（または「トップダウン」）型コスト・モデルが一番採用されるのは、既
知や予測可能な主要変数が少ししかない場合である。最も一般的なパラメータ型モデル例
は、統計的コスト推定関連性（CER＝Cost Estimating Relationship）モデルである。十分
確立した統計方法を使用すれば、システムの 1 つまたは 2 つ以上の特性とそのコストの関
係を示す 1 組の統計的データから唯一の方程式（または 1 組の方程式）が引き出される。
- 144 -
宇宙機ハードウェア調達コスト予測用の統計的 CER モデルは、すでに多数開発されている。
このようなモデルでは、通例、ハードウェアの重量の他、設計の複雑性、継承性といった
その他の特性を使用してコスト予測値を得る。同様に、ソフトウェア用 CER モデルもすで
に開発されているが、この場合は経営資源コード行とその他要素に関する判定に基づいて
開発費を予測する。（枠内補足記事「統計的コスト推定関連性：事例と落とし穴」を参照）。
統計的コスト推定関連性：
事例と落とし穴
ほとんどのコスト分析に通用する 1 つのモデルは、統計的データに基づく「コスト推定
関連性」（CER＝Cost Estimating Relationship）モデルである。通常、このモデルの形は、
1 つまたは 2 つ以上の記述的特性に応じたコスト（従属変数）を示す一次方程式である。こ
の一次方程式の係数は、統計的回帰技法を使用して、完成済みの同種プロジェクトから得
た統計的データを当てはめて推算したものである。この種のモデルは、解析的かつ決定論
的なものである。宇宙用として認定された地球周回用受信機／発振器第 1 ユニットのコス
ト C は、次のとおりである。
In C＝3.822 + 1.110 In W + 0.436 In z
この場合、W は受信機／発振器の重量、z は受信機箱の個数である。In は自然対数関数で
ある。（出所：米国空軍システム指令・宇宙部、"Unmanned Space Vehicle Cost Model"(「無
人宇宙船コスト・モデル」)、第 7 版、1994 年 8 月）。先端技術システムには CER モデルが
広く採用されてはいるが、理論的根拠と実用的根拠の両面から問題視されている。そのよ
うな問題の一つは、コストと独立変数の関係が変わらないという想定に基づいたものであ
る。その他の問題は、多くのモデルに使用されている共通の独立変数である重量に基づく
CER の有効性を、電子的パッケージや複合材の発達に照らして疑問視したものである。統計
的 CER の採用に反対する意見でも、入力データの精確度、少ないデータ点による統計的有
意性の低さ、統計的信頼帯域の無視、基本的データの偏りといった問題を指摘している。
もう 1 種のパラメータ型モデルは、容認済み関連性に基づいたものである。その一般的
モデル例は、補修費や予備品初期費と再発費の予測にロジスティックス関連性を適用した
ものに見られる。このコスト予測の有効性も、入力パラメータの質に左右される。
パラメータ型コスト・モデルの主な利点は、予測結果を再現でき、最低限の時間と労力
で作成できる点にある。そのため、性能に基づくパラメータ型コスト・モデルを適正に作
成すれば、初期のトレード研究に利用できる。
もう一つのコスト予測方法は「類推」技法である。新しいシステムや構成要素の機能・
性能特性が、コストがわかっている既成のものと余り変わらない場合は、相違点に対する
- 145 -
技術的判断を反映するように既知コストを調整することができる。
「積み上げ」（または「ボトムアップ」）技法による予測は、作業明細構成図（WBS＝Work
Breakdown Structure）に示された作業を実施する各組織ごとに推定コストをまとめた結果
である。適正に実施すれば、積み上げ予測は非常に精度の高いものになるが、「もし....で
あれば、どうなるか」という問題が出てくるたびに、新たに予測し直さなければならない。
想定条件を変えるたびに、古い予測の一部が無効になる。積み上げ予測は通例、時間のか
かる労働集約的な技法であるので、トレード研究中に得られるコスト予測件数は実際上非
常に限られている。
どの技法を採用しても、統合化と試験、プログラム・マネジメント、システムエンジニ
アリングなどの費用を扱う場合にはたいてい、各ハードウェア要素と各ソフトウェア要素
の直接費をも「ひっくるめる」（1 を超える係数を掛ける）必要がある。このような追加費
用は、システムレベル・コストと呼ばれているが、直接費のパーセンテージとして算定さ
れる場合が多い。
表5
宇宙システムのパラメータ型コスト・モデル例
モデル
出所
用途
無人宇宙船コスト・モデル
（USCM）*
コスト推定および評価用情
報審査プログラム（PRICE）
空軍資材指令／宇宙・ミサイ
ルシステムセンター
GE／RCA 社
宇宙ステーション運用コス
ト予測モデル（MESSOC）
ソフトウェア・コスト予測
ツール（SCT）*
多変数計測器コスト・モデル
（MICM）*
小型衛星コスト・モデル
（SSCM）*
宇宙ステーション本部支援局
無人地球周回宇宙船の DDT＆E、FH、
AGE、LOOS**
PRICE／H:電子・機械ハードウェア用
DDT＆E 費および生産費向け、PRICE
／S:ソフトウェア向け
地球周回宇宙ステーションの完成期
運用コスト
NASA 有人・無人飛行および地上ソフ
トウェア開発費
搭載機器プロトタイプの開発・製造
費
クラス C・D 新型地球周回小型衛星の
システム／サブシステム・レベル DDT
＆E 費と FH 費
有人・無人宇宙機および打上げロケ
ットのサブシステム・レベル DDT＆E
費と FH 費
JPL（ジェット推進研究所）
GSFC（ゴダード宇宙飛行セン
ター）（コード 152.0）
The Aerospace Corporation
マーシャル宇宙飛行センタ
MSFC（マーシャル宇宙飛行セ
ー統計的（歴史的）コスト・ ンター）
モデル*
*
**
統計に基づくコスト推定関連性。
FH＝Flight Hardware(飛行用ハードウェア）
AGE＝Aerospace Ground Equipment（地上支援装置）
LOOS＝Launch and Orbital Operations Support(射場及び軌道運用支援）。
DDT＆E＝Design, Development, Test and Evaluation（設計、開発、試験、評価）。
パラメータ型コスト・モデルの使用
NASA システムのコスト予測には、多数のパラメータ型コスト・モデルが利用されている。
表 5 には、これらの各種モデルの一部を示す。残念ながら、単独でライフサイクル・コス
トを予測できるものはない。ライフサイクル・コストを予測するには、数種のモデル（他
- 146 -
の技法 2 種も含む）を併用する必要がある。この数種のモデルで予測した各種コストを統
合化する場合、システムエンジニアは各種モデルの入力データと想定条件が互いに適合す
るものか、すべての関連ライフサイクル・コスト項目を網羅したか、コストのタイミング
が適正かどうかを確認する必要がある。
学習曲線理論
学習曲線（進歩曲線とか経験曲線ともいう）は、航空機や宇宙機のような複雑なシステ
ムを構成する多数のユニットの製造単価が数量の増加に伴い低下する傾向があるという経
験的観測を経時的に処理する方法である。一般的に言えば、この理論は、生産量が 2 倍に
増えると、「単価」は「一定の割合」（％）で低下するというものである。単価（単位当た
りのコスト）は、生産単位数に対する平均コストか、又は最終生産単位のコストとみなす
ことができる。前者の場合の曲線は、一般的に累積平均学習曲線と呼ばれている。後者の
場合の曲線は、単位学習曲線と呼ばれている。両曲線とも、本質的に同一の学習率を有し
ている。
C（1）を第 1 生産単位の単価、C（Q）を第 Q 生産単位の単価とすると、学習曲線理論で
は、次のような数値 b があるといえる。
C（Q）＝ C（1）Qb
数値 b は学習率により指定される。学習率 90 パーセントとは、第 2 生産単位の単価が第
1 生産単位の単価の 90 パーセント、第 4 生産単位の単価が第 2 生産単位の単価の 90 パーセ
ント、....であるという意味である。一般的に、C（2Q）／C（Q）比を学習率 LR といい、
小数で表記される。上記方程式を使用すると、b＝ln（LR）／ln2 となる。この場合、ln は
自然対数である。
学習曲線は常に採用できるとは限らない。たとえば、時間当たり生産率が基本方程式に
何の影響も与えないからである。各種学習率に関する経験的研究や表も含め、学習曲線の
詳細については、Harold Asher 著 "Cost-Quantity Relationships in the Airframe
Industry"(「機体産業におけるコストと量の関係」）（R-291、The Rand Corporation、1956
年）を参照されたい。
ライフサイクル・コスト予測上、システムエンジニアがモデルの予測結果に何らかの調
整を加える必要があると考える場合もある。このような状況が起こるのは、年ごとに異な
る「固定」ドル価格で予測値を示したいろいろなモデルの予測結果を組み合わせなければ
ならない場合である。その場合は、適切なインフレ率を適用しなければならない。また、
何らかのモデルからハードウェアアイテムの第 1 ユニットに対するコスト予測が得られた
が、プロジェクトでは多数のユニットを必要とするという場合も、調整が必要になる。そ
- 147 -
の場合は、第 1 ユニットのコストに学習曲線を適用すれば、必要とする多数のユニットの
コスト予測が得られる。（枠内補足記事「学習曲線理論」を参照）。
費用延べ払い関数例：
ベータ曲線
推定調達費を延べ払いにする一つの技法としては、「ベータ曲線」の採用がある。1960 年
代後半にジョンソン宇宙センター（JSC＝Johnson Space Center）で開発されたこの 5 次多
項式関数は、累積費用の分数を累積時間の分数 T の関数として表わすものである。
累積費用の分数＝10T2(1−T）2(A＋BT）
＋T4(5−4T）、0≦T≦1 の場合。
A と B はベータ曲線の形を決定するパラメータである（0≦A＋B≦1）。この両パラメータ
は、特に、累積時間の 50 パーセントに達した時にすでに支出済みの累積コスト分を制御す
るものである。下図には 3 つの例を示す。曲線（1）に示すように、A＝1、B＝0 の場合は、
累積時間の 50 パーセントに達した時にコストの 81 パーセントが支出済みである。曲線（2）
に示すように、A＝0、B＝1 の場合は、累積時間の 50 パーセントに達した時にコストの 50
パーセントが支出済みである。曲線（3）に示すように、A＝B＝0 の場合は、コストの 19 パ
ーセントが支出済みである。
コスト
①
②
③
0
時間割合
1.0
通例、ジョンソン宇宙センター（JSC）では、以前のプロジェクトから得たデータに基づ
いて、A＝0、B＝1 の 50 パーセント曲線か、A＝0.32、B＝0.68 の 60 パーセント曲線を採用
している。
追加計算を必要とする 3 番目の状況は、何らかのモデルから調達業務全体のコスト予測
が得られたが、そのモデルではこのような業務に数年かかることを考慮していない場合で
ある。その種のプロジェクトでは、システムエンジニアは、調達費の標準的「ランプアッ
プ」と「ランプダウン」に基づく 1 組の「年度別費用延べ払い」方式を採用することがで
きる。（枠内補足記事「費用延べ払い関数例：ベータ曲線」を参照）。
- 148 -
宇宙システムの一般的なパラメータ型コスト・モデルはすでに数種開発されているが、
それらを適正に使用するには、学習期間にかなりの投資を行う必要がある。これらの既成
コスト・モデルを適用できないプロジェクトの場合は、トレード研究向けに新しいコスト・
モデルを開発する必要がある。この新型モデルの開発作業は、システムエンジニアリング・
プロセス中に適時に採用できるように、プロジェクト・ライフサイクルの初期から開始す
る必要がある。既成モデルを使用するにせよ新型モデルを使用するにせよ、システムエン
ジニアリング・マネジメント計画書（SEMP＝Systems Engineering Management Plan)やそ
の関連ライフサイクルコスト・マネジメント計画書では、プロジェクト・ライフサイクル
の各フェーズにおいて使用すべきモデル（およびその使い方）を特定する必要がある。
5.3
効果の定義とモデル作成
システム効果という概念は、コストという概念よりも捕らえどころがない。しかし、こ
の概念も、トレード研究において検討すべき最も重要な要素の一つである。多くの代替案
から最適案を選定する場合、システムエンジニアとしては、確実な定義と測定がやりにく
くても、システム効果を考慮に入れなければならない。
システム効果の測定値は、システムの目標と目的の達成結果を「定量的に」表わしたも
のである。各システム（または同一の目標と目的を持つシステム群）は、それぞれ固有の
システム効果測定値を持っている。NASA システム全体に通用するシステム効果測定値もな
いし、そのような効果を表記する正規の単位もない。さらに、システム効果は、システム
が運用される状況（つまり、プロジェクトやスーパーシステム）に左右されるので、その
測定では常にその点を考慮しなければならない。しかし、システムエンジニアとしては、
システム効果測定戦略を策定する際にシステム効果の数少ない基本的な共通特性を利用す
ることができる。
5.3.1
システム効果測定戦略
システム効果はほとんど多面的なもので、通例は次のようなものの相乗効果によるもの
である。
・
システム出力の品質
・
システム出力のサイズまたは量
・
システムの適用範囲または包括性
・
システム出力の適時性
・
システムのアベイラビリティ
システム効果測定値とその測定方法（つまりモデル）は、「トレード研究で検討中の問題」
に対する主要効果面（1 つまたは 2 つ以上）に的を絞ったものにすべきである。どの効果面
- 149 -
が重要かは、機能解析を合わせて行えばほぼ明らかになる。システム効果を数学的に算定
した基本的システム性能または技術的属性を特定する場合にも、機能解析が大いに役立つ。
（ただし、上記の各効果面がいくつかの側面を持つこともある。そのような場合は、その
各側面を、基本的システム性能または技術的属性の一機能とみなすことができる）。理想的
な場合は、システム機能解析、システム効果測定値、機能・性能要求事項の間に強い関連
性がある。機能要求事項のフローダウンを可能にする同じ機能解析から、システム効果と
システム性能の測定値が得られ、さらにその測定値を（トレード研究により）最適化する
と、システム性能要求事項が生まれる。
システム効果の測定方法またはモデルでは、こうした基本的性能または技術的属性とシ
ステム効果測定値の間の信頼できる関係を提示すべきである。プロジェクト・ライフサイ
クルの前半段階では、そのようなシステム効果モデルにより、高レベルの性能および技術
的属性とシステム効果測定値の間にある簡単なパラメータ関係を具体的に示すことができ
るであろう。プロジェクト・ライフサイクルの後半段階でも、各種運用シナリオとその各
代替案に関するより詳細な特定データを必要とするもっと複雑な関係を、システム効果モ
デルで示すことができるであろう。つまり、アーキテクチャのトレード研究段階で早期に
システム効果モデルを作成すれば、機能の視点からシステムを検討できる。他方、設計の
トレード研究段階でシステム効果モデルを作成すると、視点を製品へ移すことができる。
この点は、単純なパラメータ型コスト予測からより詳細な草の根予測へとコスト・モデル
を移行させるのと変わらない。
トレード研究にシステム効果測定値を使用する場合の
実際の落とし穴
システムの性能または技術的属性とシステム効果との間から信頼できる関係を得るの
は、往々にして大変な作業となる。システム効果モデルと称するものが、テキストに書か
れた多数の効果面のうちの 1 つか 2 つを扱っているにすぎない場合も多い。また、支援用
モデルが正しく導入されていないこともある。データが不完全であるか、信頼できない場
合も多い。このような場合、トレード研究で報告された各種代替案のシステム効果測定結
果は、そのトレード研究の範囲内での各種代替案の「相対的」効果を示すにすぎない。シ
ステムエンジニアとしては、その測定結果を使用する場合の実際の落とし穴を十分認識す
べきである。
システムエンジニアは、システム効果測定値とその測定方法をシステム設計の分解度に合
わせて調整しなければならない。システム設計と運用概念が成熟するに伴い、システム効
果予測値も成熟しなければならない。システムエンジニアとしては、トレード研究だけで
はなく、技術的性能測定値（TPM＝Technical Performance Measure)の追跡調査によるプロ
ジェクト・マネジメントのためにも、システムの効果、その性能および技術的属性の現実
- 150 -
的な予測値を提示できなければならない。
これまで述べたことは、ある容認済みシステム効果測定値に基づいて言われてきた。シ
ステムエンジニアが唯一の測定値と唯一の測定方法（モデル）しか使用しない場合は、シ
ステム効果を算定する作業もかなり簡単なものになる。しかし、コストの場合と同様、唯
一の測定値などはありえない。測定値が存在しなければ、システムエンジニアは、高レベ
ルで、しかもまだ基本的な主要システム性能または技術的属性の算定に立ち戻らなければ
ならない。実際上、このような高レベルの性能または技術的属性は、たとえ真に包括的な
システム効果測定値を表わすものでなくても、トレード研究のために（システム）効果測
定値（MoEs）の状態まで引き上げられる。
この高レベルの性能または技術的属性は、上述の各種効果面の一つを示すことができる
か、またはその効果面の構成要素にすぎないこともある。それらはおそらく、低レベルの
性能または技術的属性に関する知識や予測を必要とするものであろう。図 26 は、システム
効果を階層的樹形図にどのように表わすことができるかを示すものである。この図は、あ
る意味で、ライフサイクル・コストに関する図 25 に対応するものだが、簡単な追加による
拡張方式はシステム効果には適用されない。
最後に、システム・コストと同様、システム効果も不確定なものであることを認識する
必要がある。この点については、第 5.4 項においてさらに詳しく述べる。
5.3.2
NASA システム効果の測定
図 26 に示す各種システム効果面は一般的なものである。特定なシステムにはそのすべて
を適用してはならない。システムエンジニアとしては、どの性能またはどの技術的属性が
システム効果を構成するものか、それらをどのように組み合わせるべきかをシステムごと
に判断しなければならない。表 6 には、特定の種類の NASA 飛行システムの場合に各システ
ム効果面をどう解釈できるかという点についていくつかの例を示す。この表は、あらゆる
性能または技術的属性をできるかぎり列挙するか、各記入項目にできるかぎり記入しよう
とたものではなく、一例として示したものにすぎない。
- 151 -
システム効果
出力の品質
出力量
適用範囲
出力の適時性
アベイラビリティ
精度
能力
瞬時または短期
的適用範囲
信頼性
信頼性
その他
生存性／
無防備性
長期的適用範囲
対応性
保全性
その他
その他
その他
予備品数と
設置位置
輸送能力
その他
図26 システム効果項目（一般的なもの）
表6
システム
の種類
打上げシ
ステム
無人宇宙
ステーシ
ョン
惑星探査
衛星／探
査機
地球観測
機
適用範囲または
包括性
出力量
打上げの信頼
性、打上げ時
の安全性、打
上げ前処理時
の安全性
微小重力環
境、運用安全
性
LEO、GEO、GTO などに対する
ユーザー・ペイロード打上
げ能力
（アベイラビリ 予 定 打 上 げ
ティの欄を参照） 確率（システ
ム誘因の延
期なし）。
年間ユーザー使用可能出力、
IVA、EVA、与圧容積、質量
増大、質量減少、CPU 時間、
データ記憶、アップリンク、
ダウンリンク、取付け点時
間など
サイト／サンプル数
サイト／サンプ
ル種類
データ／サンプ
ル回収時間
運用時間／
総時間比。
データ／サンプ
ル回収時間、打上
げ時間帯適合確
率
データ回収時間、
不測の事態への
対応性
打上げ時間帯適
合確率
設計寿命適
合確率。
観測の同時性
運用時間／
総時間比。
測定機器の分 年間観測時間
解能。ビッ
ト・エラー率。
（同上）
観測目標数
視野、測定機器の
共同作用、スペク
トル種類
（同上）
（同上）
（同上）
年間観測時間
出力の適時性
アベイラビ
リティ
出力の品質
ロボット
地表探査
ロバー
天体物理
学観測機
各種 NASA 飛行システムの効果面
運用時間／
総時間比。
設計寿命適
合確率
LEO(Low earth orbit＝低高度地球周回軌道)、GEO(Geo-stationary earth orbit＝静止軌道)、GTO（Geo-stationary
transfer orbit＝地球静止軌道への遷移軌道）
IVA(Intravehicular activity＝船内活動)、EVA（Extravehicular activity＝船外活動）、CPU（Central processing
unit ＝中央処理装置）
- 152 -
表 6 に示すシステムの多くでは、システム効果が、一定の出力レベルでの数年間にわた
る断続的（または連続的）運用により大幅に変動する。この点は「アポロ」型プロジェク
トと対照的である。このプロジェクトでは、明確に指定された時間範囲内にただ 1 回の飛
行を成功させたことによりシステム効果が大幅に決定された。したがって、この 2 つのケ
ースでは、システム効果の測定値が当然異なっている。（運用期間が長く、出力も断続的で
ある）前者のケースでは、システム効果の測定値にアベイラビリティの定量値を導入する
必要がある。そのために、システムエンジニアは専門技術者を介入させ、次項で説明する
専門モデルを採用する。
5.3.3
アベイラビリティ・モデルとロジスティックス支援性モデルの作成
本章でアベイラビリティとロジスティックス支援性を重視する一つの理由は、将来の
NASA システムが「ロジスティックスを無視した打上げ」にはなりそうにない点にある。ロ
ジスティックス支援問題が運用期間中のシステム効果を決定する重要要因となる限り、プ
ロジェクト・ライフサイクルの前半段階でのトレード研究によりロジスティックス支援を
徹底的に分析することが不可欠となる。もう一つの理由は、アベイラビリティとロジステ
ィックス支援性が方法論とモデル開発にとって絶好の領域であったことである。各種の方
法とモデルの高度化により、システム全体に対する各種支援案の影響を予測しやすくなっ
た。つまり、ロジスティックス問題をシステム設計に導入することにより、システム効果
を高める（またはライフサイクル・コストを引き下げる）チャンスも増えるというわけで
ある。
アベイラビリティ・モデルでは、システム設計とそれに導入されたロジスティックス支
援の技術的属性と、システム効果算定値のアベイラビリティ成分の関係を示す。この種の
モデルでは、システム構成要素の故障率と補修率およびロジスティックス支援の資源と方
針に応じたシステムのアベイラビリティを予測する。（枠内補足記事「アベイラビリティの
測定」を参照）。
ロジスティックス支援性モデルでは、システム設計とそれに導入されたロジスティック
ス支援の技術的属性と、目標と目的を達成するためにシステムの運用に必要となる 1 件ま
たは数件の「経営資源要求事項」との関係を示す。この種のモデルでは、たとえばシステ
ム保全要求事項、予備品の数量と設置位置、処理施設の要求事項、さらに最適検査方針な
どにも重点を置く。従来のロジスティックス支援性モデルは、通例、特定の経営資源や特
定の機能に関する測定値「のみ」に基づいて作成されていた。たとえば、システムの希望
予備品在庫量は、需要充足率などの供給効率測定値を満たすという視点から算定されてい
た。システムの視点から見ると、このような算定方法は準最適資源所要量を算定する傾向
になる。最近のロジスティックス支援性モデルでは、システム・アベイラビリティの影響
- 153 -
に基づいて資源要求事項を算定する。（枠内補足記事「ロジスティックス支援性モデル」を
参照）。
- 154 -
アベイラビリティの測定
アベイラビリティは運用時間／総時間比として算定できる。その場合、総時間という基
準パラメータは、運用時間（「アップタイム」）と「ダウンタイム」に分割できる。システ
ム・アベイラビリティは、ダウンタイムに対する寄与率に左右される。したがって、シス
テム・アベイラビリティを下支えするのは、システム設計の信頼性と保全性の属性である
が、その他のロジスティックス支援要素も重要な役割を果たすことがある。このような属
性と支援要素、さらにシステムの運用環境が変わらない場合は、いくつかの「定常アベイ
ラビリティ」測定値を容易に算定することができる。（定常条件が適用されない場合も、ア
ベイラビリティを算定できるが、基本的条件が動的なためかなり複雑なものとなる）。シス
テムエンジニアとしては。下記の方程式に精通する必要がある。これらは補修可能システ
ムに関する定常アベイラビリティ概念を示すものである。
・
固有＝MTTF／（MTTF＋MTTR）
・
達成＝MTTMA／（MTTMA＋MMT）
・
運用＝MTTMA／（MTTMA＋MMT＋MLDT）
＝MTTMA／（MTTMA＋MDT）
この場合、
MTTF＝Mean time to failure（平均故障時間）、
MTTR＝Mean time to repair(平均修理時間)、
MTTMA＝Mean time to a maintenance action(平均保全作業時間)（補正および予防）、
MMT＝Mean (active) maintenance time（平均（実）保全時間）（補正および予防）、
MLDT＝Mean logistics delay time(平均ロジスティックス遅延時間)（行政上の遅れ、予
備品、保全要員または補給品待ちによるダウンタイムも含む）、
MDT＝Mean downtime(平均ダウンタイム）（（実）保全とロジスティックスの遅れによる
ダウンタイムも含む）。
アベイラビリティ測定値は、何らかの時点における測定値や何らかの期間の平均値と
して算定することもできる。冗長型システムの運用モード劣化も考慮に入れると、アベイ
ラビリティの算定がさらに複雑化するが、処理できる。補修不能システムの場合は、アベ
イラビリティと信頼性が同等になる。（6.2.1 項の枠内補足記事「信頼性関数」を参照）。
他のロジスティックス資源量を一定にしたまま、特定のアベラビリティ・レベルを達成
するのに必要な資源量を算定してロジスティックス資源所要量を算定するためには、いく
つかのアベイラビリイ・モデルを使用できる。アベイラビリティ・モデルとロジスティッ
クス支援性モデルの境界線が厳密でないこともある。ロジスティックス支援性モデルのな
かには、唯一の資源しか処理できないものもあれば、数種の資源を同時に処理できるもの
もある。簡単なスプレッドシートという形のものもあれば、大型のコンピュータ・シミュ
- 155 -
レーションという形のものもある。この種のモデルから大きな能力を得ようとすれば、よ
り多くの時間と労力を費やさなければならない。各新型システムにはどんなアベイラビリ
ティ・モデルとロジスティックス支援性モデルが必要かを判定する場合、システムエンジ
ニアとしては、そのシステム特有の運用概念とロジスティックス概念、その環境も考慮に
入れしなければならない。通常、トレード研究において専門工学データをシステムエンジ
ニアの使いやすい形に変換する場合には、アベイラビリティ・モデルとロジスティックス
支援性モデルが必要になる。プロジェクト・ライフサイクルの各フェーズにおいてどのア
ベイラビリティ・モデルとどのロジスティックス支援性モデルを使用するかは、システム
エンジニアリング・マネジメント計画書（SEMP＝Systems Engineering Management Plan)
に特定しておくべきである。
これらのモデルのもう一つの役割は、システムの正式な総合ロジスティックス支援（ILS
＝Integrated Logistics Support）計画書に盛り込まれる定量的要求事項を提供すること
である。図 27 には、トレード研究プロセスにおけるアベイラビリティ・モデルとロジステ
ィックス支援性モデルの役割を示す。
一つのアベイラビリティ・モデルやロジスティックス支援性モデルから有益な結果を得
るためには、各システム設計案に関する質の高い専門工学的データの収集が必要不可欠で
ある。（このデータの一部は、リスク・マネジメント作業で実施する確率的リスク評価にも
使われる）。システムエンジニアとしては、このようなデータを収集し、そのデータを実施
中のトレード研究に適する形式で保管する作業を調整しなければならない。MIL-STD
（Military Standards ＝米国陸軍標準規格）-1388-2B 向けに目下開発中のものなど、関係
表形式のディジタル・データベースを使用すれば、このような作業もかなり容易になる。
アベイラビリティ・モデルとロジスティックス支援性モデルの作成、そのデータの収集
を運用段階まで続ければ、システムに関する「運用トレンド解析と評価」（たとえば、シス
テムのアベイラビリティが低下しているか、上昇しているか？）を実施できる。一般的に、
この種の解析と評価は、システムの信頼性向上、ロジスティックス支援の低コスト化、保
全性・予備品対策の改善といった潜在的製品改良領域を特定するのに極めて役に立つ。（総
合ロジスティックス支援の詳細については、第 6.5 項を参照）。
- 156 -
ロジスティックス支援性モデル：
2例
ロジスティックス支援性モデルでは、特定のシステム設計の信頼性と保全性の属性なら
びにシステムの他のロジスティックス変数を使用して、運用段階における乏しいロジステ
ィックス資源の需要（つまり所要量）を定量化する。ここで説明するモデルは、どちらも
宇宙ステーション「フリーダム」向けに開発されたものである。一方は確率的シミュレー
ション・モデルで、その実行は各種結果の母集団から採取したサンプルの「試験」である。
各種関係変数の平均値と偏差を正確に予測するには、数回実行しなければならない。もう
一方は決定論的解析モデルである。ロジスティックス支援性モデルとしては、そのいずれ
かを使用することができる。この 2 つのモデルでは、「フリーダム」特有のロジスティック
ス環境を処理する。
SIMSYLS は、「フリーダム」向け軌道上保全ロジスティックス補給の包括的確率的シミュ
レーション・モデルである。このモデルでは、EVA(extravehicular activity＝船外活動）
や IVA(Intravehicular activity＝船内活動）などの保全作業用資源および質量増大と質量
減少用ロジスティックス資源の需要予測を行う。ORU（orbital replacement unit＝軌道交
換ユニット）の実故障と偽似故障の影響の他に、ロケット補修や地上補修の遅れのような
その他の各種確率的事象の影響も定量化できる。SIMSYLS からは、運用アベイラビリティの
算定値もいくつか得られる。このモデルは、アベイラビリティ・モードでも資源要求モデ
ルでも使用できる。
M-SPARE は、アベイラビリティに基づく最適予備品モデルである。このモデルでは、何ら
かの予備品予算レベルにおいて、宇宙ステーションのアベイラビリティを最大にするよう
な ORU（軌道交換ユニット）用予備品構成を算定する。そのアベイラビリティは、各補給サ
イクルにおける ORU の予備品需要がその需要を満たす程度の予備品量にしかならない確率
として定義されている。SIMSYLS とは異なり、M-SPARE のアベイラビリティ測定では、予備
品量の影響しか処理しない。M-SPARE では、まず目標アベイラビリティ（または目標予算）
を算定し、次に最適在庫量を算定する。この機能は、SIMSYLS にはないものである。
詳細については、DeJulio, E., 著 "SIMSYLS User's Guide" （SIMSYLS 使用手引書）、
Boeing Aerospace Operations 、1990 年 2 月、および Kline, Robert,その他共著 "The
M-SPARE Model"（M-SPARE モデル）、LMI、NS901R1 、1990 年 3 月を参照されたい。
- 157 -
5.4
コストと効果の確率的処理
コストと効果という結果変数の点推定値が「全体像を示さない」場合
−
つまり、シ
ステムの予測コストと予測効果の可変性に関する情報が、そのシステムに関する適正な選
択に関係がある場合
−
は、コストと効果の確率的処理が必要になる。このような不確
定要因が決定を左右する可能性がある場合、システムやプログラムのアナリストとしては、
そうした不確定要因の存在を認識するだけではなく、それ以上のことをしなければならな
い。不確定性の影響をモデル化するのに役立ついくつかの技法については、第 5.4.2 項で
説明する。この技法はコスト・モデルと効果モデルの両方に適用できるが、以下に示すモ
デル例の大半はコスト・モデル用である。
システム効果出力
（静的および動的）
専門工学的入力データ
・ 信頼性
・ 保全性
・ 輸送
・ 通信
・ 人的要素とトレーニン
グ
・ 予備品の調達・在庫・
分配、試験設備、処理、
保守施設
・ ロジスティックス・運
用作業スケジュール
・ 安全性と品質保証
図 27
5.4.1
・システムアベイラビリティ
・システム信頼性
・総合ロジスティックス
アベイラビリティ
・モデル
ロジスティックス
支援性モデル
システム効果モ
デルへ
支援効果
総合ロジスティ
ックス支援計画
書へ
システム「資源要求」出力
（静的および動的）
・システム保全および予備品要求
・施設とシステムの支援設備要求
・輸送要求
・その他
システムのライ
フサイクルコス
ト・モデルへ
アベイラビリティ・モデルとロジスティックス支援性モデルの役割
モデルの不確定性原因
システム解析に使用される各種モデルの不確定性の原因は多数ある。簡単に言えば、そ
れらは次のものである。
・
モデルの構造方程式の適正さに関する不確定性。特に、モデル作成者の選んだ関数
の形が、各方程式の入力データと算定結果の関係を最も良く表わしたものかどうか
という不確定性
・
モデルのパラメータに伴う不確定性。これらのパラメータも、実際にはモデル作成
者が選んだものである。統計的回帰から引き出したモデルの係数ではこのような不
確定性が顕著だが、既知の物理的定数も実験や測定上の誤差によりある程度の不確
定性を伴う
・
新しいシステムを示すモデルの入力データ（たとえば推定重量や熱特性など）の真
の値に伴う不確定性
- 158 -
一例として、1 つまたは 2 つ以上の統計的コスト推定関連性（CER＝cost estimate
relationship）からなるコスト・モデルを考えてみよう。プロジェクト・ライフサイクル
の前半段階（フェーズ A と B）では、通常、新しい NASA システムのコスト予測にこの種の
モデルが使用される。プロジェクトマネジャとしては、そのコスト予測がどの程度信頼で
きるものかを知る必要がある。
一連の不確定性は、入力変数（たとえば重量など）がコストを正しく説明する変数なの
かどうか、一次方程式や対数一次方程式の方が適切かどうかに関するものである。厳密な
工学的関連性の場合でも、モデルの仕様間違いは決して珍しいことではない。
コスト予測の不確定性に寄与するモデル関係のもう 1 組の不確定性は、過去のデータか
ら推定したモデルの係数に関するものである。良くできた統計的回帰方程式でも、係数推
定値が偶然に得られたものにすぎない場合もあるため、モデルを使ったコスト予測を確率
項目に示す必要がある。（幸いなことに、希望の信頼性レベルを得るためのコストの上限と
下限は容易に算定できる。コスト予測と共にこのような情報の提示も強く推奨したい）。
新しいシステムを示すコスト・モデルの入力データがフェーズ A で精確にわかっている
場合でも、上述の各種不確定性が存在する。しかし、入力データがフェーズ A で精確にわ
かっている場合は滅多にない。むしろ、プロジェクト・ライフサイクルの初期段階におい
てかなりの当て推量でモデルの入力データが選定される場合の方が多い。モデルの入力デ
ータに伴う不確定性は、確率分布に起因すると言える。入力データが重量のような物理的
測定値であるか、それとも「複雑性係数」のような主観的評価値であるかという場合も同
様である。モデル入力データの不確定性は、フェーズ C と D において使用される「積み上
げ」コスト・モデルにまで波及することがある。その場合、不確定性の原因は、「まだわか
っていない未知データ」の特定と収集を怠った点にある。そのため、モデルの各種入力デ
ータ（各実施団体が推定したコスト）は、確率分布の異なる変数と考えることができる。
5.4.2
不確定性を処理するためのモデル作成技法
モデルの不確定性による影響は、モデルの出力に不確定性をもたらすという点である。
この不確定性を定量化すると、出力変数全体の確率分布が得られる。その確率分布は、確
率密度関数（または離散出力変数の集合関数）もしくは累積分布関数という形で表わされ
る。（枠内補足記事「コスト S 曲線」を参照）。このような不確定性を処理するための技法
としては、次のものがある。
・
解析的解決法
・
意思決定解析
・
モンテカルロ・シミュレーション
- 159 -
コスト S 曲線
コスト S 曲線は、プロジェクトのコストが特定のコスト予測値を超えない場合の確率を
示す。この確率は予算信頼性レベルと呼ばれることもある。この曲線は、リスク準備金と
して貯えておく緊急用準備金と計画調整引当金（APA＝Allowance for Program Adjustment）
の総額を設定する際に使用される。
100
基本コスト予測額＋準備金
信頼性（％）
50
プロジェクト・
コスト予算額
基本コスト予測額
0
コスト（ドル）
X
上に示す S 曲線では、プロジェクト・コスト予算額の信頼性レベルがわずか 40％しかな
い。準備金を加えると、そのレベルは 50％まで上昇する。S 曲線の勾配は、少額の準備金
を加えた場合に信頼性レベルがどの程度上昇するかをプロジェクトマネジャに知らせる。
完成見積り（EAC＝Estimate at Completion)S 曲線をリスク・マネジメント方法と併用で
きる点に留意されたい。リスク・マネジメントは、技術的性能測定（TPM＝Technical
Performance Measure)の項（第 4.9.2 項を参照）で述べたコスト状態のもう一つの報告・
評価方法である。
解析的解決法
モデルの構造とその各種不確定性が許す限り、必要な確率密度（または累積確率）関数
に対して閉鎖型解析的解決法を採用できる場合もある。その例を簡単な信頼性モデルに示
す（図 29 を参照）。
意思決定解析
第 4.6 項で検討したこの技法からも累積確率関数が得られるが、連続入力確率分布を離
散化（不連続化）する必要がある。使用する確率間隔が大きくなればなるほど、算定結果
の精度は高くなるが、意思決定樹形図も拡大する。しかも、不確定な各モデル入力データ
がその樹形図に一次計算以上の複雑性を加える。そのため、この技法は、次に説明するモ
ンテカルロ・シミュレーションに比べ効率が悪くなる場合が多い。
- 160 -
モンテカルロ・シミュレーション
確率密度
モンテカル
ロ・シミュレ
ーションから
は、サンプル
x1、x2 、x3を採
取することに
よりこの曲線
が得られる
複雑すぎて解析方法だけでは解決で
きない確率モデルに対して近似値を算
ｙ＝ｆ(X1, X2, X3)
定する場合には、この技法がよく採用さ
れる。モンテカルロ・シミュレーション
確率密度
は、出力変数の確率分布を推算するため
に、いくつかの入力点をそれぞれの領域
からサンプル採取する方法である。簡単
X1
確率密度
なモンテカルロ解析では、各不確定入力
の値をその確率分布から無作為に採取
X2
確率密度
する。その確率分布は不連続分布でも連
図28
続分布でもよい。各入力ごとに１つずつ
X3
採取されたこの 1 組の無作為採取値は、
3つの不確定入力によるモンテカ
ルロ・シミュレーション
図 28 に示すように、対応する出力値の
算定に使用される。この手順全体を k 回
くり返す。このようにして得られた k 個の出力値は、入力確率分布から推算された出力変
数に対する確率分布から得られた 1 つの無作為サンプルを形成する。
この技法の使用例としては、図 2（第 2 章）と図 24（第 5 章）がある。この 2 つの図で
は、3 つの設計概念案の予測コストと予測効果を確率の「雲模様」(cloud）として示してい
る。この雲模様は、3 つのシステム・レベルのモンテカルロ・シミュレーション結果と解釈
してもおかしくはない。この雲模様で示された情報は、各設計概念案の点推定値で具体的
に示された情報よりもはるかに多い。
モンテカルロ技法の利点は、得られた確率分布の精度を予測するのに標準的な統計的試
験を採用できる点にある。そのため、所定レベルの精度を得る場合に必要となる実行回数
（サンプル数）を算定できる。算定時間とコストが大きな制約となる場合は、更に慎重な
サンプル採取戦略によりその時間とコストを削減する方法も数種ある。このようなサンプ
ル採取戦略については、MSFC-HDBK（Marshall Space Flight Center-handbook＝マーシャ
ル宇宙飛行センター・ハンドブック）-1912 "Systems Engineering"（「システムエンジニ
アリング」）（第 2 巻）を参照されたい。
モンテカルロ・シミュレーションを実施するためのソフトウェアは市販されている。こ
のようなソフトウェアとしては、いくつかの普及型スプレッドシート向けの追加パッケー
ジの他、システムやプログラムのアナリストがパソコンを使ってまったく初めからモンテ
カルロ・モデルを作成できるようなパッケージもある。このようなパッケージでは通常、
必要な計算を効率的に実施し、その結果を図形表示する。この図形表示は、確率情報を伝
えるのに大いに役立つ。ロジスティックス支援性に取り組む場合のように、モンテカルロ・
シミュレーションの用途が幅広い場合には、カスタム・ソフトウェアが必要になることも
- 161 -
ある。（枠内補足記事「ロジスティックス支援性モデル」を参照）。
モンテカルロ・シミュレーションはかなり採用しやすい技法である。また、多くの場合
には、特定の組み合わせの不確定性が何を意味しているかを、マネジャに明確に伝えるこ
ともできる。NASA の飛行準備確認に対するこの技法の有力な適用例は、Moore､ Ebbeler、
Creager の文献に見られる。この適用例では、モンテカルロ・シミュレーションを従来型
の信頼性解析技法およびリスク解析技法と組み合わせている。
- 162 -
6．
システムエンジニアリング・プロセスに対する専門工学分野の導入
この章では、いくつかの専門工学分野の基本概念、各種技法、その成果、それらをシス
テムエンジニアリング・プロセスに適合させる方法について検討する。
6.1 専門工学分野の役割
専門技術者は、多くの専門工学分野から得た特定の知識と解析方法を応用して、「得られ
たシステムが実際にその運用環境においてミッションを実施できるものかどうかを確認す
る」ことで、システムエンジニアリング・プロセスを支援する。これらの専門工学分野の
代表的なものとしては、信頼性、保全性、総合ロジスティックス、試験、製造／生産、人
間工学、品質保証、安全工学などがある。したがって、専門工学の役割の一つは、「ミッシ
ョンの保証」である。他方、システムエンジニアの仕事の一部は、こうしたミッション保
証業務が適時にプロジェクトに導入され、適切な問題に取り組んでいるかどうかを確認す
ることである。
専門工学分野の役割を説明する際に採用するもう一つの概念は、「X 向け設計」という概
念である。「X」とは、プロジェクト・レベルのシステムエンジニアがプロジェクトの目標
／目的を達成するために考慮する必要のある各種エンジニアリング「特性」（たとえば信頼
性、試験性、生産性、支援性など）を指す。関連専門工学分野は多岐にわたるため、NASA
のプロジェクトに応じて変わってくるが、常に必要となる分野もある。各製品開発チーム
（PDT＝Product Development Team）に必要となる特定の専門工学分野を特定するのは、シ
ステムエンジニアの仕事である。システムエンジニアリング・プロセスと一緒に実施すべ
き技術作業に専門工学分野を導入する選定済みの組織的方法については、システムエンジ
ニアリング・マネジメント計画書（SEMP＝Systems Engineering Management Plan)（パー
ト III）にその概要を記載すべきである。プロジェクトの種類と適用範囲によっては、技
術作業において、さらに詳細な各専門工学計画立案書という文書を必要とする場合もある。
技術作業の一環として、専門技術者は各種専門分野に共通する業務を実施することも多
い。専門技術者は、第一に専門解析技法を採用して、プロジェクトマネジャとシステムエ
ンジニアが必要とする情報を生成する。また、それぞれの専門分野におけるシステム要求
事項の設定と記載を助け、データ・パッケージ、技術変更要求書（ECR＝Engineering Change
Requests)、試験結果、主要プロジェクト審査向け文書などを審査する。プロジェクトマネ
ジャやシステムエンジニアは、そのようにして得られた情報と文書がプロジェクトに付加
価値を与え、そのコストに見合ったものとなるかどうかを確認する。
専門工学分野の技術作業は、時間と内容の両面でもうまく導入すべきであり、各種の組
織や専門分野を分離して孤立化させるべきではない（つまり、4 人が 2 組に分かれて競技を
行うゴルフ・フォーサムというよりも、バスケットボール・チームのようにすべきである）。
- 163 -
それは、たとえば、信頼性技術者の FMECA（failure mode, effects, and criticality
analysis ＝故障モード影響及び致命度解析）（またはそれと同等の解析）結果を適時に保
守 技 術 者 へ 送 り 、 次 に 保 全 技 術 者 の 保 全 性 解 析 を ロ ジ ス テ ィ ッ ク ス 支 援 解 析 （ LSA ＝
logistics support analysis）に導入するということである。さらに、LSA 結果を適時にプ
ロジェクト・レベルのシステムエンジニアに送り、主要トレード研究に必要なその他のコ
スト・効果データと組み合わせる。同時に、信頼性技術者の FMECA 結果をリスク・マネジ
ャにも送り、必要に応じてクリティカルアイテムをクリティカルアイテムリスト（CIL＝
Critical Items List)に記入すると共に、製品開発チーム（PDT＝Product Development Team)
に対して適切な設計または作業軽減化戦略を策定するよう警告する。品質保証技術者の作
業は、信頼性技術者の作業と統合化すべきである。それによって、たとえば、後者の信頼
性モデルによる構成部品故障率の想定条件を、実際の（飛行用）ハードウェアにより達成
するか改善化することもできる。実際の各プロジェクトでは、このような手続き上の調和
と適時性は容易には実現できない。それでも、それらがシステムエンジニアリングの目標
であることには変わりはない。
6.2
信頼性
信頼性とは、部品、製品またはシステムが特定の運用条件下において所定期間故障しな
い確率であると定義できる。信頼性はシステム特有の設計特性である。運用・支援費とシ
ステム効果に寄与する主要要素として、信頼性はシステムのコスト効果算定においても重
要な役割を果たす。
6.2.1
信頼性技術者の役割
信頼性工学は、コスト効果のあるシステムの目標に寄与する主要専門分野である。シス
テムエンジニアリング・プロセスにおいてこのような専門業務を実施するには、主として、
ミッション全体において予測される物理的環境内でシステムが機能できるような特定の設
計特性を採用する面で積極的な役割を果たすと共に、設計トレードと（試験プログラム、
運用、総合ロジスティックス支援）計画のためにシステムの信頼性を独自に予測する必要
がある。
- 164 -
信頼性関係式
システムエンジニアは、連続運用システムに関する以下の信頼性パラメータと関係式に精
通していなければならない。
名称
記号
関係式
ハザード率
λ(t)
=-(1/R)dR/dt
信頼性
R(t)
=
累積故障確率
故障確率密度
F(t)
f(t)
=
∫
∞
∫
t
t
0
f(τ)dτ
f(τ)dτ
=-dR(t)/dt
=f(t)/(1-F(t))
=1-F(t)
=1-R(t)
=λ(t)R(t)
多くの信頼性解析では、故障が偶発的なものでλ（t）＝λとなり、故障確率密度が指
数分布通りであると想定する。その場合は、R（t）＝exp（−λt）、平均故障時間（MTTF＝
Mean Time to Failure）＝1／λとなる。多くのシステムに適用されているもう一つの想定
条件は、ワイブル分布通りの故障確率密度である。その場合には、ハザード率λ（t）が t
に応じた簡単な power law を満たす。ワイブル・パラメータを適正に選択すると、特別ケ
ースとして一定のハザード率を回収できる。こうした（または同様の）想定条件は解析上
便利だが、システムの実ハザード率は予測しにくい。（枠内補足記事「バスタブ曲線」も参
照）。
信頼性技術者はいくつかの業務を実施する。その業務についての詳細は、NHB(NASA
Handbook＝NASA ハンドブック）5300.4(1A-1) "Reliability Program Requirements for
Aeronautical and Space System Contractors"(航空宇宙システム契約者に対する信頼性プ
ログラム要求）に説明されている。要するに、信頼性技術者の業務としては、次のものが
ある。
・
信頼性プログラム計画書を作成かつ実行する
・
信頼性予測モデルならびにその関連環境（たとえば振動、音響、熱、EMI／EMC
（electromagnetic interference/electromagnetic compatibility＝電磁干渉／電
磁適合性））モデルを開発かつ改良し、システム信頼性予測を実施かつ改良する。こ
れらのモデルと予測には、これまでのプロジェクト経験をできるかぎり反映させる
べきである
・
信頼性目標と環境設計要求事項を設定かつ配分する
・
冗長度や信頼性対保全性のような問題を扱った設計トレード研究を支援する
・
リスク・マネジメントを支援するために、信頼性問題の原因となりそうな設計属性
- 165 -
を特定し、適切なリスク軽減化対策を推奨する
・
プロジェクトの保全計画や ILS（Integrated Logistics Support＝総合ロジスティッ
クス支援）計画に適時に使用できる信頼性データを作成する
・
ハードウェア認定試験に必要な環境試験要求書と環境試験仕様書を作成する。信頼
性技術者は、認定試験要求事項を削除または緩和するために技術解析を実施し、そ
れを正当化することもできる。このような作業は通常、プロジェクトの検証計画と
も緊密に調整される
・
信頼性予測を検証し、システムの信頼性予測モデルを妥当性確認し、異常を解明か
つ解消するために、認定試験データの解析を行う
・
総合的システム検証の一環として、実際の運用条件下において信頼性データを収集
する
信頼性技術者は、システムの信頼性問題に関する限り、他の専門技術者（たとえば品質
保証、保全性、検証、生産性技術者）とも協力する。小型プロジェクトでは、信頼性技術
者がこのような他の専門業務の一部またはすべてを実施することもある。
6.2.2
信頼性プログラムの立案
プロジェクトの信頼性プログラムでは、信頼性工学を支援する作業について説明する。
信頼性技術者は、コスト、スケジュール、リスク面も考慮した信頼性計画書を作成する。
この信頼性プログラムの立案は、フェーズ A から開始すべきである。プロジェクトマネジ
ャやシステムエンジニアは、信頼性技術者と協力して適切な信頼性計画を策定しなければ
ならない。それは、信頼性プログラムの作成では多くの要素を考慮する必要があるからで
ある。それらの要素としては、次のものがある。
・ NASA のペイロード分類法。信頼性計画における問題と故障の解析内容とその文書は、
通常、クラス D よりもクラス A のペイロードの方が広範に渡っている。（分類法の指
針については、添付資料 B.3 を参照）
・
ミッションの環境リスク。ミッション環境モデルは、数種開発する必要がある。飛
行プロジェクトの場合は、地上（輸送および取扱い）環境、打上げ環境、軌道（地
球軌道またはその他軌道）環境、惑星環境のモデルも必要になる。さらに、信頼性
技術者としては、その各環境における設計要求と検証要求にも取り組まなければな
らない
・
設計の継承度とハードウェア／ソフトウェアの再利用度
信頼性技術者は信頼性プログラムを「信頼性プログラム計画書」として文書化し、さら
にその計画書の概要をシステムエンジニアリング・マネジメント計画書（SEMP＝Systems
Engineering Management Plan)に記載し、プロジェクト・ライフサイクルを通して必要に
応じた更新をすべきである。小型プロジェクトでは、その概要だけで十分な場合もある。
- 166 -
月探査船（LEM＝Lunar Excursion Module）の信頼性
信頼性技術者の仕事の一部は、すべての故障を偶発的なものと想定せずに、故障の基本的
原因となる物理的要因と人的要因を究明することである。グラマン社の Joseph Gavin 月探
査船（LEM＝Lunar Excursion Module）計画担当部長によると、「［LEM の］各構成要素と各
サブシステムを約 10 年間試験した結果、［NASA では］異常らしきものを 14,000 件も発見し
たが、そのうち究明されなかったものはわずか 22 件にすぎない」ということである。
バスタブ曲線
多くのシステムでは、ハザード率関数が下のグラフのような典型的な「バスタブ曲線」を
示す。バーンイン故障や不適切な品質保証慣行のために、当初はλ（t）値が高いが、初期
の故障率期間中に徐々に低下する。有効寿命期間中は、λ（t）値が一定になり、故障が偶
発的に発生することを反映している。その後は、摩耗故障のためにλ（t）値が上昇し始め
る。信頼性指数関数が適用されるのは、有効寿命期間中だけである。
ハザード率、λ(t)
標準的機械設備
標準的電
気設備
バーンインまたは
デバッギング期間
有効寿命
期間
偶発
故障率
時間またはサイクル数
摩耗期間
出所：H.E. Lambert、Lawrence Livermore Laboratory 報告書、UCRL-51829、1975年
最新の「シャトル」データを使用すると、次のような図が得られた。そのバスタブ曲線は本物か？
補正（予定外）
保守作業件数／軌道飛行時間数
1.0
コロンビア
チャレンジャー
0.8
アトランティス
ディスカバリー
0.8
エンデバー
出所：T.Weber、Rockwell
International社、
宇宙システム事業部
第1回ポスト51L飛行
0.4
0.2
0
1000
2000
3000
4000
5000
6000
7000
8000
9000
10000
軌道飛行累計時間数
6.2.3
信頼性のある宇宙空間用システムの設計
これまでも常に、信頼できる宇宙空間用システムの設計が NASA の目標であり、多くの苦
い教訓も得てきた。システムエンジニアとしては、信頼性を達成するための基本的な設計
方法を知っていなければならない。この基本的な設計方法としては、「故障回避」、「故障許
- 167 -
容範囲」、「機能の冗長性」などがある。
故障回避
故障回避は、信頼性技術者と品質保証技術者にとっての共通の目的であり（第 6.3 項を
参照）、次のような努力からなる。
・
設計余裕を設けるか、できるかぎり適切なディレーティング（負担軽減）方針を採
用する
・
必要な場合に高品質の部品を使用する。（S クラス部品の故障率は、通例、一般軍事
用調達部品の 1／4 である）
・
材料パッケージや電子部品パッケージを慎重に検討する。
・
製造施設、製造工程、製造関係文書に対して公式検査を実施する。
・
すべての部品に対してできるかぎり受領試験や受領検査を実施する。
直列接続の2 ユニット：
R＝RaRb
a
b
故障許容範囲
実並列接続の2 ユニット：
R=1-（1−Ra）
（1−Rb）
a
ユニットb が待機状態
の2 ユニット：R＞Ra
故障許容範囲は、何らかの構成要素が故
障してもシステムが動作し続ける能力に関
連があるシステム設計特性である。この動
a
b
作継続能力は、設計の冗長性と故障検出応
答機能から得られる。設計の冗長性にはい
b
くつかの形があり、そのうちの数例を信頼
性関係式と共に図 29 に示す。
クロスリンクL のあるシステム：
R＝
（Ra＋Rb−RaRb）
（1−
（1−Rc）
（1−Rd）
）
a
c
機能の冗長性
機能の冗長性は、ミッション要求事項を
b
d
十分満たすように、システムが構成要素の
故障に対応できるというシステムの設計・
図29 信頼性の基本ブロック図
運用特性である。このような特性
は通常、本来の意図とは異なる運用次善策
方法と構成要素の使い方を伴うものである。たとえば木星探査機「ガリレオ」では、損傷
した高利得アンテナは補修できなかったが、ソフトウェアの決定位置により次善策を達成
し、科学データと映像をさらに圧縮した。その後、データ伝送速度は著しく低下したが、
こうした圧縮データと圧縮映像が低利得アンテナから回収された。
この 3 方法の実施費用はそれぞれ異なる。S クラス部品は通例高価だが、冗長性はシステ
ムの質量、体積、費用、複雑性を増大させる。したがって、プロジェクトが異なれば、異
なった信頼性達成方法を採用するのがよい。各種方法の中から最適方法を選択するには、
- 168 -
システムエンジニアとしては、各方法ごとにシステム・レベルの効果とライフサイクル・
コストを把握しておかなければならない。そのためには、第 5.1 項に述べたトレード研究
方法と、信頼性解析のツールおよび技法を併用すべきである。
6.2.4
信頼性解析のツールと技法
信頼性ブロック図
複雑なシステムの各種構成要素が一緒に機能する状態を示すには、信頼性ブロック図を
使用する。このブロック図は、各種構成要素の接続のしかたを簡潔に示したものである。
図 29 には、信頼性基本ブロック図を示す。
故障樹形図(FT)と故障樹形図解析(FTA)
故障樹形図は、何らかの（望まない）トップ事象の原因となる数件の故障の組み合わせ
を示す図である。この故障樹形図は通常、故障樹形図解析時に作成される。故障樹形図解
析は、トップ事象が確実に発生する道筋を明らかにする質的技法である。
故障樹形図を作成する場合は、連続的
トップ事象
T
この故障樹形図には、
2 つの最小カットセッ
トがある。その一方
（事象C）は単一点故
障を示す。
AND
ゲート
に連結してトップ事象に至る。こうして
連結された事象群は、「ゲート」という
記号で接続された樹形図構造を形成す
中間故
障事象
E1
付随故障事象を特定し、それらを論理的
る。そのいくつかの基本例を図 30 の樹
E2
形図に示す。故障樹形図の作成と故障樹
形図解析を、完全な確率的リスク評価
A
E3
C
（PRA＝probabilistic risk
E4
assessment)の準備段階とする場合が多
い。この技法の詳細については、米国原
OR
ゲート
子力規制委員会（NRC＝Nuclear
C
B
A
B
基本故障事象
Regulatory Commission)の"Fault Tree
Handbook"(「故障樹形図ハンドブック」）
を参照されたい。
図30 単純故障樹形図
信頼性モデル
各構成要素の信頼性予測から各種アーキテクチャ／設計案の信頼性を予測するには、信
頼性モデルを使用する。単純なシステムの場合は、信頼性ブロック図に示された各種構成
要素と「連結糸」に確率の法則を適用して信頼性を算定することが多い。（図 29 を参照）。
さらに複雑なシステムの場合は、システムの故障樹形図の評価にしばしば「最小カットセ
- 169 -
ット」（minimal cut sets）法を採用する。この方法はブール(Boolean)代数定理に基づい
たものである。各構成要素の信頼性関数自体が不確定な場合は、モンテカルロ・シミュレ
ーション法を採用する方が良い。これらの方法の説明は信頼性工学のテキストにも記載さ
れ、信頼性計算向けソフトウェアも広く利用されている。モデル／ソフトウェアの編集に
ついては、D. Kececioglu 著 "Reliability, Availability, and Maintainability Software
Handbook"（「信頼性、アベイラビリティ、保全性ソフトウェア・ハンドブック」）を参照さ
れたい。
FMECA と FMEA
故障モード、影響及び致命度解析（FMECA＝Failure Modes, Effects, and Criticality
Analysis）と故障モード・影響解析（FMEA＝Failure Modes and Effects Analysis）は、
ハードウェアの故障および安全性リスクを識別し、その特性を表示する専門技法である。
（第 4.6.2 項も参照）。
問題／故障報告書（P／FR＝Problem/Failure Report）
認定試験時と受領試験時（フェーズ D）および運用時（フェーズ E）に遭遇した信頼性問
題と不具合問題を報告する場合、信頼性技術者は問題／故障報告システム
（Problem/Failure Reporting System)を使用する。
6.3
品質保証
使用できる各種設計のうちの最適設計を使用しても、ハードウェアの製造（またはソフ
トウェアのコード化）と試験では、自然と人間の気まぐれから逃れることはできない。そ
のため、システムエンジニアとしては、実際に生産して納入したシステムがその機能、性
能、設計上の要求事項を満たしているかどうかを確認する必要がある。品質保証（QA＝
Quality Assurance)では、プロジェクト・ライフサイクル中に生産されたアイテムと使用
された製法の個別評価結果をプロジェクトマネジャやシステムエンジニアに提示する。品
質評価技術者は、いわば、このような品質評価においてシステムエンジニアの目と耳の役
割を果たす。プロジェクトマネジャやシステムエンジニアは、品質評価技術者と協力して、
プロジェクトに適した品質評価計画（品質評価作業の範囲、責任、時期）を策定しなけれ
ばならない。信頼性計画の場合と同様、品質評価計画も NASA のペイロード分類法に大幅に
左右される（添付資料 B.3 を参照）。
6.3.1 品質保証技術者の役割
品質保証技術者はいくつかの業務を実施する。その業務の詳細については、NHB(NASA
Handbook＝NASA ハンドブック）5300.4(1B) "Quality Program Provisions for Aeronautical
- 170 -
and Space System Contractors"(「航空宇宙システム契約者向けの品質プログラム規定」）
に記載されている。端的に言えば、これらの業務は次のものである。
・
「品質保証プログラム計画書」(Quality Assurance Program Plan)を作成かつ実施
する
・
コンフィギュレーション・マネジメント手続きとその関係文書が完全なものかどう
か を 確 認 す る と 共 に 、 ECRs ／ ECPs(Engineering Change Requests/Engineering
Change Proposals ＝技術変更要求書／技術変更提案書）の最終結果を監視する（第
4.7 項を参照）
・
調達元の評価と選定に参加する。
・
製造／組立て中のアイテムと施設ならびに NASA フィールドセンターへ納入済みのア
イテムを検査する
・
要員のトレーニングと、製造／組立て中に使用される技術文書が適切なものかどう
かを確認する
・
特に試験環境、試験用コンフィギュレーション、合格／不合格規準に関して、検証
要求事項が適正に指定されているかどうかを確認する
・
認定試験と受領試験を監視し、検証要求書と試験要領書に適合しているかどうか、
試験データが適正かつ完全なものかどうかを確認する
・
各種不具合と問題／故障報告書（P／FRs＝Problem/Failure Reports)に対する解決
策と最終決定を監視する
・
システムの物理的コンフィギュレーションが、CDR（Critical Design Review＝詳細
設計審査）で承認された"build-to"（または"code-to")文書に適合しているかどう
かを検証する
・
故障解析向け品質保証（QA＝Quality Assurance)データを収集かつ保管する
また、品質保証技術者は、製品システムの品質を落とす恐れのある設計、材料、ワーク
マンシップ、製造・検証プロセス、その他特性上の問題点に対する主要審査［主として SRR
（System Requirements Review＝システム要求審査）、PDR(Preliminary Design Review＝
基本設計審査）、CDR（Critical Design Review＝詳細設計審査）、FRR(Flight Readiness
Review＝飛行準備審査）］にも参加する。
6.3.2
品質保証のツールと技法
PCA／FCA
物理的コンフィギュレーション監査（PCA＝Physical Configuration Audit）では、シス
テムの物理的コンフィギュレーションが承認済みの"build-to"（または"code-to")文書に
適合しているかどうかを検証する。機能コンフィギュレーション監査（FCA＝Functional
Configuration Audit）では、受領検証（通常は受領試験）結果が承認済みの検証要求書に
- 171 -
適合しているかどうかを検証する。（第 4.8.4 項を参照）。
インプロセス検査
インプロセス検査（In-Process Inspections）の適用範囲、実施時期、実施場所は、品
質保証プログラム計画書に記載されている。この検査は、製造／組立計画立案書および検
証計画立案書に従って実施すべきである。（第 6.6 項と第 6.7 項を参照）。
QA サーベイ
品質保証（QA＝Quality Assurance）サーベイは、プロジェクトで実施する諸作業と手続
き、プロジェクトで使用する書類を調べ、所定の規格と基準に対比して評価する。補正対
策に関する推奨事項は、プロジェクトマネジャに報告する。
再審委員会
再審委員会（MRB＝Material Review Board)は、通常プロジェクトマネジャが設置し、プ
ロジェクト・レベルの品質保証技術者が委員長になり、不具合品に関する正式処分を実施
する。
6.4
保全性
保全性とは、システムを運用状態のまま容易に保管できるものか、故障後もシステムを
安全かつ経済的に運用状態に容易かつ迅速に回復できるものかという点を示すシステム設
計特性である。（不完全ながらも）しばしば採用される保全性測定項目としては、平均保守
ダウンタイム、運用 1 時間当たりの保全作業量（作業時間数）、年間保守全費用などがある。
どのように測定しても、保全性は、システムのハードウェア・ソフトウェア設計、保全要
員の所要技能レベル、診断・保全手順の適性、試験設備の有効性、保全作業を実施する物
理的環境など、多くの要因に左右される。
6.4.1
保全性技術者の役割
保全性工学は、コスト効果のあるシステムの目標に寄与するもう一つの主要専門分野で
ある。システムエンジニアリング・プロセスにおいてこのようなシステム目標の達成に寄
与するのは、主として予測される物理的環境内で安全な保全作業を容易に実施できるよう
な特定の設計特性を採用するという積極的な役割と、総合ロジスティックス支援（ILS＝
Integrated Logistics Support)システムを開発するという中心的役割を通してである。
（ILS については、第 6.5 項を参照）。
保全性技術者はいくつかの業務を実施する。その業務の詳細については、NHB（NASA
- 172 -
Handbook ＝NASA ハンドブック）5300.4(1E) "Maintainability Program Requirements for
Space Systems"(「宇宙システムの保全性プログラム要求」）に記載されている。端的に言
えば、その業務は次のものである。
・ 「保全性プログラム計画書」（Maintainability Program Plan）を作成かつ実行する。
この作業は通常、総合ロジスティックス支援（ILS＝Integrated Logistics Support）
プログラム計画書と並行して実施される。
・
総合ロジスティックス支援（ILS＝Integrated Logistics Support）概念の一環とし
て、システムの保全性概念を設定かつ改良する。
・
保全性要求事項を設定かつ配分する。この要求事項は、保全性概念に適合し、シス
テム・レベルのアベイラビリティ目的に起因したものとすべきである。
・
・
保全性設計の欠陥を指摘するために工学設計解析を実施する。
各種解析を実施してシステムの保全性資源要求事項を定量化し、保全計画書
（Maintenance Plan）にそれらを記載する。
・
シ ス テ ム の 保 全 性 要 求 事 項 と 、 総 合 ロ ジ ス テ ィ ッ ク ス 支 援 （ ILS ＝ Integrated
Logistics Support）要求事項の保守関係面が満たされているかどうかを検証する。
・
総合ロジスティックス支援（ILS＝Integrated Logistics Support）システム妥当性
確認の一環として、実際の運用条件下における保全性データを収集する。
上述の解析作業の多くは、第 6.5.3 項に述べるロジスティックス支援解析（LSA＝
Logistics Support Analysis）の一環として実施する。保全性技術者は、プロジェクトの
各フェーズに適する上記業務項目に関する主要プロジェクト審査にも参加し、それらの審
査を支援する。
6.4.2
システム保全概念と保全計画
システム運用概念とユーザー要求事項が変われば、総合ロジスティックス支援（ILS＝
Integrated Logistics Support）概念も変わる。この ILS 概念の中心となるのはシステム
保全概念である。システムの保全設計要求事項とそのロジスティックス支援資源要求事項
を（ロジスティックス支援解析（LSA＝Logistics Support Analysis）プロセスを通して）
設定する際には、この保全概念がその設定基準として使用される。システム保全概念を設
定する際には、ミッションのプロファイル、システムの使い方、システムの運用アベイラ
ビリティ目標、予測有効寿命、物理的環境などを考慮する必要がある。
従来、システム保全概念の記述方法はハードウェア指向だが、必ずしもそうする必要は
ない。システム保全概念では、従来、予測保全レベル（枠内補足記事「保全レベル」を参
照）、補正・予防保守向けの一般的補修対策、供給システムの対応性に関する想定条件、新
設または既存施設のアベイラビリティ、保全環境などを記述する。当初は、同じようなシ
ステムの経験に基づいてシステム保全概念を設定してもよいが、プロジェクト・ライフサ
- 173 -
イクルの初期段階にトレード研究を必ず実施すべきである。このトレード研究では、シス
テム全体の最適化という点から各種保守概念案のコスト効果に重点を置くべきである。
宇宙ステーション「アルファ」の各種保全レベル
多くの複雑なシステムの場合と同様、宇宙ステーション「アルファ」の保全概念には、「組
織」、「中間」、「倉庫」（または「売り手」）という 3 つの保守レベルが必要になる。システ
ムエンジニアとしては、こうした用語の他、各レベルに関連のある基本特性に通じていな
ければならない。一例として、「アルファ」の場合を考えてみよう。
レベル
組織
実施作業
軌道上の乗組員が軌道交換ユニット
（ORU＝Orbital Replacement Unit）の
取りはずしと交換、目視検査、小規模
補修整備と校正を実施する。
予備品
少量
中間
ケネディ宇宙センター（KSC＝Kennedy
Space Center)の保全施設で軌道
交換ユニット（ORU）の補修、詳細検査、
整備、校正、若干の変更を行う。
多種
倉庫／
売り手
工場で大規模なオーバーホール、変更、
複雑な校正を実施する。
非常に多種
必要に応じて製造する
保守計画書（Maintenance Plan）は、システムの保全概念、保全資源要求事項、支援保
全解析について記載したもので、総合ロジスティックス支援計画書（ILSP＝Integrated
Logistics Support Plan)に主要技術項目として編入される。保全計画書には、さらに予備
品、保全施設、試験設備と支援設備など、ILSP に必要なその他の事項も記載するほか、「各
保全レベルごとに」保全要員の訓練計画、訓練施設、技術データ、教材なども記載する。
支援保全解析では、補正・予防保全作業量、初期およびその後の予備品所要供給量、シス
テムのアベイラビリティなどの総予測値に基づき、保全計画書の実行性と信頼性を予測す
べ き で あ る 。 こ の 総 予 測 値 は 、 ロ ジ ス テ ィ ッ ク ス 支 援 解 析 （ LSA＝Logistics Support
Analysis）に適する慣行上最適な保全解析ツールと詳細保全データを使用して得たものと
する。（第 6.5.3 項を参照）。
6.4.3
保全可能な宇宙用システムの設計
将来は、保全可能な NASA 宇宙用システムの設計がますます重要になる。それゆえ、シス
テムエンジニアとしては、船内活動（IVA＝Intravehicular activity)と船外活動（EVA＝
Extravehicular activity)による保全作業を容易にする基本設計特性を十分認識する必要
がある。そのための良い慣行例としては、次のものがある。
・
軌道交換ユニット（ORU＝Orbital Replacement Unit）の設置と取りはずしを容易に
- 174 -
行えるように、必要に応じて設置用粗調整および微調整ガイドを使用する
・
インタフェース用ツールとハードウェア構造間の走査用すき間(sweep clearances)
をできるだけ小さくし、開口部に接近する必要がある保全作業向けに十分な最大活
動範囲（clearance envelope) を設ける
・
IVA お よ び EVA 保 守 作 業 向 け に 、 許 容 活 動 範 囲 （reach envelope）、乗組員の
loads/forces や作業上の一般的制約を設定する
・
軌道交換ユニット（ORU）設置場所における補正・予防保守作業頻度を検討する
・
いかなる ORU の交換も、他の ORU を取りはずさずに行えるようにする
・ ORU 交換時や他の ORU の保守作業時の劣化や損傷を予防できるようなシステム熱設計
を選択する
・
設備や部品の誤った取扱いを少なくするために、ORU の取扱い方を簡単にする
・
アイテム数をできるだけ少なくするために、ツールおよびハードウェアアイテムの
共通化、規格化、互換性を奨励する
・
良好な設計慣行に合わせて接近時間をできるだけ短縮化するような ORU 用ファスナ
を選択する
・
IVA または EVA 保守作業中、何らかの ORU の取りはずし、交換、試験、検査時に安全
ハザードが生じないように ORU の表面構造を設計する。ミッションや安全性にとっ
て重要な ORU に関しては、注意事項や警告も記入する
・
変更、検証、拡張を容易にするソフトウェアを設計する
・ ミッションや安全性にとって重要な機能を遮断せずに、オンラインでソフトウェア・
セグメントを交換できるようにする
・ 危険な条件を導入させずに、オンラインやオフラインでソフトウェアの変更、交換、
検証を行えるようにする
6.4.4
保全性解析のツールと技法
保全用機能流れブロック図（FFBD）
保全用機能流れブロック図（FFBD＝Functional Flow Block Diagrams)は、添付資料 B.7.1
で説明するシステム用 FFBD と同じように使用する。トップレベルの保全用 FFBD は、シス
テム保全概念を補足し、明確化する。低レベルの保全用 FFBD は、ロジスティックス支援解
析（LSA＝Logistics Support Analysis）の保全作業目録の基盤となる。
- 175 -
HST 補修作業（STS−61）から得た保全性に関する教訓
（このハンドブックの編集上）保全性に関してミッションからどんな教訓を得たかと質問
した時、STS(Spacecraft Tracking Station＝宇宙機追跡局）−61 の職員は次のように答え
た。
・ ハッブル宇宙望遠鏡（HST＝Hubble Space Telescope）の設計に導入した保全性要件
がうまく働いた
・ LEO(Low Earth Orbit＝低高度地球周回軌道）の宇宙機の場合は、補修整備オプショ
ンを除外してはならない。つまり、コストと質量に影響を及ぼしても、たとえば固
定把持具などを装備することである
・ 補修整備が保全概念の一部となる場合は、宇宙機全体にそれを適用する。（たとえば
HST の太陽電池電子制御箱は交換できるように設計されていなかったが、やはりそう
すべきだった！）
・ 握り棒のサイズを適正にするとか、取りはずしや再取り付けを容易に行えるコネク
タやファスナーを使用するといった細部に注意を払う
その他の助言：
・ 地上用モックアップや図面が「配備通りの」(“as-deployed” )コンフィギュレーショ
ンを正確に示すものかどうかを確認する
・ 特に新型ツールを採用する場合は、ツール・システム間のインタフェースを検証す
る
・ 保全性計画には、実状に合った保全作業訓練対策を盛り込む
保全タイムライン
回復時間（time-to-restore)をミッションの有効性や安全性の重要要素とみなした場合
は、保全のタイムライン解析（添付資料 B.7.3 を参照）を実施する。（そのようなケースに
は、EVA(Extravehicular activity＝船外活動）補修や緊急補修の手順を含めることもでき
るであろう）。保全タイムライン解析は、簡単なスプレッドシートによるものから広範なコ
ンピュータ・シミュレーションと試験を伴うものまで多岐にわたる。
FMECA と FMEA
故障モード、影響及び致命度解析（FMECA＝Failure Modes, Effects, and Criticality
Analysis）と故障モード・影響解析（FMEA＝Failure Modes and Effects Analysis）は、
ハードウェアの故障および安全性リスクを識別し、その特性を表示する専門技法である。
この両解析については、このハンドブックのリスク・マネジメントの項（第 4.6.2 項も参
照）と信頼性工学の項（第 6.2.4 項を参照されたい）において説明した通りである。保全
性技術者としては、LRU(Line Replaceable Unit＝ライン移転ユニット）／ORU（Orbital
Replacement Unit＝軌道交換ユニット）レベルにおいて故障予測データ［つまり MTTF（mean
time to failure＝平均故障時間）や MTBF（mean time between failures＝平均故障間隔）］、
故障検出手段、補正保全対策の特定（LSA 作業目録の場合）などにより、FMECA／FMEA を強
化する必要がある。
- 176 -
保全性モデル
各種設計案が保守性要求事項をどの程度満たしているかを評価する場合や保全資源要求
事項を定量化する場合には、保全性モデルを使用する。そのモデル作成方法は、構成要素
のデータを集計するスプレッドシートの作成から、複雑なマルコフ・モデルや確率的シミ
ュレーション・モデルの作成まで多種多様である。モデル作成では、既成システムの同種
構成要素による経験から得た LRU／ORU レベルの信頼性データと回復時間データを使用する
場合が多い。このようなモデルの用途としては、次のものがある。
・
年間保全時間数や保全ダウンタイムの予測
・
システムの MTTR(Mean Time to Repair＝平均修理時間）とアベイラビリティ予測（枠
内補足記事「アベイラビリティの算定」を参照）
・
信頼性と保全性のトレードオフ
・
LRU／ORU（ライン移転ユニット／軌道交換ユニット）の最適修復規準分析（ORLA＝
Optimum Repair Level Analysis)
・
（信頼性を中心とした）最適予防保全解析
・
予備品要求事項解析
・
（宇宙用）予備品の質量／体積予測
・
補修対廃棄分析
LSA と LSAR
ロジスティックス支援解析（LSA＝Logistics Support Analysis）は、システムエンジニ
アリング・プロセスへ支援性要件を導入する正式の技術的手法である。上述のツールと技
法の多くは、保全性データを LSA に導入するか、LSA 結果を得るために使用される。LSA 結
果は、ロジスティックス支援解析記録（LSAR＝Logistics Support Analysis Record)のデ
ータ表に収録される。このデータ表は、ベースライン化された ILS システムを正式に文書
化したものである。（第 6.5.3 項を参照）。
問題／故障報告書（P／FR）
保全性技術者は、問題／故障報告システム（P／FRS＝Problem/Failure Reporting System）
（または承認済みの同等のシステム）を使用して、認定試験や受領試験時（フェーズ D）と
運用時（フェーズ E）に遭遇した保全性問題と不具合を報告する。
6.5
総合ロジスティックス支援
システムエンジニアリング・プロセスの下で実施される総合ロジスティックス支援（ILS
＝Integrated Logistics Support）活動では、開発段階（フェーズ D）と運用段階（フェー
ズ E）においてコスト効果が得られるように製品システムを支援する。そのためには主とし
- 177 -
て、初期段階において各種支援特性を同時に検討し、各種システム概念案と各種 ILS 概念
案に関するトレード研究を実施し、慣行上最良の技法を使って各 ILS 要素の資源要求事項
を定量化し、各 ILS 要素に関連のある支援アイテムを取得する。運用段階における ILS 活
動では、システムを支援する他、実際の運用条件の下で各種解析を行ってコスト効果の向
上を図る。これらの解析により、ILS システムとその資源要求事項を絶えず練り直す。ILS
を無視したり、ILS の決定が不適正であると、得られたシステムのライフサイクル・コスト
に必ず悪影響を及ぼす。
6.5.1
ILS 項目
NHB(NASA Handbook＝NASA ハンドブック）7120.5 によると、ILS の適用範囲として以下の
9 つの項目を挙げている。
・
保全整備：
システムの持続的運用に必要なライフサイクル補修／整備概念とその
要求事項を立案かつ実行する過程
・
設計インタフェース：
支援性がシステムの定義と設定に影響を与え、ライフサイ
クル・コストを削減するような、ロジスティックスとシステムエンジニアリング・
プロセスの相互作用と関係
・
技術データ：
システムの定義、生産、試験、評価、変更、引渡し、支援、運用に
使用される科学的、工学的、技術的、コスト上の記録情報
・
トレーニング：
システムの運用要員と支援要員のトレーニング（訓練）に必要と
なる方法、手続き、装置、設備
・
供給支援：
システムの支援目的と使用目的を達成するために、あらゆる必要材料
を供給する作業
・
試験設備と支援設備：
システムの開発、生産、運用を容易にするために必要とな
る設備
・ 輸送と取扱い： システムのアイテムと材料の適正かつ安全な移動、取扱い、包装、
貯蔵に必要な作業、資源、方法
・
人的資源と人事計画：
現在と将来の運転員、保守要員、技術者、管理者等の人件
費を考慮して、最良の人材構成を選定する作業
・
6.5.2
システム用施設：
システムの開発と運用に必要となる不動産
ILS 計画の立案
ILS（Integrated Logistics Support＝総合ロジスティックス支援）計画の立案は、プロ
ジェクト・ライフサイクルの初期段階から開始し、「ILS プログラム計画書」として文書化
すべきである。この計画書には、実施予定の各種 ILS 作業、その作業の実施方法とシステ
- 178 -
ムエンジニアリング・プロセスへの導入のしかたを記載する。大型プロジェクトでは、ILS
システム（ILSS）自体が大型システムになる可能性があるので、ILS プログラム計画書を個
別 文 書 と し て 作 成 す る こ と も で き る 。 小 型 プ ロ ジ ェ ク ト で は 、 当 然 、 SEMP(Systems
Engineering Management Plan＝システムエンジニアリング・マネジメント計画書）にそう
した情報を記載する。ILS プログラム計画の重要部分は、ロジスティックス支援解析（LSA
＝Logistics Support Analysis）の実施戦略に関する部分である。それというのも、この
種の解析には、ロジスティックス技術の専門家が多数参加するからである。（第 6.5.3 項を
参照）。
プロジェクト・ライフサイクル全体を通した ILS 作業の「結果」は、通常、総合ロジス
ティックス支援計画書（ILSP＝Integrated Logistics Support Plan)として文書化される。
ILSP はプロジェクトで使用される上級 ILS 文書である。予備 ILSP は、フェーズ B 終了時ま
でに作成し、その後は保管すべきである。この計画書には、プロジェクトのロジスティッ
クス支援概念、プロジェクトのフェーズ別、ILS 項目別の責任体制、さらに LSA 結果、特に
トレード研究結果を記載する。大型システムの ILSP は、システム文書とはまったく別の個
別文書とすべきである。小型システムの ILSP は、他のシステム文書と統合することもでき
る。ILSP には通常、以下の技術項目が含まれる。
・
保全計画書
−
システム保全概念に基づいて立案され、システム設計過程と LSA
過程で練り上げられる。［NMI(NASA Management Instruction＝NASA 管理手引書）
5350.1A "Maintainability and Maintenance Planning Policy"(「保全性及び保全
計 画 政 策 」） お よ び NHB(NASA Handbook ＝ NASA ハ ン ド ブ ッ ク ） 5300.4(1E)
"Maintainability Program Requirements for Space Systems"(「宇宙システムに対
する保全性プログラム要求」）では、ILS という用語を使用していないが、LSA のほ
ぼすべての段階を指定している。保全計画の詳細については、第 6.4.2 項を参照）
・
要員・訓練計画書
−
運転員と保全作業トレーニングを特定するほか、トレーニ
ング用の教科課程、施設、設備、技術データ、特殊訓練用教材などについて説明す
る。NMI 5350.1A／NHB 5300.4(1E) によると、この保全作業訓練項目は保全計画書
に盛り込まれる
・
供給支援計画書
−
予備品（補修可能品と消耗品）と消耗品（LSA により特定され
る）の所要量ならびにその調達、包装、取扱い、貯蔵、輸送方式を扱う。この計画
書では、さらに在庫管理、ブレークアウト・スクリーニング、需要データの収集と
分析といった問題も扱う。NMI 5350.1A／NHB 5300.4(1E) によると、予備品供給項
目は保守計画書に盛り込まれる
・
試験・支援設備計画書
−
必要な試験設備と支援設備（LSA により特定される）の
種類、地理的設置場所、所要量を扱う。NMI 5350.1A／NHB 5300.4(1E) によると、
この項目は保全計画書に盛り込まれる
・
技術データ計画書
−
必要なすべての技術データの収集・保管方式を特定する
- 179 -
・
NMI 5350.1A／NHB 5300.4(1E) によると、トレーニング用技術データは保全計画書
に盛り込まれる
・
輸送・取扱い計画書
−
あらゆる設備、容器、供給品（LSA により特定される）な
らびにシステム構成要素の包装、取扱い、貯蔵、輸送に対する支援方式を扱う
・
施設計画書
−
システムの開発、試験、保管、運用に必要となるあらゆる不動産
を特定すると共に、既存施設の改造によって利用できる要求事項を特定する。この
計画書では、各新設施設や施設改造に関するコストとスケジュールの予測も提示す
る
・
廃棄計画書
−
廃棄に必要な設備、供給品、さらに最終的にはシステム自体も含
め、すべてのアイテム（たとえば廃棄すべき予備品など）の安全かつ経済的な廃棄
方式を扱う
ILS（Integrated Logistics Support＝総合ロジスティックス支援）コスト（つまりシス
テムのライフサイクル・コスト）は、システム設計固有の信頼性と保全特性に左右される。
プロジェクト・レベルのシステムエンジニアとしては、どんなにすぐれた ILS 計画でも、
このような設計特性が設計過程に影響を及ぼすことを認識しなければならない。要するに、
コスト効果のある ILS を達成するための慣行上最適な方法は、以下の作業を実施すること
である。
・
ILS プログラム計画書を作成し、SEMP(Systems Engineering Management Plan＝シ
ステムエンジニアリング・マネジメント計画書）（パート III）と調整する
・
上記計画書の技術部分を実行することにより、システムと ILS 案の最適な組み合わ
せを選定し、その結果設定されたロジスティックス資源要求事項を定量化する
・
選定された ILS システムを文書化し、ロジスティックス資源要求事項の概要を
ILSP(Integrated Logistics Support Plan＝総合ロジスティックス支援計画書）に
記載する
・
システム要求書やシステム仕様書に支援性データを記入する
・
選定済み ILS システムの検証と妥当性確認を行う
6.5.3
ILS のツールと技法：
ロジスティックス支援解析
ロジスティックス支援解析（LSA＝Logistics Support Analysis）は、支援性要件をシス
テムエンジニアリング・プロセスに導入する正式の技術的手法である。LSA はプロジェク
ト・ライフサイクル全体を通してくり返し実施されるので、支援性目的を目指してシステ
ム設計が徐々に改良される。そのために、ILS 技術者は、システムエンジニアリング・プロ
セスにおけるトレード研究で検討すべき支援性要素と支援性関連設計要素を特定する。
「プロジェクト・レベルのシステムエンジニアは、予測システム効果と予測ライフサイク
ル・コストに影響を与えるという形でこうした支援性要件を大幅に導入する」。ILS 技術者
- 180 -
は、（ILSS＝ILS System ＝総合ロジスティックス支援システムに対しては）「システム」技
術者としての役割も果たし、ILSS の機能要求事項を特定し、ILSS に関するトレード研究を
実施し、必要となるロジスティックス支援資源を文書化し、ILSS の検証と妥当性確認を監
視する。
MIL-STD（Military Standards＝米国陸軍標準規格）-1388-1A に記載された LSA プロセス
は、一つの指針として採用できるが、NASA で採用する場合は、プロジェクトに合わせて調
整すべきである。図 31a と図 31b は、NASA のプロジェクト・ライフサイクルにおける LSA
プロセスを詳細に示すものである。LSA プロセスをくり返すたびに、より詳細な入力データ
を使用し、その結果をより一層改良する。そのため、運用段階（フェーズ E）の開始時まで
には、補給すべきあらゆるロジスティックス支援資源も特定され、ILSS も検証済みとなる。
各反復プロセスの第 1 段階では、「ミッション、システム・アーキテクチャ／設計、ILSS パ
ラメータを理解する」。特に、この第 1 段階では、以下の作業も実施する。
システムエンジニアリング・プロセス
初期検討
機能ベース
ライン
フェーズA−予備解析
フェーズB−定義
Ｃ
Ｃ
LSA作業
ILSSの機能要求
事項を特定する。
Ａ
ミッション、システ
ム・アーキテクチャ、
支援システムパラメー
タを理解する。
ILSSの機能要求
事項を特定する。
Ａ
ミッション、システ
ム・アーキテクチャ、
支援システムパラメー
タを理解する。
Ｂ
支援性要素と支援
性関連設計要素を
設定する。
Ｄ
各種ILSS案を
案出する。
Ｂ
支援性要素と支援
性関連設計要素を
設定する。
Ｅ
注：LSA 作業の管理と計画に関連のある作
業は示していない。
作業分析
を行う
Ｄ
各種ILSS 案
を案出する.
Ｅ
各種ILSS案を評
価する／トレード
研究を行う。
検証・
妥当性確認作業
Ｆ
ILSS案を評価す
る／トレード研究
を行う。
Ｇ
Ｇ
支援性検証計
画の立案
支援性検証計
画の立案
図31a ロジスティックス支援解析プロセスフローチャート（フェーズA とB）
システムエンジニアリング・プロセス
"Design-to"
ベースライン
配備状態ベー
スライン
フェーズC／D−設計と開発
Ｃ
LSA作業
ILSSの機能要求
事項を特定する。
Ａ
ミッション、システ
ム・アーキテクチャ、
支援システムパラメー
タを理解する
B
支援性要素と支
援性関連設計要
素を設定する。
フェーズE−運用
Ｆ
新しいILSSの機
能要求事項を特
定する
作業分析
を行う
Ｄ
ILSS案を案出
する。
生産後と打ち上げ
後の支援システム
研究
Ｅ
ILSS案を評価する
／トレード研究を
行う
ILSS案を評価する
／トレード研究を
行う
検証・認証作業
注：LSA業務の管理と計画に関連のある作業
は示していない
Ｇ
支援性検証
計画の立案
各種ILSS案を
案出する
Ｈ
Ｈ
支援性検証
結果／解析
支援性／運用
トレンド解析
図31b ロジスティックス支援解析プロセスフローチャート（フェーズC／D とE）
- 181 -
作業分析を
改定する
・
運用概念、ミッション期間、ユニット数、軌道パラメータ、宇宙輸送オプション、
割当て支援特性など、システムの予定用途関係の要素を（プロジェクト・レベルの
システムエンジニアから）受け取る
・
開発中のシステム向けの ILSS に適用しても、または ILSS と組み合わせてもコスト
効果のありそうな既成のロジスティックス資源能力や資産を文書化する
・ 利用できる技術を明確化する。（この技術には、ロジスティックス支援要求事項を削
減化できる新システム・アーキテクチャ／設計技術と、「いかなる」レベルのロジス
ティックス支援資源要求事項を満たす作業をも低コスト化する ILSS の新技術も含め
る）
・
ILS 概念と当初の想定（「たたき台」的）ILSS を文書化するか、（後半フェーズにお
いて）ベースライン ILSS を更新する
ILS 技術者はこのような作業の結果を使用して、「支援性要素と支援性関係設計要素を設
定し」、それらをプロジェクト・レベルのシステムエンジニアへフィードバックする。つま
り、以下の作業を実施する。
・
検討中の各種システム概念と各種運用概念に関連のある支援性要素を明確化し、そ
れらの数値を推算する。それらの支援性要素には、運用チームの規模、システムの
RAM（reliability 、availability、maintainability ＝信頼性、アベイラビリティ、
保全性）パラメータ、年間推定 IVA／EVA(Intravehicular activity/Extravehicular
activity＝船内活動／船外活動）保守時間数、質量増大要求なども含めることもで
きるであろう
・
上記推算値を使用して、プロジェクト・レベルのシステムエンジニアが行うシステ
ム効果とライフサイクル・コストの予測と、システム・アベイラビリティ目標やシ
ステム支援性目標の設定を支援する。（NHB(NASA Handbook＝NASA ハンドブック）
7120.5 と本ハンドブックの第 5.3.3 項を参照)
・
システム支援性リスクの識別とその特性表示を行う。（NHB7120.5 と本ハンドブック
の第 4.6 項を参照）
・
支援性関係の設計制約を文書化する
LSA（Logistics Support Analysis＝ロジスティックス支援解析）の中心は、次の作業段
階にある。この段階では、ILSS 自体にシステムエンジニアリングと解析が適用される。ILS
技術者はまず最初に、「ILSS に対する機能要求事項を特定する」必要がある。機能解析プロ
セスでは、製品システムに関連のある基本作業目録を作成し、その基本作業目録を使って、
再設計を必要とするシステム設計の欠陥指摘を支援する。その作業目録には、通常、補正・
予防保全作業と、ILSS の機能要求事項から生じるその他の運用・支援作業が含まれる。通
例、保全性技術者が作成する補正・予防保全作業目録に記入される主作業は、FMECA／FMEA
（ Failure Modes, Effects, and Criticality Analysis ／ Failure Modes and Effects
Analysis＝故障モード影響及び致命度解析／故障モード及び影響解析）（またはそれと同
- 182 -
等の解析）である。FMECA／FMEA 自体は、通例、信頼性技術者が実施する。作業目録全体は、
ロジスティックス支援解析記録（LSAR＝Logistics Support Analysis Record)のデータ表
として文書化される。
次に、ILS 技術者は「採用できそうな各種 ILSS 案を案出し」、第 5.1 項に述べたような
「トレード研究を実施する」。このトレード研究では、プロジェクトのフェーズに応じた各
種問題に重点を置く。フェーズ A と B におけるトレード研究では、LEO(Low Earth Orbit＝
低高度地球周回軌道）上の宇宙機を補修整備できるかどうか、有人宇宙ステーションを支
援するにはどんなロジスティックス・モジュール構成が最適と思われるか、どんな保全レ
ベル数と保全位置数が最適かといった高レベル問題に重点が置かれる。フェーズ C と D で
は、たとえば各最終アイテムの最適補修レベルへと視点を変更する。フェーズ E では、シ
ステム設計とそのロジスティックス支援要求事項が十分明らかになっているので、運用デ
ータに照らして各種問題に対するトレード研究を再度実施することが多い。これらのトレ
ード研究ではほぼ常に、LSA 向けに考案された技法とモデルを主に使用する。LSA 技法とモ
デルのカタログについてシステムエンジニアが参照できる資料としては、"Logistics
Support Analysis Techniques Guide"（「ロジスティックス支援技法手引書」）1985 年、陸
軍資材指令部パンフレット第 700-4 号がある。
MIL-STD 1388-1A/2B
NHB(NASA Handbook＝NASA ハンドブック）7120.5 では、LSA（Logistics Support Analysis
＝ロジスティックス支援解析）の実施する指針として MIL-STD（Military Standards＝米国
陸軍標準規格）1388 を挙げている。MIL-STD 1388-1A は次の 5 項目に分けられている。
・ LSA の計画と管理（図 31a と図 31b には示していない）
・ ミッションと支援システムの定義（枠 A と B に示す）
・ 各種代替案の作成と評価（枠 C、D、E に示す）
・ ロジスティックス支援資源要求事項の決定（枠 F に示す）
・ 支援性の評価（枠 G と H に示す）
MIL-STD 1388-1A では、いくつかの役に立つヒントを示し、本ハンドブックに記載した次
のような原則を推奨している： 機能解析、トレード研究による設計の連続改良、システ
ム効果とライフサイクル・コストの重視、適切なモデル、選定規準。
MIL-STD 1388-1B には、ILS 情報と LSA 結果を機械で読み取れる形に文書化するための
LSAR 関係データ表フォーマットとデータ・ディクショナリが記載されている。
フェーズ B の終了時までには、ILSS 機能解析結果とトレード研究結果を十分改善化かつ
詳細化して、ロジスティックス支援資源要求事項に関する量的データを提示すべきである。
それには、作業目録にある各作業に対する「作業分析を行う」必要がある。これらの要求
事項は、LSAR データ表を修正すれば正式に文書化される。プロジェクト・レベルのシステ
ムエンジニアは、ILSS トレード研究、LSA モデル、LSAR データ表から、重要なライフサイ
クルコスト・データと（システム）効果測定値（MoEs＝Measures of effectiveness)を得
る。製品システムの定義が改良され、より適切なデータが得られるに従い、このようなデ
- 183 -
ータと測定値はフェーズ C と D までに連続的に改良される。LSA プロセスへの入力データ（専
門工学分野から得られる）とその結果との関係は、図 27 に示すとおりである（第 5.3 項を
参照）。
LSA を実施する場合、ILS 技術者は、フェーズ D におけるシステムの統合化と検証および
配備（たとえば打上げ）のためにロジスティックス資源要求事項の決定と（LSAR データ表
への）文書化をも行う。ほとんどの宇宙機の場合、これらの支援には打上げ前の輸送、取
扱い、貯蔵、試験も含まれる。初めて打上げられる宇宙システムの場合は、開発打上げ延
期期間中に支援が必要となる。有人宇宙ステーションの場合は、軌道上組立品運用延期期
間中に支援が必要となる。ILS 技術者はリスク・マネジメント作業をも支援し、予備品供給、
ロジスティックス計画、ロジスティックス・プロセスなどの適性を検討する。たとえば、
予備品供給では、システムの予測有効寿命期間中に生産ラインが閉鎖される可能性を考慮
に入れなければならない。
検証・妥当性確認作業の一環として、ILS 技術者は「支援性検証計画」を立案し、フェー
ズ D において支援性検証／試験データを収集する。このデータは、システム設計と ILSS の
欠陥を指摘し、補正する場合や LSAR データ表を更新する場合に使用される。フェーズ E に
おいては、実際の運用条件の下で支援性の試験と解析が実施される。そのデータは、製品
改良作業と将来のプロジェクトのための貴重な遺産である。
6.5.4
連続調達とライフサイクル支援
LSA （ Logistics Support Analysis ＝ ロ ジ ス テ ィ ッ ク ス 支 援 解 析 ） 文 書 と 支 援 用
LSAR(Logistics Support Analysis Record＝ロジスティックス支援解析記録)データ表には、
大量のデータが記載される。定義段階、設計段階、開発段階（フェーズ B から D）では急に
変更が加えられることが多いので、今のところはこのようなデータを適時に利用すること
は難しい。連続調達・ライフサイクル支援（CALS＝Continuous Acquisition and Life-Cycle
Support） −
1993 年にコンピュータ支援調達・ロジスティックス支援（Computer-Aided
Acquisition and Logistics Support）からこの名称に変更された
−
技術を採用すれば、
NASA フィールドセンター間および NASA とその契約者間のディジタル・データ交換が改善化
されるので、このジレンマを解消できる。ロジスティックス技術分野における初期の CALS
作業では、CALS ディジタル・データ交換規格の立案に重点が置かれた。現在は、STEP
（Standard for the Exchange of Product＝製品交換規格）モデル・データのようなデー
タベース統合化規格や製品定義規格へと重点が移ってきた。
- 184 -
NASA は CALS で経費節減を図れるか？
国防総省（DoD）の CALS 計画は 1985 年に着手された。1988 年以降は、国防総省の新型シス
テムに対しても CALS 計画が求められてきた。Clark によると、CALS による国防総省全体の
経費節減は 1 億 6,000 万ドル（財政年度当たり 9,200 万ドル）を超えている。しかし、主
計局（GAO＝Government Accounting Office）では、国防総省の CALS 採用を批判してきた。
その批判の的は、CALS ではユーザー間の情報交換能力に限界があるという点にあった。
NASA フィールドセンターが CALS で経費節減を図るには、新たにハードウェア、ソフトウ
ェア、トレーニングにかなりの投資が必要になろう。NASA の大手契約者の多くはすでに CALS
技術を導入している。だが、CALS を採用しようとするシステムエンジニアとしては、中小
企業の供給業者と対話するには CALS 方式と CALS 以外の方式の両方が必要になる場合もあ
り、たとえディジタル化されていても、契約者の特許権付きデータを防護する必要がある
という点を十分認識しなければならない。
CALS 技術は、文書（または労働）集約的環境から高度に自動化かつ統合化した環境への
移行を可能にする。それに付随して、設計と開発に必要な時間と経費の削減化、ILS 製品と
意思決定の質的向上という利点も期待されている。CALS により経費節減を図れるのは、主
としてコンカレントエンジニアリング（concurrent engineering）、コンフィギュレーショ
ン管理（コントロール）、ILS 業務の 3 領域である。コンカレントエンジニアリング環境で
は、NASA の多分野製品開発チーム（PDT＝Product Development Team）（システム契約者の
PDT をまねたり、その PDT と協力することもある）が CALS 技術を採用し、PDT 間のデータ
交換とデータ・アクセスをスピードアップすることができる。部品や供給業者に関するデ
ータを CALS を通して入手できれば、部品の選択と調達をも改善できる。（コンカレントエ
ンジニアリングの詳細については、第 3.7.2 項を参照）。
コンフィギュレーション管理でも CALS 技術を活用できる。ECR／ECP（Engineering Change
Request/Engineering Change Proposal＝技術変更要求書／技術変更提案書）の提出、処理、
追跡に CALS を利用すれば、認否手続きの遅れを短縮できる上、その遅れに伴う間接費をも
削減できる。コンカレントエンジニアリングでも、設計・開発段階（フェーズ C と D）にお
ける ECR／ECP 件数を削減化できる見込みはあるが、それらの文書を適時に処理できれば大
幅な経費節減は図れる。（コンフィギュレーション管理の詳細については、第 4.7.2 項を参
照）。
最後に、CALS 技術を採用すれば、供給支援などの各種 ILS（Integrated Logistics Support
＝総合ロジスティックス支援）業務を同時に実施でき、しかも手作業が少なくなる。たと
えば、設計の安定した構成部品や予備品の調達を早期に着手できる（また、早期に試験を
実施できる）。同時に、その他の構成部品の供給を（設計が安定化するまで）延期でき、コ
ストのかかる間違いを犯すリスクも低減化する。売り手の対応が迅速化すれば、運用段階
における予備品の在庫量を削減できる。
- 185 -
6.6
検証
検証とは、納入可能な地上用・飛行用ハードウェアとソフトウェアが機能上、性能上、
設計上の要求事項に適合しているかどうかを確認する過程である。この検証過程は、計画
の立案、要求事項の定義、適合性確認などの作業からなり、初期段階から着手され、プロ
ジェクト・ライフサイクル全体を通して続けられる。このような作業は、システムエンジ
ニアリング・プロセスに欠かせない重要な一部となる。「検証プロセスの各段階におけるシ
ステムエンジニアの仕事は、検証結果を理解かつ評価し、何らかの異常事項を解消するこ
とである」。本項では、検証計画構想の立案から運用・廃棄の検証に至る NASA の検証プロ
セス全体について概説する。プログラム／プロジェクトにおいてどんな検証プロセスが選
定されても、SEMP(Systems Engineering Management Plan＝システムエンジニアリング・
マネジメント計画書)に記載すべきである。
検証計画の目的は、機能上、性能上、設計上のすべての要求事項（プログラム／プロジ
ェクトにおけるレベル I からレベル n までの全要求事項）が満たされているかどうかを確
認することである。各プロジェクトでは、そのコスト、スケジュール、リスク面を考慮し
て検証計画を策定する。全てのプロジェクトに通用する検証計画などは一つもない。した
がって、各検証作業とその結果が特定のプロジェクトに適しているかどうかを評価する必
要がある。検証プロセス全体には通例システム設計団体と試験団体がある程度介入するの
で、検証計画には検証技術者がかなりの調整を加えるが必要がある。
システムエンジニアリング・プロセス
初期検討
フェーズA／B−予備解析と定義
"Design-to"
ベースライン
要求書とVRMを
更新する
検証作業
要求書とVRMを
更新する
検証計画の立案
最終アイテムの要求書
と仕様書を理解する
主要審査
最終アイテムの要求書
と仕様書を理解する
検証／試験マスター
プランを作成する
VRM =要求マトリックス
VRSD =検証要求・仕様書
SRR=ステム要求審査
PDR=本設計審査
VRSD＝証要求・仕様書
CDR＝細設計審査
フェーズC−設計
VRSDを作成する
検証計画の
立案
VRSDを更新する
適合書を作成する
SPR
設計／開発検証を実施する
検証／試験マスター
プランを更新する
適合書を更新する
PDR
図32a 検証プロセスフローチャート（フェーズA／B とC）
- 186 -
CDR
システムエンジニアリング・プロセス
"Build-to"
ベースライン
フェーズD−開発
試験記録、データ、解析結果を文書化し、試験記録を書き、保管する
要求書とVRM
を更新する
検証作業
最終アイテムの要求書
と仕様書を理解する
認定検証を実施する
検証計画の
立案
FRR＝飛行準備審査
SAR＝システム受納審査
ORR＝運用準備審査
VRSD＝検証要求・仕様書
VRM＝検証要求マトリックス
TRR＝試験準備審査
構成要素
検証／試験マス
タープランを更
新する
サブシステム
必要に応じ
たTRR
受納検証を実施する
システム
構成要素
サブシステム
システム
開発に備えて検証を実
施する
運用検証を
実施する
試験後審
サブシステム／システム検証／試験要領書を作成する
VRSD を更新
する
構成要素検証／試験要領書を作成する
必要な支援用デ
ータと解析結果
適合書を更新
する
適合書を更新
する
主要審査
必要な支援用デ
ータと解析結果
適合書を更新
する
適合書を更新
する
SAR
FRR
ORR
図32b 検証プロセスフローチャート（フェーズD）
6.6.1
検証プロセスの概観
検証作業は、プロジェクトのフェーズ A から開始される。フェーズ A では、検証計画の
構想が形づくられるに従い、プロジェクトの総合的マスタースケジュールおよびコスト予
測に新データを導入する。フェーズ B では、このような計画立案作業が増え、要求事項、
コスト、スケジュールを改良する。さらに、システムの各種要求事項を評価し、予備検証
方法を選定するほか、要求事項が検証「できる」ものかどうかを確認する。フェーズ B の
作業結果はフェーズ C においてさらに進展し、より詳細な計画書と要領書が作成される。
フェーズ D では、検証作業がかなり増える。こうした検証作業は、通常、認定検証と受納
検証、配備準備のための検証、運用検証からなる。図 32a と図 32b には、NASA のプロジェ
クト・ライフサイクル全体にわたるこのような検証プロセスを示す。（これらの図では、検
証作業で実施される安全性審査を個別作業として示していない）。
検証計画の構想
検証計画は、プロジェクトに合わせて調整すべきである。プロジェクトマネジャやシス
テムエンジニアは、検証技術者と協力して検証計画の構想を立案しなければならない。こ
の構想の立案とその後の検証計画の策定では、多くの要素を検討する必要がある。それら
の要素としては次のものがある。
・
特に飛行プロジェクトの場合は、プロジェクトの種類。検証方法と検証時期は、関
連打上げ品目(article)の種類（たとえば実験用品目、ペイロード、ロケットなど）
によって異なってくる。
・
NASA のペイロード分類法。特定の打上げ品目に必要となる検証作業と検証文書は、
通常、NASA のペイロード分類法によって異なってくる。クラス A のペイロードに関
する検証計画は、クラス D のペイロードに比べかなり包括的なものとなる。（分類法
- 187 -
の指針については、添付資料 B.3 を参照）。
・
プロジェクトのコスト面とスケジュール面。検証作業は、プロジェクトのコストと
スケジュールを左右する重要要因となる場合がある。検証計画の策定では、こうし
た面を早期に検討すべきである。検証方法と検証要求事項に関する決定や施設の種
類と設置場所の選定を行う前に、トレード研究を実施すべきである。たとえば、中
央集中施設で試験を実施するか、いくつかの分散施設で試験を実施するかという選
定を行う際には、トレード研究を実施すべきである。
・ リスク面。検証計画の策定では、リスク・マネジメントを考慮に入れる必要がある。
定性的リスク評価と定量的リスク解析（たとえば FMECA(Failure Modes, Effects,
and Criticality Analysis ＝故障モード影響及び致命度解析）など)では、追加試
験により軽減化できる新しい問題点を特定することが多く、それだけ検証作業の範
囲も拡大する。採用すべき最適検証方法とその実施時期を選定するトレード研究で
は、その他のリスク評価も役立つ。たとえば、モデル試験を実施すべきか、低コス
トだが検出能力の低い解析法でモデル特性を算定すべきかという選択を行う場合は、
トレードを実施することもできるであろう。プロジェクトマネジャやシステムエン
ジニアは、プロジェクトのコスト面とスケジュール面から許容し得るリスクを識別
しなければならない。
・
（必要な場合に）何らかの品目(article）を一方の場所から他方の場所へ移動させ
る輸送手段と検証施設／検証場所のアベイラビリティ。この場合は、ILS（Integrated
Logistics Support＝総合ロジスティックス支援）技術者との調整が必要になる。
・ 調達戦略（つまり局内開発契約や局内システム契約）。NASA フィールドセンターでは、
しばしばプロジェクトの作業報告書（SoW＝Statement of Work)を通して契約者の検
証プロセスを構成することができる。
・
設計の継承度とハードウェア／ソフトウェアの再利用度。
検証方法と検証技法
システムエンジニアとしては、要求事項との適合性を検証するために検証技術者がどん
な方法や技法を採用するかを知る必要がある。端的に言えば、これらの方法や技法は次の
ものである。
・
試験
・
解析
・
実証実験
・
類似法
・
検査
・
シミュレーション
・
記録の妥当性確認
- 188 -
「試験」による検証とは、定常条件下や特定環境下において設備を実際に運転して性能
評価を行うことである。この試験は、機能試験と環境試験の 2 種に分類できる。「機能試験」
とは、設計仕様と同等の条件またはそれ以下の条件の下で飛行用または飛行用に構成した
ハードウェアやソフトウェアに対して実施する個別試験または一連の電気的・機械的性能
試験である。その目的は、システムが設計仕様と性能仕様通りに十分機能するかどうかを
確認することにある。機能試験は通常、定常条件下で実施される。性能試験は、次の試験
や運用の前にシステムの性能を検証するために、各環境試験や各長距離移動の前後に実施
する。「環境試験」とは、飛行環境内で十分機能するかどうかを確認するために、飛行中ま
たは飛行中に構成したハードウェアやソフトウェアに対して実施する個別試験もしくは一
連の試験である。環境試験としては、振動試験、音響試験、熱真空試験などがある。試験
目的によっては、環境試験と機能試験を組み合わせることもある。
「解析」による検証は、仕様書や要求書に適合しているかどうかを検証するために、試
験の代わりに（または試験のほかに）実施する検証である。その解析技法としては、シス
テムエンジニアリング解析、統計と定量解析、コンピュータとハードウェアによるシミュ
レーション、コンピュータ・モデルなどを選定できる。解析を行えるのは、（1）厳密かつ
精確な解析を実施できる、（2）試験を実施できないか、コスト効果がない、（3）類似法を
採用できない、（4）検査による検証だけでは不十分、と判定した場合である。
「実証実験」による検証は、保全性、人間工学特性などの要求事項と実証実験技法を併
用することである。「類似法」による検証は、以前の受領データやハードウェア・コンフィ
ギュレーションとその用途を審査し、その品目(article)の設計と製造方法が、同等か、も
っと厳しい仕様書に従って認定された他の品目と類似しているか同一であるかを評価する
過程である。「検査による」検証は、設計特性を検証するために実施する設備や文書の物理
的評価である。検査を実施するのは、構造特性、ワークマンシップ、物理的寸法、物理的
状態（清浄度、表面仕上げ、施錠(locking)ハードウェアなど）を検証するためである。「シ
ミュレーション」による検証は、飛行用アイテム以外のハードウェアやソフトウェアを使
用して設計特性と性能を検証する過程である。「記録の妥当性確認」による検証は、最終ア
イテム受納時の製造記録を使用して、飛行用ハードウェアの構造特性と製造法を検証する
過程である。
各種検証段階
検証段階とは、各種検証目標が達成される検証作業期間と定義されている。このハンド
ブックでは、飛行システムの検証段階として以下の段階を採用している。
・
開発
・
認定試験
・
受領
・
配備準備（打上げ前ともいう）
- 189 -
・
運用（軌道上または飛行中運用ともいう）
・
廃棄（必要な場合のみ）
解析とモデル
性能・設計要求事項を満たしているかどうかを検証かつ判定する場合には、モデルを使っ
た解析がプログラム／プロジェクト全体を通して広く採用されている。試験では検証でき
ないほとんどの検証要求事項は、解析とモデルにより検証される。解析およびモデル作成
過程は、プロジェクト・ライフサイクルの初期段階から開始され、フェーズ D の大半を通
して継続される。入力データとして実データを使用できるようになるに伴い、これらの解
析とモデルは定期的に更新される。多くの場合、解析とモデルは試験結果により妥当性確
認または確証される。検証関係の試験結果は、プロジェクトの保管記録として文書化すべ
きである。
「開発段階」とは、新しいプロジェクトやシステムを考案し、認定試験用や飛行用ハー
ドウェアの製造にまで実用化する期間である。この段階の検証作業（たとえばブレッドボ
ード試験など）では、開発システムがミッションの目標や目的を達成できるものかどうか
を確認する。この段階で実施する試験は、通常、設計組織が行うか、設計組織と試験組織
が共同で実施する。また、この段階で基本設計審査（PDR＝Preliminary Design Review)と
詳細設計審査（CDR＝Critical Design Review）を実施すれば、プログラム／プロジェクト
要求事項を検証することも、部分的に検証することもできる。プログラム／プロジェクト
要求事項を正式に満たすために実施する開発作業は、品質保証のための監視を受ける必要
がある。
「認定試験」段階とは、飛行用（プロトフライト用）またはフライトタイプのハードウ
ェアが機能上、性能上、設計上の要求事項を満たしているかどうかを検証する期間である。
この段階の検証は、受領条件よりも厳しい条件の下で、飛行用に構成されたハードウェア
に対して実施し、そのハードウェアが飛行環境において十分な余裕を持って機能するかど
うかを確認する。「受領段階」とは、納入可能な飛行用最終アイテムがミッション条件下に
おいて機能上、性能上、設計上の要求事項を満たすかどうかを示す期間である。受領段階
は、射場へ飛行用ハードウェアを出荷すると同時に終了する。
「配備準備」段階は、飛行用ハードウェアやソフトウェアが射場に到着すると同時に始
まり、打上げと同時に終了する。この段階で検証される要求事項は、ロケットや射場など
の総合施設に対するものである。「運用検証段階」は発射と同時に開始される。この段階で
は、飛行システムが宇宙環境条件下でうまく機能するかどうかを検証すると共に、宇宙環
境に対する要求事項を検証する。「廃棄段階」は、廃棄要求事項を検証する期間である。
- 190 -
6.6.2
検証計画の立案
検証計画の立案は、プロジェクトのあらゆるフェーズにおいて実施する「長い対話」の
過程であるが、特にフェーズ C において集中的に実施される。検証技術者は、プログラム
／プロジェクトとミッションの各種要求事項に基づいて検証要求事項と検証作業の予備定
義を行う。その要求事項の検証を簡略化するには、プロジェクトのミッションおよびシス
テム定義段階で、要求事項を明確な用語で表記すべく努力する必要がある。システムとイ
ンタフェースの要求事項が設定され改良されるに伴い、検証技術者はそれらを評価して適
切な検証方法やその組み合わせを選定する。次に、これらの要求事項と検証方法を適当な
要求書に記載する。
検証技術者は、検証対象のレベル（たとえば部品、サブシステム、システムなど）や維
持すべき環境制御装置（たとえばコンタミネーションなど）と共に、「各検証段階」に実施
する検証方法を使用して、システムの開発、認定試験、受領に関係のある検証作業の基本
スケジュールを設定する。この基本スケジュールはプロジェクトのマイルストーンとも一
致するものとし、検証作業の改善化に応じて更新すべきである。
検証計画の立案中、検証技術者は検証計画に必要な各種文書も特定する。このような文
書 と し て は 、 通 常 次 の も の が あ る ：（ 1 ） 検 証 要 求 マ ト リ ッ ク ス （ VRM ＝ Verification
Requirements Matrix）、（2）検証マスタープラン（MVP＝Master Verification Plan）、（3）
検証要求仕様書（VRSD＝Verification Requirements and Specifications Document)、（4）
検証要求適合書（VRCD＝Verification Requirements Compliance Document)。試験要領書
と試験報告書も指定できる。システムエンジニアとしては、検証プロセスに関するこれら
の基本文書に精通していなければならないので、以下でこうした各文書について説明する。
検証要求マトリックス
検証要求マトリックス（VRM＝Verification Requirements Matrix）は、要求書（一般的
には、システム要求書やコンフィギュレーションアイテム（CI）仕様書）の一部を構成し、
機能上、性能上、設計上の各要求事項の検証方法、検証を行う段階、（時には）適用可能な
検証レベルを明記したものである。検証技術者は、設計組織、システムエンジニアリング
組織、試験組織との調整を図りながら VRM を作成する。VRM の内容は、各プロジェクトの要
求書に合わせて調整され、VRM によってその詳細度が異なることもある。基本設計審査（PDR
＝Preliminary Design Review)の結果、VRM はベースライン化され、特に検証計画の基本路
線を確定する。添付資料 B.9 には、CI 仕様書にある VRM の一例を示す。
検証マスタープラン
検証マスタープラン（MVP＝Master Verification Plan）は、検証計画の全容を記載した
文書である。MVP の内容と詳細度は、あらゆる検証作業を十分示せるものである。各主要作
- 191 -
業は詳細に定義かつ説明される。このマスタープランでは、飛行用ハードウェアとソフト
ウェアの認定、受領、打上げ前、運用、廃棄検証作業をすべて網羅する。（通常、開発段階
の検証作業はこのマスタープランに記載せず、別の文書に記載する）。このマスタープラン
には、主要検証作業の一般的スケジュールと作業順序を示す。また、試験用ソフトウェア、
地上支援設備（GSE＝Ground Support Equipment）、さらに検証作業に必要な施設について
も概説する。検証技術者は、検証計画構想のほか、プログラム（レベル I）要求条件書（PRD
＝Program Requirements Document)、システム／セグメント（レベル II）要求書（SRD＝
System/Segment Requirements Document ）、 コ ン フ ィ ギ ュ レ ー シ ョ ン ア イ テ ム （ CI ＝
Configuration Items)仕様書に記載された各種要求事項、その文書上の VRM（Verification
Requirements Matrix＝検証要求マトリックス）により特定された検証方法などを十分理解
した上で、検証マスタープランを作成する。その場合も、検証技術者は設計団体、システ
ムエンジニアリング団体、試験団体と緊密に協力する必要がある。添付資料 B.10 には、検
証マスタープランの概要例を示す。
検証報告書
検証報告書は、解析ごとに作成すべきであり、少なくとも、機能試験、環境試験、エン
ド・ツー・エンド（end-to-end）適合性試験のような各主要試験作業ごとに作成すべきで
ある。試験が長期間にわたる場合や他の作業により中断させられる場合は、機能試験、音
響試験、振動試験、熱真空／サーマルバランス試験のような各試験作業ごとに検証報告書
を作成する必要も出てくる。検証報告書は試験後数週間以内に作成すべきで、各試験結果
が対応する検証要求事項に適合した証拠を示す必要がある。検証報告書には、次の事項の
適当なものを記載すべきである。
・
各種検証目的とその達成度
・
検証作業の説明
・
試験用コンフィギュレーションおよび飛行用コンフィギュレーションとの相違点
・
各試験の特定結果ならびに試験の注釈も含めた各試験手順
・
各解析の特定結果
・
試験結果のデータ表、グラフ、説明図、写真
・
公称結果との偏差、問題／故障、承認済み異常補正対策、再試験作業の説明
・
廃棄対策も含めた不適合事項／不具合報告書の概要
・
検証作業の成否に関する結論と推奨事項
・
試験で破損した支援設備の状態
・
試験手順書の写し
・
試験結果の有効性確認と合格認定。
- 192 -
検証要求仕様書
検証要求仕様書（VRSD＝Verification Requirements and Specifications Document)は、
打上げ品目(article)と地上用システム／セグメントの検証に必要な要求事項と仕様を詳
細に明記したものである。VRSD には、認定試験から運用検証に至るあらゆる作業に必要な
要求事項と仕様を明記する。打上げ品目にソフトウェアが導入されている場合は、飛行用
ソフトウェアの検証に必要な要求事項も明記する。VRSD は、「あらゆる」方法による検証を
対象とする。しかし、プログラム／プロジェクトによっては、試験で検証すべき要求事項
のみを明記した文書を使用する場合もある。
VRSD には、レベル I、II、III 要求書に明記されたすべての要求事項ならびにそれらか
ら派生した要求事項を記載すべきである。VRSD には、また、各要求事項に関する合格基準
と各種制約も明記される。VRSD では、通例、各種要求事項の検証場所も特定する。大型プ
ログラム／プロジェクトに関する VRSD は、各検証作業／検証場所（たとえば熱真空試験な
ど）ごとに作成し、その検証作業に対する要求事項のみを記入するように作成し直す。検
証技術者はそのような要求事項、検証計画の構想、打上げ品目を十分理解した上で VRSD を
作成する。VRSD は検証作業の開始前にベースライン化される。VRSD の中心部は、以下のフ
ィールド（項目）からなるデータ表である。
・
各要求事項を示す数値記号
・
検証すべき特定要求事項の記述
・
各要求事項の「合格／不合格」規準と許容範囲
・
順守すべき制約
・
要求事項に対する理解を助けるための備考
・
要求事項の検証場所
打上げ品目の図面や図表と共に、VRSD は検証要領書を作成するための基本文書となるほ
か、検証要求適合書（VRCD＝Verification Requirements Compliance Document）を作成す
るための基本文書の一つとなる。
検証要求適合書
検証要求適合書（VRCD＝Verification Requirements Compliance Document）は、レベル
I からレベル n までの設計、性能、安全性、インタフェースの要求事項ならびに検証要求仕
様書（VRSD＝Verification Requirements and Specifications Document)の各要求事項に
対する適合証拠を示すものである。VRSD の要求事項までフローダウンすると、すべての要
求事項のトレーサビリティが完全なものになる。すべての要求事項に適合すれば、レベル I
の要求事項が満たされたことになる。
VRCD には、要求事項ごとに、検証方法（1 種または数種）と、採用した検証方法ごとの
適合情報を明記する。適合情報は、要求事項に対する適合性を示す実データもしくはその
実データの記載場所を示す参照番号を提示するものである。（この文書では、また関連不具
- 193 -
合報告書（NCR＝Non-Compliance Report）や問題／故障報告書（P／FR＝Problem/Failure
Report）を引用して不具合を示す。異常事項を解消後は、この文書に再検証情報を明記す
る）。適合情報としては、検証報告書、自動試験計画書、検証要領書、解析報告書、試験報
告書を引用することもできる。適合情報を検証適合書に記入する作業は長期間にわたる。
大型システムや大型ペイロードの場合は、その作業を連続的に実施することもある。検証
適合書に記載される情報は、システム受領審査（SAR＝System Acceptance Review）と飛行
準備審査（Flight Readiness Review)に備えた最新のものでなければならない。プロジェ
クト・ライフサイクル全体を通して適合情報を適時記入する必要があるので、検証適合書
はベースラン化されない。しかし、この文書は、プロジェクト保管記録の極めて重要な一
部となる。
検証要求適合書（VRCD）の中心部も、各種要求事項に関連のあるデータ表である。VRCD
のデータ表は次の項目（フィールド）からなる。
・
各要求事項を示す数値記号
・
各要求事項が明記されている文書を示す数値記号
・
満たすべき特定要求事項の記述
・
要求事項の検証に使用した検証方法
・
記述された要求事項に対する適合性を示すデータの記載場所。この情報は、適合性
データが記載されている場所を正しく示すものであれば、試験報告書、試験要領書、
解析報告書、その他の情報のいずれでもよい。再試験情報も示す
・
検証作業中に検出された不具合
・
特定方法以外の方法による、不具合または合格に関する適合性情報の記述。たとえ
ばウェーバーなど
検証要領書
検証要領書（Verification Procedure）は、特定の検証作業を実施する際の指示事項を
順次記載した文書である。検証要領書は、要求事項を満たすために実施する検証作業に合
わせたものであり、その検証作業は試験、認定試験、その他の検証関係作業のいずれでも
よい。検証要領書は、VRSD(Verification Requirements and Specifications Document＝
検証要求仕様書）に明記された要求事項を満たすために書かれたもので、試験準備審査（TRR
＝Test Readiness Review)の前か、この検証要領書を使用する検証作業の開始前に提出す
る。（枠内補足記事「試験準備審査」を参照）。
各種施設、地上支援用電気設備と機械設備、特殊試験設備の受納検証を行う場合も、こ
の検証要領書を使用する。検証要領書の記載事項は、通常以下に列記したものだが、検証
作業や試験品目(article)に応じて変更できる。
・
試験品目や試験材料の名称と識別記号
・
試験用コンフィギュレーションの識別記号ならびに飛行用コンフィギュレーション
- 194 -
との相違点
・
適用検証仕様書により設定された試験目的と判定基準の特定
・
検査または試験される特性と設計の合格／不合格基準および基準値と許容範囲
・
実施すべき手順と作業の順列説明
・
必要なコンピュータ・ソフトウェアの識別記号
・
使用すべき測定設備、試験設備、記録設備の識別記号およびその有効範囲、精度、
種類
・
必要なコンピュータ試験プログラム／支援設備とソフトウェアが飛行用ハードウェ
アに使用する前に検証済みであるという証明
・
採用されるデータ記録設備やその他自動試験設備の運転に関する特別指示事項
・
試験設備、試験品目、測定点の識別記号、設置位置、相互接続を示す配置設計図、
図表、線図
・
危険状況や危険作業の識別
・
要員の安全確保ならびに試験品目と測定設備の劣化防止のための予防対策と安全指
示事項
・
維持すべき環境条件やその他の条件とその許容範囲
・
検査上または試験上の制約
・
不具合と異常事態またはその結果に関する特別指示事項
・ 全検証作業前後と全検証作業中の施設と設備の保全、ハウスキーピング、確認検査、
安全性・取扱い要求事項に関する仕様
検証要領書には、検証結果や所見を記載する空白スペースを設け、検証報告書の一部と
することもできる。実施通りの検証要領書の写しは、プロジェクトの保管記録の一部とし
て保管される。
試験準備審査
試験準備審査（TRR＝Test Readiness Review)は、すべての地上用、飛行用および運用シス
テムが試験を支援する準備態勢にあるかどうかを確認するために、各主要試験の前に実施
される。この審査では、試験施設、地上支援設備（GSE＝Ground Support Equipment）、試
験設計、ソフトウェア、試験要領書、検証要求事項の詳細状態を審査する。試験作業と試
験スケジュールの概要を決め、要員の責務も特定する。検証では、試験のために特定した
すべての検証要求事項が試験設計と試験要領書に記載されているかどうかを確認する点を
重視する。
- 195 -
6.6.3
認定試験検証
認定試験段階の検証作業は、飛行用ハードウェアの設計開発完了後に開始し、飛行用ま
たはフライトタイプのハードウェア（およびソフトウェア）が予測環境条件下における機
能・性能要求事項を満たすかどうかを確認するための解析と試験からなる。通常、認定試
験では、最悪ケースの荷重と環境応力をハードウェアにかける。最悪ケースの荷重と環境
に対するハードウェアの耐性を確認するために実施する検証項目としては、振動／音響特
性 、 圧 力 限 界 、 漏 れ 率 、 熱 真 空 、 熱 サ イ ク ル 、 電 磁 干 渉 と 電 磁 適 合 性 （ EMI ／ EMC ＝
electromagnetic interference/electromagnetic compatibility）、高電圧限界と低電圧限
界、寿命／ライフサイクルなどがある。認定試験段階では、多くの性能要求事項を検証す
るほか、試験データを取得するたびに解析とモデルを更新する。ハザード解析報告書に明
記された安全要求事項も、認定試験を通して満たすことができる。
認定試験は、通常、構成要素レベルやサブシステム・レベルで実施されるが、システム・
レベルで実施することもできる。プロジェクトにおいて、認定試験用ハードウェアを建造
せず、飛行用ハードウェア自体を認定試験に使用する場合、その試験を「プロトフライト」
試験という。プロトフライト試験の詳細については、MSFC−HDBK（Marshall Space Flight
Center - Handbook ＝ マ ー シ ャ ル 宇 宙 飛 行 セ ン タ ー ・ ハ ン ド ブ ッ ク ） -670" General
Environmental Testing Guidelines(GETG) for Protoflight Instruments and Experiments"
（「プロトフライト計測器および実験のための一般環境試験指針書」）を参照されたい。
6.6.4
受領検証
受領段階の検証作業では、飛行用ハードウェアとソフトウェアが機能上、性能上、設計
上の要求事項をすべて満たし、射場への搬出準備が整っているかどうかを確認する。受領
段階は、打上げ品目に組み立てる各構成要素や各部品の受領と同時に始まり、システム受
領審査（SAR＝System Acceptance Review）まで続く。
打上げ品目、特に大型品目を組立、統合化した後に、（たとえば接近できないなどの理由
により）検証が行えない場合もある。この場合は、組立・統合化「中に」検証を実施する。
その検証を「インプロセス試験」(in-process test)という。その場合の受領試験は、イン
プロセス試験と同時に開始され、機能試験、環境試験、エンド・ツー・エンド(end-to-end)
適合性試験まで続く。機能試験は、通常、構成要素レベルから開始され、システム・レベ
ルを経て、すべてのシステムの同時運用をもって終了する。すべての試験は、検証要求仕
様書（VRSD＝Verification Requirements and Specifications Document)に明記された各
種要求事項に従って実施する。飛行用ハードウェアを入手できない場合やその使用が特定
の試験に適さない場合は、シミュレータを使用してインタフェースを検証する。試験中に
異常が発生した場合は、適当な報告システム（NCR(Non-Compliance Report＝不具合報告書）
- 196 -
や P／FR（Problem/Failure Report＝問題／故障報告書）)に記載し、何らかの解決策を決
定してから試験を続行すべきである。大規模な異常や処理しにくい異常を解消する場合は、
システムエンジニアの協力を得るほか、設計組織、試験組織などの協力も必要である。必
要な場合は、解析とモデルの検証も行い、試験データが得られるたびに更新する。
6.6.5
配備準備の検証
打上げ前（配備準備）検証段階は、打上げ品目(article)が射場に到着すると同時に開始
し、打上げと同時に終了する。この段階では、打上げ品目を加工処理し、打上げロケット
に組み込む。打上げロケットが「シャトル」やその他の打上げロケットである場合もあれ
ば、打上げ品目が打上げロケットの一部である場合もある。この段階に対する検証要求事
項は、検証要求仕様書（VRSD＝Verification Requirements and Specifications Document)
に明記されている。射場が「ケネディ宇宙センター」（Kennedy Space Center) の場合は、
VRSD の代わりに運用保全要求仕様書（OMRSD＝Operations and Maintenance Requirements
and Specifications Document)を使用する。
この段階で実施する検証では、出荷中のシステムに目に見える損傷が生じていないか、
システムが正しく機能し続けているかどうかを確認する。システムのエレメントを個別に
出荷し、射場で組み込む場合は、通常、システムとシステム・インタフェースの試験を実
施する必要がある。システムがキャリアに組み込まれている場合は、キャリアとのインタ
フェースも検証する必要がある。その他の検証としては、打上げロケットに組み込んだ後
に実施するものや射座で実施するものがある。こうした検証では、システムがうまく機能
し、適正な打上げコンフィギュレーション状態にあるかどうかを確認する。打上げ前とカ
ウントダウン中に何らかの緊急事態発生が予測される場合は、緊急事態検証書とその手順
書を作成する。何らかの緊急事態により、打上げロケットや打上げ品目を射座から加工処
理施設へ回収する必要がある場合には、この緊急事態検証書とその手順書が不可欠となる。
- 197 -
ソフトウェアの IV＆V
プロジェクトマネジャやシステムエンジニアのなかには、ソフトウェア検証計画に IV＆
V(Independent Verification and Validation＝独立検証および妥当性確認）手続きを加え
たいと思う者もいるであろう。IV＆V とは、ソフトウェアの開発者でも調達者でもない組織
が、ソフトウェア開発ライフサイクル中に得られた製品の審査、検証、妥当性確認を独自
に実施する過程である。IV＆V 代行者(agent)は、ソフトウェアの成否に何の利害関係も持
たない。その代行者が関与するのは、ソフトウェアがその要求事項に照らして徹底的に試
験されたものかどうかを確認することだけである。
IV＆V 作業は、ライフサイクル中に順次実施されるプロジェクトの検証・妥当性確認（V
＆V）作業と重複するが、IV＆V 代行者は非公認の試験を実施しないという点が異なる。IV
＆V 手続きを採用した場合は、IV＆V 代行者が正式受領試験を 1 回だけ実施すればよい。こ
の場合、開発者は、そのソフトウェアの受領試験準備が整っているかどうかを正式に実証
する。
6.6.6
運用と廃棄の検証
運用検証では、無重力の（無重力に近い）真空環境においてシステムが適正に機能する
かどうかを確認する。この検証は、検証作業というよりはシステムの起動と運用を通して
実施される。軌道上で組み立てたシステムは、各インタフェースを検証し、エンド・ツウ・
エンド試験時に適正に機能しなければならない。液体流と気体流を供給する機械的インタ
フェースの検証では、漏れが生じないか、圧力と流量が仕様範囲内にあるかどうかを確認
する。環境システムも検証する。すべての運用検証作業に対する要求事項は、検証要求仕
様書（VRSD＝Verification Requirements and Specifications Document)に指定されてい
る。
廃棄検証では、あらゆるシステム製品(product)とその工程が安全に運用を停止し、廃棄
されたかどうかを確認する。廃棄段階は、フェーズ E の適当な時期に（たとえば予定時期
か、早期に故障や事故が発生した場合は早期に）開始し、すべてのミッション・データを
収集し終り、廃棄要求事項を満たしているかどうかを確認するための検証が終了した時点
で完了する。運用と廃棄の検証作業では、検証評価を実施することもある
システムが所期のミッション目標／目的をどの程度達成したかを評価する。
- 198 -
−
つまり、
6.7
製造性
製造性とは、完成した設計を実際のハードウェアやソフトウェアに容易かつ経済的に変
換する（つまり組立てる、製造またはコード化する）ことができるというシステム特性で
ある。NASA の主要システムは少量生産の傾向があるが、「シャトル」の耐熱タイルに関する
経験から見ても、システムのコスト効果にとっては特定の製造性が極めて重要になる場合
もある。
6.7.1
生産技術者の役割
生産技術者は、特定設計特性を実用化して生産性向上を図るという積極的な役割を通し
て、またプロジェクトに必要な生産工学的解析を実施することにより、［多分野製品開発チ
ーム（PDT＝Product Development Team）の一員として］システムエンジニアリング・プロ
セスを支援する。このような業務と解析としては、次のものがある。
・
システムのリスク・マネジメントプログラム（第 4.6 項を参照）の一環として製造
／組立を行う。そのために、厳密な生産リスク評価を実施し、効果的なリスク軽減
化対策を立案する
・
生産性を向上させるシステム設計特性を明確化する。通常は、設計の単純化、製造
許容範囲、危険材料の回避などが作業の中心となる
・
最もコスト効果の高い組立／製造方式を選定するために、製造性のトレード研究を
実施する
・
プロジェクトの制約の中で生産の可能性を評価する。この評価としては、契約者と
主要下請業者の経験と能力、新しい製造技術、特殊工具類、生産要員トレーニング
要求事項などに対する評価がある
・
リードタイムの長いアイテムや重要材料を識別する
・
ライフサイクルコスト・マネジメントの一環として生産コストの見積りを行う
・
生産スケジュールを設定する
・
組立／製造工程の妥当性確認方法と計画を立案する
このような業務と生産工学解析の結果は、プロジェクトの生産段階に適した詳細度で製
造計画書（Manufacturing Plan）に記載される。また、生産技術者は、上記項目に関する
主要プロジェクト審査（主として基本設計審査（PDR＝Preliminary Design Review)と詳細
設計審査（CDR＝Critical Design Review））ならびに生産準備審査（ProRR＝Production
Readiness Review）などの特殊中間審査にも参加し、それらを支援する。
- 199 -
6.7.2
製造性のツールと技法
製造の機能流れブロック図（FFBD）
製造の機能流れブロック図（FFBD＝Functional Flow Block Diagram)は、添付資料 B.7.1
で説明するシステム FFBD と同じように使用する。トップレベルの製造 FFBD は、システム
の製造手順を補足かつ明確化するものである。
リスクマネジメント・テンプレート
国防総省の DoD 4245.7M "Transition from Development to Production....Solving the
Risk Equation"(「開発から生産への移行....リスク方程式の解き方」）のリスク・マネジ
メント・テンプレートは、広く認められている一連のリスク、リスク対応策、国防総省の
経験から得られた教訓である。このテンプレートは、生産上のリスク削減化を図るもので
あるが、NASA の各プロジェクトに合わせて変更できる。
製造性評価ワークシート
このワークシートも、国防総省のために開発されたもので、各種生産方法から最適方法
を 選 択 す る 一 助 と し て 、 判 断 力 に 基 づ く 評 価 方 法 を 採 用 し て い る 。 "Producibility
Measurement for DoD Contracts"(「国防総省の契約のための生産性測定」)を参照された
い。
製造性モデル
各種製造計画案の可能性評価、ライフサイクルコスト・マネジメントの一環としての生
産コスト見積りなど、多種多様の問題を処理する場合は、製造性モデルを使用する。特定
の製造性モデルとしては、次のものがある。
・
生産量を予測し、システム改良や予備品生産を製造工程に導入するためのスケジュ
ール・モデル
・
たとえば各種工場作業の個別事象シミュレーションのような製造または組立流れ作
業シミュレーション
・ 学習率と生産率の感度を導入した生産コスト・モデル。（枠内補足記事第 5.2.3 項「学
習曲線理論」と「費用延べ払い関数例」を参照）
統計的工程管理／実験計画法
この技法は、製品の望ましくない品質変化の原因を究明し、その影響を低減するために
製造部門で長年採用されていたものだが、TQM（Total Quality Management＝総合的品質マ
ネジメント）の下で再び復活してきた。この新しい「品質工学」(Quality Engineering)で
現在通用している各種技法をまとめて、「タグチメソッド」(Taguchi methods)という。タ
- 200 -
グチメソッドについては、田口著 "Quality Engineering in Production Systems"（「生産
システムにおける品質工学」）（1989 年）を直接参照されたい。この技法に関するハンドブ
ックとしては、米国海軍の "Producibility Measurement Guidelines: Methodologies for
Product Integrity"（「製作性測定指針書：製品保全方法」）がある。
6.8
社会の容認
NASA システムは、その資金を出す社会に受け入れられるものでなければならない。シス
テムエンジニアはこの点を考慮し、システムエンジニアリング・プロセスに社会の関心事
を導入する。システムによっては、この社会的関心事が設計とコストに非常に不利な条件
を課すこともある。社会的関心事を受け入れることができても、そのための計画立案と解
析に時間がかかり（プロジェクトのクリティカルパスに影響を及ぼすという程度でも）、専
門工学の資源をかなり使用することもある。システムエンジニアとしては、各種アーキテ
クチャ／設計案の高レベル・トレード研究にこのようなコストも含めなければならない。
6.8.1
環境への影響
NASA の政策と連邦法では、環境に影響を及ぼす恐れのある NASA のあらゆる活動を国内環
境政策法（NEPA＝National Environmental Policy Act)にある諸政策と手続きに従って実
施すると規定している。NASA のプロジェクトやその他の活動に関しても、NEPA では、プロ
ジェクトをなぜ計画し、どう計画するのかという点、環境への潜在的影響の種類と範囲な
どを説明するために研究と解析を実施することを規定している。NASA 本部、その現場セン
ター、契約者側施設のどこでプロジェクトが実施されるにせよ、このような研究を実施し
なければならない。しかも、プロジェクト計画段階（つまりフェーズ A）の最も早い時期に
着手する必要がある。環境アセスメント（EA＝Environmental Assessment）という形で得
られた研究結果や、もし認められれば、環境影響報告書（EIS＝Environmental Impact
Statement）の徹底的分析を通して得られた研究結果を一般国民に提示し、その審査と意見
を受けなければならない。（枠内補足記事「NEPA とは？」を参照）。
まず最初に、NASA のプロジェクトには、国内環境政策法（NEPA）により環境影響報告書
（EIS）が明らかに必要となるような規模と種類のものもあれば、EIS を必要としないもの
もある。しかし、NASA のほとんどの大型プロジェクトは、その中間に該当する。つまり、
EIS が必要かどうかが「事前に」はっきりとわからない。その場合は、EIS が本当に必要か
どうかを判定するために環境アセスメントを行う。「1970 年以降に得た NASA の経験では、
大量または危険な量の汚染物質（ロケットの排気ガス、新型物質、放射性物質）が放出さ
れる（または放出される恐れのある）プロジェクトには EIS が必要であった」。この種のプ
ロジェクトでは、環境アセスメント（EA）を実施しない。したがって、プロジェクトの解
- 201 -
析では、環境影響報告書（EIS）の作成を重視し、それを支援すべきである。
NEPA とは？
1969 年の国内環境政策法（NEPA＝National Environmental Policy Act)では、国内環境政
策とその目標を宣言し、その目標の達成方法を提示している。NEPA では、「人間の環境に多
大な影響を及ぼす大規模な連邦活動」に対して環境影響報告書（EIS＝Environmental Impact
Statement）の提出を義務づけている。
環境への影響に関する適用文書としては、以下のものがある。
・
1969 年の国内環境政策法（NEPA＝National Environmental Policy Act)とその修正
法（40 CFR 1500-1508）。CFR＝Code of Federal Regulations(連邦規制コード）。
・
国内環境政策法（NEPA）実施手続き（Procedures for Implementing the National
Environmental Policy Act)（14 CFR 1216.3)。
・
国内環境政策法の規定事項実施(Implementing the Requirements of the National
Environmental Policy Act)、NHB (NASA Handbook＝NASA ハンドブック）8800.11 。
・ 1970 年 3 月 5 日付け大統領令第 11514 号「環境保護と環境改善化」（Protection and
Enhancement of Environmental Quality)およびその修正令である 1977 年 5 月 24
日付け大統領令第 11991 号。
・
1979 年 1 月 4 日付け大統領令第 12114 号「大規模連邦活動による国外環境への影
響」（Environmental Effects Abroad of Major Federal Actions)。
国内環境政策法（NEPA）に規定された手続きでは、国内環境政策とその目標に沿ううよ
うにプロジェクトを計画かつ実施することになっている。このような手続きは、まず第一
に、フェーズ A において潜在的環境問題に重点を置いたプロジェクトを立案するシステム
エンジニアを支援する。第二に、プロジェクトの基本的実施理由と実施方法を一般国民に
報告する手段となる。最後に、NASA としても、計画事業に対する国民の審査と意見を受け
ることができ、それらの意見を検討し、回答を与える必要が生じる。システムエンジニア
としては、以下に述べる NEPA に基づく各種手続きに精通すべきである。
環境アセスメント（EA）
環境アセスメント（EA＝Environmental Assessment）書は、環境影響報告書（EIS）を作
成すべきか、明確な影響なしに関する所見書（FONSI＝Finding of No Significant Impact）
を作成すべきかを判定できる十分な根拠と解析結果を提示するための簡潔な公文書である。
その解析では、プロジェクトの目標／目的を達成するためのあらゆる方法の妥当案が環境
へ与える影響を、比較できるように特定すべきである。活動を行わない（つまり、プロジ
ェクトを実施しない）という案についても研究すべきである。NASA としては、環境への影
- 202 -
響が最も小さい案を必ずしも選定する必要はないが、その影響がどの程度のものかを明確
化し、NASA の選択を裏づける根拠を示す十分な情報を入手しなければならない。環境解析
は、プロジェクトのシステムエンジニアリング・プロセスに欠かせない重要な部分である。
環境アセスメント（EA）は、プロジェクト案や活動案に対する責任者である NASA 本部の
プログラム担当副局長（PAA＝Program Associate Administrator)の責務である。EA は NASA
本部か NASA 現場センターで実施できる。EA に対する承認は、責任者のプログラム担当副局
長（PAA）が与える。ほとんどの場合、EA の承認書は、管理システム・施設（Management Systems
and Facilities)（コード J）担当副局長（AA＝Associate Administrator)に対する覚書と
いう形を取る。この覚書には、プロジェクトに環境影響報告書（EIS）が必要かどうかを記
載する。EIS が必要とみなされた場合は、EIS 作成の趣意書（NOI＝Notice of Intent）を
作成する。EIS が不要とみなされた場合は、有意の影響なしに関する所見書（FONSI＝Finding
of No Significant Impact）を作成する。
有意の影響なしに関する所見書（FONSI）
有意の影響なしに関する所見書（FONSI＝Finding of No Significant Impact）では、環
境アセスメント書（EA）に述べたプロジェクト案または活動案が人間の環境に有意の影響
を及ぼさないものであるため、EIS を作成する必要がないと判断された理由を簡潔に提示す
べきである。国家的規模のプロジェクトや活動に関する FONSI は、連邦公報（Federal
Register）に掲載され、30 日間一般国民の審査に付される。この期間に要請があれば、い
かなる情報も速やかに提供される。
趣意書（NOI）
環境影響報告書（EIS）作成の趣意書（NOI＝Notice of Intent）には、プロジェクト案
や活動案の簡単な説明、実施可能な各種代替案、環境アセスメントにより明らかになった
主な環境問題、NASA が採用予定のスコーピング（範囲決定）方式ならびにスコーピング会
議の開催場所と日時などを記載すべきである。趣意書（NOI）は、責任者である NASA 本部
のプログラム担当副局長（PAA）が作成し、連邦公報に掲載される。趣意書は、関係者にも
送付される。
スコーピング（Scoping)
責任者である NASA 本部のプログラム担当副局長（PAA）は、環境影響報告書（EIS）で扱
うべき諸問題の範囲を決定すると共に、重大な環境問題を特定するために、早期に公開手
続きを実施しなければならない。環境問題のスコーピング（範囲決定）も、プロジェクト
案や作業案の責任者である NASA 本部のプログラム担当副局長（PAA）の責務である。しか
し、プログラム担当副局長（PAA）はコード J の副局長（AA）と緊密に協力する場合が多い。
スコーピングでは、まず最初にあらゆる環境パラメータを検討し、EIS で扱うべき重要なパ
- 203 -
ラメータを特定する。スコーピング過程で検討すべき環境の種類と問題点は、NHB(NASA
Handbook ＝ NASA ハ ン ド ブ ッ ク ） 8800.11 "Implementing the Provisions of National
Environmental Policy Act"（「国内環境政策法の規定事項実施」）第 307.d 項に記載されて
いる。
環境影響報告書（EIS）
国内環境政策法（NEPA）の手続きの中で環境アセスメント（EA）とスコーピング（Scoping)
では、環境影響報告書（EIS）で扱うべき重大な環境問題とその影響に関する評価結果を、
プロジェクト案や作業案の責任者である NASA 本部のプログラム担当副局長（PAA）に提示
する。EIS の作成自体は、NASA だけで実施することも、他の政府機関や契約者の支援や協
力を得て実施することもできる。EIS 作成に参加する契約者は、NASA 本部の指定した意思
表明書（disclosure statement）を作成し、プロジェクトの結果に何の利害関係もないこ
とを示すべきである。
解析に関する EIS の中心部は環境への影響に関する項で、各種代替案の比較評価のため
の基盤となる。各代替案のための解析結果は、意思決定者に提示する選択案を目立たせる
ように表示すべきである。そのような表示に特に適する表示形式としては、環境への影響
の種類（たとえば大気汚染、水質汚染、絶滅寸前の生物種など）に対して各種代替案を示
すマトリックス形式がある。そのマトリックスには、各代替案とその影響の種類ごとに環
境影響値（予測値）を記入する。その後に記載する各種代替案の検討事項は、EIS の極めて
重要な部分であり、それ相応の配慮を払うべきである。
NASA による環境影響報告書（EIS）案の審査は、コード J 担当副局長（AA）が管理する。
NASA 審査のために提出された EIS 案には、連邦、州、地方の担当職員とその他関係者のリ
スト案も添付すべきである。
EIS 案の外部審査も、コード J 担当副局長が管理する。EIS 案の公表と入手方法を知らせ
る公告を連邦公報に掲載すると共に、その写しを意見募集書と共に配布する。EIS 案を受理
したら、環境庁（EPA＝Environmental Protection Agency)も連邦公報に公告を出す。その
公告期日は、EIS 案の公表期間の開始日とする。意見受理期間は、少なくとも 45 日間とす
る。コード J 担当副局長（AA）が受理した外部審査員の意見は、EIS 作成当局へ送付される。
各意見は最終 EIS に盛り込むべきである。
必要に応じて上述の審査過程で修正を加えた最終 EIS の草案は、コード J 担当副局長（AA）
へ送付し、最終審査に付した後に印刷して配布すべきである。最終 EIS には、信頼できる
意見すべてに対するしかるべき回答を記載すべきである。NASA としてはあらゆる反対意見
に従う必要はないが、NASA の意見は合理的かつ論理的で、しかも反対意見よりも強力な論
拠とデータに基づいたものでなければならない。
NHB(NASA Handbook＝NASA ハンドブック）8800.11 "Implementing the Provisions of
National Environmental Policy Act"（「国内環境政策法の規定事項実施」）（第 309.d 項）
- 204 -
によると、「EIS 作成過程の重要部分は、一般国民の参加である。この過程の初期段階から
参加すれば、活動案に関する苦情や目的を満たすための長い道のりをたどることもあるが、
十分な情報を得て参加した人々の方が活動案に賛成する率がかなり高いことは、経験上明
らかである。活動案が世論の関心を喚起する見込みがかなりあると思われる場合は、初期
の立案段階で参考として一般国民の意見も導入すべきである。EIS が認められるのであれば、
スコーピングと EIS 審査の両過程にも一般国民を参加させるべきである。初期段階から参
加させれば、最適案が選定され、世論の反対を弱める一助ともなり得る。」
決定記録（ROD）
EIS 作成過程が完了し、一般国民の審査期間が終了すると、NASA は自由にプロジェクト
案や活動案に関する決定を下し、その決定を実施することができる。その時点で、そのプ
ロジェクトや活動の責任者である NASA 本部のプログラム担当副局長（PAA）は、決定記録
（ROD＝Record of Decision）を作成する。この決定記録（ROD）は、決定を下す際に環境
要因を考慮したことを示す正式の公的記録となる。ROD は連邦公報に掲載されないが、関連
するプログラム／プロジェクト関係の公文書として保管し、要請があれば開示しなければ
ならない。
6.8.2
原子力安全打上げ認可
大統領指令／国家安全保障会議覚書-25（PD／NSC-25＝Presidential Directive/National
Security Council Memorandum-25）では、「放射線源を使用する必要のある飛行プロジェク
トは、打上げ認可を求める際に長期間の解析と審査を受ける」と規定している。原子力安
全打上げ認可手続きは、国内環境政策法（NEPA＝National Environmental Policy Act)に
基づく手続きとはまったく別のものである。データ収集面で両者間に重複個所があるかも
しれないが、NEPA と原子力安全打上げ認可にそれぞれ必要となる文書は連邦と NASA のまっ
たく別の要求事項を満たさなければならない。NEPA による認可手続きはプロジェクトの初
期段階に実施されるが、打上げ認可手続きはフェーズ C／D から正式に開始される。
フェーズ A／B の作業は、環境アセスメント／環境影響報告書（EA／EIS）の要求事項に
左右される。責任者である NASA 本部のプログラム担当副局長（PAA）は、原子力システム
統合化技術者や打上げロケット統合化技術者と調整を図りながら、できるだけ早期に、プ
ロジェクトの EA／EIS と安全解析／打上げ認可計画書（Safety Analysis/Launch Approval
Plan）の作成に着手しなければならない。この場合の EA／EIS の主目的は、放射線源を選
択する基本的根拠を包括的に評価することである。さらに、EA／EIS は、ミッションの各種
設計案、飛行システム案、打上げロケット案による環境への影響と、それら各案に関連の
ある原子力安全問題に光を当てる。
打上げ認可担当技術者は、フェーズ A において以下の特定要求事項が満たされているか
- 205 -
どうかを確認する。
・
信頼できるすべての代替案の定義、宇宙機設計影響評価、コスト・トレードなどか
らなる放射線源設計のトレード研究を実施する
・
放射線源特有の飛行システム要求事項を特定する
・
各種原子力案に関しては、米国エネルギー省（DOE＝Department of Energy）が既成
原子力システム設計の適性を評価できるように、飛行システム電力の要求事項と代
替案を特定し、その運用環境と事故環境を定義する
フェーズ B における作業は、プロジェクトの EA／EIS 計画の特定事項によって異なって
くる。責任者である NASA 本部のプログラム担当副局長（PAA）は、EA／EIS の準備と作成を
NASA 現場センター、NASA 本部、契約者のいずれで実施するのか、他のフィールドセンター、
打上げ施設、エネルギー省、その他の政府機関や団体によるどんな援助が必要かといった
選定を行う。打上げ認可担当技術者は、フェーズ B において以下の特定要求事項が満たさ
れているかどうかを確認する。
・
プロジェクト、飛行システム、打上げロケット、放射線源の説明書を更新かつ改良
する
・
フェーズ A で実施した放射線源設計のトレード研究を更新かつ改良する
・ ミッションの原子力リスクと環境ハザードの予備評価を実施するエネルギー省（DOE）
を支援する
打上げ認可担当技術者は、ミッションの原子力安全問題に関係のある各種作業、インタ
フェース、記録業務を調整する責務も負う。以下の業務は、打上げ認可担当技術者が管理
する。
・
プロジェクトの EA／EIS と安全解析／打上げ認可計画書の立案
・ EA／EIS および原子力安全打上げ認可業務に関係のある各種文書のデータベース保管。
このデータベースは、ミッション開発・計画過程において技術的決定と技術的選択
がどう行われたか、またなぜ行われたかという点を記録した証跡記録の作成と保管
に使用できる。初期段階においてそのような技術的作業に着目すれば、その後の打
上げ認可過程において時間と経費を節約できる。この種のプロジェクトでは、計画
過程において特定の方法や代替案に重点を置いた理由の説明を、打上げ認可過程で
求められる場合もある
・ EA／EIS と安全解析に必要となるミッション・データの生成とトレード研究において
必要に応じて実施する文書作成と審査の支援
・ EA／EIS 過程と原子力安全打上げ認可過程を支援するために必要となる、打上げロケ
ット統合化技術者、エネルギー省（DOE）、NASA 本部との接点をプロジェクトに設け
る業務。この業務としては、放射線源の安全問題に関する一般国民と議会の疑問に
答える業務や、何らかの訴訟が起こった場合に必要となる訴訟手続きを支援する業
務などがある
- 206 -
・
放射線源安全解析向けの事故環境や指令破壊環境の発生に必要となる技術的解析支
援の提供。通常の技術的解析技法は確率的リスク評価（PRA＝Probabilistic Risk
Assessment)である。第 4.6.3 項を参照されたい
表7
カテゴ
リー
惑星保護カテゴリー
適用対象
要求事項の概要
1
月、太陽、水星
2
上記惑星または火星以外に対
するすべてのミッション
宇宙機と打上げロケットによる太陽系天体との衝突事故回避。打上げ
ずみハードウェアの最終処分に関する文書作成。着陸機と探査機用有
機材料の目録作成。
3
火星向けフライバイとオービ
ター
衝突確率に対する厳しい制限。オービターの軌道上寿命に関する要求
事項または宇宙機の微生物学的清浄度に関する要求事項。
4
火星着陸機
火星に衝突させる予定のない宇宙機エレメントによるハード衝突確
率に対する厳しい制限。バイオアッセイ（生物検定）により直接確認
した着陸機ハードウェア表面の微生物学的清浄度。
5
月と水星以外の惑星からのサ
ンプル回収ミッション
ターゲット惑星着陸ミッションのカテゴリー別アウトバウンド
（outbound）要求事項。そのミッションのインバウンド・レッグ
（inbound leg)要求事項はまだ最終的に決まっていないが、地球帰還
前にターゲット惑星に接触したハードウェアの殺菌と、回収サンプル
の密封を含める見通しである。
6.8.3
カテゴリーの確認のみ。
惑星保護
米国は、国連の「月及びその他天体を含めた宇宙の探査と利用における諸国の活動に関
す る 原 則 条 約 」 (Treaty of Principles Governing the Activities of States in the
Exploration and Use of Outer Space, Including the Moon and Other Celestial Bodies)
の締約国である。「宇宙」条約とも略称されるこの条約の一部（第 9 条）には、月やその他
天体の探査は、「地球外の物質を持ち込むことによる地球環境の有害な汚染と変化を回避
するように」実施しなければならないと規定されている。NASA の政策書（NMI（NASA
Management Instructions＝NASA 管理手引書） 8020.7D）には、「太陽系の条件を維持する
目的は、将来生物構成成分と有機成分を探査するためである」と明記されている。また、
地球とその生物圏を惑星やその他の地球外汚染源から防護するための NASA の基本政策も設
定している。
NASA の飛行プロジェクトが順守すべき一般的規制は、NHB(NASA Handbook＝NASA ハンド
ブック）8020.12B "Planetary Protection for Robotic Extraterrestrial Missions"（「ロ
ボットによる地球外ミッションにおける惑星保護」）に明記されている。ターゲットにする
太陽系の天体に応じて、また宇宙機やミッションのタイプ（フライバイ、軌道機、着陸機、
サンプル回収など）に応じて、それぞれ異なるミッションにはそれぞれ異なる要求事項が
適用される。一部の天体（太陽、月、水星）には、アウトバウンド（outbound）汚染要求
事項は適用されない。しかし、火星探査ミッションのアウトバウンド段階に対する現行要
- 207 -
求事項は、特に厳しいものである。惑星保護計画の立案は、ミッションの実行性が確認さ
れるフェーズ A から開始される。フェーズ A が終了する前に、プロジェクトマネジャは、
宇 宙 科 学 担 当 副 局 長 （ AA of Space Science) 室 の 惑 星 保 護 担 当 官 （ PPO ＝ Planetary
Protection Officer）に、ミッションのタイプとターゲット惑星を記載した書簡を送り、
そのミッションの惑星保護カテゴリーを指定するよう要請する。表 7 には、現在採用して
いる惑星保護カテゴリーとその関連要求事項の概要を示す。
フェーズ B の終了時に実施する基本設計審査（PDR＝Preliminary Design Review)の前に、
プロジェクトマネジャは、それらの要求事項を満たすための諸対策を詳細に記載した惑星
保護計画書（Planetary Protection Plan)を NASA の惑星保護担当官（PPO）に提出しなけ
ればならない。プロジェクトの進捗状態とそのような要求事項の達成状態を報告する惑星
保護打上げ前報告書（Planetary Protection Pre-Launch Report）は、NASA の惑星保護担
当官（PPO）に提出され、その承認を受ける。飛行準備審査（FRR＝Flight Readiness Review)
においてこの報告書が承認されると、プロジェクトが最終的に承認されることになるので、
打上げ許可を得るためにはこの報告書の承認を得なければならない。実際の打上げやミッ
ションの初期事象によるミッション計画のずれを報告するために、この報告書を更新した
惑星保護打上げ後報告書（Planetary Protection Post-Launch Report)も作成される。サ
ンプル回収ミッションに限り、地球帰還向け打上げ前、地球再突入前、地球外サンプルを
研究のため科学界に配布する前に、追加報告と追加審査が必要になる。最終的には、正式
なミッション終了宣言時に、惑星保護ミッション終了報告書（Planetary Protection
End-of-Mission Report）が作成される。この報告書は、元の惑星保護計画書（Planetary
Protection Plan)と対比してミッションの全経緯を審査し、NASA の惑星保護要求事項に対
する適合度を文書化したものである。この文書の内容は、通例、宇宙空間研究委員会（COSPAR
＝Committee on Space Research)の会議において NASA の惑星保護担当官（PPO）により報
告され、国際惑星保護規定に対する NASA の順守度が他の宇宙進出諸国に伝えられる。
- 208 -
添付資料 A
略語
略語を使用するのは、団体名、文書名、作業名、理念などを一般に理解されている範囲
内で手短かに引用するためである。しかし、略語を乱用すると、コミュニケーションを妨
げることもある。NASA「略語集」は、NASA のシステムエンジニアリングで使用されるあら
ゆる略語の包括的リストを提供しようと努力した成果である。添付資料 A では、このハン
ドブックに使用された略語と NASA の主要機関の略語という 2 つのリストを記載する。
AA（Associate Administrator (NASA))
APA（Allowance for Program Adjustment）
ACWP（Actual Cost of Work Performed)
AGC（Aerospace Ground Equipment）
AHP（Analytic Hierarchy Process）
BCWP（Budgeted Cost of Work Performed)
BCWS（Budgeted Cost of Work Scheduled)
C／SCSC（Cost/Schedule Control System Criteria)
CALS（Continuous Acquisition and Life-Cycle Support)
CCB（Configuration (or Change) Control Board)
CDR（Critical Design Review）
CER（Cost Estimating Relationship）
CI（Configuration Item）
CIL（Critical Items List)
CoF（Construction of Facilities）
COSPAR（Committee on Space Research)
COTR（Contracting Office Technical Representative)
CPM（Critical Path Method）
CR（Change Request）
CSCI（Computer Software Configuration Item）
CSM（Center for Systems Management)
CWBS（Contract Work Breakdown Structure)
DCR（Design Certification Review)
DDT＆E（Design, Development, Test, Evaluation)
DoD（(U.S.) Department of Defense)
DOE（(U.S.) Department of Energy)
DR（Decommissioning Review）
DSMC（Defense Systems Management College）
EA（Environmental Assessment）
- 209 -
EAC（Estimate at Completion）
ECP（Engineering Change Proposal)
ECR（Engineering Change Request）
EIS（Environmental Impact Statement）
EMC（Electromagnetic compatibility)
EMI（Electromagnetic Interference)
EOM（End of Mission）
EPA（(U.S.) Environmental Protection Agency）
EVA（Extravehicular Activities)
EVM（Earned Value Measurement）
FCA（Functional Configuration Audit）
FFBD（Functional Flow Block Diagram)
FH（Flight Hardware)
FMEA（Failure Modes and Effects Analysis）
FMECA（Failure Modes, Effects, and Criticality Analysis）
FONSI（Finding of No Significant Impact）
FRR（Flight Readiness Review)
GAO（General Accounting Office）
GOES（Geo-synchronous Orbiting Environmental Satellite)
GSE（Ground Support Equipment）
HQ（NASA Headquarters)
HST（Hubble Space Telescope）
I＆V（Integration and Verification）
ILS（Integrated Logistics Support）
ILSP（Integrated Logistics Support Plan)
ILSS（Integrated Logistics Support System)
IOP（Institutional Operating Plan）
IRAS（Infrared Astronomical Satellite)
IV＆V（Independent Verification and Validation)
IVA（Intravehicular Activities)
LEM（Lunar Excursion Module (Apollo))
LEO（Low Earth Orbit)
LMEPO（Lunar/Mars Exploration Program Office)
LMI（Logistics Management Institute）
LOOS（Launch and Orbital Operations Support）
LRU（Line Replaceable Unit)
- 210 -
LSA（Logistics Support Analysis）
LSAR（Logistics Support Analysis Record)
MDT（Mean Downtime)
MCR（Mission Concept Review）
MDR（Mission Definition Review)
MESSOC（Model for Estimating Space Station Operations Cost）
MICM（Multi-variable Instrument Cost Model）
MLDT（Mean Logistics Delay Time)
MMT（Mean Maintenance Time)
MNS（Mission Needs Statement)
MoE（Measure of (system) Effectiveness)
MRB（Material Review Board)
MRR（Mission Requirements Review)
MTBF（Mean Time Between Failures）
MTTF（Mean Time To Failure）
MTTMA（Mean Time to a Maintenance Action)
MTTR（Mean Time To Repair/Restore)
NAR（Non-Advocate Review)
NCR（Non-Compliance (or Non-Conformance) Report）
NEPA（National Environmental Policy Act)
NHB（NASA Handbook)
NMI（NASA Management Instruction)
NOAA（(U.S.) National Oceanic and Atmospheric Administration）
NOI（Notice of Intent）
OMB（Office of Management and Budget)
OMRSD（Operations and Maintenance Requirements and Specifications Document (KSC))
ORLA（Optimum Repair Level Analysis)
ORR（Operational Readiness Review）
ORU（Orbital Replacement Unit）
P／FR（Problem/Failure Report）
PAA（Problem Associate Administrator (NASA)）
PAR（Program/Project Approval Review)
PBS（Product Breakdown Structure)
PCA（Physical Configuration Audit）
PDR（Preliminary Design Review)
PDT（Product Development Team）
- 211 -
PDV（Present Discounted Value）
PERT（Program Evaluation and Review Technique)
POP（Program Operating Plan）
PPAR（Preliminary Program/Project Approval Review)
PPO（Planetary Protection Officer）
PRA（Probabilistic Risk Assessment)
PRD（Program Requirements Document)
ProRR（Production Readiness Review）
QA（Quality Assurance)
QFD（Quality Function Deployment)
RAM（Reliability, Availability, and Maintainability)
RAS（Requirements Allocation Sheet)
RID（Review Item Discrepancy)
RMP（Risk Management Plan）
ROD（Record of Decision）
RTG（Radioisotope Thermoelectric Generator)
SAR（Systems Acceptance Review)
SDR（System Definition Review）
SEB（Source Evaluation Board)
SEMP（Systems Engineering Management Plan)
SEPIT（Systems Engineering Process Improvement Task）
SEWG（Systems Engineering Working Group (NASA)）
SI（Le Système International d'Unités (the international [metric] system of units)）
SIRTF（Space Infrared Telescope Facility)
SOFIA（Stratospheric Observatory for Infrared Astronomy）
SoSR（Software Specification Review)
SoW（Statement of Work)
SSR（System Safety Review）
SRD（System/Segment Requirements Document）
SRM＆QA（Safety, Reliability, Maintainability, and Quality Assurance)
SRR（System Requirements Review）
STEP（Standard for the Exchange of Product (model data))
STS（Space Transportation System)
SSA（Space Station Alpha)
SSF（Space Station Freedom)
TBD（To Be Determined; To Be Done）
- 212 -
TDRS（Tracking and Data Relay Satellite)
TLA（Time Line Analysis）
TLS（Time Line Sheet)
TPM（Technical Performance Measure(ment))
TQM（Total Quality Management）
TRR（Test Readiness Review)
V＆V（Verification and Validation)
VMP（Verification Master Plan）
VRCD（Verification Requirements Compliance Document)
VRM（Verification Requirements Matrix）
VRSD（Verification Requirements and Specifications Document)
WBS（Work Breakdown Structure）
WFD（Work Flow Diagram)
NASA の諸機関
ARC（Ames Research Center）
COSMIC（Computer Software Management & Information Center)
DFRF（Dryden Flight Research Facility)
GISS（Goddard Institute for Space Studies (GSFC)）
GSFC（Goddard Space Flight Center)
HQ（National Aeronautics and Space Administration Headquarters）
JPL（Jet Propulsion Laboratory)
JSC（Lyndon B. Johnson Space Center）
KSC（John F. Kennedy Space Center）
LaRC（Langley Research Center)
LeRC（Lewis Research Center)
MAF（Michoud Assembly Fcility）
MSFC（George C. Marshall Space Flight Center）
SCC（Slidell Computer Complex）
SSC（John C. Stennis Space Center）
STIF（Scientific & Technical Information Facility)
WFF（Wallops Flight Facility (GSFC)）
WSTF（White Sands Test Facility (JSC))
- 213 -
添付資料 B
システムエンジニアリングのテンプレートと例
添付資料 B.1
SEMP の概要例
Defense Systems Management College が推奨するシステムエンジニアリング・マネジメ
ント計画書（SEMP＝Systems Engineering Management Plan)の概要例を下に示す。この概
要例は単なる見本にすぎないので、プロジェクトの種類とその固有リスクに応じて手直し
するべきである。
システムエンジニアリング・マネジメント計画書
タイトルページ
序説
第1部
技術計画の立案と管理
1.0
責任と権限
1.1
標準、手順、トレーニング
1.2
プログラムリスク分析
1.3
作業明細構成
1.4
計画審査
1.5
技術審査
1.6
技術性能測定
1.7
変更管理手順
1.8
エンジニアリング計画の統合化
1.9
インタフェース制御
1.10
マイルストーン／スケジュール
1.11
その他の計画と管理
第2部
システムエンジニアリング・プロセス
2.0
ミッションと要求解析
2.1
機能解析
2.2
要求事項の配分
2.3
トレード研究
2.4
設計最適化／有効性の適合性
2.5
統合
2.6
インタフェースの技術的適合性
2.7
ロジスティックス支援解析
2.8
製造性解析
2.9
仕様樹形図／仕様書
- 214 -
2.10
文書作成
2.11
システムエンジニアリングのツール
第3部
専門工学／統合化要求事項
3.1
統合化設計／計画
3.1.1
信頼性
3.1.2
保守性
3.1.3
人間工学
3.1.4
安全性
3.1.5
標準化
3.1.6
生存性／無防備性
3.1.7
電磁適合性／電磁干渉
3.1.8
電磁パルス硬化
3.1.9
総合ロジスティックス支援
3.1.10
コンピュータリソース・ライフサイクルマネジメント計画書
3.1.11
製造性
3.1.12
その他の専門工学要求事項／計画
3.2
統合化システム試験計画
3.3
支援作業との適合性
3.3.1
システムのコスト効果
3.3.2
価値工学
3.3.3
TQM／品質保証
3.3.4
材料と工程
- 215 -
添付資料 B.2
搭載用望遠鏡の「テーラリング済み」WBS
図 B-1 には、2.5-3.0 m の望遠鏡を搭載した 747SP 型航空機として開発予定の赤外線天
文学成層圏観測施設（SOFIA＝Stratospheric Observatory for Infrared Astronomy）に関
する製品明細構成図（PBS＝Product Breakdown Structure)の一部を示す。この PBS は、観
測施設搭載の望遠鏡エレメント向けに作成されたものである。PBS の各レベル名は、本ハン
ドブックの 3 頁（原文）にある枠内補足記事「階層的システム用語」に合わせたものであ
る。
図 B-2 から図 B-5 には、本ハンドブックの第 4.3 項の原則に基づいて作成した、上記
PBS に対応する作業明細構成図（WBS＝Work Breakdown Structure）を示す。各レベルの WBS
要素は、PBS から引用した主要引渡し可能製品である。WBS の各レベルは、マネジメント、
システムエンジニアリング、統合化と試験などの必要業務（つまり機能）要素を加えて完
成される。各レベルの統合化と試験という WBS 要素は、そのレベルにおいて主要引渡し可
能製品を統合化する作業を示す。
この添付資料では SOFIA プロジェクトを例証として採用したにすぎないが、フェーズ C
／D の開始時には、プロジェクトマネジャの判断に従い、実際の条件に合わせて SOFIA の
WBS に変更を加えるべきである。WBS に大幅な変更を加えるような条件としては、たとえば
プロジェクトに対する諸外国の参加がある。
SOFIA
地上支援システム
観測システム
科学計測器
搭載設備
航空機
エレメント
エンクロージャー
／研究所／事務所
地上支援設備
（GSE）
望遠鏡
エレメント
望遠鏡
サブシステム
コンソール／電子
制御サブシステム
図 B-1 赤外線天文学成層圏観測施設（SOFIA）の製品明細構成（WBS）
- 216 -
ミッション計画
シミュレータ
SOFIA プロジェクト
観測
システム
地上支援
システム
システムエン
プロジェクト・マ ジニアリング
ネージメント
（プロジェク
ト・レベル）
プロジェク
トのI＆V
運用・ロジス
ティックス
計画立案
科学支援
プログラ
ム保証
I＆V＝Integration and Verification＝統合化と検証
図 B-2 SOFIA プロジェクトのWBS（レベル3）
観測システム
科学
搭載機器
搭載設備
システム・
マネジメント
システムエン
ジニアリング
（システム・
レベル）
システム
のI＆V
図 B-3 SOFIA 観測システムのWBS（レベル4）
- 217 -
システム
開発支援
設備
耐空性
保証
搭載設備
航空機
エレメント
望遠鏡
エレメント
システムエンジ
ニアリング
（セグメント・
レベル）
セグメント・
マネジメント
セグメントの
I＆V
セグメント
開発支援設備
図 B-4 SOFIA 搭載設備のWBS（レベル5）
望遠鏡エレメント
望遠鏡
サブシステム
コンソール／
電子制御
サブシステム
エレメント・マ
ネジメント
システムエンジ
ニアリング
（エレメント・
レベル）
エレメントの
I＆V
図 B-5 SOFIA 望遠鏡エレメントのWBS（レベル6）
- 218 -
エレメント
開発支援設備
添付資料 B.3
クラス A−D ペイロードの特性表示、ミッション成功度、SRM＆QA コスト指針書
添付資料 B.3 は、NMI(NASA Management Instruction＝NASA 管理手引書） 8010.1A
"Classification of NASA Payloads"（「NASA ペイロードの分類法」）の付属書 A を転載し
たものである。
クラス A
クラス B
クラス C
クラス D
特性表示
高優先順位、最低
リスク
高優先順位、中位
リスク
中位優先順位、中
／高リスク
高リスク、最低コ
スト
ペイロード分類に
使用する代表的要
素
高い国家的威信。
長期のハードウェ
ア所要寿命。高い
複雑性。最高コス
ト。長い計画期間。
重要な打上げ制
約。再利用／再飛
行も、問題解消の
ための飛行中保全
も実施不能。
高い国家的威信。
中期のハードウェ
ア所要寿命。高−
中位の複雑性。高
コスト。中期の計
画期間。若干の打
上げ制約。再利用
／再飛行も、問題
解消のための飛行
中保全も困難か実
施不能。
中位の国家的威
信。短期のハード
ウェア所要寿命。
中−低位の複雑
性。中位のコスト。
短期の計画期間。
打上げ制約がほと
んどない。再利用
／再飛行も、問題
解消のための飛行
中保全も実施可能
の場合もある。
低い国家的威信。
短期のハードウェ
ア所要寿命。低位
の複雑性。低コス
ト。短期の計画期
間。打上げ時間／
軌道上の重要制約
なし。再飛行可能
または経済的交換
可能。飛行中保全
が実施可能の場合
もある。
ミッション成功規
準の達成
リスク低減化のた
めに余裕のある計
画やその他の対策
を講じる。最高の
実効的製品保証基
準を採用する。
ミッション全体の
成功に対する低リ
スクと部分的成功
に対する中位リス
クを維持しなが
ら、多少のコスト
削減化を達成する
ために、妥協策を
講じる。
大幅なコスト節減
を可能にするため
に、ミッションの
成功に対する中位
リスクを受け入れ
る。
できるだけ低コス
ト化するために、
ミッションの成功
に対する高リスク
を受け入れる。最
低製品保証要求事
項を受け入れる。
SRM＆QA コスト項
目の推定相対値
[1]
1.0
0.7 x クラス A
0.4 x クラス A
0.1 x クラス A
注 [1]： 「SRM＆QA（Safety, Reliability, Maintainability, and Quality Assurance＝安全性、
信頼性、保全性、品質保証）コスト」の明細記入方法と計算方法は多種多様である。クラス A プログ
ラムの場合、これらのコストは通例、プログラム総コストの 10−15％範囲内である。この表に明記
した SRM＆QA コスト項目の相対値を採用したのは、各種プログラム分類における SRM＆QA プログラム
（およびその関連コスト）間の実質的格差を求め、意味のあるコスト／リスク・レベル階層を形成す
るためである。
- 219 -
添付資料 B.4
1.0
2.0
3.0
4.0
リスク・マネジメント計画書の概要例
概説
1.1
リスク・マネジメント計画書（RMP）の目的と適用範囲
1.2
適用文書と定義
1.3
プログラム／プロジェクト（またはシステム）の説明
リスク・マネジメント方法
2.1
リスク・マネジメントの基本方針／概観
2.2
管理組織と責任体制
2.3
スケジュール、マイルストーン、審査
2.4
関連プログラム計画書
2.5
下請業者のリスク・マネジメント
2.6
プログラム／プロジェクトのリスク評価指標
リスク・マネジメントの各種方法、プロセス、ツール
3.1
リスクの識別と特性表示
3.2
リスク解析
3.3
リスクの軽減化と追跡
主要リスクの特定*
4.1
技術的リスク
4.2
プログラムリスク
4.3
支援性リスク
4.4
コスト・リスク
4.5
スケジュール・リスク
* 各項には、各リスクの説明、特性、解析結果、軽減化対策、報告用測定基準を記載する。
- 220 -
添付資料 B.5
クリティカルアイテムリスト例
シャトルクリティカルアイテムリスト
サブシステム
−
オービター
：着陸時減速
FMEA NO 02-1-001-1
版：82/02/09
．アセンブリ
：主着陸ギア
中断：
重要機能：
．受入検査部品番号
：MC621-0011
．売り手部品番号
：1170100 MENASCO
機体
．数量
：2
有効性：
．
：左側
フェーズ
．
：右側
．
PL
1
重要ハードウェア：
LO
00
冗長性スクリーン：
DO
x
A-N/A
102
099
x
x
103
x
1
104
x
LS
B-N/A
C-N/A
．
．作成者：
承認者：
承認者（NASA）：
．DES
L L RHODES
DES
SSM
．REL
A L DOBNER
REL
REL
．
．
．アイテム：MLG ストラット
．
MLG 衝撃ストラットの内部および外部シリンダと耐荷重部材。
．機能：
．
MLG 耐荷重部材用シリンダ
−
ダンパー。油圧液がオリフィスを通過することで衝突エネルギーを吸
収する場合およびスプリングのない部品をその伸張位置まで回復させる弾性剤として乾燥窒素を使用す
る場合。
．故障モード：
構造的故障
．
．原因：
．
応力腐食。部品の構造的故障。超過荷重。
．（A）サブシステム、（B）インターフェース、（C）ミッション、（D）乗組員／機体に対する影響：
．
（A）サブシステム機能の喪失。（B）なし。（C）なし。（D）着陸時に主ストラットが破損すると、おそら
く機体が破損するであろう。
．対策とその基本的根拠（A）設計、（B）試験、（C）検査、（D）故障歴：
． （A）最悪ケースの離着陸の場合（ストラットが平伏した場合）でも、構造部材のたわみ(yield)がない限
り、ストラットは、通常の着陸総重量 207,000 ポンド、シンク速度 9.6 フィート／秒、対応する着陸ロ
- 221 -
ールアウトおよび制動条件の下で 1 回の着陸に耐えうる。
（B）試験の合格条件としては、検定済みの材料と工程が使用されているかどうかの検証も含まれる。検
定基準としては、各着陸ギアの寿命期間中の等価荷重を示す散乱係数 4.0 の疲労荷重試験スペクトル
（参照番号 MC62-0011 の表 10−11）もある。静荷重試験には、故障なしの最悪ケース条件である／機体
重量 227 キップ／および右回転によるタキシバンプ試験（65k ペイロード）も含めた。（C）ターンアラ
ウンド目視破損検査では、破損しやすい領域を支えるにはもっと多くの部材を使用する。製造者側では
−原材料を検証−目視検査／識別を実施−部品の防護・塗装・メッキ工程を検証。検査により−製造、
設置、組み立て作業を検証。SHOP TRAVELER MIPS により−防食処理を検証。検査による表面と表面下の
欠陥検証のための非破壊鑑定（NDE＝Non-Destructive Evaluation）。適正に監視された取扱い・貯蔵環
境の検証。検査により契約要求事項に対する材料と設備の適合性を検証−78 年 9 月 25 日の監査により
検査結果を検証。（D）落下試験計画では、外部パッキン押え用ナットが破損した。MENASCO 社では設計
変更を行い、アルミニウムを鋼材に変えた。部品番号 1170134-1 のスナッバー・リングも設計変更にな
った。部品番号 1170107-1 の上部軸受は、アルミニウム・青銅製の一体型軸受に交換された。
（訳注：
（C）項では、句読点とハイフンの前後関係がよくわかりません）。
- 222 -
添付資料 B.6
1.0
概説
1.1
コンフィギュレーションアイテム（CI）の説明
1.2
計画のフェーズとマイルストーン
1.3
特殊特性
2.0
組織
2.1
構造とツール
2.2
権限と責任
2.3
指針書と参考文書
3.0
コンフィギュレーションの識別
3.1
ベースライン
3.2
仕様
4.0
コンフィギュレーションコントロール
4.1
ベースラインの公表
4.2
手順
4.3
CI 監査
5.0
インタフェース・マネジメント
5.1
文書作成
5.2
インタフェース制御
6.0.
7.0
コンフィギュレーション・マネジメント計画書の概要例
コンフィギュレーションのトレーサビリティ
6.1
名称と番号付け
6.2
ハードウェアの識別
6.3
ソフトウェアとハードウェアの識別
コンフィギュレーションの状態説明と通信
7.1
データバンクの説明
7.2
データバンクの内容
7.3
報告
8.0
コンフィギュレーション・マネジメント監査
9.0
下請業者／売り手の管理
- 223 -
添付資料 B.7
機能解析技法
添付資料 B.7 は、Defense Systems Management College（バージニア州フォートベルボ
ア）が 1990 年 1 月に出版した「防衛システム管理手引書」（Defense Systems Management
Guide）から転載したものである。
＊＊＊＊＊＊
システムの要求事項を分析するのは、各機能領域の目的を達成すべきシステム機能を識
別するためである。各機能は、トップダウン方式により入力、出力、インタフェースの要
求事項として識別かつ記述されるので、各サブ機能もそれより大きな機能領域の一部とし
て認識される。各種機能は論理的順序に配列されるので、システムの特定用途もエンド・
ツー・エンド経路で追跡できる。利用できるツールは多いが、機能の識別に採用できるの
は、1）作業の順序と関係を示す機能流れブロック図（FFBD＝Functional Flow Block Diagram)、
2）データ・インターフェースを展開する N2 図、3）タイムクリティカル機能の時間系列を
示すタイムライン解析である。
B.7.1
機能流れブロック図
機能流れブロック図（FFBD）の目的は、システムが実施すべきすべての機能の順序関係
を示すことである。FFBD では機能事象の時間系列を示す。つまり、各機能（1 つのブロッ
クで示される）は前の機能の後に実施される。また、並行して実施される機能もあれば、
交互に実施される機能もある。各機能の実施時間と機能間の時間間隔は図示されないが、
何分の 1 秒から数週までとさまざまである。FFBD は設備指向ではなく、機能指向のブロッ
ク図である。つまり、「何」を実施すべきかという点は指定するが、機能を「どう」実施す
るかという点に対しては特定の回答を与えない。
FFBD は一連のレベルで展開される。各レベルの FFBD では、機能分解により識別された同
一作業を示し、それを論理的順序関係で表示する。たとえば宇宙機の飛行ミッション全体
は、図 B-6 に示すように、トップレベルの FFBD に示すことができる。第 1 レベルの FFBD
にある各ブロックは、次に、第 2 レベルのブロック図「ミッション作業を実施する」に示
すように、一連の機能に展開できる。このブロック図では、入力（運用軌道へ移行させる）
と出力（宇宙輸送システム軌道へ移行させる）の両方を示し、インタフェース識別・管理
プロセスを開始する点に留意されたい。第 2 レベルのブロック図にある各ブロックは、図
B-6 の第 3 レベル・ブロック図に示すように、一連の機能に順次展開される。このようなブ
ロック図を使用する目的は、要求事項を展開するためと、有利なトレード研究を識別する
ためである。たとえば、「宇宙機のアンテナは、ペイロード・データを伝送する時だけ追跡
データ中継衛星（TDRS＝Tracking and Data Relay Satellite)を捕らえるのか、それとも
緊急指令の受信や緊急データの伝送に備えて TDRS を絶えず追跡するのか？」といったトレ
- 224 -
ード研究を実施するためである。FFBD に交代作業や緊急作業を導入し、ミッションの成功
確率を高めることもできる。フローチャートは、システム運用の全容を明らかにし、運用
要領書や緊急対策要領書を作成する際のたたき台となるほか、運用手順に変更を加えてシ
ステムの運用全体を簡略化できるピンポイントを指摘する場合にも役立つ。また、場合に
よっては、交代作業の FFBD を使用して、必要なデータが得られるまで特定機能を実施し続
ける各種方策を示すこともでき、その各種代替案から最適案を選定することもできる。
B.7.2
N2 図
N2 図は、主にソフトウェア分野においてデータ・インタフェースの開発に広く利用され
てきたが、ハードウェア・インタフェースの開発にも利用できる。図 B-7 には基本 N2 図を
示す。システムの諸機能は対角線上に示されている。N x N マトリックス上の残りのます
目には、インタフェースの入力と出力が示されている。空白のます目は、対応する機能間
にインターフェースがないことを示す。データは機能間を時計方向に流れる（たとえば記
号 F1 →F2 は、機能 F1 から機能 F2 へデータが流れていることを示す）。伝送されるデータ
は、適当なます目の中に記入できる。また、円と数字を使用すれば、図 B-8 に示すように
いくつかのデータ・インタフェースを分離して個別リストを作成することもできる。制御
ループという大型円を使用すれば、フィードバック・ループを持ち、機能間を時計方向に
流れるデータの流れを示すこともできる。図 B-8 には重要機能の識別法も示されている。
この図では、機能 F4 が上位モジュールのその他すべての機能につながる多数の入出力デー
タを有している。機能 F7 と F8 の上下モジュール間には、単純なデータの流れしかない。下
位モジュールには、機能間に複雑な相互関係が認められる。N2 図では、ハードウェアとソ
フトウェアの構成要素という機能レベルまで順次下位レベルへ下降させることができる。
N2 図では、インタフェースを介して供給すべきデータを定義するほかに、対立が起こる領
域を正確に示すこともできる。
- 225 -
トップレベルのフローチャート
第1 レベル：飛行ミッション
軌道投入まで
上昇する
検査と配備を
行う
運用軌道へ移
行する
ミッション作
業を実施する
1.0
2.0
3.0
4.0
OR
緊急作業
STS軌道へ移
行する
宇宙機を回収
する
6.0
7.0
再突入と着陸
8.0
STS＝Space Transportation System＝宇宙輸送システム
5.0
第2 レベルのフローチャート
第2 レベル：4.0 ミッション作業を実施する
運用軌道へ
移行する
参照番号（3.0)
電力を供給
する
姿勢を安定
化させる
温度制御を
行う
4.1
4.2
4.3
軌道主電源
を供給する
コマンド（高
利得）を受け
る
OR
4.5
4.4
コマンドを
記憶／処理
する
ペイロード・
データを得る
4.7
4.8
OR
STS軌道へ移
行する
参照番号（6.0)
4.10
サブシステ
ム状態デー
タを得る
コマンド（オム
ニ）を受ける
ペイロードとサ
ブシステムのデ
ータを伝送する
AND
サブシステム
のデータを伝
送する
OR
4.9
4.6
第3 レベルのフローチャート
第3 レベル：4.8 ペイロード・データを得る
コマンドを
記憶／処理
する
ペイロード・デー
タを伝送する
参照番号(4.10)
参照番号（4.7)
TDRSの指向
ベクトルを算
定する
4.8.1
次のターゲットに向けて作業をくり返す
TDRSの方向
へ回転させ
て追跡する
レーダーを
待機状態に
する
4.8.3
4.8.2
LOS指向ベ
クトルを算
定する
4.8.5
4.8.4
コマンドERPを
出し、レーダー
に給電する
宇宙機をLOSベ
クトルの方向
へ旋回させる
1.0
RECの信号と
フォーマット
を処理する
4.8.8
4.8.7
4.8.6
レーダーを
待機状態に
する
（宇宙空間）
レーダーを
OFFにする
TDRS＝Tracking and Data Relay Satellite＝追跡データ中継衛星
LOS＝Line of Sight＝視線方向
ERP＝Effective Radiated Power＝有効放射電力
REC＝Recorder＝レコーダー
4.8.9
（地上）
TDRS暦表を
更新する
TDRS暦表を
更新する
LOSの緯度と
経度を特定
する
レンジを算
定する
ERP．PWと
TINT を選定す
る
最適LOSシー
ケンスを選定
する
4.8.10
4.8.11
4.8.12
4.8.13
4.8.14
4.8.15
図 B-6 機能流れブロック図の展開
- 226 -
コマンドLOAD
をフォーマッ
トする
4.8.16
OR
B.7.3
入力
タイムライン解析
タイムライン解析は機能時間
出力
機能
1
(F1)
F1→F2
F1→F3
に関する検討を加えるもので、
F1→F4
運用機能、試験機能、保守機能
に関する設計要求事項を設定す
機能
F2→F1
F2→F3
2
(F2)
F2→F4
る際に使用される。タイムクリ
ティカル機能と機能系列の解析
機能
F3→F1
F3→F2
を実施かつ記録する場合には、
3
(F3)
タイムライン・シート（TLS＝
機能
F4→F1
F4→F2
4
(F4)
出力
Time Line Sheet)を使用する。
その他に、数学的モデルやコン
ピュータ・シミュレーションな
入力
N2 図の基本原則：
どのツールが必要になる場合も
ある。タイムライン解析の実施
・ 機能（または準機能）はすべて対
角線上に示す。
・出力はすべて水平方向（左方向か
右方向）に流れる。
・入力と出力は機能ではなく、アイ
テムである。
対象は、ミッションの成功、安
全性、資源の利用、ダウンタイ
ムの短縮化、アベイラビリティ
の向上などに時間が重要な要因
2
図 B-7 N 図の定義
となる領域である。あらゆる機
能系列にタイムライン解析が必要になるわけではない。時間が重要要因となるものだけで
ある。タイムクリティカル（時間が重要）とみなされる領域は、次のものである：1）シス
テムの反応時間に関係のある機能、2）ミッションのターンアラウンド時間、3）時間のカ
ウントダウンが必要な作業、4）設備や要員の最適利用率の算定にタイムライン解析が必要
となる機能。宇宙計画の高レベル・タイムライン・シート（TLS）例を図 B-9 に示す。
タイムクリティカル機能系列の場合は、時間要求事項を許容範囲付きで明記する。タイ
ムライン解析は、人間と機械のトレードオフ過程で重要な役割を果たす。自動式と手動式
のいずれかを選定し、どの準機能にどの時間を割り当てるかを決める。タイムライン解析
を採用すれば、サブシステム／構成要素の時間要求事項を設定できる上に、時間要件以外
の領域のトレード研究も実施できる（たとえば、宇宙機の位置設定は、地上ネットワーク
を使って行うべきか、航行衛星からの入力データを使用する機上計算により行うべきか？）。
図 B-10 は保守タイムライン・シート（TLS）例である。この図では、何らかのアイテム（分
留器）のアベイラビリティが多数の保守作業の同時完了に左右されることを示している。
さらに、適当な機能流れブロック図（FFBD＝Functional Flow Block Diagram)と要求割当
シート（RAS＝Requirement Allocation Sheet）を参照して高レベルの要求事項に対するト
レーサビリティも示している。
- 227 -
単純な流れ
重要機能
相互に緊密な関係を
持つ機能グループ
制御ループ
ノード点
複雑な相互関係
図 B-8 N2 図の主要特性("N2 Chart", R. Lano, © 1977 TRW Inc.から転載）
- 228 -
アンテナをTDRS方
向へ回転させる
宇宙機
NB RECを始動する
TDRSにロック
アップする
WSの送信機を始
動する
パス予備計画
TDRS=跡データ中継衛星
WS=ワロップス基地
NB REC=帯域レコーダー
WSGS=ロップス基地地上システム
TLM=隔測定データ
ターゲット
入力
OPTIM PT
SEQ
コマンドLOAD
を設定する
コマンド
LOAD点検
宇宙機の暦表更新
WSGSリンク
を作動させ
る
システムをロッ
クアップする
地上システム
TDRSの暦表更新
コマンドを
ロードする
TLMを処理する
WSデータを記
録する
WSデータを処
理する
PROC（手順）
デー
タを記録する
最終パス入力
-9.0
ユーザーへデータ
を伝送する
-3.0
-6.0
時間（分）
0
-60
-30
図 B-9 飛行ミッションのタイムライン
（D）出所−FFBD（機能
流れブロック図）
37.5 x 3
作業
順序＃
（B）場所−エンジン
ルーム3
（A）機能−蒸気圧縮（VC）分留器の定
期保守整備を実施する
タイムライン・シート
（C）保守整備の種類−予定
の 200 HR PM
（E）機能と作業−RAS（要求割当シート） （F）時間−時間数
37.5 x 37
.5
作
業
1.0
乗組員
.01
.02
.03
.04
.05
.06
.07
.08
.09
圧縮機のベルトを検査する。
ブローダウン・ポンプに注油する。
取り付けボルトを点検する。
ブリーザ・キャップを洗浄する。
食品ストレーナーを洗浄する。
オイル交換を行う。
フィルタを交換する。
V 形駆動ベルトを交換する。
制御パネルの清掃と検査を行う。
A2
B1
B1
B1
C1
B1
C1
D1
C1
.10
.11
新しいダイアフラムを設置する。
制御器を清掃する。
A2
B1
.3H
.2H
.1H
.1H
.5H
.2H
.4H
.9H
.1H
.7H
.1H
合計人時 − 3.6 人時
経過時間 − 1.0 時間
図B-10 保全作業タイムライン・シート例
- 229 -
添付資料 B.8
宇宙ステーション「フリーダム」の運用に対する ORU の MTBF 変更の影響
宇宙ステーション「フリーダム」（SSF＝Space Station "Freedom")の軌道交換ユニット
（ORU＝Orbital Replacement Unit）の信頼性は、この宇宙ステーションの運用コストに大
きな影響を及ぼす。その信頼性は平均故障間隔（MTBF＝Mean Time Between Failures）か
ら算定する。その影響に関する研究論文としては、William F.Fisher 博士と Charles Price
による"SSF External Maintenance Task Team Final Report"(「宇宙ステーション「フリ
ーダム」の船外保守作業チーム最終報告書」）（ジョンソン宇宙センター、1990 年 7 月）が
ある。また、Anne Accola その他による研究論文でも、その影響についてパラメータを使
って示している。添付資料 B.8 は、この論文 "Sensitivity Study of SSF Operations Costs
and Selected User Resources"（「SSF 運用コストと特定ユーザー資源の感度研究」）（1990
年 5 月に開催された宇宙システムのコスト算定方法とその適用対象に関する国際航空宇宙
アカデミーのシンポジウムで発表）から抜粋したものである。
＊ ＊＊＊＊＊
宇宙ステーション「フリーダム」（SSF＝Space Station "Freedom")の設計段階の中に実
施できるトレードオフは多数ある。その多くは、主に乗組員の安全性、運用コスト、ミッ
ション目標の達成に主な関連性があり、運用コストと、コスト以外の重要な運用パラメー
タについて検討する。設計の特定問題領域の一例としては、SSF を構成する各種軌道交換ユ
ニット（ORU＝Orbital Replacement Unit）の信頼性がある。ロジスティックスによる SSF
へのアップマスと SSF からのダウンマスに対しては、ORU の信頼性が密接な関係を持ち、利
用資源とその他運用作業に必要な資源に影響を及ぼす。さらに、ミッション実施（つまり
各種実験）と宇宙ステーションの保守作業に必要な乗組員の時間に対しても、ORU の信頼性
が密接な関係がある。
運用コストに対する平均故障間隔（MTBF）の影響を図 B-11 に示す。補修費と予備品費は、
MTBF の変動により大きな影響を受ける。補修費は、交換用予備品費と同様、MTBF に反比例
する。初期予備品費は、MTBF 以外の変数からも影響を受ける。初期予備品と交換用予備品
からなる混成予備品費は、補修費ほど大きな影響を受けない。ORU の MTBF をすべて半減す
ると、5 年間の運用コストは 10 パーセントしか増大しない。ORU の MTBF をすべて 2 倍にす
ると、総運用コストは 3 パーセント低下する。つまり、MTBF は一般に考えられているほど
重要なものではないと思われるであろう。しかし、図 B-12 と図 B-13 に示すように、MTBF
は運用コストよりも乗組員の使用可能時間と使用可能アップマスにはるかに大きな影響を
及ぼす。
- 230 -
乗組員の使用可能時間は限られた資
120
源であるため、貴重な商品となる。
名目運用変動率（％）
100
80
（MTBF を短縮化して）ORU の交換回数
60
を 2 倍にすると、乗組員の保守作業時間
40
は 50 パーセント伸びる。その結果、必
20
要な実験や科学的業務のために使用で
0
きる時間量は 22 パーセント減少する。
-20
ORU の交換回数を半減すると、乗組員の
-40
保守作業時間は 20 パーセント短縮し、
-60
-60
-40
-20
0
20
40
60
名目MTBF（平均故障間隔）変動率（％）
乗組員の使用可能時間は 8 パーセント
増える。
補修費
予備品費（初期費＋再調達費）
5年間の運用コスト
スペースシャトルの所定飛行回数では
図B-11 運用コストに対するMTBF の影響
SSF へ所定量のペイロードしか輸送で
きないので、使用可能アップマス（質量
増大分）も貴重な資源となる。軌道上
80
へ余分の ORU を輸送すれば、実験用ペ
60
乗組員の名目時間変動率(%)
イロードの積み込みのための使用可能
アップマスは減少する。特に、ORU 交換
40
回数を 2 倍にすると、使用可能アップ
20
マスはゼロまで落ちる。逆に、ORU 交換
回数を半減すると、使用可能アップマ
0
スは 30 パーセント増大する。
-20
-40
-60
資源に対する MTBF の影響も興味深い
が、名目資源を一定に維持するための
-40
-20
0
20
40
60
名目MTBF（平均故障間隔）変動率(%)
果を定量化するというのも良い考えで
乗組員の使用可能時間
乗組員の保守作業時間
図 B-12
総コストに基づいて各種シナリオの効
ある。図 B-14 には、乗組員の使用可能
乗組員の時間に対する MTBF の影響
時間を一定に維持するために必要とな
る年間乗組員数を示す。この図から明
らかなように、ORU 交換回数を 2 倍にした後、乗組員の名目使用可能時間を一定に維持する
ためには、宇宙ステーションでは 2 名の乗組員を余分に必要とする。ただし、この乗組員
増員が設計上可能かどうかという点や、設計費に対するその影響を評価する試みはまった
くなされていない。ORU 交換回数の半減による乗組員の削減数は少なく、半年間に実際では
1 名減るだけである。
- 231 -
図 B-15 には、名目使用可能アップマ
150
スを一定に維持するために必要となる 5
100
年間のスペースシャトル飛行回数を示
す。スペースシャトルの飛行回数は、端
使用可能アップマス
50
数を切り上げて整数にしてある。ORU 交
換回数を 2 倍にすると、5 年間に 8 回の
0
スペースシャトル飛行が余分に必要に
-50
なる。ORU 交換回数を半減すると、5 年
間に必要なスペースシャトル飛行回数
-100
は 2 回少なくなる。ただし、スペースシ
-150
-60
ャトルが余分の飛行回数を実施できる
-40
-20
0
20
40
60
名目MTBF 変動率（％）
使用可能アップマス
ORU のアップマス
かどうかという点や、信頼性の異なる各
種 ORU の製造が設計費に及ぼす影響を評
価する試みはまったくなされていない。
図B-13 アップマスに対するMTBF の影響
2.5
図 B-16 には、前の 2 図によるコスト
への影響を評価し、5 年間の運用コスト
2
年間乗組員数
と組み合わせた結果を示す。使用可能ア
5
ップマスと乗組員の時間という両資源
をその名目値に維持した場合には、MTBF
1
の影響は実際上 2 倍に増大する。
0.5
0
-0.5
-1
-60
-40
-20
0
20
40
60
名目MTBF 変動率（％）
図B-14 乗組員数に対するMTBF の影響（乗組員の使用
可能時間を一定に維持）
- 232 -
10
8
6
2
0
-2
-4
-60
-40
-20
0
20
40
60
名目MTBF 変動率（％）
図B-15 STS(宇宙輸送システム）の飛行回数に対するMTBF
の影響（使用可能アップマスを一定に維持）
25
20
5 年間の名目運用コスト変動率（％）
5 年間のSTS 飛行回数
4
15
10
5
0
-5
-10
-60
-40
-20
0
20
40
60
名目MTBF 変動率（％）
維持した場合
維持しない場合
図B-16 5 年間の運用コストに対するMTBF の影響（使用可
能アップマスと乗組員の使用可能時間を一定に
維持した場合と維持しない場合）
- 233 -
添付資料 B.9
検証要求事項マトリックス例
添付資料 B.9 は、マーシャル宇宙飛行センターが公表した"National Launch System Level
III System Requirements Document"(「国有打上げシステムのレベル III システム要求書」
から抜粋した検証要求事項マトリックス（VRM＝Verification Requirements Matrix）の極
一部である。ここでは、VRM の内容と一つの形式例を示すに留める。このマトリックス例に
ある VRM コードの説明は、次表に示す。
項目番号
3.2
6.2
3.2
3.2
3.2
3.3
3.3.1
3.3.1.1.
3.3.1.1.1
3.3.1.1.2
3.3.1.1.2
3.3.1.1.2
3.3.1.1.3
3.3.1.1.4
3.3.1.1.4.1
3.3.1.1.4.2
要求事項
3.2 搭乗員認定条項
機体の基本設計は、有人飛行に必要な設計上の安
全要素、信頼性、健康監視を考慮に入れたものと
する
フライトクリティカル・システムの設計はすべ
て、第 3.20.5.14 項に明記したように、信頼性の
高い部品と構成要素を採用したものとする。
機体の破損に至るような故障を起こす恐れのあ
る重要システムはすべて、少なくともフェイルセ
ーフ設計を採用したものとする。
その設計は、第 3.4.10.3 項に明記したような緊
急検出システム（EDS＝Emergency Detection
System）を装備したものとする。
3.3 運用要求事項
3.3.1 打上げロケット地上運用要求事項
3.3.1.1 運用準備要求事項
1.5 段 LV（Launch Vehicle＝打上げロケット）と
HLV（Heavy Lift Vehicle＝重量物打上げロケッ
ト）は、1.5 段 LV と HLLV（Heavy Lift Launch
Vehicle ＝大重量打上げロケット）の総飛行率、
年間飛行回数 44 回以下に対して少なくとも TBD
（To be determined＝未定）の運用時間分数（第
6.1.1 項を参照）を示すものとする。
各射場において、打上げロケットがその打上げ予
定期日（ロケットの統合化開始時より遅くならな
い期日と定義されている）から 10 日以内に打上
げを実施できる確率は、90 パーセントを超えるも
のとする。
LV（Launch Vehicle＝打上げロケット）は、その
打上げ予定期日から 20 日以内に打上げを実施で
きる確率 95 パーセントをも満たすものとする。
LV は昼間や夜間に打上げを行う能力を備えたも
のとする。
LV は、第 3.20.5.7 項に従ってペイロード・キャ
リア、ペイロード、LV エレメント（たとえばペイ
ロード・キャリア用アダプターなど）、地上の間
の電位差を解消する手段を備えたものとする。
3.3.1.1.4 持続可能な打上げ率。
LV は、KSC（Kennedy Space Center＝ケネディ宇
宙センター）からの年間飛行回数 3 回という最大
予定打上げ率を達成できるように設計されたも
のとする。
LV は、CCAFS（Cape Canaveral Air Force Station
＝ケープカナベラル空軍基地）からの年間飛行回
数 14 回（弾性エネルギー要求事項を満たすため
の飛行 4 回も含む）という最大予定打上げ率を達
成できるように設計されたものとする。
- 234 -
Ａ
Ｂ
Ｃ
4.1
4.1
Ｄ
０
2.4,
3.5
2.1,
3.5
3.2,
3.5
3.5
0
0
0
2.4
2.4
2.4
2.4
2.4,
3.5
0
3.5
3.5
7.14,
7.17
Ｅ
Ｆ
検証要求事項マトリックスのコード説明
コード
0
1.0
1.1
1.2
2.0
2.1
2.2
2.3
2.4
3.0
3.1
3.2
3.3
3.4
3.5
4.0
4.1
4.2
4.3
4.4
5.0
5.1
5.2
5.3
5.4
6.0
6.1
6.2
6.3
6.4
7.0
7.1
7.2
7.3
7.4
7.5
7.6
7.7
7.8
7.9
7.10
7.11
7.12
7.13
7.14
7.15
7.16
7.17
7.18
検証方法／レベル
方法
情報のタイトルのみ
類似法
構成要素類似法
サブシステム類似法
解析
構成要素解析
サブシステム解析
総合エレメント解析
総合機体解析
検査
構成要素検査
サブシステム検査
総合エレメント検査
総合機体検査
設計文書の審査
記録の検証
構成要素の記録検証
サブシステムの記録検証
総合エレメントの記録検証
総合機体の記録検証
実証試験
構成要素実証試験
サブシステム実証試験
総合エレメント実証試験
総合機体実証試験
シミュレーション
構成要素シミュレーション
サブシステム・シミュレーション
総合エレメント・シミュレーション
総合機体シミュレーション
試験
構成要素機能試験
構成要素環境試験
構成要素 EMI／EMC（電磁干渉／電磁適合性）試験
構成要素プルーフ（保証）試験
その他の構成要素試験
サブシステム機能試験
サブシステム環境試験
サブシステム・プルーフ（保証）試験
その他のサブシステム試験
総合エレメント機能試験
総合エレメント環境試験
総合エレメント EMI／EMC（電磁干渉／電磁適合性）
試験
総合エレメント・インターフェース試験
その他の総合エレメント試験
総合機体機能試験
総合機体環境試験
総合機体インターフェース試験
ホット・ファイアリング試験
- 235 -
コード
Ａ
Ｂ
Ｃ
Ｄ
Ｅ
Ｆ
検証段階
段階
開発
認定試験
受領
打上げ準備
飛行／運用
飛行後／廃棄
添付資料 B.10
1.0
2.0
3.0
4.0
5.0
検証マスタープランの概要例
概説
1.1
適用範囲
1.2
適用文書
1.3
文書の保管と管理
プログラム／プロジェクトの説明
2.1
プログラム／プロジェクトの概
観と検証マスタースケジュール
2.2
システムの説明
2.3
サブシステムの説明
統合化・検証（I＆V）組織およびそ
の職員
3.1
プログラム／プロジェクト管理
当局
3.2 NASA フィールドセンターの統合
化・検証（I＆V）組織
3.3
国際提携統合化・検証（I＆V）
組織
3.4
主要契約者の統合化・検証（I
＆V）組織
3.5 下請業者の統合化・検証（I＆V）
組織
検証チームの作業関係
4.1
検証チームのスケジュール作成
および審査会議
4.2
検証と設計審査
4.3
データ不一致の報告および是正
手続き
システム認定検証
5.1
試験*
5.2
解析
5.3
検査
5.4
実証試験
6.0
システム受領検証
6.1
試験*
6.2
解析
6.3
検査
6.4
実証試験
7.0
射場検証
8.0
軌道上検証
9.0
ミッション後／処分検証
10.0 検証文書の作成
11.0 検証方法
12.0 支援設備
12.1 地上支援設備
12.2 飛行支援設備
12.3 輸送、取扱い、その他のロ
ジスティックス支援
12.4 TDRSS／NASCOM（データ中継
衛星システム／NASA 通信
網）支援
13.0 施設
* この項には、たとえば EMI／EMC
（electromagnetic
Interference/electromagnetic
compatibility＝電磁干渉／電磁適合
性）、メカニズム、熱／真空試験といっ
た各種試験に関する項目も記載され
る。この種類別細分化は、解析、検査、
実証試験にも適用される。
- 236 -
添付資料 C
C.1
メートル法の使用
NASA の方針
NASA の方針（NMI(NASA Management Instruction＝NASA 管理手引書）8010.2A と NHB(NASA
Handbook＝NASA ハンドブック）7120.5 を参照)は、次のとおりである。
・
国際的に SI と略称されている国際単位系を採用する。これは、あらゆる主要システ
ム開発計画向けの推奨度量衡法として、ANSI／IEEE（米国規格協会／電気電子学会）
規格 268-1992 により定められたものである。
・
経済的に採用可能な限り、調達、補助金交付、ビジネス関係の業務においてはメー
トル法を採用する。
・
既成システムには、インチ・ポンド法の継続使用を認める。
・
メートル法のみの採用を実施できない場合、安全性や性能の支障となる場合等は、
メートル法とインチ・ポンド法の併用を認める。
C.2
単位の定義
添付資料 C の一部は、IEEE 規格 268-1992"American National Standard for Metric
Practice"( 「メートル法慣用に関する米国規格」)(著作権 ©1992 The Institute of
Electrical and Electronics Engineers, Inc.）から転載したものである。本書への転載
と使用に対しては、IEEE はいかなる責任も義務も負わない。本書への転載に際しては IEEE
の許可を受けている。
＊＊＊＊＊＊
米国以外では、小数点としてコンマが通用している。そのため、一部の用途では、（たと
えば 23,478 のように）数値を 3 桁ずつ区分するのにコンマを使用するという米国の慣用法
は、混乱を招く恐れもある。このような混乱を避けるために推奨されている国際的慣用法
では、小数点から左右に数えて 3 桁ごとに数字を区分し、各 3 桁の数字群を区分するのに
小さいスペースを挿入する。小数点の左右両側に 4 桁の数字がある場合は、通常スペース
を使用する必要はない。ただし、表と表の間で統一を図る場合は別である。
C.2.1
SI 単位の接頭辞
SI 単位の倍数名と約数名は、枠内補足記事に示す接頭辞や記号を使って形成できる。（唯
一の例外は、キログラムという重量単位である。歴史的理由により、単位名を形成する基
本名として「グラム」が使用されている）。
- 237 -
SI 単位の接頭辞
因数
接頭辞
記号
発音
10+24
yotta
Y
ヨッタ（a は about の a と同じ）
10+21
zetta
Z
ゼッタ（a は about の a と同じ）
exa
E
イグザ（a は about の a と同じ）
10+15
peta
P
ペタ（a は petal の a と同じ）
+12
tera
T
テラ（terrace の terra と同じ）
10+9
giga
G
ギガ（g は giggle の g、a は about の a と同じ）
+6
mega
M
メガ（megaphone の mega と同じ）
10+3
kilo
k
キロ**
10+2
hecto*
h
ヘクト
10
deka*
da
デカ（decahedron の deca と同じ）
10-1
deci*
d
デシ（decimal の deci と同じ）
10-2
10
10
10
+18
1
centi*
c
センチ（centipede の centi と同じ）
-3
milli
m
ミリ（military の mili と同じ）
10-6
micro
μ
ミクロ（microphone の micro と同じ）
nano
n
ナノ（a は ant の a と同じ）
10-12
pico
p
ピコ
10-15
femto
f
フェムト
atto
a
アット（a は hat の a と同じ）
10-21
zepto
z
ゼプト（e は step の e と同じ）
-24
yocto
y
ヨクト
10
10
10
10
*
-9
-18
1000 を累乗する「べき数」以外の接頭辞（つまりヘクト、デカ、デシ、センチ）は、
実際上使用を避けるべきである。
**
各接頭辞が接頭辞であることを示すために、その接頭辞の第一音節にアクセントをつ
ける。「キロメートル」も例外ではない。
C.2.2
基本 SI 単位
アンペア（A）：
「アンペア」とは、真空中に 1 メートル間隔で敷設された、無視できる
断面直径と無限の長さを持つ 2 本の並列直線導線内を流れる電流が、この両導線間に長さ 1
メートル当たり 2 x 10-7 ニュートンに等しい力を発生させる定電流量である。
カンデラ（cd）：
「カンデラ」とは、周波数 540 x 10+12 Hz の単色放射線を発し、所定方
- 238 -
向の放射強度が 1 ステラジアン当たり 1/683 ワットである光源のその方向における光度で
ある。
ケルビン（K）：
「ケルビン」とは熱力学的温度の単位で、水の三重点の熱力学温度の
1/273.16 に相当する。
キログラム（kg）
： 「キログラム」とは質量の単位で、キログラムの国際原器の質量に等
しい。（キログラムの国際原器とは、国際法定計量事務局（International Bureau of Weights
and Measures）がフランスのセーブルに保存している特定のプラチナ・イリジウム合金製
シリンダーである）。
メートル（m）：
「メートル」とは、1 299 792 458 分の 1 秒間に光が真空中を伝わる経
路の長さである。
モル（mol）
： 「モル」とは、 0.012 キログラムの炭素 12 に含まれる原子と同数の単位粒
子を含む系の物質の量である。注記：
モル単位を使用する場合は、単位粒子を指定しな
ければならない。単位粒子は、原子、分子、イオン、電子、その他の粒子、またはそのよ
うな粒子の特定粒子群のいずれかである。
秒（s）：
「秒」とは、セシウム-133 原子が 2 つの超微細レベルの粉砕状態間を遷移する
時に発する放射線の 9 192 631 770 周期に相当する時間である。
C.2.3
補助 SI 単位
ラジアン（rad）：
「ラジアン」とは、何らかの円の円周から、その半径と等しい長さの
円弧を切り取った場合、その円弧における 2 つの半径間の面角である。
ステラジアン（sr）
： 「ステラジアン」とは、何らかの球体から、その半径に等しい長さ
の辺を持つ正方形の面積に等しい球面面積の立体を切り取った場合、その球体の中心を頂
点とするその立体角である。
C.2.4
特殊名付き誘導単位
本節 C.2 で定義した単位のほかに、特殊名を持たない誘導単位（速度の m／s、電界の強
さの V／m、エントロピーの J／K など）で測定される量も多い。
ベクレル（Bq＝l／s）：
「ベクレル」とは、1 秒間に 1 回という自然核変換率で崩壊する
- 239 -
放射性核種の放射能レベルである。
摂氏（℃＝K）
： 「摂氏」はケルビンに等しく、方程式 t＝T−To により定義された摂氏温
度を表わす場合に、ケルビンの代わりに使用される。この場合、t は摂氏温度、T は熱力学
的温度、To ＝273.15K（定義上）である。
クーロン（C＝A・s）：
「電荷」とは電流量と時間の積分である。その単位である「クー
ロン」は、1 秒間に流れる電流 1 アンペアに等しい。
ファラッド（F＝C／V）：
「ファラッド」とは、何らかのキャパシタを 1 クーロンに等し
い電気量で充電した時に、その極板間に 1 ボルトの電位差が生じた場合にそのキャパシタ
が有するキャパシタンス（静電容量）である。
グレイ（Gy＝J／kg）：
「グレイ」とは、電離放射線により物質に付与された単位質量当
たりのエネルギーが 1 ジュール／キログラムである場合の吸収線量である。（「グレイ」は、
電離放射線量である付与されたエネルギー比、カーマ、吸収線量指数にも使用される）。
ヘンリー（H＝Wb／A）
： 「ヘンリー」とは、閉回路内を流れる電流が 1 秒 1 アンペアの割
合で一律に変動する時に 1 ボルトの起電力が生ずる場合のその閉回路のインダクタンスで
ある。
ヘルツ（Hz＝l／s）：
「ヘルツ」とは、1 秒の周期で発生する周期的現象の発生頻度であ
る。
ジュール（J＝N・m）
： 「ジュール」とは、1 ニュートンの力をかけられた点が、その力の
方向へ 1 メートル移動する場合の作業量である。
ルーメン（lm＝cd・sr）：
「ルーメン」とは、1 カンデラの均等光度を有する点光源から
1 ステラジアンの立体角で発射された光束である。
ルックス（lx＝lm／m2)：
「ルックス」とは、1 平方メートルの表面上に均等に分散され
た 1 ルーメンの光束から得られる照度である。
ニュートン（N＝kg・m／s2)：
「ニュートン」とは、質量 1 キログラムの物体に力をかけ
た時に、1 メートル／秒 2 の加速度をその物体に与える力である。
オーム」（Ω＝V／A）：
「オーム」とは、導体の 2 点間に 1 ボルトの定電位差を印加した
- 240 -
時に、この導体内に 1 アンペアの電流が流れる場合に生ずるその 2 点間の電気抵抗である。
この導体は起電力の発生源とはならない。
パスカル（Pa＝N／m2)：
「パスカル」（rascal と同じ韻律で発音するとよい）とは、1 平
方メートル当たり 1 ニュートンの圧力または応力である。
ジーメンス（S＝A／V）
： 「ジーメンス」とは、1 ボルトの電位差により 1 アンペアの電流
が発生する場合の導体のコンダクタンスである。
シーベルト（Sv＝J／kg）：
放射線の吸収線量
x
「シーベルト」とは、国際放射線防護委員会の定めた「電離
無次元係数 Q（線質係数） x
N（その他の乗算係数）」の値が 1 キ
ログラム当たり 1 ジュールになる場合の線量当量である。
テスラ（T＝Wb／m2)：
「テスラ」とは、1 平方メートル当たり 1 ウェーバーという磁束密
度である。もう一つの磁場量定義方式によると、「テスラ」は、1 アンペアの電流が流れる
長さ 1 メートルの電線に 1 ニュートンの力を発生させる、電流の方向に垂直な磁束密度と
定義されている。磁束密度とは、1 電流要素にかかる力がこの電流要素と磁束密度のベクト
ル積に等しくなるような軸ベクトル量と定義されている。
ボルト（V＝W／A）：
「ボルト」（電位差と起電力の単位）とは、1 アンペアの定電流が流
れる導体の 2 点間の電力消散量が 1 ワットに等しい時に生ずるその 2 点間の電位差である。
ワット（W＝J／s）
： 「ワット」とは、1 秒間に 1 ジュールのエネルギー付与率を示す電力
である。
ウェーバー（Wb＝V・s）：
「ウェーバー」とは、1 回巻きの回路と連結し、一定速度で 1
秒間にゼロまで低下する、その回路に 1 ボルトの起電力を発生させる磁束である。
C.2.5
SI と併用する単位
「時間」：
時間の SI 単位は「秒」である。この単位は推奨単位であり、特に技術的計
算を行う場合は、この単位をなるべく採用すべきである。時間が生活習慣やカレンダー・
サイクルと関係がある場合は、分、時間、日、その他のカレンダー単位を必要とする場合
もある。たとえば、車の速度は通常キロメータ／時で表わされる。
分（min）：
1 分＝60 秒
時間（h）：
1 時間＝60 分＝3600 秒
- 241 -
日（d）：
1 日＝24 時間＝86 400 秒
週、月など。
面角：
面角の SI 単位は「ラジアン」である。ただし、ラジアンを使用しにくい場合は、
度やその約数の使用も認められる。分と秒の使用は、天文学や地図製作といった特殊な分
野以外は推奨できない。
度（°）：
面積：
1 度＝（π/180）ラジアン
分（’）：
1 分＝（1/60）度＝（π/10 800)ラジアン
秒（”）：
1 秒＝（1/60）分＝（π/648 000）ラジアン
面積の SI 単位は「平方メートル」（m2)である。ヘクタール（ha）はヘクトメート
ル（hm2)に対する特殊名である。広大な土地や水域の面積は、通常ヘクタールや平方キロメ
ートル（km2)で表わされる。
体積と容積：
体積や容積の SI 単位は「立方メートル」である。推奨単位は、立方メート
ルのほか、立方センチメートルなどを付けた正規の倍数である。特殊名の「リットル」の
使用は、立方デシメートルの代わりとして使用を認められているが、容量、乾量、流体（液
体と気体）量に限られる。「ミリ」や「ミクロ」以外の接頭辞は、「リットル」と併用すべ
きではない。
質量： 質量の SI 単位は「キログラム」である。すべての用途には、この単位のほか、「グ
ラム」（g）に SI 接頭辞を付けた倍数の使用が推奨される。「トン」で表わされてきた大重
量の測定単位としては、「メガグラム」（Mg）が適している。しかし、商業界や技術界で通
用しているいくつかの大重量単位には「トン」を付けている。たとえば 2240 ポンドの大ト
ン（または英トン）、2000 ポンドの小トン（または米トン）、1000kg または約 2205 ポンド
のメートルトン（米国以外では「トン」(tonne）ともいう）などがある。このような単位
はいずれも SI 単位ではない。「メートルトン」単位の使用は商業界のみに限定すべきで、
接頭辞を併用すべきではない。「トン」(tonne）の使用は避けるべきである。
その他：
ANSI／IEEE（American National Standards Institute/Institute of Electrical
and Electronics Engineers(米国規格協会／電気電子学会））規格では、"Units in Use with
SI Temporarily"（「SI と一時的に併用する単位」）に「キロワット時」（kWh＝3.6 MJ）も含
めている。すべての用途に対しては、エネルギーの SI 単位「ジュール」とその倍数の併用
が望ましい。しかし、電気エネルギーの単位としては「キロワット時」が通用している。
新分野にはこの単位を導入すべきではなく、最終的には「メガジュール」に代えるべきで
ある。上記規格で「一時的」使用を認められたその他の単位としては、断面積の「バーン」
- 242 -
（1b＝10-28 m2)、圧力の「バール」（1bar＝10+5Pa）、放射性核種の放射能単位である「キュ
リー」（1Ci＝3.7 x 10+10 Bq）、X 線やガンマ線の被ばく量である「レントゲン」（1R＝2.58 x
10-4 C／kg)、線量当量の「レム」（1rem＝0.01Sv）、吸収線量の「ラッド」（1rd＝0.01Gy）
などがある。
C.3
換算係数
換算係数表が記載されている多くの文書の一つは、ANSI／IEEE（American National
Standards Institute/Institute of Electrical and Electronics Engineers(米国規格協
会／電気電子学会））規格 268-1992 である。以下に示す表は、その規格から抄録したもの
である。SI 単位の記号は、かっこ（
）内にボールドフェース（太字）で示す。数値と 10
のべき数の間にアスタリスク(*) の付いた係数は、定義上正確なものである。国際慣用法
に合わせ、数字群には（コンマではなく）スペースを挿入している。
左欄の単位から中央欄の単位に換算するには、右欄の係数をかける。
換算すべき単位
換算された単位
エーカーフット .............................. 立方メートル（m 3 ) ..................... 1.233 5 E+03
エーカー .................................... 平方メートル（m 2 ) ..................... 4.046 9 E+03
天文単位.................................... メートル（m） ....................... 1.495 979 E+11
気圧単位（標準） ............................ パスカル（Pa） ....................... 1.013 25*E+05
..............................................
バレル（石油の単位、42 ガロン） ............. 立方メートル（m 3 ) ................... 1.589 873 E-01
ボードフット ................................ 立方メートル（m 3 ) ................... 2.359 737 E-03
英国熱量単位（国際表） ...................... ジュール（J） ....................... 1.055 056*E+03
カロリー（熱化学） .......................... ジュール（J） ........................... 4.184*E+00
カロリー（国際表） .......................... ジュール（J） ......................... 4.186 8*E+00
水銀柱センチメートル(0℃） .................. パスカル（Pa） ....................... 1.333 22 E+03
..............................................
水柱センチメートル(4℃） .................... パスカル（Pa） ....................... 9.806 38 E+01
..............................................
カップ ...................................... ミリリットル（mL） ...................... 2.366 E+02
キュリー ....................................
ベクレル（Bq） ........................... 3.7*E+10
日.......................................... 秒（s） .................................. 8.64*E+04
- 243 -
..............................................
日（恒星） .................................. 秒（s） ............................. 8.616 409 E+04
度（角度） .................................. ラジアン（rad） ..................... 1.745 329 E-02
摂氏 ........................................ ケルビン（K） ..................... Tk＝t℃ + 273.15
..............................................
華氏 ........................................ 摂氏（℃） ................... t ℃＝（t °F -32)/1.8
..............................................
華氏 ........................................ ケルビン（K） ............. Tk＝（t °F + 459.67)/1.8
ランキン .................................... ケルビン（K） ......................... Tk＝T °R/1.8
ダイン ...................................... ニュートン（N） ............................. 1*E-05
電子ボルト.................................. ジュール（J） ........................ .1.602 19E-19
エルグ ...................................... ジュール（J） ............................... 1*E-07
ファゾム.................................... メートル（m） ......................... 1.828 8 E+00
フィート .................................... メートル（m） ........................... 3.048*E-01
水柱フート（39.2 °F） ....................... パスカル（Pa） ....................... 2.989 07 E+03
..............................................
フートキャンドル ............................ ルックス（lx） ...................... 1.076 391 E+01
フートランベルト ............................ カンデラ／メートル 2(cd／m 2 ) ......... 3.426 259 E+00
ft・lbf ..................................... ジュール（J） ....................... 1.355 818 E+00
ft・lbf／s .................................. ワット（W） ......................... 1.355 818 E+00
フートポンダル .............................. ジュール（J） ....................... 4.214 011 E-02
g（自由落下の標準加速度） ................... メートル／秒 2(m／s 2 ) ................. 9.806 65*E+00
..............................................
ガロン（米国液体単位） ...................... 立方メートル（m 3 ) ................... 3.785 412 E-03
ガウス ...................................... テスラ（T） ................................. 1*E-04
グレーン .................................... キログラム（kg） .................... 6.479 891*E-05
馬力（550 ft・lbf／s） ...................... ワット（W） ......................... 7.456 999 E+02
時間 ........................................ 秒（s） ................................... 3.6*E+03
時間（恒星時） .............................. 秒（s） ............................. 3.590 170 E+03
インチ...................................... メートル（m） ............................ 2.54*E-02
..............................................
- 244 -
水銀柱インチ（32 °F） ....................... パスカル（Pa） ....................... 3.386 39 E+03
..............................................
水柱インチ（60 °F） ......................... パスカル（Pa） ....................... 2.490 89 E+02
..............................................
キログラム重（kgf） ......................... ニュートン（N） ...................... 9.806 65*E+00
..............................................
キロワット時（kW・hr または kWh） ............ ジュール（J） ............................. 3.6*E+06
キップ（1000 lbf） .......................... ニュートン（N） ..................... 4.448 222 E+03
ノット（国際） .............................. メートル／秒（m／s） ................ 5.144 444 E-01
ランベルト.................................. カンデラ／メートル 2(cd／m 2 ) .............. 1/π*E+04
..............................................
光年 ........................................ メートル（m） ........................... 9.461 E+15
リットル .................................... 立方メートル（m 3 ) ........................... 1*E-03
マクスウェル ................................ ウェーバー（Wb） ............................ 1*E-08
モー ........................................ ジーメンス（S） ............................. 1*E+00
ミクロン .................................... メートル（m） ............................... 1*E-06
ミル ........................................ メートル（m） ............................ 2.54*E-05
..............................................
マイル（国際） .............................. メートル（m） ....................... 1.609 344*E+03
マイル（米国法定） .......................... メートル（m） ....................... 1.609 347 E+03
マイル（海里） .............................. メートル（m） ........................... 1.852*E+03
オンス（常用） .............................. キログラム（kg） .................... 2.834 952 E-02
オンス（トロイまたは薬用） .................. キログラム（kg） .................... 3.110 348 E-02
オンス（米国流体単位） ...................... 立方メートル（m 3 ) ................... 2.957 353 E-05
パーセク .................................... メートル（m） ....................... 3.085 678 E+16
パイカ（印刷機用単位） ...................... メートル（m） ....................... 4.217 518 E-03
ポンド（質量の単位）（常用）（lb または lbm） .. キログラム（kg） .................. 4.535 923 7*E-01
ポンダル .................................... ニュートン（N） ..................... 1.382 550 E-01
ポンド重（lbf） ............................. ニュートン（N） ..................... 4.448 222 E+00
クァド ...................................... ジュール（J） ........................... 1.055 E+18
クォート（米国乾量） ........................ 立方メートル（m 3 ) ................... 1.101 22 E-03
..............................................
- 245 -
クォート（米国液体単位） .................... 立方メートル（m 3 ) .................... 9.463 53 E-04
..............................................
ラッド（吸収線量） .......................... グレイ（Gy） ................................ 1*E-02
レム（線量当量） ............................ シーベルト（Sv） ............................ 1*E-02
レントゲン .................................. クーロン／キログラム（C／kg） ............ 2.58 E-04
..............................................
スラッグ .................................... キログラム（kg） .................... 1.459 390 E+01
テーブルスプーン ............................ ミリリットル（mL） ...................... 1.479 E+01
ティースプーン .............................. ミリリットル（mL） ...................... 4.929 E+00
サーム（米国） .............................. ジュール（J） ....................... 1.054 804*E+08
トン（TNT の爆発エネルギー） ................. ジュール（J） ........................... 4.184 E+09
冷凍トン（12 000 Btu／h） ................... ワット（W） ............................. 3.517 E+03
トン（小トン、2000 lb） ..................... キログラム（kg） .................... 9.071 847 E+02
ヤード...................................... メートル（m） ........................... 9.144*E-01
年(365 日）.................................. 秒（s） ............................... 3.153 6*E+07
年（恒星年） ................................ 秒（s） ............................. 3.155 815 E+07
- 246 -
索引
Advanced projects
"Alpha"
先端プロジェクト
「アルファ」（Space Station "Alpha" を参照）
Analytic Hierarchy Process（AHP）
"Apollo"
「アポロ」
Architecture
Audits
解析階層プロセス
アーキテクチャ（system architecture を参照）
監査
Availability
アベイラビリティ
measure of
∼の測定
as a facet of effectiveness
models of
∼のモデル
as part of the LSA
Baselines
一効果面としての∼
LSA（ロジスティックス支援解析）の一環としての∼
ベースライン
control and management of
in C/SCS
C／SCS（コスト／スケジュール管理システム）における∼
in reviews
Bathtub curve
∼のコントロールとマネジメント
審査中の∼
バスタブ曲線
Bayesian probability
ベイズの確率
Budget cycle, NASA
予算サイクル、NASA∼
Budgeting, for projects
予算編成、プロジェクトの∼
Change Control Board (CCB)
composition of
conduct of
変更管理委員会
∼の構成
∼の運営
Change Requests (CR)
変更要求書
Concurrent engineering
コンカレントエンジニアリング
Configuration control
コンフィギュレーション・コントロール
Configuration management
Congress
コンフィギュレーション・マネジメント
議会（米国）
Constraints
制約
Contingency planning
緊急計画
Continuous Acquisition and Life-Cycle Support (CALS)
連続調達・ライフサイクル支援
Control gates
コントロール・ゲート
- 247 -
Cost
コスト（life-cycle cost も参照）
account structure
caps
∼計算構成
∼キャップ（上限）
estimating
∼見積り（予測）
fixed vs variable
in trade studies
operations
overruns
固定対可変∼
トレード研究における∼
運用∼
∼繰り越し
spreaders
Cost-effectiveness
∼延べ払い
コスト（費用）効果
in trade studies
トレードオフ研究における∼
Cost Estimating Relationship (CER)
コスト推定関連性
Cost/Schedule Control System (C/SCS)
Critical Design Review (CDR)
詳細設計審査
Critical Item/Issue List (CIL)
Critical path
重要アイテム／問題リスト
クリティカルパス
Decision analysis
意思決定解析
Decision Sciences
意思決定学
Decision support package
Decision trees
Design-for-X
意思決定支援パッケージ
意思決定樹形図
Design engineer(ing)
設計技術者（設計技術）
X 向け設計
Design reference mission
Design-to-cost
設計標準ミッション(reference mission を参照）
デザイン・ツー・コスト（design-to-life-cycle cost を参照）
Design-to-life-cycle cost
Design trades
Digraphs
コスト／スケジュール管理システム
デザイン・ツー・ライフサイクルコスト
設計トレード（trade studies を参照）
ダイグラフ
Discounting
割引（present discounted value を参照）
Earned value
収益額
Effectiveness
効果
facets of
in TPM
各種∼面
TPM（技術的性能測定）における∼
in trade studies
トレード研究における∼
Engineering Change Request (ECR)
技術変更要求書（change request を参照）
- 248 -
Engineering specialty disciplines
in concurrent engineering
in SEMP
各種専門工学分野
コンカレントエンジニアリングにおける∼
SEMP（システムエンジニアリング・マネジメント計画）における∼
in trade studies
トレード研究における∼
Environmental Assessment (EA)
環境アセスメント
Environmental Impact Statement (EIS)
Estimate at Completion (EAC)
Event trees
環境影響報告書
完成見積り
事象樹形図
Failure Modes and Effects Analysis (FMEA)
故障モード・影響解析
（Failure Modes, Effects, and Criticality Analysis を参照）
Failure Modes, Effects, and Criticality Analysis (FMECA)
故障モード影響及び致命度解析
Fault avoidance
故障回避
Fault tolerance
故障許容範囲
Fault tree
Feasibility
故障樹形図
実現可能性
Feasible design
実現可能な設計
Figure of merit
メリット数
Flight Readiness Review (FRR)
"Freedom"
飛行準備審査
「フリーダム」（Space Station "Freedom" を参照）
Functional Configuration Audit (FCA)
機能コンフィギュレーション監査
Functional Flow Block Diagram (FFBD)
機能流れブロック図
Functional redundancy
"Galileo"
機能冗長性
木星探査機「ガリレオ」
Game theory
ゲーム理論
Gantt chart
ガント・チャート
Goddard Space Flight Center (GSFC)
Hazard rate
Heisenberg
ハザード率
ハイゼンベルク（uncertainty principle を参照）
"Hubble" Space Telescope
IEEE
ゴダード宇宙飛行センター
「ハッブル」宇宙望遠鏡
電気電子学会
Improvement
改良
- 249 -
continuous
連続∼
product or process
製品または製法の∼
Independent Verification and Validation (IV&V)
Inflation, treatment of
独立した検証及び妥当性確認
インフレ、∼の処理
Institutional Operating Plan (IOP)
行政機関運用計画書
Integrated Logistics Support (ILS)
総合ロジスティックス支援
concept
plan
∼概念
∼計画
Integration
統合化
conceptual
system
Interface
概念の∼
システム∼
インタフェース
requirements
control of
∼要求（事項）
∼の制御
Jet Propulsion Laboratory (JPL)
ジェット推進研究所
Johnson Space Center (JSC)
ジョンソン宇宙センター
Kennedy Space Center (KSC)
ケネディ宇宙センター
Learning curve
学習曲線
Lesson Learned
教訓
"Lexicon", NASA
「略語集」、NASA∼
Life-cycle cost
ライフサイクル・コスト（cost も参照）
components of
controlling
Linear programming
∼の諸項目
∼の管理
線形計画（法）
Logistics Support Analysis (LSA)
ロジスティックス支援解析
Logistics Support Analysis Record (LSAR)
Lunar Excursion Module (LEM)
Maintainability
保全性
concept
∼概念
definition of
models
Maintenance
月探査船
∼の定義
∼モデル
保守（整備）
- 250 -
ロジスティックス支援解析記録
plan
∼計画
time lines
Make-or-buy
Margin
∼タイムライン
製造か購入か
余裕
Marshall Space Flight Center (MSFC)
handbooks
マーシャル宇宙飛行センター
∼ハンドブック
historical cost models
Material Review Board (MRB)
∼の経時的コスト・モデル
再審委員会
Mean Time Between Failure (MTBF)
Mean Time To Failure (MTTF)
平均故障間隔
平均故障時間
Mean Time to Repair (or Restore) (MTTR)
Metric system
平均修理（または回復）時間
メートル法
conversion factors for
∼の換算係数
definition of units in
∼における各種単位の定義
Military standards
Mission analysis
米陸軍標準規格
ミッション解析
Mission assurance
ミッション保証
Mission Needs Statement (MNS)
Models, mathematical
ミッション・ニーズ報告書
モデル、数学的∼
characteristics of good
cost of
∼のコスト
of effectiveness
Markov
適正な∼の特性
効果∼
マルコフ∼
pitfalls in using
programming
∼使用時の落とし穴
プログラミング∼
relationships to SEMP
types of
∼と SEMP の関連性（関係）
∼のタイプ（種類）
use in systems engineering
Monte Carlo simulation
モンテカルロ・シミュレーション
Multi-attribute utility theory
Network schedules
多属性有用性理論
ネットワーク・スケジュール
Non-Advocate Review (NAR)
NASA Handbook (NHB)
非支持者審査
NASA ハンドブック
NASA Management Instruction (NMI)
Nuclear safety
システムエンジニアリングにおける∼の使用
NASA 管理手引書
原子力安全性
- 251 -
Objective function
目的関数
Objectives, of a mission, project, or system
目的、ミッション、プロジェクト、またはシステムの∼
Office of Management and Budget (OMB)
Operations concept
運用概念
Operations research
Optimization
オペレーション・リサーチ
最適化
Optimum repair level analysis (ORLA)
Orbital Replacement Unit (ORU)
Outer Space Treaty
Partitioning
軌道交換ユニット
パラメータによるコスト見積り（予測）
細分化（interfaces を参照）
ペイロード
classification
nuclear
PERT
最適修復規準分析
宇宙条約
Parametric cost estimation
Payload
行政管理予算局
∼分類法
原子力∼（nuclear safety を参照）
プログラム評価及び審査手法
Physical Configuration Audit (PCA)
Precedence diagram
物理的コンフィギュレーション監査
順位図
Preliminary Design Review (PDR)
Present Discounted Value (PDV)
基本設計審査
現行割引価格
Probabilistic Risk Assessment (PRA)
Probability distribution
確率分布
Problem/Failure Reports (P/FR)
Producibility
問題／故障報告書
製作性
models
Producing system
∼モデル
生産システム（product system と峻別する）
Product Breakdown Structure (PBS)
Product development process
Product improvement
製品明細構成（図）
製品開発プロセス
Product development teams (PDT)
Product system
確率的リスク評価
製品開発チーム
製品改良
製品システム
Program, level of hierarchy
Program/project control
プログラム、∼階層レベル
プログラム／プロジェクト・コントロール（管理）
Program Operating Plan (POP)
プログラム運用計画書
- 252 -
Project
プロジェクト
level of hierarchy
management
plan
∼階層レベル
∼マネジメント（管理）
∼計画
termination
Project life-cycle
NASA
∼停止
プロジェクト・ライフサイクル
NASA の∼
technical aspect of
Protoflight
Prototype
Quality
∼の技術面
プロトフライト
プロトタイプ
品質
of systems engineering process
as a facet of effectiveness
Quality Assurance (QA)
Red team
一効果面としての∼
品質保証
Quality Function Deployment (QFD)
Queueing theory
システムエンジニアリング・プロセスの∼
品質機能配備
待ち行列理論
レッド・チーム
Reference mission
Reliability
標準ミッション
信頼性
block diagrams
∼ブロック図
definition of
∼の定義
in effectiveness
engineering
models
in TPM
Requirements
∼工学
∼モデル
in SEMP
Reporting
効果の∼
SEMP の∼
TPM の∼
報告（status reporting and assessment を参照）
要求（事項、条件）
allocation of
analysis
∼の配分
∼解析
as part of the baseline
documentation
ベースラインの一部としての∼
∼文書
functional
機能∼
interface
インタフェース∼
- 253 -
margin
余裕∼
performance
性能∼
reviews
∼審査
role of
∼の役割
software
ソフトウェア∼
specialty engineering
専門工学∼
traceability
∼トレーサビリティ
verification
∼検証
Reserves
余裕
project
プロジェクトの∼
schedule
スケジュールの∼
Resource leveling
経営資源レベル
Resource planning
経営資源計画（budgeting を参照）
Risk
リスク
analysis
∼解析
aversion
∼回避
identification and characterization
management
∼マネジメント
mitigation
∼軽減化
templates
∼テンプレート
types of
∼のタイプ（種類）
Safety reviews
Scheduling
安全性審査
スケジュール（作成）
S-curve, for costs
S 曲線、コストの∼
Selection rules, in trade studies
Simulations
SOFIA
Software
∼の識別と特性表示
選定規準、トレード研究における∼
シミュレーション
赤外線天文学成層圏観測施設
ソフトウェア
cost estimating
in WBS
∼コスト見積り（予測）
WBS における∼
off-the-shelf systems engineering
Source Evaluation Board (SEB)
Space Shuttle
既成システムエンジニアリング∼
ソース評価委員会
スペースシャトル
Space Station "Alpha"
Space Station "Freedom"
宇宙ステーション「アルファ」
宇宙ステーション「フリーダム」
- 254 -
Specialty disciplines
Specifications
専門分野（engineering specialty disciplines を参照）
仕様（書）
Status reporting and assessment
状態報告及び評価
Successive refinement, doctrine
連続改良、∼主義
Supportability
risk
支援性（Integrated Logistics Support を参照）
∼リスク
Symbolic information
記号情報
desirable characteristics of
in systems engineering
システムエンジニアリングにおける∼
System Acceptance Review (SAR)
System architecture
System engineer
システム受領審査
システム・アーキテクチャ
システムエンジニア
role of
∼の役割
dilemma of
∼のジレンマ
System management
システム・マネジメント（project management を参照）
Systems analysis, role of
Systems approach
∼の望ましい特性
システム解析、∼の役割
システム方式
Systems engineering
objective of
システムエンジニアリング
∼の目的
metrics
∼評価指標
process
∼プロセス
Systems Engineering Management Plan (SEMP)
システムエンジニアリング・マネジメント計画書
Systems Engineering Process Improvement Task (SEPIT)team
システムエンジニアリング・プロセス改良業務（SEPIT）チーム
Systems Engineering Working Group (SEWG)
Taguchi methods
Tailoring
システムエンジニアリング作業グループ
タグチメソッド
調整
of configuration management
by each field center
コンフィギュレーション・マネジメントの
各フィールドセンターによる∼
of effectiveness measures
効果測定値の∼
of product development teams
製品開発チームの∼
of project cycle
プロジェクト・サイクルの∼
of project plans
プロジェクト計画の∼
of project reviews
プロジェクト審査の∼
- 255 -
of project hierarchy
of risk management
of SEMP
プロジェクト階層の∼
リスク・マネジメントの∼
SEMP の∼
of systems engineering process metrics
システムエンジニアリング・プロセス評価指標の∼
of verification
検証の∼
Technical Performance Measure(ment) (TPM)
assessment methods for
技術的性能測定
∼の評価方法
relationship to effectiveness measures
relationship to SEMP
∼と SEMP の関連性（関係）
role and selection of
Test(ing)
∼の役割と選定方法
試験（verification も参照）
Test Readiness Review (TRR)
試験準備審査
Total Quality Management (TQM)
Trade study
総合的品質マネジメント
トレードオフ研究
in ILS
ILS の∼
process
∼プロセス
in producibility
生産性の∼
progress as a metric
評価指標としての∼の進捗度
in reliability and maintainability
reports
検証における∼
トレード樹形図
Uncertainty, in systems engineering
Uncertainty principle
Validation
信頼性と保全性の∼
∼報告書
in verification
Trade tree
∼と効果測定の関連性（関係）
不確定性、システムエンジニアリングの∼
不確定性原理
妥当性確認（有効性の確認）
Variances, cost and schedule
Verification
偏差、コストとスケジュールの∼
検証
concept
∼概念
methods
∼方法
relationship to status reporting
reports
∼報告書
requirements matrix
stages
∼と状態報告の関連性（関係）
∼要求事項マトリックス
∼の各種段階
- 256 -
Waivers
ウェーバー
Weibull distribution
ワイブル分布
Work Breakdown Structure (WBS)
development of
errors to avoid
example of
∼の作成
∼における回避すべきエラー
∼例
and network schedules
Work flow diagram
作業明細構成（図）
∼とネットワーク・スケジュール
作業フローチャート
- 257 -

人類として初めて月面に降り立った アームストロング宇宙飛行

アストロバイオロジーセンター開所式 センター長挨拶

情253 「ディジタルシステム設計 」 （1）DigsysIntro1

小型衛星を用いた準リアルタイム地球観測システムの検討

英語熱が高まる新連載を一挙掲載『イングリッシュ・ジャーナル』4月号発売。

787kb - 帝京大学中学校・高等学校

レーザベースのリモートセンサは 複数の方法で他の天体をプローブ world