ガイドブックのガイド（４）サルNASAとシステミング

f:id:levii-miura:20201113072951p:plain

「ガイドブックのガイド」では、システミングガイドブックの要点や補足、具体例や関連する話題、制作や議論の裏話などをブログで紹介していきたいと思います。

システミングガイドブックは下記のリンクより無料でダウンロードすることができます。 levii.co.jp

今回は

システミングガイドブックに続いて公開したレヴィのブックレット「サルでもわかるNASA式システム開発」通称：サルNASAの冊子版が完成しました。冊子版の様子についてはこのブログと同時公開の"サルNASA"の冊子版が届きました！をご覧下さい。

せっかく手元に冊子がそろったので、今回はサルNASAの内容とシステミングの対応についてガイドしていきたいと思います。

システミングとシステムズエンジニアリング

そもそもシステミングは、宇宙開発やソフトウェア開発などの分野で発展してきたシステムズエンジニアリングや、それを一般化したシステム思考を誰でも上手に実践するためのフレームワークとしてレヴィが構築したものです。

サルNASAの６.アポロ計画とシステムズエンジニアリング（p.15～）で書かれているように、NASAはアポロ計画をきっかけにシステムズエンジニアリングに着目するようになり、その体系化や発展に取り組んできました。それを継承した現在のシステムズエンジニアリングのエッセンスを抜き出して、誰でも実践できるように分かりやすく再構築したものがシステミングです。

つまり、システミングの源流を辿っていくと、サルNASAで書かれているようなことに行き着くのです。そのため、サルNASAで解説されていることや主張されていることはどれも、システミングの内容に対応させることができます。

サルNASAの内容とシステミングの対応について全部書いているととても長くなってしまうので、今回はその一部について取り上げたいと思います。

システムライフサイクル

サルNASAのp.6にあるように、NASAではシステムライフサイクル（システムの一生）をPre-PhaseからPhase Fの７つに分けています。

f:id:levii-miura:20210615162559p:plain — NASAのシステムライフサイクルモデル

このうち、システミングが扱う主な場面はPre-Phase:（コンセプト検討）からPhase C（最終設計）くらいまでとなります。Pre-PhaseやPhase A（コンセプト開発）は、システムの目的設定や全体像を含むので、ビューモデルの左側に近いところのビューを考える（モデリングする）ことに相当します。一方で、Phase Cの最終設計ではビューモデルの右側のビューを考えることに相当し、製造はビューモデル右端の「システム」をつくり出すところに相当します。

そこでざっくりで考えると、各ライフサイクルステージで扱うビューと、ビューモデル上での位置を下図のように対応づけることができます。

f:id:levii-miura:20210615150025j:plain — システムライフサイクルとビューモデルのざっくり対応

ここで注意して欲しいのですが、上の図はあくまでもざっくりとした対応であり、正確ではありません。例えば７.システムを見定め、決める（サルNASA p.19～）で示されているように各フェーズにおける設計プロセスは再帰的・反復的なものになるので、ビューモデルの左に行ったり右に行ったりします。また、上の図では基本設計はシステムの中ビューに対応するように見えますが、必ずしもそうではなく、基本設計ではシステムの外ビューもたくさん扱います。

さて、ここまで確認したところでサルNASAのp.9の図（下図）を見ると、システミングで扱う範囲までのステージ（概念検討～開発）でシステム全体のコストの90%が決まることがわかります。システミングが扱う範囲は、プロジェクトにとってものすごく重要なのです。

f:id:levii-miura:20210615153153p:plain — 各開発段階での意思決定の影響（サルNASA p.9）

システムデザインプロセス

７.システムを見定め、決める（サルNASA p.19～）の章ではシステミングに関わる話題がたくさん出てきます。この章ではNASAにおけるシステムデザインの４つのステップについて説明されています。そしてこれらのステップは、下図のように反復的・再帰的であるとされています。

f:id:levii-miura:20210615154742p:plain — システムデザインプロセスの相互関係（サルNASA p.20）

このようにシステムデザインプロセスが反復的・再帰的になるのは（ならざるを得ないのは）、システミングガイドブックp.9の「やってみないとわからない」の項で説明していることが関係しています。その部分を引用してみます

わからない④ やってみないとわからない（曖昧さ）：システムデザインを進めていく上では「具体化してみないとわからない」や「つくってみないとわからない」という場面が数多くあります。最初は曖昧なものでも、一度それで仮決定として詳細化や具体化を進めてみると、はじめて問題点やあるべき姿に気づき、仮決定だった曖昧な箇所まで戻って修正することができます。ここまでに挙げてきた①～③の”わからない”にも、最初はわからないけど、一度具体化することでわかるようになったり気づいたりすることが多くあります。

また、反復的・再帰的なデザインプロセスにおいてはビューモデルの整合性リンクや整合性観点がとても重要になってきます。行き当たりばったりで行ったり来たりするのではなく、ビュー間の対応やつながりをチェックしながら行ったり来たりすることが重要です。