ソフトウェアの正確性にまつわる経済学

以下の文章はこちらの記事を翻訳したものです。

あなたはおそらく、完全に正確なソフトウェアを開発した経験がないでしょう。

これはあなたの能力への批判ではなく、単なる事実の指摘です。

非自明なソフトウェアには、少なくとも1つのバグが存在することがほとんどです。

もちろん、ほとんどバグのない小さなライブラリであれば、開発した経験があるかもしれませんが、全くバグのない複雑なプログラムを作成することは非常に難しいです。

ここで述べているのは、高度な学術的概念ではなく、むしろ実践的な話です。

バグが指摘されれば、それを認め、気をつけることが一般的な反応です。

では、なぜこのような現象が起こるのでしょうか？

まず、精密なソフトウェア開発が行われない理由から考えてみましょう。これは、適切な方法を知らないからではありません。私たちは長い間、かなり正確なソフトウェア（通常よりもはるかに精密なソフトウェア）を作る方法を知っています。例えば、NASAの開発プロセスを見れば、彼らはこの方法をほぼ完璧に実行しています（参照: Fast Company）。

しかし、NASAのプロセスを見ると、私たちが同じことをすることは現実的ではないと結論づけられます。NASAの方法は、一般的なソフトウェア開発に投じられる労力と比べて非常に多大です。プロセスも複雑で手間がかかり、一般的な開発環境における、日々変化する要件や厳しい締め切りに対応するのが難しいです。

つまり、問題は、精密なソフトウェアを作る方法を知らないことではなく、そのコストが高すぎるということです。

「高すぎる」というのは、単に利益率が10％低下する程度のことではありません。もし私たちのソフトウェア開発にもNASAと同等のコストがかかった場合、市場に受け入れられる価格で売ることが不可能なレベルです。さらに、開発に長い時間がかかりすぎると、他の企業が2年早く競合製品を市場に投入し、私たちの製品がリリースされた時点で既に市場の関心を失っている可能性があります。

（「販売」と「リリース」には様々な意味があります。これは、従来の意味でのお金を払ってソフトウェアのライセンスを得ることを指すこともあれば、サブスクリプションや広告スペースを通じての収益化を指すこともあります。さらに、有償のカスタム開発プロジェクトを意味することもあります。ここでは、単純に「販売」と「リリース」という言葉を使います。）

NASAが高い精度でソフトウェアを開発する理由は、バグが発生すると膨大なコストがかかり、数年間の努力が無駄になり、さらには命が失われるリスクがあるからです。バグのもたらすコストがこれほど高ければ、正確性を確保するために多額の時間と費用を投じることは、合理的な投資と見なされます。医療技術や航空産業も、安全性が重要な分野であるため、同様のアプローチを採用しています。医療技術におけるバグは命に関わるリスクをもたらすことがあり、飛行中にエンジンが自動的に再起動するのは望ましくありません。

しかし、私たちの多くが開発するソフトウェアは、これほどの安全性が求められるものではないため、消費者側からしても、そこまで正確なソフトウェア開発にお金をかけようとは思いません。

結果として、私たちは不完全なソフトウェアを書き、よりコストパフォーマンスの高いテスト方法を採用しています。つまり、 一旦、ソフトウェアを市場に出し、様子見をするのです。このアプローチでは、ユーザーの何人かがソフトウェアのバグを発見することになります。実際、多くのユーザーがさまざまなバグに遭遇することもあります。

これにより、実質的にはユーザーを品質保証（QA）部門の一部にしているようなものです。

率直に言って、これ自体はそれほど問題ではないことです。ユーザーは自分たちが支払う価格に見合った期待を持つものですが、その価格には高い精度が含まれていないため、彼らが得るのは完璧ではないソフトウェアです。開発者の多くは、バグのあるソフトウェアをリリースすることに対して何らかの罪悪感を感じるかもしれません。しかし、ここで理解しておくべき重要な点があります：バグのあるソフトウェアは道徳的な失敗ではありません。完璧なソフトウェアをリリースする選択肢が現実的には存在しないのであれば、なぜ私たちはそれを選ばなかったという理由で自分を責める必要があるのでしょうか？

しかし、ユーザーを品質保証（QA）部門として扱うことにはデメリットもあります。

