ID:82671さん

**① どんなサービス・システムか** - 企業が社員向けにコースやテスト・アンケートなどのコンテンツを作り、公開して受講してもらう人材育成SaaS（導入企業は約30社） - Cloud Run上で動くGoのAPI、React（TypeScript）のフロントエンド、AlloyDB（PostgreSQL）で構成。ファイル変換などはPub/Subを使った非同期処理で動かしている - 開発体制：エンジニア5名、PdM1名、QA1名 **② 何を担当したか** - バックエンドとフロントエンドの両方を担当し、不具合の調査・改修、機能開発（要件定義からリリースまで）、API設計を行った - 設問・選択肢のランダム化機能：API設計、バックエンドとフロントエンドの実装、リリース手順づくり - ランダム化機能に伴う本番DBマイグレーション：移行方針の決定、手順書の作成、本番での実施 - 集合研修機能：APIの設計と実装 **③ どんな技術を用いたか** - 言語：Go、TypeScript - フロントエンド：React、Vitest - データベース：PostgreSQL（AlloyDB）、sqldef - インフラ：GCP（Cloud Run、Cloud Run jobs、Pub/Sub、Eventarc、Cloud Storage） **④ どんな機能を開発したか** - 設問・選択肢のランダム化：テスト・アンケートの設問と選択肢の表示順をランダムにする設定を追加。コンテンツの作成・編集・取得と受講開始のV2 API、作成画面の設定項目、受講画面の表示ロジックを実装した - メンテナンス画面：メンテナンス中に表示する画面をデザインチームに提案し、実装した - 集合研修：研修削除APIと資料作成APIを設計・実装し、資料一覧取得APIも設計した - 不具合修正：在籍状況によってメンバーを検索できない不具合と、在籍状況の閲覧権限がないとコースを公開できない不具合を直した **⑤ どんな課題に取り組んだか** - 本番DBマイグレーションの安全性：ランダム化機能のために、不要になるカラムの削除を含むスキーマ変更が必要だった。ステージングで試すと、失敗時にバックアップから戻すのに約10分かかり、その間アプリを使えないと分かった - メンテナンス中の非同期処理：ファイル変換の完了通知（Pub/Sub）は、再試行が最大5回・合計約150秒で打ち切られる。デッドレター（届かなかったメッセージの退避先）も設定されておらず、メンテナンス中に届いた通知が捨てられるおそれがあった - 既存APIの変更：ランダム化の設定を扱うため、コンテンツの作成・編集・取得と受講開始のAPIを変える必要があった - テストの保守性：リポジトリ層のテストが、モンキーパッチ（gomonkey）に頼っていた **⑥ どんな工夫をしたか** - 作業時間をデータで決めた：DB負荷とリクエスト数の推移を見て、利用がほとんどない22時以降に設定。5時開始の案は、始業までに復旧する余裕がないため見送った - 切り戻しを前提に手順書を作った：バックアップの取得と復元、切り戻し時のデータ不整合、失敗時の戻し方、メンテナンスが延びた場合の対応、リハーサルに使う環境まで先に決めた - 影響を経路ごとに洗い出した：APIは特定のテナント以外に503を返してメンテナンス画面を表示し、定期実行ジョブはスケジューラを一時停止した。非同期処理は再試行の仕様を調べ、再試行回数の変更やデッドレターの導入など5つの対策案を検討した - レビューを論点ごとに分けた：手順書をまとめて見てもらうのではなく、切り戻し、データ不整合、システム制御などに分けて依頼し、他チームのレビューも受けた - APIはバージョンを分けて切り替えた：既存APIを直接変えずにV2として追加し、リリース手順、切り戻し手順、旧APIを削除するタイミングを決めた - PRを小さくした：APIの実装をhandler・usecase・repositoryの層ごとに別のPRにして、レビューしやすくした - テストの目的を絞った：ランダム化のロジックをdomain層に切り出し、「設定どおりにランダム化が効くか」だけを単体テストで確かめた。gomonkeyは3回に分けて外した **⑦ どんな成果を出したか** - 本番DBマイグレーションを手順どおりに実施し、問題なく完了させた - ランダム化機能のAPI設計（バージョンの分け方、コンテンツの取得・作成、受講開始）は、どれも大きな修正なくレビューを通った - 設計・仕様のレビューで2回以上の修正が必要になった割合が、2025年10月〜2026年1月は56%（57件中32件）だったのに対し、2〜3月は約7%（14件中1件）に下がった - 期間中にPRを83件マージした。そのうち小規模なPR 82件の平均リードタイムは0.79日（目標は2日、レビュー待ちなどの時間は含まない） - リポジトリ層のテストが、gomonkeyを使わずに動くようになった

