iOS 13とmacOS 10.15 Catalinaは、Appleにとって異例のバグだらけのリリースとなりました。6月のWWDCでベータ版がバグだらけになったのは予想外ではありませんでしたが、Appleが9月の正式リリースから一部機能を削除した後も、さらなる問題が発生。そのため、Appleは急いでアップデートをリリースせざるを得なくなりました。なぜでしょうか？Appleのソフトウェアエンジニアとして18年間働いた経験から、いくつか考えがあります。
機能リストの過負荷はスケジュールチキンにつながる
Appleは、次期製品に重要な機能を積極的に搭載しています。タイトなスケジュールと野心的な機能セットのため、ソフトウェアエンジニアと品質保証（QA）エンジニアは、締め切りが近づくにつれて夜間や週末にまで働くことが日常となっています。iCloud Driveのフォルダ共有のように、一部の機能は将来のリリースまで延期されることが避けられません。
うまく運営されているプロジェクトでは、遅れている機能は早期に削減されるため、エンジニアは実際に出荷される機能の磨き上げに時間を割くことができます。しかし、マネージャーが「スケジュールチキン」をしてしまうこともあります。誰も部署会議で自分の担当部分が遅れていることを認めたくないからです。マネージャーは、その機能の別の部分に取り組んでいる誰かがさらに遅れていることを期待し、遅延による利益を享受しながら、遅延の原因となった責任を負わないようにします。しかし、誰も目をつぶらなければ、エンジニアは期限内に完了することが不可能な機能の開発を続け、最終的には将来のリリースに先送りされてしまいます。
Appleは、各リリースに詰め込みすぎないことでこのスケジュール上の問題に対処できるかもしれないが、それはAppleの企業文化ではない。AirPodsや噂のBluetoothトラッキングタイルのように、リリーススケジュールが決まっていない製品は、完成度が十分になるまで延期できる。しかし、iPhoneやOSのように年間リリーススケジュールが決まっている製品は、現状がどうであれ9月には出荷しなければならない。
クラッシュレポートではクラッシュしないバグは特定されない
レポート機能を有効にしている場合（推奨）、Apple の組み込みクラッシュレポーターがアプリケーションのクラッシュだけでなく、カーネルクラッシュも自動的に Apple に報告します。クラッシュレポートには大量のデータが含まれます。特に便利なのはスタックトレースです。これは、コードがクラッシュした場所を正確に示し、さらに重要なのは、どのようにしてその時点に至ったかを示します。スタックトレースは、エンジニアがクラッシュの原因を突き止め、修正するのに役立つことがよくあります。
クラッシュレポートはスタックトレースによって一意に識別されます。複数のクラッシュレポートに同じスタックトレースが含まれている場合、すべてのユーザーが同じクラッシュを経験していることを意味します。クラッシュレポーターのバックエンドは、スタックトレースに基づいてクラッシュレポートをソートし、最も頻繁に発生するレポートを最優先します。Appleはクラッシュレポートを真摯に受け止め、その修正に尽力しています。その結果、Appleソフトウェアのクラッシュは以前よりも大幅に減少しています。
残念ながら、クラッシュレポーターはクラッシュ以外のバグを検知できません。iCloudにアップロードされない写真、MacからiPhoneに同期されない連絡先カード、Time Capsuleのバックアップが破損して数ヶ月ごとに再起動を余儀なくされる問題、そして新しいiPhone 11のセットアップアプリがループに陥り、iCloudアカウントへのサインインを何度も求められ、Appleサポートに電話するまでに至った問題など、クラッシュレポーターは検出しません。（これらはすべて私が実際に経験した問題です。）
Appleは、クラッシュを起こさないバグについては、昔ながらの方法で追跡しています。つまり、人間のテスター（QAエンジニア）、自動テスト、そしてサードパーティの開発者やAppleサポートからの報告です。言うまでもなく、このアプローチは科学であると同時に芸術でもあり、クラッシュを起こさないバグを特定すること（特にAppleサポートからの報告から）と、エンジニアがそれらを追跡することは、どちらもはるかに困難です。
重要度の低いバグはトリアージされる
開発中、Appleは開発サイクルの段階とバグの重大度に基づいてバグのトリアージを行います。アルファ版までは、エンジニアはほぼすべてのバグを修正できます。しかし、開発がアルファ版、そしてベータ版へと進むにつれて、主要機能の妨げとなる深刻なバグのみが修正され、出荷日が近づくにつれて、データ損失やクラッシュを引き起こすバグのみが修正されます。
このアプローチは理にかなっています。エンジニアとして、コードを変更するたびに新たなバグが発生する可能性があります。また、変更は新たなテストサイクルをトリガーします。リリースが近づいている段階では、影響が理解されている既知のバグを修正する方が、気づかないうちに新しい機能に支障をきたす可能性のある修正を追加するよりも効果的です。
Apple Storeへの来店やサポートへの問い合わせを多く引き起こすバグは、たいてい修正されます。多くのユーザーをサポートするために十分なサポート担当者を雇うには、かなりの費用がかかります。バグを修正する方がはるかに安価です。私がApple製品の開発に携わっていた頃は、Apple Storeへの来店やサポートへの問い合わせを多く引き起こしている上位のバグのリストが配布され、それらを修正することが求められていました。
残念ながら、まれなバグやそれほど深刻ではないバグ（データ損失ではなく単なる混乱を引き起こすバグ）は、トリアージ システムによって常に後回しにされてしまいます。
回帰は修正されます。古いバグは無視されます。
Apple は古いバグを修正するのが下手だ。
AppleはiPhone 11のような新製品に特に注意を払い、深刻な顧客問題がないか探しています。問題には迅速に対応し、大きな問題は概して適切に解決しています。しかし、この初期段階の精査をすり抜けるような軽微な、あるいは稀なバグは、永久に残る可能性があります。
変更が新たなバグを引き起こすと言ったことを覚えていますか？エンジニアが誤って機能に不具合を起こした場合、それは「リグレッション」と呼ばれます。エンジニアにはそれを修正することが期待されています。
しかし、バグレポートを提出し、QAエンジニアがそのバグがソフトウェアの以前のリリースにも存在すると判断した場合、それは「リグレッションではない」とマークされます。定義上、それは新しいバグではなく、古いバグです。おそらく、誰もそれを修正するために割り当てられることはないでしょう。
Appleのすべてのグループがこのように働いているわけではありませんが、多くのグループがそうしています。私は本当に頭がおかしくなりそうでした。Appleで私が知っているあるグループは、「リグレッションではない」と書かれたTシャツを作ったほどです。バグがリグレッションではないなら、修正する必要はありません。だからこそ、先ほど述べたiCloudの写真アップロードのバグや連絡先の同期のバグは、永遠に修正されないかもしれません。
自動テストは控えめに使用
ソフトウェア業界はファッション業界と同じように流行に左右されます。現在、自動テストが流行しています。自動テストには、テスト駆動設計、ユニットテスト、ユーザー駆動テストなど、様々な種類があります。ここで詳細に立ち入る必要はありませんが、Appleは特定の分野を除いて、自動テストをあまり行っていないとだけ言っておきます。Appleは手動テストに大きく依存しており、おそらく依存しすぎていると言えるでしょう。
自動テストの最も重要な領域はバッテリーパフォーマンスです。毎日、OSビルドがデバイス（iPhone、iPad、Apple Watchなど）にロードされ、一連の自動テストが実行され、バッテリーパフォーマンスが低下していないことが確認されます。（もちろん、これらの自動テストはAppleのコードのみを対象としているため、実際の操作では重大なバッテリーパフォーマンスの問題が発生する可能性があり、その場合は手動で追跡・修正する必要があります。）
バッテリー以外にも、Apple社内には自動テストを活用していることで知られるグループがいくつかあります。Safariはおそらく最も有名でしょう。コードのチェックインごとにパフォーマンステストが実行されます。チェックインによってSafariのパフォーマンスが低下する場合は、拒否されます。自動テストの強化は、Appleのソフトウェア品質の向上に繋がるでしょう。
複雑さが増大
Appleにとってもう一つの厄介な問題は、エコシステムの複雑さが絶えず増大していることです。数年前、AppleはMacしか販売していませんでした。プロセッサはコアが1つだけでした。10万行のコードは巨大で、そのほとんどがシングルスレッドでした。
現代のAppleのオペレーティングシステムは数千万行ものコードで構成されています。Mac、iPhone、iPad、Apple Watch、AirPods、HomePodはすべて互いに通信し、iCloudとも連携しています。すべてのアプリはマルチスレッドで動作し、（不完全な）インターネットを介して相互に通信しています。
今日のApple製品は過去に比べてはるかに複雑化しており、開発とテストが困難になっています。テストマトリックスは、機能やOSバージョンなどの行数が増えただけでなく、テスト対象となる互換性のある製品に対応する次元も増えています。さらに、複数のコアで実行される複数のスレッド、プッシュ通知、ネットワーク遅延といった非同期イベントにより、包括的なテストスイートを作成することは事実上不可能です。
楽しみにしている
Appleは前例のない対応として、iOS 13.0の出荷前にiOS 13.1を発表しました。これは、ソフトウェア品質の問題がいかに深刻であるかを示す、稀な事例です。Appleは膨大なリソースを保有しており、同社のエンジニアたちは今年の問題を克服するでしょう。
短期的には、過去数年よりも頻繁に、より多くのバグ修正アップデートが提供されると予想されます。長期的には、Appleの上層部はこの問題を十分に認識しており、最善の解決策を検討しているはずです。バグはサポートコストとエンジニアの工数の両方でコストがかかるという事実に加え、広報上の懸念事項にもなりつつあります。Appleはプレミアム製品にプレミアム価格を設定しており、ソフトウェアの品質低下は企業の評判を損なう可能性があります。
デイビッド・シェイヤーは18年間、Appleのソフトウェアエンジニアとして活躍しました。iPod、Apple Watch、Appleのバグ追跡システムRadarなど、数々のプロジェクトに携わりました。