ID:78628さん

* **役割:** フロントエンドエンジニア * **規模/体制:** フロントエンド: 2名 / バックエンド: 3名 / デザイナー: 1名 / QA: 1名 * **技術スタック:** TypeScript, HTML, CSS, Ruby / Next.js, React, MUI, Ruby on Rails **【概要・背景】** カルテアプリケーションのフロントエンドリプレイスおよびデザインシステムの構築を担当しました。 誕生から約5年が経過したRuby on Rails製の既存アプリケーションでは、フロントエンドまでRailsで実装されていたため、MUIやshadcnなどのUIライブラリを使用することができず、理想とするデザインや操作性の実現が難しい状況でした。 また、最初のリプレイス対象となった「カルテ画面」では、初期表示のタイミングでユーザーに紐づくすべての予約・カルテデータを一括取得する設計になっており、通院回数に応じてデータ量が線形に増えていくことで、レスポンスが遅延するというパフォーマンス課題も抱えていました。 これらを解決するため、Next.jsとTypeScriptを用いたモダンなフロントエンド環境への段階的リプレイス方針を決定し、メイン機能であるカルテ画面の刷新と、それに伴うデザインシステムの構築に着手しました。 **【自身の役割】** 本プロジェクトにおいて、アーキテクチャ設計、詳細設計、ライブラリ選定、実装、コードレビューまでを一貫して担当しました。また、チームの「チャンスがあれば積極的に職能を越境する」という方針のもと、フロントエンド開発にとどまらず、Ruby on Railsを用いたスキーマ定義、シンプルなAPI実装も自発的に担当しました。 **【発揮したバリュー・成果】** * **MUIの特性を活かしたデザインシステムの段階的構築:** これまでのデザインシステム開発の経験を活かし、最初から全てのコンポーネントを網羅的に実装するのではなく、カルテ画面の構築に必要なコンポーネントから順次実装していく段階的アプローチを提案し、実行しました。コンポーネントのProps設計は具体的なユースケースがないと難しいと考えているためです。いくらデザインシステムとして綺麗なコンポーネントを定義したとしても、実際に画面に組み込んでみると使い勝手が悪かった。実装が難しかった。too muchだった。など実際に手を動かして、実際の画面に組み込まないと分からないことはたくさんあります。そのため、仕様が固まっている画面に必要なコンポーネントから実装していく方針を取り、無駄の少ない実用的なコンポーネントを効率的に実装しました。 * **標準設計に基づいたUI/UX調整とデザイン提案:** MUIの標準仕様から逸脱したデザイン要求に対しては、将来的なメンテナンス性の低下を防ぐ観点から、MUIの設計思想に沿った代替案をデザイナーへ提案・調整しました。 具体例として、「担当医情報ドロワー」と「診療所変更モーダル」を同時に開いたとき、現在の担当医を確認しながら操作したいという理由から「ドロワーを上に表示したい」という要望がありました。しかし、MUIの標準仕様（z-index: ドロワー1200 / モーダル1300）では、モーダルがドロワーの上に表示されるようになっています。これはUIの意味的にドロワーは情報補助に使われ、モーダルは意思決定・注意喚起に使われるものなので、より重要度の高いモーダルの表示を優先するという MUIの設計を反映したものだと考えています。この仕様を崩して強引に表示順を入れ替えると、レイアウト崩れやz-index管理の複雑化を招くだけでなく、操作の主従関係が曖昧になりユーザーの認知負荷を高めるリスクがあります。 そこで、「担当医情報を確認しながら選択したい」という本質的なニーズを満たすため、モーダル内に現在の担当医サマリーを表示し、モーダル内で操作を完結させるUI案を提案し、合意を得て、MUIの標準設計に従いつつユーザーにとっても使いやすいUIを実装することができました。 * **職能を越えた開発の円滑化とドキュメント整備:** バックエンドエンジニアなどフロントエンドを専門としないメンバーでも迷わず開発できるように、アプリケーション全体のアーキテクチャ設計、MUIのスタイリング方針、DialogやDrawerといった複合コンポーネントの利用方法を体系的にドキュメント化しました。これにより開発効率が向上しただけでなく、開発者が生成AIを活用する際にも正しいコンテキストを参照することが可能となり、チーム全体で高品質なコードを素早く実装できる体制を構築できるようになったと考えています。 * **不確実性の高いリプレイスにおけるリスク管理:** 歴史の長いシステム特有の「過去の意思決定の不透明さ」に対し、メンバー間で入念なコミュニケーションを重ねることでデグレを防止しました。また、リプレイス初期フェーズにおける不確実な領域のリスクを低減するため、PdMやデザイナーと緊密に連携し、既存仕様をベースとした、機能要件を最小限に絞り込んだコンパクトなリリース戦略を提案し、遂行しました。これにより、無事契約期間内にファーストリリースの機能実装まで完了することができました。

