システムズエンジニアリングはNASAの宇宙開発で活用されてきました。
ゆえに、システムズエンジニアリングとは宇宙開発に対して実施するものであるという誤解をしている人がいるかもしれないがそうではありません。
一方でMBSE（Model-based systems engineering）が自動車開発で使われ、広がり始めたため、システムズエンジニアリングという言葉自体が広まっています。
システムズエンジニアリングを活用するにはどんな情報から考えた方がいいのか、宇宙機開発や自動車開発以外にどのように応用していけばいいのか、簡単にまとめてみました。
必要な情報①製品の開発から使うまでの全体の流れを整理する
宇宙開発の業界では宇宙開発の流れと同時期にシステムズエンジニアリングを実地で学ぶことになるため、二つを混同する可能性があります。
宇宙開発の流れは、ユーザーがいてユーザーからの要望を整理して設計・製造・検証を行い、運用・活用するまでの流れです。
システムズエンジニアリングは、これらの一連の流れを分解して、整理して、成功率を上げつつ、2機目以降の開発効率も上げていくものです。
さて、全体最適化という言葉を聞いたことがないでしょうか？
例えば、改善しやすいところから改善し、技術力があるところだけ注視して開発していくと、部分的に高度な性能を有し、高い品質の製品が開発されるでしょう。
しかし、インテグレーションされるほかの部品の性能や品質が低い場合、よくて性能の向上が半減し、バランスの悪い品質になります。
結果、性能が適度に向上して、品質もそれなりに高い製品が完成されます。
想像していたより残念な製品が結果として製造されます。
全体の流れを整理するということは、どこを重点的に開発して、どの技術に注力するか明確にして推し進めることで、全体の性能や品質を向上させる狙いがあります。
まずは攻めるべきかを見極めるために製品の全体の流れが必要です。
全体の流れを把握してからでないと、部分最適化となり、製品としての性能を効率に上げることが難しくなります。
最初に必要な情報は、製品の全体の流れを知ることです。
ちなみに、開発全体の流れとシステムエンジニアリングを混同したままでいるとどうなるでしょうか。
とても堅実な開発となるため、失敗が少ない堅い製品が誕生します。
デメリットは、スケジュールが前号機と同等か、面白いことに遅くなることが多いです。
前号機と近しくするために、過去の資料を解読し同じ工程をなぞるのですが、人員が変わることでの作業のムラ、測定装置の差、変更点への評価の仕方が変わります。
結果、前回では発生しなかった不具合が出たりして、前号機のスケジュールより遅延することも少なくありません。
悪い意味で融通が効かないことから様式美と言われることもあるとかないとか。
宇宙開発業界の人と会話するときのズレはそこにあります。
それは宇宙開発の流れとシステムズエンジニアリングが混同しているという所にある気がします。
いわゆるオールドスペースがこの傾向にあるように見られ、ニュースペースの場合に他の業界からの参入も多いことから上手く分離できている気がします。
ただ、多くの企業が新規開発のフェーズから、量産販売フェーズに移った時に、優位さが逆転しそうな気もしますがどうなんでしょうね。
必要な情報②製品の機能分解
システムズエンジニアリングを活用するまでにやること2つ目は、機能をおさらいすることです。
機能分解するときの注意は、意識的に部品構成図と分けることです。
1つの機器に1つの機能があるとは限りません。
部品構成図で考えを整理するのはありですがそこで止まらないでください。
部品や機器で分解すると、複数の機能を持つ機器に対して分析漏れが発生します。
機器や環境条件の変更が発生した際に、変えたことで性能が上がるかもしれませんが、一部の機能が未達になり、開発途中から新しい機器の導入を検討し始めることになるからです。
機器や部品の変更の際に機能がまとまっていれば選定の項目から抜けることは少なくなります。
副産物ではありますが、機能分解を行い、分析を続けていけば、他社製品との比較にもなりますし、製品のコア技術なども明確になりやすいです。
必要な情報2つ目は、現在の製品あるいは新規に開発する製品の機能分解を行い、製品の設計情報を整理することです。
システムエンジニアリングではこの分析情報から、リスクのレベルを算出し、変更があった場合、変更部品に対して許容可能なリスクレベルなのか。
安全対策、安全設計が有効であるか、部品を減らしても問題ないのか、ダメなのか、という検討の影響度が整理され、決断を早くすることができます。
機能分析には別の側面もあり、ユーザーからの要求に対して製品に機能が備わっているのか確認しやすくできます。
システムズエンジニアリングでは、要求定義という上位の要求からトップダウン型で適合を確認する傾向があるため、事前に分析しておくと理解が早いと思います。
ちなみに機能分析は要求定義からの盲目的にトップダウン型で進めると、製品の妥当性確認はできるのですが、内在する必要な機能性能を洗い出すことを忘れてしまうため注意が必要です。
製品全体を考えて、考えなければならない機能、性能を取りこぼしてしまう可能性があります。
高性能の記録媒体の要求があっても通信速度が遅くては意味がないですし、通信速度が速くても、規定時間内に情報を送受信できる能力（例えばデータ圧縮）がなければ成り立ちません。
高精度の光学レンズを装備していても、それを支持する機構が熱や応力に弱ければ性能を生かし切ることはできません。
内部機器の配置のバランスを考えて配線を行わなければ、ケーブルにノイズの影響を受けて、機器そのものが使用できなくなってしまうこともあります。
要求事項に対する網羅性だけではなく、システムとしても再現率の高い成立性を目指すには機能分析はとても重要な項目となります。
必要な情報③プロジェクトマネジメント
システムズエンジニアリングの分野には、プロジェクトマネジメントという言葉が出てきます。
システムエンジニアリングとプロジェクトマネジメントは、両方とも製品を製造する上で使用されるノウハウであり、フレームワークのようなもので、それぞれの役割が違います。
誤解が生まれやすい原因として、システムズエンジニアリングをプロジェクトに活用していく上で、それぞれの担当製品のマネジメントを行うことになります。
このマネジメントの手法は、プロジェクトマネジメントの手法と親和性があり、意図しなくともプロジェクトマネジメントでいわれているようなマネジメントを行うことになります。
さて、システムズエンジニアリング、あるいはプロジェクトマネジメントの教本や記事を読んだときに何か足りないと感じることがあると思います。
エンジニアリングとしてプロジェクトに携わっていても、製品を形にするにはどうしてもマネジメントとして管理する部分が出てきます。
コスト管理、工数（人員）管理、計画管理、各チームとの調整、マイルストーンの設定などはこのプロジェクトマネジメントの知識が使われます。
マネージャー側で計画を立案する際に、自身で計画立てる場合もありますが、エンジニアに内容を確認し、スケジュールを含めた計画を組みます。
この際に調整シロとしてマージンを考慮して組み上げていきます。
マネージャーとエンジニア、お互いに無理のない範囲に調整していくというのが非常に難しく、経験や知識によるところが大きいです。
これは一般的な知識ではなく各組織の特性に合わせて微調整していきます。
この特性を読んだり、過去の知見に当てはめていくためにフレームワークが使用されます。
フレームワークを知ることは解決策を見つける手段が多く手元にあるとも言えます。
このフレームワークの一つがプロジェクトマネジメントにつながっていきます。
各組織の特性を知るために、製造現場との調整や繰り返し経験することで勘所を掴んでいることが多いことから、プロジェクトマネジメントは人間とのコミュニケーションが重要とも言われます。
これらのノウハウは、言語化しても読み手側できちんと伝わるか難しいため、実地や経験で蓄積させていくことが多いです。
もちろん難しいからと言って、口伝だけにたよらずマニュアル化をしないという選択肢はとらない方がよいでしょうね。
間違っていれば修正すればいいですし、内容が古すぎて合わない場合は、過去や現在の事例に合わせて整えていきます。
結局、口伝で伝わり、個々人での創意工夫により調整してきた内容を文書化しているだけですので、時間がかかることを除いてやっていることは変わらないのです。
そう、必要な情報３つ目はプロジェクトマネジメントになります。
システムズエンジニアリングとプロジェクトマネジメント、それぞれの知見を持つことで、よりスムーズに製品開発を進めることができます。
終わりに
システムズエンジニアリングを活用するにはどんな情報から考えた方がいいのかをまとめました。
ズバリ次の三つです。
- 製品の開発から使うまでの全体の流れを整理する
- 製品の機能分解
- プロジェクトマネジメント
プロジェクトマネジメントあたりは、一朝一夕で学ぶことは難しいですが、ほかの二つは案外製品開発の中で実施してきた組織もあるのではないでしょうか。
組織の中で、製品開発の必須資料としてまとめているところもあるでしょう。
ただシステムズエンジニアリングと認識したうえで、体系立てて製品開発するのと、組織の仕組みとして社内審査を通すために作成するのとでは、資料レベルの質が変わります。
今回は、システムズエンジニアリングって、最初は何から手を出すのかを考えたときに、取っかかりやすい３項目を挙げてみました。
いわゆる土台となる部分ですので、参考にお願いします。
参考資料
WG関連資料
