ソフトウェアの品質保証とは？

2年ほど前でしょうか。とあるものづくり系の会社の取締役総務部長とシステム選定の話をしている際、総務部長がふと「鈴木先生、ソフトウェアに品質不良というものはあるのですか？」とお尋ねになりました。私も元々ものづくりに携わってきましたので、品質には色々苦労させられてきましたが、改めて「ソフトウェアの品質」について問われると、確かに世の中のシステム導入系の書物や書き物にはあまり記述が無い話題だな、と気がつきました。

さらに、その部長にとって、形のある「モノの品質」については、ものづくりの根幹を成す会社の重要なKPIそのものなので、改めて説明の必要が無い数字群となるわけですが、見えない、形が無いソフトウェアというものについて、その品質とはどんなものなのか全く腑に落ちなかったわけです。

その問いに対しては、ソフトウェアの品質保証に関する一般的な管理方法と、テスト方法についてご説明差し上げ理解を頂いたのですが、最近ふと日本のソフトハウスの品質に関する実力が低下しているのではないか？と思わせる事象がありましたので、あらためて本コラムでも書いてみることにしました。

その事象は、ある機械メーカーA社さんが製品をIoT化する際に発生しました。A社の製品の内部には、機械をコントロールする小さなコンピュータが搭載されており、その中に組み込まれたソフトウェアがモーターの回転速度やトルクをコントロールしており、センサーからのフィードバックで精密制御を実現する、というものでした。

この組み込み用コンピュータモジュールはB社から仕入れたもので、様々な用途やモーターに使える汎用のコントローラですので、導入した最初の段階で初期設定が必要です。その初期設定の為には、パソコンにコントローラを接続し、専用ソフトで各種の設定値を入力する様になっています。A社はこの製品を販売し、ネットワーク経由でデータを取得し、それを当社が開発ご支援していた基幹システムに取り込んで管理する、という仕組み作りに取り組んでいたのです。

さて、基幹システムもほぼ完成し、販売するハードウェアの試作段階も終盤です。ところがその段階で大きな問題に直面しました。B社の説明書の通りにコントローラに設定値を入力しようとしたところ、数字のマイナスを入力したいのに、ソフト上で入力しようとすると勝手にプラスになってしまうのです。何回やっても同じで、マイナスの値を入力して設定ボタンを押し、念のため再度コントローラから読み込みするとプラスに勝手に変わっている…。

仕方無いのでダメ元でプラスの数字を入力して設定したところ、なんと正常にマイナスの数字が返ってくるではありませんか！A社は当然B社の設計者に連絡し、現象を説明したところ、設定ソフトとコントローラ側に組み込まれているソフトのバージョンが適合しておらず、極性が勝手に逆になってしまうことが解りました。ここまでたどり着くのにA社は数時間を費やしています。

A社の担当者は大きな疲労感を感じながら、次の設定値を設定することにしました。地球の自転の影響をキャンセルするため、緯度経度を入力しないといけません。これも説明書の通りに入力し設定したところ、今度は正しく設定できたようです。胸をなで下ろしてコントローラを機械に接続し、試運転してみました。「ウン動くぞ！」と思ったのも束の間、誤差が次第に大きくなっていくではありませんか。コントローラは誤差を自動修正するはずなのに、誤差がどんどん大きくなり、しまいには機械の動作限界を超えてしまって異常停止する始末です。

誤差の広がり方を数字で取得してグラフ化し、何が起こっているのか解析したところ、コントローラが誤差を打ち消す方向でモーターを制御しないといけないのに、誤差を助長する方向にモーターに制御信号を出していることがわかりました。ここまで来ると嫌な予感しかしません。再びB社の設計者に連絡し、現象を説明したところ、しばらく時間が欲しいと言われ、数日間待ちました。すると設計者から連絡があり、「緯度の計算の正負を間違えていた」とのこと。我々が日本の緯度を設定したのに、勝手に南緯になってしまい、ソフトウェアは地球の裏側として認識していた、ということになります。

さすがにこの2度目の間違いには大きな不安といらだちを感じました。それでもA社はコントローラを完成品として購入してしまっていたので、まずは使わざるを得ません。これ以上の不具合が発生しないことを祈りながら運用をはじめましたが、その後も開発者から不定期にソフトウェア更新のお知らせが来ました。その更新内容を読むと、実に稚拙なミスの修正が多かったのです。A社が経験した不具合もケアレスミスによる不具合でしたが、その他にも整数と実数を取り違えたり、ふたつの設定値を入れ違えた結果、片方を修正すると反対側が修正されてしまう、というミスだったり、通常では考えられないケアレスミスの連続が続いたのです。

ソフトウェアは人がキーボードで入力してゆく、という実に原始的な方法で開発される部分が現代でも多く残っています。当然打ち間違いもあるでしょうし、誤認識による誤りも発生するでしょう。問題はそれを開発者側の組織がいかに検出し、顧客に影響を与えないように組織的に保証するか、です。自動検査ツールなども進化していますが、最後はやはり人間の手によって間違いが無いことを保証しなければならない、これがソフトウェアの品質保証の最後の防波堤なのです。

今回取り上げたコントローラのソフトウェアについては、その開発会社の技術者があまりにもケアレスミスが多い、ということが問題の根幹ですが、会社としての品質保証体制が充分機能しておらず、開発者個人の作り上げる品質がB社の製品の品質レベルを左右してしまっていた、という事例となります。往々にして「仕様は優れているのに、導入したら品質が悪い」ということも起こりえるのがソフトウェアの怖いところでもあります。

今回の事例は、A社の製品に組み込まれたコントローラのソフトのお話でしたので代替えが効きます。A社はその後B社のものをやめ、他の会社のコントローラに変更して恒久対策としました。しかし、基幹システムの様な大規模なソフトウェア導入プロジェクトの場合、品質問題の多発はプロジェクトの成功を大きく阻害します。開発の後半段階に入ってバグ潰しばかりをやっていてもきちんとしたモノが納品されるとは限りません。開発会社選定段階で品質保証体制やその手法を確認することが非常に重要なのです。

仕様だけでシステムを選ぶこと、これは非常に危険であるということをご理解頂ければと思います。