システムズエンジニアリングの基礎と検証(Verification)、妥当性確認(Validaton)の徹底解説

前回はNASA システムズエンジニアリング　ハンドブックの前書きとイントロダクション（導入部）の解説をしました。

前書きとイントロダクションの重要ポイントを復習すると以下の３点になります。

もし興味が出たら記事を覗いてみて下さい。

さて今回は、いよいよ本題に入ってシステムズエンジニアリングの基礎（原題:2.0 Fundamentals of systems engineering)を解説していきます。

システムズエンジニアリングの定義や基本的な考え方など、システムズエンジニアリングの土台になる部分なので丁寧に解説して行きます。

ここからはシステムズエンジニアリングと正確に書くと文字数が多いのでSEと略していきます。ただし重要な箇所では略しませんので注意して下さい。

SEの基礎

NASAにおいて”システムズ　エンジニアリング”とは、システムの設計、実現、技術マネジメント、運用、そして退役（もしくは廃棄）に至るまでを対象とした、体系的かつ複数の専門分野にまたがるアプローチとして定義されています。

システムとSEの定義

システムとは、ニーズ（needs）を満たすために求められる能力を生み出すべく、複数の要素（サブシステム）が一体となって機能する組み合わせのことを指します。
※システムの能力とは、単なる出力（output)だけでなく、システム全体の品質、性質、特性、機能、動的な挙動（振る舞い）、そして機能、性能のすべてを含みます。

従ってシステムへの技術的な判断を下す際には、個々の要素だけでなく全体像(Big Picture)を見ることが非常に重要になります。

具体的にはコストやスケジュールなどの様々な制約の中で、要求された機能面、物理面、運用面などの様々な要求をシステムのライフサイクル全体に渡って達成する方法です。つまりシステムのライフサイクルコストを抑制する方法論とも言えるわけです。

ここまでのことからSEを言い換えると、個々の複数の要素、それらの繋がり、全体を同時に考える論理的思考そのものです。

システムについての詳細は以下の関連記事を参考にしてください。

SEは技術（Art)と科学（Science）の融合

SEでは、相反する制約の中で、あらゆる要件を満たしつつ、運用可能なシステムを開発するための技術（Art )でもあり科学(Science)です。
※論理的思考が科学。

これらの論理的思考でのSEの技術(Art)の部分は、システムのバランス追求と妥当性確認のために、”いつ、どこを調査すべきかを知ること”にあります。

このスキルを持つ人材は、システムエンジニアと呼ばれることが多く、リード・システムエンジニア、テクニカルマネージャー、チーフエンジニアといった他の肩書きを持つかもしれませんが、本書ではシステムズエンジニアという用語を使用します。

システムズエンジニアの役割

システムズエンジニアの正確な役割と責任は、プロジェクトの規模と複雑さ、そしてライフサイクルのフェーズによって変化します。

プロジェクトの規模の大小や誰がそのSEの責任を担うにせよ、SE機能は確実に実行されなければなりません。

システムズエンジニアの役割と責任の実際の割り当ても、プロジェクトの大小や組織形態などによって変化する可能性がありますが、最終的にシステムズエンジニアはコンセプトを実際の製品へと進化させる責任と役割を果たす必要があります。

システムズエンジニアは以下の役割を負うことで、上記の責任を果たします。

ここまでの責任と役割を果たすためにシステムズエンジニアは、以下のタスクを主体的に遂行します。

このタスクに基づき、システムズエンジニアは技術的な計画活動を主導し、技術文書を文書化することにおいて、主たる責任を持ちます。

ここまでのことを要約するとシステムエンジニアリングとは、トレードオフと妥協のプロセスで、単一の専門分野からの視点ではなく、システムを横断する広い視野を用いることです。

つまりシステムエンジニアリングとは全体像（Big Picture）を見ることであり、以下の2つを確実に実行しなければいけません。

システムズエンジニアはいついかなる時も、この2つのことを自問自答しながらタスクを遂行することが非常に重要です。

プロジェクト管理におけるSEの位置づけ

