林原優仁

## 【プロジェクト概要】 既存顧客向けワークフローシステムの新規開発 ### 【OS】 - Mac ### 【言語】 - TypeScript - Go ### 【フレームワーク】 - React ### 【DB】 - PostgresSQL ### 【その他ミドルウェア、サーバー等】 - GCP ### 【役割】 - メンバー - フロントエンドリードエンジニア ### 【プロジェクト規模】 - 要員 3 名（全体 9 名、フロントエンドメンバー３名） ## 【プロダクトの目的】 これまで各プロダクトの基本情報の情報更新は各プロダクト内部で独自に実装していました。しかし、同様の処理を各プロダクトで行うのは非常に非効率であり、拡張性に欠くため、社員の基本情報の更新処理を一手に担うプロダクトとして「ワークフロー（以下karinと呼びます）」がスタートしました。また責務の細分化ではなく、承認経路APIを他プロダクトに提供することで柔軟な申請を実現しようという目標を掲げています。 ## 【担当フェーズ】 - 要件定義/基本設計/詳細設計/実装/テスト（単体・E2E） ## 【業務内容】 - 仕様書の作成・運用 - 連携バッチの作成 - CI/CD 環境調整（フロントのみ、主に Vitest, Playwrite, Biome） - 資料作成・メンバーのマネジメント業務（進捗管理/品質管理） - プロジェクトのマネジメント業務（進捗管理/品質管理/リスク管理） ### 【実績・取り組み等①】ストーリー単位でのチケットの見直し・管理 ストーリー単位でのチケット作成により、実装の漏れや重複が多発し、進捗管理が困難でした。特に権限管理やパターンの洗い出しが重要な本プロダクトにおいて、これは致命的な問題でした。また、非エンジニアチームが開発に関与できず、手戻りが発生するという課題にも直面しました。 この問題を解決するため、開発中盤から画面単位での実装を試験的に導入し、並行してチケットの漏れや重複のチェックも行いました。これらの施策は、開発プロセスの透明性を高め、チーム全体の生産性を向上させることを目的としています。 その結果、非エンジニアでも進捗を正確に把握できるようになり、QAやデザイナーも開発にスムーズに関与できるようになりました。これにより、チーム全体の連携が強化され、プロジェクトの効率が大幅に向上しました。 ### 【実績・取り組み等➁】権限管理の仕様調整 大きく「管理者」「代理申請者・承認者」「申請者・承認者」「回付者」という権限（以降ロールと呼びます）があり、それぞれのロールに対してステータス（申請済み、承認待ちなど）がありました。 この権限管理の仕様が不完全で属人化していたため、API や画面が完成してから問題が頻発するという課題に直面しました。この問題を解決するため、まず、大きく 4 つあるロールとそれぞれのステータスを組み合わせた全パターンを洗い出しました。次に、仕様をできる限り簡略化した上で、スキーマの変更を提案・実行し、API のプロトタイプも作成しました。 これらの施策は、漠然とした不安を解消し、仕様の属人化を防ぐことを目的としています。すべてのパターンを洗い出すことで、開発の初期段階で DB やスキーマ設計の修正が必要な箇所を早期に発見できるようになり、手戻りのない効率的で正確な開発を実現することができました。 ### 【実績・取り組み等③】コードルール、レビュールール、エラールールの作成・運用 参画当初、コードルールやエラー設計に統一性がなかったため、レビューに不必要な時間がかかったり、マージまでの時間が長引くという問題に直面しました。この課題を解決するため、まずコードルールの叩き台を作成し、md 形式で管理することで、レビューの基準を明確にしました。これにより、AI（Copilot）を使ったクオリティチェックも可能にし、開発効率の向上を図りました。さらに、エラー文言や処理に関して、専用のドキュメントを作成して誰でも参照できるようにし、サーバーサイドと連携して調整を行うことで、セキュリティリスクが低く、ユーザーに配慮したエラー設計を実現しました。 これらの取り組みにより、実装者の意図が明確になり、レビューコストや手戻りが大幅に削減されました。結果として、開発プロセスの効率化とプロダクト全体の品質向上に大きく貢献しました。 ### 【実績・取り組み等④】フロント・バックエンドでの責務の厳格化 バックエンドのリソース不足により、フロントエンドの処理が過剰に肥大化するという問題に直面しました。この問題を解決するため、フロントエンドは表示と入力に終始すべきという考えのもと、チームで協議し、処理をできるだけバックエンド側で実施するよう変更しました。具体的には、スキーマの変更と一部バックエンドのユースケース実装を行いました。 これらの施策により、1 ページで呼び出す API を約 1/3に削減でき、副作用の影響の軽減、状態管理コストの劇的な低下、描画時間の短縮といった成果を達成しました。 ### 【実績・取り組み等⑤】フロントエンドパフォーマンス改善 前述のように、できる限りの処理をサーバーサイドで行うようにしたものの全てをサーバーに責務を持たせることはできませんでした。フロントでの処理もできる限り計算量を抑えることを意識し、例えば、Mapや Set の使用をコードルールに加えたり、適切な関数や Hooks の利用によるレンダリング回数を減らす取り組みを行いました。またその際、計算量などの処理への知見がないメンバーに対してはナレッジの共有を行い、理解してから実装していただけるようにフォローを行いました。 Map や Set の導入で画面のパフォーマンスが飛躍的に上昇したわけではありませんでしたが、より適切な Hooks の利用による保守性の向上や今後起こりうるパフォーマンス低下の技術負債の予防を行うことができました。またメンバーのパフォーマンスやより正しいコードを書くという責任感の向上を感じることができました。 ### 【実績・取り組み等⑥】リリース後のロードマップ原案の作成 プロダクトのリリース後、プロジェクトリーダーやバックエンドリーダーと連携し、プロダクトの潜在的な課題をリストアップし優先度付けを行いました。さらに、それらをロードマップに落とし込む計画を策定しました。この取り組みは、チーム全体が同じ方向を向き、効率的に開発を進めることを目的としています。 この結果、ロードマップに基づいた開発体制を築くことができ、チームの目標が明確化されました。 ### 【実績・取り組み等⑦】ライブラリの選定 DnD ライブラリの選定に失敗した経験から、開発効率を向上させることの重要性を学びました。その反省を活かし、次に選定に関わったAPI モックライブラリでは、バックエンドの対応を待たずにフロントエンドの開発と API 連携を完了できる点を重視しました。 この取り組みにより、開発のボトルネックを解消し、プロジェクト全体のスピードを向上させることができました。

## 労務管理アプリ 入社手続きやマイナンバーの管理、年末調整などのプロダクトに参画しています。 もともと外注によって納品されたプロダクトであるので望ましくない実装方法や仕様のリプレイスや定期リリースのためのQAなどを行なっています。 WIP