この記事では、「サルでもわかるNASA式システム開発」ガイドブックのポイントを抜粋して紹介しています。全文をお読みになりたいかたはこちらから無料ダウンロードしていただけます。
「曇りなき眼で見定め、決める！」
映画「もののけ姫」で、石つぶての秘密*1を調べ、その後どうするのかを問われたアシタカがエボシに向かって放ったセリフです。
システムデザインにおいても、システムを曇りなき眼で見定め、決めることが大切です。
NASAのハンドブックでは、システムデザインのプロセスを4つに分けています。
- 利害関係者の期待の定義 (Stakeholder Expectations Definition)
- 技術要求の定義 (Technical Requirements Definition)
- 論理分解 (Logical Decomposition )
- 設計ソリューションの定義 (Design Solution Definition)
これらのプロセスは、A→B→C→… というように順番に進むものではなく、相互に依存しており、反復的に行き来するものです。
これらのプロセスが実行されることで、妥当性が確認された技術要求と、利害関係者の期待を満たす設計ソリューションを得ることができます。
下の図は、4つのシステムデザインプロセス間の再帰的な関係を示したものです。
NASAの宇宙開発ミッションのおけるシステムデザインプロセスは、ミッションの目的、制約、成功を定義するための基準などの「利害関係者の期待」を収集して、明確にするところからはじまります。
「利害関係者からの期待」を出発点として、仮のアーキテクチャ*2、ConOps（Concept of Operation）、派生要求を作っていきます。
ConOps（「コノプス」と発音します）というのは、「利害関係者の期待」を満たすために、ミッション運用中に、どのようにシステムが利用されるのかを説明するために作成されるものです。
システムの運用の見通しを示し、ユーザーに関連する要求や機能を明確化するために用いられます。
システムズエンジニアリングの世界では、よく出てくる専門用語です。
下図のような分かりやすい絵を使って、運用のコンセプトを表現する他、ミッションの概要や運用のシナリオについて詳しく書かれた資料となります。
システムデザインプロセスでは、システムのアーキテクチャとConOpsと要求の間の整合性が取れるように、反復的な活動と設計に対する意思決定を行うことが求められます。
整合性が取れた後、利害関係者の期待を満たすかどうかの検証が行われます。
- システムが期待どおりに機能するのか？
- 予算とスケジュールの制約の範囲内で実現可能なのか？
- システムは、プロジェクトへの資金提供の承認を得られるような、機能を提供し、運用ニーズを満たしているのか？
などといった質問に対して全て「YES」と答えられる必要があります。
システムの設計は、その設計が要求を満たしているかどうかを分析し、検証できる程度まで、深く行う必要があります。
実装レベルまで設計を深めないと検証ができない場合は、上流設計の段階でも具体的なモノの設計にまで踏み入れます。
これらのプロセスは、システム（アーキテクチャ、ConOps、要求）が利害関係者の期待に応えるまで続きます。
システムが利害関係者の期待を満たすことが確認できたら、システムのベースライン（開発の拠り所になる設計情報）を設定します。 ベースライン化された要求が徐々に深い階層の要求（より具体的な要求）に分解されていきます。 *3
NASAの場合は、ライフサイクルプロセスのステージごとに、システムデザインプロセスの焦点が変わります。
上述のシステムデザインプロセスは、主にプレフェーズAに適用され、フェーズCまで継続されるものです。
- プリフェーズAでは、承認を得るための実現可能な設計を作成することに焦点を当てます。
- フェーズAでは、設計アーキテクチャの最適化を目指し、代替手段の検討や技術的な成熟度の分析が行われます。
- フェーズBでは、承認基準を満たす基本設計が行われます。
- フェーズCでは、フライトモデルを作るための詳細な設計が完了します。
最後に、システムデザインに対するNASAの有り難い言葉 “System Design Keys”を紹介します。
システムデザインの鍵 (System Design Keys)
- ミッションの目的と運用の概念を正しく理解して定義しましょう。これにより、利害関係者の期待を正しく捉えることができ、プロジェクトのライフサイクル全体にわたる品質管理と効率的な運用につながります。
- 要求の検証を成功させるために、完全で徹底的な要求のトレーサビリティを確保しましょう。
- システム全体を開発するときや、大きな変更や小さな変更を加えるときの誤解を避けるために、明確で曖昧さのない要求を構築しましょう。
- 設計コンセプトの開発中に行われたすべての決定を技術データパッケージに文書化しましょう。 これにより、将来提案される変更と修正を評価する際に、元々の設計哲学と交渉結果を利用することができます。
- 設計ソリューションの検証は、継続的で反復的なプロセスであり、その間、設計ソリューションは利害関係者の期待に対して評価されます。
これらの言葉を意識し、システムを曇りなき眼で見定め、決めることが、良いシステムデザインを進める秘訣ではないでしょうか。
次回以降、各プロセスについて、さらに深く見ていきます。
