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の特定フェーズでドキュメント化済みであれば、当該ドキュメントへのリンクを設けるだけでもかまいません。
Issue(= Epic)：解くべき課題を記載します。プロジェクトくらいの規模になると、プロジェクト内に分解可能な複数のIssueが混在するケースも多いですが、その場合は適切な粒度に分解したIssueをすべて記載します。
Story：Storyタイトルと概要を記載します。詳細は後述する別ツールにまとめますが、特にプロジェクトスコープが大きいとEpicのみでは読む人が具体的なプロダクトイメージを抱けないので、概要を記載しています。
Issueの分解基準ですが、解決して顧客に価値を提供できる最小限の粒度にすることを1つの基準にしています。
②に関しては、「Issue Analysis」という顧客の要望管理のページに記録し分析します。
Request：顧客の言ったことをとにかくそのまま記載します。起票者の解釈を持ち込まないことが重要です。
Why：Requestが生まれた背景を記載します。起票者はRequestを受けた際にこの背景まで深掘ってヒアリングします。
Issue：Whyを踏まえた解くべき課題です。Story化した場合は当該StoryチケットのURLを添付しています。
Requestが異なっても根本的なWhyが共通であれば、1つのIssueで複数のRequestに応えることが可能となりますし、このように要望を抽象化してより本質的でインパクトの大きいIssueを導き出すことを意識しています。
結果として、顧客の要望トリガーでプロジェクトの発足に繋がることもありますし、粒度の小さいIssueであれば直接Story化のSTEPに進むケースもあります。
ちなみに、1については以下のnoteでさらに詳しく書いてもいるので、お時間ある方はぜひこちらも参照ください。
2. Story化
弊社ではAjile Project Managementツールとして「Pivotal Tracker」を利用しており、Storyは当該ツール上で作成し優先順位の管理を行っています。
2022年からRENIではAjile Project Managementツールを「Linear」に移行しました。大まかな使い方はPivotal Trackerと同様ですが、Linearについての詳細はこちらの記事が参考になるのでぜひご覧ください。
Issueをブレイクダウンすることにより、必然的にStoryに落とし込まれます。
StoryはIceboxに起票します。Icebox上ではリリースチケットを活用することでプロジェクト単位、あるいはIssue単位でまとめています。
週次で行うBacklog Refinementにおいて、Iceboxの中から直近の1ヶ月程度で取り組みたい優先度の高いプロジェクトやIssueに紐づくStoryをBacklogに移動させます。
Storyを切ること自体は1のフェーズでIssueが明確に特定できていれば難しいことではありません。ただし、内容については弊社ではStoryのテンプレートを準備しており、Story化へ取り組むハードルを下げると同時に品質がぶれないことを意識しています。
Storyのテンプレート
Goal：当該Storyの目的と実装後の理想の状態を記載します。Storyチケットで最も重要な要素です。Issue Analysisにまとまっていれば、当該Issueへのリンクでもかまいません。
Rules：プロダクトの外部仕様を記載します。アクションとその結果を記載しますが、画面単位ではなくStoryを意識することが重要なので、インプットに対してデータがアウトプットされる対象を網羅します。
UI：UIデザインのURLを添付します。PdMが描いたワイヤーであったり、デザイナーがデザインしたFramerのURLが添付されます。
Examples：具体的な値を用いたExampleケースを記載します。異常系や制御系の具体例を記載することで、ステークホルダー間で認識を合わせることができます。
Questions：Storyの起票者、またはそれを読んだEngineerなどが質問を記載する場所です。MTGなどで確認します。
Notes：補足情報を記載する場所です。Rulesはある程度シンプルにした方が読む人の頭に入りやすいので、外部仕様として記載するほどではないが明示しておいた方が良い実装上の留意点などを記載します。
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アカウントからご連絡いただいてもかまいません。
最後まで読んでいただいてありがとうございました！
この記事が気に入ったらサポートをしてみませんか？