WORKS
人材配置SaaSの開発PM — 品質ゲートの制度化とオフショア週次運営
引き継いだSaaSプロダクトの開発を、品質を落とさず回し続ける。個人の頑張りではなく「制度」で品質を守る開発体制を作った事例です。
SUMMARY 概要
| 業界 | HRサービス業 |
|---|---|
| 規模感 | 事業会社のプロダクト部門 |
| 課題領域 | SaaSプロダクト開発・品質管理 |
| 支援範囲 | PRD作成、技術レビュー、受入テスト（UAT）設計、リリース可否判定、オフショア開発チームの週次スプリント運営 |
| 期間・体制 | 開発PM受託・継続中 |
ISSUE 課題
このSaaSは、エンネクト株式会社の代表が企画段階から最も深く知る立場にあるプロダクトです。同社に引き継がれてからも、機能開発と保守を続けていく必要がありました。しかし開発の実働はオフショアチームが担っており、要件の質、実装の質、リリース判断の質を誰がどう担保するのかが定まっていませんでした。
APPROACH 支援内容
プロダクトを企画からリリースまで立ち上げた当事者として、エンネクトが開発PMを受託しました。場当たりのチェックではなく、開発の各段階に「通過条件」を置く品質ゲートを制度として設計しています。
- フェーズ1: 品質ゲートの設計 — 要件定義（PRD作成）→ 技術レビュー → 受入テスト（UAT）設計 → リリース可否判定、という4つの関門を開発プロセスに組み込みました。各関門で何を確認し、何をもって通過とするかを定義しています。
- フェーズ2: 週次スプリント運営 — オフショア開発チームと週次のスプリントを運営し、要件の受け渡し・進捗・品質の確認を毎週同じリズムで回す体制にしました。
- フェーズ3: 制度としての運用 — 個別案件ごとにPRDを作成し、技術レビューとUATを経てリリース可否を判定する運用を継続しています。
OUTCOME 成果
品質ゲートが「制度」として回る状態になりました。誰かの記憶や気付きに頼らず、どの開発案件も同じ関門を通ってリリースされます。要件はPRDとして、検証はUATとして文書に残るため、判断の根拠を後からたどることもできます。開発拠点が海外にあっても、品質の議論を成果物ベースで行える体制です。
POINT 支援のポイント
この事例の型は、品質を「人」ではなく「関門」で守ることです。PRD・技術レビュー・UAT・リリース判定という関門の設計は、自社開発のプロダクトに限らず使えます。外部から導入する製品の受け入れ品質を管理する場面でも、確認の観点と通過条件をあらかじめ決めておく同じ型が機能します。開発体制の内外を問わず転用できる、開発品質管理の基本形だと考えています。