プロダクトマネージャの仕事を半分ほど読んで、2 点学びになったことがあったのでメモを残す。1 点目でボリュームがあったので 2 点目は次の記事で。
1. Disagree and Commit に対する誤解
自分の理解が浅かったという話。自分の理解は、ある事柄を進めていく際、提案した何らかの方法で任せてもらえる用にするための合意形成のプロセスだとしていた。そのため、自分の使い方としては開発 Go をもらうためにミーティングを開いて複数の提案を行うということだった。なので、多くの時間は用意した資料を自分が説明し、質疑応答するということで自分が話す割合が多かった。これで大きな問題もなく物事を進めていたが、潜在的に何が悪いのかが紹介されていた。具体的には、「プロダクトマネジメントの世界では、はっきりとした承認、明示的な賛意でないものは、驚くほど危険です。その曖昧な注意を払っていない非明示的な賛意の例としていちばんに上がるのが「よさそう」という反応です」 と書かれていた。整理をして選択肢を提示して議論をしているものの、よさそう止まりのミーティング参加者はいるのではないか。自分も提案する側でないときはよさそうで済ませてしまっていることもある。
そこで本書で紹介されていた詳細なプラクティスを取り入れたほうがもっとよい意思決定とその後の開発ができると思った。本書では集団での合意形成の際には、参加者全員の「進めてよい」と積極的なコミットメントが必要。コミットメントのプロセスでは、そうしなければ語られなかったはずの質問、懸念、反対意見を引っ張り出さなければいけません。 と紹介されていた。(正確には Intel で始まった文化の模様)
自分ができていなかったのは、質問、懸念、反対意見を引っ張り出さなければいけません ということ。承認をもらうことが目的になってしまっていた節があるので、もっと対話や議論で案を洗練する必要があると思った。そうしないとよいプロダクトの進化につながらないし、どこかで反対意見を差し込まれたときにロールバックが大変になる可能性があるから。
ではどう進めるかというと一例として
「チームにとって大きな決断事項なので、ここにいる全員がすべての情報を共有していることを確認しておきたいのです。これから1人ずつお尋ねするので、このやり方で進めてよいなら『コミットする』とお答えください。コミットできない場合は、その理由をお話しください。そこからどうできるかを考えましょう」
と前置きをし
「今回のゴールは、質問や懸念点があったら共有することによって、できる限り良い判断を下すことです。確信がないのなら、『はい』と言わなくて大丈夫です」
と話すことで No に近い意志や今のままだと進めにくいという意見を拾いやすくする。
懸念事項がでたらそれについて検討する。自分たちで判断できそうであればその場で議論すればいい。懸念がその場で解決できない場合は、いつまでに解決できそうか、誰がその懸念を扱うかを決めて持ち越す。次の会のときは必要に応じてメンバーを集めればよさそう。持ち帰ったモノによっては全員で確かめる必要がないと思うため。
また、そのほかの tips を紹介する。
-
コミットしてくれなかったら、成功基準を設定しまたあとで判断できるようにする
- コミットしないのは、参加者が真剣に考えてくれている結果なので良い兆候。ただ前に進むために判断材料を探しにいく必要がある。ここのゴール手順を設定するのも難しそうではある。
-
沈黙は不合意として扱う
- 多くのミーティングでは沈黙を暗黙の合意として扱う。自分も特になければ終わりますでクロージングしがちである。Disagree and Commit では 積極的なコミットメントしか 合意としてみなさない。なので、沈黙していたら合意したことにならないと話し、考えや懸念点を話してもらう。ミーティング主催者として居心地は悪いかもしれないが、良い意思決定のために意見をなるべく引き出せるように聞く姿勢をもつようにする。