この記事では、「サルでもわかるNASA式システム開発」ガイドブックのポイントを抜粋して紹介しています。全文をお読みになりたいかたはこちらから無料ダウンロードしていただけます。
「飛行機は美しい、夢だ。設計家は、夢にカタチをあたえるのだ!」
映画「風立ちぬ」で、飛行機の設計家カプローニ氏が次郎少年の夢の中で語ったセリフです。
夢は、夢のままでは叶えることができない。
「空を飛びたい」という漠然とした夢を、飛行機のような実現手段に落とし込むことができてはじめて、夢を叶えることができるようになります。
NASA式システムデザインの第2プロセスである「技術要求定義(Technical Requirements Definition)」は、まさに「利害関係者の期待」にカタチを与えるプロセスと言えます。
技術要求定義とは、一言でいれば、「利害関係者の期待」をシステムが満たすべき「技術要求」に変換することです。
NASAのハンドブックによると、まずは、「利害関係者の期待」をシステムが「解決すべき問題」に置き換え、次に解決すべき問題を一連の「技術要求」に変換します。
これらの要求は、「〜しなければならない」(英語では”shall”)という形式で表現され、システムのProduct Breakdown Structure(PBS)*1や関連する補助プロダクトといったソリューションを定義するのに用いられます。
要求定義に際しては、次のような注意事項が書かれています。 顧客から要求を受け取ることは、要求定義プロセスの終わりではなく、はじまりなのですね。
It is important to note that the team must not rely solely on the requirements received to design and build the system. Communication and iteration with the relevant stakeholders are essential to ensure a mutual understanding of each requirement. Otherwise, the designers run the risk of misunderstanding and implementing an unwanted solution to a different interpretation of the requirements. This iterative stakeholder communication is a critically important part of project validation. Always confirm that the right products and results are being developed. ( システムデザインを実行するチームは、システムの設計と構築のために受け取った要求だけに依存してはいけません。 各要求に対する共通の理解を得るためには、関連する利害関係者とのコミュニケーションと反復が不可欠です。 そうしないと、設計者は、要求の解釈を誤り、望ましくないソリューションを実装するリスクを冒します。利害関係者との反復的なコミュニケーションは、プロジェクトの妥当性確認にとって非常に重要です。 正しいプロダクトと結果が開発されていることを常に確認しましょう。)
さて、具体的なプロセスを見ていきたいと思います。
下の図は、「技術要求の定義」プロセスの全体像を示したものです。 「利害関係者の期待の定義」プロセスなどから来るインプットを受け取り、「検証済みの技術要求」や「性能指標」などをアウトプットするのが、このプロセスの責務です。
このプロセスのインプットは下記の4つとなります。
1. ベースライン化された利害関係者の期待(Baselined Stakeholder Expectations) 利害関係者と合意された利害関係者の期待(ニーズ、ゴール、目標、仮定、制約、外部インターフェイスなど)です。 2. ベースライン化されたConOps(Baselined Concept of Operations) 利害関係者の期待に応えるために、ライフサイクルフェーズ中にシステムがどのように運用されるかを説明します。運用の観点からシステムの特性を説明し、システムのゴール、目標、および制約の理解を容易にします。 3. ベースライン化された補助サポート戦略(Baselined Enabling Support Strategies) 最終プロダクトの開発、テスト、生産、運用、または廃棄に必要な、「利害関係者の期待定義」プロセスで特定された補助プロダクトについて説明します。また、ライフサイクル全体で最終プロダクトがどのようにサポートされるかについての説明も含まれています。 4. 有効性の指標(MOE:Measures of Effectiveness) 「利害関係者の期待の定義」プロセス中で、プロジェクトが成功と見なされるために(つまり、成功基準を満たすために)、満たす必要があると識別された指標です。
このプロセスのアウトプットは下記の3つとなります。
1. 検証済みの技術要求(Validated Technical Requirements) 解決すべき問題を表現した要求と、顧客および利害関係者によって検証および承認された要求のセットです。要求は、システム要求ドキュメント(SRD)、プロジェクト要求ドキュメント(PRD)、インターフェイス要求ドキュメント(IRD)、およびソフトウェア要求仕様(SRS)などに記述されます。 2. 性能指標(MOP:Measure of Performance) 設計ソリューションが満たされている場合に、1つ以上のMOEが満たされることを保証するのに役立つ定量的指標です。 MOEごとに2つ以上のMOPが存在する場合があります。 3. 技術的業績評価指標(TPM:Technical Performance Measures) 現時点でのパラメーターの達成値を期待値または必要な値と比較することによって、監視および傾向分析するために用いる評価指標です。 TPMは、進捗状況を確認し、欠陥を特定するために使用されます。
次に、具体的な技術要求の記述を見たいと思います。
まず、要求には、PBSを介して設計要素に割り当てられる要求と、プロダクトのの境界を越える横断的な要求があります。
PBS(プロダクトの構成要素)に割り当てられる要求は、機能要求(実行する必要のある機能)、性能要求(これらの機能をどの程度適切に実行する必要があるか)、およびインターフェイス要求(プロダクト間の相互作用に関する要求)です。
一方で、 横断的な要求には、環境、安全、人的要因、「-ilities」*2、および設計標準などに由来する要求が含まれます。
設計初期の機能要求は、例えば下記のようなものです。
推力ベクトルコントローラー(TVC)は、ピッチ軸とヨー軸に関する機体制御を提供しなければならない。
技術チームは、設計を通じて、このステートメントを機能要求および性能要求に変換する必要があります。
関連する性能を伴う機能要求に分解すると、例えば下記のようになります。
- TVCは、エンジンを最大9度±0.1度ジンバルしなければならない。
- TVCは、最大5度/秒±0.3度/秒の速度でエンジンをジンバルしなければならない。
- TVCは、40,000ポンド、±500ポンドの力を提供するものとしなければならない。
- TVCは20Hz ±0.1Hzの応答速度を持たなければならない。
このような形で、要求は、顧客と共に定義するものから、徐々にソリューションを実現するための具体的なものへとフローダウンされていきます。
上に行くほど「夢」に近いものになり、下に行くほど「実現手段」に近いものになります。
フローダウンされ、定義された要求は、”Validated” とならないといけません。
要求の妥当性を確認するためには、次のような問いかけを行います。
- 要求は正しく書かれていますか?
- 要求は技術的に正しいですか?
- 要求は利害関係者の期待を満たしていますか?
- 要求は実行可能ですか?
- 要求は検証可能ですか?
- 要求は冗長ですか?それとも過剰に指定されていますか?
これらの質問に正しく答え、利害関係者やチーム内での合意をとり、要求は”Validated” な状態になります。
この工程を省略すると、要求に対する認識の齟齬によって、後で思わぬ事態が生じ、大きな手戻りが発生することにつながります。
NASA式システムデザインの中で、要求は、顧客から与えられるものではなく、システムデザインを通じて、顧客や技術チームのメンバーなどと認識を揃えながら、一緒に作り上げていくものなのです。
「利害関係者の期待」に、適切な”カタチ”を与える。
それが要求定義プロセスの肝となります。