なぜ装置ソフトウェアは、V字モデルの右半分を実行できないのか

V字モデルを知らない装置エンジニアは、たぶんいません。左側を下って要求から詳細設計・実装へ降り、右側を上って単体テスト・結合テスト・システム検証へ戻る。教科書にも、社内の品質マニュアルにも載っています。

にもかかわらず、自動化装置の開発現場で、この図の通りに動いているところはほとんどありません。左側は、だいたい書かれている。右側は、下二段が空いている。

これは、現場が怠けているからではありません。

左側は、経験で書ける

V字の左の下り —— 要求定義、リスクアセスメント、安全要求仕様、システム設計、詳細設計、実装 —— は、実のところ、なんとか実行できます。

過去の装置の資料があり、似た機構を組んだ経験があり、前回どこで詰まったかを覚えている人がいる。完璧ではないにせよ、レガシー資料と熟練者の経験で、左側は埋まります。

問題は右側です。

V字の右側は、下から順に単体テスト → 結合テスト → システム検証 → 受入検証と上がっていきます。ソフトウェア産業なら、この一番下 —— 単体テスト —— がいちばん密度が高い。関数ひとつ、クラスひとつを切り離して、入力を与えて出力を確かめる。

自動化装置で、同じことをやってみてください。

Z軸の昇降ロジックだけを切り離して試したい。しかし Z軸は、モータドライバに繋がり、原点センサに繋がり、上位の制御器に繋がり、隣の軸との干渉条件に縛られている。それらはひとつのハードウェアとして組み上がって初めて動く。分解して単位で試す構造が、そもそも存在しないのです。

装置ソフトウェアに単体テストがないのは、書かなかったからではない。書ける対象が物理的に存在しないからです。

結果として、検証は結合テスト → システム検証 → 現場立ち上げにだけ依存することになります。V字の右側は、下二段が欠けたまま運用される。

そして装置業界は、この欠けた状態で数十年やってきました。方法は単純です —— 装置が動けば OK。

この経験的検証は、実際うまくいってきました。少なくとも、うまくいっているように見えてきました。だから続いています。

代償は、動かなかったときに現れます。しかもいちばん高くつく場所で。

ソフトウェア工学には、修正コストは発見が遅れるほど跳ね上がるという古い経験則があります。設計段階で直すコストを 1 とすると、結合テストで 10、現場や量産で 100 から 1000。装置開発では、ここに現場での再作業、納期遅延、安全認証の再提出が上乗せされます。

しかし本当に効いてくるのは、金額そのものではありません。切り分けができないことです。

単体テストとモジュール検証があれば、誤りの在り処はある程度絞れます。それがないと、現場で問題が出たとき、こう始めることになる ——

「これは設計の問題か、実装の問題か」

この判断から始めなければならない、という状況そのものが、装置ソフトウェアの検証コストの正体です。デバッグに何人・何週間かかったかを思い出してください。その大半は、直す時間ではなく、どこが悪いのかを突き止める時間だったはずです。

もちろん、手を打ってこなかったわけではありません。

どれも正しい。そして、どれも誤りを減らすことはできても、なくすことはできない。レビューは人間が読む限り見落とすし、「検証済みモジュールだけ使う」は新しいことをやらないという意味でもあります。

もう一段踏み込もうとすると、こうなります。

静的解析を入れる。 レガシーコードに走らせた瞬間、警告が数千件出ます。どれが本物の問題か分からないまま、まず仕分けから始めなければならない。導入の初日がいちばん重い、という構造です。

単体テストを入れる。 そのためには、テストできる単位に分解できる実装を用意する必要がある。つまり、実装・製作のコストを全部先に払うことになります。

どちらも「やったほうがいいのは分かっている」で止まる理由があります。

ここで、問いを立て直す価値があります。

V字の右側の下二段が埋まらないのは、実装されたものを試す手段が装置にないからでした。ならば、実装されたものを試すのをやめればいい —— 設計そのものを確かめるという手が残っています。

これは屁理屈ではありません。実際、V字の左側で私たちが書いているものを見てください。詳細設計には、装置がどういう状態を持ち、どういう順で動き、どの条件でインターロックが効くかが書かれています。その情報だけで確かめられる問いが、いくつもあります。

これらはどれも、実機がなくても答えられる問いです。そして、実機ができてから答えるには高すぎる問いでもある。

「設計そのものを確かめる」というのは、装置業界には馴染みのない発想かもしれません。しかし、まったく新しい話ではありません。世界はすでに「モデルで設計する」方向へ動いていて、そこにあと一段足りないだけです。

設計を確かめることと、テストすることが具体的にどう違うのかは、テストと形式手法は、何が違うのかで扱います。