ID:82513さん

## プロジェクト経験概要 BBCの全社デザインシステム「GEL（Global Experience Language）」のアップグレードに伴い、認証プラットフォームの共有UIコンポーネントライブラリをv1からv2へ移行するプロジェクト。6,200万ユーザーが利用するサインイン・登録画面のUIを、アクセシビリティ向上とデザイン一貫性の改善を目的にコンポーネント単位で段階的に刷新した。 ## チーム情報 - **チーム規模**: フロントエンド4〜5名（UXデザイナーと密連携） - **自分の役割**: シニアフロントエンドエンジニア、アクセシビリティチャンピオン ## 開発・実装内容A: コンポーネントライブラリv2の設計と段階的移行 ### 【概要】 認証プラットフォームの全画面で使用されるUIコンポーネント（ヘッダー、ボタン、フォーム要素、レイアウト等）を、GEL v2準拠の新コンポーネントに置き換え。 ### 【どのような機能の開発・実装か】 Storybookでコンポーネントカタログを管理しながら、v2コンポーネントを設計・実装。既存のv1コンポーネントとv2を共存させ、フィーチャートグルで画面単位に切り替えられるアーキテクチャを構築。 ### 【課題・問題点】 - 本番環境で6,200万ユーザーが利用中のUIを、ダウンタイムやデグレードなく移行する必要があった - v1コンポーネントは複数のアプリケーションから参照されており、一括置換は影響範囲が広すぎてリスクが高い - 旧コンポーネントにはアクセシビリティの課題（コントラスト不足、スクリーンリーダー非対応など）が蓄積していた - UXチームとの連携が必要で、デザインと実装のズレを防ぐ仕組みが求められた ### 【打ち手・使用した技術】 - **フィーチャートグルによる共存アーキテクチャ**: React Contextでv1/v2を切り替えるラッパーを設計。各ページでフィーチャートグルをONにするだけでv2に切り替わり、問題があれば即座にv1へフォールバック可能 - **コンポーネント単位の移行**: ヘッダー、ボタン、フォーム要素など、コンポーネントごとに独立してv2化。PRもコンポーネント/ページ単位で分割し、レビューの負荷を軽減 - **Storybookによるコンポーネントカタログ**: 全コンポーネントをStorybookに登録し、UXデザイナーが実装済みコンポーネントを視覚的に確認・フィードバックできる環境を構築。デザインと実装の乖離を早期に発見 - **アクセシビリティの組み込み**: v2コンポーネントの設計段階からWCAG 2.2 AA準拠を要件とし、セマンティックHTML、適切なARIA属性、カラーコントラスト比の確保をデフォルトに - **使用技術**: React, TypeScript, styled-components, Storybook, フィーチャートグル, Jest, react-testing-library ### 【成果】 - 本番環境でのデグレードゼロでコンポーネント移行を進行 - フィーチャートグルの共存パターンが確立され、以後のUI変更にも再利用可能なアーキテクチャに - Storybookカタログによりフロントエンドとデザインチーム間のコミュニケーションコストが削減 ## 開発・実装内容B: アクセシビリティ改善とWCAG準拠 ### 【概要】 v2移行を機に、認証フロー全体のアクセシビリティを体系的に改善。外部コンサルタントとの監査結果を反映し、v2コンポーネントにアクセシビリティをデフォルトで組み込んだ。 ### 【どのような機能の開発・実装か】 サインイン、ユーザー登録、パスワードリセットなどの全フローにおけるスクリーンリーダー対応、キーボードナビゲーション、カラーコントラスト、フォームのautocomplete/パスワードマネージャー互換性の改善。 ### 【課題・問題点】 - v1コンポーネントではアクセシビリティが後付けで対応されており、各コンポーネントの対応レベルにばらつきがあった - エラーメッセージの動的表示がスクリーンリーダーに通知されないケースがあった（ライブリージョン未設定） - パスワードマネージャーとの互換性が不十分で、autocomplete属性が適切に設定されていなかった ### 【打ち手・使用した技術】 - 外部アクセシビリティコンサルタントによる監査結果を、v2コンポーネントの設計要件として組み込み - v2コンポーネントの全フォーム要素にセマンティックHTML・ARIA・適切なautocomplete属性をデフォルトで実装 - ジュニア・ミッドレベルのエンジニアとペアプログラミングでアクセシビリティ修正を実施（チーム全体の知識底上げ） - VoiceOverでのテストを開発フローに組み込み - react-testing-libraryでgetByRole/getByLabelTextを標準のクエリ手法として定着させ、アクセシビリティとテストの品質を同時に向上 - **使用技術**: React, セマンティックHTML, ARIA, VoiceOver, react-testing-library ### 【成果】 - 認証フローが**WCAG 2.2 AA準拠**を達成 - アクセシビリティがv2コンポーネントのデフォルト品質として定着し、個別対応の工数がゼロに - ペアプログラミングによりチーム全体のアクセシビリティ知識が向上 - 自身がチームの**アクセシビリティチャンピオン**として品質基準の維持を担当

