ID:62904さん

# プロジェクト概要 株式会社ジャパゲートシステムズと業務委託契約を結び、副業として記帳代行業務支援SaaS「記帳プロ」を0→1で開発しました。同社と顧客の税理士事務所が共同で立ち上げたサービスで、既存サービスSTREAMEDの競合という位置づけです。2025年12月に開発を開始し、2026年5月にリリースしました。ターゲットとした税理士事務所では、所員全員が既存の運用から移行して日常業務で使っています。 # チーム情報 開発は私一人です。税理士事務所と直接やり取りし、業務ヒアリング・要件整理、フロントエンド／バックエンドの設計・実装、DB設計、インフラ構築、リリース、運用開始後の改善までをすべて担当しました。 技術：Next.js（Server Actions）、TypeScript、Prisma、Supabase、Vercel、Gemini API # 開発・実装内容A：レシート画像のAI OCR・分類機能 【概要】 記帳代行では、レシートなどの証憑を見ながら人が仕訳を起こし、目視で確認する工程に時間がかかっていました。この入力・確認の負担を減らす機能です。 【どのような機能の開発・実装か】 レシート画像をGeminiでOCRし、記帳に必要な情報（日付、支払先、内容、勘定科目、税区分、インボイス登録番号など）を抽出・分類する機能を、私が設計・実装しました。 【課題・問題点】 LLMの判定は誤ることがあり、そのまま記帳に使うと誤った仕訳につながります。また、税務上の判断は一般的なOCRのプロンプトだけではカバーできませんでした。 【打ち手・使用した技術】 ・プロンプトは一般的なLLM OCRのベストプラクティスをもとに設計し、税務上気をつけるべき観点を税理士から聞き取って、判定の観点として組み込みました ・AIの結果を鵜呑みにさせないよう、確認が必要な箇所を出力画面にアラートで表示し、人の最終確認につなげる設計にしました # 開発・実装内容B：一人でもAIで品質を落とさない開発体制 【概要】 私が設計方針・実装の判断・レビュー・品質管理を担い、Claude CodeとCodexを実装支援に活用しています。 【課題・問題点】 一人で全領域を担当しながらAIによる生成コードも扱うため、人の目のレビューだけでは品質と設計の一貫性を保てません。 【打ち手・使用した技術】 ・npm scriptsにlint／typecheck／build／test／knip（未使用コード検出）をまとめ、AIが書いたコードも同じ基準で機械的に検証しています ・ファイルの置き場所などリポジトリの設計ルール違反を検知するカスタムESLintルールを自作し、人がレビューで指摘しなくても済む仕組みにしました ・E2Eテストを継続的に拡充しています ・設計やルールからのずれを洗い出して整理するClaude Codeのスキルを作り、週1回、範囲を絞って定期運用しています これらの仕組みで、一人体制のままリリースと、リリース後の改善要望への対応を続けられています。

# プロジェクト概要 リクルートの住まい領域に常駐し、引越し業者向けのトラック配車管理アプリを0→1で立ち上げました。引越し案件（カセット）をトラックと時間に割り当てて管理するアプリです。担当期間は2024年4月〜2024年9月です。 # チーム情報 私はフロントエンドの主担当です。常駐先でフロントエンドの実装方針の意思決定を任され、React Router、Zod、React Hook Formの導入と、画面・コード設計、実装を主導しました。API側との仕様調整、工数見積もり、企画・デザイナーとの調整も私が担当しました。API側の開発と企画・デザインは、各担当者と連携して進めました。 # 開発・実装内容A：DnDによる配車画面と、カセット編集フォームの連動 【どのような機能の開発・実装か】 月次・日次の管理画面で、カセットをドラッグ&ドロップでトラックと時間枠に配置する画面と、カセットの作成・編集フォーム（日付、住所、個人情報、引越しに関するほぼ全項目）、設定画面を開発しました。 【課題・問題点】 DnDでの配置とフォームでの編集が、同じデータを別々の操作で変更します。特に「同じ時間・同じトラックに重複して登録できない」という判定は、DnD側とフォーム側の両方で行う必要がありました。別々に実装すると、片方だけ仕様が変わって判定結果がずれるリスクがありました。 【打ち手・使用した技術】 Zodのスキーマと重複判定の関数を共通化し、判定を呼び出す場所だけをDnD側とフォーム側で分ける構成にしました。判定のロジックを1か所に保つことで、どちらから操作しても同じ結果になり、仕様変更時の修正も1か所で済むようにしました。 # 開発・実装内容B：複雑な入力フォームの設計 【課題・問題点】 配車管理は入力項目が多く、業務ルールも複雑です。画面が増えることを見据え、フォームの状態管理と入力チェックを一貫した形で扱う必要がありました。 【打ち手・使用した技術】 React Hook Formで入力状態を管理し、Zodでバリデーションのスキーマを一元管理する構成を、私が設計しました。業務ルールをスキーマとして整理することで、画面ごとに設計がばらつかず、追加開発にも対応しやすくしました。 # 開発・実装内容C：未確定の仕様を早期に整理する 【課題・問題点】 0→1開発のため、仕様が固まりきらないまま開発が進む場面がありました。 【打ち手】 フロントエンドだけでは判断できない業務仕様やAPI仕様を早い段階で企画・API側に共有し、確定させてから実装に進めることを徹底しました。設計の考え方は、ペアプログラミングとコードレビューを通じてチームに共有しました。

## プロジェクト概要 リクルート住まい領域に常駐し、マンション来訪者向けアンケートシステムの新規開発に参画しました（2020年10月〜2021年3月）。要件定義が済んだ段階から参加し、半年以内の開発期間で、決められた要件を品質を保ちながら実装する案件でした。 ## チーム内での役割・担当範囲 フロントエンドの設計・実装・テストを担当しました。要件定義そのものではなく、要件を画面の仕様に落とし込み、実装時に判明した不明点をチームと調整する役割です。 使用技術はThymeleaf、SCSS、TypeScript、Redux、webpack、Storybookです。 ## 取り組み：画面仕様の不明点を解消してから実装する ### 課題・背景 入社1年目で初めての新規開発でした。運用保守とは異なり、要件定義後も画面単位では未確定の仕様が残り、「誰がいつ決めるか」が曖昧になる場面がありました。期間が限られているため、不明点を残したまま実装すると、後から仕様の解釈が変わり、手戻りにつながることが課題でした。 ### 自分の判断・工夫 実装を進める前に、画面ごとに仕様の抜けや判断が必要な点を洗い出し、チーム内で確認して解消する進め方を取りました。実装後に修正するよりも、先に認識を合わせることを重視し、確認した仕様に沿ってフロントエンドの設計・実装・テストを進めました。 ### 成果 画面仕様の不明点を先に解消することで、実装の後戻りを減らしました。また、既存仕様に沿って対応する運用保守から、チームと方針を決めながら新規開発を推進する経験を積みました。この経験が、その後の0→1開発でフロントエンド主担当を担う土台になっています。