ID:63889さん

# 担当業務 - マッチングアプリを開発する3名規模のチームに参画。 - フロントエンド(JavaScript、Vue2系でSPA開発)、バックエンド(PHP7.3/Laravel5系)を主担当。 - 機能開発の見積もり、DB設計、UI設計、要件定義、テスト、リリースを担当。 - ユーザー画面と管理画面の機能開発、保守運用、顧客折衝を担当。 # 経験 - クライアントが非エンジニアだったため、顧客折衝では専門用語を避け、具体例や簡単なイラストを用いて機能や設計を説明。仕様の認識齟齬による手戻りを防ぎ、見積もりから設計・実装までスムーズに進められた。 - 既存コードの全面的な改善は工数的に難しかったため、改修はリスクの大きい箇所に絞り、機能のリリースを優先する体制で開発。納期を守って機能を市場に出し続けた。 - 例として7日間500円の限定キャンペーン機能のリリースを急ぎ、市場に出した。早期にユーザーを獲得し、キャンペーン経由で有料プランへ移行するユーザーも想定を上回った。売上は想定を20%以上上回り、サービスの利益に貢献した。

# 担当業務 - 与信審査システムを開発する9名規模のチームに業務委託として参画。 - フロントエンド(Vue 3系/Nuxt.js)とバックエンド(Express)を主に担当。 - 管理画面の機能開発・新規ページの追加・リファクタリングを担当。 # 経験 - データ操作は基本TypeORMに統一し、複数テーブルを結合する複雑な集計だけ生SQLで実装。ORMで無理に書くと可読性が落ちる箇所に線を引き、レビューのしやすさと性能を両立した。 - 仕様が口頭やチャットに分散し、実装時に認識齟齬が起きやすかったため、確定した仕様をNotionに集約する運用を整備。実装前に全員が同じページを参照する流れができ、仕様起因の手戻りを減らした。 - 冗長な重複コードが多く、変更のたびに複数箇所の修正が必要だったため、追加開発と並行して共通化のリファクタリングを実施。同じ修正を何箇所にも入れる作業がなくなり、変更時の影響範囲を限定した。

# 概要 個人、医療機関のオンライン診療医療システム開発 # チーム情報 ①チーム構成・規模 プロジェクトマネージャー：2名 プロジェクトリーダー: 1名 バックエンド：1名 フルスタックエンジニア：1名 フロントエンド：1名 QA: 3名 ②チーム内の自身の役割 フロントエンドメインで参画。主にフロントエンドの品質管理をメインで担当 新規機能の追加やバグ対応だけでなく、ライブラリアップデートやテストコードの導入を担当 また、バックエンドのソースコードも適宜読みながら対応しました。 # 担当業務 - 個人・医療機関のオンライン診療システムを開発する15名規模（うちエンジニア4名）のチームに業務委託として参画。 - フロントエンド（React、Next.js(page router)、apollo-client）を主担当とし、バックエンド（Ruby on Rails、GraphQL）も担当。 - 設定画面の機能開発と、管理画面の追加開発を並行して進行。 - 品質改善として、テストの自動化・保守性の向上・ライブラリのバージョンアップを担う。 # 経験 - UIに関わるテストをJestからStorybookのtest-runnerによるインタラクションテストへ移行。理由として実DOMに近い形で検証でき、後からビジュアルリグレッションテストへ拡張しやすいため。ロジックのユニットテストはJestに残した。 - Next.jsのルーティングに型を付けるためpathpidaを導入。URLやクエリのtypoによる実行時エラーを、実装時の型チェックで検出できるようにした。 - UI差分の自動チェックのためChromaticを導入。無料のreg-suit＋Storycapも検討したが、画像の保存に外部ストレージとの連携が必要で運用が重いため見送り。CLI実行だけでキャプチャから差分比較まで完結するChromaticを選定した。従量課金のため、スナップショットは差分が出たストーリーのみに絞って費用を抑えた。エンジニア以外でもUI差分を確認できるようになり、デグレ検知とQA確認の負担を減らした。 - E2EテストとしてPlaywrightを導入し、フォーム操作や認証などの重要な導線に絞って整備。GitHub Actionsと連携し、stg・本番環境はテストデータやコストへの影響を避けるため、workflow_dispatchによる手動実行とした。 - 複数のプロジェクトでTypeScript・Next.js・Chakra UIなど古くなっていたライブラリの大型アップデートを担当。事前に整えたChromaticの差分検知を使い、依存関係の制約を洗い出した上でReact、Next.jsの順に段階的にバージョンアップし、アップデートによる破壊的変更でUI崩れをPRの段階で検知できる状態で進めた。 - モノレポの3つのフロントエンドが個別にyarn installを実行しており、CIの消費時間が膨らんでいた。加えてyarn自体もv1系と古く、v2以降へのアップデートを試みたがNode.jsや依存ライブラリの制約で断念。そこで、依存パッケージを1箇所に保存して各プロジェクトから参照する仕組みを持つpnpmへ移行し、インストールをルートの1回に集約した。未宣言の依存を検出できる厳密さも評価して選定。その結果、GitHub ActionsのBillable timeを約40%削減した。

