この記事では、「サルでもわかるNASA式システム開発」ガイドブックのポイントを抜粋して紹介しています。全文をお読みになりたいかたはこちらから無料ダウンロードしていただけます。
「難問は、それを解くのに適切かつ必要なところまで分割せよ。」
近代科学の基礎にある機械論的自然観を提唱したことで知られるデカルトが著書「方法序説」で述べた言葉です。
デカルトは、「我思う、故に我あり」でも有名ですね。
複雑なシステムを扱うときにも、複数の視点から分割して理解することが大切になります。
冒頭から余談なのですが、著者がNASA式システム開発と馴染みがあるのは、超小型衛星開発の中でNASAから審査を受ける機会が度々あり、審査をうまく通過するためにはNASAのエンジニアが何を考えているのかを理解する必要があったからです。
その衛星のひとつ「ひろがり」が今度、宇宙に行きます。
NASAのWEBサイトにも特集ページを作って頂きました。
https://www.nasa.gov/mission_pages/station/research/experiments/explorer/Investigation.html?#id=8450
「ひろがり」の開発物語についても、そのうち書きたいと思いますが、今日のテーマは、NASA式システムデザインの第3プロセスである「論理分解（Logical Decomposition）」です。
具体的なプロセスの紹介の前に、「ひろがり」の前の超小型衛星で、2014年2月にH-IIAロケットで打ち上げられたOPUSAT「こすもず」の統合試験で起きた事件を紹介します。
あれは、JAXAへの納品目前の統合試験のときでした。
この衛星が宇宙に出て最初の仕事は、アンテナを展開することなのですが、なぜか展開しません。
「試験を繰り返したはずの衛星が動かない！なぜだぁ！」
徹夜続きの開発現場に衝撃が走りました。
JAXAへの引き渡し期日まで、時間がなく、1日の試験の遅れが致命傷になりかねない状況でした。
原因は至って簡単なことでした。
アンテナ展開機能を実現するためのソフトウェアを誰も書いていなかったのです。
このような自体に陥った根本的な原因は、システムを分割するときに、各構成要素に責務をきちんと割当て、境界を明確にしていなかったことにあります。
この責務の分解と割当こそが、「論理分解」プロセスのテーマです。
NASAのハンドブックには、こうあります。
Logical decomposition is the process for creating the detailed functional requirements that enable NASA programs and projects to meet the stakeholder expectations. This process identifies the “what” that should be achieved by the system at each level to enable a successful project.
（論理分解は、NASAのプロジェクトが利害関係者の期待に応えられるよう、詳細な機能要求を作成するためのプロセスです。このプロセスは、プロジェクトを成功させるために各レベルで「システムが達成すべきことは何か？」を特定します。）
「機能」という言葉は、分かるようで分からない言葉のひとつだと思います。
例えば、目の前にDr. GRIP的なボールペンと100円ショップで買った名もなきボールペンがあったとします。
片方のボールペンを使っていましたが、インクが切れるなどして使えなくなった場合、もう片方のボールペンを使うと思います。
Dr. GRIP的なボールペンと100円ショップで買った名もなきボールペンは「異なるモノ」ですが、「同じ機能」を持っているため、代替が可能です。
ここでいう機能は、「長期間、消えることなく紙に文字を残す」となります。
システムを主語にしたとき、「システムがやること」を記述したのが「機能」です。
システムを設計するときに、利害関係者の期待を満たすような「モノ」に目を向けるのではなく、「システムがやるべきこと」に目を向けるべきであるというのがNASA式です。
さて、具体的なプロセスを見ていきたいと思います。
下の図は、典型的な「論理分解」プロセスの全体像を示したものです。 「技術要求の定義」プロセスなどから来るインプットを受け取り、「論理分解モデル」や「論理分解ワークプロダクト」なるものをアウトプットするのが、このプロセスの責務です。
このプロセスのインプットは下記の２つとなります。
1. 技術要求（Technical Requirements） 顧客やその他の利害関係者によって承認された、解決すべき問題を表す一連の要求です。 2. 技術指標（Technical Measures） プロダクトの有効性と顧客満足度を決定するために、利害関係者の期待と要求に基づいて確立された一連の指標のことで、追跡および評価される指標です。
このプロセスのアウトプットは下記の３つとなります。
1. 論理分解モデル（Logical Decomposition Models） システムの要求と機能の関係と、その振る舞いを定義したモデルです。これらのモデルには、システムの要素（ハードウェア、ソフトウェア、HITL、サポート担当者など）の基本的な構造と関係を定義するシステムアーキテクチャモデルと、設計作業を実行できるようするためにより低いレベルへと要求を分類する方針が含まれます。 2. 導出された技術要求（Derived Technical Requirements） 入力された技術要求には記載されていないような、システムアーキテクチャを決定することによって導出される技術要求のことです。ベースライン要求と導出された要件の両方が、システムアーキテクチャと機能に割り当てられます。 3. 論理分解ワークプロダクト（Logical Decomposition Work Products） このプロセスの活動によって生み出された別のプロダクトのことです。キーとなる意思決定やlessons learned などが相当します。
「論理分解」プロセスの中でも、特に重要なのがシステムアーキテクチャモデルの確立です。
システムアーキテクチャを確立する活動は、ハードウェア、ソフトウェア、HITL（Human in the loop）、サポート要員、通信、運用など、システムの構成要素の基本的な構造と関係を定義します。
また、システムの要素と要求を下位レベルの機能と要求に分割して、設計作業を実行できるようにします。
つまり、「難問を分解」します。
当然、分割したサブシステム間のインターフェースも定義します。
システムアーキテクチャは、システムの機能要素の戦略的な編成と見なすことができ、要素間の役割、関係、依存関係、およびインターフェイスを明確に定義して理解できるようにするものです。
要素単体の動きに着目するのではなく、その要素がどのように組み合わされて全体に貢献するかに焦点を当てています。
システムアーキテクチャがきちんと定義できていると、要素が別々に開発されると同時に、それらが効果的に連携してトップレベル（または親）の要求を達成できるようになります。
システミングでいう「分けて、つなげて、考える」です。
システムアーキテクチャの開発は、創造的、再帰的、協調的、反復的なプロセスです。
プロジェクトの目的、トップレベル（または親）の要求、および制約に焦点を合わせて、目的を達成できる少なくとも1つ、できれば複数のコンセプトアーキテクチャを開発する必要があります。
ハンドブックでも、システムアーキテクトの創造的な精神を要する活動だと記述されています。
一方で、システムアーキテクチャの開発に利用できる手法やツールは色々あります。
手法としては、米国国防総省アーキテクチャー・フレームワーク (DoDAF)などが有名です。
DoDAFでは、オペレーショナル・ビュー (OV)、システム・ビュー (SV)、およびテクニカル標準ビュー (TV) の 3 つのビューと全体ビュー (AV) で、システムアーキテクチャを記述します。*1
システムをどのようなビューで捉え、どのようなモデルを使って各ビューを表現するかを定めたものを、レヴィでは「KATA」と呼んでいます。
「国防総省」とかつくと仰々しいですが、様々な視点からシステムを観て、適切な分割と全体の最適化を行うという考え方自体は、多くのシステム開発プロジェクトに有効かと思います。
DoDAFを使いこなす自信はないけど、そのエッセンスを活用してシステムデザインを進めて行きたいという方のために、レヴィでは日夜KATA作りに勤しんでおります。
