サルでもわかるNASA式システム開発

SARU NASA System GUIDE サルでもわかるNASA式システム開発

SARU NASA System GUIDE 01

はじめに 1995年に発行された“NASA Systems Engineering Handbook” という本があります。 このハンドブックは、NASAが宇宙開発のプロジェクトを進める上で、重要だと考えていること が記述された、システムデザインに携わるエンジニアにとってはバイブルのような本です。 宇宙開発に限らず、システムデザインに役立つノウハウが満載なのですが、日本では、ほとんど 読まれていないと思います。 とても勿体ないことなので、エッセンスを抜き出して、宇宙開発に馴染みが薄い方にも読み やすいように、1話ごとに紹介していく形式で、「サルでもわかるNASA式システム開発」と してまとめました。 C o n t e n t s 1 . システムのジレンマ 2 . 理想なき者に計画なし 3 . ガントチャートには早すぎたんだ 4 . システムを知る者は勝ち、知らざる者は勝たず 5 . 優れたシステムズエンジニアがやっていること 6 . ア ポロ計画とシステムズエンジニアリング 7 . システムを見定め、決める 8 . ゴール指向なウォーターフォール・モデル 9 . 良い分割が良いシステムを生み出す 02

1 . シ ステムのジレンマ 「相手に自分のぬくもりを 伝えたいと思っても、 身を寄せれば寄せるほど 体中のトゲで お互いを傷つけてしまう。 人間にも同じことが言えるわ。」 新世紀エヴァンゲリオンの第参話で、赤木リツコ博士が「ヤマアラシのジレンマ」の話をしています。 システム設計にも、そんな悲しいジレンマがあります。 製品やサービスを作っていく上で、パフォーマンス（品質、性能）、コスト、リスクは、常に高い関心ごとです。 パフォーマンスはなるべく高くしたい一方で、コスト、リスクはなるべく低く抑えたい。 その願望は常に打ち砕かれることになります。 ヤマアラシが付かず離れずの距離に落ち着くように、システムもパフォーマンス、コスト、リスクがバランスを取る ところに落ち着きます。 NASAのハンドブックでは、システムズエンジニアのジレンマ*1として、次のように説明されています。 • 一定のリスクで、コスト*2を削減するには、パフォーマンスを低下させる必要があります。 • 一定のコストでリスクを軽減するには、パフォーマンスを低下させる必要があります。 • 一定のパフォーマンスでコストを削減するには、より高いリスクを受け入れる必要があります。 • 一定のパフォーマンスでリスクを軽減するには、より高いコストを受け入れる必要があります。 03

【システムズエンジニアのジレンマ】 パフォーマンス コスト削減のためには リスク削減のためには パフォーマンス低下 パフォーマンス低下 コスト コスト削減のためには リスク 高いリスク 【パフォーマンスが一定の場合】 【コストが一定の場合】 【リスクが一定の場合】 パフォーマンス パフォーマンス ハイリスクで ハイコストで パフォーマンス 良いならば 良いならば パフォーマンスを パフォーマンスを ハイリスクで ローリスクを 向上できる 向上できる 良いならば 求めるならば コスト削減できる コスト削減はできない ローリスクを ローコストを コスト リスク コスト 求めるならば リスク コスト 求めるならば リスク パフォーマンスを パフォーマンスを 向上できない 向上できない 例えば、ハイリスク・ハイリターンで 同様に、パフォーマンスを向上させる また、リスクを取ることなく、パ 良いならば、コスト削減はできます こととリスクを減らすことは、共に フォーマンスの向上とコスト削減を が、ローリスク・ハイリターンを求め コストを消費するので、コストを固 両立させることはできません。 るならば、コスト削減はできません。 定してしまうと綱引きになります。 叶う願いは3つではなく、2つまでなのです。 冷静さを失って、このジレンマを忘れた意思決定をしてしまうプロジェクトは実は多いのではないでしょうか。 （そしてプロジェクト末期にその意思決定が間違っていたことに気がつく） かくいうNASA自身でさえ、”Faster, Better, Cheaper”（ より早く、より良く、より安く）というスローガンを 掲げていたことがありました。*3 3つを共存させることは不可能ではありませんが、非常に困難であり、ゲームのルールを変えるような革新的な 発想が必要になります。 *1:今回の話では同時に満たせない性質が２つではなくて３つあるので、正確にはジレンマではなくてトリレンマですね。 *2:時間（スケジュール）は、コストの一種だと扱っています。 *3:このスローガンは失敗だったという議論も多くある一方で、ルナ・プロスペクターのような成功事例もあるため、一概に間違っていたとも言えません。 04

