toBプロダクトにおけるプロダクトマネジメント
RENIの中田です。
今日は、弊社が実践しているプロダクト開発の仕組みを具体的に紹介します。
Product Managerが担っている「プロダクト開発が健全に進むための仕組み作り」については、意外と言語化、体系化されて共有されているものは少ないと感じています。
以前複業で携わっていたスタートアップ複数社においてもこの仕組みを整えることを求められていたため、一定のニーズがあるのでは?と思いnoteを書くことにしました。
世のProduct ManagerやSoftware Engineerにとって何かしら参考になれば幸いですし、「こんなやり方もあるよ!」といったフィードバックも遠慮なくコメントください!
RENIは何を作ってるの?
前提として、RENI社はアーティストマーチャンダイジングをDXしている企業です。今回はRENIのプロダクトの中でも「MD Cloud」というマーチャンダイズの基幹業務をデジタルスクラッチするプロダクトでの開発プロセスについて紹介します。
※RENIの事業をより深く知りたい方はこちらのnoteを先にご覧ください。
RENIの開発プロセス
では、本題です。弊社のプロダクト開発サイクルをざっくりとフロー化するとこんな感じです↓
できるだけ具体的な内容にした方がイメージしやすいと思うので、利用しているツールも記載しています。
世に出回っているノウハウは1 -> 4にかけて充実していくので、本noteでは逆に前工程のボリュームを多く取ります。
1. Issueの特定
最も重要であり、かつ、最も体系化されていないSTEPだと思います。
Issueの出所は2つです。
①自社内部(= 戦略)から
②顧客の声から
弊社はドキュメントシステムとしてNotionを活用していますが、それぞれを記載するNotion上のページを明確にしています。
①に関しては、「Documents」ページにドキュメントを作成し、提案や検討事項として整理します。そして、正式にプロジェクトとして発足した場合は「Product Roadmap」に新規プロジェクトとして作成することで、時間軸を意識できるようにします。
ちなみに、Documentsページは事業(= プロダクトに限らず)に関するあらゆるドキュメントを作成する場所であり、ドキュメントを作成する場所を限定することで書くことへのハードルを下げる意図があります。
NotionのProduct Roadmapにプロジェクトを作成したら、当該プロジェクトの詳細を記載します。そのテンプレートが以下です。
Issueの分解基準ですが、解決して顧客に価値を提供できる最小限の粒度にすることを1つの基準にしています。
②に関しては、「Issue Analysis」という顧客の要望管理のページに記録し分析します。
Requestが異なっても根本的なWhyが共通であれば、1つのIssueで複数のRequestに応えることが可能となりますし、このように要望を抽象化してより本質的でインパクトの大きいIssueを導き出すことを意識しています。
結果として、顧客の要望トリガーでプロジェクトの発足に繋がることもありますし、粒度の小さいIssueであれば直接Story化のSTEPに進むケースもあります。
ちなみに、1については以下のnoteでさらに詳しく書いてもいるので、お時間ある方はぜひこちらも参照ください。
2. Story化
弊社ではAjile Project Managementツールとして「Pivotal Tracker」を利用しており、Storyは当該ツール上で作成し優先順位の管理を行っています。
Issueをブレイクダウンすることにより、必然的にStoryに落とし込まれます。
StoryはIceboxに起票します。Icebox上ではリリースチケットを活用することでプロジェクト単位、あるいはIssue単位でまとめています。
週次で行うBacklog Refinementにおいて、Iceboxの中から直近の1ヶ月程度で取り組みたい優先度の高いプロジェクトやIssueに紐づくStoryをBacklogに移動させます。
Storyを切ること自体は1のフェーズでIssueが明確に特定できていれば難しいことではありません。ただし、内容については弊社ではStoryのテンプレートを準備しており、Story化へ取り組むハードルを下げると同時に品質がぶれないことを意識しています。
Storyのテンプレート
3. デザインスプリント
デザインスプリントを回すための仕組みとして、弊社では
①Design Sprint Planning
②Design Sprint Review
の2つの会議体を週次で設けています。
その名の通り、Planningでは次のSprintで取り組むスコープとその要求内容の共有、すり合わせをPdMとデザイナーで行います。
ReviewではそのSprintで取り組んだアウトプットのレビューを行います。
ちなみにデザインツールは「Framer」を利用しています。Framerをご存知ではない方は以下のnoteをご覧ください。
デザインスプリントを開発スプリントの前に明示的に設けている理由は、実装前にプロダクトの不確実性を低減させるためです。
弊社が開発している「MD Cloud」というプロダクトは、クライアント企業のコア業務を担うこともあり複雑で細かい要求にも対応している関係上、プロトタイプの段階でユーザからフィードバックをもらうことのメリットが大きいです。
私自身がPdMであり、かつ週に2日クライアントでありパートナーでもある企業のオフィスに出社して、ユーザの業務を肌感で理解していることもあり、その環境の恩恵を最大限享受するためにもプロトタイプを頻繁にユーザに見せています。
4. 開発スプリント
開発スプリントにおいてもデザインスプリントと同様に
①Sprint Planning
②Sprint Review
の2つの会議体を週次で設ける仕組みにしています。
既存機能の改善をメインに行なっているタイミングではSprintを1週間として、PlanningのMTGでCurrent IterationのスコープとなるStoryチケットを決め、ReviewのMTGで結果を振り返ります。
Storyにはポイントを付与し、予め決めているSprintでの消化ポイントを目標にスコープを決め、実績を振り返るという一般的なサイクルです。
リファクタリングのような規模の大きなプロジェクトをメインに進めている期間は、上記のような厳密なSprintを回すのではなく、より上流の要求とスケジュール感の認識を合わせつつ、実装しながら詳細な仕様を詰めていくようなスタイルで進めています。
最後に、エンタメをDXする仲間を募っています!
最後まで読んでいただきありがとうございます。この記事をご覧になったあなたが自分のチームに持ち帰り、チームのプロダクト開発に活用できる示唆を提供できていれば嬉しいです。
最後に弊社のことを少し話すと、上述の内容から大層なプロダクト開発を行なっているような印象を抱かれたかもしれませんが、プロダクトチームはまだ数名しかおらず、社員も15名程度のベンチャー企業です。
一方、事業的には2021年度後半から、既にARR60億強となっているECプラットフォームとMD Cloudを連携させ、さらに大きなエンタメマーケットにエントリーしようとしている、そんな面白いフェーズです。
今後、どんどん優秀な方にjoinいただき、プロダクトマネジメントもエンジニアリングもチームとしてレベルアップしていきたいと考えており、絶賛採用強化中です。
興味を持っていただいた方はぜひ応募ください、Meetyでカジュアル面談も受付中です!
僕のTwitterアカウントからご連絡いただいてもかまいません。
最後まで読んでいただいてありがとうございました!
この記事が気に入ったらサポートをしてみませんか?