最近に始まったことではありませんが、広く使われているシステムの不具合を報道されることを多く目にします。時には停止が報道されたり、時にはデータが無くなったりとか、「その時そのシステム」で様々な症状ですが、それが政府系のシステムだったり公に使われているものであればあるほど、マスコミから叩かれます。それと並行して、「システムの品質をユーザーに評価させている現状など、自動車業界から見るとおかしい状況だ。IT業界は何か勘違いを起こしているのではないか？」という批判も目にしました。実はこれこそが大きな勘違いなのです。

このコラムでも何回か話題にしていますが、ソフトウェアの塊であるシステムは、たいていの場合は多くの機能が複雑に組み合わされ、ケースバイケースでいろいろな動きをします。例えば、タイムカードの様な機械を想像してみてください。昔ながらの、カードを差し込むとその時刻のスタンプが紙に印刷される様な、きわめて単機能のものなのであれば、多少のソフトウェアが入っていたとしてもかなりシンプルな構造のものになります。こんな単機能なソフトウェアでバグが発生したりすることは、ほぼ皆無でしょう。

ところが、これに従業員毎の雇用条件や休日・残業の条件を追加し、定められた時間ではない時刻に打刻しようとしたときに警告を出すような機能を追加することを考えます。すると、

従業員情報

従業員毎の雇用条件に合致する労働時間、残業時間帯、その合計時間

従業員毎の休日の設定値

など、複雑なデータをあらかじめ用意しておき、それをタイムカード機に事前に設定しておく必要があります。しかも、「休日で時間外労働の場合は上司の課長にメールが飛ぶようにする」などの条件分岐が入る場合は、その情報と条件を判断するソフトウェア機能も必要になります。

ここまでくると機能がかなり複雑になりますね。機械ではなく人間が打刻をするようなことを考えても、従業員数が多い場合は一人ではなかなか対応できなくなる複雑さだと思います。それをソフトウェアに管理させるわけですから、機能を開発するためには一つ一つのケースを漏れなく洗い出すことがかなり膨大な作業になります。この場合、雇用条件が複雑で社員一人一人の条件が大きく異なり、従業員が大勢の場合には、おそらくこの「ケースバイケース」を全部洗い出すことが困難になってくるでしょう。たとえ頑張って洗い出したとしても漏れが出てしまう可能性が大です。

この「漏れ」が不幸にして残存した場合、それに対応するソフトウェアも丸ごと漏れてしまうので、いつもは正常に動作しているタイムカード機であっても「漏れたケース」が発生、つまり「想定していなかったイレギュラーな時間帯での打刻操作」が発生した瞬間に何らかの不具合を起こしてしまいます。うまく設計されたソフトであっても、おそらく警告を出して弾く、といったユーザーからはよくわからない反応を示されてしまい、ユーザーは戸惑うことになるでしょう。

この不具合はいったい誰の責任なのでしょうか？細かいケースの洗い出しから漏れてしまったわけなので、少なくともソフト開発者だけの責任ではありません。システムを企画した担当者にも責任がありますし、それを指摘できなかったユーザーにもあります。

さらにこれが、タイムスタンプ機ではなくもっと複雑なシステムの場合、どうでしょうか？おそらく「ケース」そのものを洗い出すことすら不可能なぐらい様々な使い方をされると思います。ここまでくると、ユーザーにも明確な責任が求められます。

つまり、「使う上でのすべてのケースを想定する」ことは、ユーザーにもその役割を演じることが求められる、と言えるのです。

では、「ユーザーが全ケースを想定できないのであれば、システムの設計者がケースを全部想定して品質保証テストをするべきだ」という正論を唱える人も出てくるでしょう。しかし、これはシステムによってはあまりにも非現実的なことになります。洗い出しすることがそもそも難しいので、洗い出したケースを検証する必要があります。しかもそれは「使い方や手順だけでなく、さまざまな種類のデータの洗い出し」でもあるので、組み合わせ数は膨大になります。これらのデータやケースを専門のソフトウェアを作って全部抽出する、という方法もありそうですが、そのソフトを作ることも結構厄介です。結局、「テストするためのプログラムのテスト・・・」とか「ケースを洗い出すためのトリプルチェック・・・」といった様に、終わりが見えないループに入ることも起こりえます。それと比例してコストも時間も青天井のように広がっていきます。複雑になればなるほど。

結局、これらすべてのケースを洗い出すことは経済的にも現実的ではなくなる場合が多いのです。この点は、お叱りを覚悟で言えば、自動車の様な単機能の商品を作っている方々には想像もできないことだと思います。（もっとも、最近の自動運転機能については、この無限地獄の状態に簡単に入ってしまうと思いますが）

結局のところ、現実的には「よく起こりそうな可能な限りのケースを洗い出し、検証テストをして運用に入り、運用で出てきた問題には迅速に対応する」という進め方が一番適している、と言わざるを得ないでしょうし、それがデジタル化特有の進め方なのだと思います。