システムズエンジニアリングとSEの仕事

　製造業をはじめとした従来「モノづくり」から、デジタルを活用した「コトづくり」へのシフトしていく中で、これまで以上に、コトを提供する手段となる「システム」の重要性は増大しています。しかし、システムを構築し、維持していくというのは、実は結構難しい話なのです。システムが大規模・複雑になると、難しさはどんどん大きくなっていきます。

　システムを扱うための考え方を体系化したものとして「システムズエンジニアリング」という工学の分野があります。システムズエンジニアリングの考え方を通じて、システムを構築し維持していく難しさは何なのか、そのために何をすべきかを紹介していきます。

コンポーネントを組み合わせただけではシステムにならない

一つ目の話は、そもそもの考え方の話です。

　システムズエンジニアリングにおける「システム」とは「目的を成し遂げるために、相互に作用する要素のグループ」のことを指します。要素にはハードウェアやソフトウェアといったモノ（コンポーネント）だけではなく、人や情報や社会のルールなども含まれます。　

　米国で行われていた宇宙開発プロジェクトでは、1940年代ごろから、優れたコンポーネントを個別に設計しそれを組み合わせても、システムとしては必ずしもうまく機能しないということが、認識されるようになってきました。システムが複雑になるにつれ、システムの振る舞いは、コンポーネントが意図したものと異なってしまい、大きなコストがかかってしまうようになっていました。

　月まで人を運ぶロケットを例にとってみます。ロケットの一つのコンポーネントであるエンジンだけを見ると、極力高い出力のエンジンを作るのが良いように思われますが、出力が高い大型エンジンは重量が大きくなり、その分必要なものがロケットに搭載できなくなり、「月まで人を運ぶ」という目的には、必ずしも最適ではないかもしれません。さらに、開発のための時間がかかる、莫大なコストがかかるなどの問題もあります。

　このような問題に対し、システムズエンジニアリングではシステムの目的・要求からスタートし、それを実現するアーキテクチャを決め、要素に分解していくという考え方をします。この考え方は図のようなV字モデルで示されています。

　ソフトウェア業界の人にはこのV字モデルは馴染みが深いかもしれません。ソフトウェア業界で使われるV字モデルは以下の図のようなものですが、個々のプロセスがソフトウェア開発のプロセスに置き換えられているだけで、基本的な考え方は同じです。

　　このように、システムズエンジニアリングでは、要求からシステムに必要な要素に分解をして設計をしていくという考え方をします。しかし、日本におけるモノづくりは、これまで、個々にすり合わせを行い、要素を個別に設計し、これを積み上げるやり方が主流だったためこの考え方に馴染めない人も多いようです。考え方の転換が必要なのですが、それがうまくできていないことが、モノづくりからコトづくりへの変化を阻む要因になっているような気がします。

要件定義とは要求を全て取り入れることではない

　システムズエンジニアリングプロセスへの最初のインプットは、システムの目的とステークホルダーのニーズなどです。これらのインプットを明確化することを要求定義といい、この要求を分析した結果を元にシステムとして実現すべき事項であるシステム要件（System Requirement）を定義します。

　まず、顧客などステークホルダーの要求（ニーズ）は往々にして曖昧であることが問題になります。曖昧なままにシステムを実現してしまうと、本来必要であったものとは全く違ったものができてしまったりします。要求を明確にするためのヒアリングや打ち合わせに、かなり時間がかかってしまうことがよくあります。

　要求が明確になったとして次に出てくる問題が、多くの場合、全ての要求をシステム要件に盛り込めないという現実です。システムを構築する際には、コスト、完成の期限、従うべき法令、環境的な条件など、多くの制約条件を考慮する必要があります。制約条件の中で、システムを実現可能なものにするためには、何らかの要求を諦めたり、代替手段で行ったりすることも必要です。

　一般的に、パフォーマンス（機能・性能）、リスク、コストは相互にトレードオフの関係になっています。リスクを増やさずにパフォーマンスを上げるためには、コストは上昇します。３つ全部は成り立たないのです。この場合、ステークホルダとよく話をして、何かを諦めてもらうことも必要になります。

要件定義とアーキテクチャ設計の関係

　アーキテクチャ設計とは、システム要件をシステムを構成する要素に割り付け、構成要素の仕様を明確にするとともに、構成要素間のインタフェースを明確化することです。つまり、システム要件をどのように実現するかを決める行為です。

　ここで、間違えやすいのが、要件定義とアーキテクチャ設計の順序です。要件定義の結果を受けて、アーキテクチャ設計を行うのが正しいように見えますが、必ずしもそうではありません。要件定義は、制約条件の中で「実現可能な」システムを定義するものですので、要件が実現できるアーキテクチャは、本来要件定義と並行して行う必要があります。そうでないと、要件を実現可能なかどうか不明なまま決める事になり、実現可能だったとしても、後からコストや工程が大幅に増加してしまうことになりかねません。

　要件定義がされてからアーキテクチャ設計できるのは、すでに既存のシステムがあってこれを、更新したり改造したりする場合など、あらかじめアーキテクチャがほぼ確定しており、変えようがない場合だけです。

ライフサイクル全体を見通す

　システムズエンジニアリングでは、システムのライフサイクル全体を見通し把握することも重要視されています。システムは、一度構築されたら使い終わるまでそのままということは、まずありません。そのライフサイクルの中で、改善、機能追加、部分更新などが起き、これに対する考慮が必要です。特にソフトウェア中心のシステムの場合、変更が起きる頻度はかなり大きくなります。

　改善、機能追加、部分更新などにより、システムを構成しているコンポーネント間の相互作用は変わます。それまで上手く動いていた機能が、全く関係ないように見える新機能の追加によって、突然動かなくなったりすることがあります。複雑なシステムの場合、変更によるコンポーネント間の相互作用への影響は大きくなります。

　どのような機能改善や追加がありそうかを見越し、機能追加をしても、極力コンポーネント間の関係が変わらないようなアーキテクチャ設計が求められます。ただ、コンポーネント間の相互作用への影響を把握し予見するのは、永遠の課題と言えるほど難しい話です。

システムを設計するということ（SEとは）

　上記のような問題を解決しながら、システムを設計することになるわけですが、この設計をするのは「システムエンジニア（SE）」と呼ばれる職種の人です。SEという用語はIT業界における職種の名称として使われることが多いのですが、実際にはプラント、宇宙、交通などの分野にもSEはいます。

　IT業界におけるSEという用語は、曖昧な用語で、人によって定義が違うことがよくあります。ソフトウェアエンジニアのうち「プログラマ」以外の仕事をする人をSEと呼んでいるケースが多く見られます。この場合、システムを設計する仕事の他、顧客との折衝やプロジェクトマネージメントなどもSEの仕事になります。

　　あるいは、顧客と打ち合わせをし「要求定義」をする人をSEと呼んでいるケースもあります。学生向けの就活サイトなどで、SEに向いているのはコミュニケーションが得意な人で、そうでない人はプログラマに向いている、というような記事をたまに見かけます。SEにはコミュニケーション能力が必要という意味では、あながち間違いではありませんが、SEを「お客と話をする人」という面からしか見ていないようにも感じられます。

　いずれのケースにも違和感があります。システムズエンジニアリングの本来の趣旨から考えると、SEの仕事の本質は「顧客の要求を元に、実現可能なアーキテクチャを設計し、検証すること」なのではないかと思います。SEをやるには、ハードウェアやソフトウェアの他、関連法令、システムが対象としている分野のドメイン知識など、幅広い技術的知見が求められます。「お客と話をするのが得意」なだけでは務まらないものなのです。