はじめに

VUCAの時代と呼ばれ、経済環境が目まぐるしく変わる昨今において、世の中に新しいものを提供し、イノベーションを起こすことは、誰もが考えるべき経営課題となりました。お客さまにおかれましても、新しいものを世に出すべく粉骨砕身されていらっしゃるかと思います。その中で、（MB）SE（Model Based Systems Engineering）が重要だと耳にされた方も多いのではないでしょうか。事実、本誌99号の一般社団法人日本自動車工業会（JAMA）様における当社の（MB）SEの取り組みの記事は大変ご好評をいただいており、お客さまからの期待が大きいことを改めて認識いたしました。一方で現在までに広がりを見せている（MB）SEには難解な言葉や概念が多くあり、調査してもまず何をどうしたらよいかがわからないとのお声を多く拝聴します。そこで、本誌にて私たちの（MB）SEに対する理解を解説することにしました。

今回は記念すべき第一回としてSEの対象である「新しい仕組みに変革するために必要な考え方」について解説することで（MB）SEを適用する際に気を付けるべき前提のご理解へのご参考にしていただければ幸いです。本稿には、過去に筆者が寄稿した記事^［1］の一部を利用して執筆していることについてあらかじめご留意ください。

改革（Transform）の本質

DXの幻想

DXの本質とは、デジタル技術を用いて変革をすることにあると先に述べました。ちまたではDXという言葉で単純なDigitizeや、ちょっとしたDigitalizeをDXと称して販売されることが散見されるように思われます。先に言及したトランスフォーメーションの話を前提とすると、既存の組織や構造の上にデジタルシステムを乗せようとしてもチグハグなシステムになってしまうことが起こります。

また、ITベンダが提供する各種ITツールは、前提となっている方法論や考え方が必ず存在します。例えば、PLM（Product Lifecycle Management）やALM（Application Lifecycle Management）は欧米で製品開発やソフトウエア開発を管理する方法として検討されてきたものであり、欧米の文化や業務プロセスを前提としてITツールが開発されています。日本で広まっているPLMやALMのITツールの多くは欧米のITベンダが開発したものであることからも、ITツールをそのまま導入するだけですぐに使えるようになる代物ではないことがお分かりいただけると思います。

つまり、ITツールの導入一つ取っても、組織構造・業務プロセスなどのエンタープライズアーキテクチャ全体を有機的に組み替えていくことが本来求められるというわけです。ITツールさえ導入すればDXが実現できるのではなく、トランスフォーメーションした未来を描き、その未来の実現に向けた各種プロジェクトを展開することがDXのような改革に不可欠であるということになります。

新しい仕組みを既存の仕組みに
載せるために

DXを実現するためには本質的に組織体を含めた仕組みを0から構築する必要があると先に述べました。しかしながら、そのようなことは現実的に難しいというお客さまが大半であると思います。そのため、現実的なアプローチとして「カイゼン」が行われるかと思います。この「カイゼン」という言葉が非常に厄介もので、表面的なものをいくら変えたとしても問題の真因にたどり着かないことが多々あります。そこで、次より適切な「カイゼン」を実現するための考え方についてご紹介します。

DXのようなパラダイムシフトを乗り越えるための考え方として、新しいシステムをいかに設計し、運用すべきかについてJames Martin氏は図3（Seven Samurai）のようなフレームワークを提供しています ^[5]。このフレームワークは問題対処のために別のシステムを適用すると別の問題を引き起こしていくことについて言及しています。例えるなら、沖縄県のハブを駆除するためにマングースを連れてきたらハブを捕食するのではなく、想定に反して別の固有生物を捕食するようになってしまったという状況と同じようなことです。

そのような状況に対するトータルな仕組みとして7つの要素を考慮したシステムを構築することの重要性について述べています（厳密には要素が7つ以上存在する可能性の指摘に対してJames Martin氏本人も認めているところはあるものの、彼が黒澤明監督の映画『七人の侍』が大のお気に入りで、なんとか7つの要素にしようと試みたのが実情だとか）。

まず、運用中のシステム（S1）を考えます。このシステムは、製品開発における開発プロセスや、企業の事業システムなど、さまざまなレベルのものとして考えられる代物です。

運用システム（S1）において問題（P1）が発生したとします。この問題に対処するために介入システム（S2）が適用されることになります。この介入システムは実現システム（S3）によって生み出されます。介入システムはそのまま現実の問題に対して適用できれば良いのですが、実行環境の様々な影響により、エラーや性能低下などが発生しうります。それにより介入システムは実際に展開されるシステム（S4）と成ります。展開システム（S4）は他に存在するシステムと連携されうります（S5）。ここまでの流れを通じてこれまでの運用システムが問題解決後のシステム（S1’）と成ります。新しく生まれた運用システム（S1’）を維持するためのシステム（S6）は実現システム（S3）が開発します。ここまでの一連の構造は、ある主体が問題解決をするものです。この主体をある企業の一組織が実行すると想定すると、別組織が同様に問題（P1）に対処しようとすることが想定されます。そうすると、別の介入システム (S7）が運用システム（S1’）に適用され、別のシステムが展開されます（図中波線展開システム）。展開システム（S4）はこのシステムと競合が発生することが想定されます。

問題に対処して運用システムをカイゼンしていくためには、Seven Samuraiのような要素全体を考慮する必要があります。この考えを用いることで、導入してから問題が多発する、という状況を事前に防ぐことができます。

おわりに

本稿では（MB）SEの導入や適用する前に、どのような考え方を知っておくことが重要なのかをDXという言葉の危うさと共にSeven Samuraiという考え方をもってご紹介いたしました。

単純なデジタル化やツール導入のレベルでもSeven Samuraiで表現されるようなさまざまなコンフリクトが発生することとなります。一方で、このような考え方を知らずにカイゼンだけを進めようとすると場当たり的な対応になってしまい、将来的に大きな問題が発生することにつながる可能性があります。

今回は（MB）SEがはやり言葉になっている今だからこそ、その前提として押さえておきたい考え方についてご紹介しました。

関連するソリューション

• MBSE/MBDソリューション

関連するソリューションの記事