ID:81197さん

# 1. 予約管理システムの機能改善・新規開発（Rails + Vue + AWS） 医療クリニック向け予約管理システムにて、仕様整理〜実装〜検証までフルスタックで担当。 仕様が散在しておりバグが多い状態から、API設計・UI改善・外部API統合まで幅広く改善を行った。 ## チーム情報 - PM兼エンジニア1名 - エンジニア2名 - 小規模体制で要件整理〜実装までの自走が求められる環境 --- ## Swagger（OpenAPI）導入（自身が主導） ### 概要 API 仕様が複数のドキュメントに分散し、メンバー間で認識齟齬が多発していた。 ### どのような機能の開発・実装か - 既存APIを統合し、Swagger UI で参照可能な API ドキュメントを構築 - 新規API追加を OpenAPI 形式で標準化する仕組みを構築 ### 課題 - 仕様確認に毎回時間がかかる - 担当者によってレスポンス理解が異なる - 新規 API を追加するたびに確認漏れが発生 ### 打ち手 - Swagger(OpenAPI) の導入を自ら提案・主導 - 既存 API の棚卸し・仕様統合 - レスポンス形式・エラー仕様・型定義の標準化 - OpenAPI準拠で新規APIを追加できる運用フローを構築 ### 成果 - 仕様確認時間が 従来比 1/3 程度 に短縮 - 認識齟齬が大幅減少し、開発の手戻りが減少 - 追加開発のスピードと品質が向上 ### 使用技術 Swagger / OpenAPI / Rails / YAML / GitHub --- ## 既存予約ロジックの改善（Rails） ### 概要 複雑化した予約ロジックを整理し、拡張性と保守性を改善。 ### どのような機能の開発・実装か - 予約作成・更新・取消・一覧検索など、予約領域の主要 API を改善 - バリデーション強化、DB制約追加、レスポンス統一などを包括的に実施 ### 課題 - ロジックが肥大化し影響範囲が不明確 - 外部サービスとの整合性問題 - DB制約・バリデーションが不十分 - N+1 の発生でパフォーマンス低下 ### 打ち手 - 仕様の棚卸し、差分の表形式整理 - バリデーション追加・DB制約見直し - ActiveModel::Serializer でレスポンス設計を統一化 - 予約関連API 8つ以上の改修を単独担当 - N+1 を解消しクエリを最適化 ### 成果 - コードの可読性改善により、レビュー工数が削減 - 新機能追加時の影響範囲が明確になり、開発スピード向上 - バグ再発率が減少し、安定した運用に貢献 ### 使用技術 Rails / MySQL / ActiveRecord / ActiveModel::Serializer / YARD --- ## 外部予約サービス連携（API & Webhook 統合） ### 概要 外部予約サービスと自社予約ロジックを統合。 ### どのような機能の開発・実装か - Webhook受信APIの新規実装 - 外部API → 自社ロジックへのデータ反映フロー構築 - 二重更新防止処理と再試行ロジックの実装 ### 課題 - 外部APIのレスポンス形式が自社と異なる - Webhook通知と通常APIが二重更新になり整合性が崩れやすい - 異常時の再試行設計が欠如 ### 打ち手 - Webhook受信APIを新規実装 - イベント種別ごとの更新処理・再試行設計 - JSONパース・データ整形・DB反映まで一貫して担当 - ログ発火式のリトライ方針を設計 - 自社ロジックへの統合を実現し運用を安定化 ### 成果 - 二重更新の不整合が解消し、予約データの安定性が向上 - 外部API連携のコードが整理され、他メンバーも理解しやすい構造に改善 ### 使用技術 Rails / JSON / MySQL / Webhook --- ## フリースペース予約（バックエンド専任） ### 概要 医療現場の新しい運用形態に合わせ、 通常予約とは別仕様の “フリースペース予約” を追加。 ### どのような機能の開発・実装か - フリースペース専用の予約作成・編集・キャンセル API を実装 - 通常予約との共通部＆差分を吸収するロジックを構築 - UI 仕様の差異を踏まえたバックエンド処理を新設 ### 課題 - 部屋指定なし／繰り返し予約なし／在庫管理なし - 既存ロジックの分岐が増え、破綻しやすい構造 - UI/UXにも差分が必要 ### 打ち手 - booking API を拡張し、通常予約との差分を吸収するロジック設計 - 編集・キャンセル処理の統合 - DBバリデーション調整 - フロントとの仕様すり合わせを主導 ### 成果 - 通常予約ロジックとの整合性を維持したまま新仕様の導入に成功 - 要件理解の速さにより、フロント担当メンバーより「進行が円滑になった」とフィードバック ### 使用技術 Rails / MySQL / ActiveRecord --- ## 手動タグカテゴリ管理（Rails + Vue） ### 概要 タグ配信機能のためのカテゴリ管理を新規開発。 ### どのような機能の開発・実装か - カテゴリ管理画面の新規追加（Vue） - カテゴリ・タグの CRUD API の新規実装（Rails） - カテゴリ × タグの中間テーブルを用いた紐づけ機能 ### 課題 - 仕様が固まっておらず、要件整理が必要 - カテゴリとタグの関連が複雑 - フロント・バック両方の改修が必要 ### 打ち手 - モデル設計、API設計、CRUD実装 - カテゴリ×タグの紐づけロジック - フロント側の画面追加・UI修正 - 検索フィルタの実装 ### 成果 - 仕様未整理の状態からゼロイチでリリースまで主導 - バック・フロント両面の対応により、実装の抜け漏れゼロで完遂 ### 使用技術 Rails / Vue 3 / TypeScript / Vuex / Composition API --- ## AWS環境移管（CloudFormation / IaC） ### 概要 既存システムを新 AWS 環境に移行するタスクにて、インフラ構築を主担当。 ### どのような機能の開発・実装か - VPC・EC2・RDS など基盤構成の IaC 化 - RDS/S3/ALB/Route53 の環境移行 - 構成図ドキュメントの整備 ### 課題 - 既存構成が手動構築でブラックボックス化 - SG・IAM 権限が複雑でリスクが高い - 新環境構築が毎回手作業で非効率 ### 打ち手 - CloudFormation で VPC / サブネット / EC2 / ALB / RDS を IaC 化 - Mappings を用いて dev/prod 切替可能なテンプレートを作成 - SG・IAM ポリシーを最小権限に整理し安全性向上 - draw.ioによる構成図を作成し、チーム共有 - RDS：mysqldump → 新環境RDSへインポート - S3：全オブジェクトをダウンロード→再アップロード - ACM 証明書／ALB／Route53 の再設定と疎通テスト - CloudWatch ログ/メトリクス設計の再整理 ### 成果 - 予定より約2週間（半月）前倒しで移行完了 - 手動構築の環境をすべてIaC化し、再現性を確立 - インフラ担当から「構成把握が容易」「ドキュメントが非常にわかりやすい」と評価 - 今後の新環境構築の工数を大幅削減 - ドキュメント整備により、属人化していたインフラ構成を可視化 ### 使用技術 CloudFormation / VPC / Subnet / EC2 / RDS / S3 / ECS / ALB / IAM / CloudWatch / Route53 / ACM / draw.io / MySQL --- ## その他（抜粋） ※実装タスクが多岐に渡ったため、特に難易度が高かったもののみ深掘りしています。 - バッチ予約 API の改修 - バリデーション・DB制約の調整 - バグ調査（ログ解析／再現手順作成／修正） --- # 2. チームワーク・推進力（3名チーム） 小規模チーム（PM兼エンジニア1名+ エンジニア2名）で、仕様整理・調整・バグ調査を自走的に担当し、プロジェクト推進に貢献 ### 具体的な貢献 - PM・他エンジニアと連携し、仕様のすり合わせを円滑に進める役割を担った - バグ発生時には、再現調査〜原因特定を主体的に行い、修正方針をチームと共有 - Rails / Vue / AWS の横断スキルでボトルネックを解消 ### チームに与えた影響 - 手戻りの少ない安定した実装を継続的に提供 - 仕様の曖昧さを自ら整理し、開発の進行をスムーズにすることに貢献 - 小規模チーム内で、任せたタスクを着実に完遂する「自律したエンジニア」として信頼を獲得