# 担当業務 ・企画〜要件定義（PRD作成）〜設計〜実装〜CI/CD〜運用まで全工程を1人で担当 ・React 19 / React Router v7（SPA）+ TanStack Query によるフロントエンド開発 ・Hono + Cloudflare Workers によるAPI開発、Drizzle ORM + Turso（libSQL）によるDB設計・マイグレーション運用 ・Spec-first OpenAPIによるAPI仕様駆動の開発フロー構築 ・Next.js / Prisma / Supabase 構成からの全面リプレイス（技術選定・移行の意思決定を含む） # 課題 初期はNext.js / Prisma / Supabase / Sentryの構成で開発していましたが、 ・フロントエンドとAPIの間で型定義を手書きで二重管理しており、API変更時に型の乖離やランタイムエラーが発生しやすい ・個人開発の規模に対してインフラ構成が重く、運用コスト・デプロイの複雑さが開発スピードを下げている ・画面が増えるにつれてコンポーネントの責務が曖昧になり、状態管理・表示・配置のコードが混在して保守しづらい といった課題があり、「実務と同じ水準の設計規律で、小さく速く運用できる構成」への移行が必要だと判断しました。 # 取り組んだこと、工夫したこと ・**フルスタックリプレイスの実施**：Next.js / Prisma / Supabase構成から、Vite + React SPA / Hono on Cloudflare Workers / Drizzle ORM + Turso構成へ段階的に移行。エッジで動く軽量APIと無料枠内で完結するインフラに刷新し、デプロイを`wrangler deploy`1コマンドに簡素化。 ・**Spec-first OpenAPIによる型の一元化**：API仕様を`openapi.yaml`に集約し、openapi-typescriptでフロントの型・APIクライアント（openapi-fetch）を自動生成。Redoclyによる仕様Lintと、CI上での型生成→typecheckにより、フロント・API間の型乖離をビルド時に検出できる仕組みを構築。 ・**依存方向を一方向に固定したアーキテクチャ設計**：`pages → components/pages → shared`、`server/routes → server/_logic → external`という依存ルールを定め、画面間の相互importとWeb/API間の相互参照を禁止。設計原則・コーディング規約をCLAUDE.md・docsに明文化し、AIエージェント（Claude Code）を使った開発でも設計が崩れないようにした。 ・**index / template / presenterパターンの採用**：画面ごとに状態管理（Container）・配置（template）・表示（presenter）を3ファイルに分離し、操作単位（list/create/update/delete）でhooks・API呼び出しを凝集。UIの見通しと変更容易性を確保。 ・**テスト・品質基盤**：Vitest + Testing Library + MSWでAPIモックを含むテストを整備。CIはlint（Prettier）/ typecheck（server・node・appの3プロジェクト別tsconfig）/ test / buildの4ジョブ構成にし、PRごとに全チェックを実行。 ・**認証設計**：Better Auth（Google OAuth）を導入し、WebはCookie・将来のモバイルはBearer Tokenという伝送方式の分離を前提にミドルウェアでセッション検証を実装。 # 成果 ・API変更起因の型不整合をCI（型自動生成→typecheck）で検出できるようになり、フロント・API間の仕様乖離によるランタイムエラーを未然に防げる構成になった。 ・Cloudflare Workers + Turso構成により、コールドスタート・サーバー管理なしでほぼ無料枠内の運用を実現。デプロイ・環境構築の手数が大幅に減り、機能開発に時間を集中できるようになった。 ・依存方向の固定とpresenterパターンにより、画面追加時の影響範囲が予測可能になり、AIエージェントに実装を任せても設計ルールから逸脱しないコードベースを維持できている。 ・設計判断（なぜHonoか、なぜSpec-firstか、なぜSPAか）をドキュメントに残し、技術選定の理由を説明できる状態で開発している。 # 他に対応したこと ・Drizzle Kitによるマイグレーション運用（ローカル/本番の環境別適用、`db:generate`→`db:migrate`のフロー整備、シードスクリプト作成） ・環境変数管理の設計（wrangler用`.dev.vars`とVite用`.env.local`の分離、`.env.example`による共有） ・dnd-kitによるドラッグ&ドロップ、Rechartsによる振り返りデータの可視化などリッチなUI実装 ・Swagger UI（@hono/swagger-ui）によるAPIドキュメントの自動配信 ・Prettier + organize-imports + Tailwindプラグインによるコード整形の自動化、cspellによるスペルチェック ・CLAUDE.mdにセキュリティルール（.envファイルの参照禁止等）を定義し、AIエージェント開発時の情報漏えいを防止