ID:78628さん

- **役割：** フロントエンドエンジニア（リード） - **体制：** フロントエンドエンジニア 2名 / バックエンドエンジニア 3名 / デザイナー 1名 / QAエンジニア 1名 - **技術スタック：** HTML, CSS, TypeScript, Ruby / Next.js, Ruby on Rails / MUI **【概要・背景】** カルテアプリケーションのフロントエンドリプレイスおよびデザインシステムの構築を担当しました。誕生から約5年が経過したRuby on Rails製の既存アプリケーションでは、フロントエンドまでRailsで実装されていたため、MUIやshadcnなどのモダンなUIライブラリを使用することができず、理想とするデザインや操作性の実現が難しい状況でした。また、最初のリプレイス対象となった「カルテ画面」では、初期表示時にユーザーに紐づくすべての予約・カルテデータを一括取得する設計になっており、通院回数に比例してレスポンスが遅延するというパフォーマンス課題も抱えていました。これらを解決するため、TypeScriptとNext.jsを用いたモダンなフロントエンド環境への段階的リプレイス方針を策定し、メイン機能であるカルテ画面の刷新とデザインシステムの構築に着手しました。 **【自身の役割】** 本プロジェクトにおいて、要件定義、アーキテクチャ設計、詳細設計、実装、テスト、コードレビュー、リリースまでを一貫して担当しました。また、チームの「チャンスがあれば積極的に職能を越境する」という方針のもと、フロントエンド開発にとどまらず、スキーマ定義やシンプルなAPI実装も自発的に担当しました。 **【発揮したバリュー・成果】** **医療要件に応えるためのフロントエンドアーキテクチャの設計とリード：** 新規カルテアプリケーションの開発において、Next.js（App Router）をベースとしたフロントエンドリポジトリをゼロから構築し、アーキテクチャ設計をリードしました。医療現場では、適用されている処方箋や医師が入力したメモなどの情報をもとに医療が行われるため、それらの情報をリアルタイムかつ正確に表示する必要がありました。そのために、主に以下の2つのアプローチを実践しました。 1. **Feature-basedアーキテクチャの採用：** App Routerのルーティング層（`app`）と機能層（`features`）を明確に分離し、機能ごとにUIとデータフェッチをまとめました。React Server Components（RSC）の登場により、サーバー側で高速にデータの取得を行いつつ、各コンポーネントが独立して必要な情報のみを取得できるようになったことで、機能ごとの分割が容易になりました。そのため、レイヤーや技術的な分類ではなく、機能単位で実装をコロケーション（近接配置）できるFeature-basedなフォルダ構成が、最も自然で開発が行いやすいと考えたためです。 また、この構成はAIの精度にもプラスに働くと考えています。それは、AIはディレクトリツリーを移動する回数が増えるほど推論ミスを起こしやすくなる傾向があるためです。例えば、「ユーザー設定の更新フォームを修正して」と指示した際、src/components/、src/hooks/、src/types/ のように技術レイヤーごとに情報が散らばっていると、AIのコンテキスト移動が必然的に増え、出力精度が落ちてしまいます。一方、Feature-basedな構成であれば、対象となる src/features/user-setting/ などの特定のディレクトリだけをコンテキストに含めるだけで完結するため、ハルシネーションが減り、結果としてAIの出力精度向上へと繋がります。 2. **確実なリアルタイム同期を実現するデータフェッチ戦略：** 患者情報をリアルタイムに画面へ反映させる要件に対しては、RSCによる高速なデータ取得を起点とし、WebSocketで更新通知のみを受信し、それをトリガーにSWRの`mutate()`を発火させて再フェッチする方針を考案して実装しました。WebSocketで実際のデータを直接受け取り上書きする設計にしなかった理由は、通信遅延によってはメッセージの到達順序が不安定になり、古い情報で画面が上書きされてしまうリスクがあり、それが重大な医療事故に直結すると考えたためです。更新通知をきっかけに常にAPIを実行し、DBから最新の値を直接取得し直すことで、構造的にデータの不整合を排除しました。これらの設計により、RSCによる高速なデータ表示を実現しつつ、医療現場での実用に耐えうる確実なリアルタイム同期を両立させることができました。 **OpenAPIを活用した型安全なAPI連携とバックエンドとの協業：** APIレスポンスへの型付けと、フロントエンド・バックエンド間におけるインターフェースの認識齟齬を防ぎ、シームレスにAPI開発を進めるため、Rails側にはRSpecからOpenAPIスキーマを自動生成する`rswag`を導入しました。Next.js側では、スキーマから型定義を出力する`openapi-typescript`と、軽量なAPIクライアントである`openapi-fetch`を採用しました。これにより、エンドポイントとHTTPメソッドを指定するだけで、深いネストを持ったレスポンスの型までが完全に自動推論される仕組みを構築しました。この取り組みにより、型定義を手作業で管理する工数をゼロにしつつ、バックエンドの仕様変更による影響を開発時に確実にとらえられるようになり、安全かつ開発体験の高い協業体制を確立することができました。なお、API通信用の関数やSWRのフックまでを自動で生成するツール（Orvalなど）を採用しなかった理由は、「OpenAPIによる型推論」という本来の目的に対して、フックまで自動生成する機能はオーバースペックであると判断したためです。また、Feature-basedアーキテクチャを採用していた背景から、自動生成されたグローバルなフックをUIコンポーネントから直接呼び出すよりも、`openapi-typescript`の型を活用し、各Feature内でドメインに則した関数を定義する方が、機能の境界線をクリーンに保てると考えたためです。 **型安全なMUIラッパーによるデザインシステム構築とUI/UXの最適化：** 本リプレイスプロジェクトと並行して、MUIをベースとしたデザインシステム構築の実装リードを担当しました。構築にあたっては、最初からコンポーネントを網羅的に実装するのではなく、メイン機能である「カルテ画面」に必要なものから順次実装する段階的アプローチを提案し、実行しました。具体的なユースケースがない状態で実装を進めると、デザイン要件の必要性の判断を推測に頼ることになり、不要なパターンを生み出して開発スピードの鈍化や実装の複雑化を招く可能性があるためです。実際の画面構築と並行して仕様を固めることで、無駄がなく実用性の高いコンポーネント群を効率的に実装することができました。 また、MUIの標準コンポーネントは自由度が高く、デザインシステムで定義された仕様から逸脱した表現が実装者の裁量で可能になってしまう課題がありました。これを防ぐために各MUIコンポーネントのラッパーを作成し、デザインシステムで許可された表現（例えばModalのsizeはmediumまたはlargeのみ許可する等）をTypeScriptの`Omit`等を用いて型レベルで厳格に制限しました。さらに、ESLintの`no-restricted-imports`ルールにより、`app`や`features`層でのMUIの直接インポートを禁止し、必ず自作のラッパーを経由する仕組みを構築しました。これにより、デザインシステムで定義されていない表現を機械的に防ぐだけでなく、AIエージェントが型情報から仕様の制約を正確に推論できるようになり、AIによるコード生成精度の向上にも寄与しました。 さらに、MUIの標準仕様から逸脱したデザイン要求に対しては、将来的なメンテナンス性の低下を防ぐ観点から、MUIの設計思想に沿った代替案をデザイナーへ提案・調整しました。具体例として、「担当医情報ドロワー」と「診療所変更モーダル」を同時に開いたとき、現在の担当医を確認しながら操作したいという理由から「ドロワーを上に表示したい」という要望がありました。しかし、MUIの標準仕様（z-index: ドロワー1200 / モーダル1300）では、モーダルがドロワーの上に表示される仕様になっています。これは、UIの意味的にドロワーは「情報補助」、モーダルは「意思決定・注意喚起」に使われるため、より重要度の高いモーダルの表示を優先するというMUIの設計思想を反映したものだと考えています。この仕様を崩して強引に表示順を入れ替えると、レイアウト崩れやz-index管理の複雑化を招くだけでなく、操作の主従関係が曖昧になりユーザーの認知負荷を高めるリスクがあります。そこで、「担当医情報を確認しながら選択したい」という本質的なニーズを満たすため、モーダル内に現在の担当医サマリーを表示し、モーダル内で操作を完結させるUI案を提案しました。結果としてデザイナーからの合意を得ることでき、MUIの標準設計に従いつつ、ユーザーにとっても使いやすいUIを実装することができました。

