Webフロントエンド版DX Criteria (v202402)/プロダクトのユーザー体験と変化に適応するチームのためのガイドライン
page icon

Webフロントエンド版DX Criteria (v202402)/プロダクトのユーザー体験と変化に適応するチームのためのガイドライン

Webフロントエンド版について

💡Webフロントエンド版DX Criteriaの概要2024/2/7 8:392024/3/6 0:08✍️Webフロントエンド版DX Criteriaのポリシーと構造2024/2/7 8:392024/3/26 3:31❓Webフロントエンド版DX Criteriaに関するFAQ2024/2/16 1:052024/3/19 7:32🔰Webフロントエンド版DX Criteriaの使い方2024/2/14 8:462024/4/16 23:57✅Web フロントエンド版DX Criteria一覧2024/2/15 14:412024/4/3 0:43

DX Criteria 企業のデジタル化とソフトウェア活用のためのガイドライン

Webフロントエンド版はオリジナル版のビジョンを継承し、スコープを絞ることで具体性を高めたサブセットの位置付けです

✅ クライテリア（チェックリスト項目群）

ℹ️
本クライテリアを有効にご活用いただくため、最初に下記のドキュメントをご一読ください
 

⚙️ 1. 持続可能な技術スタック

開発チームが適切なツールと技術を選択し、保守しやすく、進化し続けるコードベースを維持し、促進することが求められます。コードベースの継続的な改善に取り組むためには、コード品質の確保やライブラリの慎重な選定が重要です。このプロセスを通じてチームは技術的負債を最小限に抑え、長期的なプロジェクトの持続可能性を高めます。

1-1. コードベース

💡
コードベースの保守性は、システムの長期的な健全性と進化に不可欠です。保守性が高いコードは理解しやすく、エラーの特定と修正、新機能の追加が容易になります。 これにより、開発の効率が向上し、継続的な運用コストが削減されます。また、良好な保守性は開発チームの士気を高め、プロダクトの品質を維持することにも寄与します。
 

1-2. 開発環境

💡
開発環境は作業効率に大きく影響します。適切なツールは繰り返し作業を自動化し、エラーの早期発見、コードの品質管理を支援します。 これにより、開発者はルーチン作業から解放され、創造的なタスクに集中できるようになります。 強力なツールチェインはプロジェクトのスケジュールを短縮し、コストを削減し、最終的に製品の市場投入までの時間を短縮することができます。
 

1-3. UIコンポーネント

💡
コンポーネント志向なUI開発は、インターフェースを再利用可能な部品、つまりコンポーネントに分割するアプローチです。 これにより、UIを構築する過程での一貫性と予測可能性が向上します。各コンポーネントは独立しており、特定の機能を持つため、異なるプロジェクト間での再利用が容易になります。 また、コンポーネント間の明確なインターフェースによって、チームメンバー間での作業の分担がしやすくなり、開発プロセスが加速します。 メンテナンスも容易で、大規模なアプリケーションでも安定した品質のUIを維持することができます。

1-4. アプリケーション設計

💡
アプリケーション特性に応じた設計は、そのアプリケーションの成功に不可欠です。性能、拡張性、保守性、セキュリティなどの要件を考慮して、システムを計画的に構築する必要があります。 たとえば、リアルタイム処理が要求されるアプリケーションは、遅延を最小限に抑えるための高性能な設計が求められます。 また、ユーザーベースが時間とともに増加することが予想される場合、スケーラビリティを考慮した設計が必要です。 適切な設計により、アプリケーションはその目的を効果的に果たし、ユーザーに価値を提供できます。
 

1-5. 技術選定

💡
持続可能な運用のための技術選定では、将来的な成長、変化に対応し、長期間にわたって効率的な運用を保つことができる技術を選ぶ必要があります。 要素を総合的に評価し、ビジネスの要件や将来の展望と照らし合わせて適切な技術を選定することが重要です。
 

🛡️ 2. ユーザー体験を支える品質

アプリケーションのパフォーマンス、セキュリティ、アクセシビリティといった、ユーザーに直接見えにくいが重要な品質基準を定めます。それらを保証するための具体的な基準とプロセスを確立し、ユーザーが安全で快適にアプリケーションを利用できるようにします。
 

2-1. パフォーマンス

💡
Webプロダクトにおいてユーザー操作に対するパフォーマンス(応答性能)はユーザー体験に直結します。パフォーマンスが低い状態は利用効率を低下させ、総じてユーザーエンゲージメントやビジネスKPIに負の影響を与えます。プロダクトのパフォーマンスについて変化や改善の必要を捉えてコントローラブルな状態を実現するためには観測可能な体制を構築することが重要です。
 
 

