なぜ98%のサポートでは堅牢なエンジニアリングに不十分なのか

98%の成功率は重大なギャップを隠蔽する

98%の成功率は高く聞こえますが、食品の安全性、給与支払、またはアクセシビリティのように、失敗が深刻な結果をもたらす文脈においては、頻繁で容認できない事態を意味します。レストランにとって、98%の食中毒ゼロのサービスとは、顧客が月に約1回は病気になることを意味します。雇用主にとって、給与の支払いが2%の確率で漏れることは、重大な信頼の侵害です。

リスクが高いとき、パーセンテージは誤解を招く

失敗のコストが高い場合、失敗の絶対数はパーセンテージよりも重要です。世界人口の98%のユーザーに対して機能するウェブサイトは、依然として約1億5000万人のユーザーを除外しています。もしそれらのユーザーが特定のターゲット層に属している場合、その影響はさらに大きくなる可能性があります。著者の入れ子になったCSSに関する自身の経験がこれを物語っています。一般的な統計ではその機能は「広くサポートされている」ものの、サイトの訪問者の約70%しかそれを利用できず、残りの30%の視聴者が取り残されたのです。

エッジケースには段階的な機能低下（Graceful Degradation）が必要である

堅牢なエンジニアリングとは、「ほとんどのユーザーが正しく動作する」ことではなく、エッジケースを優雅に処理することです。新しいブラウザ機能が段階的に機能を低下させることができない場合、サポートされていない2%のユーザーは壊れた体験を経験することになります。これは「幅広いサポート」という主張と矛盾します。プログレッシブ・エンハンスメント（@supports や JavaScript による機能検知を用いて機能のサポート状況を確認すること）により、開発者はすべてのユーザーに機能的なベースラインを提供しつつ、可能であれば高度な機能を提供することができます。

98%の閾値に関するコミュニティの視点

wccrawford: "If your business plan requires you to capitalize on more than 98% of the market, it’s already a failure. The trade‑off is code complexity vs. market size, and each company must decide individually."

nemo1618: "Removing >99% of needles from a Christmas tree still leaves a visible mess; the remaining 1% stands out more as you approach 100%."

MatekCopatek: "Profit motives often drive the acceptance of 98% support. Ticketing services, for example, may ignore a 2% failure rate because fixing it would cost more than the lost sales."

phailhaus: "Percentages can be deceptive; expressing success as odds (1 in 50 vs. 1 in 100) highlights the real impact of moving from 98% to 99%."

onion2k: "If a feature can’t degrade gracefully, it isn’t truly ‘widely supported.’ Use progressive enhancement with @supports or feature‑detecting JavaScript; the extra work is minimal."

collinmanderson: "US and UK government websites officially support only 98% of browsers. With 1.66 billion sessions in a month, 2% equals roughly 33 million sessions—far from negligible."

compiler‑guy: "Early OCR software boasted 99% accuracy, but that still meant five errors per page—demonstrating that high percentages can still produce noticeable failures."

部分的な成功が許容される場合

すべての失敗はバイナリ（二値的）ではありません。ウェブ開発において、部分的に機能する機能は、食品の安全性や給与支払のように、いかなる失敗も許容されない分野とは異なり、依然として価値を提供できます。問題の種類を認識することが、98%という指標が許容できるかどうかを判断するのに役立ちます。

開発者のための実践的なガイダンス

失敗のコストを特定する – 2%の失敗率が許容できるもの（例：UIの見た目の違い）か、壊滅的なもの（例：セキュリティ、健康、支払い）かを判断します。
実際のターゲット層を測定する – 一般的な市場シェアの統計は、あなたの特定のユーザーベースに対してサポートが過剰に評価されている可能性があります。
プログレッシブ・エンハンスメントを実装する – すべてのブラウザに対してベースラインの体験を提供し、その上で機能検知を用いて高度な機能を追加します。
エッジケースの指標を指標として追跡する – 除外された2%のユーザーの体験を追跡し、実世界のインパクトを学んで、修正の優先順位を決定します。
成功を「確率」として表現する – 少数派の重要性を伝えるために、信頼性を「50人に1人のユーザーが問題に遭遇する可能性があります」のように表現します。

結論

98%の成功率は便利な短縮表現ですが、ハイリスクなドメインにおいて、それはしばしば容認できない失敗を隠蔽します。堅牢なエンジニアリングリングには、ヘッダーのパーセンテージを超えて、実際のターゲット層への影響を影響を測定し、エッジケースを残して優雅に処理するシステムを設計することが求められます。

なぜ98%のサポートは堅牢なエンジニアリングに不十分なのか