最近の排ガス不正、施工データ偽装事件に思う

ドイツの大手自動車メーカーであるフォルクスワーゲン社(VW社)の排ガス不正問題はまだ真相究明に至っておりませんが、最初にニュースを聞いた時には正直驚きました。それは「あのVW社が」というポイントであって規制逃れの手法そのものに驚いたわけではないのですが、そうこうしているうちに、今度は横浜市のマンションの傾きの発覚により施工データの偽装が明らかになりました。いずれもまだ問題の全容が見えていない段階ですので詳しい言及は避けますが、なんとなく似たような臭いを感じます。

特にVW社による不正の類は、IT業界では大なり小なり割とある話なのではないかなと思います。VW社の場合は市場に出してしまったのでかなり大きな問題になっていますが、リリースまでには直す前提で、例えば工程完了判定をパスするために不具合があっても検査に合格したことにするということは、実際にやるかどうかは別として簡単に出来そうなものです。ですので、テスト結果を鵜呑みにするのではなく、あるいはテスト結果だけを評価するのではなく、どのようにテストしたのかというテストのプロセスを評価するような仕組みが必要になってきます。

あるシステム開発でテストの自動化を導入した時のことです。開発チームではメンバー間で生産性や品質にばらつきがあるのは普通のことですが、全体として短納期で高品質を求められた結果、あるメンバーはそれがプレッシャーになったのか自動テストのコードはスカスカで、本体のプログラムは全くダメという状況に陥ったことがありました。この時、自動化したのは単体テストのみで、結合テストは通常通り手動で行うことにしていたのですが、単体テストの時はテスト結果が毎日OKとなっていたので問題ないように思われたのですが、結合テストになって初めてその品質の悪さが露呈したのです。この時はその人の書いたプログラムはほぼ作り直しで、納期には何とか間に合ったものの、当人以外のリカバリーを担当したメンバーは大変な思いをしました。

テスト駆動開発という開発手法も存在しますが、いずれにせよ合否の基準が最初から決まっている場合、エンジニアはその基準に合わせて開発を行う傾向があります。これは何もシステム開発だけではありません。会社の人事評価も同様です。会社が良かれ悪しかれ定めた基準によって、社員はその行動パターンを決定します。例えば、基本給は横並びだけど持っている資格に応じた手当を継続的に出すよということにしたとしたら、多くの社員は本業はそこそこに就業時間中に資格取得のための勉強に励むでしょう。

話を戻してソフトウェアの場合、予めテストの合否基準が決められていることで、効率的に開発を進めることができる部分があるのかもしれませんが、それで全てがうまく行くわけではないという至極まっとうな教訓が得られました。チーム全体が意欲的な場合にはうまく行くが、そうでない場合は特に、人には失敗を隠そう、ごまかそうとする性質があります。VF社の不正も環境負荷の少ないエンジンが供給できず、それを隠すために不正なソフトウェアを組み込んで試験を通そうとしたようですし、施工データの偽装も担当者が失敗を隠すためにデータを偽装したとの報道がなされました。今後全てのことが明らかにされた時、また新たな教訓が得られることと思います。
—-