2-2. アクセシビリティ

💡
アクセシビリティという観点は、サービスを通じて提供される価値に対して実際のユーザーがアクセス可能であることを保証するために重要な観点です。UIや体験上の欠陥はサービスやビジネスにアクセスできない状態をシステム障害等と同様に生み出します。 日本国民において何らかの障害を抱える人は概算で9.2%（令和5年版 障害者白書より）にのぼります。障害者差別解消法においてもWebやIT分野の環境整備は求められており、ユーザーの多様性が想定される現代においてその重要性は益々高まっています。
 

2-3. セキュリティ

💡
Webフロントエンド領域のセキュリティリスクは伝統的なWebアプリケーション脆弱性だけではなく、開発や運用に関わるエコシステム領域において多角化と複雑化が進んでいます。 静的検査や既知のセキュリティリスクをキャッチアップする基本的な体制はもちろん、技術やエコシステムが進化し続ける中で開発者のセキュリティ知識をアップデートし続けることがリスク軽減のために必要です。
 

2-4. プライバシー

💡
ユーザーへの価値提供を確かにするために各種の外部ツールを導入することは有効な取り組みです。一方でWebブラウザを通して必要以上に情報を取りすぎてしまったり、適切な開示や情報提供を怠ってしまったりすることはユーザーのみならず提供側としても不測のリスクを招きます。 近年は世界的にプライバシー保護のための各種枠組みが整備される中、Webブラウザベンダーも重要な関心ごととしてアップデートを続けています。これらの動向を正しく理解し組織として適切に対応できる体制が必要です。

2-5. デザイン

💡
Webフロントエンドでデザインは主にUI開発を通して密接に関わります。一貫したユーザー体験の提供と開発効率を両立するためには一定の仕組み化と忌憚のないコミニュケーションが欠かせません。 デザインと開発は決してトレードオフの関係ではありませんが、そうでないからこそ中長期の運用や提供したい体験を見据えた設計や議論が重要です。
 

🔄 3. 安定的なデリバリー

ビルド、テスト、デプロイを自動化することで、開発サイクルを迅速化し、品質の維持向上を図ります。CI/CDの実践によって効率的なビルドプロセスと迅速かつ安全なデプロイ戦略を実行します。これにより開発チームはリリースプロセスをスムーズに進め、顧客に価値を迅速に届けることができます。
 

3-1. テスト

💡
WebフロントエンドのテストはUIに対する煩雑なテストコードが忌避されてしまうこともありますが、適切なテストの設計と計画によって開発効率と堅牢性を両立できます。過剰なテスト計画は運用におけるソフトウェアテストの持続可能性を損ね、手作業に依存しすぎることも開発効率を損ねてしまいます。プロダクトの開発フェーズに応じてテストすべき対象と、その方法の見極めることが必要です。

3-2. ビルド

💡
昨今のWebフロントエンドにおいてビルドプロセスは最終的にユーザーに対して配信されるアセットをコートベースから生成するために不可欠な工程です。ビルド処理時間の遅延、設定ファイルの複雑化など、いずれもデリバリーの効率性を損ねる要因です。メンテナンス工数の確保はもちろん、チーム状況に応じて持続可能な選定および計画を策定することが重要です。
 

3-3. デプロイ

💡
コンスタントにデプロイできる仕組みづくりは価値提供の頻度や効率に繋がります。安全性や確実性を重視する観点と共に、迅速な価値提供のためには攻めの姿勢も一定必要とされます。不確実性の中で攻めの姿勢を支えるためには事後の異常検知やProgressive Deliveryの環境を整備することが重要です。
 

3-4. サプライチェーン

💡
サプライチェーンはコードベースにおける各種の依存関係を指します。昨今Webアプリケーションはnpmを筆頭としたエコシステムの上で非常に大きなサプライチェーンに依存して成り立っています。依存ライブラリの更新や交換、削除をする工数や体制の確保はコードベースの鮮度ひいては持続可能性を保つために必要な取り組みです。
 

3-5. CI/CD

💡
デリバリー全体を支えるCI/CDの仕組みはWebフロントエンド技術領域がUI層だけでなくWebアプリケーション全体を包含しつつある中で、Webフロントエンド開発者にも一定以上の理解と関与が求められています。分担はチームや組織の体制に依存するものの、全体的な工程の理解や自動化の推進は積極的に行うべきテーマです。
 

✏️ 4. 効果的なシステム設計

