ID:60615さん

精算管理SaaSの開発チーム（エンジニア6名）における、コードレビュー体制とPRレビューのアサインフロー、および新規参画メンバーのオンボーディングプロセス。役職としてのマネージャーではなく、チームメンバーの立場から課題を発見し、仕組みとして設計・導入する形で関与した。

特定メンバーへのレビュー依頼の集中とアサイン漏れによるPR滞留をなくし、レビュー品質を落とさずにチーム全体のスループットを維持・向上させること。また、レビュー内容を個々の指摘で終わらせず、チームの技術判断基準として定着させること。加えて、新規参画メンバーが属人化した暗黙知に頼らず、自力で開発に着手できる状態まで早期に立ち上げること。誰かに割り当てられた役割ではなく、チームの生産性上のボトルネックとして自ら課題を見つけ、責任を持って解決まで担うという立場で取り組んだ。

## 背景 正式なマネジメント役職には就いていないが、チーム6名の開発の中で、レビューとオンボーディングの 運用に非効率が積み重なっていることに気づき、自発的に課題として扱った。 ## 1. PRレビューアサインの仕組み化（2026年3月） ### 問題 PRのレビュワーアサインが手動で行われており、特定メンバーへのレビュー依頼の集中と、アサイン漏れに よるPR滞留が発生していた。1件ごとの遅延は小さいが、積み重なるとチーム全体のスループットに影響 すると判断し、自ら改善に着手した。 ### 考え方・工夫 「誰が見るか」を人の裁量に任せている限り偏りは解消しないと考え、仕組みで解決する方針にした。 GitHub Actionsでレビュワー自動アサインの機構を設計し、PRのラベル（backend / frontend）で 候補者プールを分離した上で、現在のレビュー依頼数が最も少ないメンバーを自動選択するロジックを 実装した。同数の場合はランダム選択とし、負荷の偏りをさらに抑制する設計にした。 導入にあたっては、いきなり全チームに強制するのではなく、既存の運用を壊さない形で段階的に切り替え、 違和感があれば都度チームにヒアリングして調整した。 ### 結果 PRオープンからレビュー開始までの時間が平均22.4時間から9.4時間まで短縮した（約58%削減、 Findyで計測）。アサイン漏れによるPR滞留もゼロになり、レビュー負荷がチーム6名に均等に分散された。 ## 2. コードレビューを「個別指摘」から「チームの仕組み」に変換（2025年11月〜2026年5月） ### 問題 レビュワーとして日常的にPRレビューを担当する中で、同種の問題（設計上の考慮漏れなど）が 形を変えて繰り返し発生することに気づいた。都度指摘して直すだけでは、レビュワーの注意力に 依存した運用になり、根本的な再発防止にならないと考えた。 ### 考え方・工夫 マルチテナント環境における権限制御の設計不足をレビューで検知した際、その場の修正だけで 終わらせず、「なぜこの設計が必要か」を言語化し、GitHub Copilotのカスタム指示（instruction） にルールとして組み込んだ。これにより、以後の実装段階でAIコーディングツール側から同種の 考慮漏れに気づける状態を作り、レビュワーの個人的な注意力に依存しない予防機構にした。 他のレビューでも、パフォーマンス設計（N+1回避）や例外処理、テスト観点について、指摘に 留めず「設計意図」として伝えることを意識し、個別の指摘がチームの技術判断基準として 定着するよう心がけた。 ### 結果 本番リリース前に権限制御の不備を検知・修正し、リスクを未然に防止した。また、レビュー観点を 仕組み化したことで、同種の実装がPR段階で発生しにくい状態を作ることができた。 ## 3. 新規参画メンバーのオンボーディング設計（2025年11月〜） ### 問題 新規メンバーを受け入れる際、環境構築の手順が暗黙知化しており、立ち上がりが個人の経験や 質問のしやすさに左右され、属人的になっていた。 ### 考え方・工夫 「聞けばわかる」状態を「見ればわかる」状態に変えることを目指し、環境構築の各手順をIssue化 して着手順序と完了条件を明文化した。また、詰まりを早期に拾えるよう1on1の導線を設計し、 新規メンバーが自分から声を上げにくい状況でもフォローできる体制を整えた。 ### 結果 新規参画メンバー2名の受け入れに活用し、いずれも環境構築フェーズでの詰まりなく開発着手まで 到達できた。「聞けばわかる」から「見ればわかる」への転換が、属人化していた立ち上がりプロセスの 標準化につながった。 ## 今後について 正式なマネジメント役職の経験はまだないが、上記の取り組みを通じて、チームの生産性のボトルネックを 構造的に見つけて解消することにやりがいを感じている。今後はより裁量を持って、開発プロセスや チームの生産性設計そのものに関与していきたいと考えている。