**① どんなサービス・システムか** - 人材配置プロダクト：配置案のシミュレーションや発令表などを使って、部署やメンバーの配置を検討するためのSaaS（導入企業は20〜30社程度） - スキル管理プロダクト：メンバーのスキルを期ごとに回答・記録し、スキルマップで見える化するSaaS（導入企業は20〜30社程度） - GoのAPI、React（TypeScript）のフロントエンド、AlloyDB for PostgreSQLで構成。リリース前のAI提案機能は、LLMの処理をCloud TasksとCloud Runで非同期に実行する構成 - 開発体制：エンジニア3名、PdM1名、QA1名 **② 何を担当したか** - バックエンドとフロントエンドの両方を担当した。各機能で、仕様の具体化から設計、実装、QAとの連携、リリースまでを行った（5機能のうち3件は両方を実装） - AI提案機能：PRDの作成と要件定義、DB設計、非同期処理と排他制御の設計、API設計を担当した。既存プロダクトに非同期処理の仕組みを入れるための設計も行った - AI提案機能のPjM（2026年7月上旬〜8月）：仕様と依存関係の整理、関係者との調整、タスクとスケジュールの組み直しを行った - 社内エキスパートとの定例に参加し、開発中の機能の共有・相談やスコープの調整を行った - 機能開発と並行して、技術的負債の解消と開発基盤の改善を行った。技術的負債を扱う定例の立ち上げと運営、依存関係の更新PRの一次対応、不具合対応も担当した **③ どんな技術を用いたか** - 言語：Go、TypeScript - フロントエンド：React、Node.js、pnpm - データベース：PostgreSQL（AlloyDB for PostgreSQL）、sqldef - インフラ：GCP（Cloud Tasks、Cloud Run、Cloud Storage） - AI：LLM - 開発基盤：Renovate、Goのlint（gocritic、errcheck、staticcheck、gosec、tparallelなど） **④ どんな機能を開発したか** - 部署・メンバー変更差分のCSV出力（人材配置）：発令表で、部署とメンバーの変更差分をCSVで出力できるようにした。フロントエンドのCSV生成とUIを実装した - スキル値でのソート（スキル管理）：スキルマップをスキル値で並び替えられるようにした。既存API 1本の拡張とUIを実装した - スキル未回答者への通知（スキル管理）：スキルを回答していないメンバーに通知を送れるようにした。新規API 3本とUIを実装した - カテゴリ・スキル領域の平均値（スキル管理）：スキルマップで平均値を表示し、並び替えと絞り込みもできるようにした。既存API 3本の拡張とUIを実装した - 成長したスキルのハイライト（スキル管理）：メンバー詳細画面で、前の期から最も伸びたスキルを目立たせて表示するようにした。フロントエンドのロジックとUIを実装した - スキル領域・スキルレベルのAI提案（スキル管理、リリース前）：管理者が選んだメンバー（最大1,000人）とスキル領域（最大20件）について、人事データベースのメンバー情報をもとに、LLMがスキル領域・スキル・レベルを根拠付きで提案する。管理者は提案を採用するか却下するかを選べる。テーブル6つと新規API 10本（公開API 9本、内部のタスクハンドラ1本）を設計した **⑤ どんな課題に取り組んだか** - 短い期間での複数の機能開発：異動直後の約3か月で、2つのプロダクトにまたがる5機能を開発した。そのうち2件は既存APIを合わせて4本拡張するもので、今ある画面や仕様に影響を出さないようにする必要があった - 要件が決まっていない：AI提案機能はPRDが複数に分かれていて要件定義が進みにくかった。テーブル設計に必要な要件も決まっていなかった - 大量のデータ：AI提案機能は、最も多い場合に1テナントで年2億行（1回の実行で最大1,000万行）のデータが増える。将来、年200億行になっても構造を変えずに済む設計が必要だった。容量を試算すると1テナントで年約110GiBになり、50テナントが3年使うとストレージの上限（16TiB）に届く見込みだった - 非同期処理の失敗：LLMの処理をCloud Tasksで非同期に動かすため、次のことが起きても実行全体が終わらないまま残らないようにする必要があった - タスクの投入に失敗する - ワーカーが途中で止まる（at-most-once） - 同時に更新されて、完了の数を数えもらす - 同時実行：同じテナントで同時に実行されると、年間の実行回数の上限を超えるおそれがあった - 仕様と依存関係の未整理：AI提案機能の開発中、仕様や依存関係が整理されていないことが作業を止めていて、スケジュールに影響が出ていた - 技術的負債：スキル管理プロダクトにlintエラーが約40件残っていて、エラーハンドリングの書き方もそろっていなかった。Renovateの更新PRには、pnpm v11やsqldef v3などのメジャーアップデートも含まれていた **⑥ どんな工夫をしたか** - 影響範囲と既存のルールを先に確かめた：既存APIを拡張するときは影響範囲を細かく調べ、新規APIはプロダクトの既存の設計ルールに沿って設計した。テストの観点も、開発中にQAエンジニアとすり合わせた - PRDを引き取って文書にした：PdMの代わりにPRDの作成を引き取り、利用回数の制限や、休職者・退職者・削除済みアカウントの扱いなどを決めた。未決定事項も洗い出し、後から振り返れる形で残した - 将来の規模を基準にDBを設計した： - 提案結果は追記のみ（INSERT-only）にして、スキルごとに1行で持つ形にした - JSONBでまとめる案を含む5案を比べた。JSONBにしても容量は約17%しか減らないと試算し、この形に決めた - 画面からの参照は、メンバー単位のページ分けと必要な分だけの後読みで、1回のリクエストあたり最大500行に抑えた - 検索の使われ方に合わせて、一部はあえて正規化を崩した - 容量からデータの持ち方を決めた：容量の試算をもとに、3か月を超えたデータはCloud Storageに移してから削除する方針にした。削除方法も、分けて行うDELETEからパーティションごとのDROPへ段階的に移す計画を立てた - タスクの粒度と完了の判定を決めた： - 1メンバーを1タスクにして、次の4つを両立した - 1タスクを30分以内（dispatch deadline）に終わらせる - LLMに送るリクエスト量を調整する - 失敗した分だけをやり直す - 進み具合を表示する - 実行全体の状態は保存せず、メンバーごとの状態から表示するたびに計算する方式にした（4案を比較） - 失敗しても必ず終わる仕組みにした： - 投入に失敗しても、2時間たって終わっていない分は失敗として扱い、実行全体を必ず終了状態にした - 一括投入のbatchCreate APIは、正式版前で、一部だけ成功することがあると調べて使わなかった - 代わりに、同時に動かす数を制限したgoroutineでの並列投入と、待ち時間を少しずつ延ばして揺らぎも加えるリトライ（指数バックオフ＋ジッター）にした - 同時実行はテナントごとに1つずつ処理した：`pg_advisory_xact_lock`を使い、同じテナントの実行が重ならないようにした。テーブルロック、ロック専用の行、カウンター用のテーブル、部分ユニークインデックスなどと比べ、まだ行がない初回の実行でも排他できる点で選んだ - PjMとして論点とタスクを組み直した：論点を整理して関係者と調整し、タスクを組み直した。進み具合に合わせて、実装の順番やスケジュールも見直した - 改善の目的と範囲をチームでそろえた：技術的負債を扱う定例を立ち上げ、「なぜ改善するのか」「どこまで対応するのか」をチームで確認しながら進めた - 影響を調べてから対応した：Renovateの更新PR 12件（Go、Node.js 22、pnpm v11、sqldef v3など）は、影響の調査から修正まで行い、レビューできる状態にした。不具合が起きたときは、対象の機能、起きたこと、起きていた期間、顧客への影響をまとめて共有し、修正からリリースまで対応した **⑦ どんな成果を出したか** - 異動後の約3か月（2026年4月〜7月上旬）で5機能をリリースした。5件とも担当の交代やスケジュールの遅れはなかった - AI提案機能のADR 5本は、すべてテックリードのレビューを経て承認された。既存プロダクトに非同期処理の仕組みを入れるADRも、テックリードのレビューを通った - 新規API 10本の設計が、チームのレビューを経て確定した - AI機能の調査・設計資料のうち52%を作成した（チームで最多） - PRDを引き取ってからは、要件の手戻りなくプロジェクトが進んでいる - PjMとして作業を止めていた問題を解消し、当初の見込みより約2週間分の工数を減らした - 機能開発以外の改善PRを147件マージした（2026年4〜9月、チームで最多）。定例を続けた結果、ほかのメンバーからも改善PRが出るようになった - スキル管理プロダクトのlintエラー約40件をすべて解消した。人材配置プロダクトでも、gocritic・errcheck・staticcheck・gosec・tparallelなどの指摘を解消した - スキル管理プロダクトのエラーハンドリングを、スタックトレースを残す方式に統一した。設計方針は`ARCHITECTURE.md`にまとめ、AIがプロジェクトの設計やルールを理解するための情報としても使えるようにした