【ITニュース解説】Bringing Baseline into Product Development — and Keeping It Safe in Practice

システムエンジニアとしてWebサービス開発に携わる際、新しいWebの機能を使いたいけれど、「この機能はユーザーの使っているブラウザでちゃんと動くのだろうか？」という疑問にぶつかることは少なくない。現代のWebブラウザは多種多様で、それぞれのブラウザが新しい機能を実装するタイミングや対応状況は異なるため、開発者は常にその互換性の問題と向き合っている。もし、ユーザーのブラウザが対応していない機能を使ってしまうと、Webサイトの一部が表示されなかったり、正しく動作しなかったりする。これは、ユーザーがサイトから離脱する原因になったり、問い合わせが増えたり、ひいては企業への信頼を失うことにもつながりかねない。このような問題を未然に防ぎ、Web開発をより安心で効率的に進めるためのアプローチの一つが、「Baseline（ベースライン）」という考え方だ。

Baselineは、「Webの機能が、主要なすべてのブラウザで安全に、かつ広く使える状態になったのはいつか」という難しい問いに、シンプルな答えを提供する。従来の開発では、各ブラウザのバージョンごとに互換性リストを細かく確認する必要があり、その管理は非常に手間がかかり、しかもすぐに古くなってしまうという課題があった。Baselineは、ブラウザのバージョンを追いかけるのではなく、「特定の機能そのものが、どの程度普及しているか」という視点に焦点を当てる。これにより、開発チームは一貫性のある、そして根拠に基づいた意思決定ができるようになる。

Baselineでは、機能の利用可能状態を以下の三つの段階で表現する。

一つ目は「Limited availability（限定的利用可能）」だ。これは、その機能がまだ主要なすべてのブラウザでサポートされていない状態を指す。この段階の機能は実験的な位置づけであり、もし本番環境でどうしても使用したい場合は、その機能が使えないブラウザのために、代替手段（フォールバック）をきちんと用意する必要がある。

二つ目は「Newly available（新しく利用可能）」だ。これは、その機能が主要なすべてのブラウザの最新安定版でサポートされるようになった状態を意味する。この段階の機能は、注意深く導入すれば早期に利用を始めることができるが、まだ普及しきっていない可能性も考慮する必要がある。

三つ目は「Widely available（広く利用可能）」だ。これは、Newly availableの状態からさらに30ヶ月間、普遍的にサポートされている状態を指す。この段階の機能は、市場に広く普及しており、使用する際のリスクが非常に低いと見なされるため、安心して採用できる実用的な基準となる。 これらの段階に加えて、「2023年」のように特定の年を指定し、「2023年以前にNewly availableになった機能はすべて使用可能とする」といった基準を設けることもできる。このように、Baselineは個々のブラウザバージョンではなく、機能そのものの普及度合いを基準とすることで、開発者の判断をサポートする。

では、開発チームが実際に「私たちのBaseline」をどのように設定すれば良いのだろうか。まず、初期のデフォルトとしては、最も保守的で安全な「Widely available」を設定するのが一般的だ。これは、機能が普遍的にサポートされてから十分な時間が経過しているため、実環境での採用リスクが非常に低いという利点がある。次に、自身のWebサービスを実際に利用しているユーザーが、どのようなブラウザを使っているかを把握するため、アクセス解析ツール（Google Analyticsなど）やリアルユーザーモニタリング（RUM）ツールを活用する。これらのデータに基づいて、「年」の基準（例えば「2022年より古い機能は使わない」など）を調整し、サービス利用者の大半をカバーできる最適なバランスを見つける。そして最後に、例外ポリシーを明確に定義する。例えば、代替手段が容易に実装できる機能や、特定のビジネス上の理由で早期に導入したい機能など、Baselineの基準から外れても許容されるケースを文書化し、チーム全体で合意する。この一連のプロセス、すなわち安全なデフォルト設定、データに基づいた調整、そして明確な例外規定を設けることで、開発チームの意思決定は透明で一貫性のあるものとなる。

「なぜブラウザのUser-Agent（ユーザーエージェント）情報だけではだめなのか？」という疑問を持つかもしれない。User-Agent文字列は、ユーザーが使用しているブラウザやOSに関する情報を含むが、これだけを頼りにするのには限界がある。User-Agent情報は簡単に偽装される可能性があり、またWebクローラーやスキャナーといったプログラムによっても汚染されやすい。さらに、たとえUser-Agent情報が正確であったとしても、企業内で設定された特別なポリシーや、ブラウザのセキュリティ設定、開発者向けのフラグなどによって、特定の機能が無効化されている場合をUser-Agentだけでは把握できない。User-Agentに基づくポリシーは、ブラウザのバージョンと機能の複雑な対応表（マトリックス）を常に管理する必要があり、これはすぐに古くなる上に、Web標準における機能の分類とも一致しにくいという欠点がある。それに対し、Baselineは機能そのものに着目し、その普及度合いを基準とすることで、より信頼性の高い判断基準を提供する。User-Agentデータは、あくまでユーザー層の把握やコミュニケーションの補助として活用し、機能採用の意思決定はBaselineに基づいて行うのが賢明だ。

Baselineを実際の開発ワークフローに組み込む方法はいくつかある。まず、プロジェクトのビルド設定やトランスパイル（新しいJavaScriptのコードを古いブラウザでも動くように変換する作業）のターゲットを、設定したBaselineに合わせる。一部のツールはデフォルトでWidelyな設定になっているが、そうでない場合はBaselineの基準をBrowserslistクエリ（対応ブラウザを指定するための設定）やesbuildターゲット（ビルドツールesbuildのターゲット指定）に変換して適用する。これにより、実際にユーザーに届けるコードが、チームで合意した基準に沿ったものとなる。次に、問題が発生する前に、コードエディタ上や継続的インテグレーション（CI）環境で早期に検知する仕組みを導入する。例えば、JavaScriptのコードに対してはESLintという静的解析ツールにBaselineプラグインを導入し、CSSやHTMLに対しても同様のプラグインを設定することで、開発者がBaselineの基準を超える機能を使おうとした際に、その場で具体的な警告やエラーメッセージが表示されるようになる。これにより、問題のあるコードが本番環境にデプロイされる前に修正できる。具体的な例として、JavaScriptの非推奨なDate#getYear()やDate#setYear()のような機能を使おうとすると、Baselineルールによって警告が表示され、潜在的なバグを防ぐことができる。最後に、設定したBaselineポリシーを文書化する。デフォルトの基準（例: Widely）、特定の年を設定する方法、例外処理のルールなどを明文化することで、チームの誰もがポリシーを理解し、特に新しく参加したメンバーも迷うことなく開発を進めることができる。これは、個人の経験や暗黙の了解に頼るのではなく、「コードとして定義されたポリシー」として機能する。

Baselineは、JavaScriptだけでなく、CSSやHTMLにも適用できるため、開発チーム全体で一貫した基準を保つことが可能になる。例えば、CSSの新しいプロパティやHTMLの新しい要素が、Baselineの基準を満たしているかどうかをリンターでチェックできる。これにより、Webサイト全体で安定したユーザー体験を提供するための土台が築かれる。

まとめると、Baselineは、Web開発において「どの機能を使っても安全か」という問いに対する、現実的で実践的な解決策だ。明確な基準を定め、その根拠をチームで共有し、そしてその基準をツールに自動的に守らせることで、開発チームはユーザー体験を危険に晒すことなく、迅速かつ自信を持ってWebサービスを開発・提供できるようになる。これは、現代のWeb開発において、安定性と効率性を両立させるための重要なアプローチと言えるだろう。