はじめに
こんにちは、井古田です。 広告サービスの開発部署でPdMをメインでやっています。
今回は、PdMになった初期のころに導入したリリーストレインについてご紹介します。
実際にプロダクト開発のなかでリリーストレインをどのように運用しているのかをまとめてみました。
リリーストレイン導入の背景と目的
私たちの部署では主軸となる3つのプロダクトの開発・運用を行っています。
リリーストレインを導入する以前では、以下のような問題がありました。
- 各プロダクトの戦略・方向性が中・長期で把握しづらい
- 次に開発する案件の優先度が決まっていない
- 追加機能の開発や運用の対応などで優先度が変更し、リリース日が延長される
これらの問題を解決するために、プロダクト戦略のロードマップ的な役割と、リリース時期を固定させ、MVP（実用最小限の製品： minimum viable product）での開発意識を持ってもらうためにリリーストレインを導入することにしました。
リリーストレインを導入することで、プロダクト戦略や開発内容の透明化をはかり、各チームの繁忙期を把握しながらバランスの良い運用・保守タスクの調整を行い、安定したプロダクトでの価値提供を考えています。
リリーストレインと運用フローについて
↑リリーストレインのサンプル図
リリーストレインの管理はmiroを採用しています。
スケジュールに直接コメントやメモを残したり、時系列などの表現がとても容易で便利です。
私たちの部署では、四半期または半期でファーカスする領域を決め、それぞれでリリーストレインを作成しています。
フォーカスする領域は、「新規開発」・「管理画面リニューアル」・「クラウド移行」などがあります。
スクラム開発を導入しており、リリーストレインの期間の粒度はスプリントに合わせてスケジュールを引いています。
1スプリントの期間が1週間であれば、スケジュールも週単位になります。
次に運用フローをご紹介します。
計画を立てる
四半期または半期のタイミングでPdMとビジネスサイドで事業戦略をもとに、プロダクト戦略を考えます。
この段階では機能についてはあまり深く考えず、プロダクトでどんな価値をいつ提供すべきかを考えます（課題や改善したい指標などが明確になっているとスムーズに進みます）。
MVPを考える
価値を提供するために必要なMVP（実用最小限の製品： minimum viable product）を考えます。
私たちの部署ではMVPキャンバスを利用して、ビジネスサイド、PdM、開発チームの認識を揃え、開発の目的や価値を明確にし、無駄な開発を無くすようにしています。
作成したMVPキャンバスをもとに、MVPの開発であることと、おおよそのリリース目処をステークホルダー全員で認識を合わせるように心がけています。
MVPキャンバスはConfluenceで管理し、リンクをリリーストレインに紐づけることで、各チームのリリース内容を把握出来るようにしています。
MVPキャンバスについての詳細は、まっちゃんの記事を参考にしてください。
プロダクトバックログで管理する
私たちの部署では、プロダクトバックログの管理にJIRAを採用しています。
MVPキャンバスは、JIRAのエピックで管理し、必要なストーリーやタスクを洗い出しリリースプランニングを行います。
リリースプランニング後、見積もりを行いリリーストレインを更新します。
↑エピックとストーリーの関係性
オーバーオールリファインメント
定期的に各チームのPdMが集まり、リリーストレインの更新、バックログのリファインを行います。
リリーストレインの進捗や変更内容の確認し、運用・保守などのタスクを、各チームの状況を考慮しながらどのチームで対応するかを決定しています。
おわりに
今回リリーストレインを導入したことで、以下のような効果がありました。
- 中・長期的に案件が明確になり、プロダクトの戦略や方針について話し合う機会が増えた
- リリーストレインの期限に間に合わせるために、MVPでの開発を徹底する意識がついた
- 各PdM間での運用・保守タスクの調整がしやすくなり、バランスよく分散して対応できるようになった
思いの外開発チームから好評で嬉しかったです！
まだまだリリーストレインや運用の部分で改善が出来そうなので、さらに良くしていければと思います。
