モノづくり企業がソフトウェア企業でもあるべき理由 | 反応性と競争力を高めるために

記事をシェアする:

 

デジタル変革の大きな波が、製品開発にもやってきています。

従来のビジネスのあり方を大きく変革させるデジタル変革は、製品開発の根幹をソフトウェア集約型へと変化させるものです。この大波を正しく捉え、既存のシステムをソフトウェアと統合することができれば、モノづくり企業は大きな差別化と強い競争力を手にすることができます。

 

デジタル変革は、製品設計、モデル化、開発、テスト、変更、管理、および製品の市場への投入と展開方法という、企業活動のさまざまな点に根本的な変化をもたらしています。

技術レベル、規制、ビジネスの複雑さは増し続け、さらにそれを上回るスピードで桁違いの量へと増加するソフトウェア…。リアルタイムデータの可視化向上とエンジニアリングプロセス最適化の必要性は高まり続けるばかりです。

 

そんな中、デジタル変革により劇的に増え続けている新たな機会を手にするには、メカ・エレキ・ソフトの情報をシステム・オブ・システムズ（個々に運用・管理される複数のサブシステムが統合されたシステム）全般に渡って統合し、IoT（モノのインターネット）データの全てを包含させることが必要なのです。

 

■ システム・オブ・システムズ – ボーイング社の失敗に学ぶ

適切なエンジニアリング・ライフサイクル管理を、的確にインテリジェント・システムに組み込むことがいかに肝要か — それをわかりやすく伝えてくれるのが、カプセル型宇宙船打ち上げ後にソフトウェアの欠陥が複数発見された先日のボーイング社の宇宙船「スターライナー」のケースではないでしょうか。

失敗の発端は、スターライナーのタイマーが誤った時間にリセットされ、結果燃料を早すぎるタイミングで使用されてしまった結果、国際宇宙ステーション（ISS）にまでたどり着けなかったことです。

 

しかしそれ以上の大問題は、この問題の解決にあたっていた途中で、ソフトウェアの重大な別の問題が発見されたことです。この大問題は、解決されなければスターライナーが地球大気圏に再突入するときに大惨事を起こす可能性があるというものでした。

大気圏再突入までの限られた時間で対応できなかったときには…。

 

この大失敗は、他システムと関わり合っているソフトウェアの一部に対するテスト不足に起因するものでした。ボーイング社は世界を代表する航空工学企業でしたが、残念ながらシステム・オブ・システムズを十分理解しているソフトウェア企業ではなかったのです。

ボーイング社は、この失敗により数億ドルの費用を被ることとなるでしょう。

 

莫大な量へと増え続けるソフトウェアに対応し、継続的に安全性を重視したエンジニアリングを進めるには、自動化と効果的なモデルが必要となります。

幅広いパートナーやサプライヤーからなるエコシステム全体で数万以上の要件を管理するチームには、これだけの複雑さに対応し処理することのできるソフトウェアソリューションが不可欠です。

その存在により、チームはハードウェアの準備が整う前から、インターフェイスを適切に定義した上での十分なテストを実施できるのです。

 

複雑なタスクの分析とレポーティングを自動化することで、主要なステークホルダーへ高い可視性を提供することができます。その可視性の高さがチームのデータ再利用を促進し、結果として製品の市場投入までの時間が大幅に短縮されます。

すでに十分に調査とテストが行われていて、その結果が再利用できるときに、車輪の再発明は必要ないのです。

また、リアルタイム性の高いレポーティング機能が用いられれば、進行および達成状況はすばやくかつ広く共有されるようになります。そうすれば、メトリクスを用いて、イテレーションの進み具合と計画と現状のギャップが簡単に確認できるようになります。

 

あらゆる開発イテレーションにおいて、ハードウェアとソフトウェアの品質と性能、そしてリスク管理における基礎となるのは検証と妥当性確認です。

アジャイル開発手法を採用し、スプリント期間の境界を明確にし、さまざまな種類の統合テストを導入することにより、ソフトウェアチームはより広範囲に、長期イテレーションに対して検証と妥当性確認のためのテストを実行できるようになるのです。

 

■ DevOpsとデジタルエンジニアリング

デジタルエンジニアリングとエンジニアリング・ライフサイクル管理（ELM）の一部である DevOps プラクティスに、機械学習と高度な分析を適用することで、チームの生産性は大きく向上します。

コンプライアンス評価や、計画と現状のギャップ評価はより早くより正確になり、状況に適した計画の調整や変更を行えるようになります。

 

例えば、以前であればチームは要求の確認やチェックにパターンマッチングスクリプトを作成していました。でも、それが活用されることは非常にまれでした。なぜなら、スクリプトに用いられていた言語は、文脈を理解することができないからです。

実際のところ、複雑な要求におけるマッチングはおろか、シンプルなものですらほとんどそれを活かせなかったのです。

 