プロジェクト管理には大きく分けて3つの目的があります。

SEは、このうちの技術面に強く関連しており、プロジェクトマネージャー（PM）が予算と期限内に届けることに責任を持つのに対し、システムエンジニアは技術的な成功（性能・品質・安全など）に責任を持ちます。

この両者の役割は重なり合う部分も多く、NASAではSE（技術側）とPP&C（プロジェクト計画・管理：ビジネス・予算側）が連携してプロジェクトを支える構造になっています。

システムの各要素の相互接続と検証(Verification)、妥当性確認(Validation)の解説

少し短いですがNASA システムズエンジニアリング　ハンドブックの内容はここまでで終了とし、ここからは文中で出ててくる内容で、筆者が重要だと思う項目を重点的に解説していきます。　

システムの能力は要素間の関係性、相互接続によって生み出される

まずは原文を見て行きましょう。

これを具体例で自動車を使って理解していきましょう。

まずは適当に自動車の主な構成部品とそれぞれの機能を考えて行きます（あくまで単純な例です）。

それぞれの構成部品単体では全く自動車にはなりえません。

いずれにせよ、単体で何かの役に立ちそうな構成部品は皆無です。

ここで各構成部品の関係性を考慮して相互に正しく接続します（実際はかなり複雑）。

図からわかるように各構成部品単体では、単なる変な置物に過ぎなかった各要素が、相互に正しく接続されると人が乗って自由に移動できる自動車になります。

これがSEの”個々の要素が独立して機能する能力を超えて、システム全体として付加される能力は、主に要素間の関係性、つまりそれらがどのように相互接続されているかによって生み出される”を単純化して示した例になります。

さらに踏み込んで解説するとSEでは全体像(Big Picture)を見ることが非常に重要だと述べてきました。

上記の例のように全体像を見る視点があると相互の関係を考慮したチェックが行えるようになり、SE視点の正しい設計ができるわけです。

例では非常に単純化しているので誰もが当たり前に感じるかもしれませんが、実際の自動車開発において構成部品が3万点以上に及ぶので非常に重要な視点になります。

また自動車に限らず、ロケット、飛行機、発電所などの大規模製品からスマホ、パソコン、電動アシスト自転車等の身近な製品まで大きくカバーできる考え方になるのです。

次の例としては視点を製品から組織に変えて日本政府を例に見て行きましょう。

自動車と同様に各省庁を単体の構成部品と見做して、いくつかの省庁を考えます。

それぞれの省庁単体は、当然ながら一点の機能に特化しています。

それぞれ、単体で各々の仕事を押し進めると国民がまともに生活できる国になるとは思えません。

ここで各構成省庁の関係性を考慮して相互に正しく接続します（単なる筆者の想像例です）。

各省庁が確からしい相互接続によって、まともに動く政府になったと思います（筆者の想像です）。
※実際には、図と比較にならないくらい複雑怪奇。各省庁間の情報・人員のやり取りは筆者の願望で実際はわからない

このようにSEの考え方の”個々の要素が独立して機能する能力を超えて、システム全体として付加される能力は、主に要素間の関係性、つまりそれらがどのように相互接続されているかによって生み出される”はプロジェクト、製品だけでなく政府のような大きな組織・プロジェクトにも適用できる幅が広い考え方になっています。
※政府のような大きな組織・プロジェクトが本領発揮分野でもある

さらにSEが正しく実行されれば政府のような大きな組織・プロジェクトでも下記のように正しい政策ができるようになるという方法論です。

検証と妥当性の違い

本文中で何度もさらっと使われている重要な言葉、検証と妥当性を解説していきます。この2つの言葉はSEの根幹を成す非常に重要な言葉なので特に丁寧に解説し行きます。

まずはSEの学会のような組織、INCOSE、JCOSEから意味を引用します。英語も重要なので覚えて下さい。

分かるような、分からないような難しい文章です。INCOSE、JCOSEともに学会のような存在なのでわかりやすさよりも正確性、網羅性を重視するので仕方がないかもしれません。

ここからは私流に解説していきます。

検証(Verification)とは?

