実際にユーザーに届くものを決めるのは誰か
パイプラインは動いている。テストはすべてパスしている。ビルドはグリーン。デプロイボタンが目の前で待っている。しかし、誰もそれを押さない。
なぜか？ それは、この特定のバージョンを本当にユーザーに届けるべきかどうかを誰かが判断する必要があるからだ。その判断は技術的なものではない。プロダクトと調整に関する判断だ。そして、その判断が明確に行われなければ、パイプラインは空回りするだけになる。
この判断を担うのが、プロダクトマネージャーとリリースマネージャーの2つの役割だ。彼らは同一人物ではなく、同じ仕事をするわけでもない。しかし、この2人が協力することで、CI/CDシステムだけでは答えられない「これを今リリースすべきか？」という問いに答える。
プロダクトマネージャーは「何を」作るかを決める
プロダクトマネージャーはコードを書いたりパイプラインを実行したりはしない。彼らの仕事は、ユーザーとビジネスが実際に何を必要としているかを理解し、それをエンジニアリングチームの作業に変換することだ。CI/CDの文脈では、この役割はコードが1行も書かれる前から重要になる。
プロダクトマネージャーは、どの機能を次のスプリントに入れるか、どれを延期するか、どれを完全に落とすかを決める。その決定は、デリバリーがどれだけスムーズに進むかに直接影響する。
もしプロダクトマネージャーが大きすぎる機能を優先すると、エンジニアリングチームは圧倒され、リリースは遅れる。優先順位が頻繁に変わると、開発者は中途半端な作業を捨てることになる。優れたプロダクトマネージャーは、優先順位付けが単に「何が最も重要か」だけではないことを理解している。「現実的な期間内に実際に完了してリリースできるか」も同様に重要だ。
ここがプロダクトマネージャーとCI/CDシステムの相互作用のポイントだ。チームが常に間違ったものに取り組んでいるのであれば、高速なパイプラインも役に立たない。プロダクトマネージャーの仕事は、パイプラインに、適切に定義され、正しくスコープされ、ユーザーのニーズに合致した作業が投入されるようにすることだ。
リリースマネージャーは「いつ」出すかを調整する
リリースマネージャーは、リリースが実際にいつ、どのように行われるかを調整する人物だ。これは専任の役割であることもあれば、DevOpsエンジニアやテックリードが交代で務めることもある。機能としては同じで、バージョンを本番環境にリリースする前に、全員の準備が整っていることを確認する。
リリースマネージャーは具体的に何を調整するのか？
まず、リリーススケジュールだ。チームは毎週木曜日の午後2時のように固定スケジュールを使うのか？ それとも機能が完成するたびにリリースするのか？ どちらのアプローチも機能するが、リリースマネージャーは全員が現在どの方式で動いているかを把握しているようにする。
次に、技術的な準備状況だ。すべての変更がメインブランチにマージされているか？ すべてのテストがグリーンか？ データベースマイグレーションはステージングで実行済みか？ これらのチェックは基本的なものに聞こえるが、誰かがやってくれているだろうと皆が思い込んで、しばしばスキップされる。
3つ目は、コミュニケーションだ。サポートチームは変更が来ることを知っているか？ 新機能にアナウンスが必要な場合、マーケティングは準備できているか？ コードが完璧でも、他のチームを驚かせるようなリリースは混乱を引き起こす。
リリースマネージャーは、ゴー／ノーゴーの判断も主導する。これは、全員が集まり（多くの場合、短いチャットや簡単なミーティングで）、リリースを進めるか延期するかを決める瞬間だ。重大なバグが発見されたばかりなら、リリースマネージャーは「待った」をかける。すべてが安全に見えれば、リリースマネージャーはゴーサインを出す。
これら2つの役割がエンジニアリングチームとどう連携するか
プロダクトマネージャーとリリースマネージャーは孤立して動いているわけではない。彼らは常にエンジニアリングチームとやり取りする。
プロダクトマネージャーは開発者と話し、機能にどれだけの労力が必要かを理解する。非技術者には簡単そうに聞こえる機能でも、数週間の作業が必要になることがある。プロダクトマネージャーは、現実的な優先順位を決めるためにそのインプットを必要とする。
リリースマネージャーはQAと話し、テストが十分かどうかを確認する。DevOpsと話し、インフラが新しいバージョンに対応できる状態かを確認する。プロダクトマネージャーと話し、ある機能の遅延がリリース計画全体に影響するかどうかを確認する。
成熟したチームでは、フィーチャーフラグのようなプラクティスによって、この連携はよりスムーズになる。フィーチャーフラグを使えば、プロダクトマネージャーはリリーススケジュールを待たずに、どの機能をどのユーザーに対して有効にするかを制御できる。リリースマネージャーも、コードがまだ有効化されていなくても本番環境にデプロイされているため、プレッシャーが少なくなる。
しかし、フィーチャーフラグは魔法ではない。それでも調整は必要だ。フラグがクリーンアップされずに溜まると、技術負債になる。プロダクトマネージャーとリリースマネージャーは、どのフラグが存在し、どれが有効で、どれを削除できるかを追跡する必要がある。
これらの役割はゲートキーパーではない
プロダクトマネージャーとリリースマネージャーを障害と見なすのは簡単だ。開発者はリリースしたがっている。パイプラインの準備はできている。なぜ誰かの承認を待たなければならないのか？
しかし、これらの役割は無駄な作業を防ぐために存在する。開発者が何日もコーディングした後で、その機能がユーザーの実際のニーズに合っていないことが判明する状況を想像してほしい。あるいは、チームがデプロイの準備はできているが、マーケティングがアナウンスの準備をしていない状況を想像してほしい。どちらの状況も労力を無駄にし、フラストレーションを生む。
プロダクトマネージャーは、チームが正しいものを作るようにすることで前者のシナリオを防ぐ。リリースマネージャーは、組織が新しいバージョンを受け入れる準備ができていることを確認することで後者のシナリオを防ぐ。
プロダクトマネージャーとリリースマネージャーのための実践的チェックリスト
もしあなたがこれらの役割を担うことになった場合、あるいはこれらの役割の人と一緒に仕事をする場合、デリバリーをスムーズに保つための短いチェックリストを以下に示す。
- スプリント計画の前: 機能が適切に定義され、現実的にスコープされていることを確認する。大きすぎる場合は、分割する。
- コードを書く前: 開発者と工数見積もりについて話し合う。簡単そうに聞こえるからといって、機能が小さいと決めつけない。
- マージの前: すべての変更がレビューされ、テストされていることを確認する。「後で直す」を常態化させない。
- リリース日の前: サポート、マーケティング、その他のチームがリリースが行われることを認識していることを確認する。サプライズは混乱を招く。
- ゴー／ノーゴーの前: テスト結果、マイグレーションのステータス、既知の問題を確認する。不明な点があれば、延期する。
- リリース後: どのフィーチャーフラグがまだ有効かを追跡する。次のリリースサイクルの前にクリーンアップする。
まとめ
間違った機能が作られていたり、組織がそれを受け入れる準備ができていなければ、高速なパイプラインも無意味だ。プロダクトマネージャーとリリースマネージャーは、あなたの速度を落とすためにいるのではない。彼らは、あなたがボタンを押したときに、それが実際に意味を持つようにするためにいるのだ。