- **役割：** フロントエンドエンジニア（リード） - **体制：** フルスタックエンジニア 2名 / フロントエンドエンジニア 2名 / デザイナー 1名 - **技術スタック：** HTML, CSS, TypeScript / Next.js, Hono / shadcn/ui, Tailwind CSS, Zod, Prisma **【概要・背景】** モバイルオーダーおよびPOSレジシステムにおける、デザインシステムの構築、UX改善、および新規機能開発を担当しました。同社ではこれまで開発スピードが優先され、専任デザイナーが不在であったため、エンジニアがデザインと実装を兼任していました。その結果、同一アプリケーション内でもページごとにUI表現の不一致が生じるなどの課題が発生しており、これらを解決すべくデザインシステム構築プロジェクトが立ち上がりました。また、ITリテラシーを問わず不特定多数のユーザーが利用するtoC向けアプリケーションであるという性質から、UXやアクセシビリティの改善要望が多く蓄積している状況でした。 **【自身の役割】** デザインシステム構築をメインミッションとする短期スポットメンバーとして参画し、本プロジェクトにおいて、マイルストーンの策定から技術選定、詳細設計、実装、デザインレビュー、コードレビューまでを一貫して主導しました。また、これらの本務と並行して、UX改善やクーポン機能などの新規機能開発にも自発的に従事しました。 **【発揮したバリュー・成果】** **限られた期間内でのデザインシステム構築の完遂とプロジェクト推進：** 約3ヶ月という限られた契約期間内で、達成要件であるデザインシステムの構築を確実にやり切るため、まず全体のマイルストーンを策定し、プロジェクトの進行をリードしました。具体的には、策定したマイルストーンをもとに週次のスプリントごとに進捗の振り返りと調整を行い、遅延のない開発サイクルを維持するよう推進しました。結果として、期間内にデザインシステムで定義された主要コンポーネントの実装から既存コンポーネントの置き換えまでを無事完遂させることができました。 **shadcn/uiの採用による実装効率の最大化と学習コストの最適化：** デザインシステムで定義されたコンポーネントを実装するためのライブラリとして、shadcn/uiを採用しました。独自のデザイン要件に合わせたスタイリングを実現するため、Headless UIライブラリの利用を前提とし、候補としてshadcn/ui、Radix UI、React Aria Componentsの3つを挙げました。その中でshadcn/uiを選定した最大の理由は、「実装のしやすさと学習コストの低さ」です。本プロジェクトではフロントエンド専業ではないフルスタックエンジニアもUI実装を担当する体制であったため、実装への参入障壁を下げることが極めて重要でした。 Radix UIやReact Aria Componentsは自由度が高い半面、自前でProps設計を行いラッパーコンポーネントを実装するコストがかかります。対してshadcn/uiは、CLIを用いて実装済みのコンポーネントをプロジェクト内に出力できるため、導入および学習コストを大幅に抑えられると判断しました。また、コンポーネントのソースコード自体がプロジェクト配下に追加されるため、node_modulesに隠蔽されるよりも内部仕様の把握やカスタマイズが容易である点も大きな魅力でした。すでにプロジェクト内でTailwind CSSが採用されていた技術的背景との親和性も高く、結果としてフロントエンド専任以外のメンバーでも迅速かつ比較的容易にUI実装が行える環境を構築することができました。 **チーム全体の生産性とコード品質を向上させる開発基盤の整備：** これまで開発スピードを優先してきた結果として後回しになっていた開発基盤の整備にも着手し、具体的に以下の3つの施策を主導しました。 1. **テスト戦略の策定とチームへのテスト文化の浸透：** テストを書く習慣がチームに浸透しておらず、カバレッジが不足している状態でした。限られた工数の中で最大の効果を得るため、UIテストよりも優先度が高いと判断した「純粋なビジネスロジック（合計金額や食べ放題の残り時間計算など）」のテスト実装から着手しました。これらは副作用を持たずテストが書きやすい上、ビジネスへのダイレクトな影響が大きいためです。次に、API通信部分のテストを実装し、「正しいパスとメソッドでの呼び出し」「Zodによるリクエストのバリデーション」「Prisma経由でのデータベース保存の成功」を確認することで、Hono、Zod、Prismaの各レイヤーが正しく連携することを保証しました。 また、特定のメンバーのみがテストを書く属人化を防ぐため、必要なテストケースを事前に `test.todo` としてコード上にドキュメント化し、ファイルごとに実装チケットを起票しました。実際のテストコード実装をフロントエンド経験の浅いメンバーにアサインすることで、参入障壁を下げつつチーム全体にテストを意識する風土を醸成することができました。 2. **Storybookの運用ルール策定によるコンポーネント管理の最適化：** 導入済みのStorybookにおいて、コンポーネントの表現パターンの定義基準が統一されていない課題がありました。そこで、開発者が迷いなく実装・確認を行えるように、以下の3つの運用ルールを策定しました。 第一に、「Defaultは最も情報量が少ない状態のこととする」と定義しました。Defaultではコンポーネントの役割の大枠を確認することが目的であるため、オプショナルな要素を除外した最も標準的なユースケースを基本状態としました。 第二に、「Enum型（sizeやcolorなど）Propsの切り替えはControlsパネルから確認する」運用としました。すべての組み合わせに対してストーリーを作成するとパターン数が膨大になり、VRTの実行コストを圧迫してしまうためです。 第三に、「要素の分岐（DOM構造の変更）が入る場合は、独立したパターンとして定義する」としました。例えば、通知バナーにオプショナルな `title` を渡し、新たに `<h3>` タグが描画される場合などは独立させます。DOM要素が変わるということはUIが提供する文脈や役割が変わることを意味し、これをControls任せにするとUIの文脈が隠蔽されてしまうと考えたためです。 これらのルールにより、既存のストーリーを整理できただけでなく、チーム全体が明確な判断軸を持って開発を進められるようになりました。 3. **Knipの導入とCI連携による不要コードの継続的排除：** 機能開発を進める中で、未使用の型定義や命名規則変更時の旧関数の残留など、不要なデッドコードが蓄積していることが判明しました。これらは可読性低下や保守性悪化につながるため、静的解析で不要コードを検出・削除するツールとしてKnipを導入しました。段階的に不要パッケージや型定義の削除を進めてローカル環境でのエラーをゼロにした後、KnipのチェックをGitHub Actionsに組み込みました。これにより、PR作成時やコミット時に自動チェックが実行され、継続的に不要なコードが混入することを防ぐ仕組みを構築しました。

