ID:42197さん

## 日雇いバイトマッチングアプリ新規開発（MAU数十万〜100万規模） **期間:** 2023年11月〜2024年11月 **規模:** 将来的に月間MAU数十万〜100万規模を見据えたBtoCアプリ。給与・応募・評価など複数ドメインを含む。 --- ### アーキテクチャ設計と品質担保 **課題** 初期フェーズでは、業務ロジックとインターフェース層が密結合しており、テスト容易性や保守性に課題があった。 **解決策・工夫点** - gRPCによるスキーマ駆動設計を採用 - Clean ArchitectureでUseCase層・Domain層を明確に分離 - インターフェース層はDI化してモック差し替え可能に - 実装と並行してユニットテスト作成 **成果** - 自身が実装したAPIはtest coverage 100%を達成 - プロジェクト全体でもcoverage 80%以上を維持 - ドメイン単位での改修・機能追加が容易になり、リリース前の修正工数を削減 --- ### 高トラフィック対応マイクロサービス構築 **課題** 外部サーバー連携APIが複数のサーバーで重複実装されており、更新時に修正箇所が多く、ピーク時の負荷対応も困難だった。 **解決策・工夫点** - AWS SQS + Lambdaによるマイクロサービス化 - 重複ロジックを一箇所に集約 - リクエストスパイク吸収のため非同期処理キューを導入 - 秒間7,000件規模の負荷を想定した設計 **成果** - 高負荷時でも安定稼働（タイムアウト率1%未満） - 外部API更新時の修正箇所を1/5以下に削減し、保守コストを低減 - 運用負荷のボトルネックを事前に解消 --- ### ログ基盤の構築と可観測性向上 **課題** 従来のログは解析しづらく、障害発生時の原因特定に時間がかかっていた。 **解決策・工夫点** - AWS Kinesis Firehose + New Relicによる構造化ログ基盤を構築 - trace_idやリクエスト/レスポンス情報を含むログ設計に刷新 - New Relic SDKでセグメント単位のトレースを埋め込み **成果** - 障害原因特定までの時間を1/3に短縮 - チーム全員が同じ手順で調査できる運用体制を確立 --- ### チームリードと開発プロセス改善 **課題** 開発初期はGit運用方針が統一されておらず、リリース体制も不明確。加えて、Go経験が浅いメンバーが多く、知識差があった。 **解決策・工夫点** - GitHub Flowからスプリント単位のリリースブランチ戦略に刷新 - 設計・コードレビュー、1on1による技術レビューを実施 - ペアプロや画面共有レビューを通じてGoのベストプラクティスを教育 - 心理的安全性を重視したチーム文化の醸成 **成果** - デプロイ作業の属人化を解消 - レビュー文化が定着し、バグ混入率を低下 - チーム全体の生産性を向上

## 独自ブロックチェーン通貨アプリ新規開発 **期間:** （記載期間があれば補足） **概要:** 独自ブロックチェーン通貨を新規発行し、支払・送金・精算が可能なBtoCアプリ。スマホアプリと管理画面双方に対応するAPI開発を担当。 --- ### API設計・実装とスキーマ駆動開発 **課題** 初期設計では、API仕様が曖昧で機能追加時の影響範囲が把握しづらく、ブロックチェーン通貨の発行・取引ロジックの整合性確保に懸念があった。 **解決策・工夫点** - ent / entoas を用いたスキーマ駆動開発を導入 - 通貨発行・鋳造・焼却などのブロックチェーンAPIを新規実装 - 支払いAPIなどコア機能の設計・実装を担当 - atlas によるマイグレーション機能を導入し、DBスキーマ管理を自動化 **成果** - API仕様を明文化し、フロントエンド・バックエンド間の認識齟齬を解消 - ブロックチェーン取引ロジックの改修時にも影響範囲を迅速に特定可能に - 機能追加のリードタイムを短縮 --- ### 認証・ファイル管理基盤の構築 **課題** ユーザー認証やファイル管理の設計が未整備で、セキュリティと拡張性の確保が課題だった。 **解決策・工夫点** - AWS Cognitoによるユーザー管理を設計・実装 - S3によるファイルアップロード機能を実装し、セキュアなアクセス権限管理を設計 **成果** - 認証基盤のセキュリティ向上とスケーラビリティ確保 - ファイルアップロード機能の安定稼働により、管理画面からのコンテンツ更新が容易に --- ### アーキテクチャ改善と保守性向上 **課題** 開発途中でリポジトリが肥大化し、責務分離が不十分なため保守性が低下していた。 **解決策・工夫点** - DDD（ドメイン駆動設計）をベースとしたレイヤードアーキテクチャを導入 - ドメイン層・アプリケーション層・インフラ層を分離し、依存方向を明確化 **成果** - コードの見通しが改善し、新規機能追加や改修時の影響範囲を最小化 - レビュー効率の向上と開発速度の安定化

