モノ売りからコト売りへシフトするIoT時代の製造業が着目すべき、「継続的エンジニアリング」（Continuous Engineering）とは何か

昨今の製造業が作り出す製品はその多くが、ハードとソフトで成り立っているが、その比率は変化している。また、IoTの本格化に伴い、モノを作るだけにとどまらずモノを通じてサービスを提供する“製造業のサービス化“も考慮すべき課題として挙げられる。その変化に対応するモノづくりの考え方として着目すべきなのが「継続的エンジニアリング（Continuous Engineering）」だ。変化するモノづくりに継続的エンジニアリングの手法がなぜ必要なのか、なぜ有用なのか、解説する。

[PR／MONOist]

変わるモノづくりのスタイル

　「モノづくり」というキーワードを聞くと、昔ながらの日本製造業を想像される方も多いかもしれないが、この日本という国を支える製造業の世界も日々変化し、世界的な競争の波にさらされている。品質もさることながら、より重要なのは競争に勝つためのスピードと顧客ニーズへの対応であり、その要求は日々複雑化している。では、以前までの製造業に求められる開発スタイルと、どのような部分で違いが出ているのだろうか。

日本アイ・ビー・エム　Watson IoT 営業部 テクニカルセールスの徳島洋氏

　日本アイ・ビー・エム　Watson IoT 営業部 テクニカルセールスの徳島洋氏は、モノづくりにおけるソフトウェアの比重が高まっていることを指摘する。モノづくりの世界において「製品」とは、メカ、エレキといったハードウェアとソフトウェアを組み合わせることで成り立っているが、現在、その比率に変化が見られるのだ。

　自動車を例に見てみよう。自動車業界では従来、開発においてメカとエレキの要素が大きく、ソフトウェアの比重は低かった。しかし、最近ではハイテク化が進み、障害物が前にあれば止まるようなADAS（Advanced Driving Assistant System：先進運転支援システム）の導入は既に盛んであり、さらには、自動運転や車をネットワーク端末として定義し様々なサービスに組み込もうとするコネクティッド・カーにおいては、車自身がIT技術の塊のような存在になりつつある。

　ハードウェアとして車両の進歩も止まらず進んでいるが、ハイテク化が急速に進む中、開発におけるソフトウェアの割合は増えており、それはプログラムのコード量や複雑性がさらに増していることも意味している。つまり、想定する品質で市場や顧客ごとのニーズに対応しようとすれば、それだけ管理の手間やコストが増大するというわけだ。

　また、現場は市場ニーズに応えるために、より開発スピードを要求されるようになっているが、昔ながらのスタイルで要素ごとに別々に開発を行っていくと、互いの整合性をとる部分で時間がかかってしまう。

　車の例でいえば、市場は日本だけでなく、欧州や米国もターゲットとなり、各国の法規制や要求に個別にしかも、スピード感を持って対応しなければいけない。既存モデルをベースに新車種を作る際には開発時に蓄積した知見の再利用が有効な手段となるが、これがなかなか実現できない。

　こうした問題はなにも車の開発だけで起こる問題ではない。IoT（Internet of Things）化の進む産業機器――組み立てラインのロボットアーム――を例にしてみよう。旧来のロボットアームに求められた要件は正確な動作と長期の利用に耐える信頼性、低いランニングコストといったものだった。

　しかし、ロボットアームも、内蔵する制御プログラムによる単純な実行だけではなく、PLC（プログラマブル・ロジック・コントローラー）による柔軟なプログラマブル制御が一般化している。さらには人感センサーなどを組み合わせた人との協調作業、Industry4.0の構想に見られるロボット同士、またはロボットとクラウド、ロボットと人といった相手を限定しない協調作業とより高い作業柔軟性が求められるに従い、ソフトウェアの占める割合は旧来の比ではないほどに高まっている。

　また、ロボットアーム（産業用ロボット）の使われる場所は日本国内とは限らない。欧州には欧州の、米国には米国の順守すべき基準や安全規格が存在し、それらの国と地域、生産する用途に合わせた細かな対応ができなければ競争力を失ってしまう。つまり「ハードウェアのスペックが高い」だけでは競争に勝てない時代が到来しており、要求や仕様策定といった上流工程を含めた、開発工程の見直しが求められているのだ。

　車にしてもロボットにしても、製品カテゴリー自体は以前から存在する。完全な新規製品だとしても、開発の土台となった製品は必ず存在する。しかし、なぜ、既存製品がありながらもこのような事態に陥るのか？

　徳島氏はベースモデルを開発した担当者の情報やノウハウが引き継がれず、さらに連携する要求文書や設計文書、コードやテスト成果物同士の相関関係が分からず、開発成果物そのものが肥大化しやすい傾向があるためだと説明する。加えて言えば、現担当者が「今動いているモノに怖くて触れない」という心理状況に陥り、結果として既存コード／製品の改良にまで踏み込めない自体も見受けられると話す。