## プロジェクト経験概要 ウェールズ語委員会の法的義務（Welsh Language Standard 53）に基づき、BBC認証プラットフォームの全ユーザーフローにウェールズ語翻訳を追加するプロジェクト。約6ヶ月の期限内に、サインイン・登録・プロフィール管理画面の国際化対応を完了させた。 ## チーム情報 - **チーム規模**: フロントエンド3〜4名（翻訳チームと連携） - **自分の役割**: フロントエンドリード、実装の主担当 ## 開発・実装内容A: 認証フロー全体のi18n対応 ### 【概要】 サインイン、ユーザー登録、プロフィール編集など全ユーザーフローへのウェールズ語翻訳の組み込み。 ### 【どのような機能の開発・実装か】 既存のReactアプリケーションにi18nの仕組みを拡張し、フォームラベル・エラーメッセージ・ページタイトル・ナビゲーション要素のウェールズ語対応を実装。 ### 【課題・問題点】 - 法的義務のため期限に猶予がなく、期限超過は法的リスクにつながる - 既存のi18n実装がフォーム内テキストのみ対応しており、ページタイトルやCTA（Call to Action）コンポーネントなど未対応箇所が多数あった - 翻訳対象のUI要素を洗い出すと、複数のアプリケーションとコンポーネントライブラリにまたがっていた - ウェールズ語はテキストの長さが英語と異なるケースがあり、レイアウト崩れのリスクがあった ### 【打ち手・使用した技術】 - **対象の洗い出しと優先順位付け**: 全ユーザーフローをたどり、翻訳が必要なUI要素を網羅的にリスト化。法的要件を満たす最低限のスコープと理想的なスコープを分離し、まず法的要件を優先 - **i18nの拡張**: ページタイトル、CTAコンポーネント（他BBCサービスに注入されるサインイン/登録ボタン）など、既存のi18nが届いていなかった箇所にキー管理を追加 - **フィーチャートグルによる段階的リリース**: 画面ごとにウェールズ語対応をトグルで制御し、問題があれば個別に英語へフォールバック可能 - **レイアウト検証**: テキスト長の差異によるレイアウト崩れを確認し、flexbox/レスポンシブ対応で吸収 - **使用技術**: React, TypeScript, i18n, フィーチャートグル, Jest, react-testing-library ### 【成果】 - **法的期限内にウェールズ語対応を完了**、法的リスクを回避 - i18nの仕組みが拡張されたことで、将来的な多言語対応（スコットランド・ゲール語等）の基盤が整った - フィーチャートグルによる段階的リリースにより、本番環境での問題をゼロに抑えた ## 開発・実装内容B: テスト戦略とQA連携 ### 【概要】 翻訳の正確性と既存機能への影響がないことを保証するためのテスト戦略の設計・実施。 ### 【どのような機能の開発・実装か】 翻訳キーの抜け漏れ検出、レイアウト崩れの検証、既存テストスイートの多言語対応。 ### 【課題・問題点】 - 翻訳キーの漏れがあると未翻訳テキスト（英語）が混在し、法的要件を満たせない - 既存のテストがすべて英語テキスト前提で書かれており、ウェールズ語切り替え時にテストが壊れるリスク ### 【打ち手・使用した技術】 - テストをテキスト内容ではなくアクセシビリティロール（ボタン、フォームラベル等）で要素を特定する方針に統一し、言語に依存しないテストに移行 - 翻訳キーの網羅性チェックをCIに組み込み、キー漏れを自動検出 - **使用技術**: Jest, react-testing-library, Jenkins ### 【成果】 - 言語切り替えに依存しない堅牢なテストスイートを構築 - 翻訳キー漏れの自動検出により、リリース前の品質を担保 - テスト方針の改善はウェールズ語対応以外の開発にも恩恵をもたらした