2 . 理想なき者に計画なし 「夢なき者に理想なし、 理想なき者に計画なし、 計画なき者に実行なし、 実行なき者に成功なし。 故に、夢なき者に成功なし。」 教育者・吉田松陰 幕末の志士に大きな影響を与えた教育者、吉田松陰の言葉です。 「計画なき者に実行なし」ということで、製品開発の現場で は、開発計画が必ず作られますが、そこで登場するのが、 ガントチャートです。 ヘンリー・ガント氏が生み出して以来、100年以上にも渡り、 ガントチャートは様々な現場で使われて来ましたが、多くの マネージャ、エンジニアに失敗体験も与えてきました。 ガントチャートによる管理がうまくいかない主な理由は、 作業に抜け漏れがあることと作業の見積が不正確である ことです。 NASAでは、どのように考えているのか見てみましょう。 ガントチャートの例（旧NASA SE Handbookより） プロダクトを生み出すための技術面での計画を、NASAでは、技術計画（Technical Plan）と呼んでいます。 The Technical Planning Process, the first of the eight technical management processes contained in the systems engineering engine, establishes a plan for applying and managing each of the common technical processes that will be used to drive the development of system products and associated work products. This process also establishes a plan for identifying and defining the technical effort required to satisfy the project objectives and life cycle phase success criteria within the cost, schedule, and risk constraints of the project. 05

最初の文で述べていることは、プロダクトの開発に必要な作業を洗い出し、着実に実行できる計画を立てましょう ということで、至極当たり前のことです。 次の文で述べられていることが非常に大切です。 必要な技術的作業を特定し、定義するための計画も確立 つまり、プロジェクトの初期の段階では、何をすべきかを完全に洗い出すことは不可能なので、「必要な技術的作業 を特定する」ための計画も一緒に立てるべしと述べています。 吉田松陰の言葉を思い出してください。 理想なき者に計画なし システム（プロダクト）のあるべき姿が見えないと、実行性のある計画は立てられません。 そこでNASAでは、Pre-Phase Aという段階を設け、「システム（プロダクト）のあるべき姿」を追求することを開発 計画に含めることを推奨しています。 Pre-Phase Phase A Phase B Phase C Phase D Phase E Phase F コンセプト検討 コンセプト開発 基本設計 最終設計・製造 システム統合・ 運用・保守 運用終了 試験・打ち上げ NASAのシステムライフサイクルモデル 上の図のように、NASAでは、システムの一生（システムライフサイクル）を7つの段階に分けています。*1 再び、ハンドブックの言葉を参照してみます。 This effort starts with the technical team conducting extensive planning early in Pre-Phase A. With this early planning, technical team members will understand the roles and responsibilities of each team member, and can establish cost and schedule goals and objectives. 宇宙開発らしいところで、最初はトップダウンで役割と責任を明確化し、その上で各チームメンバーが動き出す ことになります。 From this effort, the Systems Engineering Management Plan (SEMP) and other technical plans are developed and baselined. Once the SEMP and technical plans have been established, they should be synchronized with the project master plans and schedule. In addition, the plans for establishing and executing all technical contracting efforts are identified. 初期の段階では、プロジェクトの都合は一旦置いておき、システムに焦点を当てた計画を立てます。 それをシステムズエンジニアリング管理計画や技術計画と呼んでいます。 しかし、それだけでは、プロダクトの完成が遅すぎたり、コストがかかりすぎてしまうので、要所要所で、プロジェクト 全体のゴールやスケジュールと同期をとります。 つまり、プロジェクトマネジメント活動とシステムズエンジニアリング活動は、プロダクトを成功裏に生み出すため の前輪と後輪になっているわけです。 「ガントチャート」という言葉を聞くと、プロジェクトマネー ジャーの仕事というイメージが強いかもしれませんが、実際に は、エンジニアの仕事があってはじめて、実効性のある計画 システムズ プロジェクト エンジニアリング マネジメント を立てることができます。 活動 活動 *1:JAXAも同じような方式で衛星開発を行っています。 プロジェクトマネジメントとシステムズエンジニアリング活動は協調する 06

