BETA

"MBD"開発とものづくりの今後 ~デジタルとアナログの無境界化とデザイン~

投稿日:2020-01-30
最終更新:2020-01-30

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

先日、知人のウェブデザイナーと話す機会があり面白いチャートを見せてもらった。

彼が抱えるデザインチームのメンバーのスキルが一覧表になっている。今できること、今後必要になるスキルが一目瞭然だ。

UX, UI改善を目的としたWebサイト改修

アニメーション作成

動画編集

インフォグラフィック作成

3D技術による画像作成・編集

面白いことに、今後一層マーケットから需要の高まるスキルとして「3D」が挙げられていた。ひとたび、街中に目を向けるとVRなどの仮想現実技術を使ったポップアッププロモーションも増えているが、導入コストや効果の観点からは今のところはまだ「3D」が現実的な要件なのだという。

さて、この記事を読んでくださる方の多くはウェブデザイナーではないはずだ。気になるのはエンジニアリングにこの話はどう関わるのかということであろう。

この記事では、「Model-based Design」をキーワードに、今後のものづくり技術に求められるプラットフォームとその適用について考察をしていく。

Model-based Designの2つの課題

大きくデザイン・設計の世界に目を向けると、エンジニアリングの世界ではかなり前から3D CADを用いた設計図作成は「常識」である。これ自体は何ら目新しいものではない。

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

※ MBDのプラットフォームはソフトウェア開発においてはC、C++ のコードやHDL( VHDL 、Verilog )で作られることが多い

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

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

ものづくりの匠の「経験と勘」による「お任せ」で上手く回っている現場は今でも多い。だが、今後の開発要求とマーケットの変化のスピードを考えると、ここばかりに頼れないと考える組織も多い。

AI, IoTなどのテクノロジーが一般化し、アナログ世界をデジタルに切り取る「デジタルスレッド」の時代がハードウェア・ソフトウェア開発の世界にも訪れて久しい。このような状況を受け、注目されている開発モデルがある。The MathWorksが提唱した「Model-based Design Workflow (MBD)」である。

これは共有されたモデル(コード)、グラフィックデザインのなかでシステムテスト、シミュレーションを行うことで設計段階の理解の深化、開発の各段階の連続性を高めることに役立つ。さらにはコードの間違いなどによる手戻りをふせぐことで効率的な開発を実現する効果がある。

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

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

多くの注目を集めているとはいえ、MBDはむやみやたらに導入して効果のあるものではないーということを覚えておいてほしい。この開発手法の成功には組織改革を含む戦略的な施策が必要となる。

MBD成功のポイントは開発プロセスを「完全に」データ化することである。これがなかなか難しい。

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

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

そんなMBDが組織に理解され、プラットフォームが整備されるとその真価を発揮する。

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

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

(1)効率的な開発とコスト削減

・コミュニケーションコストの低減 (本社機能と開発現場が異なる国、地域というケースは特に重要)

・ドキュメントミスの減少 (内容もさることながらドキュメント自体の量の削減にも役立つ)

・コードミスの減少

(2)知識継承

・各開発プロセスにおけるコードの再利用

・開発レベルの維持 (常に正しい開発ソースをもとに開発できるため)

MBDはものづくりの開発体制が多様化し、アウトプットデータをもとに改修を繰り返すようなプロジェクトにとっては有用なモデルだと言えるだろう。

多くの場合、メリットを口頭で説明しても最初から組織に理解され、説得することは難しい。

今できていることを「ベター」にするよりも、現状維持によるパフォーマンス発揮のほうがリスクが少ないと考える人が多いためだ。

特にそのイニシアティブに緊急性がないと判断されれば現場の抵抗になりかねない。

ものづくりの未来を考えるとき、そこにすぐ目に見える「緊急性」がなくとも、来るデジタルーアナログ無境界化の世界ではその「必要性」があることは確かである。

現状、そこに気付いた企業・プロジェクトから開発体制、プラットフォームのシフトチェンジをはじめている。

この記事を読んでいただいたエンジニアの皆さんは現在の開発環境、今後の戦略をどう考えるだろうか。

技術ブログをはじめよう Qrunch(クランチ)は、プログラマの技術アプトプットに特化したブログサービスです
駆け出しエンジニアからエキスパートまで全ての方々のアウトプットを歓迎しております!
or 外部アカウントで 登録 / ログイン する
クランチについてもっと詳しく

この記事が掲載されているブログ

@Techtekの技術ブログ(nyuPATBwgCcZNaVr)

よく一緒に読まれる記事

0件のコメント

ブログ開設 or ログイン してコメントを送ってみよう