Webフロントエンド版DX Criteria
プロダクトのユーザー体験と変化に適応するチームのためのガイドライン
Webフロントエンド版は、DX Criteriaのビジョンを継承し、スコープを絞ることで具体性を高めたサブセットです。
はじめに読む
クライテリア（チェックリスト）
持続可能な技術スタック
開発チームが適切なツールと技術を選択し、保守しやすく、進化し続けるコードベースを維持し、促進することが求められます。コードベースの継続的な改善に取り組むためには、コード品質の確保やライブラリの慎重な選定が重要です。このプロセスを通じてチームは技術的負債を最小限に抑え、長期的なプロジェクトの持続可能性を高めます。
1-1コードベース
コードベースの保守性は、システムの長期的な健全性と進化に不可欠です。保守性が高いコードは理解しやすく、エラーの特定と修正、新機能の追加が容易になります。 これにより、開発の効率が向上し、継続的な運用コストが削減されます。また、良好な保守性は開発チームの士気を高め、プロダクトの品質を維持することにも寄与します。
コードのデプロイに対する不具合の発生割合、ライブラリをアップデートする頻度、PRのオープンからクローズまでの時間などを計測し、定期的（月ごと〜半年ごと）に改善のためのアクションを計画・実施している。
静的型付け言語、コードフォーマッター、リンターを導入している。
APIレベルで型情報を共有できるツールを利用して、Webアプリと疎通するシステムを含むコードベース全体で型安全性を担保している。
補足
例えば、OpenAPI、GraphQL、tRPC、gRPCなどを利用していること。
静的型付け言語やリンターにおける違反を厳格に運用するあまりコードベースの保守性が低下している。
補足
その一方で、静的型付け言語やリンターを利用しているが、any や error を warn に落とすなど、それぞれの違反を勝手に抑制してしまい、曖昧な運用になっていることもアンチパターンと言える。 一時的な違反の抑止措置を講じている場合、その「一時的な違反抑止」が追跡可能になるようにしている場合はその限りではない。要はanyやwarnに変えて抑制するのであれば、なぜそうしたかをちゃんとコードベース内に追跡可能な形で残していることが求められる。 要は厳格すぎても曖昧すぎても問題がある。
1-2開発環境
開発環境は作業効率に大きく影響します。適切なツールは繰り返し作業を自動化し、エラーの早期発見、コードの品質管理を支援します。 これにより、開発者はルーチン作業から解放され、創造的なタスクに集中できるようになります。 強力なツールチェインはプロジェクトのスケジュールを短縮し、コストを削減し、最終的に製品の市場投入までの時間を短縮することができます。
ビルド時間、テスト実行時間、デプロイ時間などのメトリクスを取り、それらを元に定期的（月ごと〜半年ごと）に開発効率の改善を計画・実施している。
フォーマッター、リンターといったツールセットをチームで共通化し、それらのルール更新を定期的（月ごと〜半年ごと）に検討している。
ローカル開発環境でもバックエンドのプロセスに依存せずに、モックやAPIのテスト環境で開発できている。
ツールセットを統一する際に過剰にルールを厳しくしすぎてしまい、開発効率が低下してしまっている。
1-3UIコンポーネント
コンポーネント志向なUI開発は、インターフェースを再利用可能な部品、つまりコンポーネントに分割するアプローチです。 これにより、UIを構築する過程での一貫性と予測可能性が向上します。各コンポーネントは独立しており、特定の機能を持つため、異なるプロジェクト間での再利用が容易になります。 また、コンポーネント間の明確なインターフェースによって、チームメンバー間での作業の分担がしやすくなり、開発プロセスが加速します。 メンテナンスも容易で、大規模なアプリケーションでも安定した品質のUIを維持することができます。
広く共通化を意図しているUIコンポーネントがカタログ化されており、それに該当しないものも定期的（月ごと〜半年ごと）に整理し、改善している。
UIコンポーネントの責務、再利用性、インターフェースに関するチーム内プラクティスを逐次共有し、定期的（月ごと〜半年ごと）に見直して改善している。
コンポーネント指向なUIライブラリやフレームワーク（React, Vue.js, Angularなど）やWeb技術を使用している。
UIコンポーネントの設計パターンが開発者間で共有されておらず、コンポーネントの粒度をコントロールできていない（細かすぎ、大きすぎ）。
1-4アプリケーション設計
アプリケーション特性に応じた設計は、そのアプリケーションの成功に不可欠です。性能、拡張性、保守性、セキュリティなどの要件を考慮して、システムを計画的に構築する必要があります。 たとえば、リアルタイム処理が要求されるアプリケーションは、遅延を最小限に抑えるための高性能な設計が求められます。 また、ユーザーベースが時間とともに増加することが予想される場合、スケーラビリティを考慮した設計が必要です。 適切な設計により、アプリケーションはその目的を効果的に果たし、ユーザーに価値を提供できます。
アプリケーションの特性に応じてメトリクスの計測を行い、定期的（月ごと〜半年ごと）に改善アクションを計画、実施している。
補足
特に閲覧が多いアプリケーションではレンダリングにかかる時間、インタラクションが多いアプリケーションでは操作中の時間など、アプリケーションの特性に応じてメトリクスの計測を行い、半期程度の頻度でメトリクスに基づいた改善のアクションを計画、実施しているか。
ユーザーの理解と設計学習を両方実施していること。ユーザーに関しては要求の把握やユーザテストの実施、設計に関してはプロトタイプの作成、書籍などのインプット、コードレビューの参画などで学習している。
サービスのユーザー体験を念頭に設計を見直して中長期の開発計画に反映する機会が年次的（半年ごと〜年ごと）にある。
組織内での共通化を優先するばかりに、サービス特性に合わない設計を転用してしまいユーザー体験を損ねている。
1-5技術選定
持続可能な運用のための技術選定では、将来的な成長、変化に対応し、長期間にわたって効率的な運用を保つことができる技術を選ぶ必要があります。 要素を総合的に評価し、ビジネスの要件や将来の展望と照らし合わせて適切な技術を選定することが重要です。
使用しているライブラリ・サービス・ツールの更新頻度、セキュリティ事象などのメトリクスを追跡し、定期的に（月ごと〜半年ごと）改善を計画・実施している。
使用している技術やその周辺技術の情報を収集し、何らかの形で日常的（日ごと〜週ごと）にチーム内共有をしている。
技術選定時に数年後のプロダクトビジョンや目標を考慮し、技術的負債の蓄積を避けるための明確な戦略や基準を設け、その遵守を確認している。
新しい技術やライブラリについて任意の選定基準に従った調査を行わず、話題になっているなどの動機だけで採用している。
ユーザー体験を支える品質
アプリケーションのパフォーマンス、セキュリティ、アクセシビリティといった、ユーザーに直接見えにくいが重要な品質基準を定めます。それらを保証するための具体的な基準とプロセスを確立し、ユーザーが安全で快適にアプリケーションを利用できるようにします。
2-1パフォーマンス
Webプロダクトにおいてユーザー操作に対するパフォーマンス(応答性能)はユーザー体験に直結します。パフォーマンスが低い状態は利用効率を低下させ、総じてユーザーエンゲージメントやビジネスKPIに負の影響を与えます。プロダクトのパフォーマンスについて変化や改善の必要を捉えてコントローラブルな状態を実現するためには観測可能な体制を構築することが重要です。
Core Web Vitalsやプロダクトのコアな価値に通じる速度指標についてパフォーマンス計測を週1回以上の頻度で自動的に計測している。
補足
動画メディアであればメディアコンテンツが視聴可能になるまでの時間を User Timings API で収集するなどが考えられる。
速度指標やアセットサイズ指標の計測結果をチーム内で共有し、アクションプランを定期的（月ごと〜半年ごと）に検討している。
Synthetic MonitoringやReal User Monitoringに対応したパフォーマンス計測サービス（SpeedCurve、New Relic など）か同様の仕組みで任意の指標を常時計測している。
目標やアラートを設定していないことによって、過度に最適化したり、運用中に生じた性能劣化を見過ごしたりしてしまっている。
2-2アクセシビリティ
アクセシビリティという観点は、サービスを通じて提供される価値に対して実際のユーザーがアクセス可能であることを保証するために重要な観点です。UIや体験上の欠陥はサービスやビジネスにアクセスできない状態をシステム障害等と同様に生み出します。 日本国民において何らかの障害を抱える人は概算で9.2%（令和5年版 障害者白書より）にのぼります。障害者差別解消法においてもWebやIT分野の環境整備は求められており、ユーザーの多様性が想定される現代においてその重要性は益々高まっています。
Lighthouseやaxe-coreなどを利用した自動アクセシビリティテストを日常的（日ごと〜週ごと）に実施している。
Webアクセシビリティについて目指す品質基準を開発のガイドラインとして定めている。
補足
自分たちの事業において、どの程度の基準を満たすようにWebアクセシビリティを整備するか言語化しておくことが重要である。 具体的にはJIS X 8341-3:2016 か WCAG (Web Content Accessibility Guidelines) の各レベル A/AA/AAAを目安にできる。方針策定および対外的な基準の掲出に際してはウェブアクセシビリティ基盤委員会が公開しているウェブアクセシビリティ方針策定ガイドラインやデジタル庁のウェブアクセシビリティ導入ガイドブックを参考にするとよい。
開発プロセスの中で人による視認性、操作性、情報構造などのレビューを行っている。
補足
Webアクセシビリティの課題は自動テストで検出できるものばかりではない。開発プロセスの各段階において手動テストによるチェックを挟むことでアクセシビリティの確実性が高まる。 WCAGはもちろんAndroidなど他プラットフォームのドキュメントでも手動テストによるアクセシビリティチェックの併用を推奨している。
HTMLのフォーム要素やナビゲーション要素を代替するUIパーツを開発する中で、ブラウザが提供する標準的な操作性が失われてしまっている。
補足
通常、標準的なフォーム要素を使用することでキーボード操作等のアクセシビリティは担保されるが、div要素等を多用したオリジナルのUIを開発する場合はフォーカスや選択などのサポートを独自に実装する必要がある。 見た目はオリジナルでも内部的に標準のHTML要素を活かすことで、独自実装をせずにアクセシビリティを維持できる場合がある。またOSSとして公開されているUIコンポーネントライブラリの多くはアクセシビリティに配慮した実装がされているので、それらをカスタムして使用するのも良い方法である。
2-3セキュリティ
Webフロントエンド領域のセキュリティリスクは伝統的なWebアプリケーション脆弱性だけではなく、開発や運用に関わるエコシステム領域において多角化と複雑化が進んでいます。 静的検査や既知のセキュリティリスクをキャッチアップする基本的な体制はもちろん、技術やエコシステムが進化し続ける中で開発者のセキュリティ知識をアップデートし続けることがリスク軽減のために必要です。
SASTに相当する静的検査がPull Requestごとに実行されて一定の基準を満たさないコードが混入しない仕組みになっている。
補足
SAST（Static Application Security Testing）相当のソリューションは各所から提供されており、身近な例ではGitHub Code Scanningなどがある。
Webのセキュリティと開発時の注意事項について、開発者を対象とした教育カリキュラムや研修を実施して知識のアップデートを促している。
DependabotやRenovateなどのサプライチェーン脆弱性を検知できる仕組みを利用して、緊急度に応じた期間内にアップデートを適用できている。
ソースコード中にクレデンシャル等の機密情報がハードコーディングされている。
補足
ソースコードは開発者のローカルにコピーが作成されたあとの管理不備や、リポジトリ管理サービスの読み取り権限の漏洩等で暴露されてしまう危険性が高い傾向にある。 JavaScriptバンドルやHTMLを経由してクライアントサイドに露出する前提のAPIキーなどは制限の対象から外せるが、Secrets Managerなどの運用を前提に一元的に扱うほうが多くの場合で管理上のメリットを得られる。 Secrets Managerなどを経由してビルド時や実行時に環境変数として注入する手法が一般的である。
2-4プライバシー
ユーザーへの価値提供を確かにするために各種の外部ツールを導入することは有効な取り組みです。一方でWebブラウザを通して必要以上に情報を取りすぎてしまったり、適切な開示や情報提供を怠ってしまったりすることはユーザーのみならず提供側としても不測のリスクを招きます。 近年は世界的にプライバシー保護のための各種枠組みが整備される中、Webブラウザベンダーも重要な関心ごととしてアップデートを続けています。これらの動向を正しく理解し組織として適切に対応できる体制が必要です。
定期的（月ごと〜半年ごと）にマーケティングや各種の計測に用いられるサービス・ツールを棚卸しすることで不要になった外部スクリプトを削除できている。
Webにおけるプライバシー保護と開発時の注意事項について、開発者を対象とした教育カリキュラムや研修を実施して知識のアップデートを促している。
開発やマーケティング活動の中で利用者に関する情報の外部送信するツールを組み込むとき、各種の法令に準じて適切な情報開示や必要なオプトアウトを提供するためのプロセスが整備されている。
補足
利用者に関する情報の外部送信は国内外を問わず整備が進んでおり、事業の対象エリアに応じて適切な管理が必要である。 国内では電気通信事業者に課せられる外部送信規律などがある。自組織の法務担当者と連携できるようにプロセスを整備しておくと良いだろう。
Webブラウザの各ベンダーによるプライバシーに関する仕様変更をキャッチアップできていない。
補足
この種のアップデートは通常、周知と対応のための十分な猶予期間が設けられている。猶予期間中に影響の有無の判断して対応が必要である。 プライバシー関連の仕様変更に伴うインパクトは関わる事業によっても異なるが、ブラウザベンダーのリリースを定期的にキャッチアップしていると言える体制、機会がチーム内に設けられていることが望ましい。
2-5デザイン
Webフロントエンドでデザインは主にUI開発を通して密接に関わります。一貫したユーザー体験の提供と開発効率を両立するためには一定の仕組み化と忌憚のないコミニュケーションが欠かせません。 デザインと開発は決してトレードオフの関係ではありませんが、そうでないからこそ中長期の運用や提供したい体験を見据えた設計や議論が重要です。
デザイントークン（視覚的な構成要素）やUIのバリエーション（状態の表現など）における一貫性を保つために、デザイナー等を含む関係者内で定期的（月ごと〜半年ごと）に棚卸しと整理を行っている。
補足
一貫性を保つ為の手段としてデザインシステムのような言語化・体系化は有効なアプローチだが、それ自体はWebフロントエンド技術領域におけるクライテリアとはしていない。 デザインシステムを前提とせずとも、デザインと実装の接合点におけるUIの中でデザイントークンやUIのバリエーションが一貫性のある体験を提供できているか定期的に見直す取り組みが重要である。
利用状況の把握や改善検討のために、実際の利用者を想定したユーザーテストを定期的（月ごと〜半年ごと）に実施している。
一般に公開されるURLはレスポンシブWebデザインを前提として利用デバイスの多様性に応えられるデザインと開発をしている。
補足
レスポンシブWebデザインを前提とすることはスマートフォンやラップトップ、タブレットなどの多様なデバイスに対する利便性向上につながり、別々のバージョンを複数作るよりもUIの管理工数が減ることも期待される。 利用コンテキストが限定されているプライベートなWebアプリケ—ション（toB SaaS など）においては、レスポンシブWebデザイン以外も視野に入れて開発・運用を計画する。
開発の意思決定フローの中で、デザインと実装どちらか片方だけの都合が優先されるようになってしまっている。
補足
デザインを優先しすぎることで開発の複雑性を上げてしまい持続的なユーザー体験の提供を損ねることがある。また実装の都合を優先しすぎることは本来の提供価値を十分に発揮できなくなってしまう恐れもある。 上流・下流のような関係ではなく、提供したい価値と持続性のバランスを常に議論して判断できる関係性が重要である。
安定的なデリバリー
ビルド、テスト、デプロイを自動化することで、開発サイクルを迅速化し、品質の維持向上を図ります。CI/CDの実践によって効率的なビルドプロセスと迅速かつ安全なデプロイ戦略を実行します。これにより開発チームはリリースプロセスをスムーズに進め、顧客に価値を迅速に届けることができます。
3-1テスト
WebフロントエンドのテストはUIに対する煩雑なテストコードが忌避されてしまうこともありますが、適切なテストの設計と計画によって開発効率と堅牢性を両立できます。過剰なテスト計画は運用におけるソフトウェアテストの持続可能性を損ね、手作業に依存しすぎることも開発効率を損ねてしまいます。プロダクトの開発フェーズに応じてテストすべき対象と、その方法の見極めることが必要です。
CIにおける各種テストの所要時間が常に記録されていて必要なときに参照できる状態にある。
テストのメンテナンス工数が確保されていて、頻繁に失敗するなど効率性や頑健性を妨げるテストが放置されない仕組みができている。
開発者向けの方針として、品質管理のために何をテストし、どのようなテスト手法を用いるかが明確に文書化されている。
テスト工程が計画的に整備されていないことによる不具合の顕在化で開発効率やユーザー体験の低下が起きている。
3-2ビルド
昨今のWebフロントエンドにおいてビルドプロセスは最終的にユーザーに対して配信されるアセットをコートベースから生成するために不可欠な工程です。ビルド処理時間の遅延、設定ファイルの複雑化など、いずれもデリバリーの効率性を損ねる要因です。メンテナンス工数の確保はもちろん、チーム状況に応じて持続可能な選定および計画を策定することが重要です。
CI/CDにおける各種ビルドの所要時間や成果物のファイルサイズが常に記録されていて必要なときに参照できる状態にある。
ビルドプロセスのメンテナンス工数が確保されていて、コードベースの肥大化や設定の複雑化によって生じたビルドの不具合が放置されない仕組みができている。
フレームワークが提供する標準設定や、追加の設定を要しないゼロコンフィギュレーションなツールを使うなどで、ビルドの設定を記述・管理するスコープを最小限に保っている。
ビルドのプロセスや設定ファイルの複雑化によって、必要に応じたアップデートや優れたソリューションへの移行が過度に困難になっている。
3-3デプロイ
コンスタントにデプロイできる仕組みづくりは価値提供の頻度や効率に繋がります。安全性や確実性を重視する観点と共に、迅速な価値提供のためには攻めの姿勢も一定必要とされます。不確実性の中で攻めの姿勢を支えるためには事後の異常検知やProgressive Deliveryの環境を整備することが重要です。
デプロイの頻度や変更のリードタイムなどデプロイ指標の計測結果がチーム全体に共有されていて、チームで定期的（月ごと〜半年ごと）に振り返っている。
新しいバージョンをリリースしたあと、システムの安定性やユーザー体験に関わるメトリクスの変化などを検知でき、改善や切り戻しの意思決定が行えるようになっている。
段階的に新しいバージョンを提供したり（Canary Release）、機能の ON/OF を安全に切り替えたり（Feature Toggle）できる仕組みを導入している。
デプロイするたびにサービスが何らか不安定になるため、デプロイ頻度が抑制されてしまっている。
補足
Webアプリケーションが依存する外部サービスにおいてリリース時の整合性が保証されていない、リリース前に開かれていた場合に古いファイルへのアクセスが発生して404が生じるなどリリース前後の潜在的な不具合が見過ごされているケースを指す。 影響が僅少であれば状況に応じてリスクに目を瞑る選択肢もあるが、リリース頻度に影響を与えるようなネガティブがあれば改善すべきである。
3-4サプライチェーン
サプライチェーンはコードベースにおける各種の依存関係を指します。昨今Webアプリケーションはnpmを筆頭としたエコシステムの上で非常に大きなサプライチェーンに依存して成り立っています。依存ライブラリの更新や交換、削除をする工数や体制の確保はコードベースの鮮度ひいては持続可能性を保つために必要な取り組みです。
DependabotやRenovateなど依存ライブラリの更新を検知する仕組みを導入している。
補足
2-3-3 (セキュリティ) でも依存ライブラリに関する自動検知について触れているが、通常のアップデートサイクルとは異なる緊急性の高いアップデート対応でも有効な仕組みである。
依存ライブラリについて更新や置き換え、削除などの管理を定期的（月ごと〜半年ごと）に計画、実施できている。
補足
依存ライブラリは放っておくといたずらに肥大化してしまいがちである。例えばアップデートに工数が必要な場合は適切に計画するか、代替手段への置き換えを検討できる。Polyfillなどの類は最新のブラウザ環境であれば不要になっていることもある。 サプライチェーンをマネジメントするという観点で定期的な棚卸しと見直しをすることが望ましい。
依存ライブラリの重要度や自チームのリソースを踏まえて、更新の反映サイクルなどをポリシーとして定めている。
自動的に作成された依存ライブラリの更新Pull Requestが手つかずのまま形骸化してしまっている。
補足
依存ライブラリの更新を検知してPull Requestを自動作成してくれるサービスは便利だが、自信をもってマージできるテスト環境が整っていない等の背景で放置されてしまうと、サプライチェーンのマネジメント自体が形骸化してしまう。 サプライチェーンのプラクティス項でも触れているとおり、優先順位等の戦略をもって自分たちのチームにとって許容できる頻度になるように設定すると良い。
3-5CI/CD
デリバリー全体を支えるCI/CDの仕組みはWebフロントエンド技術領域がUI層だけでなくWebアプリケーション全体を包含しつつある中で、Webフロントエンド開発者にも一定以上の理解と関与が求められています。分担はチームや組織の体制に依存するものの、全体的な工程の理解や自動化の推進は積極的に行うべきテーマです。
CI/CDを取り扱う関係者で運用を振り返る機会が定期的（月ごと〜半年ごと）にあり、継続的な改善を行っている。
CI/CDの各種設定ファイル以外にパイプラインの全体像が分かるドキュメントなどのナレッジがありチーム内で更新、共有ができている。
CI/CDのパイプライン全体が自動化されている。
CI/CDのパイプラインを開発チームの当事者が自分たちで管理、改善できていない。
補足
専任の運用チームの関与を否定するのものでは決してないが、Webフロントエンド領域の担当者が自発的に改善アクションを起こさない、起こせない等の状況は健全ではない。 Webフロントエンド技術の知見を活かすことでCI/CDパイプラインひいてはデリバリーの改善に寄与できるはずである。
効果的なシステム設計
ユーザーの要求とビジネスのニーズに合わせたアーキテクチャ選定と、最適なユーザーエクスペリエンスとパフォーマンスを実現するための戦略立案が求められます。これにはモジュール性、拡張性、および保守性を考慮した設計が含まれます。適切な設計を通じてシステムは将来の変化にも柔軟に対応できるようになります。
4-1サーバー
サーバー周りはフロントエンドとは無関係ではなく、むしろ昨今ではどのようにデータとUIを結びつけるかといった活動の中で中核の部分であると言えるでしょう。その中でどのようにサーバーサイドと協調するか、運用をしやすいメトリクスを収集するかについてまとめています。本項目を達成することで開発生産性と運用継続性を向上させることが可能です。
サーバーアプリケーションのリソースについてメトリクスを収集している。
補足
リソースのメトリクスには例として下記のものが挙げられる。 - CPU利用率 - メモリ利用率 - ディスク使用量 - ネットワーク帯域幅
Webフロントエンド開発者がサーバーの実装や運用に関わる場合、バックエンドやインフラ領域の学習機会を提供している。
API実装が分業下にある場合、そのインターフェースをWebフロントエンドの実装者が主導して定義している。
補足
Webフロントエンド開発者がAPIのインタフェースを先行して決定し、バックエンドに対して要求を出す Consumer Driven Contracting な開発スタイルを実践している。バックエンドの API を待ってから開発をすることで、フロントエンドの開発開始が遅れてしまうことがない。
Webフロントエンドとバックエンドの分業している場合、画面の生成やデータの処理方法等の実現手段について片方による一方的な意思決定が行われている。
4-2インフラ
Webフロントエンドに限らない部分であるインフラのメトリクスとPlatform as a Service の運用についてまとめています。CDNはもはやフロントエンドが関わる必要がある構成要素であり、また専用のインフラエンジニアを職責として持てないような組織ではPlatform as a Service の検討も必要だと思っています。インフラとフロントエンドがどのような距離感で関わるかは今後の組織体制や能力開発において重要項目であり、本クライテリアを達成することで組織において高い運用能力を得ることが可能です。
インフラおよびシステムの可用性についてメトリクスを収集している。
補足
可用性のメトリクスに関しては例として下記のものが挙げられる。 - レスポンス時間 - エラー発生率 - ダウンタイム - MTTR
自分たちの設計を実施する上での最適な方法を模索するため、Webフロントエンド開発者がインフラ設計に参画している。
開発者のスキルセットに応じて必要があればインフラやシステムの一部としてPlatform as a Serviceを利用できる。
補足
Platform as a Service の具体例として下記のものが挙げられる。 - Vercel - Firebase - Supabase - Amplify
既定のインフラ構成が固まってしまっていて、新規開発やリプレース時などにインフラの再設計を検討する余地がない。
4-3キャッシュ
CDN、ブラウザのキャッシュは強力である反面、意図しない不具合を招いてしまうこともある側面を持ちます。使い所を間違えたり、理解が浅いまま利用してしまうと、大きな障害を引き起こす危険性を持っており、どうやって組織に定着させるかを検討することが必要です。本項目を達成することで、パフォーマンスと耐障害性に強いプロダクトの開発ができます。
計測可能なキャッシュヒット率について、定期的（月ごと〜半年ごと）に改善のためのアクションを検討している。
補足
ブラウザキャッシュなど基本的に計測できない対象を除き、CDNやサーバーサイド全般のキャッシュは、現状の設定がリアルユーザーにとって効果的かを観測すべきである。
ブラウザキャッシュやサーバーサイドキャッシュ、CDNなど各キャッシュ機能の特徴に応じて使い分けた設計をしている。
CDNキャッシュのパージ操作やデプロイによって、任意のタイミングで各種キャッシュを更新できる（古いキャッシュが参照されなくなる）仕組みになっている。
補足
急な情報の更新やアプリケーションの不具合を想定して、予め合意された時間内に適切に既存のキャッシュが無効化され、新しいキャッシュに置き換わるような仕組みであることを確認する。 静的ファイルについてはファイル名やパラメータにファイルのハッシュ文字列を付け加えるなどで常に一意なURLを作る(キャッシュバスティング)なども有効である。
キャッシュの利用を設計時に検討しておらず、使う使わないの判断もなく一貫性のないキャッシュ設定が適用されている。
4-4モニタリング
フロントエンドでもBFFなどのサーバプロセスを運用する以上、ダウンタイムやプロセスの監視は必要になります。また、それだけではなく、エラーが起きている事を監視する必要もあります。これらの項目を達成することで、障害発生時にスムースに対応ができるようになります。
SLI/SLOに関わるシステムの稼働を24時間365日モニタリングしている。
補足
下記の方法を例示する。 - ヘルスチェック用のエンドポイントを設け、ステータス確認ができるようになっている - プロセスの監視 - ログのモニタリング - アラートの通知 - トラフィック分析 (DDoS や 不正アクセス数の検知)
エラーログを収集し、定期的（月ごと〜半年ごと）にエラーの傾向を分析し、その結果をもとに改善活動を計画している。
各種事象を調査する際にバックエンド、インフラ、フロントエンドに渡って統合されたログをトレースできるようになっている。
モニタリングにおける異常検知時のアラートが設定されていなかったり、対応フローが確立しておらず問題が解決されなかったりしている。
補足
例えばSentryを導入したものの、アラートを通知するように設定されていないなどのケースが考えられる。
4-5障害対応
ログインの失敗など障害に繋がる主要なユーザーアクションに関する利用状況データを計測している。
障害後、Webフロントエンドを主とする開発者も漏れなく当事者としてポストモーテムに参加している。
補足
障害発生後のポストモーテムにも学びの場を活かせるようにしていることも重要
Webフロントエンドを主とする開発者にも障害対応のロールと責任を明確にしている。
障害対応に必要なスキルや知識の獲得にチームや組織として取り組んでおらず、業務負荷が一部の個人に集中してしまっている。
成長できるチーム
技術力の向上、効果的なコミュニケーション、およびチーム間の協力を促進するために、教育プログラムやワークショップを定期的に開催し、適切な職務分担を確立します。チーム文化の育成とメンバーひとりひとりの専門性の獲得が変化への迅速な適応につながり、持続的なチーム成果の鍵となります。
5-1専門性の育成
フロントエンドのようなまだ分野として確立されていない領域では、技術交流、教育、プロトタイプ開発といった複数の手段を持って専門性を獲得する必要があります。本クライテリアでは複数の手段を有しているか、チーム全体でそれを養おうとする空気があるかを確認することで専門性が獲得しやすい環境になっているかを確認しています。
複数の開発チームがあるとき、使用技術や問題点を互いに共有をする機会を定期的（月ごと〜半年ごと）に設けている。
技術や開発に関する勉強会やワークショップへ定期的（月ごと〜半年ごと）に各個人やチームが参加する文化がある。
補足
所属の組織内では得られない観点や普段とは異なる知見に触れることは、技術や開発におけるより広い視野や選択肢の獲得につながる。現状維持バイアスを抑制し、変革と適応を促すために投資すべき文化である。
技術のトレンドをキャッチアップし、それを取り入れた小規模プロジェクトやプロトタイプ開発の機会を設けている。
補足
例えば開発用のデバッグ目的のサイトや開発ブログ、管理ツールなどで試せる場を意図的に作ることを想定
共有する際に、特定の人だけが話題を提起しており、話の内容が固定されてしまっている。
補足
下記の問題を内包していることがある。 - ナレッジ共有のハードルが高く、共有や交流のための話題を持ち込みにくい。 - 共有するべき話題が何かをきちんと把握しきれてない。
5-2イネーブリング
開発者の生産性を上げることや利用可能な技術を育成を通じて増やす活動をイネーブリングと呼びます。チームトポロジーのイネーブリングチームという用語から取りました。本クライテリアはフロントエンドの利用可能な技術や生産性を増やす活動を指しており、またそれらを継続的に運用を通じて底上げしていく指標を指しています。
横断的な技術向上を図るチームや取り組みがある場合、ユーザー体験や生産性の向上など事業成果に繋がる指標を追跡している。
チームの生産性を向上するためのツールやプラクティスをおおよそ定期的（月ごと〜半年ごと）に調査して導入を検討、試行している。
チーム内やチーム間で共有すべき取り決めやナレッジをコンテンツ化して蓄積している。
補足
口伝や個人の努力によって伝えるのではなく、明示的なコンテンツとして蓄積することで、現状の振り返りや認識の共有ができるようになる。新入社員や異動者に対するオンボーディングコンテンツとしての効果も期待される。
組織内の技術方針が定まっておらず、なし崩し的に採用技術の断片化が進んでいる。
5-3職務定義
フロントエンドチームはチーム全体のハブになることが多いです。デザイナー、プランナー、バックエンドエンジニア、インフラエンジニアなどの架け橋になります。必然的に複数の能力が必要になり、またソフトスキル面も重要になります。職務の範囲を定義し、キャリアの方向性を講じていく必要があります。本クライテリアではそういう職務を定義しているかといった指標を作って確認しています。
スキルマップによって職能の可視化を行い、年次的（半年ごと〜年ごと）に内容を更新している。
フロントエンドエンジニアが何をどこまで受け持つのか、またその足りない部分はどうやって改善するのかを言語化・可視化している。
Webフロントエンド技術領域の技術選定に責任をもつ職務上の役割が任命されている。
補足
フルスタックにすべてを分けずに全部を包括する事を目標とした組織の場合は必ずしもWebフロントエンド専門の役職が必要とは限らないが、昨今の移り変わりが速い状況に対して、専門家を置くという事を検討しているかをポイントとして記述することとした。
ディレクションやデザインなど開発の隣接業務に圧迫されて、メンバー本来の職能に関する成長が阻害されてしまっている。
補足
こちらも5-3-3と同様、Webフロントエンド領域に閉じずに全てを実施するような組織は存在するとは思うが、昨今のフロントエンドの移り変わりの速さを勘案してこの項目を入れた。
5-4ビジネス連携
フロントエンドエンジニアはUIを構築することだけではなく、その活用状況を分析し、ビジネスに活かす必要があります。その際にはマーケティング部門やデザインと言った他分野と協業し、ビジネスドメインの知識を学習していく必要があります。本クライテリアではこういった連携ができているかをベースに指標が作られています。
他の技術領域（バックエンド、デザイン）やマーケティング部門などの連携先と互いの KPI や方針を相互理解する機会を設けている。
重視すべきプロダクトの品質特性を理解するため、ビジネス上のドメイン知識を学習する機会を設けている。
一定以上の工数を必要とする技術施策について、常にビジネス上の目標や意義を整理して取り組んでいる。
開発が関知しないところで導入された外部ツールやスクリプトについてトラブルシュートなどが急に割り込まれる。
補足
Google Tag Managerなど開発を介さずツールやスクリプトを導入できるサービスは有益だが、個々の内容によってはプロダクト開発上の指標（エラー発生率や速度指標など）にネガティブな影響が生じる可能性がある。 2-4-3とあわせて開発者が有事の際すぐに対応できるよう把握できていることが望ましい。過度の承認制は組織のアジリティを損ねる恐れがあるため、あくまでコントローラブルである状態を保つことを念頭に置いくと良い。
5-5外部発信
専門性の育成部分でも触れてますが、フロントエンドは流行り廃りが激しいこともあり、知見を内外に発信していくことが、自分たちの専門性を上げるうえでも、ブランディングによる採用の観点でも重要になります。特に誰か一人だけが発信しているのではなく、チーム全体で継続して続けていくことが重要になります。
チーム全体で発信の方針を定め、それに基づいて定期的（月ごと〜半年ごと）に発信数やインプレッション関連指標をモニタリングしている。
補足
発信の方針例: - 月に一度はブログを書く - 三ヶ月に一度は外部向けの勉強会を開くなど
発信内容についてレビュープロセスを設けて社内での議論や学習を促している。
テックブログや勉強会の開催、外部イベントへの登壇など複数チャネルにおける発信のチーム内実績がある。
外部発信の活動が特定の個人に依存しており、チーム全体で持続可能な取り組みになっていない。
補足
発信する際に特定の個人に依存することは個人が転職や休職などで状況が変わった際に脆弱な仕組みになってしまう。チーム全体で発信するという心持ちが必要。
Webフロントエンド版は、DX Criteria本体とは別に更新されます。 DX Criteria本体を見る