　昔ながらのモノづくりにおいては、特定人物に依存することでチーム全体やプロジェクトを引き継いだメンバーにノウハウや知識が伝えられず、これが後の開発やメンテナンスに影響を及ぼすケースも多い。この部分をシステム化し、ソフトウェアのコードや仕様の依存関係を明らかにすることで、複雑だった開発プロセスを簡易にし、チーム内の風通しを良くする効果も期待できる。

　開発においては、市場のニーズに応じる形で多数の派生品が登場し、管理すべきドキュメントやコードが膨大になることもあるだろう。また、トラブル時や関係機関の確認・認証の際には、必要な資料をさかのぼって調べる必要がある。これらの作業をツールである程度自動化しておくことで、必要な工数や管理コストは大幅に削減されるはずだ。

　ケース・バイ・ケースではあるものの、レギュレーション（法規制）の多い業界でこうした作業に割かれる時間は決して短いものではなく、作業効率向上や正確なトレーサビリティに対して、継続的エンジニアリングが大きな効果を発揮することになる。今回紹介する事例も、それが顕著である自動車業界のものだ。

自動車業界にいまALMが必要な理由

　世界的な自動車産業の集積地であるドイツに本社を構え、自動車部品供給の中核として国際的に知られるのがRobert Bosch GmbH（以下、ボッシュ）だ。日本にも拠点を有するボッシュグループは全世界で売上高約490億ユーロ、29万人以上（2014年末時点）の従業員を抱える巨大企業であり、自動車業界以外にも製造装置や工具、建築設備やホームアプライアンスといった分野で同ブランドによる製品や技術展開を行っている。だが売り上げの3分の2は自動車業界向けの部品や技術提供によるものであり、業界における役割もそれだけ大きい。

　現在、自動車業界は変化と革新の途上にあり、ユーザー層の拡大に合わせた細かいニーズへの対応や各国規制への対応、そして自動運転車や電気自動車など新技術への対応が進みつつある。

　特に後者において、自動車のシステム化推進によるソフトウェア比率の増大で開発負担も増えつつある。単純に部品を組み立てていくだけでなく、システムとして機能させるために互いが連携する必要があり、機能統合による予期しないトラブルへの対処など、課題は多い。

　また自動車の製造にあたっては多数の部品を組み合わせる必要があり、それに応じて参加する部品サプライヤー間での連携や品質の維持管理が問題となってくる。部品単体においても、より競争力を高めるために機能を向上させる必要があり、開発能力の向上が求められている。そこでボッシュが導入したのが「ALM（Application Lifecycle Management：ソフトウェアの開発や保守を各アプリケーションのライフサイクルに渡って継続的にプロセス管理する考え方）」の仕組みだ。

ツール導入の狙いとマイルストーン

　従来から存在する問題としては、作業工程ごとに使われるツールがばらばらで、しかもその一部が旧式で互いの接続連携が困難であり、全体を通した開発ワークフローの効率化やソフトウェア共有ができなかったことが挙げられる。しかもツールによってユーザーインターフェースが異なり、当該ツールを中心とした視点でデータにアクセスするため、全体の見通しが悪く、チーム間のコラボレーションが難しいという問題もある。

　また工程ごとにツールのサイロ化が発生することで、データの重複も多くリソース管理上の無駄が発生しやすい。前述のボッシュをみても世界中に開発チームが分散しており、コラボレーションにおける時間と地理的な制約も大きい。これらを相互連携させるための強力な仕組みが必要というわけだ。

　ボッシュはALM導入に際して、自動車分野全体にあたる24拠点への展開を想定しており、該当する製品ライン数は10、対象となるユーザー数は2022年までに5000人以上に達するという。安全に関する機能でありソフトウェアが複雑化しやすいことから、ALMの運用は当初ADAS（Advanced Driver Assistance Systems：先進運転支援システム）の分野で開始されたが、今後は自動運転分野を中心に展開されていくことになるという。ALMの導入によって同社では、通信にかかる工数や遅延を15％削減、進捗状況や品質分析により運営効率を20％改善、さらにはソフトウェア提供や変更における工数の大幅削減を見込んでいる。

