PO としての思考を開示してみる
株式会社いい生活エンジニアの杉原です。
今月から社内のとあるプロダクトの PO (プロダクトオーナー)になりました。
（任命したのは自分なのですが）
PO をやるのは今回で2回目になりますが、慣れて来たらプロダクトの全てをコントロールできる、とても楽しくてやりがいのあるポジションです。
そこで僕が PO をやる上で考えていること、実際やったこと、を言語化してみます。
PO って何すればいいの？
PO は「プロダクトオーナー」で、文字通り受け取ると「プロダクトについてオーナーシップを持っている人」です。
オーナーシップを持つ、とはどういうことかというと、それについて全責任を持つということです。
つまり PO という言葉はその人が持っている責任範囲について明示しているだけであり、業務内容については定めていません。
そして定められてる責任範囲とは「プロダクトに関わること全て」ということになります。
これを誤解して、 PO の業務は報告書を書くことだとか、プロダクトバックログの管理だとか、業務内容で PO という仕事を定めてしまうと、その仕事は無機質なものになるし、たぶん評価も上がらないでしょう。
PO の責任範囲は「プロダクトに関わること全て」なのだから、業務は当然「プロダクトに関わること全て」です。
チームには売り方を考える PdM (プロダクトマネージャー)や、マネジメントを担当する SM (スクラムマスター)などがいるので、業務範囲を分割すべき、という人もいるかもしれませんが、僕の意見は違います。
売り方を考えることもチームをマネジメントすることも「プロダクトに関わること」なのだから、それらは全て PO の責任範囲内です。
なので、それらは PO の業務ではない、ということはないです。
それがオーナーシップを持つということです。
もし業務の内容で PO の仕事に取り組んでいる人がいるなら、一旦その思考を切り替えてみたら、ちょっと世界が変わって見えるんじゃないでしょうか。
PO としての思考
僕が PO としてプロダクト開発をする上で、大事にしていることの優先順位は以下です。
- チームメンバーが気持ち良く開発できること
- ユーザーがちゃんと使ってくれるものを作ること
- 売れるものを作ること
何故この優先順位なのかということを説明します。
チームメンバーが気持ち良く開発できること
これが最も大事なのは、受注して開発して納品して終わり、という単発の受託案件ではなく、安定した品質でクラウドサービスを提供し続け、その対価としてサブスクリプションでお金をもらう、というビジネスモデルを取る場合です。
単発の開発ならそこまで品質に拘る必要もないし、それなりの人材を一時的に雇って開発しても何とかなるでしょう。
（そんなことねーよという突っ込みは一旦無視します）
ただし、クラウドサービスを提供するなら、リリースしたものは保守運用する必要があるし、ユーザが増えたらそれなりに大規模なシステムになってくるので、技術力も必要です。
であればスキルの高いメンバーには長く働いてもらう必要があるし、スキルの高いメンバーが働きたくなるような環境にする必要があります。
スキル云々を最初に書いてしまいましたが、そうではなくても人は気持ち良く仕事をしてるときの方がパフォーマンスが高いので、開発効率を考えてもこれは大事です。
あと、僕はそもそも自分自身が気持ち良く開発したいというモチベーションが高いです。
ユーザーがちゃんと使ってくれるものを作ること / 売れるものを作ること
この2つの優先順位は会社のフェーズにもよると思いますが、僕はエンジニアがコミットすべきは「ユーザに使われること ＞ 売れること」だと思っています。
もちろん売上は事業を継続する上で大切ですが、そもそも売れるかどうかはビジネス戦略によるものが大きいというのと、売れても使われてないならそれは長くは続かない売上だからです。
ユーザの依存度が高いならその段階で売れていなくても例えば値上げすることもできますし、それをフックに広告を出すなど他のビジネス戦略も取れます。
なので PO として大事にしたいことは、ユーザにちゃんと作ってもらえているかどうか、そして次点で売上、というのが僕の思考です。
経営からの圧力、重要顧客の要望や解約など、この優先順位を狂わせようとするバイアスはたくさんあります。もちろんビジネス上の制約で優先順位を逆転せざるを得ないことはあるでしょう。しかし、圧力と戦って優先度を守り、プロダクトを正しい方向へ導くことが、エンジニアたる PO としての役目だと思っています。
PO になってやったこと
上記を踏まえて、 PO になってからやったことです。
Design Doc を作る
プロダクトをこれからどうしていきたいか、についての認識をチームメンバーで統一し、ひいては他チームのメンバーにも共有できるように、 Design Doc を作りました。
これは PdM にベースを作ってもらって、僕が加筆、レビューを何回か、という感じで進めました。
ロードマップを決める
これからどうして行くかの方向性が何となく見えたところで、どのぐらいの時期を目標に何をやりたいか、をロードマップとしてまとめました。
キックオフする
チームメンバーのモチベーションを高めるために、キックオフをしました。
キックオフでは、どういう体制で進めていくか、プロダクトが現状どうなっていて、これからどうして行きたいのか、ということを話しました。
これはちゃんと伝えたかったので、チームメンバー全員出社で対面でやりました。
プロダクトバックログを断捨離する
担当するプロダクトの epic ボードが、プランニング対象と backlog と TODO が無数にあり、今何をやっていて次何をやりたいのか、が見えづらい状態だったので、本当にやりたいもの以外は全部 Open に戻し、見るべき epic がボード1枚に収まる状態にしました。
意外とこれをやる人は少ないなと思ってるんですが、気持ち良く開発するには無尽蔵にタスクが積まれている状態は好ましくないと思っているので、えいやとやりました。
技術的負債と向き合う
担当するプロダクトは2021年にリリースされているのですが、様々な歴史的経緯により、早くも大きめの技術的負債がいくつかありました。
僕が PO になったタイミングでこれは回収できるところは回収したいと思い、思い切って技術的負債の回収の優先順位を最大にしました。
まだ若手のチームメンバーにとっては若干無茶振り感もあるかなと思いましたが、技術的負債の回収はプロダクトのアーキテクチャ全体を理解する機会にもなるので、良い選択だったと思っています。
これも僕の開発優先順位の最大が「チームメンバーが気持ち良く開発できること」だからだと思っています。
おわりに
僕の PO としての思考と実際にやったことを言語化してみましたが、如何だったでしょうか。
読んでいただければ分かる通り、 PO という仕事には正解もなければ不正解もありません。
これを読んで少しでも PO ってかっこいいな、楽しそうだな、と思っていただければ嬉しいです！
Discussion