今日のアプリストア主導のビジネス環境では、多くの従来型のハードウェア製造業の皆さんは、かつてビジネスの本質であったハードウェア製品が、ソフトウェア製品やサービスを運ぶための単なる手段になっていることに気づいていることでしょう。
アップルはiPhoneで携帯電話の世界を変えました。かつてハードウェアに焦点を当てていたこの製品カテゴリでは、アフターマーケットアプリストアに突然カスタマイズが追加されました。新しい特徴と機能が無線通信で提供されるようになりました。過去10年間、テスラは同様のパラダイムシフトを自動車の世界に押し広げてきました。多くの人が自動車業界におけるプラットフォームのチャンピオンと見なしているフォルクスワーゲングループは、2030戦略において、統合ソフトウェアプラットフォームが統合メカトロニクスプラットフォームと同じくらい重要であることを明確に示しています。
実際、多くの元ハードウェアビジネスエグゼクティブは、ハードウェアビジネスがソフトウェアビジネスに変わりつつあることを目撃しています。かつてはエキスパートなメカニカルエンジニアに依存していましたが、今日の企業ではCADよりも多くのSWコーダーを持っていることがあります。
現在、顧客価値、カスタマイズ、およびパフォーマンスの多くはソフトウェア主導であるため、ソフトウェアアーキテクチャにその重点が置かれています。それぞれが特定の製品プラットフォームをサポートするために開発された複数のソフトウェアモノリスのレガシーを抱える企業は、既存の状態から、製品専用に統合開発された効率的なソフトウェアアーキテクチャを利用して最大のパフォーマンスと顧客価値を生み出し、開発作業と時間を最小限に抑えながら、新しいバージョンに移行するという複雑な課題に直面しています。
このブログでは、ソフトウェアアーキテクチャ、特にハードウェアと電子機器をソフトウェアと組み合わせた製品の基本的なベストプラクティスを共有します。しかし、最初に、ハードウェア製造業が今日直面しているソフトウェアに関連するいくつかの重要な課題を見てみましょう。
ハードウェア製造業における典型的なソフトウェアアーキテクチャの貧弱な症状
この章では、ソフトウェアアーキテクチャが明確な戦略なしに時間の経過とともに有機的に開発されてきた企業の典型的な問題点について説明します。
スピード感
異なるソフトウェアのパーツを切り離す戦略がないため、すべてのソフトウェアが毎回同じ方法で「一度に」提供されます。すべての機能が一直線に並んでいないとリリースされません。リリースに不可欠と判断された機能に遅れが生じると、リリース全体が遅れます。たとえ変更されていなくても、リリースのたびにすべてのコードを再テスト・検証する必要があるため、開発・イノベーションのスピードは低くなります。リリースは膨大であり、テストの労力も同様に大きくなっています。
これは、交通事故の車の列と考えることができます。すべての車線が1つに絞られて事故現場を通過し、より多くの事故を引き起こすリスクを伴う車の大規模な列を作成します。
図 1.機能が並んでリリースを待つ
複数のソフトウェアプラットフォームが同じ機能を実装していても、異なるハードウェアプラットフォームに向かっている場合、速度問題は悪化します。この問題は、ソフトウェアとハードウェアを組み合わせたプラットフォームごとに、テストと検証の努力をしなければならないことを意味します。これはソフトウェアプラットフォームへの機能展開をさらに遅らせることになります。
また、ハードウェアの違いにより、各ソフトソフトウェアプラットフォームに若干の違いがあるとします。その場合、同じ機能を繰り返し実装し直すことになります。最悪の場合、最新のハードウェアでリリースされたソフトウェア機能の中には、古いハードウェアに到達しないものもあります。レガシーハードウェアの開発・テストにかかる労力がかかりすぎてしまい、既存の顧客を置き去りにすることになります。
図 2.同様の機能を実装する複数のソフトウェアプラットフォーム
コスト認識
モノリシックリリース（ターンキー開発）のもう1つの問題は、個々の機能の開発にかかるコストを予測するのが難しい場合があることです。機能開発は、システム全体の大規模な統合とテスト作業に大きく依存しています。機能コストは、コストの多くが完全な統合を処理する別のプロジェクト、つまり「リリースプロジェクト」でカバーされるため、過小評価される傾向があります。「リリースプロジェクト」の透明性は低く、経営陣は、彼らがお金のために何を得るのかわからないまま、ブラックホールにお金を投げ込んでいるとしばしば信じています。
バグの発見と修正に関連するコストも、同じ理由で計算が困難です。ソフトウェアシステムの依存関係が明確ではないため、コードの複雑さの増加に関連する隠れたコストを計算する良い方法はありません。
品質維持
製品が十分な品質を持つことを保証するための努力は、通常、モノリシックにリリースされた製品では非常に大きく、時間がかかります。テストと検証の作業が1か月から数か月の間に見られ、テストに多くの物理ハードウェアを必要とする大規模なシステムテスト作業が行われることは珍しくありません。この問題は、変更がシステムのどの部分に影響するかについての理解の欠如が原因のひとつです。
しかし、ソリューションスペースが非常に大きいため、システムのすべての側面をテストすることは不可能です。したがって、変更が失敗したときに以前に問題が発生することがわかっているものはすべて再テストされます。
大きなリリースを行う速度は遅いので、いくつかの機能やバグ修正のために「小さな」リリースをしたくなります。この場合、時間を節約するために、選択したテストのみが実行されます。これらの小さなリリースは、変更の副作用がよく知られていないため、しばしば裏目に出る可能性があります。1か所で小さなバグ修正を行うと、予期しない場所に波及効果が簡単に発生する可能性があります。たとえば、新しい機能は、無関係なサブシステムが依存していたメモリまたは CPU リソースを消費する可能性があります。
拡張性がない
ソフトウェアシステムのスケーラビリティの問題が時間の経過とともに有機的に成長することは珍しくありません。メモリの増大やコンピューティングコア数の増加など、新しいハードウェア機能を活用するための努力は、かなりの開発努力なしに効率的に収穫することはできません。
また、システムをより小さなフットプリントにスケーリングすることも問題になる可能性があります。コードのハードウェア要件は十分に文書化されていないため、ソフトウェアをより小さなハードウェアフットプリントに絞り込むには多大な労力が必要です。必要なソフトウェアフットプリントを実現するためにビジネスクリティカルな機能を取り出す必要があり、市場で競争力のない製品を作成する場合があります。
柔軟性がない/ハードウェアとガチガチの関係
多くの場合、ソフトウェアはハードウェアとの結合が高いため、ハードウェアの変更に敏感になります。この依存関係は、2020年のコロナウイルスのパンデミックから始まった最近の世界的なマイクロチップ不足の問題で最近非常に明白であり、波及効果はまだ感じられています。
多くの企業は、15年前のチップ設計で古いハードウェア設計を市場に投入し続けています。これらの企業は、サプライヤーが15年前のチップ設計したくないため、代わりに最新のチップを導入することを余儀なくされています。彼らは、多くの「ベアメタル」ハードウェア設計(オペレーティングシステムなしの実装)のために、完全なソフトウェア書き換えをしなければならないというシチュエーションに直面しています。
ハードウェア製造業におけるソフトウェアアーキテクチャの6つのベストプラクティス
ソフトウェアのモジュラリティは、ソフトウェアが標準化されたインターフェイスを持つ小さなピースにどれだけ分解されているかを測定するものです。再利用可能なコードの塊を組み合わせて、ソフトウェア製品を作るという考え方です。そのため、ある特徴や機能の実装、テスト、実装を一度だけ行い、ハードウェア製品ポートフォリオ全体で再利用を最大化することができます。
ほとんどのプロフェッショナルソフトウェアは、すでに何らかの形でモジュラー化されています。実際、モジュラープログラミングは1960年代に考え出されました。ただし、多くの企業は、モジュラーソフトウェアアーキテクチャの可能性を最大限に活用できず、前述のように、ソフトウェアをモノリシックディストリビューションでリリースしています。この章では、モジュラーソフトウェアアーキテクチャのベストプラクティスをいくつか紹介します。
1.モノリシックソフトウェアアーキテクチャではなくモジュラーソフトウェアアーキテクチャ
モノリシックソフトウェアをモジュールに分割できるとします。その場合、それを開発、テスト、統合、およびリリースするためのより高速な方法を得ることができます。機能は、互いに影響を与えることなく準備ができたらリリースでき、バグはシステム全体に波及する副作用のリスクを冒すことなく修正できます。
前述の自動車事故の例では、モジュラー化とは、道路に車線を追加し、車線の1つで事故が発生したときに車が通過できるようにすることを意味します。
図 3.モジュラーソフトウェアは並行してリリース可能
ハードウェアプラットフォームごとに1つのソフトウェアプラットフォームを使用する代わりに、複数のハードウェア製品をサポートし、再利用を最大化する1つのモジュラープラットフォームを作成できます。各モジュールには独自のリリースサイクルがあり、自動車のドライブバイワイヤ機能などのミッションクリティカルな機能の低速リリースや、ユーザーインターフェイスの改善のための高速リリースが可能です。
図 4.再利用を最大化したモジュラーリリーストラック
2. 戦略的ソフトウェアモジュールとAPI
多くの企業は、すでに次の理由により、何らかの方法でモジュラー化されたソフトウェアを持っています。
- オブジェクト指向設計の実装
- クラス、マクロ、およびテンプレート
- コンポーネントとサブシステム - 多くの場合、企業ごとに決められた階層構造、つまりコンウェイの法則などに基づく
- プログラミング言語の違い - C++ と HTML がうまく融合しない
- オペレーティングシステムの違い - FreeRTOS と iOS 用に記述されたコードがうまく混ざらない
- ハードウェアの依存関係 – 計算は複数の物理ハードウェア ノードに分割されます
そうは言っても、コードをモジュールに分割する最適な方法は何ですか?1つのアプローチは、モジュールとそのインターフェイスの戦略を考えることです。
頻繁に変更する必要がないソフトウェアが存在する可能性があり、APIはシステム全体で広く使用されています。そのコードを変更すると、コストがかかる可能性があります。通常、顧客向けではないため、顧客はここで前払い金を支払う気がない可能性があります。ここで差異を持つ必要はありません。このコードは、"オペレーショナル エクセレンス" モジュールにクラスター化できます。これは、システム内で変更する必要がなく、再利用できるバックボーンサービスです。
顧客のニーズと期待に準拠するために、市場に関連するために必要なソフトウェアもあります。顧客のニーズは、地域、国、業種によって異なります。ここでは、多くの市場で関連性を持つように、多くの差異をサポートする必要があるかもしれません。このタイプのコードは、「顧客との親密さ」モジュールにクラスター化できます。
最後に、あなたを会社として定義したり、業界全体で大きな開発の推進力が起こっているのを見たりするソフトウェアがあります。市場での関連性を維持するために、このテクノロジーを頻繁に更新する必要がある場合があります。このコードは、顧客が追加料金を支払うことをいとわないものでもあります。このコードは、「プロダクトリーダーシップ」モジュールにクラスター化できます。
図 5.モジュールに戦略を適用する
3. ソフトウェアの移植性
ソフトウェアとハードウェアを組み合わせる場合、ソフトウェアの移植性がモジュール性の主要なターゲットになる可能性があります。ソフトウェアの移植性は、実行されるハードウェアに依存しないソフトウェアとして定義されます。この独立性は、ハードウェアレベルをアプリケーションレベルから抽象化する慎重に設計されたインターフェイスで実現できます。正しく行えば、ソフトウェアのどの部分を新しいハードウェアプラットフォームに引き継ぐことができ、どの部分を適応させる必要があるかを制御できます。
4.自動テスト
頻繁に変更されるソフトウェアにとって、テストは重要な関心事です。自動化されたテストは、より速くテストし、より早く問題を発見することができます。そうすれば、変更の統合に費やす時間やリソースを減らすことができます。自動化されたテストは、ソフトウェアのモジュール化によってより効果的に実現されます。変化する部分を堅牢なインターフェースで分離することで、より小さな塊のテストが可能になり、テストとバグの発見の両方がより速くなります。
5.無線通信を経由したソフトウェアのアップデート機能(OTA：Over-The-Air)
更新プログラムと機能がインストール ベースに実装されているソフトウェアの場合、無線通信を経由したソフトウェアの更新機能 (OTA) はイノベーティブな出来事です。制御された効率的な方法でソフトウェアの更新をプッシュするには、頻繁に更新されることを意図したモジュールを、変更のリスクがはるかに高い重要なモジュールから分離することが重要です。ソフトウェアの小さな塊の更新も高速で、リソースの消費も少なくなります。
製品にOTA更新機能を追加すると、ソフトウェア品質とアフターマーケットビジネスモデルの向上への扉が開かれます。また、サイバーセキュリティの脆弱性に対抗するための高速で効率的な方法でもあります。
6.書き換えではなくリファクタリング
企業がソフトウェア開発において新しく改良された技術に投資する正当な理由があります。ただし、これは、新製品でも再利用するためにリファクタリングできる完全に機能するコードを破棄することを犠牲にしてはなりません。結局のところ、コードは古くなりませんが、それを取り巻く世界は変化します。現在機能しているコードを書き直すのではなく、明日何が必要かを理解し、戦略的な再利用を可能にするために必要なインターフェイスを作成してみてください。
ハードウェア製造業におけるソフトウェアアーキテクチャの3つの優れた例
Tesla
おそらく最もよく知られている「ソフトウェア定義アーキテクチャ」は、自動車産業の中にあります。既存の車両にOTAで継続的に機能が導入され、週単位で車がより賢く、より使いやすくなっています。集中化された強力なコンピュータにほとんどの機能が搭載され、完全な自動運転など将来の需要に対してオーバースペックになっています。テスラでは、安全上の問題が発生した場合、機能トグルを適用して該当する機能を遠隔で無効にすることができ、大規模なリコールを回避することができます。
あまり知られていないかもしれませんが、テスラは自動車から生成されるデータを収益化する能力を持っています。テスラは毎年、顧客にソフトウェアのアップグレードやデジタルサービスを販売し、1台あたり1200ドル近くを売り上げています。その多くは、車の使用中にデータを収集し、Wi-Fiに接続したときにアップロードすることで実現されています。テスラは、収集したデータにより、アンチロックブレーキシステムのキャリブレーションを改善し、モデル3の制動距離（時速90～0km）を5m向上させ、全車にOTAで配布しました。また、テスラでは、車の運転状況をデータ化することで、安全運転をする車のオーナーに保険料を安くするサービスを提供しています。
テスラは、コンピューティングというハードウェアの性能向上という直接的なコストがかかる一方で、製品の寿命や競争力を効果的に延ばし、余分なコストをカバーするサービスを提供することで、ライフサイクル価値の向上と顧客の満足を獲得しています。
iRobot OS
iRobotは、その象徴的な丸いデザインで、ロボット掃除機のあるべき姿を定義しました。実際、アイロボット社製でなくても、多くの人がロボット掃除機のことをルンバと呼んでいるほど、そのデザインは優れています。最新バージョンは以前のモデルに比べて掃除があまり良くないかもしれませんが（すでにそれは素晴らしいものです）、その代わりに、iRobot Geniusソフトウェアを通じて、使用するたびに、よりインテリジェンスなナビゲートをしてくれるようになりました。ロボットはすでにペットの糞や携帯電話の充電器のケーブルを発見して避けることができますが、より多くの対象が継続的に追加されています。例えば、昨年のクリスマスには、ロボットがクリスマスツリーを検知し、その下に松やトウヒの棒が積もらないように、ツリーの下の掃除ゾーンを提案しました。また、犬が冬毛になったときや花粉の季節になると、より頻繁に掃除をするように提案します。また、ロボットは主要なデジタルアシスタントと連携し、音声コマンドを可能にします。これらの機能拡張は、ロボットがドックで充電されているときに、OTAで継続的に行われます。
ロボット掃除機には厳しい競争がありますが、アイロボット社は、その象徴的な機械的デザインよりも、堅牢なソフトウェアと優れたユーザー体験で対抗しています。
ABB RobotWare
ABBのロボットコントローラのモジュラーシリーズOmniCoreTMは、組み込みロボットコントローラと標準的なPC上で実行できるソフトウェアプラットフォーム（RobotWare）を提供します。ABBはこのコンセプトをバーチャルコントローラ（VC）と呼んでいます。この利点は、高度で正確なロボットプログラミングを、ロボットのハードウェアがなくても、例えば生産工場からの輸送中に行うことができることです。ようやくロボットが現場に到着したら、すぐにプログラムとコンフィギュレーションをロボットと同期させて生産を開始することができるのです。また、ソフトウェアはモジュラー化されており、リアルタイムの動作実行や安全システムに影響を与えることなく、ユーザーインターフェースや接続性を改善することが可能です。ABBは、ロボットをクラウドインフラに接続し、予知保全、ソフトウェアの自動バックアップ、フリート管理などの追加ソフトウェアサービスを可能にするために、ロボットの安全性を高めることに多大な投資を行っています。
機械式ロボットアームはコモディティですが、ABBの高度なシミュレーション機能とモジュラーソフトウェアアーキテクチャは、明確な差別化要因です。膨大な機能の豊富さと強力なソフトウェアエコシステムにより、競合他社が対抗するのは非常に困難なものです。
ソフトウェアのモジュラー化プロジェクトに着手する前のヒントとリマインダー
ソフトウェアアーキテクチャを改善する際に考慮すべき側面が非常に多いため、どこから始めればよいかわからない場合があります。多くの場合、これにより、開発者はコードを掘り下げて後で質問し始めます。ここにあなたがそれに来る前に何を考えるべきかについてのいくつかのヒントを上げておきます。
ヒント1: ソフトウェアアーキテクチャはR&Dのみの関心事であってはならない
ソフトウェアのモジュラー化はR&Dの関心事にすぎないと考えるのは簡単です。社内で最も優秀なソフトウェアエンジニアやアーキテクトにしかアクセスできない場合は、それを実現する方法を理解できるはずです。これは技術的には真実かもしれませんが、開発予算はR&D以外の人々によって設定されることを覚えておくことが重要です。この取り組みが会社にもたらす価値を確認または理解できない場合、この作業に必要な予算とコミットメントを与えない可能性があります。
さらに、要件の議論に販売、サプライチェーン、ソーシング、およびサービスを関与させて、ニーズと問題点を理解できれば、モジュラー化の取り組みも彼らにとってより重要になる可能性があります。次に例をいくつか示します。 製品の販売方法とアーキテクチャでそれを実現する方法をどのように調整できますか?製品をサービスとして販売したり、アフターマーケットのアップグレードを販売したりすることが企業戦略である場合、ソフトウェアアーキテクチャチームはこれを理解する必要があります。サプライチェーンから電子チップのサプライヤーを迅速に変更する必要がある場合、ソフトウェアアーキテクチャチームはそのニーズに応える必要があります!
ヒント2: 改善されたソフトウェアアーキテクチャが生み出す価値を定量化してみてください
このヒントが最初のヒントに関連しているのは、会社に生み出される価値を指摘できれば、全員を参加させ、モジュラー化作業に足並みをそろえることがはるかに容易になるからです。この取り組みでは、ソフトウェアのコスト要因をある程度理解する必要があります。
図 6.ハードウェアとソフトウェアの主なコスト要因
ソフトウェアの場合、通常、直接材料費は総システムコストの大部分を占めません。確かにいくつかのソフトウェアライセンスが関係している可能性があります。中規模から大量生産製品の場合、ソフトウェアライセンスは通常、ハードウェアの直接的な材料費と比較して重要ではありません。ソフトウェアのインストールには通常、本番環境で数ステップしか含まれないため、プロダクションフローもソフトウェアにとって大きな懸念事項ではありません。 サプライチェーンの効率は、デジタル化とインターネットが超高速の調達を提供するため、通常影響を受けません。むしろ、その逆の場合もあり、ソフトウェアがハードウェアのサプライチェーン効率にとって重要なボトルネックとなることがあります。この問題は、新しいチップサプライヤーに切り替えようとしたときに多くのハードウェア製造会社を襲ったパンデミック後のチップ不足の問題によって実証されています。
ソフトウェアの場合、開発コスト、テストと検証の労力、およびメンテナンスとサポートのコストは、 ソフトウェア製品を作成する上で最も重要なコストドライバーです。
したがって、モジュールシステムが生み出す可能性のある価値をよく理解するために、これらの最後の3つの領域の原価計算の改善に焦点を当てることが重要です。これらの利点は、現在のソフトウェアアーキテクチャのステータスによって大きく異なる可能性があります。
例：
- 複数のソフトウェアプラットフォームで重複する作業に開発労力を費やしていませんか?
- 再利用が不足していて、コードのいくつかの場所に同じことを実装していませんか?
- リリースごとに広範な手動テストと検証を行っていますか?代わりに、より小さな増分リリースでそれを改善できますか?
- バグの検出と修正、および修正の展開に関連するコストはどれくらいですか?
ヒント 3: KPI を早期に定義する
プロジェクト管理には、「測定されていないものは従わない」という古いことわざがあります。これは、モジュラー化作業の進捗状況を追跡することが重要であることを意味します。
モジュラー化の取り組みの早い段階で、いくつかの主要業績評価指標(KPI)を開発するようにしてください。もちろん、それらがプロジェクトの目標に依存します。
ここにあなたが始めるためのいくつかの例があります:
- ソフトウェアプラットフォームの合計ビルド時間。(並列ビルドパイプラインを使用して減らすことはできますか?)
- 自動的にテストされるパブリック API 関数の数
- 自動的にテストされる内部 API 関数の数
- ソフトウェア リリースの合計インストール時間
- ソフトウェア修正/パッチの合計インストール時間
- システムの総構成可能性(モジュールシステムとモジュールバリアントでカバーできるソフトウェア製品の数)
- 展開されたシステムの重大なソフトウェア障害をどれだけ迅速に修正できますか?
- エンジニアリング・トゥ・オーダー開発作業量
まとめ
このブログでは、ハードウェア製造業がソフトウェアアーキテクチャを改善する必要があることに気付いたときの課題と機会、および成功するためのベストプラクティスとして私たちが見ているものについて説明しました。ソフトウェアの開発が得意であることは、以前はハードウェアを多用していた多くの企業にとって、必要なものからビジネスクリティカルなものへと急速に移行しています。戦略的なモジュラー原則に基づいてソフトウェアアーキテクチャを作成することは、R&Dの懸念事項だけでなく、会社全体が成功する必要があります。正しく行えば、より優れたソフトウェアをより早く、より高品質でリリースし、市場での関連性をより長く維持し、企業と消費者の両方に優しい製品を構築できるビジネスを作成できます。
ブログをPDFでダウンロード – あなたの備忘録としたり、同僚と共有したりできます。
つながりましょう!
戦略的製品アーキテクチャは私の情熱であり、皆さんと会話を続けられることを嬉しく思っています。モジュール性やソフトウェアアーキテクチャに関する一般的な話題について議論したり、相談相手になったりしたい場合は、電子メールまたは私のLinkedinで直接私に連絡してください。
Roger Kulläng
Senior Specialist Software Architectures
roger.kullang@modularmanagement.com
+46 70 279 85 92