3 . ガ ントチャートには早すぎたんだ 「腐ってやがる・・・ 　　　　 早すぎたんだ」 映画「風の谷のナウシカ」でトルメキア帝国の軍参謀クロトワが朽ちていく巨神兵の姿を見て発した言葉です。 ガントチャートも同様で、成熟前に目覚めさせると、せっかくの大作も崩れ落ちていきます。 腐らない計画を作るためには、どうしたら良いのでしょうか？ 技術計画づくりのコツもNASAのハンドブックに載っています。 原文のままだと少し難しいので、意訳して転載します。 1. ガントチャート的な計画を立てる前に、プロダクトのあるべき姿を表した樹形図（P r o d u c t B r e a k d ow n S t r uc t u r e）を描けるくらいまで、時間をかけてプロダクトに対する理解を深めましょう。技術の開発と検証に 必要な時間を見積り、作業の依存関係を明確にし、設備や予算などのリソースの制約をリストアップして、計画を 立てるために必要な情報を整理しましょう。 2. プロダクトを分割し、分担して開発が進められるように、分割の境界（インターフェース）を明確にしましょう。 インターフェースを修正しないといけないときの対処法も合わせて決めておきましょう。 3. 何かを変更しないといけないときに、その変更の影響範囲がどの程度なのかを理解するために、チームの中で 合意されているプロダクトの情報（コンフィギュレーション）を管理しましょう。 4. 重要かつ価値ある指摘を集められる様に、マイルストーンになるレビューを実施しましょう。レビューは、通過 儀礼的に行えば良いものではなく、実施の基準を満たした時のみ、実施されるものであるべきです。 5. 分析結果に影響を与えるバイアス、仮定、および制約を理解しましょう。 6. 状況の変化に対して、分析結果の見直しと分析のやり直しをいつするべきかを把握できるように、すべての分析は、 コンフィギュレーション管理の下に置きましょう。 07

このうち、特に大切なのが、「PBS (Product Breakdown Structure)」と「コンフィギュレーション」です。 PBSは、プロダクトを要素に分解したものです。 自転車 例えば自転車を例にとると、下図のようになります。 自転車の要素に分解するためには、まず 駆動部 操作部 フレーム オプション 自転車の機能を理解する必要があります。 ペダル ハンドル ライト また、機能を定義するには、自転車に対する 要求や規制、ユーザーの使い方に対する 理解が必要です。 ギア ブレーキ 荷物カゴ つまり、様々な視点からプロダクトを眺 タイヤ チャイルド め、理解しなければ、プロダクトを要素に シート 分割することはできず、PBSを描くことはできません。 この時重要となってくるのが、システム思考です。 要求 そして、ガントチャートの一列目に並ぶ作業の同期ポ イントは、多くの場合、PBSの要素を統合するタイミン システム グになります。 したがって、ガントチャートを正しく作 機 るためには、プロジェクトマネージャーがリソースや 能 運用 コストに頭を悩ませるだけでなく、PBSが必要になり ます。なお、システム思考については、レヴィのWEB 様々な視点でシステムを観る サイトでも解説しているので、興味のある方はそちら も合わせてご覧ください。 コンフィギュレーションという言葉は、宇宙開発特有 かもしれません。プロジェクトを進めていくと、「どれ が最新の要求リストなんだ？」や「この設計情報には 最近の仕様変更が反映されているのだろうか？」と いった疑問を持つことが少なくないと思いますが、こ れが「コンフィギュレーションが管理されていない」状 態です。プロダクト開発に関わる全ての人が拠り所に できる、合意され、管理されている設計情報の集まり のことをコンフィギュレーションといいます。 技術的なベースラインの進化（NASA SE Handbookを元にレヴィが作成） コンフィギュレーションの管理についても、ハンドブックには説明があるのですが、長くなるので、それは別の機会 に回します。重要なのは、上のコツにもあるように、コンフィギュレーションを管理することで、何か変更が生じたと きに、その影響範囲を迅速に分析できるようになることです。 刻一刻と状況が変化するときこそ、コンフィギュレーション管理という、腰を重くするような活動が重要になるとい うのは、面白いものですね。このように、NASAのSystems Engineering Handbookには、プロジェクトを走ら せるための様々な含蓄が随所に述べられています。 ガントチャートを引く前に、プロダクトのことを理解するための時間を十分に確保しましょうというのは、宇宙開発 以外でも有効なやり方なのではないかと思います。 08

