①この記事のターゲット
- 新人POとして案件に配属された人（主に技術系のPO）、技術系のPOとして案件を回しているが、「ん？POというより、どうもプロジェクトリーダー/PLじゃない私？」と思っている人向け
②背景
- 会社の規模によってはアジャイル開発のプロダクトオーナーがビジネス側（営業やマーケティングなど）と技術側（プロダクト開発）が分かれていることがある
- 技術側のPOは、エンジニア達を率いて開発管理/プロジェクトマネージメントを求められる色が強いと思う。その場合、ビジネス側POからふんわりとした要望を渡され、要件定義前後から技術側POが引き継ぎ、プロダクトバックログの作成〜エンジニアの開発管理を行うと思う。
- 例えば、私の会社の場合は、Q単位でビジネス側から要望の一覧を受け取り、Q内の開発管理は技術側に任されており、要望内容をエンジニアが開発できるレベルまで要件として定義していく。開発管理のためにバックログを作成するが、その優先順位についても、開発側に一任されており、ビジネス側としてはQのマイルストン内に要望したものが完成すればOKという構造だ。
③私が思う課題点
- こうした構成の場合、プロダクトオーナーというかプロジェクトリーダーでは。。。と思ってしまうし、、何よりステークホルダがビジネス側のPOという目線になりやすい。
- プロダクトオーナーは、「プロダクトの価値の最大化」に貢献するべきなのだけれど、、ビジネス側のPOの言うがままに開発をしてしまって、彼らの要望を満たすこと＝私の使命！になってしまいがち。
- そこで、私が技術系プロダクトオーナーでも、ここは握っておいた方が良い！！、と普段の業務で感じている１２のポイントと、その理由をまとめてみた。（もちろん技術面も含まれる）
④チェックしておきたい１２のこと
- どんなプロダクトであるか
- プロダクトのステージ
- プロダクトのビジョン
- ターゲットユーザーと価値
- ビジネスモデル
- KPI
- ステークホルダ
- 独自性・独自体験
- 開発手法やチーム構成
- 技術スタックやアーキテクチャ
- システム構成図
- 社内アセットの活用
⑤理由
1. どんなプロダクトであるか
- プロダクトについて簡単に説明できるように。開発管理をしていると、何かしらプロダクトの資料作成を求められたり、講演などで発表を求められることもある。
- アジャイル開発をしていればインセプションデッキを作る中でエレベータピッチというものを作っているかもしれない。その粒度で説明できると良いと思う。
2. プロダクトのステージ
- 自分のプロダクトが会社の中でどういった位置に置かれているのか分からない場合は把握しておこう。立ち上がったばかりなのか、リリースしてから時間が経っているのか、プロダクトが置かれている状況はどうなんだろうか。
- 技術系のPOは開発チームを抱えているわけだが、開発チームを維持するのにはコストがかかる、そしてプロダクトの置かれる状況によってかけられるコストも変わってくる。常に自分のプロダクトはどの位置なのかを把握しておこう。
| ステージ | ステージ名 | プロダクトの状況 | コスト（技術系PO目線） |
|---|---|---|---|
| 0→1 | 新規開発 | 何もない状態からプロダクトを立ち上げる | コスト追加しやすい |
| 1→10 | 機能追加 | ユーザーに期待される機能を提供し、安定した事業収益を得る | 継続的なかつある程度の収益があれば良いが。 基本はコスト維持＝体制維持or縮小を求められることもある 技術系POから追加機能を提案することで体制を維持する必要があるケースが多い |
| 10+ | 運用保守 | 新規の機能追加はほぼなく、現状維持 | 最低限の体制を求められる |
3. プロダクトのビジョン
- プロダクトを通して作り出したい未来の世界観のこと。また会社の事業戦略上の位置付けも合わせて把握しておきたい。
- 最後にプロダクトを作るのはエンジニアであり、エンジニアにインプットするデザイナ含め、ビジョンを理解してもらい、より良いプロダクトを作ってもらおう。チームとしてプロダクト志向のチームを作っていく。アジャイル開発で改善を回していき、より良いプロダクトを作るために、ビジョンからしっかり伝えていきたい。
- 会社の事業戦略上の位置付けを把握すると、今後の自分のプロダクトが成長するのか、似たプロダクトが派生で生まれてくるのか、など予想しておくことができる。似たプロダクトが生まれてくる場合は、相互連携する可能性もある。
４. ターゲットユーザーと価値
- 価値を提供する先のユーザーは誰か、「誰を」「どんな状態にしたいのだろうか」を把握しておこう。
- 普段の生活の中でターゲットユーザーに近い人がいたら観察できると良いと思う。自分のプロダクトを使ってくれたら、生活の中でどう使われるかな？そういった想像をしていると、新しい発見やアイデアが生まれることもある。
5. ビジネスモデル
- どうやってお金を稼ぐのか、収益の流れ（広告？どこからお金が生まれるのか）、コスト構造はどうなっているのか（エンジニアやデザイナにいくら払っているのか、サーバー費用は？）を把握しておきたい。
- 開発の優先度や方針を決めるときに、自分だったらこの額出してこの機能を作るだろうか、と今一度考える視点を持つべき。
- 冒頭のプロダクトのステージでも記載していたが、常に開発チームを維持できるコストが確保できるとは限らない。自分が持っているお金で開発してもらうなら..この要件よりこっちにお金払いたいな..なぜなら..と考えること。
6. KPI
- このプロダクトは何を持って評価されるのか？自分達が継続して開発チームを雇うためには、KPIを達成していきプロダクトの価値を証明し、お金を獲得する必要がある。
- 開発の優先度を決めるときも、KPIの意識が必要だ。特に技術系POとしてリファクタを進めたい時でも、KPIの機能の優先順位を下げてしまうと、次期開発での予算獲得が難しくなり、開発チームを維持するコストに影響が出る可能性もある。バランスが重要・・・
7. ステークホルダ
- プロダクトに関して意思決定できる権限が自分にあるとは限らない。。。誰が決裁権を持っているのだろうか、明確にしておきたい。
- 誰にどの程度の情報をレポートするのか、レポートラインやレポート内容の線引き（この人はここまで気にするorしない）を把握しておこう。レポート漏れは極力避けること。ステークホルダから信頼を獲得し、味方につけておきたい。
8. 独自性・独自体験
- これはユーザーへの提供価値に近いのだけれど、このプロダクトが持っている独自性や独自体験、オリジナリティをPMとして意識しておきたい。その独自体験があるかぎりプロダクトのユーザーは自分のプロダクトを選んでくれている。
- また、自分のプロダクトと似たプロダクトがあるならば、それは継続Watchしておくべき。他のプロダクトで良いなと思ったアイデアは自分のプロダクトに取り入れることを考えてもよし。
9. 開発手法やチーム構成
- どんな開発手法を採用しているのか、何人規模のチームで開発しているのか、開発手法の特性を活かしきれているのか？プロダクトのステージとマッチしているのか、など考えてほしい。
- またトラブル時などにも誰が何を得意としているか、誰に何を依頼するのか、は把握しておくと、いざという時にも安心。
- 後述の技術スタックにも似ているが、メンバーのケイパビリティ（どんな技術をどのくらい開発してきたか）を把握することも必要。新しい要件に対応するときに今のチームにケイパビリティがあるのか？ないならどうするのか？（メンバーを育てるのか、外部からケイパビリティを獲得するのか、別の方法Saasサービス等で解決できるのか？）を考える。
10. 技術スタックやアーキテクチャ
- 自分がこの案件を通して活用している技術スタックのこと。
- 技術系POとしてどんな技術スタックを使っているのか把握しておくと普段のITニュースなどでも目につきやすくなる。また、この辺りが案件横通しで共有されていると、会社内の他の案件Tmから「俺も使ってみようと思っていたんだよね」「気になってたんだよね」「この前こんなバグ見つけたんだけど」「バージョンアップしたら〇〇になったんだが..汗」とかの情報が入ってきやすい。積極的に公開・共有していきたい。
- メルカリの記事を参考にすると以下の感じ。
| カテゴリ | 技術スタック |
|---|---|
| アプリ種別 | スマホアプリ/Webアプリ（SPA,SSR,SSG,..）/PCアプリ/... |
| プログラミング言語/ライブラリ・フレームワーク | Swift、Java、Flutter、React、Next.js |
| インフラ | GCP,AWS, |
| ミドルウェア | NGINX,Apache... |
| データベース | Firestore, Amazon S3 |
| 運用監視 | Datadog, Crashlytics |
| データ分析 | GA4, Firebase |
- またアーキテクチャを把握しておくのも良い。例えば、FlutterでMVVMで作っている場合で、自分が追加する要件はViewだけで開発できるのか、Modelまで手を加えるのか、分かるようになると、おおよその開発規模/ストーリーポイントも感覚で掴めていけるようになり、スケジュール感がおおよそ予測できるようになる。トラブルで突発的な作業が発生した時に、ビジネス側POやステークホルダに頭出しできるようになる。
11. システム構成図
- 全体的な構成を把握するレベルとNWの通信経路がわかるレベルで把握できると良いと思う。
- 前者はトラブル発生時の切り分け・エスカレ用の説明資料にも役立つと思う。
- 後者はNWの性能目標を設定するときやNW関係のトラブル対応や性能課題を調べるとき、役立つはず。
- 他のシステムとも跨いで通信しているときのトラブル対応時は、通信経路上にいくつかポイントを置いて、パケットをキャプチャしてどこまではOK/NGと切り分けていくことになるので把握している/していないでは天と地の差が出る（経験談）
12. 社内アセットの活用
- 社内アセットを活用することは、より早く機能提供することに繋がるし、全社的に最適解と判断されやすい。自分の社内のアセットの知見を広げておくと、機能提案のアイデアや開発時の選択肢が増えやすい。
- 周りに同じような技術系POがいるなら、他の案件ではどんな社内アセットを使っているか、積極的に情報収集しておこう。
以上！！
⑥最後に
- 個人的に重要そうなものや意識して欲しいポイントを踏まえて１２のチェック項目を作ってみた。
- この記事の内容は、Voicyのプロダクト開発の語り場チャンネルやプロダクトマネジメントのすべてなど参考（やほぼそのまま記載..）にさせてもらっている（もちろん自分の経験から、ここは理解して抑えておいた方が良いだろうな、という部分も記載）。
- この記事を最後まで見てくれた人で、「これは必要！」「これは要らない」「これが足りないぞ！」など、思うことがあれば積極的にコメントして欲しい。