ものづくりの未来とモデルベース開発 ～デジタルとアナログの無境界化とデザイン～

はじめに　～ものづくりの現在～

先日、Webデザイナーの知人との話しの中で、彼のデザインチームメンバーのスキル一覧表を見せてもらう機会があった。現在の保有スキルと今後身に着けるべきスキルがまとめられていたのだが．．．

• UX, UI改善を目的としたWebサイト改修スキル
• アニメーション作成スキル
• 動画編集スキル
• インフォグラフィック作成スキル
• …
• 3D技術による画像作成・編集

面白いことに、今後需要の高まるスキルとして「3D」が挙げられていた。昨今街中に目を向けるとVRなどの仮想現実技術を使ったポップアッププロモーションが増えており、Webデザインのスキルとしても「VR」が求められるかと思っていたが、「導入コスト」「効果」の観点からは今のところはまだ「3D」が現実解なのだそうな。

さて、この記事の読者はWebデザイナーよりHW技術者の方が多いだろう。HW技術者にとってこの話はどう関わるのかということであろう。

MBD（Model-based Design）とは

広くプロダクトデザインの世界に目を向けると、製品開発の世界でもかなり前から3D CADを用いたモデル作成は当たり前の用に行われてきた。これ自体は何ら目新しいものではない。

しかしながら近年、IoTプロジェクト、およびソフトウェアのアジャイル開発で注目が高まる「Model-based Design(MBD)」という観点でものづくりの現場を見てみると、開発プロセスのなかで「完全（3D）データ化すること」*そしてその3Dデータを「組織で共有し効率的に活用すること」、この2点は未だに多くの企業で達成できていない。

MBD（モデルベース開発）とは、実機を仮想環境上にシミュレーション可能なモデルとして構築し、”設計→検証”を繰り返す設計手法のことで、特に宇宙航空、産業機器、自動車業界等で採用されている。MATLABを提供するMathWorks社によって提唱された考え方だ。従来よりもプロジェクト初期段階で最終仕様の細かい部分を詰めることができるので、試作回数を減らせ、先々のソフト開発工数を削減することができる。その一方、開発初期のモデル作成に工数を取られるので、業界によっては余計な工数が膨らむ危険性もある。

一般的に、ソフトウェア開発においては *MBDのプラットフォームはC、C++ のコードやHDL( VHDL 、Verilog )で作られることが多い。IoTではハードウェア端末のモデル化として3Dデータを活用する流れがある。

IoT端末開発におけるMBD

IoT市場では、消費者や製品のまわりで起こっているあらゆることをメーカ側がデータとして知りえるようになってきている。現実世界で取得されるこのデータはすさまじい量となる。ものづくりの現場ではそのデータを得た生身のエンジニアがテスト・検証を繰り返し、開発部門に改修要求を出す。フィジカルの世界で起こった製品まわりの「アナログ」を「デジタル」に映しとっていく作業だ。（いわゆる「デジタルスレッド」と呼ばれる）

このように開発現場、特に自動車開発、航空、宇宙開発の領域では、デジタルとアナログの境界が混ざりあうようになり、開発プロセスには日々大量のデータ・シュミレーション・プロトタイプ開発・検証作業が行き交う。まさに大渋滞である。

たしかに、そのようなモデルに時間を取る事もなく、匠の「経験と勘」で上手く回っている開発現場も少なくない。だが、今後の開発要求とマーケットの変化のスピードを考えると、ここばかりに頼れないと考える組織も多い。

AIやIoTなどを活用したものづくりでMBDを取り入れた場合、クラウド、端末、制御ソフトをモデル化し、各フェーズの開発者と共有できていれば、最終サービスの共通したイメージを持つことができ、各フェースの適正なアウトプットを判断しやすくなる。これにより各フェースにおけるの手戻りを大幅に削減できるだろう。さらには営業部門や運用保守部門からの有益なフィードバックを得ることも可能だろう。

この手法は自動車・航空・宇宙開発・国防などの大規模製品開発の場面でよく出されるベストプラクティスであり、一般的には小規模～中規模のプロジェクトや製造業には向かないとされてきた。

しかし昨今のテクノロジー活用を受けて、このモデルの価値に改めて目を向けるリーダーが増えている。ハードウェア開発のメーカーでいえば自動車メーカーのマツダ、ソフトウェア開発の観点ではアクセンチュア、IBM、Oracle、Microsoftが開発手法の実現化を進めている。

多くの注目を集めているとはいえ、MBDはむやみやたらに導入して効果のあるものではないーということを覚えておいてほしい。この開発手法の成功には組織改革を含む戦略的な施策が必要となる。MBD成功のポイントは開発プロセスを「完全に」データ化することである。これがなかなか難しい。

自動車業界を例に挙げよう。先に紹介したマツダは開発段階で３D CADの完全なデータ化に苦戦した。将来的な開発要求、後工程でのバリフィケーション効率化のために、全工程で共有する「データ」は完全である必要がある。

これまで、開発現場の熟練の頭のなかにあったことをデータにすべて落とし込むことは難しい。技術的なハードルもさることながら、「なぜ今ここでそこまでやる必要がある？」という心理的なハードルも高い。まさに現場の魂である技術を落とし込む、そして共有できるプラットフォームに載せるというわけだからその心理的抵抗も否めない。「より良いものづくりをする」という信念のもと、MBDモデルの導入にあたっては計画的な組織改革が必要となる。そんなMBDが組織に理解され、プラットフォームが整備されるとその真価を発揮する。

MBDの本当の価値　～ものづくりの未来を支える２つのこと～

MBDのメリットは大きく分けて次の２つがある。

（１）開発効率の向上（コスト削減・期間短縮）

• 遠隔開発のコスト低減（本社と開発部門が遠隔地にあるケースでは特に重要）
• ペーパーワークの減少（ドキュメント作成業務の削減と効率化）
• コードミスの減少

（２）知識継承

• 各開発プロセスにおけるコードの再利用
• 開発レベルの維持　（常に正しい開発ソースをもとに開発できるため）

MBDはものづくりの開発体制が多様化し、アウトプットデータをもとに改修を繰り返すようなプロジェクトにとっては有用なモデルだと言えるだろう。多くの場合、メリットを口頭で説明しても最初から理解されることは難しい。むやみな理想追従よりも、現状維持によるパフォーマンス発揮のほうがリスクが少ないと考える人が多いためだ。

しかし一歩先の未来のものづくりを考えた場合、遅かれ早かれMBDのアプローチに移行することは間違いがない。全ての実機をモデル化し、検証→設計 を繰り返すことが、組織全体としてのあるべき姿だと言える。現状、そこに気付いた企業・プロジェクトから開発体制、プラットフォームのシフトチェンジをはじめている。開発部の各部門の部分最適からIoTサービス組織としての全体最適をめざし始めている。

この記事を読んでいただいたエンジニアの皆さんは、今後の製品開発プロセスはどうあるべきだとお考えだろう？

ご参考：