- **役割：** フロントエンドエンジニア - **体制：** フロントエンドエンジニア 5名 / バックエンドエンジニア 2名 / デザイナー 1名 / QAエンジニア 1名 - **技術スタック：** HTML, CSS, TypeScript / Next.js, React / Turborepo, GraphQL, urql, CSS Modules, Radix UI, eslint-plugin-jsx-a11y, Markuplint, @axe-core/playwright, SonarQube **【概要・背景】** 既存の経費精算システムからフロントエンドを独立させ、技術的負債を解消する新規プロダクトの開発を担当しました。本システムは誕生から約6年が経過しており、Railsに依存したCoffeeScriptによる実装や不十分なテストによる目視での動作確認、バックエンドとの密結合など、技術的負債が蓄積している状況でした。これが開発者のモチベーションを低下させるだけでなく、採用においても「技術がレガシーで成長できるか不安」という懸念から内定辞退の要因となるなど、全社的な課題となっていました。この状況を打破するため、新規リポジトリを作成し、Next.jsとTypeScriptを用いたモダンなフロントエンド環境を立ち上げ、画面ごとに段階的なリプレイスを実施しました。 **【自身の役割】** 機能開発における詳細設計、実装、テスト、コードレビュー、QA対応、およびデザイナーとの仕様調整を一貫して担当しました。また、自身の強みであるアクセシビリティやスタイリングに関する知見をチームへ積極的に共有し、レビューを通じてチーム全体のコード品質向上と最適なUI実装を牽引しました。 **【発揮したバリュー・成果】** **大規模リプレイスにおけるスコープ調整とステークホルダーとの合意形成：** 本プロジェクトにおいて最も苦労したのは、開発と並行して発生する「スコープの調整」でした。当時、デザインシステムの導入やインフラのAWS移行など全社的なプロジェクトが複数同時進行しており、想定外の連携作業が発生していました。さらにビジネス側からは、「リプレイスのついでにレイアウトを大きく変えたい」「既存の仕様ごと作り直したい」という要望も寄せられました。 しかし、社内でもほとんど前例のない大規模リプレイスにおいて、仕様変更まで同時に行ってしまうと、バグ発生時の原因特定が極めて困難になります。そこで私はチームとしてステークホルダーに対し、「Next.jsへの移行さえ完了すれば、そうした機能改善もより素早く行えるようになるため、まずは既存仕様の再現に集中させてほしい」というロードマップを提示し、丁寧に交渉を行いました。そうしてリプレイスにおけるスコープについて、他チームやビジネスサイドとうまく合意形成を図りながら、無事にモダンな環境へのリプレイスとリリースを達成することができました。 **Radix UIの技術選定：** UIコンポーネントライブラリの選定において、Ant Design、Radix UI、React Ariaの3つを比較検証し、最終的にRadix UIを採用しました。 当初は社内実績があるAnt Designも有力な候補でしたが、リプレイスと並行して構築中であった経費精算システム独自のデザインシステムを適用するためには、ライブラリが持つ既存のスタイルをオーバーライドしていく必要があり、将来的なメンテナンスに懸念がありました。そのため、UIの振る舞いのみを提供し、スタイリングは実装側でコントロールできるヘッドレスUIからの選定としました。 次に、WAI-ARIAに準拠したヘッドレスUIであるReact AriaとRadix UIを比較しました。当時のReact Ariaは、状態管理フック（@react-stately）とDOMへのバインディング（@react-aria）を手動で行う必要があり、実装コストが高いという課題がありました（※当時はまだreact-aria-componentsはメジャーリリース前だったため検討対象に含めませんでした）。対してRadix UIは、Compound Componentパターン（Dialog.RootやDialog.Triggerなど）を採用していて、通常のHTMLに近い直感的なツリー構造でマークアップできるという利点がありました。 この「実装の容易さ」「コードの可読性」を評価してRadix UIを採用し、結果として独自のUIデザインで定義されたデザインシステムを、高いアクセシビリティと優れた開発体験を両立して構築することができました。 **品質とアクセシビリティを継続的に改善する仕組みづくり：** 開発者のスキルに依存せず品質を担保する仕組みとして、静的解析ツールの eslint-plugin-jsx-a11y や Markuplint を導入しました。さらに、カラーコントラストなどコードベースだけでは判定が難しい視覚的なアクセシビリティ要件の検証を自動化するため、@axe-core/playwright を用いたテストを実装しました。また、静的コード解析ツールである SonarQube を導入し、テストカバレッジなどの品質指標を可視化・測定できる体制を整えました。 単にツールを導入するだけでなく、これらのテスト結果やカバレッジをチームで確認・吟味する定例会を週に一度設けました。対応が必要だと判断したものは実装チケットとして起票し、通常のスプリントに組み込む運用フローを構築しました。この仕組みにより、機能開発が進むにつれて後回しになりがちな技術的負債の解消や品質向上といったプロジェクトメンテナンスを、開発プロセスの一部として継続的に実行することができました。 **【執筆記事】** 技術書典マーケットでの「Money Forward TechBook #8」にて、本分離プロジェクトで行ったアクセシビリティ改善活動について「アクセシブルなプロダクトを提供するための取り組み」という題目で執筆しました。その他プロジェクト関連の執筆記事は以下の通りです。 - [aria-labelで始める、アクセシビリティ改善活動](https://zenn.dev/moneyforward/articles/b5c9b060cf9237) - [marginではなく、レイアウトを指定しよう（レイアウト手法 Stack、Clusterの紹介）](https://zenn.dev/moneyforward/articles/075a74334ca512) - [画像が「情報」を持っているかどうかの判断基準、持っていない場合はalt=""を指定しよう](https://zenn.dev/moneyforward/articles/bc93f64ba4d36a) - [href="#"のみの指定はやめよう（フォーカス移動の問題点）](https://zenn.dev/moneyforward/articles/18c45ef93815dd)

