デジタル製品におけるハードウェア開発とソフトウェア開発の統合

ソフトウェアは、私たちの世界を支える存在として、その重要性が日々高まっています。製品に組み込まれるソフトウェアが増えるほど開発は複雑になり、エラーが発生する余地も大きくなります。一方、イノベーションを促進し、複雑で高品質な製品をより短期間で市場へ参入させることへのプレッシャーがかつてないほど高まっています。さらに、ハードウェア、ソフトウェア、サービスのイノベーションという開発ストリームを並行して管理し、透明性を確保しつつ、これらすべてを一つの製品に統合するという課題もあります。

複雑な製品開発の最適化競争に後れを取りたくなければ、社内のプロセス、システム、チームの考えかたを大きく進化させなければなりません。そうでないと、複雑な製品を念頭に置き、ビジネスを根本から見直している競合他社に取って代わられるかもしれません。

この進化のカギとなるのは、次のとおりです。

• システム全体を体系的に可視化する
• システムズエンジニアリングの方法を使用する
• 部門横断的な考えかたを社内に取り入れる
• 適切な PLM/ALM ツールを活用する

ビジネスの観点から見ると、こうした進化はメーカーにとってチャンスであると同時に課題でもあります。競争が激化し、イノベーションへのプレッシャーが強まる中、ソフトウェア主導型製品は開発期間の短縮を可能にし、まったく新しいビジネスモデルへの道を開くチャンスがあります。

ただし、この進化には課題が伴います。

複数の異なる開発チーム

製品開発者の視点から見ると、機械面でのばらつきが減少したとしても、すべてのソフトウェアのコンポーネント間で緊密な相互関係を維持する必要があることから、システム全体の複雑さが増します。さらに、ソフトウェア自体についても、その背後には複数の異なる開発チームが存在し、それぞれ独自の方法とスピードでイノベーションサイクルを管理しています。これらの作業を調整し、並行して実施される開発ストリームを統合するのは、容易ではありません。

システムの検証

メーカーは、安全性が重視される製品では特に、システム全体の検証方法も考慮しなければなりません。対象となる業界や製品によっては、「すべての開発ステップと変更を元の要件まで遡って追跡できるようにすること」が規格として定められています。

連携されていないツールチェーン

ソフトウェア開発で使用されるツールキットは、今日では、アプリケーションライフサイクル管理 (ALM) に進化し、そのプロセスモデルは最新のシステムズエンジニアリングに組み込まれています。しかし多くの企業は、以前と同様に現在でも、個々の多くのコンポーネントを管理することに重点を置いています。必ずしも、全社にわたって一貫して確立された製品ライフサイクル管理 (PLM) のコンセプト（方法とツール）により、要件仕様から最終製品までの一貫性が確保されているわけではありません。

機械製品や電気機械製品を主力として成長してきた企業では、増加するソフトウェアを統合するにあたって次のような傾向が見られます。

アプローチ A: ソフトウェアをハードウェアの付属物として扱う

この場合、ソフトウェアは、ハードウェアの拡張または追加（あくまでハードウェアの一部分であり、「単なる別の部品番号」）と見なされます。ソフトウェアコンポーネントは電気機械部品と同様に扱われ、部品番号が割り当てられます。この方法でも、製品構成での ECU の特定は可能かもしれませんが、最終的に、フラット BOM（部品表）ですべての相互依存関係を特定することはできません。

アプローチ B: ALM と PLM の併用

企業によっては、PLM 環境とは別に、独立した ALM 環境を並列で構築している場合があります。この場合、「PLM と ALM は互いに何をしているのかわからないし、関心もない」という状況といえます。

ソフトウェア開発者は、電気機械開発の制約から解放され、各自のダイナミックな能力を ALM 環境で存分に発揮できます。ソフトウェアは、短いイテレーションと非常にアジャイルな方法で、現在の顧客の要件を満たすように最適化されます。

しかし、完全に分離された状況ではPLM 環境と ALM 環境の相互同期が見落とされがちです。この不一致は、その後の生産と最終製品にまで影響を及ぼします。

残念ながら、機械工学、エレクトロニクス、複雑なソフトウェアを機能的に共存させるには、上記のアプローチはどちらも理想的ではありません。

ソフトウェア主導の製品開発を最適化するための「秘訣」は、透明性、コラボレーションのための効率的なハブ、業務に必要なすべてのツールをあらゆる関係者に提供するプロセス、方法、手段を確立することです。

とは言え、最終製品がすべての要件を満たしていることを保証し、単一のユニットとして機能させるには、個々のすべての領域を調整する必要があります。これは手段や方法論だけの問題ではありません。広範かつ深いレベルでの組織改革が不可欠であり、それに向けて積極的に取り組む必要があります。この改革に関し、全体を管理し社内調整するための強力なガイドラインを提供する責任者を配置するとよいでしょう。

次に、技術開発の複雑な環境において、連携した開発プロセスを積極的に制御する必要があります。ここで適切な基盤となるのが、システムズエンジニアリングで使用されている方法です。これらには、製品やシステムのすべてのコンポーネントを共有要件に合わせて調整できる、非常に便利なツールキットがすでに含まれています。

いずれか一つのシステムズエンジニアリング標準を規定どおりに実装するか、単にガイドラインとして使用するかは、ほとんど好みの問題です。もちろん、（一部の業界で義務付けられているように）特定の標準への準拠を顧客やその他の関係者に証明する必要がある場合は、それを最優先させてください。

基盤となる開発方法

重要なのは、企業が適切な手順モデル（V モデルなど）を選択し、それを指針として活用することです。

ソフトウェア主導型製品の場合、これは何を意味するのでしょうか？まず、その製品で提供すべき機能と、満たすべきその他の要件（規格など）について考えることが重要です。これには、特定のアプローチを念頭に置かずに、できるかぎり公平に行う必要があります。

次の手順に従ってください。

• その製品で提供すべき機能を明確にする
• アーキテクチャ段階で、システムを合理的に分割する
• 相互依存関係の初期の抽象定義を提供する
• 同期メカニズムを作成する

シンプルさを維持しようとあらゆる努力をしても、ハードウェアサブシステムとソフトウェアサブシステム間の相互依存性はすぐに多様化し、複雑になってしまう可能性があることに留意することが重要です。したがって、これらすべての相互依存関係の追跡をできるかぎり支援する IT 環境が不可欠です。

上記で取り上げたタイプの方法モデルは、「開発プロセス全体を通じて、ソフトウェア主導型製品を確実に開発する」という課題に対応するための基盤となります。特に、エンドツーエンドのシステムズエンジニアリングは重要なサポートを提供します。

今日、ほとんどの企業は、これらの概念の多くをすでになんらかの形で実践しています。ただし、その多くは最適化されておらず、目的に合わせた調整もなされていません。考えかたの適切な転換を推進しつつ、特定の責任者を配置し、これらの取り組みを支援する適切なツールを使用することで、この問題を解決できます。