ID:78952さん

# プロジェクト概要 * WebサービスのバックエンドAPI（FastAPIベース）において、表示項目の制御やレスポンスの仕様変更、テスト自動化など、ユーザー体験に直結する改修・改善業務を担当しました。 # チーム情報 * チーム構成：リードエンジニア1名、自分1名（2名体制） * 自分の役割：API改修・表示制御ロジック実装補助、テストスクリプト作成、技術ドキュメント整備 # 担当業務A：表示項目の制御ロジックの実装 【目的・背景】 * 元々、すべての会員に一律の情報を返していたAPIに対し、会員レベルに応じて表示項目を切り替える要件が発生。ユーザーの体験価値を高めつつ、会員レベルの差別化を図る狙いがありました。 【取り組み内容】 * ユーザーのトークンから会員レベルを判定し、APIレスポンスで返す項目を条件分岐。 * 特定の会員レベルには非公開となる項目（例：詳細な銘柄分析情報）を除外して返却。 * 複数のエンドポイントで共通する判定ロジックを関数化し、再利用性と保守性を向上。 【思考プロセス】 * 「既存APIを改修する影響範囲の見極め」が重要と考え、リードと相談しながら設計。 * ロジックを条件分岐に分離し、将来的に会員ランクの種類が増えても対応可能なように設計。 * UI/UX観点で不自然な欠損表示にならないよう、レスポンス構造の整合性に注意。 【成果】 * 会員属性に応じたレスポンス制御を実装し、サービスの有料プランの価値を明確に伝えられるように。 * 条件分岐ロジックの実装を通して、FastAPIにおけるミドルウェア・依存性注入の理解も深まった。 # 担当業務B：API動作確認用テストスクリプトの作成 【目的・背景】 * 手動でのAPIテストは確認漏れや非効率さが課題。特に、複数の会員レベルでのレスポンス確認が必要なため、自動化が求められました。 【取り組み内容】 * curl コマンドを利用した .sh スクリプトを作成し、登録・取得・削除といった基本的なAPI操作を一括テスト可能に。 * 各スクリプトには、トークンを切り替えて無料・有料会員の動作確認ができるように工夫。 * レスポンスを jq で整形出力し、視認性の高いテストログを取得可能に。 【思考プロセス】 * 確認作業が属人的・手作業である点がボトルネックと感じ、「テストスクリプトにより再現性とスピードを担保する」という方針を立てた。 * レビュー前後でも同じ条件下で確認できるようにし、開発フローの一貫性を意識。 【成果】 * テスト作業の効率化により、実装からレビューまでの所要時間を削減。 * チームメンバーによる確認も容易になり、認識齟齬を防止できた。 # このプロジェクトで得た知見・スキル * FastAPI におけるレスポンス制御、依存関係の注入、リクエストバリデーション * 要件を抽象化して拡張性あるロジックを実装する技術設計力 * 実装者・レビュー者両方の目線を意識したテスト設計

