ID:68824さん

## プロジェクトの目的 古くから運用されてきた動画配信サービスだが、内部構造が複雑化しており新規機能追加や改善などの要求に対して対応・調査が難しく (工期の長期化やバグの危険性増加) なってきている。これを改善するために全く新しいシステムとして作り直すプロジェクトである。 ## チーム構成・役割 PM やバックエンド、運用、インフラチームなどプロジェクト全体では 50 名以上が関わっており、Web フロントエンドチームは約 10 名で開発を行っている。私はリードエンジニアとして以下のような仕事をしている。 - 技術選定 - 開発環境の構築および整備 - 初期コードの実装 - Web フロントエンドチームの進捗管理 - 他チームとの技術的な窓口 ## 使用技術・開発環境 PHP から Web フロントエンドを剥がすために、Next.js App Router を使って全く別のアプリケーションを構築している。SEO を強く意識しつつ運用費用を抑える必要があるため、Bot に対しては SSR を行い、ユーザーに対しては CSR のアプリケーションを提供している。2 つのアプリケーションを同時に開発するために Monorepo 構成をとっており、共通で利用できるコードはワークスペースへ切り出すことで開発・運用の手間を減らす狙いがある。また、SSR は GKE に CSR は GCS へ配置し、アプリケーション前段に置いた Nginx で Bot 判定を行い、 Bot の場合は GKE にルーティングさせるような構成をとっている。この Nginx も Web フロントエンドチームが管理している。Web API との通信は GraphQL を利用しており、データ取得ライブラリは urql を採用した。その他には Jest, Zustand, zod などを使っている。 ## 取り組み チームメンバー全員が業務で Next.js App Router を利用するのが初めてだったため App Router 勉強会の開催、技術選定の意思決定などを残す ADR の導入、モブプログラミングの実施を行うことで開発をスムーズに開始することができた。2024/12 現在、リプレース前の現行アプリケーションを運用してきたメンバーが段階的に新しいアプリケーションの開発に加わっているが、ADR として残した意思決定は役に立っている (納得して開発に加われている) との評価をもらっている。また、開始から約 1 年半の間大きな問題なく 10 ページ以上新アプリケーションに置き換えることができている。 ## 所属会社 合同会社DMM.com

### チーム構成・役割 ミーティングを支援するウェアラブルデバイスを管理するための Web サービスの開発に業務委託 (副業) として携わっている。チームはフロントエンド・バックエンドで役割分担をしておらず、機能単位でアサインされて開発を行っている。私はフロントエンドがメインだが、必要に応じて Web API を作成するところからフロントエンド開発までを行っている。 月の稼働時間は 40 ~ 50 時間程度で、基本的には平日夜と土日に作業をしており、必要に応じて日中のミーティングに参加している。 ### 使用技術・開発環境 バックエンドは Rust で、フロントエンドは React + TypeScript が利用されている。 ### 所属会社 Fairy Devices株式会社

## チーム構成・役割 PM 1 名、デザイナー 2 名、エンジニア 5 名で構成されているチームに業務委託として所属しており以下を担当している。 - 既存機能の改修 - バグフィックス - Web フロントエンドアプリケーションのリアーキテクチャ - Web フロントエンドアプリケーションで利用しているライブラリアップデート 月の稼働時間は 40 ~ 50 時間程度で、基本的には平日夜と土日に作業をしており、必要に応じて日中のミーティングに参加している。 ## 使用技術・開発環境 バックエンドはフレームワーク無しの PHP で、フロントエンドは Vue.js と AngularJS と一部 TypeScript が利用されている。また、Gauge と Playwright、Jest などを利用し自動テストを書いている。 ## 所属会社 株式会社コドモン