4 . シ ステムを知る者は勝ち、 　 知らざる者は勝たず 「これを知る者は勝ち、 知らざる者は勝たず。」 孫武 孫子の兵法にこんな言葉があります。 敵と味方のことをよく知ることが、戦いに勝つ上で重要だと。 システムデザインも一種の戦いであり、「プロダクトやサービスのことをよく知ること」が大切です。 プロジェクトの総コストは、設計の段階で8割近くが固定化されると言われています。 下の図は、模式的なものですが、NASAのプロジェクトにおいて、各ステージでどれくらいのコストが確定し、 また実際に費やされるのかを表現しています。 例えば、設計ステージでは、コスト（リソース）の 15%が費やされるだけですが、この段階で全体 のコスト（ライフサイクルコスト）の75%が決まり ます。 なぜなら、システムの設計方法によって、 テスト、製造、統合、運用、および維持にかかる 費用が決まるからです。 逆に、これらのコストが 決まっていなかったとしたら、後半のステージに おいて、重大なコストリスクが発生します。 後半のステージになると、設計変更のコストが 増加することにも注意が必要です。 もし、初期の ステージでテストや分析を一切行なわず、検証 ステージではじめて問題を発見するという状況 になった場合、再設計と再検証に多大なコストが ライフサイクルコストに対する各開発段階での意思決定の影響 かかることになります。 09

また、別の資料からの引用になってしまいますが、NASAのプロジェクトを調べると、初期段階での設計活動に時間 を費やす方が、コスト超過やスケジュール遅延を防げているという結果が出ています。 NASAのWerner Gruhl氏*1が1970-80年代に実施された32の主要プロジェクトを分析したところ、ほとんどの プロジェクトが初期段階（プロジェクトを定義する段階）で10%未満のリソースしか費やさず、その結果、ほとんどの 場合において40％を大幅に超えるコスト超過が発生していました。 この研究の結果、設計フェーズで15%程度のリソースを割くのが理想的だということが分かり、今日のプロジェク トでは、プロジェクトを定義する段階に十分な時間を費やすようになりました。*2 これをレヴィ式に表現すると、システムデザインをきちんとやると、プロジェクトのQCD*3が向上するということに なります。 NASAのプロジェクトでは、設計フェーズで15%程度のリソースを割くのが理想的と言われていますが、プロダクトや サービスの性質によって、この比率は変わってきます。 レヴィでは、様々なプロダクトやサービスに適したシステムデザインのノウハウを「システミングのKATA」として 整理し、活用しやすい形で提供することを行なっています。 しかし、そうは言っても、ブラックスワン的な出来 事がプロジェクトの後半で起きて、スケジュール の遅延やコスト超過が生じることもあるという 事例を紹介します。 気象衛星NOAA N-PRIMEの開発では、試験中 に衛星が横転して、損傷するという事故が起きま した。 作業員が衛星を固定していたボルトを取り外し たことを記録せず、また別の作業員はボルトが あることを確認せずにカートを動かしてしまい、 数百億円かけて開発した人工衛星がまさかの横転。 気象衛星NOAA N-PRIMEの横転事故 衛星の修理費用は1億3500万ドルもかかった そうです。 戒めとして、人工衛星開発の中で、よく紹介される失敗事例です。この事例は徹底的に調査され、詳細なレポート*4 も出ています。作業員のミスといった表面的な話に止まらず、「なぜこのようなミスが起きたのか」という本質的な 原因を考えるのがNASAの偉いところだと思います。このような失敗の蓄積が、NASAのハンドブックの元になっ ています。 *1:Eric C. Honour, Understanding the Value of Systems Engineering, 2014 *2:NASA Assessments of Major Projects, 2018 *3:QCDは、Quality（品質）、Cos（t コスト）、Delivery（納期）の頭文字で、生産管理やプロジェクトマネジメントにおいて重視される指標です。 *4:NOAA N-Prime Mishap Investigation Final Report, 2004 10