　このような形でツール間のオンライン同期が行われ、手動で行われていた作業手順を最小限にし、ソフトウェア開発におけるALM全体をカバーするツールチェーンが構築されることで、部門横断的なソフトウェア開発や継続的エンジニアリングの構成要素の1つである「エンジニアリング情報共有」が効率良く行われるようになる。

　加えて自動車業界内に存在するさまざまな開発モデルのサポートや、各工程における業界標準への準拠なども考慮することで、個々のプロセスからプロジェクト全体の管理まで、一貫した品質管理や効率化が実現する。これは継続的エンジニアリングの構成要素である「戦略的再利用」の実現ともいえる。

システムアーキテクチャとインテグレーション

　ボッシュの導入したALMにおけるツールチェーンは、IBMのRational CLM（Collaborative Lifecycle Management）をベースにしたアーキテクチャ上に構築されている。ユーザーインターフェースはWebまたはEclipseで提供され、OSLC（Open Services for Lifecycle Collaboration）による機能拡張が考慮されている。

IBMのRational CLM（Collaborative Lifecycle Management）を基にしたボッシュのALMアーキテクチャ

　チーム間における相互連携はRTC（Rational Team Concert）で提供され、リソースやプロセス管理が行われる。これらツール導入に必要な各種開発やインテグレーション、トレーニングはボッシュのインドにおけるソリューション開発拠点であるRobert Bosch Engineering and Business Solutions（RBEI）が担当する。

　RBEIはボッシュグループにおけるシステムインテグレーター（SIer）のような役割を担っているが、同時に、そこで開発されたソリューションの全グループ企業への展開や外部への提供も行っている。

Robert Bosch Engineering and Business Solutions（RBEI）はグループ内のインテグレータとしてIBM RTCをベースにしたシステム開発を推進している

　同社では、製造業におけるOEMのような業態や自動車業界のように複雑なサプライチェーンにおいて、相互の会社が安全でシームレスにデータ共有を行える仕組みとしてSmartXWeaverを提供しており、製品のライフサイクル全体を管理できるようにしている。年々複雑化しつつある車載ソフトウェア開発や自動車のサプライチェーン管理において、それだけ重要な役割を果たしているといえる。

　今回紹介したボッシュの事例は比較的大規模なもので、その目的は、同社売り上げの多くを占める自動車分野の開発効率向上だ。しかし、ただ開発効率の向上だけが「継続的エンジニアリング」の導入で実現するメリットではない。

　製造業を取り巻く課題は多い。課題は開発以外の効率化や製品バリエーション増加といったユーザーニーズの多様化、法令順守（トレーサビリティ）実現に欠かせない「継続的検証」の実現など多数あり、企業によっては単なる開発効率向上にとどまらず、社内フローの大幅な改良を検討しているケースもあるだろう。

　特に製造業においてはIoTへの対応やインターフェースのリッチ化などでソフトウェアの複雑化が進んでおり、こうした分野で「継続的エンジニアリング」の考え方とそれを構成するツール群の導入が検討されている。まずは問題の洗い出しと目標立案からスタートし、その必要性を見極めていきたい。

　「継続的エンジニアリング」の実現に向けたアプローチは各社さまざまだと考えられるが、特にこうしたソリューションの必要性が高い企業の場合、長年にわたって蓄積された資料やデータが膨大となっていることが多く、その開発システム（開発フロー）もまた、拡張が積み重なり複雑化しているケースも多いと考えられる。

　作業工程ごとにチームは別々に存在しており、互いが連携して作業することはあまり考慮されていないというのは、ボッシュでも見られた現象だ。継続的エンジニアリングを目指してのツールの導入は、導入によるコスト削減効果を目標としつつも、こうした既存の作業フローをあらためて見つめ直すための好機でもある。ぜひそのあたりを念頭に、その価値を検討してみてほしい。

・IoT本格化のなかで製造業が“モノづくり競争力”を維持するために――スピード開発の実現と複雑化する顧客ニーズへの対応

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