## プロジェクトの目的・背景 属人化していた調達関連業務の自動化を実現することを目的にプロジェクトが始まった。また、優れた開発者体験とモダン開発の社内モデルケースを作ることも副次的な目的とされていた。 ## チーム構成・役割 プロジェクトに関わる Web フロントエンド開発者は 2 人で、プロジェクトマネージャーやバックエンド開発者も含めると 30 人以上が関わっている。明示的にリーダーは決めておらず、開発者それぞれが主体的に行動するスタイルだが、チーム外との窓口的な役割を積極的に担っている。また、ディレクトリ構成とその依存関係を示した文書やテスト戦略などを作成し、技術的にもチームをリードする様な働きをした。私は、共有された要件の確認、見積、設計、UI の提案、実装、テスト、フロントエンド開発環境のチューニングまで、フロントエンドに関わる全てを担当している。 ## 使用技術・開発環境 Vite と single-spa によるマイクロフロントエンド基盤に、TypeScript と Vue.js (3 系) を利用してアプリケーションを構築している。単体テストは Vitest、結合テスト (単体テストで保証している関数らを利用した UI コンポーネントの振る舞いのテスト) は Vue Testing Library と @testing-library/jest-dom、E2E テストは、Cypress を利用して自動テストを書いている。タスクの管理には GitHub Projects を利用しており、Feature Flag (コードを書き換えることなく動的にシステムの振る舞いを変更する開発手法) を用いて 2 週間のスプリントでスクラムを意識した開発をしている。 ## 取り組んだ課題 要求された機能を期日までに提供することができていたが、より早くユーザーへ提供することを目的に、デプロイ頻度改善を行なった。具体的には、トランクベース開発 (開発者が細かく頻繁にコードを main ブランチにマージする手法) と継続的デリバリー (コードを変更し main ブランチへマージすると自動的にデプロイの準備が実行される仕組み)を導入した。その後さらにデプロイ頻度を高めるために、継続的デリバリーの全てのプロセスに成功した場合に自動で本番環境へデプロイする仕組みも導入した。 ## 取り組みの成果 これらの取り組みによって、当初は月 / 2 回だけだったデプロイが、取り組みを開始した 8 ヶ月後には月 / 34 回のデプロイを行うことができており、Four Keys (ソフトウェア開発チームのパフォーマンスを示す 4 つの指標) のデプロイ頻度がエリート分類に到達している。また、開発者が機能開発に集中して取り組み、迅速に本番環境へ反映することができるので、利用者により早く価値を提供できる様になった。 ## 所属会社 オイシックス・ラ・大地株式会社

## プロジェクトの目的・背景 創業から 20 年以上運用されてきた EC サイトである oisix.com は、1 度も再構築などがされておらず、創業当時のソースコードに継ぎ足され開発が行われてきた。この継ぎ足され続けたソースコードが原因となり、お客様の要望や、新たな機能などを提供するスピードが遅くなっていた。これを解決するために、ソフトウェアをモダンなものに置き換えて、お客様により早くよりよい価値を提供していくことを目的に刷新プロジェクトが始まった。 ## チーム構成・役割 プロジェクトに関わる Web フロントエンド開発者は最大で 10 人おり、一時期は 2 つのチームに分かれて開発を進めていた。プロジェクトを統括するマネージャー 1 人とその他は全て開発者として参加していた。チームのリーダーは決めておらず、開発者それぞれが主体的に行動するスタイルで、私を含む全ての開発者が Issue の起票 (刷新対象の決定) 、見積、設計、実装、テストを担当していた。 ## 使用技術・開発環境 Web フロントエンドにおいては、JSP (JavaServer Pages) と jQuery を中心とした JavaScript ライブラリで UI が構成されていた。 これらを TypeScript と Vue.js へ置き換えている。単体テストは jest を利用して自動テストを行なっていた。また、変更の粒度を小さくし、リリースの影響を小さくしたいとの要件から、Web Components を利用して UI パーツをリリースの単位としていたため、E2E テストについては基本的に手動で検証をしていた。全ての UI パーツの刷新が完了したページについては、Cypress で自動テストを書いた。タスクの管理には GitHub Projects を利用しており、2 週間のタイムボックスで開発とリリースを繰り返していた。 ## 取り組んだ課題 刷新を進めるなかで、特に課題に感じ、私自身が中心となって取り組んだのは Sentry の運用だった。参画以前からランタイムエラーの監視のため Sentry が導入されていたが、異常が発生した際の具体的な対応方針などが決まっていない状態で、特定のメンバーだけがエラーに対して対応を行なっていた。これを解決するために、Sentry の Issue (同類のエラーを1つにまとめたもの) の削減方針や、アラートの具体的な対応方法および観点と監視体制を記載した文書を作成し、関係メンバー全員から同意を得たうえでチームで運用監視を行った。また、作成した方針をもとに、Issue 解決に取り組もうとするメンバーと、私がナビゲーターとしてペアプロを実施するなど知識の共有を積極的に行った。他にも Issue を適切に分類し監視対象を減らすために、メンバーを巻き込み Issue のグルーピング設定等のチューニングも行った。 ## 取り組みの成果 運用監視により異常発生を即日検知し、関係者へ対応を依頼し、検知から数日の内に解決する仕組みを作ることができた。また、運用監視を 7 ヶ月実施してメンバーへアンケートを行った結果、異常に対する感度が上がったと答えた人が 75% であったので、モチベーション向上にも繋がった運用だと感じている。これらの取り組みにより、開始時 1 日平均 157 あった Sentry の Issue 数を、約 7 ヶ月で 1 日平均 97 まで削減（38%減）することができた。日頃の刷新業務に加えて、確保できる少ない時間で成果を出すことができたと思っている。 ## 所属会社 オイシックス・ラ・大地株式会社

- Nuxt.js + microCMS + Netlify を用いた JAMstack な Web サイト制作 - Vue.js を用いた SPA の銀行通帳アプリケーションの制作 - Next.js + Web Strage を用いたアプリケーションの制作 - Shopify を用いた EC サイトの構築 - 100 ページを超える大規模サイトの制作・運用