## 有機野菜認定機関向け業務アプリ開発 **概要:** 有機食品JAS規格に基づく認証業務を行う機関の社内DX化プロジェクト。 帳票作成、検査員スケジュール管理、広報資料送付先管理など、複数の業務をオンライン化するアプリを新規開発。 **役割:** プロジェクトマネージャー / フロントエンドエンジニア / バックエンドエンジニア --- ### 業務効率化とコスト削減 **課題** - エクセルや紙による二重チェック業務が非効率 - 顧客増加による業務負荷の拡大が予想 - 事務員追加による固定費増より、アプリ導入の方が費用対効果が高いと判断 **解決策・工夫点** - 要件定義・仕様策定から設計・開発・デザインまで一貫して担当 - 帳票作成、検査員スケジュール管理、広報資料送付先管理の各機能をREST API + Next.jsで実装 - Cloud Run + Firebase(Auth)を利用し、セキュアかつスケーラブルな構成を構築 - Userテーブルを中心に、農家・検査員・広報資料送付先など複数ロールを外部キーで管理する設計を採用（兼任状況を一元把握可能に） **成果** - 業務フローの完全オンライン化により、書類作成・確認にかかる時間を大幅削減 - 事務員増員を回避し、固定費増加を抑制 - 顧客増加時も追加リソースなしで業務継続可能な体制を構築 --- ### UI/UX改善と保守性向上 **課題** 従来のReact Atomic Designではディレクトリ構成の切り分けが難しく、保守性や可読性に課題があった。 **解決策・工夫点** - `bulletproof-react` をNext.jsに導入し、ベストプラクティスに沿ったディレクトリ構成を採用 - 長期的な保守・拡張を前提にコンポーネント設計を刷新 **成果** - 開発初期段階で構造を最適化し、後続機能追加の工数を削減 - 新規メンバー参加時のキャッチアップ時間を短縮 --- ### 検査員スケジュール管理機能の改善 **課題** ドラッグ&ドロップUIが必要だったが、主流ライブラリ`react-beautiful-dnd`はメンテナンス停止状態であり、将来的な保守性に懸念があった。 **解決策・工夫点** - `react-dnd`を採用し、検査員ボードのドラッグ&ドロップ機能を実装 - `useState`でドロップ先を検知し、即時サーバー更新する仕様を構築 **成果** - 操作性の高いスケジュール管理UIを実現 - 将来的なライブラリメンテナンスリスクを回避 --- ### 帳票作成機能のパフォーマンス改善 **課題** `react-pdf`によるリアルタイムプレビューは1文字入力ごとにPDF再レンダリングが発生し、パフォーマンスが低下していた。 **解決策・工夫点** - 入力遅延（debounce）を導入し、一定時間入力が止まった後に再レンダリングする仕様に変更 **成果** - 入力体験を損なわずにPDF生成処理を軽量化 - プレビュー画面の応答速度が改善

