ID:76250さん

**期間**：2024年1月 〜 2025年6月 **役割**：単独担当（要件定義・インフラ構築・実装・テスト・リリース） **チーム規模**：4名以下（本件は実質1名で完遂） ### プロジェクト概要 社内で耐用年数に達したサーバ5台のリプレイスを、**要件定義から本番リリースまで単独で担当**しました。既存サーバの構成は文書化されておらず、どの部署・システムが依存しているかも把握されていない状態からのスタートでした。 ### 課題と開発内容 このプロジェクトの本質的な難しさは技術ではなく、**「見えていない依存関係を1つ見落とすだけで本番障害になる」**という構造にありました。具体的には次のリスクがありました。 - ステークホルダーの把握漏れ・連絡漏れ → 気づかないうちに他システムを停止させる - インストール済みパッケージの入れ忘れ → 移行後に特定機能だけが動かない - 障害発生時に原因が特定できない → 復旧が長引く そこで、作業手順を作る前に**リスクを潰す仕組みそのものを設計**することから始めました。 **(1) 既存サーバの完全な棚卸し** インストールされているパッケージを全台分すべて洗い出し、一覧化しました。「たぶん入っている」を排除するためです。 **(2) 全工程のチェックリスト化** 構成確認・ステークホルダー特定・サーバ準備・パッケージインストール・テスト・リリースの各工程にチェックリストを作成し、抜け漏れが構造的に起きない状態にしました。 **(3) ログの全量保持と手順書への紐付け** 万が一事故が起きた際に原因を即座に特定できるよう、サーバのログを全て残し、手順書に貼り付けて管理しました。 **(4) 変更差分の図示による承認プロセスの整備** 責任者からリリース承認を得る際、「何をどう変更したか」が一目で理解できる図を作成しました。承認者が内容を理解しないまま承認する状態を避けるためです。 **(5) 単体・結合・総合テストの徹底** 移行対象の全機能について3段階のテストを実施しました。 ### 工夫した点 **指示されたのは「サーバの入れ替え」でしたが、実際に必要だったのは「事故を起こさないプロセスの設計」だと判断し、そこから作りました。** チェックリスト・全ログ保持・変更差分の図示は、いずれも誰かに指示されたものではなく、想定されるリスクから逆算して自分で用意したものです。 また、リプレイス作業の中で構成を棚卸しした結果、**実際には使われていないサーバを発見し、削除を提案・実行**しました。移行対象を減らすことは自分の作業リスクを下げることにも直結しました。 ### 使用技術 - **言語**：Java - **フレームワーク**：Struts、Spring Boot - **DB**：Oracle - **OS**：Linux、macOS ### 成果 - **サーバ5台すべてを事故ゼロで移行完了**（本番障害・切り戻し・計画外停止はいずれも発生せず） - 不要サーバの特定・削除により**インフラコストを削減** - 属人化していたサーバ構成情報を、パッケージ一覧・手順書・チェックリストとして**文書化して残した**

*期間**：2023年4月 〜 2023年12月 **役割**：開発メンバー（実装・レビュー・テスト） **チーム規模**：11〜20名 ### プロジェクト概要 顧客情報の閲覧・更新を行う社内向けツール（一部社外向け機能あり）のリプレイスです。旧フレームワークのStrutsから**Spring Bootへの移行**、それに伴うJavaのバージョンアップ、およびデザイン変更を担当しました。新卒入社直後に配属された最初のプロジェクトです。 ### 課題と開発内容 最大の課題は**移行前のコードにドキュメントがなく、仕様が読み取れないこと**でした。動いているコードだけが唯一の仕様書という状態で、それを新フレームワークの作法に沿って書き直す必要がありました。 **(1) 既存コードの解読と再実装** Strutsで書かれた既存処理を読み解き、Spring Bootの構成に沿った形で書き直しました。 **(2) 企画職からの改修依頼への並行対応** 移行作業と同時に、企画職から上がってくるツールの改修依頼にも対応しました。 **(3) カバレッジを意識したテスト実装** 移行によるデグレを防ぐため、カバレッジ率を意識してテストを実装しました。 ### 工夫した点 **既存コードの理解にAIを活用しました。** 2023年当時としては早い段階から、レガシーコードの解読にAIを使い、読解の速度と正確性を上げる進め方を取り入れています。この経験が、後に処理経路をフロー図化するツールを自作する動機になりました。 もう一点は**企画職とのコミュニケーション設計**です。MTGで処理内容を説明する際、口頭では前提の共有だけで時間が終わってしまうため、**処理をすべてフロー化して持ち込み、短時間で理解を得てから本題に入る**進め方に変えました。 ### 使用技術 - **言語**：Java - **フレームワーク**：Struts → Spring Boot - **DB**：Oracle - **OS**：Linux、macOS ### 成果 - Struts から Spring Boot への移行を完了、あわせて Java のバージョンアップとデザイン変更を実施