* **役割:** フロントエンドエンジニア * **規模/体制:** フルスタックエンジニア: 2名 / フロントエンジニア: 2名 / デザイナー: 1名 * **技術スタック:** TypeScript, HTML, CSS / Next.js, React, Hono, Tailwind CSS / Radix UI, eslint-plugin-jsx-a11y, Markuplint **【概要・背景】** モバイルオーダーおよびPOSレジシステムにおいて、デザインシステムの構築、UX改善、および新規機能開発のサポートを担当しました。それまで同社では開発スピードが優先され、デザイナーが不在であったため、エンジニアがデザインと実装を兼任していました。その結果、同一アプリケーション内でもページごとにUI表現の不一致が生じるなどの課題が発生しており、これを解決すべくデザインシステム構築プロジェクトが立ち上がりました。また、ITリテラシーを問わず不特定多数のユーザーが利用するtoC向けアプリケーションであるという性質もあり、UXやアクセシビリティの改善要望が多く溜まっている状況でした。 **【自身の役割】** デザインシステム構築をメインミッションとし、短期スポットメンバーとして参画しました。マイルストーンの策定、デザインレビュー、技術選定、詳細設計、実装、コードレビューに至るまでを一貫して主導しました。また、本務と並行して、UX改善やクーポン機能などの新規機能開発のサポートにも従事しました。 **【発揮したバリュー・成果】** * **計画的な進捗管理:** 約3ヶ月という限られた期間で確実に成果を出すため、初期段階でマイルストーンを策定、スプリントごとに進捗の振り返りと調整を行い、遅延のない開発サイクルを維持するよう心がけました。その結果、契約期間内にデザインシステムとして定義された主要コンポーネントの実装から、既存コンポーネントの置き換えまでを無事完遂させることができました。 * **多様なユーザーを想定したアクセシビリティの担保:** toC向けアプリケーションということで、なるべく多くの方々に変わらない操作性を提供するために、UIコンポーネントライブラリとしてRadix UIを採用しました。さらに、チーム全体の開発スキルに関わらず一定の品質を保つ仕組みとして、eslint-plugin-jsx-a11yとMarkuplintを導入しました。これらによって検出されたエラーを一つひとつ解消していくプロセスを通じて、チーム内のHTML仕様に関する学習と理解向上にも寄与できたと考えています。