5 . 優れたシステムズエンジニアが 　 やっていること 「“知略” 対“ 本能”！ これは武将の中の 永遠の題目ですよォ」 漫画「キングダム」で、王騎将軍が武将のあり方について語っています。 作中では、「知略」に優れた将軍もいれば、傑出した「本能」を持つ将軍もいます。「 知略型」や「本能型」という分類が できるということは、成果を上げる将軍が共通して持っている「行動特性」があるということです。 例えば、「本能 型」の将軍は、戦の中で「起こり」を感知するという特性を持っています。*1 優れたシステムズエンジニアには、どのような行動特性があるのでしょうか？ NASAには、コンピテンシーモデルというものがあります。「 コンピテンシー」は行動特性などと訳され、職務の 中で優れた業績を発揮することに結びつく個人特性のことを指す言葉です。 噛み砕くと、「優秀な人が共通してやっていること」と言えます。 NASAでは、コンピテンシーモデルは、マネージャーのトレーニングの基盤として用いられています。 コンピテン シーを定期的に確認および評価することで、スキルのギャップがどこに存在し、スキルギャップを埋めるためどの ような対処を行う必要があるかを判断しやすくなると言われています。 Competency Model ¦ APPEL Knowledge Services*2というサイトでは、プロジェクトマネージャーとシス テムズエンジニア向けのコンピテンシーエリアと、両方の分野に関わる一般的なコンピテンシーエリアについて 説明されています。 NASAのコンピテンシーモデルによると、システムズエンジニア向けのコンピテンシーは17個あり、3つの領域に 分類されています。 11

SE 1.0 システムデザイン SE 1.1 SE 1.2 SE 1.3 SE 1.4 利害関係者の 技術要求定義 論理分解 設計ソリュー 期待の定義と ション定義 マネジメント SE 2.0 プロダクトの実現 SE 2.1 SE 2.2 SE 2.3 SE 2.4 SE 2.5 プロダクトの プロダクトの プロダクトの プロダクトの プロダクトの 実装 統合 検証 妥当性確認 移行 SE 3.0 技術マネジメント SE 3.1 SE 3.2 SE 3.3 SE 3.4 SE 3.5 技術計画 要求マネジメ インターフェ 技術リスクマ コンフィギュ ント ースマネジメ ネジメント レーションマ ント ネジメント SE 3.6 SE 3.7 SE 3.8 技術データマ 技術アセスメ 技術的な意思 ネジメント ント 決定解析 システムズエンジニアリングに関するコンピテンシーモデル 「SE 1.0 システムデザイン」のコンピテンシーは、利害関係者の期待を深掘りすること、技術的な要求を定義する こと、要求を分解すること、要求を検証すること、関係者の期待と要求を満たす設計ソリューションを定義すること です。 このような行動が、システムデザインにおける優れた成果に結びつきます。 「SE 2.0 プロダクトの実現」のコンピテンシーは、設計仕様と利害関係者の期待を満たすような、完成した対象 システムを提供することです。 プロダクトの購入、再利用、またはコーディングなどを行い、プロダクトを生産します。 また、設計仕様に対するプロダクトを検証や、利害関係者の期待に対するプロダクトの妥当性を検証します。 「SE 3.0 技術マネジメント」のコンピテンシーは、プロジェクトのライフサイクル中の技術活動の管理に尽きます。 各コンピテンシーの概要を表にまとめてみました。優れたシステムズエンジニアが暗黙のうちにやっていること です。少し言葉が難解ではありますが、全体像を掴めるかと思います。 *1「: キングダム」 606話に出てくるエピソードです。　　*2:https://appel.nasa.gov/career-resources/competency-model/ 12