# 担当業務 * 既存のWebサイト（以下：サイトA）に対し、サービス終了が決定した別サービスのWebサイト（以下：サイトB）の機能・情報ページを統合するプロジェクトに参加しました。 * 新人エンジニアとして、主にAPI実装の補助、既存データ調査、テストスクリプトの作成などを担当しました。 # チーム情報 * チーム構成：エンジニア2名（リードエンジニア1名＋自分） * 開発体制：Gitによるコード管理、タスクはBacklogで管理 * 自分の役割：既存システムの仕様調査、データ取得、FastAPIを用いたAPI実装の補助、テストスクリプトの作成など # 開発・実装内容①：サイトBの機能・画面構成調査 【概要】 * サイトBの終了に伴い、必要な機能・情報をサイトAに統合する必要があり、その移行対象の洗い出しを担当しました。 【開発・実装の内容】 * サービス終了に伴って削除されるサイトBの機能や情報ページを、サイトA側で再現するため、対象となる画面や項目を確認。調査結果をもとにAPI定義書を作成しました。 【課題・問題点とその判断】 * 仕様書や設計書がほとんど残っておらず、画面とコードを突き合わせて仕様を把握する必要がありました。 * 一部の画面では、複数のAPIやDBテーブルにまたがってデータが取得されていたため、情報の関連性を理解するのに時間と注意が必要でした。 【打ち手と選定理由】 * 画面遷移を手動で操作し、各ページで表示される項目を洗い出し → 仕様の抜け漏れを防ぐため。 * 該当ソースコードを読み、どのエンドポイント・DBテーブルからデータが取得されているかを整理し、調査表としてドキュメント化 → 調査結果をチーム内で再利用可能な形にするため。 * 可能な範囲で過去のAPIレスポンスも確認し、旧サービスと同等のデータを取得できるよう配慮しました。 【成果】 * API定義書をもとにスムーズな実装に繋がり、統合作業を円滑に進める基盤を構築 * 自分自身もシステム全体像を把握することで、後続作業（API実装・テスト）でも精度の高い作業が可能になりました # 開発・実装内容②：FastAPIによるAPI実装補助 【概要】 * サイトBで提供していた情報を、サイトA側にて再現するための新規API実装をFastAPIで担当しました。 【開発・実装の内容】 * サイトBで提供されていたデータ項目を再現するAPIを作成 * フロントエンドとの連携を前提に、レスポンス構造の整合性と保守性を意識した設計 【課題・問題点とその判断】 * 複数のAPIを一から実装する必要があり、レスポンス構造を忠実に再現しながら、将来的な保守も見据えた設計が求められました。 * 旧APIにはエラー時の挙動やレスポンス形式にばらつきがあり、新APIでの統一仕様をどう設計するかが課題となりました。 【打ち手と選定理由】 * Python製のFastAPIを選択し、Pydanticモデルでリクエスト／レスポンスの型を明確化 → 型安全性の担保と、開発者同士での認識ズレを減らすため。 * API単体の動作確認は、curlやhttpxを使って実施 → 軽量かつ再現性の高い検証が可能 * エラー時のレスポンス統一（例：404/400などのフォーマット）を設計段階で決定し、保守性を意識 【成果】 * ユーザーにとって違和感なくサイトBの機能をサイトA上で利用可能にし、UXの継続性を担保 * 将来的な機能追加や修正にも対応しやすい構造にできたことで、チーム内レビューでも評価を得ました 開発・実装内容③：テストスクリプト（Shell/Python）の作成 【概要】 * 新規APIの品質担保と確認作業の効率化を目的に、手動確認に代わるスクリプトを作成しました。 【開発・実装の内容】 * 各APIのステータスコード・レスポンスを自動で確認するためのスクリプトを作成 * 初学者でも扱いやすく、拡張性のある構成を意識 【課題・問題点とその判断】 * 都度curlで確認する作業は手間がかかり、ヒューマンエラーも起きやすかった * テスト対象のAPIが増えることで確認漏れのリスクも上昇 → 簡易的な自動化が必要と判断 【打ち手と選定理由】 * 基本的な動作確認には.sh スクリプト＋curlを使用し、実行の簡便性を優先 * 複雑なレスポンス検証（例：JSON値の一致・エラーケースの再現）にはPython＋httpxを使用 → Pythonの例外処理・構文の柔軟性により、異常系も網羅的に確認できるようにしました 【成果】 * テストスクリプトにより、API実装直後の動作確認が従来の半分以下の時間で完了 * チームメンバーとの連携やレビュー時にもスクリプトを共有でき、作業効率と品質を両立 学んだこと・意識したこと * 単に手元の実装を進めるだけでなく、「どのようなデータがどこから来て、どう使われるか」を全体視点で捉える重要性を学びました * FastAPIとPydanticの仕組みを通じて、型安全な設計や非同期処理の構築にも触れることができました * テストや保守も見据えた実装・検証手法を工夫することで、チーム内での信頼向上にも繋がりました * このプロジェクトを通して、仕様調査〜API実装〜テストと幅広く携わる中で、「再現性ある調査」「保守性を意識した設計」「自動化による品質担保」といった点を意識しながら業務を進めました。今後もより大規模な開発にも対応できるよう、技術だけでなく設計やコミュニケーション力も高めていきたいと考えています。

