プロダクトオーナーとして開発チームと情報共有する際に注意していること

この記事はProduct Owner Advent Calendar 2015 23日目の記事です。 22日目はjoytomoさんによるPOなき開発現場のプロダクトオーナーシップでした。

（前提）SCRUMにおけるプロダクトオーナーと開発チームの役割について

私は普段、SCRUMで開発をしているチームのプロダクトオーナーをしています。プロダクトオーナーはwhatの担当で、情報収集してプロダクトバックログにアイテムを追加したり、優先順位を最新化したりすることが主たる役割です。開発チームはhowの担当で、プロダクトバックログの内容を実現するより良い方法を考えたり、実際に作ることが役割です。

また、別の言い方で、プロダクトオーナーは投資対効果を最大化することが役目、という説明を受けたことがあります。つまり、有限な開発リソースの中で最も効率の良い（プロダクトを目指す方向に成長させる）whatを選ぶことが重要になります。

そのためにプロダクトオーナーに必要な能力として、1番は決断する力、2番は情報収集する力だとスクラムマスター研修で教わりました。

スクラム　仕事が４倍速くなる“世界標準”のチーム戦術

プロダクトオーナーと開発チームの情報差による認識齟齬

最近思うこととして、プロダクトオーナーは情報収集が仕事なので色々な情報を把握できますが、それを全て開発チームに伝えることは難しく、結果、情報の差が出やすいな、ということがあります。

そのため、プロダクトオーナーとしては、情報収集して考えて出した結論でも、開発チーム側からすると結論だけ言われても納得できない、もしくは、プロダクトオーナーが意図した内容と異なる内容で理解してしまう（誤解してしまう）、という状態が生まれやすいのではないか、と考えています。

もちろん、そこがプロダクトオーナーの技量、ちゃんと要点をまとめて伝えることが大事、みたいな話はあると思うのですが、私自身、結構頑張って伝えているつもりでも齟齬が生まれる時があり、どう改善したら良いかなと悩んでいました。

いました、というか今でも悩んではいるのですが、ある程度考えたことがあるので、その内容を以下に書いていきます。

まずはプロダクトバックログ大事

改善の対象として真っ先に考えるのはプロダクトバックログかなと思います。プロダクトバックログにはユーザーストーリーを書くのが大事、とか、INVESTが大事、とか言われます。こういうことが出来ているか再確認する（振り返る）ことがまずは大事なんだろうなと思います。

それ以外で自分で気をつけたこととして、あまり固い文章で書くのを辞めて、出来るだけ思いや感情を書くようにしました。

例えば、

Aという機能を実装する。
KPIは3%程度改善する見込み。

と書かれるより、

Aという機能を実装します。
KPIは3%程度改善する見込みですが、
不安要素もあるので、ちょっと怪しいです。

みたいに書いた方が、温度感が分かりやすいかなと考えています。

コンテキスト共有が大事

プロダクトバックログももちろん大事なんですが、どうしても書き漏れてしまうこととか、この書き方で理解されると思ったのに駄目だった、みたいなことは出てしまいます。というか、ちゃんと読み手が理解できる文章を書いていくのは本当に大変だと思います。

これを改善するのには、普段からコンテキスト共有していることが大事だと考えています。自分が何を考えているとか、どういう情報を得たとか、判断に影響する内容を、判断する前から共有しておくことが大切になります。

例えば

鈴木さんは案1が優れていると考えていて、佐藤さんは案2が優れていると考えているとします。プロダクトオーナーは案1と案2の優先順位を考えなくてはいけなくて、最終的に案2を優先することに決めました。

このとき案1が優れていると考える鈴木さんに説明する方法として

• 客観的なデータにより優劣を示す
• 定義した判断軸による評価結果を見せて説明する

などが考えられると思います。ただ、実際には、これでは鈴木さんが納得出来ないケースも結構な数あるのではないかと思います。（データの取得方法が違うとか、評価結果が間違っているとか）

一方で、鈴木さんが案1、佐藤さんが案2を選ぶのは、それぞれ立場が違うので優先するものが異なっているためで、実際プロダクト全体で考えても差はほどんどなく（どちらも大事で）、プロダクトオーナーとしては優劣を決めづらいというようなことも多いと思います。

こういうとき、両者の立場をしっかりを理解した上で判断していることであったり、どちらの案も甲乙つけがたい状態での決断であることなどが理解されている状態にすることも大事だと考えています。（具体的に何を共有するべきかはチーム文化によって変わるとは思いますが）

普段から共有していることが大事

両者の立場を分かった上で判断しているよ、と判断後のタイミングで急に言っても胡散臭いだけな気がします。なので、出来れば、このような情報は判断が必要に必要になる前から人となり・キャラ・価値観みたいな形で、普段から開発チームに把握されていた方が良いと思います。

やり方として分報がお薦め

以前、Slackで簡単に「日報」ならぬ「分報」をチームで実現する3ステップ 〜 Problemが10分で解決するチャットを作ろうという記事が話題になったことで、これを真似て（idobataなので）個人のroomを作り、そこに自分の考えていることをどんどん書き込むようにしました。

これが想像以上に良くて、言語化しにくいのですが、阿吽の呼吸のような何となくわかる状態になります。

もちろん、最終的にはプロダクトバックログアイテムをしっかり作ることが大事なのですが、普段考えていることや大事に思っていることが開発チームと共有できるようになり、意思疎通をスムーズにしたり、書き漏れた際にも分かってもらえているセーフティネットのような役割になってくれたりしています。

また、同時に開発チームにも個人のroomで書き込んでもらっているので、認識齟齬が生まれたことが開発チームの発言からでも察することができます。

あとは、分報に限らず、プロダクトオーナーとして情報をアウトプットしていくことが大事だと思いますので、プロダクトが抱えている課題についてQiita:Teamの記事を書くとか、社長ラジオのプロダクトオーナー版、なども有用かな、などど考えています。（この辺りはまだ未実施です）

---

Product Owner Advent Calendar 2015　残り2日間はまだ空席となっておりますので、どなたか是非投稿をお願いします！！

Fearless Change アジャイルに効く アイデアを組織に広めるための48のパターン