トレタでの開発プロセスとプロダクトマネージャーのしごと

こちらはトレタAdventCalendar2023 10日目の記事です。

こんにちは、株式会社トレタでモバイルオーダーアプリ・トレタO/Xのプロダクトマネージャーをしている北川です。 toreta.in

年月はあっという間に過ぎ去るもので、プロダクトマネージャーという肩書きをいただいてからもうすぐ2年が経ちます。 手探りで始めたプロダクトマネジメント業務も少しは板についてきたと思うので、この記事では自分がトレタで行なっているプロダクトマネジメントの仕事についてまとめようと思います。

他のプロダクトマネージャーやトレタでの開発プロセスに興味のある方の参考になれば幸いです。

プロダクトマネジメントとは

まず「プロダクトマネジメント」という定義は一般的にも曖昧です。プロダクトマネジメントの定義はプロダクトマネージャーの数だけある、ということが「プロダクトマネージャーのしごと」という本にも示されています。

www.oreilly.co.jp

私がプロダクトマネージャーになってまず手にとった「プロダクトマネジメントのすべて」という本にはプロダクトマネージャーがやるべきことや必要なスキル、知識などが幅広く紹介されています。 これをすべてやるなんて超人すぎる…と途方に暮れたものです。

• プロダクトマネージャーの仕事・・・プロダクトを育てる、チームビルディング、ステークイホルダーとのコミュニケーション等
• プロダクトマネジメントの必要とされるスキル・・・発想力、計画力、実行力、仮説検証力、リスク管理力、チーム構成力等
• プロダクトマネジメントに必要とされる知識・・・ビジネス、UX、エンジニアリング等

www.shoeisha.co.jp

トレタでのプロダクトマネージャーはその本にあるようなミニCEOほどの権限はなく、そこはプロダクトオーナー（PO）が担っています。また、トレタでPM という職種にもプロダクトマネージャー(PdM)とプロジェクトマネージャー(PjM) の２つがあります。

プロダクトオーナー（PO）	プロダクトのアウトカムに責任を持つ人
プロダクトマネージュー(PdM)	プロダクトをどう作る考える人
プロジェクトマネージャー(PjM)	プロジェクトの進行管理をする人

なのでプロダクトマネージャーとしては、エンジニアリングの視点としてやりたいことに対してシステムとしてどう作るか、そのためのチームをどう構成にするか、という範囲が責務になります。

もう一つ、自分がプロダクトマネージャーの定義として大事にしているのは「Executionに責任を持つ人」ということです。この言葉はVPoE handbookという記事から引用したものです。 note.com

とにかくプロダクトを成長させるため、事業を前に進めるためなら何でもする、ということです。

チームがなければ作る、人が足りなければ採用を強化する、チームやメンバーが進む道を阻む障害があれば取り除くということを小さいことでも何でもやります。ボールが落ちていたらとりあえず拾う、というのをプロダクトマネージャーの仕事として大切にしています。

普段の開発プロセス

日々の業務としては基本的に開発プロジェクトに沿って動きます。

通常のイシューまたは機能単位での開発の流れは以下の様に行なっています。プロダクトマネージャーとして一番関わるのは要件定義と仕様作成の部分です。

要件定義フェーズは「Why」を深掘り「What」と「How」を決める工程です。

開発項目としてやることが並べられたプロダクトバックログは、期初に定めたプロダクトロードマップのイシューと、ユーザーから届くフィードバックのイシューで構成されています。 そこからユーザーが本当に欲しいものは何か、本当に必要とされている機能は何かを深掘りし、どういった形でいつのタイミングで提供するのかを以下のメンバーで決めていきます。

UX/UIデザイナー	要求に対してユーザーにどういった体験を提供するかのUXおよびUIの提案を行う。アウトプットとして画面デザインを作る。
プロダクトマネージュー(PdM)	エンジニアリング視点でシステム上どう実現するかを提案する。アウトプットとしてシステムの全体設計と、システム内のふるまいを仕様として定義する。
プロジェクトマネージャー(PjM)	各チーム内のタスクリストや稼働状況を照らし合わせてどのタイミングで行い、いつリリースするかのスケジュールを提案する。
プロダクトオーナー（PO）	プロダクトバックログの優先順位を決め、各要件の最終決定を行う。

質とスピード

我々が顧客としている飲食店のユーザー属性やユースケースは多種多様です。チェーン店や個店などの規模感の違いや、居酒屋やカフェなどの業態の違いなど店内オペレーションは店舗ごとにまるで異なります。それらすべてを満たすための仕様や設計にまとめるのは難しさがあり、すべてはトレードオフになります。トレードオフのレバーのどれを押すか、どう設計するかに迷ったときの判断軸はしばしば会社のバリューに頼ります。

note.com

トレタでは行動指針として６つのバリューが示されています。その中でも特に意識するのは「速攻」と「圧倒的品質」です。相反する2つに思われますが、デリバリーの速さと品質の両方を両立できるが最善です。

有名なt_wadaさんの「質とスピード」という話は弊社の開発現場でも浸透していて、これはまさに品質とスピードの両方を両立しましょうという話です。

質とスピード（AWS Dev Day 2023 Tokyo 特別編、質疑応答用資料付き） / Quality and Speed AWS Dev Day 2023 Tokyo Edition - Speaker Deck

これはコーディングだけではなく、設計や仕様を作る場面においてもこのエッセンスはあてはまると自分は考えています。 ここでは「質」とは「保守性」と語られています。つまり、スピードを重視することで中長期的な保守性を下げるような仕様や設計にすべきではありません。

たとえば、特定の店舗だけ機能を分岐させたいというようなカスタマイズの要望があったとします。それを実現するために店舗情報に専用のフラグを新しく足してアプリケーション上で分岐処理をさせよう、というやり方が1つ考えられます。

ただしその場合、他の条件が今後出てきて絡みあったときに複雑さは増し、QAコストも跳ね上がるため保守性は下がっていきます。フラグを持たせずに他の状態で分岐条件を判断させることはできないか、フラグを持たせるにしても将来的に２値でいいのか、などよりシンプル（疎結合）で将来的にも負債になりづらい方法がないかを常に模索する必要があります。そしてそのやり方の方が多少のデリバリーの遅れがあるとしても、質が下がりにくいのであればそちらを採用します。

スピードに関しては「スコープを削る」ことをよく行います。ただ、スコープを削るだけではなくその機能で果たしたい最終的なあるべきゴールを描いてからフェーズを分割します。その上で1stリリースとして要件を最低限満たすミニマムな部分はどこかを探り短い開発期間でリリースできるようにします。これのいいところは、将来を見据えることで場当たり的ではない仕様にしやすくなるという点です。

終わりに

前述したとおりプロダクトマネージャーの仕事は幅広いので、今回書ききれなかった内容は山ほどあります。そちらは追って別の記事で書きたいと思います。

また、トレタでは一緒にチームで働いてくれるエンジニアのメンバーや自分と同じくプロダクトマネージャーとして活躍してくれる人を求めています。飲食店の未来をアップデートする事業に興味のある方はお気軽に話を聞きにきてください。

corp.toreta.in