KDDIアジャイル開発センター株式会社で「POリード」という役職をやっている佐々木です。
皆様おそらく聞きなれない役職ですが、弊社内でもPOサポートから格上げ（？）された新たな役職であり、今後弊社が事業拡大を狙う上で重要なロール、らしいです。業務内容はググったらいわゆる転職エージェント的な募集要項が出てきたのでぺたりしときます。（自社ページに情報が出てこなかったのだが、まあ整備中なのかなと・・・でも、同ポジションの採用は随時募集中なはずです！）
POリードとは
ビジネスDXに関わる新規サービスについて、プロダクトオーナー(PO)を支援し、プロダクト価値を最大化する業務
- POと協力して、お客様の課題とプロダクトを利用した解決策（提供価値）を定義する。（プロダクトビジョンの決定）
- POと協力して、プロダクトに必要な要件（プロダクトバックログ）を整理する。
- POと協力して、提供価値、コスト、技術等の制約／制限事項を考慮し、プロダクトバックログの優先度を決める。
- POと協力して、仮説検証を繰り返しながら、アジャイル開発をリードし、プロダクト価値を最大化する。
要は、POとしての業務の補佐的な役割ですね。プロダクトオーナーという役割は、多くの会社では新規開発案件が立ち上がった際の企画立案メンバー側から新しく着任することが多いかと思いますが、そんな人が開発方中心のアジャイルスクラムに入り込むのはなかなかに障壁が大きいのではないかと思います。そこで、スクラムガイドに則ったPOという業務を理解している立場から、時には指南し、時には共に企画検討を行い、時には代行でスクラムを動かすような働きを期待されているのではないかな、と解釈しています。
注目ポイントは、全てに「POと協力して」とあるところ。あくまでPOのやりたいことを汲み取った上で、POのパフォーマンスを最大化するのがお仕事であり、自分でPO業をやるわけではない、というところでしょうか。個人的にはここが一番悩みながら働くことになるだろうな、と思っておりまして、「決めることがお仕事！」なPOを経た身としては、「自分では決められない、（悪く言えば）決めさせないといけないお仕事！」なわけで、より人・ステークホルダー・開発メンバーとのコミュニケーションを必要とし、よりスケジュール管理が必要で、決めること・決まらないことへのフラストレーションもりもりなPjM的な要素が強いお仕事になるのではないかな、と思ってたりします。
そんなこともあり、弊社代表木暮が言うには「POの上位職であると考えている」とのことです。なるほど。POを引っ張るということは、POという職務を理解している立場でないといけない、ということでしょうね。そんなチャレンジングな環境で一緒に働いてみないか！？
POの職務
さて、私の話をすると、フロント・バックエンド両開発を伴うアプリのPOを数年、タイミングとしてはリリース自体は完了した、黎明〜拡大（いわゆる1→10にする）のあたりから携わっていました。ジョインきっかけはジョブローテ的な技術→商品企画への人事異動でして、今までの企画背景とか業務知見とか無しに放り込まれたクチです。結果から言えば、企画初めの産む苦しみ、上へ通す苦労もせず、プロダクトオーナーのいいとこだけ経験できたので恵まれてたのかなと思ったりもします。
その頃は体制としてアジャイルを取ってみたものの、まだまだチームも企画方も不慣れ・未成熟で、思うように開発が進捗しなかったり、こちらとしても企画の意図を十分に伝えきれずヤキモキしていたものでした。それがうまく回り始めたな、と感じたのは、バックログを徹底的に取捨選択、整理して、チケットの記載を自分の言葉で、依頼に至る背景（Why）とAC（What）を記述できるようになってからでした。
それまでは、企画チーム側から締切やサービス構想の話を伝えて、どういう機能かの説明（どちらかと言えばHow寄り）を各業務範囲をもつ複数人担当から伝える、という流れで、ただスプリントでぶつ切りしただけのウォーターフォールや、と言われても仕方ないものでしたが、スクラムのお作法を見よう見まねで作ったチケットを通じて、必ずしも主担当ではない領域でも一人のPOが代表して自分の理解で意思を伝えるスタイルに変更できたのが良かったのかな、と振り返ってみて感じます。
そんなわけで、私が考えるPOの職務とは、シンプルに以下の通り。
- プロダクトの方向性をチームに伝え、決定する唯一無二の存在であり続けること
意味的にはこれだけだと思っています。その他は付随です。
そして、この職務を全うするためには、日本の会社あるあるの合議的な振る舞い、トップダウンによる飛び越えの指示体系からは少し距離を置いて、（少なくともチーム側から見た時に）PO自らの決断だけでチームを動かせることが求められるのだろうな、と思っています。
凡人でもできる！プロダクトオーナー資質論
こういう類のスクラム話を見ると、自分には向いてないなーと思ってしまう人もいるかと思いますが、私自身は性分としてふてぶてしいのですごく向いてたと思っていますし、一方で、「アジャイル？なにそれ？」で未熟な状態でもうまく支えられて役割を務められたこともあり、特段優れた能力は必要なかったな、とも思っているので、誰でもやればできるロールだろうなーとも思ってたりします。
暴論吐いてしまえば、あまりにスクラムガイド等に描かれているプロダクトオーナー像がキラキラでスンバラシすぎ万能すぎる神様的存在として描かれていて、こんなの見せられたら誰もなりたくないだろと思ってしまいます。ま、理想は理想として、どれだけ必要最低限のPOとしての動きを定義できるか、そんな情報ってないのかな、と思い、ないなら自分の考えでまとめてみようと。こんな企画のキの字も知らなかったペーペーがどうやってプロダクトオーナーとして虚勢を張れたか、考え方のいくつか挙げてみたいと思います。
-
今ある情報を元に打算的な最善手を決定する
プロダクトオーナーの一番の仕事は、決めることだとよく言われます。やるかやらないか、どちらのチケットが先か、AがいいかBがいいか・・・ その中でプロダクトとして最適なゴールに導く選択を行え、というやつです。ですが、本当の正解なんて誰にもわかりません。なので、今手元にある情報の中から、自分の中の基準と照らし合わせて、どれが一番得をしそうか、損をしても被害が少なさそうか、を検討してきました。
ポイントは、「今」「手札の情報を元に」決定を「その場で」してしまうことです。極論、間違っててもいいと思っています。ただし、判断の先延ばしはしません。後から情報が追加されたら判断間違ったと思うかもしれませんが、それ自体は後から直せばいいのであまり重要ではないです。判断を遅らせて止まることの方が問題です。「今」決めることでプロダクトは進み続けられます。 -
わからないことを素直にわからないという
ある意味さっきと逆です。判断に足らないときは、情報がないから（足りないから）判断できないと宣言してきました。プロダクトを導く使命を負ってしまったからには、判断材料が必要ですが、時に自分でかき集めるのではなく、判断に足る情報の収集を他の人に依頼しました。この動き方は自分が怠惰だっただけですが、これによりPOがボトルネックにならずに判断に注力できたのだから、まあよかったんじゃないかな、と感じています。 -
チームの隣に常にいる。自作業中でも声をかけられたら中断して話を聞く
多分これが周囲の理解が必要な分、一番難しいです。スクラムを回していると、チケットの不備や、やってみて気づいた矛盾点、考慮が必要だった技術的仕様など、想定外のことが大なり小なり起こります。その際に、上記した「判断」をすぐに示せる存在でなければいけません。チームに張り付きましょう。
ただ、そうするとステークホルダーとの議論の時間がほとんど取れないことに気づきます。そこは上司や企画T(POチーム！)の同僚にかなりフォローしてもらいました。もっと優秀なら空き時間でチョチョイとやってしまうのが理想なのかもしれないですが、今から思うと、即時性の要否の点で比較して、週次定例程度の共有で十分だったし、企画や営業の話は後からの伝聞でも十分に情報・気づきを得られてたので、凡人の動き的にはこれでよかったんじゃないかな、と。ここ、ガイド的には一番怒られそうだ。 -
自分の言葉・理解でまとめ、発言・プレゼンする（他人の伝書鳩にならない）
ステークホルダーの発言は現在の開発方針や、ステークホルダー同士でも意見が衝突してしまいます。ですので、混乱を避けるためステークホルダーの（そのままの）発言はできるだけチームには伝えませんでした。代わりに、自分の言葉で噛み砕いて、伝えるべきことだけを伝えることで一貫性を保とうとしました。時には伝えづらいこともありましたが、「私はそうは思わないけど」「緊急問題発生のためイレギュラーで申し訳ないけど」みたいな枕詞を使うことで、チームとして今までやってきたこととは矛盾していないことを伝えようとしました。 -
ビションはプレゼン作業と割り切る
スクラムガイドのPOの重要な業務としてプロダクトの方針（ビジョン）を定義すること、とあります。ありますが、大抵の場合、ビジョンは企画の経営判断に流用されるため、かなり遠くの達成目標として描かれることが多く、現実のプロダクトと距離があり、線で繋がっていません。ですので、経営的なロードマップ説明をプレゼンすることは必要作業として割り切り、チームとはもう少し短期の目標を語ることをメインとしていました。そんな先のことわかってたら会社員なんてせず独立して稼ぐっちゅー話。 -
自分のプロダクトが嫌い、でいい
人・記事によってはPOが1番のユーザ・お客様であれ、みたいなこといわれてますけど、ぶっちゃけ、ね。妥協とは言いませんが、自分の目標とするところから劣るプロダクトを愛することは難しい。嫌なところがあるからこそ変えたいという原動力にもなるし、自分で変えたる！でいいと思います。あと、本当のお客様は全く意外なところで挫けて不満を持ったり、全く意外なところにサービスの魅力を感じていただいたりします。大抵の場合、信じるのは自分のLikeよりお客様の声。そっちの方がピントが合ってます。 -
時間が足りない、、、でもできない、ことをそんな気にしない
もう一生解消されないであろうチケットの山がバックログに積まれますが、それに慣れましょう。なーにできなくて当たり前さ。むしろ何も積まれてないバックログのが見るの怖くなってきます。あと、どうやって開発するんだこのチケット、みたいな遠い未来の理想像を作っておくと開発陣にエモさを伝えることができていい感じです（評判は知りませんが）。
進捗も同じですね。極端な話、開発出力が上がらないのはPOの責任ではないですし（逆ギレ）。ただ、開発チームを絞ってもあまりいいことはないです。逆に「あーこれはこのスプリントでは流石に無理だねー」と同調しておくと、なぜか次のスプリントで速攻レビュー依頼が飛んできたりしてありがたいことが多かったですね。上司やステークホルダーにはいい感じに伝えて遅れることを怒られましょう。まあそれも仕事です。 -
バックログ管理はまめにする
時間がある時は一日中バックログのチケットの記載や並びを綺麗にしてたりしました。上の話とも繋がりますが、あーこれまだできてないんだなーとか、これとこれとこれができれば面白いサービスになるよなーとか、まだまだやることがあることをニヨニヨしながら磨いてました。
これやってるとなにがいいかというと、結構不意に説明しなきゃいけない時があるんですよね。チームからはチケットお代わりでこれやっていいですか？とか、上司からあの不具合修正ってどうなったんだっけ、あ、まだです積んではいます、とか。磨いて自分のものにすればするほど不意の説明がしやすくなる感覚があります。
POリードが思うプロダクトオーナーという存在
POとして今までやってきたこと（やってこなかったこと？）をお伝えしました。個人経営になりがちなPOは辛い面もありますが、周りの協力が揃えば/周りをうまく巻き込めれば、それなりの能力でもそれなりの振る舞いができることを私が保証します。今プロダクトオーナーという職種に途方に暮れている方の気の持ちようの変化や、やり方のヒントになれたらいいなと思います。
そんな考えが背景があるので、プロダクトオーナーには上記のような好き勝手な振る舞いしてもらいたいし、やりたいことを明確に持って、でも、自分でやらずにどんどん人に仕事を振ってほしいですね。そして、その地を引き出すことがある意味POリードとしての役割なのかな、と思ってたりするわけです。そして、「プロダクトの方向性をチームに伝える唯一無二の存在」になったあかつきには、同PJのPOリードの役割から卒業して、ワシが育てたと後方腕組みするのがPOリードとしてのPJのゴールだろうなーと勝手に思うわけです。（会社の指針と合ってるのか知らんけど。）
オマケ：16personalities
POってどんな性格の人が多いんでしょうかね。向き不向きみたいなことを考えててふとやってみました。誰か調査して。ちなみに私はこれ。割合的にはレアらしい。