- **役割：** フロントエンドエンジニア（リード） - **規模/体制：** フロントエンドエンジニア 3名 - **技術スタック：** HTML, CSS, JavaScript, TypeScript, Ruby / React, Ruby on Rails / Redux, GraphQL, Apollo Client, styled-components, Radix UI, eslint-plugin-jsx-a11y **【概要・背景】** 経費精算システムのフロントエンドにおける実装改善活動を主導しました。同システムは誕生から約6年が経過しており、事業成長のスピードを優先してきた背景から、複数の技術的負債が蓄積していました。具体的には、同一機能におけるUIの不一致、古いパッケージバージョンに起因するセキュリティアラート、統一されていないコーディングスタイルなどです。これらの課題を解決するため、課題の重要度や作業量を見積もり、定常的な業務プロセスとして改善に取り組む計画を策定・主導しました。 **【自身の役割】** 各課題の重要度の評価・整理、実装、レビューを担当しました。また、パッケージ管理などの定常作業を統一された手順で業務プロセスに組み込むため、ドキュメントの整備や定期的な共有会を主導しました。 **【発揮したバリュー・成果】** **定常的な改善体制の構築と推進：** フロントエンドメンバーが各々課題感を感じているにも関わらず、それぞれ別々のプロジェクトを持っており、改善のための動きが取りづらい状態でした。そこで、まずフロントエンドメンバー全員で集まり、各自が抱える課題感や改善要望を洗い出す機会を設けました。次に、挙がった課題に対して「重要度（解決することで得られるメリット）」と「作業量」を見積もりました。 このように課題と工数を可視化することで、他プロジェクトのメンバーやビジネスサイドにも「これをすることでどのようなメリットが得られるか」を伝えやすくなり、スプリント内で作業の時間を確保できるようになりました。結果として、メンバーそれぞれが自身のプロジェクトの進捗状況に合わせてチケットを取り、実装を進める体制を整えることができました。具体的には以下のような改善を行いました。 - **デザインシステムの推進：** 当時の経費精算システムでは、同じ機能を持つUIであるにも関わらず、画面によってデザインが違う箇所が多く存在しており、それを解決するためのデザインシステム構築が進んでいました。コンポーネントライブラリとしては元々MUIが採用されていましたが、独自で定義されたデザインシステムを実装するために、実装者側でスタイルをコントロールできるヘッドレスUIであるRadix UIを採用し、新規コンポーネントを作成しながらMUIからの段階的な移行を実施しました。 - **品質・スタイルの統一：** ESLintおよびStylelintを導入し、コーディングスタイルの統一と検出エラーの解消に着手しました。既存コードへの影響を考慮し、まず検出されたエラールールを一時的に無効化し、ルールごとの修正チケットを作成して、それらをひとつひとつ有効にしていく段階的な修正を行いました。 - **パッケージバージョン管理体制の構築：** dependabotを導入し、統一された手順でバージョンアップを行う体制を構築しました。「パッチバージョンアップはCIが通っていればマージ可能」「マイナーバージョンアップは破壊的変更がないかリリースノートにしっかり目を通す」といった基準をドキュメントに整備し、定期的な共有会を実施しました。結果として、バージョンアップ未処理のパッケージを120件から30件へと大幅に減少させることができました。 **セレクトUIのパフォーマンス改善：** 当時、エンタープライズのお客様から「経費登録画面が重い」という不満が多く寄せられていました。そこで原因特定から解決までのパフォーマンス改善を主導しました。 調査の結果、原因は経費登録画面の従業員セレクトフォームが、APIから一括で全従業員のデータを読み込んでいることだと分かりました。この画面では複数の経費明細を登録できるため、例えば2,000人の従業員がいる会社で100件の明細を作ろうとすると、計20万件という膨大な量のデータをレンダリングすることになり、それが深刻な画面の遅延につながっていました。 そこで仕様を見直し、初期読み込みを先頭100件に制限した上でインクリメンタルサーチを行う方式を提案し、実装しました。結果として、エンタープライズ利用時におけるDOMレンダリング件数を最大で数万〜数十万件規模から常に100件程度へと大幅に削減することができました。このパフォーマンス改善は、課題の原因発見から設計、実装、バックエンドエンジニアとの連携、ビジネスサイドへの確認までを一貫して実施し、エンタープライズのお客様の操作体験を大きく向上させることができました。