それは、ユーザーがQAの仕事には不慣れであることです。QAは複雑な専門技術であり、この分野で優れたスキルを持つ人は少ないです。経験豊富な開発者でさえ、適切なバグレポートの書き方を知らないことが多いのですから、一般のユーザーにそれを期待するのは不公平と言えるでしょう。

この結果、ユーザーが目にしているものが本当にバグなのか、それとも誤解なのかを判断するための、長くてイライラするやり取りが生じます。誤解をバグとして扱うのも問題があります。実際のバグを特定しようとするこのプロセスは時間がかかり、最終的にはユーザーの不満を招き、開発者やカスタマーサポートの貴重な時間を浪費することになってしまいます。

さらに、必ずしもユーザーがバグを報告するとは限りません。一部のユーザーはソフトウェアを試用し、動作しないと判断したら、何も言わずに去ってしまいます。これは特に、誰がそのソフトウェアを使っているかを把握するのが難しい場合に大きな問題となります。

そして、ユーザーの中には実際に敵対的な存在もいます。彼らは見つけたバグを報告せず、そのバグを利用してあなたからお金やデータを盗み、あなたがそのバグを発見するのを妨げるような行動をとることもあります。このような状況では、バグの存在が明らかになるまでに時間がかかり、時には重大な損害を引き起こす可能性もあります。

したがって、バグのあるソフトウェアをリリースすることの問題点は次の通りです：

• ユーザーによって発見されたバグは、開発者がリリース前に発見したバグよりも高いコストをもたらす。
• ユーザーによる発見は、顧客の減少、時間の無駄使い、データ盗難など、さまざまな損失を引き起こす可能性がある。

しかし、他の要素を考慮せず、純粋に数的に見た場合、開発者よりもユーザーがバグを見つけた方がはるかに効率的です。そして、完全にバグのないソフトウェアを出荷することはほぼ不可能であることが確立されているため、我々は一定の許容可能な欠陥率を選ぶしかないのです。この許容欠陥率は通常、自分たちで次のバグを見つけるコストが、ユーザーに見つけてもらうコストよりも高くなる点で決定されます。欠陥率を適切に調整することができれば、開発プロセスの改善により収益を増やすことができます。企業は利益を追求することが多いので、適切に管理されている企業はこのような行動を取ることが一般的です。

ユーザーがバグを発見した場合のコストを削減する方法は存在し、実際に取り組むべきですが、これが常に高いコストを伴うことは避けられません。

これは、ソフトウェアの品質を向上させるためには主に二つの実行可能なアプローチがあることを意味します：

1. ユーザーにバグに対する不満を感じさせる。
2. バグを見つけるコストを減らす。

私自身は、ユーザーがバグに対してより強く反応することが望ましいと思いますし、ソフトウェアの品質に対する人々の関心が高まることを願っています。しかし、これはビジネスプランとしてはあまり良い方法ではありません。なぜなら、ソフトウェアの品質を向上させることは、その開発コストを増加させることになるからです。

しかし、バグを発見するコストを下げる点については、素晴らしい考えです。なぜなら、それによってソフトウェアの品質を向上させることができ、同時に利益率も高まるからです。文字通り、全ての関係者が利益を得ます：開発者、ユーザー、そしてビジネスオーナー。

これこそが、私たちがソフトウェアの世界を改善するために活用できるレバーです。より良いソフトウェアを望むなら、バグを発見する労力を削減するツールを開発するか、見つけることが重要です。

私は個人的にHypothesisがこの方向性の一例だと考えていますが、これが唯一の方法であるわけではなく、また必要な唯一のツールでもありません。より優れたモニタリングシステム、効率的なコードレビュープロセス、静的解析ツール、改善されたコミュニケーション手段など、他にも多くの方法があります。

とにかく、自分自身を責めて罪悪感を抱きながら正確なソフトウェアを書こうとしても、それが失敗に終わった際の罪悪感が、バグを発見する能力を向上させるわけではありません。このような自己批判は現在の標準のようなもので、実際には逆効果です。個々の努力でシステム的な問題を解決することはできません。より良いソフトウェアを開発するためには、それを可能にするための経済的な環境を変えることが必要だと言えるでしょう。