## プロジェクト経験概要 英国BBCの認証・アカウント管理プラットフォームにおいて、EC2ベースのモノリスAPIからAWS Lambdaへの段階的な分離を担当。登録ユーザー6,200万人、週間アクティブ約2,500万人が利用するサービスで、ピーク時30,000 TPSに耐えるエンドポイントの設計・実装を行った。 ## チーム情報 - **チーム規模**: 約70名（フロントエンド、バックエンド、QA） - **自分の役割**: シニアソフトウェアエンジニア（フルスタック） ## 開発・実装内容A: トークンリフレッシュのLambda移行 ### 【概要】 認証トークンのリフレッシュ機能をLambdaへ移行し、大量プッシュ通知配信時のトラフィックスパイクに対応。 ### 【どのような機能の開発・実装か】 全BBCサービス（ウェブ、モバイルアプリ、外部連携）が依存するトークンリフレッシュAPIを、Lambda + ALB構成で再実装。ウェブからはCDN経由、サーバー間は直接呼び出しの2経路をサポート。 ### 【課題・問題点】 - プッシュ通知を一斉配信すると、全受信端末が同時にトークンリフレッシュを要求し、既存の認証基盤に過負荷が発生 - EC2のオートスケーリングではスパイクへの追従が遅く、数分間のレイテンシ悪化が常態化 - サインインp95 < 300ms、トークンリフレッシュp95 < 1秒のSLOを維持する必要があった ### 【打ち手・使用した技術】 - **段階的移行**: ALBのルーティングルールでLambdaとEC2を並行稼働させ、エンドポイント単位で切り替え。問題があれば即座にロールバック可能 - **ALBを選択した理由**: API Gatewayと比較し、コストが低くWAFとの統合が容易。既存のルーティング構成との互換性も高い - **コールドスタート検証**: 高頻度エンドポイントはほぼコールドスタートなしを確認。低頻度は1〜2秒を許容範囲と判断 - **使用技術**: AWS Lambda, ALB, CloudFormation, Node.js, Datadog ### 【成果】 - プッシュ通知トラフィックの推定55%をLambdaで処理し、既存基盤への負荷を大幅に軽減 - トークンリフレッシュの平均レスポンスタイム**約100ms**を達成（SLO p95 < 1秒を大幅にクリア） - ピーク時30,000 TPSでも安定稼働 ## 開発・実装内容B: 高トラフィック障害からのレジリエンス改善 ### 【概要】 2022年ワールドカップ期間中のサービス障害を契機に、ボトルネック特定とメンテナンスモード機能を実装。 ### 【どのような機能の開発・実装か】 障害原因の調査・修正、および障害時にユーザーへ適切なメッセージを表示するメンテナンスモードの新規開発。 ### 【課題・問題点】 - イングランド対イラン戦でサインイン・登録サービスが応答不能になり、多数のユーザーが試合前にサインインできなかった - 調査の結果、全ページロードで地理情報APIが呼ばれており、さらにエラーページからも同じAPIを呼んでいたため障害がカスケード - 次の試合まで数日しかなく、短期間での対策が必要 ### 【打ち手・使用した技術】 - Datadog・Splunkでボトルネックを特定し、不要な外部API呼び出しを除去 - エラーページの外部依存も排除し、カスケード障害を防止 - **メンテナンスモード**を新規実装：バックエンド過負荷時に静的ページを表示し、負荷を遮断。設定管理サービスのdial切り替えで即座にトリガー可能 - **使用技術**: Datadog, Splunk, AWS CloudWatch, Node.js, React, S3 ### 【成果】 - 次のワールドカップ試合ではサービスが安定稼働 - メンテナンスモードが以後の大規模イベント時の安全弁として定着 - この障害分析がレジリエンス専任チーム発足のきっかけとなった ## 開発・実装内容C: WAFセキュリティ基盤と攻撃対応 ### 【概要】 6,200万アカウントを保護するAWS WAFの設計・運用、およびボットアカウント大量生成インシデントへの対応。 ### 【課題・問題点】 - クレデンシャルスタッフィング攻撃が継続的に発生 - 1回のインシデントで約90,000件の偽アカウントがボットにより生成 ### 【打ち手・使用した技術】 - 多層WAFルール：IPブロックリスト、AWS管理のボットIP自動ブロック、5分間1,501回以上のログイン試行で自動遮断 - nonceパターン解析によるボット検出・遮断 - STRIDEフレームワークによる新機能の脅威モデリングに参加 - **使用技術**: AWS WAF, CloudFront, CloudFormation, Splunk ### 【成果】 - 偽アカウント生成を収束させ、実ユーザーのアカウント侵害はゼロ - 自動ブロック機構により継続的な攻撃への耐性を確保