SE 1.0 システムデザイン SE 1.1 利害関係者の期待の定義とマネジメント ユースケース、シナリオ、運用コンセプト、利害関係者の期待を顕在化します。利害関係者を特定し、コミットメント を引き出し、利害関係者が期待していることが何かを検証します。 SE 1.2 技術要求定義 ベースライン化された利害関係者の期待を、「～すること」のように表現された、設計ソリューションを定義する ために利用可能な技術要求に変換します。 SE 1.3 論理分解 技術要求を分解して、より下位のレベルのシステムの技術要求を導出します。導出された要求間の矛盾を解消し、 整合性を確立するためのシステムアーキテクチャを定義します。 SE 1.4 設計ソリューション定義 導出された要求を設計ソリューションに変換します。「作り出す」、「購入する」、「再利用する」という選択肢の 組み合わせを考え、要求を満たす様々な代替案の中から好ましいソリューションを見つけ出します。 SE 2.0 プロダクトの実現 SE 2.1 プロダクトの実装 購入し、作り出し、あるいは再利用することで、設計要求を満たすようなプロダクトを生み出します。 SE 2.2 プロダクトの統合 下位レベルの検証済みのプロダクトを組み合わせ、より上位のプロダクトである最終プロダクトにします。そのために、 プロダクトの統合戦略を準備し、詳細な計画を実行し、統合の準備ができていることを確認します。 SE 2.3 プロダクトの検証 要求に対して、最終プロダクトが適合していることを証明します。そのために、検証作業の準備、検証結果の分析、 プロダクトの適合性を証明するレポートの準備を行います。 SE 2.4 プロダクトの妥当性確認 最終プロダクトが利害関係者の期待を満たし、検証中に発見された異常が適切に解消されていることを確認します。 そのために、妥当性確認の準備、確認結果の分析、利害関係者の期待と合致していることを証明する妥当性確認 レポートの準備を行います。 SE 2.5 プロダクトの移行 検証され、妥当性が確認されたプロダクトを顧客へ届けます。プロダクトの引き渡しを実施するための準備、評価、 プロダクトの付随する必要な文書の作成を行います。 13

SE 3.0 技術マネジメント SE 3.1 技術計画 プロジェクトの目的達成に必要となる技術的な作業の特定、定義、計画立案と共に、技術プロセスのマネジメント と適用を計画します。各技術的な作業の成果物を明確し、レビューの開始条件や成功基準の特定を行います。 システムズエンジニアリングマネジメント計画（SEMP)やその他の技術的な計画を準備し、利害関係者のコミット メントを得ます。 SE 3.2 要求マネジメント 双方向のトレーサビリティの確保、プロダクトライフサイクル上の要求のベースラインを確立するための履歴 管理などを行い、プロダクトの要求のマネジメントを行います。 SE 3.3 インターフェースマネジメント 最終的なプロダクトと周辺プロダクトの間の内部および外部インターフェースの定義とコンプライアンスを維持 するために、正式なインターフェースマネジメントを確立し、利用します。 SE 3.4 技術リスクマネジメント 計画から技術的なギャップのあるリスクを調査し、それが発生する前に潜在的な技術的課題を特定します。技術 的な目標達成への影響を軽減するために、プロジェクトのライフサイクル全体にわたって、必要なリスクへの 対処を行います。 SE 3.5 コンフィギュレーションマネジメント プロダクトの要素間の整合性やトレーサビリティを維持し、ライフサイクルを通じてプロダクトの構成（コンフィ ギュレーション）の履歴を管理し、様々の時点でのコンフィギュレーションを特定します。 SE 3.6 技術データマネジメント ライフサイクルを通じて、プロダクトに関連するデータを識別子、制御します。技術的なデータの管理戦略とポリ シーを確立し、保存された技術データのリビジョン、ステータスと履歴、および関連するメタデータを維持します。 SE 3.7 技術アセスメント 技術的な作業の進捗状況を監視し、システムデザイン、プロダクトの実現、技術マネジメント作業をサポートする ためのステータス情報を提供します。技術的な指標を追跡したり、プロダクトの品質を評価したり、レビューを 実施したりします。 SE 3.8 技術的な意思決定解析 技術的な意思決定の問題を評価し、判断基準を識別し、代替案を識別・分析・選択します。意思決定の候補案の 策定は、システムのライフサイクル全体を通して行われ、健全性と安全、技術、コスト、およびスケジュールの パフォーマンスへの影響が評価されます。 プロジェクトを成功させるには、たくさんのことをやらないといけないようですね。システムが複雑になると、 とても一人ではやりきれません。そこで、「チームでシステムデザインをする」という発想が大切になってきます。 そのためのフレームワークが「システミング」です。 14