## 賃貸見積書作成システム開発 **概要:** 賃貸アパートやマンション退去時に発生する原状回復費用（壁やフローリングの傷の補修など）の見積書・請求書を作成・管理するWebアプリを開発。 ハウスクリーニング会社からの依頼で、見積書の作成・管理業務を効率化するシステムを新規構築。 **役割:** バックエンドエンジニア / フロントエンドエンジニア --- ### 業務効率化と見積管理の一元化 **課題** - 紙や既存のエクセル管理では見積書作成や検索に時間がかかり、作業の属人化も発生 - 修繕項目や費用の管理が一元化されておらず、再利用性が低い **解決策・工夫点** - 壁やフローリングなどの補修内容と費用を入力し、PDFで見積書を生成する機能を実装 - 見積書一覧の表示・確認・編集・削除機能を実装し、各管理会社が保有する見積を一元管理 - 見積もり項目と単価を登録・更新できるマスタ管理機能を追加 **成果** - 見積書作成から送付までのリードタイムを短縮 - 過去見積の再利用率向上による作業時間削減 - 誰でも同じ手順で見積を作成できる運用フローを確立 --- ### アーキテクチャ改善と保守性向上 **課題** 初期構成ではロジックやデータアクセスが密結合しており、仕様変更や機能追加時の影響範囲が広かった。 **解決策・工夫点** - Go + gin によるAPIサーバーをDDD（レイヤードアーキテクチャ）で設計 - ent ORMを採用し、atlasによるバージョン管理型マイグレーションを導入 - OpenAPI(Swagger) + RedocでAPI仕様を自動生成し、フロントエンドとの認識齟齬を防止 **成果** - ドメイン層の独立により、ビジネスロジック変更時の改修工数を削減 - DBスキーマ変更時の影響範囲を可視化し、開発速度を維持 - API仕様の自動更新でフロントとバックの連携ミスを防止

## 男性型脱毛症（AGA）オンライン診療アプリ開発（MAU5万人規模） **役割:** シニアソフトウェアエンジニア / 開発リード --- ### 開発体制の再構築と品質向上 **課題** - プロジェクト単位での開発体制により、責務が不明確でレビューが属人化 - コード全体の構造把握が難しく、品質担保に課題があった **解決策・工夫点** - 開発体制をサブドメインチーム制へ移行し、責務を明確化 - リポジトリ全体を解析・整理し、ドメインごとにレビュアーを割り当て - GitHub CODEOWNERSを活用した自動レビューフローを構築 **成果** - 属人化を解消し、コードレビュー品質とスピードを両立 - ドメイン単位での開発進行が可能になり、改修影響範囲の特定が容易に --- ### RDRA導入と要件定義プロセス改善 **課題** - 要件定義の記載粒度や責任範囲が曖昧で、関係者間の認識齟齬が発生 - 要件→設計→テストの接続性が弱く、変更管理が困難 **解決策・工夫点** - RDRA（要件駆動型の要件定義手法）を導入し、粒度ルールと責任範囲を策定 - BUC（業務ユースケース）単位でのQase + Playwright活用を試行 - ObsidianでRDRAを構造管理し、Claude Codeによるソース解析とQase API連携でBUC→UC→テストケースの自動生成・更新を実現 **成果** - 要件定義の品質と一貫性を向上 - 設計・テストとの接続性が強化され、変更対応の手戻りを削減 - 属人化されていた業務知識の可視化を実現し、ドメインモデリングへ展開可能な状態に --- ### テスト自動化と可観測性向上 **課題** - テストケースの作成・更新が手作業で、変更追従に時間がかかっていた - 業務ロジックや依存関係が不透明で、品質保証が難しかった **解決策・工夫点** - Qase API連携によるテストケースの自動生成・更新フローを構築 - Claude Codeによる依存関係解析を行い、情報・状態・ビジネスロジックの関係を明確化 **成果** - テストケース更新作業の工数を大幅削減 - ロジック依存関係の可視化により、障害原因調査や仕様変更対応が迅速化