プロダクトオーナーが最低限守るべき10のこと

みなさんこんにちは。@ryuzeeです。

とある同人誌に寄稿した原稿を知り合いに共有していたのですが、ブログでオープンにしてほしいという依頼を受けたので公開します（同人誌の発行者には許可を取っています）。

怪文書みたいなものですが、感想お待ちしております。

本稿で何を書こうか考えていたところ、Twitterで「これがNASA流の仕事術、「プロジェクトマネージャーが守るべきルール100」が公開される」という2014年の記事を見かけました。書かれている内容はとても妥当なもので、プロジェクトマネージャーだけでなく、組織のリーダーでもプロダクトマネージャーでもプロダクトオーナーでもあてはまるものでした。

ただ問題は100個という数です。チェックリストに100個の項目があっても覚えられません。プロダクトバックログに100個の項目があった場合、覚えているのは先頭の方と、気になる項目だけになるでしょう。多すぎるのはムダです（会社のルールはどうなっているでしょうか？）。

そこで今回は主にプロダクトオーナーが守るべきルールとして10個にまとめてみました。プロダクトオーナーはスクラムで成果を出す上でとても重要であり、その性質上単一障害点になりやすい存在です。プロダクトの船頭とも言え、船頭が役割を果たさないと、みんなで遭難することになってしまいます。そうならないようにこの10個のルールを気にしてみるとよいかもしれません。

1. いつも健康でいる

プロダクトオーナーにはやることがたくさんあります。たとえばスプリント中は、スプリントプランニングやスプリントレビュー、スプリントレトロスペクティブに参加し、開発チームやステークホルダーと密にコミュニケーションします。プロダクトオーナーが健康でないと、イベントのスケジュールが乱れたり、開発チームの待ち時間が増えたりしてしまいます。また正常な判断ができなくなってしまうこともあるでしょう。いつも同じパフォーマンスを発揮できるように、健康にも投資しましょう。持続可能なペースで仕事をできるようにしましょう。

2.良いことは褒めて喜び、悪いことは責めずに冷静に

プロダクトの開発では日々いろいろなことが起こります。新しく作った機能が利用者にとてもウケたり、数字が伸びたりといった良いことがあれば、チームを褒め讃えて喜びましょう。一方で大きな障害が起こったり、スプリントがまったく計画どおりに終わらなかったりしても、感情的になってはいけません。それによってどんな影響があるのかを冷静に判断した上で、同じことが起こらないようにチームと協力して直していけばよいでしょう。同じゴールを目指す仲間を責めても良いことは１つもありません。

3. 成功はメンバーの成果、失敗は自分の責任。他責にしない

プロダクトオーナーは開発チームから生み出されるプロダクトの価値の最大化に責任を持ちます。つまり開発チーム抜きには成果を達成することはできず、成功は開発チームを含めた全員の協力の結果です。プロダクトオーナーが自分の手柄のように語るようなものではありません。一方でプロダクトの船頭として、最終的な責任はプロダクトオーナーが取らなければいけません。開発チームやステークホルダーのせいにしたところで結果は変わりません。むしろ、そんなプロダクトオーナーとは一緒に働きたくないという人が増えるだけです。

4. 方向性を繰り返し示す

プロダクトオーナーは、プロダクトのビジョンつまりプロダクトでどんな課題を解決したいのかを繰り返し示して周りの人に確実に理解してもらうようにする必要があります。これにはプロダクトとしてやるべきことだけでなく、「やらないこと」を示すのも含まれます。繰り返し方向性を伝えることで、プロダクトに対する共通理解が生まれ、意図を理解したフィードバックがたくさん得られるようになります。単にプロダクトバックログを並べ替えるだけでは不十分です。

5. 現実を直視する。淡い期待に逃げない

複雑で変化の激しい世界では、当初期待したとおりに物事が進まないのは当たり前です。プロダクトへの反応がよくない、開発が思ったより進まない……。いろいろな問題が起こります。こんなときは現実を直視しなければいけません。それこそがスクラムで短いスプリントに区切って検査やフィードバックのサイクルを回す利点です。現実に目を背けて、次のスプリントでは何とかなるかもしれないと期待している暇があったら、現実を見て問題を明らかにし、解決に向けて取り組みましょう。次のスプリント以降、ベロシティが毎回20%づつ向上していけば間に合う、なんて考えてもそんな奇跡は起きません。

6. Howはメンバーに任せる

プロダクトオーナーが（自称）技術に詳しいと、プロダクトバックログを技術的な観点で書いたり、実現方法の詳細を示したりしがちです。ですがHowのプロは開発チームです。さまざまな経験やスキルを持った開発チームに任せれば、プロダクトオーナーが考える方法よりも良いやり方が見つかるのは自然なことです。プロダクトオーナーは開発チームにHowを指示する暇があったら、ユーザーや顧客、関係部署などのステークホルダーとの会話に時間を使いましょう。開発チームと話す方が楽かもしれませんが、それだけでは不十分です。

7. 意思決定は素早く。多くの意思決定はやり直せる

全部の情報を集めてから意思決定したからといって正しい判断ができる保証はありません。また全員の意見を聞いて合議制で意思決定したからといって、それがあっているかはわかりません。多くの仮説はプロトタイプやユーザーインタビューなどを使うことで素早く検証可能です。つまり意思決定に時間をかけてその間なにも学習しないような状況を避けて、繰り返し学習を続けるようにしてください。

8. 情報はオープンにする

プロダクトオーナーが、「私考える人、あなた作る人」のような思考をしていると開発チームのモチベーションは低下します。情報をオープンにして、開発チームと一緒に考えてください。ステークホルダーの情報をフィルタリングしたりサマリーしたりして渡すのではなく、生の声が手に入るようにしてください。ときには開発チームのメンバーを顧客やステークホルダーのところに連れて行くのもいいでしょう。またプロダクトの指標、経営からの指摘なども共有してください。

9. Noをきちんと言う。八方美人をしない

プロダクト開発では、いつもやりたいことがたくさんあって時間は足りません。限られた時間のなかで最大の成果を出すには、価値が低いもの、プロダクトの本質と外れるものをやらないようにしなければいけません。つまり顧客や上司、経営者などからさまざまな要望、要求、命令があったとしても、プロダクト全体として考えた上でときにはNoと言わなければいけません。ステークホルダーの要求をすべて開発チームに流し込みつつ、開発チームに対して「また無茶を言ってきた」のように言って自分が被害者かのようにふるまうのはやめましょう。Noを言うのはプロダクトオーナーの重要な仕事です

10. ときにはプロダクトやプロジェクトをやめる決断をする

プロダクトやプロジェクトで開発を進めていると、ときにはこのまま進めても良い結果が出ないのではないかと気づくことがあります。これはステークホルダーからのフィードバックやさまざまな指標に兆候があらわれます。不確実性の高い状況では、毎回うまくいくとは限りません。こんなときに、そのまま続けてしまうと貴重な時間やお金がどんどん失われていきます。そのような浪費を避けるのも成功と捉えて、ダメそうなものはやめましょう。いままでかけた時間やお金が勿体ないというサンクコスト思考は問題をさらに大きくしてしまいます。

ここで紹介した10個はあくまで最低限気にしておくべきことです。これ以外にも日々気をつけなければいけないこと、やらなければいけないことはたくさんあるでしょう。ぜひ、工夫しつつ楽しんでプロダクト開発を進めてください。

それでは。