システムズエンジニアリングが失敗していると思った時にチラ見する記事 - 往時宇宙飛翔物体システム機械設計屋の彼是宇宙blog

システムズエンジニアリングを導入してみたがどうも失敗している。

なぜか上手くいかない。

一部の人に負担が偏って効果が見えない。

そんな声とともにやがて過度に増える負担と効果から部分的に効果を見せていても、社内に広まることは無くシステムズエンジニアリングから撤退していっているのではないでしょうか。

最近はMBSE（Model-based systems engineering）が広まるとともに、SysML言語を利用したツールにより一見手軽に扱えるようになったように思えるかもしれませんが、それでも、上記のような意見とともに、うまく扱えず失敗、あるいは失敗と言えずとも効果があったとは言えない状況で終わってしまいます。

今回は、宇宙機も限らず、複数の専門分野（機械、電気、ソフトなど）が関わる製品で適用したときに、失敗が起きている理由と対策の一つを述べていきます。

※宇宙機では、宇宙機というシステムの下に、姿勢制御系、電源系、機械系といった複数のサブシステムがあり、その下にコンポーネントあるいはユニットという形での製品があります。このコンポーネントも、機械、電気、ソフトなどの分野に分かれます。

[目次]

失敗事例1：システムエンジニアリングをリーダー/マネージャーしか理解しない
失敗事例2：システムエンジニアがプロジェクトで一人か二人である
失敗事例3：プロジェクトが小規模である
対策
- 参考

ちなみに、システムズエンジニアリングを始める前提として必要な情報を過去の記事にまとめていますので、気になった方は参照ください。

mechanical-systems-sharing-ph.hatenablog.com

失敗事例1：システムエンジニアリングをリーダー/マネージャーしか理解しない

ソフトウェア開発でのシステムエンジニアは、各機能を作成するチームを調整し、それらの機能が上位の要求に適合しているか確認し、分析し、仕様を作成する役目を負っています。

客先の要求に適合できる製品を開発するために、ざっくりした要求を機能と性能に分解し、実現可能な仕様に落とし込みつつ、進めていきます。

では、今回のような複数の専門分野（機械、電気、ソフトなど）が関わる製品の場合はどうでしょうか。

突然システムエンジニアリングを導入しますと言われた他のメンバーは、ニュース記事とかでたまに出てくる単語ではありますが、内情が分かりません。

ある程度システムズエンジニアリングの知識がある人からしても、複雑多岐にわたるためにどこから説明していいか悩むところです。

こんなときに発生する問題としては、システムズエンジニアリングを推進する担当者とリーダーやマネージャークラスでどのようにメンバーを取り込み、システムエンジニアリングを回していくか、ということです。

とりあえずシステムエンジニアリングについて深く知っている人がいない状況から始まると、ある程度の知見がある推進する担当者とリーダー/マネージャークラスだけが、MBSEを回そうと仕組みの構築、もしかするとSysML言語によるアプリ（ツール）を始めます。

各メンバーは、推進担当の人とリーダー/マネージャークラスの人からツールの穴埋めに必要な情報しか入手できておらず、具体的な作業の割り振りがされていないため、ブラックボックスで進められてしまいます。

結果、システムズエンジニアリングの要求分析で精一杯となり、試作品や製品が製作されてから、情報を更新できずに、未完成のままとなり、効果を感じずにプロジェクトが終わってしまいます。

システムズエンジニアリングの効果とは何かというと、

システムズエンジニアリングの流れとして、試験結果と要求が妥当であるか、必要に応じて機能を追加したり、想定性能を見直したりします。

見直す際に各追加機能が、現在の要求や機能に影響がないかも確認します。

確認作業の中で、潜在的なリスクを共有し、事前に対策を施すことができます。

実際のところ、ある程度の設計・製造熟練者でメンバーが構成されている場合、システムズエンジニアリングを意識せずともリスクに対応できてしまいます。

これはシステムズエンジニアリングの効果の一端ですが、より分かりやすく効果を実感できる部分ではないかと考えています。

失敗事例2：システムエンジニアがプロジェクトで一人か二人である

これはMBSEでのツールを使用した場合になるんですが、複雑なシステムにおいて複数の分野にまたがっているにもかかわらず、システムエンジニアが1人か2人しかいない。

システムズエンジニアリングを学ぶのは大変です。

一様の方法というのはなく、実用化するにはほぼ確実にいくつかの方法を各プロジェクトに合わせて応用する必要があることが多いシステムズエンジニアリング。

ある程度の知識をもとに回せる人間をなんとか2人確保してプロジェクトを進めてみたものの、ツールをまともに動かそうとすると負荷が高くて断念してしまいます。

2人しか確保できない場合、下手にモデルベースとするのではなく、ドキュメントベースに移行した方が効率が良いです。

MBSEは、複数の分野に跨がるプロジェクトを、共通の言語で表現するため効果が高まります。

ここで必要なのは、各分野の人でもMBSEで書かれている内容を理解できることです。

