ボーイング737 MAXの運航停止とMCAS失速防止ソフトウェアのパッチ適用により、ソフトウェアの信頼性の問題が大きな注目を集めています。しかし、ボーイングのソフトウェアが最終的にリスク要因となるかどうかはさておき、航空業界はここ数年、信頼性の低いソフトウェアを黙認する方向に傾きつつあります。
日々の生活の中で、私は毎日何十ものソフトウェアエラーに対処せざるを得ません。私の新しいアウディA5には、予期せぬタイミングで助手席側の窓が閉まってしまうという問題があり、エンジン始動、ロック、ロック解除という複雑な手順を踏まないと、車が危険な状態に陥ってしまいます。
バグのあるソフトウェアがジープのクルーズコントロールをロックする可能性がある
続きを読む
HSBCの電子バンキングアプリケーションでは、国際送金を行うために送信ボタンをクリックする回数がまちまちです。ソニーのブラビアテレビは、リモコンのキーを押しても反応するまでに10~20秒かかります。会計ソフトIntuit Quickbooksは、顧客情報を事前に消去してしまうため、請求書の支払いを受け付けないことがよくあります。サポートラインの保留メッセージには、「クッキーを消去すれば問題の50%は解決できるってご存知でしたか?」と熱く書かれています。
常連ユーザーのリストを記事に載せるだけでも大変ですが、最後の項目について少し考えてみましょう。ユーザーがCookieを消去しなければならない状況はあってはなりません。それはシステム内部の機能です。一般的なCookie一括消去で解決できる問題は、ソフトウェアがCookieを誤って設定しているか、誤って解釈しているか、更新または消去に失敗しているかのいずれかです(あるいは、最善のケースでは、ユーザーが個別にCookieを更新または消去できる手段が提供されています)。
Intuit が実際に言っているのは、「確かに問題はあるが、それを診断する余裕はないので、大騒ぎせずにただシステムを復旧させて稼働させられる方がずっと望ましい。できれば、技術サポートの工数もかけずに済むのが望ましい」ということです。
こうした姿勢が蔓延すると、あらゆるソフトウェア開発者や開発マネージャーの頭の中に悪影響が徐々に浸透していきます。「最後の5%のバグを見つけることなんて気にするな」と。マーケティング部門が求める機能を提供し続け、技術サポートの人員が適切に管理されていれば、それで十分だ、と。そして今や、ソフトウェアの消費者は結果に慣れすぎていて、ほとんど文句を言わないほどです。
技術者を責めないでください!
ここでの重要な問題は技術的なものではなく、むしろ経済と契約の世界にあります。ソフトウェア開発者は、極めて低いバグ数を保証するソフトウェアの開発と展開方法を熟知しています。問題は、それを実現するには時間がかかるため、信頼性の高い製品の開発コストが大幅に高くなり、開発コストが2倍、3倍、あるいはそれ以上に膨れ上がることです。
F-35はソフトウェアのバグにより「スクランブルテスト」に失敗
続きを読む
開発者全員をそのレベルの能力に引き上げるためのトレーニング費用を加えると、これは大きな出費となります。しかし、その投資回収はどれほどのものなのでしょうか?
私たちには、バグ回避にどれだけの注意を払っているかをお客様に効果的に評価していただく手段がありません。確かに、高いソフトウェア信頼性を確保するために講じるべき手順に関する業界標準は存在します。例えば、コードレビュー(コードのすべての行を、作成者以外の専門家が精査する)や回帰テスト(新しいコードを厳格なプロセスにかけ、予期しない副作用がないことを確認する)などです。
これらの標準の精神をスキルとセンスをもって実践すれば、優れた製品が生まれます。しかし、標準を単なるチェック項目として扱うことも可能です。ソフトウェアが契約入札に応じて開発されている場合、チェック項目を記入した開発者は書類上は優れた開発者と同じに見え、コスト削減のため入札に勝つでしょう。
バグに遭遇した消費者がそれを開発者に報告し、開発者がそれを診断して修正するのが通常の慣行となるような状況に自分たち自身を向かせる必要があります。
バグを一切許容しないという姿勢が新たな常態となれば、ソフトウェアは当初は高価になるでしょう。しかし、その価値は十分にあります。そして長期的には、現場サポートに費やす時間が減り、古いレガシーコードを書き直すインセンティブが高まるため、コストは削減されるでしょう。
しかし、真の技術的進歩が必要な分野が一つあります。それは、AIアルゴリズムのエラー診断です。最新の機械学習システムと最新の高性能ハードウェアを組み合わせることで、自動運転車をはじめとする様々な分野で驚くべき成果が生まれています。
問題は、基盤となるアルゴリズムが、その判断に至った経緯を示す監査証跡を提供する手段を、少なくとも人間が分析できる形では提供できないことが多いことです。例えば、道路脇の薄暗い光に照らされた人物よりも、道路上の明るく照らされたゴミの形状が「人に見える」というプロファイルによく一致したために、車が急ハンドルを切って歩行者に衝突した場合、私たちはアルゴリズムに「なぜそう判断したのですか?」と必死に尋ねたくなります。
しかし、答えが数千の係数を用いた行列演算の数千回の反復にあり、それ自体がさらに長い訓練プロセスから導き出されたものである場合、その答えを再発の可能性を減らすために行動に移す方法を知ることは極めて困難です。あるいは、被害者の家族にそれがどのように起こったのかを説明することさえ困難です。
機械学習アルゴリズムの不可解さと、ソフトウェアにお金を払う人々が真の信頼性と単なる機能の違いを区別する意志、あるいは能力がないという2つの問題は、今後ますます悪化するでしょう。ソフトウェア業界とソフトウェアを購入する組織、つまり私たちほぼ全員、中小企業から大規模な公共部門組織まで、行動を抜本的に改善する必要があります。これには、より洗練された機能を求める欲求よりも、バグを一切許容しない姿勢を優先することも含まれます。®
デイビッド・カーリンのテクノロジーキャリアは、シリコンバレーの半導体エンジニアから始まりました。以来、シンクレア・リサーチとSage UK(CTO)でエンジニア職を歴任し、Sageとオーディオメーカーのハーマン・インターナショナルでもマネージングディレクターを務めたほか、自身のスタートアップ企業を長年経営してきました。現在、デイビッドはソフトウェア開発と経営管理の両面で活躍する傍ら、2008年に妻のアリソン・カーリンと共同設立したクラシック音楽ウェブサイト「Bachtrack」で音楽記事を執筆しています。