検証は日本人にとって非常にわかりやすい概念で私流に言えば”目標値に対して、実際にどんな値だったか？”という概念になります。

具体例をいくつか挙げて意識を合わせて行きましょう。

具体例からお気づきのように、検証のいずれの例も”目標値に対してどうだったか？”で検証内容、検証方法も具体的な内容であることが理解できると思います。なかでも検証の大きな特徴が数値で定量的に決まることです。

この検証の最大のポイントは”目標に対し、実物や現実の値はどうなっているか？”と考えると理解しやすいと思います。

この検証行為は、おそらく多くの方が日常生活や仕事で頻繁に触れているので理解しやすいと思います。

妥当性(Validation)とは？

妥当性（Validation)は、説明が非常に難しいのですが、一言で表すと”決めた目標がユーザーや利用者などの目的に合ってるか、どうか？”という概念になります。

この妥当性も具体例で意識を合わせて行きましょう。

具体例からわかるように妥当性は検証とは異なり、一挙に複雑になります。

最大の特徴は妥当性は総合的・定性的に決まるので数値のみで一義的には決まりません。

この妥当性確認の最大のポイントは”目的と目標の整合性”と考えると理解しやすいと思います。
※目的はユーザー、利用者、などの外部要因に大きく起因する、目標は自分達で決めた内部要因であることが多い、つまり外部と内部のベクトルの整合性とも考えられる

また学術的な正確性や論理性は全くありませんが、日本語で”そもそも、これで合ってる？”などのそもそも論は9割5分以上の確率で妥当性確認(Validation)だと考えて良いと思います。
※筆者の個人的感覚ですが、そもそも論って答えが直ぐに出ないことが多くないですか？正に妥当性確認(Validarion)の問いだと考えて良いと思います。

検証(verification)と妥当性確認(validation)

具体例の中に検証（Verification)と妥当性確認（Validation)を並べて両者の違いをまとめていきます。

この検証（Verification)と妥当性確認(Validation)は、今回の説明を含めてSEでは頻繁に出てくる概念、作業になるので確実に理解しておくことが重要です。

またSEの基礎の中で説明された技術（Art)の”いつ、どこを調査すべきかを知ること”の意味は”いつ、どこで検証（Verification)、妥当性確認(Validation)をやるか？”と言っても過言ではありません。

さらに検証（Verification)、妥当性確認（Validation)はSEそのものとも言えると私は思います。

十年前くらいから流行が続いているVプロセスも、検討（Verification)と妥当性確認(Validation)のプロセスと言っても過言ではないと思います（後の記事で詳しく解説します）。

まとめ~SEの基礎・システムの各要素の相互接続・検証(Verification)と妥当性確認(Validation)~

今回の内容をまとめて行きます。

以上になります。

ここまでの記事内ではあまり触れませんでしたが、”システムズエンジニアは技術的成功に責任を持つ”ことに関して日本ではPMとSE的な役割の両方をプロジェクトリーダーという肩書で担ってきたと思います。
※日本ではPMとSE自体の認識が薄い気がする。

個人的な見解では、最近の複雑化する社会、製品でイマイチ、日本が世界をリードできない原因の一つは実質的にPMとSEを兼任させるプロジェクトリーダー制度では複雑化に対応できていないことが大きな理由の一つだと思います。

今までにない新たなチャレンジは難しいかもしれませんがシステムズエンジニアのような技術に特化してプロジェクトをマネージメントをする役割の人を任命すると現状を打破できるかも知れません（よくあるテクニカルマネージャーとは別にプロジェクト単位で任命を推奨）。

次回は、NASAのシステムズエンジニアリングの技術プロセスの概要を解説していきます。

• NASA システムズエンジニアリング　ハンドブック　Rev2
  本解説のベースとなる本です。Public Domainなので無料で入手できます。

• システムズエンジアリングハンドブック　慶応義塾大学出版　監修:西村秀和
  本サイトでも頑張ってNASAのハンドブックを監修していきますが、時間が掛かるので直ぐにでも全体を学びたい方はこの本がおススメです。私も持っています。