# プロジェクト概要 * 画像生成AIの出力結果（画像と関連情報）を記録・参照・削除できるAPIをFastAPI + MySQLを用いて構築。 * シンプルかつ拡張しやすい設計を意識し、個人で開発・テスト・運用まで一貫して担当。 # チーム情報 * 個人開発（設計・実装・テスト・運用を全て一人で担当） # 目的 * 画像生成AIで生成されたデータが個人のローカル環境やメモ帳などに分散していたため、情報の検索・再利用に手間がかかっていた。これを解消するため、画像と関連情報を一元的に管理できるREST APIを設計・実装。 # 開発・実装内容 A：情報管理APIの開発 【概要】 * 画像生成AIで作成した画像と、その生成に使用した各種情報（モデル名、プロンプトなど）を効率よく記録・参照・削除できるREST APIを開発し、情報管理の一元化を実現。 【課題認識と背景】 * 大量の画像を生成していく中で、どの画像がどのプロンプト・モデルによって生成されたのかを後から確認できない状態が続いていた。情報は一時的にローカルファイルやメモアプリに記録していたが、検索性が悪く、モデル・プロンプトの再利用にも支障があった。 【取り組み内容と思考プロセス】 * 画像生成のたびに記録される情報の種類を精査し、「画像URL」「使用モデル」「プロンプト」「ネガティブプロンプト」に絞ることで、管理すべき情報量と入力負荷のバランスをとった。 * 「IDを手動入力する煩雑さ」がミスの原因になると考え、SQLAlchemyによる自動インクリメント機能を用いてIDを自動採番。 * 情報の登録・閲覧・削除は最低限必要な操作であり、UIなしでもコマンドベースで扱えるREST APIとして設計。 【工夫点】 * 各エンドポイントに対し、バリデーションやエラーハンドリングを実装して堅牢性を確保。 * ユーザーが手動でIDを意識しなくて済むよう、APIのインターフェースは簡素で直感的な構造にした。 【成果】 * 再利用性・検索性を高めるには、情報の粒度と構造が重要であると実感。 * 開発初期段階からスケーラビリティを意識することで、後の拡張や保守にも強い構成ができた。 * 学習コストやスピード感を考慮してFastAPIを選定し、技術選定時のトレードオフにも配慮する姿勢が身についた。 開発・実装内容 B：テスト自動化スクリプトの整備 【概要】 * APIの信頼性と保守性を高めるため、curlコマンドによる.sh スクリプトを作成。 【課題認識と背景】 * APIの実装後に毎回手動で動作確認を行うのは手間がかかり、特に細かい仕様変更時にミスが生じやすかった。 【取り組み内容と思考プロセス】 * 開発サイクルの中で、仕様変更やデータ構造の微調整が頻繁に発生。 * 手動テストは非効率と判断し、自動でAPIリクエストとレスポンスの検証ができる.sh スクリプトを作成。 【工夫点】 * curl によるAPI呼び出しスクリプト（POST、GET、DELETE） * bashスクリプトの中で複数のリクエストを順に実行し、標準出力・標準エラーを分離して記録 【成果】 * 再利用性・検索性を高めるには、情報の粒度と構造が重要であると実感。 * 開発初期段階からスケーラビリティを意識することで、後の拡張や保守にも強い構成ができた。 * 学習コストやスピード感を考慮してFastAPIを選定し、技術選定時のトレードオフにも配慮する姿勢が身についた。 * テスト工程の自動化により、変更後の動作確認が高速化し、開発スピードが向上。 * 実装・テスト・デバッグのループを短くできることで、開発全体の保守性と安定性が向上。