システムエンジニアが少ない場合、複数の分野とのすり合わせが少なくなり、一部の分野では解読しなければならない言語で記述されてしまいます。

書かれた記述を解読もできず、更新するタイミングもなければ、MBSEを使用する人が限られてしまい、効果が落ちてしまいます。

MBSEのツールとして、完璧なアウトプットを出せたけど、穴埋めをすることが目的となってしまい、それをプロジェクト内の設計や運用にうまく生かすことができないまま終わってしまう可能性があります。

理解と関係性、影響度を明確に分かりやすくするツールとしてMBSEのツールを意識して使わないと、うまくプロジェクトの一つに回せなくなるので注意が必要です。

ちなみに、少人数であったり、専門分野もそれほど広くない場合は、モデルベースよりもドキュメントベースの方が効果がある場合があります。

2人程度の場合、ドキュメントとして知見を残すことはもちろんですが、対話により理解が早く、ドキュメント方式の方が比較的早く作成できるからです。

ツールを使用すると、穴埋めに時間がかかり、本来のコミュニケーションをおろそかとなります。

結果、情報抜けや更新速度が落ちてしまう可能性があります。

失敗事例3：プロジェクトが小規模である

システムズエンジニアリングは複数の専門分野が関わる製品の場合に有効に働きます。

失敗事例2でも記載しましたが、プロジェクトのメンバーが少ない場合、システムズエンジニアリングに則って動かそうとすると、うまく回らないことがあります。

システムズエンジニアリングあるいはMBSEによるツールを利用することで、ツールやドキュメントの作成に負荷が多くなってしまい、本来システムズエンジニアリングが生きるはずの効果が薄れてしまっているのです。

複数の分野であっても、同じ組織であり、同じチームで、同じ職場で、十分な頻度で会議が成立する人数であれば、対話やコミュニケーションの方が早いです。

例えば、同じ組織であり、同じチームで、同じ職場であっても、人数の規模が多い場合や使用する言語が違う場合ですと、ある一定のルールに沿った共有言語でないと、すれ違いが発生してしまいます。

すれ違いの蓄積は、ミスや要求抜け、過去の対策忘れにつながります。

各組織は、これらが繰り返し発生しないようにするシステムを構築していくのはもちろんですが、そうもいかないことがあります。

会社そのものが違う。
部署が違う。（社内の情報共有が甘い）
設計と製造、組み立ての部署が違う。（社内の情報共有が甘い）
人数が多い。（システムエンジニアリング、リーダーシップ不足）
新規メンバーの増員が増えていく予定がある。
共通言語が違う。

このような時に、ドキュメントベースにしろ、MBSEにしろ、情報の共有と抜けのない設計にシステムエンジニアリングが有効になります。

対策

対策の一例をあげてみます。

複数のメンバーがシステムズエンジニアリングをある程度理解した上で進めること。また、完全に理解する必要はなく、始めながら理解した方が身に付きやすい。
システムエンジニアリングは、MBSEのツールを使用することではなく設計・試作・製造・試験・運用を検討する際に、検討忘れや試験の妥当性を評価するものという認識を持っておくこと。
複数のメンバー（主にリーダー）によりMBSEのツールの管理をすること。
互いの表現に誤解がないか、コミュニケーションをとり、すり合わせること。
コミュニケーションが取り難く、規模やメンバー、組織間の情報のやり取りが少ない場合は、ツールを使用することで補完できる。

MBSEという言葉が先行していますが、システムズエンジニアリングでは、モデルベースとなる前には、ドキュメントベースで今まで管理してきました。

ドキュメントベースでも、一つ一つの要求を網羅的に分析していましたが、文書が複数に渡るため、人間の頭で補完しつつ進めていました。

また、複数の分野が絡み合っているため、ドキュメントとして完成させるのにも複数のメンバーが携わり、調整するなどして時間がかかっていました。

実際に、システムズエンジニアリングを意識することは、ドキュメントが固まっていくプロジェクトの中盤ごろでした。

現在、SysML言語によるツールを使うことで序盤から、よりシステムズエンジニアリングを意識することができます。

システムズエンジニアリングは、多様な専門分野を統合したうえで製品を成立させていきます。

モデルベースという形ができるまで、宇宙機の分野では、コミュニケーションとドキュメントと人間の頭によりその差分を埋めていました。

ここ20年近くから生まれた宇宙関連企業・団体をニュースペースと呼び、それ以前の宇宙関連企業・団体をオールドスペースと呼んでいます。

ニュースペースから見て、「オールドスペースはドキュメント文化」だと称されていたのは、システムエンジニアリングをドキュメントベースで管理していたというのも理由の一つではないでしょうか。

システムズエンジニアリングを元に、試験の妥当性や変更点の影響度管理、リスク管理を進めてきたのは、過去の無数の失敗が積み重なった上での対応です。

ただ、現在はあまりに膨大になり過ぎて、ドキュメント管理に費やす時間が増えているのも事実です。

プロジェクトの規模や状況により、システムズエンジニアリングの手法を操っていただければと思います。