* **役割:** フロントエンドエンジニア * **規模/体制:** フロントエンド: 5名 / デザイナー: 1名 / QA: 1名 / バックエンド: 2名 * **技術スタック:** TypeScript, HTML, CSS / Turborepo, Next.js, React, GraphQL, urql, CSS Modules / Radix UI, eslint-plugin-jsx-a11y, Markuplint, @axe-core/playwright, SonarQube **【概要・背景】** 既存の経費精算システムからフロントエンドを独立させ、技術的負債を解消する新規プロダクトの開発を担当しました。本システムは誕生から約6年が経過しており、Railsに依存したCoffeeScriptによる実装、不十分なテストによる不安定な品質確認、バックエンドとの密結合など、技術の陳腐化に伴う複数の課題を抱えていました。これらによる開発者のモチベーション低下も懸念されていたため、新規リポジトリを作成し、Next.jsとTypeScriptを用いたモダンなフロントエンド環境を立ち上げて、画面ごとに段階的なリプレイスを実施しました。 **【自身の役割】** 機能開発において、詳細設計、実装、レビュー、QA、デザイナーとのコミュニケーションを一貫して担当しました。また、自身の強みであるアクセシビリティやスタイリングに関する知見をチームメンバーと共有し、レビューを通じて最適な実装になるよう努めました。 **【発揮したバリュー・成果】** * **共通認識の形成とUI最適化:** プロジェクト初期の検証段階では、機能要件を最小限に絞り、コンパクトなリリースを目指しました。PdMやデザイナーと定期的にコミュニケーションを取り、「本件は技術的なモダナイゼーションであり、機能の完全なリプレイスではない」という共通認識の形成に努めました。また、並行して進行していたデザインシステムの整備に対しても、エンジニアの視点からUIデザインのレビューや最適化、実装方法の提案を積極的に行いました。 * **品質とアクセシビリティの向上:** アクセシビリティ改善のため、UIコンポーネントライブラリにRadix UIを採用しました。同時に、開発者のスキルに依存せず品質を担保する仕組みとして、eslint-plugin-jsx-a11yやMarkuplintを導入しました。さらに、カラーコントラストなどの検証を自動化するため@axe-core/playwrightを用いたアクセシビリティテストを実装しました。加えて、CSS Modulesによるスケーラブルなスタイリングの実現や、静的コード解析ツール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名 * **技術スタック:** Ruby, JavaScript, TypeScript, HTML, CSS / Ruby on Rails, React, Redux, GraphQL, Apollo Client, styled-components / Radix UI, eslint-plugin-jsx-a11y **【概要・背景】** 経費精算システムのフロントエンドにおける実装改善活動を主導しました。同システムは誕生から約6年が経過しており、事業成長のスピードを優先してきた背景から、複数の技術的負債が蓄積していました。具体的には、同一機能におけるUIの不一致、古いパッケージバージョンに起因するセキュリティアラート、統一されていないコーディングスタイルなどです。これらの課題を解決するため、課題の重要度や作業量を見積もり、定常的な業務プロセスとして改善に取り組む計画を策定・主導しました。 **【自身の役割】** 各課題の重要度の評価・整理、実装、レビューを担当しました。また、パッケージ管理などの定常作業を統一された手順で業務プロセスに組み込むため、ドキュメントの整備や定期的な共有会を主導しました。 **【発揮したバリュー・成果】** フロントエンドメンバーが抱える課題を洗い出し、重要度と作業量を見積もった上で、各プロジェクトの進捗に合わせた作業計画を立てました。具体的には以下の改善を実行しました。 * **デザインシステムの推進:** 開発者間でUIの見た目を統一するため、MUIからヘッドレスUIライブラリであるRadix UIへの移行と、それを用いた新規コンポーネントの開発を実施しました。 * **品質・スタイルの統一:** 同様機能におけるUIの視覚的統一を図るとともに、ESLintおよびStylelintを導入し、コーディングスタイルの統一と検出エラーの段階的修正を行いました。 * **パッケージバージョン管理体制の構築:** dependabotを導入し、定期的な共有会やドキュメント整備を通じて、統一された手順でバージョンアップを行う体制を構築しました。結果として、未処理のパッケージ数を120件から30件へと大幅に減少させました。 * **セレクトUIのパフォーマンス改善:** APIから全従業員データを一括で読み込んでいたセレクトUIの仕様を見直し、初期読み込みを先頭100件に制限した上でインクリメンタルサーチを行う方式に変更しました。課題解決に向けた設計、実装、バックエンドエンジニアとの連携、ビジネスサイドへの確認を一貫して実施し、エンタープライズ顧客の操作体験を大きく改善しました。

