この記事では、「サルでもわかるNASA式システム開発」ガイドブックのポイントを抜粋して紹介しています。全文をお読みになりたいかたはこちらから無料ダウンロードしていただけます。
「いったん選んだ道に関して頑張る人は多い。目標に関してそうする人は少ない。」
『ツァラトゥストラはかく語りき』などで知られる哲学者フリードリヒ・ヴィルヘルム・ニーチェの言葉です。
複雑なシステムの開発プロセスというとウォーターフォール・モデルを思い浮かべる方も多いと思います。
ウォーターフォール・モデルは、悪者扱いされることがしばしばありますが、多くの場合、それはウォーターフォールをちゃんと理解せずに、それっぽいことをやった結果ではないでしょうか。
「ウォーターフォール・モデルでは、顧客や利害関係者を軽視して開発が進む」というのは誤解です。
NASAの開発手法は、PPP (Phased Project Planning)と呼ばれるウォーターフォール・モデルの一種ですが、決して顧客や利害関係者を軽視した手法ではありません。
むしろ、「利害関係者の期待」を重視しており、プロジェクトのすべてのフェーズに利害関係者を参加させることは非常に重要だと述べています。
利害関係者を自己修正フィードバックループに組み込むこと（自浄作用を持つこと）が、ミッションが成功する可能性を大幅に高めることにつながるからです。
It is extremely important to involve stakeholders in all phases of a project. Such involvement should be built in as a self-correcting feedback loop that will significantly enhance the chances of mission success. Involving stakeholders in a project builds confidence in the end product and serves as a validation and acceptance with the target audience. (NASA Systems Engineering Handbook, 4.1 Stakeholder Expectations Definition のNOTEより抜粋)
前回のブログで、システムデザインの４つのプロセスを紹介しました。
- 利害関係者の期待の定義 (Stakeholder Expectations Definition)
- 技術要求の定義 (Technical Requirements Definition)
- 論理分解 (Logical Decomposition )
- 設計ソリューションの定義 (Design Solution Definition)
これらのプロセスによって、システムの姿がアーキテクチャ、ConOps、要求という形で明らかになっていきます。 システムデザインプロセスは、システムの姿が利害関係者の期待を満たすまで繰り返されるものであり、そこには試行錯誤の過程が含まれます。
本稿では、上記の４つのプロセスのうち「利害関係者の期待の定義」に焦点を当てたいと思います。
このプロセスの目的は、
「利害関係者が誰であるか、どのように製品を使用するつもりかを特定すること」
です。
成果物としては、ユースケースシナリオ*1やConOpsなどにまとめられます。
プロセスを理解する近道は、インプットとアウトプットを見ることです。
まず、「利害関係者の期待の定義」プロセスの主なインプットは3つあります。
1. 顧客の大まかな期待（Initial Customer Expectations） 製品について、顧客から受け取るニーズ、ゴール、目標、要望、機能、およびその他の制約です。 2. 他の利害関係者の期待（Other Stakeholder Expectations） テストチームやオペレータ、責任者など顧客以外の主要な利害関係者の期待です。 3. 導出される顧客要求（Customer Flow-down Requirements） より上位レベルの要求から導出される要求です。
そして、アウトプットは次の4つ*2になります。
1. 検証された利害関係者の期待（Validated Stakeholder Expectations） 関係者感で合意の取れた製品に対する期待です。ニーズ、ゴール、目標といった形で表現され、制約と仮定も示します。 2. ConOps（Concept of Operations） ConOps*3は、システムがどのように運用され、利害関係者の期待に応えるかを説明します。運用の観点からシステムの特性を説明し、システムのゴールと目標、およびその他の利害関係者の期待を理解するのに役立ちます。 3. 補助製品のサポート戦略（Enabling Product Support Strategies） 製品の製造、テスト、展開、運用の維持、および廃棄に必要となる可能性のある特別な準備を含む戦略です。必要なサポートと、最終製品を生成するために開発する必要がある補助製品（enabling products）を特定します。*4 4. 有効性の指標 （Measures of Effectiveness） 利害関係者の期待に基づいて、有効性の指標が作成されます。これらの指標は、システムの成功に不可欠な期待を表す尺度であり、これらの尺度を満たさない場合、利害関係者はシステムを受け入れられないと見なします。
上記3つのインプットから4つのアウトプットを生み出すのが、利害関係者の期待を定義するプロセスであり、NASAのハンドブックには、そのためのアクティビティがいくつかに分解されて記述されています。
そのうちのひとつ「ニーズ、ゴール、目標を特定する」というアクティビティは、宇宙開発以外でも実効性の高いアクティビティですので、ここで紹介したいと思います。
まず、なぜ「ニーズ、ゴール、目標」（頭文字をとって、NGOs と呼ばれています）が重要かというと、解決する必要のある問題とその範囲の定義について、プロジェクトの開始時に全員が確実に合意するメカニズムを提供してくれるからです。
つまり、NGOsは、どんな問題をどこまで解決すべきかについて、チームの認識を揃えるための力となるわけです。
実際にゴールと目標を定義するには、利害関係者からニーズ、欲求、欲求、能力、外部インターフェース、仮定、および制約を引き出すことが必要です。
そのため、主な利害関係者が誰であり、誰が意思決定権を持っているかを知ることが重要となります。
レヴィでは、この活動のためにコンテキストモデリングを行うことを推奨しています。 ご関心のある方は下記の記事も御覧ください。
ところで、そもそも「ニーズ」、「ゴール」、「目標」とはなんでしょうか？
「ニーズ」、「ゴール」、「目標」という言葉は、しばしば混同されて使われます。 異なる定義の元では共通理解を築くのは難しいため、それぞれをきちんと定義づけておくことが重要です。 NASAでは下記のような定義を採用しています。
ニーズ（Needs） 他のすべてを動かす単一の声明（ステートメント）のこと。ニーズは、システムが解決すべき問題に関連している必要がありますが、解決策ではありません。 ニーズのステートメントは特異であるべきです。複数のニーズを満たそうとすると、2つの間のトレードオフが必要となり、少なくとも1つ、場合によっては複数の利害関係者の期待に応えられなくなる可能性があります。 ゴール（Goals） システムに対する特定の期待を構成するニーズの詳細のこと。ゴールは、問題(Problem)を評価していく中で特定された重要な課題（Issue：問題解決のためのアクション）をこなすこととなります。ゴールは、定量的または測定可能な形式である必要はありませんが、システムがそれらを達成したかどうかを評価できるようにする必要があります。
目標（Objectives） システムが達成しなければならない特定のゴールの成果レベルのこと。各目標は特定のゴールに関連している必要があります。一般に、目標は4つの基準を満たす必要があります。 （1）開発者、顧客、およびテスターがそれらを理解できるように、明確な方向性を提供するのに十分具体的でなければなりません。目標には、システムが何をすべきかを記載する必要がありますが、ソリューションを実装する方法を記載するべきではありません。 （2）目標は、測定可能、定量化可能、および検証可能でなければなりません。プロジェクトでは、システムが各目標を達成できているかを監視する必要があります。 （3）積極的であるが達成可能であり、挑戦的であるが到達可能でなければならず、目標は現実的である必要があります。トレードオフ調査が行われたり、業務の概念が固めたり、技術が成熟するまでは、目標は「未定」（TBD：To Be Determined）とすることができます。要求が記述され、システムが設計される以前に、目標が実現可能である必要があります。 （4）目標は、あることを達成するための方法ではなく、望ましい成果物や結果に焦点を当てた結果指向でなければなりません。目標は、要求ではありません。目標は、プレフェーズAの間に特定され、最終的な要求群の策定を支援します。また、契約上の拘束力があり、「完成した」システムデザインに対して検証されるのは、目標ではなく要求となります。
こうした活動を通じて、顧客、他の利害関係者、およびシステムエンジニアが、製品が示す機能、特性、動作、外観、およびパフォーマンスについて相互に合意することで、ライフサイクルの後半で重大な要求が増えることを防ぐことができます。
言葉の定義が多く、本稿でお伝えしたいことが埋もれてしまいそうなので、冒頭のニーチェの言葉に戻りましょう。
「いったん選んだ道に関して頑張る人は多い。目標に関してそうする人は少ない。」
ウォーターフォール・モデルなどが示している開発プロセスは、あくまで道です。
この道を歩むことも大変なことなので、そちらに目が行きがちになります。
しかし、大切なのは、目標を達成することであり、NASAの手法は、徹底的にゴール指向となっています。
レヴィもまた、複雑なシステムに挑む方々がゴール指向のシステムデザインを実践できるようになることを目指しています。
そのためのシステミング?utm_source=hatena&utm_medium=Referral&utm_campaign=hatena_20200916_nasa8であり、Balusなのです。
こちらの記事もおすすめです
*1:NASAでは、ユースケースシナリオのことを Design Reference Missions と呼ぶこともあるそうです。
*2:その他のアウトプットとして、「人間/システムの機能の割り当て」というものもあります。多くの設計では、人間は、全体システムの重要な要素であり、システム内の人間の役割と責任を明確に理解する必要があります。「人間/システムの機能の割り当て」には、組み立て、地上操作、ロジスティクス、機内および地上メンテナンス、機内操作など、ミッションに必要なすべての人間/システムの相互作用が含まれている必要があります。
*3:ConOpsについては、第7話でも少し詳しく説明しています。
*4:対象システムの運用に不可欠である補助システムのことをイネーブリングシステム（Enabeling System ）といいます。