- **役割：** フロントエンドエンジニア（リード） - **規模/体制：** フロントエンドエンジニア 2名 / バックエンドエンジニア 3名 / デザイナー 1名 / QAエンジニア 1名 - **技術スタック：** HTML, CSS, JavaScript, TypeScript, Ruby / React, Redux, GraphQL, Apollo Client, styled-components, Ruby on Rails **【概要・背景】** 経費精算システムにおいて、ユーザーが任意のマスタデータを定義できる新規機能のフロントエンド開発をスクラム体制で主導しました。既存システムには「部門」や「従業員」など固定のマスタしか存在せず、企業独自のデータ定義ができないことが原因で失注に繋がるケースが発生していました。この事業課題を解決し、エンタープライズ企業の要件にも対応できるデータ基盤を提供するため、新規機能の開発プロジェクトが立ち上がりました。 **【自身の役割】** 機能開発における詳細設計から実装、テスト、QA対応、およびデザイナーとの仕様調整を一貫して担当しました。また、プロジェクト途中で参画したフロントエンドメンバーのオンボーディングと実装サポートも行いました。 **【発揮したバリュー・成果】** - **脱Rails依存を見据えたReactの導入と新規画面開発：** 本プロダクトで初となる、Reactを採用した新規画面の開発を担当しました。将来的にフロントエンドを独立させることを見据え、当時主流だった react_on_rails の採用は見送りました。代わりに、HTML上の特定DOM要素にReactアプリケーションを手動でマウントする jsbundling-rails を採用することで、Railsへの過度な依存を避ける構成にしました。また、並行して進んでいたデザインシステムに準拠した新規コンポーネントの開発も行いました。 - **プロトタイプによるUX改善と、リスクを抑えた段階的移行：** 任意マスタが追加できるようになったことで、マスタ一覧のデータテーブルの表示が窮屈になり、視認性が下がる課題が発生しました。これに対し、「テーブルの折りたたみ機能」と「横スクロール」の2パターンのプロトタイプ（デモ）を作成してPdMやデザイナーに提案し、より使い勝手の良い横スクロール方式で合意を得ました。 また、このテーブルはアクセス数が多い主要な申請画面など計15箇所に存在し、すべてRailsによって実装されていました。これを一気にReactへ置き換えるのは不具合発生時のリスクが高すぎると判断し、安全性を考慮して少しずつ置き換えていく「段階的移行」を計画・実行しました。この課題発見から技術検証、実装、ビジネスサイドとの調整までを一貫して遂行しました。 - **新規開発に先行する技術的負債の解消（ドラッグ&ドロップ）：** 新規画面にはドラッグ＆ドロップ機能が必要でしたが、既存の画面で使われていた @react-dnd は実装が複雑でメンテナンスコストが高く、当時の最新バージョン（v16）に対してv13のままアップデートされていないという課題がありました。 無理にバージョンアップの労力をかけるよりも、より洗練された新しいライブラリを採用した方が将来的にも良いと判断し、@react-beautiful-dnd を採用しました。採用の理由は、Jiraなどを手掛けるAtlassian社が開発しており今後のメンテナンスが期待できる点と、実装がシンプルだったためです。 安全に進めるため、まずは既存画面の処理を新しいライブラリに置き換えて古いライブラリを完全に削除し、その後に新規画面の実装を行いました。これにより、負債になっていた古いライブラリを一掃し、より使いやすい環境へ乗り換えることができました。 - **心理的安全性に配慮したメンバーのオンボーディング：** プロジェクト途中で参画したメンバーのオンボーディングを担当しました。まずはAPIからUI表示まで一連の流れを経験できる比較的簡単なタスクを選び、リポジトリ構成や将来的な技術方針を共有しながら、交代制のペアプログラミング（DriverとObserver）で実装を進めました。これにより、プロジェクトの全体像をスムーズに把握できるようサポートしました。 また、参画当初は新しい環境へのプレッシャーもあると考え、出社時には一緒にコーヒーブレイクをとったり、隣の席で作業していつでも質問しやすい状態を作ったりと、メンタル面でのサポートも心がけました。 - **成果：** これらの開発の工夫やチームサポートの結果、汎用マスタ機能を計画より2週間早くリリースすることができました。また、リリース後も重大な障害を出すことなく、安定した品質での機能提供を実現することができました。