6 . アポロ計画と 　 システムズエンジニアリング 「充分に終わりのことを考えよ。 まず最初に終わりを考慮せよ。」 レオナルド・ダ・ヴィンチ かの有名なレオナルド・ダ・ヴィンチの言葉です。 NASAは、これまで多くのビッグプロジェクトを成功させてきました。 その成功の秘訣は、「組織、コスト、技術、それらの相互作用のバランスを取ることに精通していることにある」と ハンドブックには書かれています。そのために、特に重要なことが、単一の専門的なビューではなく、システムの 幅広い横断的なビューを扱うことです。 全体像を描くことで、「正しく設計」できていることだけでなく、「正しいシステム」を作れていることを都度確認 することができ、巨大プロジェクトを成功に導くことができるというわけです。 NASAの成功の秘訣は、プロフェッショナルな協働を支える技術であり、その技術こそがシステムズエンジニア リングです。 NASAのハンドブックでは、「システムズエンジニアリング」は、システムの設計、実現、技術管理、運用、および廃棄 のための体系的で学際的なアプローチと定義されています。 “systems engineering” is defined as a methodical, multi-disciplinary approach for the design, realization, technical management, operations, and retirement of a system. NASAは、どういう経緯で「システムズエンジニアリング」に着目しはじめたのでしょうか？ 大きな転機は、アポロ計画にあると言われています。 15

アポロ計画は、云わずと知れた、米国の有人月着陸計画です。 1961年5月25日，ケネディ大統領は、上下両院合同議会で次のような演説をしました。 「まず私は、今後10年以内に人間を月に着陸させ、安全に地球に帰還させるという目標の達成に我 が国民が取り組むべきと確信しています。この期間のこの宇宙プロジェクト以上に、より強い印象を 人類に残すものは存在せず、長きにわたる宇宙探査史においてより重要となるものも存在しないこと でしょう。そして、このプロジェクト以上に完遂に困難を伴い費用を要するものもないでしょう。」 そして、この宣言通り、1969年7月20日、宇宙飛行士ニール・アーム ストロングおよびバズ・オルドリンがアポロ11号で月面へ着陸しま した。 部品点数は400万点を超え、電線の総延長は60キロメートル、設計 図面は10万枚にもおよび、ピーク時の従業員数は40万人という、 人類史上類を見ない巨大プロジェクトでした。 1969年7月20日，アポロ11号が月面に着陸 実は、NASAという機関ができたのは、ケネディ大統領の演説の少し 前（1958年）であり、アポロ計画当時は、まだまだ前身の各研究セン ターの文化が色濃く残っていたそうです。 アポロ計画では、主に3つのセンターが役割を分担していました。 •有人宇宙船センター（後のジョンソン宇宙センター）：アポロ宇宙船の開発 司令船 •マーシャル宇宙飛行センター：サターンV型ロケットの開発 •ケネディ宇宙センター：ロケット打ち上げ作業 NASAの各センターは、それぞれの組織母体の伝統に根ざした技術 文化をもっていましたが、各センターが協働しない限り、この巨大 プロジェクトを成功させることはできません。 月着陸船 そこで、各センターの技術プロセスに対する管理を強化するため、 形式化・規格化された技術手法の導入を推進しましょうということ で、システムエンジニアリングに白羽の矢が立ちました。 このあたりのストーリーは、佐藤 靖氏の著書「NASAを築いた人と 技術」に詳しく書かれています。 サターンVロケット 16