# AI 駆動でのフロントエンド開発（Next.js / TypeScript） 大規模業務システム（Next.js + TypeScript）にて、 Cursor を活用した AI 駆動開発によるバグ修正・UI挙動改善を担当。 ## チーム情報 - フロントエンド中心のチーム - 自身は フロント専任で改善タスクを担当 - 既存コードベースが非常に大きく、調査力と読み解き力が求められる環境 --- ## UI挙動の調査・改善（Next.js / React Hooks） ### 概要 ユーザー操作時の UI 挙動が不安定・期待と異なる動きをする部分を中心に改善。 ### どのような機能の開発・実装か - 画面操作後に意図しない再レンダリングが発生する不具合を修正 - フォーム動作やボタン挙動のズレを調査し、Hooks の依存関係を整理 - コンポーネントの状態管理ロジックの見直し ### 課題 - 依存配列の誤りや不要な状態保持が原因で UI が乱れていた - コンポーネントの責務が曖昧で、問題箇所を特定するのに時間がかかる - 再現性が低く、初期調査の難易度が高い箇所が多い ### 打ち手 - Next.js App Router のレンダリングモデルを踏まえ、問題箇所を特定 - useEffect / useCallback / useMemo の依存関係を整理 - 状態管理ロジックを簡素化（過剰な state を削減） - Cursor（AI）を活用して候補コードを比較しつつ、挙動検証で最終判断 ### 成果 - UI のブレが解消し、操作体験が向上 - Hooks の設計が整理されたことで、同画面の後続開発が容易に - 「挙動調査のスピードが速い」とチームから評価 --- ## 小規模リファクタリング（可読性向上） ### 概要 大規模プロジェクトゆえに可読性の低いコードが散見され、保守負荷が高かったため改善を実施。 ### どのような機能の開発・実装か - 冗長なコンポーネントを分割 - 同様の処理が複数箇所に重複していたため共通化 - 過剰な props 渡しを削減し、責務を明確化 ### 課題 - 読み解きに時間がかかり、バグ調査の初動速度が低下 - コンポーネントの肥大化によりエッジケースが埋もれやすい - メンバーによって書き方がバラバラで統一性がない ### 打ち手 - Cursorのコード差分生成を活用し、改善前/後の挙動を比較 - 小さく段階的なリファクタリングにより影響範囲をコントロール - 依存関係や責務を見直してロジックを整理 ### 成果 - コンポーネント単位の見通しが改善され、後続の UI 修正が容易に - メンバーから「コードが読みやすくなった」とフィードバック - 大規模コードベースの扱いに慣れ、調査力が向上 --- ## 総合成果 - Next.js/React のレンダリング理解が深まり、UI挙動の安定化に貢献 - AI を効率よく活用しつつ、人が判断すべき箇所を見極めるスキルを獲得 - 「調査 → 分析 → 修正」の一連のフローを独力で回すスキルが強化