ユーザーの要求とビジネスのニーズに合わせたアーキテクチャ選定と、最適なユーザーエクスペリエンスとパフォーマンスを実現するための戦略立案が求められます。これにはモジュール性、拡張性、および保守性を考慮した設計が含まれます。適切な設計を通じてシステムは将来の変化にも柔軟に対応できるようになります。
 

4-1. サーバー

💡
サーバー周りはフロントエンドとは無関係ではなく、むしろ昨今ではどのようにデータとUIを結びつけるかといった活動の中で中核の部分であると言えるでしょう。その中でどのようにサーバーサイドと協調するか、運用をしやすいメトリクスを収集するかについてまとめています。本項目を達成することで開発生産性と運用継続性を向上させることが可能です。
 

4-2. インフラ

💡
Webフロントエンドに限らない部分であるインフラのメトリクスとPlatform as a Service の運用についてまとめています。CDNはもはやフロントエンドが関わる必要がある構成要素であり、また専用のインフラエンジニアを職責として持てないような組織ではPlatform as a Service の検討も必要だと思っています。インフラとフロントエンドがどのような距離感で関わるかは今後の組織体制や能力開発において重要項目であり、本クライテリアを達成することで組織において高い運用能力を得ることが可能です。
 
 
 

4-3. キャッシュ

💡
CDN、ブラウザのキャッシュは強力である反面、意図しない不具合を招いてしまうこともある側面を持ちます。使い所を間違えたり、理解が浅いまま利用してしまうと、大きな障害を引き起こす危険性を持っており、どうやって組織に定着させるかを検討することが必要です。本項目を達成することで、パフォーマンスと耐障害性に強いプロダクトの開発ができます。
 

4-4. モニタリング

💡
フロントエンドでもBFFなどのサーバプロセスを運用する以上、ダウンタイムやプロセスの監視は必要になります。また、それだけではなく、エラーが起きている事を監視する必要もあります。これらの項目を達成することで、障害発生時にスムースに対応ができるようになります。
 
 

4-5. 障害対応

💡
フロントエンドにおいても障害発生は無関係ではありません。対応をしなければ、バックエンドやインフラと同様、信頼性の低いサービスとして認識されてしまいます。障害発生はチーム全体での作業であるため、他人任せにするというやり方ではなく、ロールと責任を明確にした上で積極的に関わる姿勢が必要になります。本クライテリアを達成することで、耐障害性に強い組織を作ることが可能です。
 

🤝 5. 成長できるチーム

技術力の向上、効果的なコミュニケーション、およびチーム間の協力を促進するために、教育プログラムやワークショップを定期的に開催し、適切な職務分担を確立します。チーム文化の育成とメンバーひとりひとりの専門性の獲得が変化への迅速な適応につながり、持続的なチーム成果の鍵となります。
 

5-1. 専門性の育成

💡
フロントエンドのようなまだ分野として確立されていない領域では、技術交流、教育、プロトタイプ開発といった複数の手段を持って専門性を獲得する必要があります。本クライテリアでは複数の手段を有しているか、チーム全体でそれを養おうとする空気があるかを確認することで専門性が獲得しやすい環境になっているかを確認しています。

5-2. イネーブリング

💡
開発者の生産性を上げることや利用可能な技術を育成を通じて増やす活動をイネーブリングと呼びます。チームトポロジーのイネーブリングチームという用語から取りました。本クライテリアはフロントエンドの利用可能な技術や生産性を増やす活動を指しており、またそれらを継続的に運用を通じて底上げしていく指標を指しています。

5-3. 職務定義

💡
フロントエンドチームはチーム全体のハブになることが多いです。デザイナー、プランナー、バックエンドエンジニア、インフラエンジニアなどの架け橋になります。必然的に複数の能力が必要になり、またソフトスキル面も重要になります。職務の範囲を定義し、キャリアの方向性を講じていく必要があります。本クライテリアではそういう職務を定義しているかといった指標を作って確認しています。
 

5-4. ビジネス連携

💡
フロントエンドエンジニアはUIを構築することだけではなく、その活用状況を分析し、ビジネスに活かす必要があります。その際にはマーケティング部門やデザインと言った他分野と協業し、ビジネスドメインの知識を学習していく必要があります。本クライテリアではこういった連携ができているかをベースに指標が作られています。
 

5-5. 外部発信

💡
専門性の育成部分でも触れてますが、フロントエンドは流行り廃りが激しいこともあり、知見を内外に発信していくことが、自分たちの専門性を上げるうえでも、ブランディングによる採用の観点でも重要になります。特に誰か一人だけが発信しているのではなく、チーム全体で継続して続けていくことが重要になります。