しかし現在は、ELM機能が提供する自然言語を用いたルールツリーを適用すれば、文脈を汲み取り要件を明確にし、問題を品質チェッカーにより特定することができるようになりました。

このような機能を要件や品質分析に適用することで、国際システムエンジニアリング協議会「INCOSE」が定義する、業界標準に則ったレベルの品質を担保することができるのです。

 

クラウドを通じてこれらのELM機能にアクセスするには、開発環境との連携および調整が必要です。組織には複数環境が混在しているため、さまざまな自動化とエンジニアリング・ライフサイクルフェーズ間が同期されなければなりません。

組織には複数環境が混在しているため、クラウドを通じてこれらのELM機能にアクセスし、さまざまな自動化とエンジニアリング・ライフサイクルフェーズ間を同期させるには、開発環境との連携および調整が必要です。

 

エンジニアリング・ワークフローの変更管理、品質管理、モデルベースのテスト、および開発ライフサイクル全体にわたる調整と可視化を可能とする要件へのリンク — これらの機能は欠かすことができません。

中でも、エンジニアリング・データにおいては、複雑さに対応するために欠かせないのが正確で適切なバージョン管理であり、変更とそれに関わる要件と品質への関連付けは、ELMプロセスの可視性と管理を共有するために不可欠です。

 

ELMシステムは、さまざまな環境が共存する現在のオープンな状態を踏まえたものでなければなりません。

オープンなインタフェース規格OSLC（Open Services for Lifecycle Collaboration）などを用いて異なるシステムやツール群をつなぎ、開発環境におけるベースラインを整え、複数ツールからモデルをロードし、モデルと要件間のリンクを作成する方法を提供できなければならないのです。

そして複数ツールが統合されている状況でも、モデルのバージョン更新タイミングを選択できるようになっているなど、システムの進化と同期してユーザーがより広範に適切な選択ができるものであるべきでしょう。

 

現在は、単純な製品でさえシステム・オブ・システムズにより複雑化しています。それぞれの影響と依存関係は、追跡可能な状態を保っていなければならないのです。

グローバル構成というコンセプトは、システム変更に対する複数レベルの変更を可視化するツリー制御という概念を提供します。

要求やコードが更新されたときには、テストも合わせて更新されなければなりません。そしてテスト結果も、特定のテストに対する結果として適切に記録・保持・更新され、常に最新の変更管理結果が参照できる必要があります。

 

こうしたシステムは、いわばロシアのマトリョーシカ人形のようなものと言えるかもしれません。システム本体に関連する要件、アーキテクチャ、設計、テスト、および変更管理というレイヤーの中に、それぞれ複合レイヤーが存在しています。

単一デバイスを理解すると同時に、それが他システムと共に全体を構成する一部であることが十分理解され、それが他システムにどのように影響しているか、どのような相互依存関係にあるか。それが正しく理解されていることが絶対に必要となります。

そしてこれらの可視性が高ければ、柔軟性は大きく高まり、開発時間の短縮とコストの削減、そして品質担保にも大いに貢献するのです。

 

デジタル変革に必要とされるELMシステムは、成功したプロジェクトの文書化された基本モデルを取得し、要件、モデル、テスト、バリアントを再利用してすばやく構築することができなければなりません。

最後に、そうした観点から、世界トップクラスのIT専門調査会社IDCの提言を紹介します。

 

■ エンジニアリング・ライフサイクル戦略へのIDCの提言

IDCは、次の4つのステップを推奨しています。

1. 「優秀なヒーロー」に頼ったリスクのある開発手法ではなく、協調的なアジャイル・アプローチを製品と関連ソフトウェアの作成と再利用を推進するエンジニアリング手法を採用する。
2. エンジニアリング・ライフサイクル管理の現在の成熟度レベルを評価することから始める – 主要なギャップの確認、プロセスと自動化戦略の確立、最大のペインポイントとビジネスメリットの明確化など。
3. このアプローチを利用して、要件から品質、変更管理、コンプライアンス、製品リリースに至る製品ライフサイクルフェーズ全体にわたり関係するメカ・エレキ・ソフトの全チームを集める。
4. 機械学習やAIなどの先進テクノロジーと、精度や対象範囲を広げ続けている高度な分析技術を存分に活用できるよう、複雑化を増すシステム・オブ・システムズとIoTソリューションに適合した統合エンジニアリング・ライフサイクル戦略を作成する。

 

問い合わせ情報

お問い合わせやご相談は、Congitive Applications事業 cajp@jp.ibm.com にご連絡ください。

 

関連ソリューション: 全社規模でのシステム・エンジニアリング

 

関連記事: 製品ライフサイクル全体を統合するソリューション「IBM ELM7.0」発表

関連記事: 「CASE時代のクルマづくり基盤」セッションレポート @東京モーターショー

関連記事: 市場調査会社Ovum社が、IBMをALMおよびDevOpsソリューションの業界リーダーに指名

---