**期間**：2025年8月 〜 現在 **役割**：開発メンバー（API内部の詳細設計・実装・テスト） **チーム規模**：5〜10名 ### プロジェクト概要 BtoCアプリ内で発生する決済処理について、新規機能の開発を担当しています。大枠のアーキテクチャは既に決定済みの状態から入り、**各APIの内部設計を自分で詰めて実装まで持っていく役割**です。想定トラフィックは100rps以上。 ### 課題と開発内容 決済領域は1件の不整合がそのまま金銭的損失と顧客対応コストに直結するため、「**落ちないこと**」と「**落ちたときに追えること**」の両立が前提要件でした。担当したのは主に3点です。 **(1) 顧客情報を決済フローに取り込むバッチ処理の実装** 外部から連携される顧客情報を決済処理側で参照可能な形に取り込むバッチを実装しました。 **(2) メッセージキュー（MQ）による非同期処理の実装** 決済処理本体と、ステークホルダーへの通知処理を疎結合にするためMQを整備しました。外部システムの遅延や障害が決済本体に波及しない構成にすることが目的です。 **(3) 決済完了後の永続化とステークホルダーAPI連携の設計・実装・テスト** 決済が成立した後に取引情報を永続化し、ステークホルダーのAPIを呼び出す一連の処理を、設計から結合試験まで担当しました。 ### 工夫した点 **外部APIの可用性は自分たちで保証できない**という前提に立ち、MQを挟んで「決済本体の成否」と「通知処理の成否」を切り離しました。通知側が失敗しても決済が巻き戻ることのない設計です。 もう一点は認識の揃え方です。結合試験で発生した不具合の調査時、処理経路が複雑で口頭説明では関係者の理解が揃わないという問題がありました。そこで**コードの処理経路をフロー図として自動的に可視化するツールを自主的に開発**し（詳細は「業務外・自主的な取り組み」に記載）、チーム内の共通言語として使っています。現在はチームメンバーが機能仕様を説明する場面でも使われています。 ### 使用技術 - **言語**：Java - **フレームワーク**：Spring Boot - **DB**：Oracle - **ミドルウェア**：メッセージキュー - **OS**：Linux、macOS - **その他**：AIコーディングツール（Claude Code）を実装・レビューに活用 ### 現状 現在は結合試験フェーズで、試験中に発生した決済処理ロジックの不具合の調査・修正を担当しています。

**期間**：2025年12月 〜 現在（業務委託） **役割**：プロジェクトマネージャー兼ソフトウェアエンジニア **チーム規模**：4名以下 ### プロジェクト概要 LINEミニアプリとして提供する求人マッチングサービスの開発です。**エンジニアとして参画し、現在はPM兼SEとして案件全体を担当**しています。依頼元とのMTG、機能追加の提案、工数の管理、そして実装までを一貫して担っています。リリース済みで、現在**1,000人以上のユーザー**に利用されています。 ### 課題と開発内容 **(1) 求人レコメンド機能の設計・実装** このサービスの中核機能です。ユーザーと求人のマッチ度をどう定義するかが設計課題でした。求職者にとって「通える距離か」と「自分の条件に合うか」の両方が重要である一方、単純な条件フィルタでは候補が絞られすぎるという問題がありました。 そこで**重み付きスコアリングによるランキング方式**を設計しました。ユーザーと求人の地理的な距離、およびユーザーの登録情報と求人情報の各項目のマッピングに対してそれぞれ重みを設定し、その合計スコアの高い順に表示する仕組みです。フィルタで候補を切り捨てるのではなく、スコアの序列で提示することで、条件が完全一致しない求人も候補として残ります。 **(2) DB設計と基幹機能の実装** 求人・会員を扱うスキーマを設計し、CRUD機能を実装しました。 **(3) PMとしての案件推進** 依頼元とのMTGに出席し、要望をヒアリングして機能追加を提案、工数を見積もってスケジュールを管理しています。 ### 工夫した点 **非エンジニアである依頼元と、技術的な意思決定の間を翻訳することを自分の役割の中心に置いています。** 依頼元から渡されるのはデザインや要望であり、そこから必要な技術・データソースを判断して実装に落とす部分が空白になっていました。ここを埋めることでPMまで任されるようになりました。 また本業のフルタイム勤務と並行して本案件を担当しており、**限られた稼働時間で成果を出すために、工数見積もりと優先順位付けを自分で行う必要がありました。** ### 使用技術 - **言語**：TypeScript - **フレームワーク**：Next.js - **ORM**：Prisma - **DB**：PostgreSQL（NeonDB） - **インフラ**：Vercel - **プラットフォーム**：LINEミニアプリ（LIFF） > 注：本件は開発途中から参画したため、**技術選定そのものには関与していません**。面接で選定理由を問われる可能性があるため、レジュメ上も「選定した」とは書いていません。 ### 成果 - **リリース済み・1,000人以上のユーザーが利用** - エンジニアとして参画後、**PM兼SEとして案件全体の担当を任される**役割拡大