- **役割：** フロントエンドエンジニア - **規模/体制：** フロントエンドエンジニア 2名 / バックエンドエンジニア 2名 / デザイナー 1名 / QAエンジニア 1名 - **技術スタック：** HTML, CSS, JavaScript, TypeScript, Ruby / React, Ruby on Rails / Redux, GraphQL, Apollo Client, styled-components **【概要・背景】** 秘書および経理担当者が他の従業員に代わって経費申請を行う、「代理申請機能」の新規開発をスクラム体制で担当しました。従来、役職者の代わりに秘書や営業事務担当が申請を行いたいという要望が多く寄せられていましたが、ダミーアカウントの作成など顧客側に運用でのワークアラウンドを強いている状態でした。この課題を抜本的に解決し、正当な権限を持つユーザーがスムーズに代理申請を行える新機能の開発プロジェクトが立ち上がりました。 **【自身の役割】** 機能開発において、詳細設計、実装、レビュー、QA、デザイナーとのコミュニケーションを一貫して担当しました。 **【発揮したバリュー・成果】** - **エンタープライズ利用を見据えたパフォーマンスの事前改善：** PdMやデザイナーと連携してUI実装を進める中で、仕様上の「申請者検索フィールド」が全従業員データを無制限に一括取得する設計になっていることに気づきました。そのままでは、数千人規模の従業員を抱えるエンタープライズ企業において画面の遅延などのパフォーマンス低下を引き起こす懸念がありました。 そこで、実装に入る前に初期読み込みを先頭100件に制限し、以降はインクリメンタルサーチで取得する方式への仕様変更を提案・実装しました。リリース後に問題になる前にボトルネックを潰すことで、大規模顧客でも快適に動作する品質を担保しました。 - **「ボーイスカウト・ルール」に基づく周辺コードの自発的な改善：** 自身の担当機能の開発にとどまらず、関連する既存画面のバグ修正や、類似機能とのUI・レイアウトの統一、可読性を高めるリファクタリング、不足していたテストコードの拡充などを機能開発と並行して自発的に実施しました。既存のコードベースに対しても「来た時よりも美しく」の精神でアプローチし、新規機能の追加に伴う技術的負債の蓄積を未然に防ぎました。 - **成果：** これらの取り組みを通じ、代理申請機能を計画通りにリリースすることができました。リリース後も大きな障害を出すことなく、安定した品質での機能提供を実現することができました。