特に面白い文化を持っていたのは、ヴェルナー・フォン・ブラウン（Wernher von Braun）が率いたマーシャル宇宙飛 行センターです。中核メンバーは、100名強のドイツ出身の技術者たちでした。ドイツ時代からの長きに渡る協働から 来る、団結力のあるチームだったそうです。 フォン・ブラウンは、米国最初の人工衛星エクスプローラー1号を打ち上げたジュピターCロケット、アポロ計画の サターンVロケットの開発者であり、ロケット開発の歴史に名を残す人物です。 第2次世界大戦中はドイツでV2 ロケットを開発したことでも知られています。 彼は、こんな言葉を残しています。 良いチームはみな、、、 冷静な科学的言語では評価が難しい一定の性格をもっている。 良いチームには帰属の意識、誇り、そして集団で物事を成し遂げる気持ちがある。 自ら進んで取り組むという要素がそこにある。 良いチームは木や花のようにゆっくりと有機的に育つのでなければならない。 エンジニアらしい発想で、自律性と実践的経験を重んじ、過度な管理は しないという方針でした。 一方で、アポロ宇宙船計画室長であったジョセフ・シェイ（Joseph F. Shea）は、その対極に位置する方針を持っていました。 トップダウンで物事を進めることを好み、週間報告で自ら全てをコント ロールしていくことでアポロ計画を推進していきました。 毎週1000ページを超えるレポートに目を通し、フィードバックを返し ていたとか。 彼は、こんな言葉を残しています。 フォン・ブラウン 私は変更委員会を民主的プロセスで運営したことは一度 もなかった。 敬意を持って一言で表わすならば、極めて優秀な独裁者です。 このように、異なる文化・専門性を持つセンターが協力して、進めてい たのがアポロ計画でした。 どれかひとつの文化・やり方に統一することは難しい一方で、好き勝手 にやるわけにもいきません。 ジョセフ・シェイ 17

実際、計画の初期段階では、好き勝手にやって失敗を繰り返していたそうです。 そこで、プロフェッショナルな活動をつなぐ横串として、形式化・規格化された技術手法が必要だろうということで、 システムズエンジニアリングの体系化と活用が進められました。*1 当然のことながら、各センターの技術者たちの中には、反発もあったようです。 しかし、最終的には程よいバランスで、各センターにシステム全体の最適化や計画全体の整合性の維持を図る活動が 浸透し、アポロ計画は成功しました。 もちろん、フォン・ブラウンのような天才がうまくやった部分も多分にあるとは思いますが、アポロ計画を通じて、 各センター独自の技術文化とシステムズエンジニアリングが時に衝突、時に融合し、今日に至るNASAの技術基盤が 形成されていきました。 余談ですが、1969年当時のアポロ計画の技術者の平均年齢は26歳だったそうです。 若い！ 私が大阪府立大学で衛星開発を指導していたときの経験談なのですが、システムズエンジニアリングを導入すること で、若手に活躍のチャンスを適切に与えることができるという効果がありました。 最初の人工衛星を作ったときには、ある程度の経験を積んだ4年生や修士の学生が開発を担っており、低学年の学生は 手伝い程度で、責任ある仕事を任せられていませんでした。 しかし、現在では、システムズエンジニアリングの考え方が浸透しており、1年生から衛星開発の一端を担えるように なっています。これは、作ろうとしている人工衛星の全体像を明確にし、共有した上で、やるべきことを定義し、プロ ジェクトを進められるようになったからだと考えています。 ダ・ヴィンチの言葉の通り、「終わりの姿」を考えることからはじめているわけです。 *1:システムズエンジニアリング導入の背景には、技術的な必要性だけでなく、NASAには世論と議会への説明責任があり、予算やスケジュールの制約が 　 ある中で、月着陸という野心的な技術開発を進めていく必要があったということも色濃くあります。 18

7 . シ ステムを見定め、決める 「曇りなき眼で見定め、 決める！」 映画「もののけ姫」で、石つぶての秘密を調べ、その後どうするのかを問われたアシタカがエボシに向かって放った セリフです。 システムデザインにおいても、システムを曇りなき眼で見定め、決めることが大切です。 NASAのハンドブックでは、システムデザインのプロセスを4つに分けています。 • 利害関係者の期待の定義 (Stakeholder Expectat ions Def in i t ion) • 技術要求の定義 (Technica l Requi rements Def in i t ion ) • 論理分解 (Logical Decomposi t ion ) • 設計ソリューションの定義 (Des ign Solut ion Def in i t ion) これらのプロセスは、A→B→C→… というように順番に進むものではなく、相互に依存しており、反復的に行き来 するものです。 これらのプロセスが実行されることで、妥当性が確認された技術要求と、利害関係者の期待を満たす設計ソリュー ションを得ることができます。 19