* **役割:** フロントエンドエンジニア (リード) * **規模/体制:** フロントエンド: 2名 / デザイナー: 1名 / バックエンド: 3名 / QA: 1名 * **技術スタック:** Ruby, JavaScript, TypeScript, HTML, CSS / Ruby on Rails, React, Redux, GraphQL, Apollo Client, styled-components **【概要・背景】** 経費精算システムにおいて、ユーザーが任意のマスタデータを定義できる新規機能のフロントエンド開発をスクラム方式で主導しました。既存システムには「部門」や「従業員」など固定のマスタデータしか存在せず、ユーザー独自のデータ定義ができないことが原因で失注に繋がるケースが発生していました。このビジネス課題を解決するため、柔軟なデータ定義を可能にする新機能開発プロジェクトが立ち上がりました。 **【自身の役割】** 機能開発において、詳細設計、実装、レビュー、QA、デザイナーとのコミュニケーションを一貫して担当しました。また、プロジェクト途中で参画したフロントエンドメンバーのキャッチアップや実装のサポートも行いました。 **【発揮したバリュー・成果】** * **Reactを用いた新規画面開発とUX改善:** 本システムで初となるReactを採用した新規画面の開発に挑戦しました。デザイナーと密に連携し、デザインシステムに準拠した新規コンポーネントを開発しました。また、任意のマスタ定義が可能になったことでマスタ一覧のデータテーブル表示が窮屈になる課題が発生したため、横スクロールの導入をデザイナーに提案し、技術検証から実装、ビジネスサイドへの確認、QAまでを一貫して遂行しました。 * **既存画面の改善:** ドラッグアンドドロップに用いるライブラリのメジャーバージョンアップや、既存画面における同様機能のUIの視覚的統一を実施しました。 * **メンバーのオンボーディング:** プロジェクト途中で参画したメンバーに対し、リポジトリ構成や将来的な技術ビジョンを説明しました。簡単なタスクを通じたペアプログラミング（DriverとObserverの交代制）を実施し、スムーズに全体像を把握できるようサポートしました。 * **成果:** これらの取り組みの結果、汎用マスタ機能を計画より2週間早くリリースすることができ、リリース後も重大な障害が発生しない安定した品質での提供を実現しました。

* **役割:** フロントエンドエンジニア * **規模/体制:** フロントエンド: 2名 / デザイナー: 1名 / バックエンド: 2名 / QA: 1名 * **技術スタック:** Ruby, JavaScript, TypeScript, HTML, CSS / Ruby on Rails, React, Redux, GraphQL, Apollo Client, styled-components **【概要・背景】** 秘書および経理担当者が他の従業員に代わって経費申請を行う、「代理申請機能」の新規開発をスクラム方式にて担当しました。従来から、役職者の代わりに秘書や営業事務担当が申請を行いたいという要望が多く寄せられていましたが、ダミーアカウントの作成など顧客側での運用回避が必要な状態でした。この課題を抜本的に解決するため、正当な権限を持つユーザーが代理申請を行える新機能の開発プロジェクトが実施されました。 **【自身の役割】** 機能開発において、詳細設計、実装、レビュー、QA、デザイナーとのコミュニケーションを一貫して担当しました。 **【発揮したバリュー・成果】** * **パフォーマンスの改善:** プロジェクトマネージャーやデザイナーと連携しながら、エンジニア視点での提案を交えてUI実装を進めました。その際、申請者検索フィールドが無制限にデータを取得する仕様となっており、エンタープライズ企業においてパフォーマンス低下を引き起こす懸念を発見しました。これを解決するため、初期読み込みを先頭100件に制限し、以降はインクリメンタルサーチで取得する方式に変更してパフォーマンスを改善しました。 * **自発的な品質向上活動:** 新規機能の開発にとどまらず、関連する既存画面のバグ修正、同様機能のUI/レイアウト統一、リファクタリング、テストコードの追加などを自発的に実施しました。 * **成果:** 代理申請機能を計画通りにリリースし、その後も大きな障害なく安定した稼働を継続させることができました。