　徳島氏はトレーサビリティの問題も指摘している。前述のように知見の再利用におけるコードのコピーは常套手段だが、単純にコピーを行うだけでは依存関係が切れてしまう。仮にAというモデルの車のコードをコピーしてBという新モデルを開発し、後にBで問題が発生したとする。この場合、実はAにも潜在的に問題が発生している可能性があり、こうした問題の追跡は単純なコピーでは難しい。2つのモデルを例にしたが、実際にはより多くの派生モデルが存在することが普通で、この場合の発見はより困難になる。

“モノ売りからコト売りへのシフト“へ対応するため、継続的エンジニアリングができること

　自動車にしても産業用ロボットにしても既に“つながる“ことを前提とした――IoTを前提とした――製品企画が必須であり、それは他の製品においても同様だ。水道メーターでもエアコンであっても、他のモノあるいはネットワークにつながることで、製品単体を超えた価値を提供しなくてはならない時代になっているとも言える。

　つまり、現在の製造業には単純なデバイス開発だけではなく、“提供するサービス”まで視野に入れた設計開発（IoT化・つながる化を前提とした製品開発）が求められているのだ。製造業はこれまで高い品質の製品を作れば良かったが、これからは作って市場へ投入した製品をサービスやソフトウェアの進化によって使い続けてもらう、モノ売りからコト売りへのシフト、いわば“製造業のサービス化“に対応していかなくてはならない。

　しかし、作り込みによる精度/品質向上を是とする気質やIoT化を前提とするために開発工程の複雑化（前段で述べた製品開発におけるソフトウェア開発の比重増加はその端的な一例と言える）もあり、その実現は容易とはいえない

　そこで登場するのが「継続的エンジニアリング（Continuous Engineering）」という概念だ。製品は一度作ってしまえば終わりではなく、継続的にメンテナンスや改良を行い、ときには問題解決のために過去にさかのぼってトレースを繰り返す必要がある。コードを含めた仕様書や設計図のバージョン管理だけでなく、リソースの相関関係を含めた全体図、そして問題を追跡するためのトレーサビリティが、これを実現するためのツールには求められる。

　モノづくりに重要なのは人材だといわれるが、一方で特定の人材に極度に依存することは、人の喪失やプロジェクトの終了とともに築かれたノウハウも失ってしまうことにもつながる。ツール導入の狙いは、開発スピードの促進とともに、こうしたエンジニアリングに関する情報共有にもある。IoTがうたわれるなか、組み込み機器におけるソフトウェアコードの複雑化や肥大化は今後より進むとみられ、ノウハウ共有や迅速なトラブル対応のためにも、統一的な管理環境はより重要になるはずだ。

　IBMでは、継続的エンジニアリング実践のためのツールスイートを提供している。同社では継続的エンジニアリング成功のために「エンジニアリング情報共有」「継続的検証」「戦略的再利用」の3つのプラクティスを提唱しているが、あくまでこれは理想的な姿であり、ツールの強制導入によって社内の作業フローに悪影響を及ぼすよりも、まずは「できるところから手を付ける」のが重要だ。社内での情報共有など、まずは効果がわかりやすく、作業フロー改善の余地が見込まれる部分からツール導入を検討してみるといいだろう。

IBMが継続的エンジニアリング実践のために提供するツール群

　同社が製造業向けに提供する開発ツールとして、スウェーデン企業のTelelogicを2007年に買収し、製造業で重要となる要求管理ツール「DOORS」やSysML/UMLモデリングツール「Rhapsody」に加え、製品ライフサイクルを可視化するRational Engineering Lifecycle Manager（RELM）、要求管理の次世代ツールであるDOORS Next Generation（DNG）、モデルをベースとしたコラボレーションツールであるRational Design Manager（RDM）を自身のポートフォリオとしている。

　これらツールを使うことで、要求から設計までのトレーサビリティ、要求とテストのトレーサビリティを管理し、影響範囲の特定や事前シミュレーションによるバグ潰しが可能になり、開発スピード促進や品質向上へとつながることが期待できる。特にTelelogic買収以前から欧米を中心に多くの大手製造業の顧客を抱えており、関連ノウハウを蓄積してフィードバックも得ている。

　次回では、このあたりの実際の業界での継続的エンジニアリングの取り組みや、IoTの世界におけるトレンドについてまとめていく。

この記事に興味のある方にオススメのホワイトペーパー

【ホワイトペーパー】
IoT時代の製品開発ノウハウ「継続的エンジニアリング」を知っていますか？
誰でも分かる「継続的エンジニアリング」 。いますぐ使える製品開発ノウハウを詰め込んだ小冊子を大公開！

---

【ホワイトペーパー】
自動車ソフトウェア開発におけるALM〜先端技術を追求するボッシュの挑戦〜
自動車部品大手ボッシュは、どのようにソフトウェア開発に取り組んでいるのか。IBMとともに取り組んだ自動車部門全体でのアプリケーション・ライフサイクル・マネジメント（ALM）についてご紹介