「動いているから大丈夫」の時代は終わった

制御ソフトウェアの開発では、まず動かしてみることが大切です。

考えているだけでは分からないことも多く、実際に動かすことで仕様の不足や技術的な課題が見えてきます。

先行開発やPoCでは、完成度よりも早く試すことが優先される場合もあります。

しかし、動いたソフトウェアに機能を継ぎ足し、改良を繰り返していけば、自然に良い製品になるとは限りません。

製品や装置が複雑になるほど、「動いている」というだけでは十分ではなくなっています。

ボトムアップだけでは限界がある

現場では、必要になった機能から順番に作り、既存のソフトウェアへ追加していくことがあります。

最初は小さなソフトウェアだったものが、仕様変更や派生開発によって徐々に大きくなっていきます。

このようなボトムアップ型の開発でも、規模が小さいうちは対応できます。

しかし、求められる品質や性能が高くなると、部分的な改善だけでは限界が見えてきます。

現在の製品や装置には、単に目的の動作をするだけでなく、さまざまな要求があります。

• 必要な応答性能を満たす
• 異常時に安全に停止する
• 将来の機能追加に対応する
• 派生機種へ展開できる
• 他の装置やシステムと連携する
• 不具合の原因を追跡できる
• 長期間にわたって保守できる

これらを、機能を追加するたびに個別に対応していくと、ソフトウェア全体の整合性を保つことが難しくなります。

自分のソフトウェアだけ正しくても十分ではない

例えば、ある制御ソフトウェアが、受け取った入力信号に対して正しい演算を行い、仕様どおりの出力を返しているとします。

ソフトウェア単体では、正しく動いているように見えます。

しかし、その入力信号に遅れやノイズがあったらどうでしょうか。

センサの精度が足りない、通信周期が遅い、信号が更新されていない、

別のシステムが誤った値を出している、といった状態では、制御ソフトウェアだけが正しくても、

製品全体として正しい動作にはなりません。

反対に、ソフトウェアが要求する出力を出していても、モータや機械がその指令どおりに動けない可能性もあります。

このとき、

入力信号の問題なので、私たちのソフトウェアの問題ではありません

と切り離して考えるだけでは、製品全体の問題は解決しません。

もちろん、責任範囲を明確にすることは必要です。

しかし、製品や装置を完成させるためには、担当範囲を越えて、システム全体として成立しているかを見る必要があります。

作っているのはソフトウェアではなく、システムと捉える

制御ソフトウェアは、単独で価値を生むものではありません。

センサから情報を受け取り、状態を判断し、モータやアクチュエータへ指令を出し、

機械や装置を意図したとおりに動かすための一部です。

つまり、作っているのはソフトウェアだけではなく、ソフトウェアを含む一つのシステムです。

そのため、開発では最初に、

• システム全体で何を実現するのか
• どの程度の性能や信頼性が必要なのか
• 各機器やソフトウェアが何を担当するのか
• どのような入力を受け取り、何を出力するのか
• 異常時にシステム全体がどう動くのか
• 将来どのような変更や拡張が想定されるのか

を考える必要があります。

そのうえで、システムに求められる要求を、機械、電気、制御、ソフトウェアなどへ割り当てていきます。

「まず動かす」と「そのまま製品にする」は違う

まず動かしてみることは、今後も重要です。

問題なのは、試作として作ったものを、全体設計を見直さないまま機能追加し、製品へ成長させてしまうことです。

試作では、特定の条件で動けば十分だったかもしれません。

しかし、製品では、さまざまな条件や異常、長期間の使用、将来の変更まで考える必要があります。

そのため、PoCや試作から製品開発へ進む際には、一度立ち止まり、

• この構造で要求性能を満たせるか
• 機能の役割や責任が整理されているか
• 入力信号の品質を含めて成立しているか
• 異常時の動作が定義されているか
• 今後の拡張や派生開発に耐えられるか

を確認することが重要です。

必要であれば、アーキテクチャを設計し直したり、機能を分割したり、インターフェースを整理したりします。

システム全体から考える開発へ

制御ソフトウェアの規模や役割が小さかった時代には、

担当者が自分の範囲を正しく作れば、製品全体もある程度成立していたかもしれません。

しかし、現在の製品や装置では、複数のソフトウェア、センサ、アクチュエータ、通信、機械が複雑に関係しています。

個々の担当者が自分の範囲だけを最適化しても、システム全体が最適になるとは限りません。

「動いたから大丈夫」ではなく、

システム全体として、要求された品質や性能を満たしているか

を確認する必要があります。

まず動かして学ぶ。その後、システム全体の要求から構造を見直し、設計・実装・検証を進める。

制御ソフトウェアが複雑になる時代には、この両方を使い分けることが重要ではないでしょうか