プロダクトマネージャの仕事を半分ほど読んで、学びになったことがあったのでメモを残す。前回記事。今回は、コミュニケーションについて。
小さくコミュニケーションをとることのメリット
5章より
これをやらないとどうなるか。例えば、ある機能を作るための仕様を自分で考えレビューしてもらうとする。そこには自分の考えたさいきょうの機能案がある。大々的にお披露目した結果、自分では理解・把握できていないコンテキストが露呈されやり直しとなった。構想に対して個別に相談にいって仕様の選択肢を増やしたり、懸念を無くしていくことが抜け落ちている。この作業無しに全部まとめて提示してもみんなどこにフィードバックすればいいのかわからないのだ。そのため、小さくコミュニケーションをとってある種時間を犠牲にして洗練された仕様や作る理由を構築する。
私はフィードバックする側として大きなやりたいことに対してレビュー?する側として参加したことがある。そのときもやはりこの現象と同じで、やりたいことに対して確信を持って Go とは言えないフワフワした感じがあった。どうしてか考えてみると、いくつか要因があったと思う。
-
やりたいことの共有が主で、参加者がどうリアクションすればいいか不鮮明。
- 参加者としてフォローすればよかったが、何か決める場なのか、アイデアを出す場なのかはっきりしていなかった。趣旨がはっきりしていないと参加者としては余計何を考えて発言すればいいかわからないし、人数が多いとさらに発言もしにくくなる。こういうミーティングだと感じたらまずどこまでできれば目標達成できるのか認識合わせをこちらから仕掛けないといけない。
-
情報量が多い。
- 冒頭5-10分くらい話されてしまうと何を話すべきかわからなくなってしまうことがある。事前に事前にミーティングの趣旨があったとしても長いストーリーを聞いているとこの情報は必要なのかとか考えてしまう。丁寧に説明していただけるのはありがたいのだが、受動的に聞く情報量が多いと参加者と主催者の知識差も感じることになって溝が生まれてしまうような気がする。温度感の違いを生むというか。対策としてはやはり、情報量が多い場合は事前に読み込みを行ってもらうことが重要かと思う。一度読んで、考えてきてもらうことで知識の隔たりが軽減され、ミーティングのときに意見が出しやすくなるはず。ステークホルダは忙しいので、当日に目線合わせを行いやすくするために事前に短時間ミーティングするなど強制でインプットしておくといいかな。
どちらかというと、1度にインプットする情報が多いとミーティングとしては機能しにくいと思っている。その場(短時間)で多くの情報を自分で整理して、わからない点を質問して確かな理解にするのは難しいから。また、ミーティング主催者は何かアウトプットがほしいという反面、参加者はまずはキャッチアップで精一杯という構図が温度差を生みそう。繰り返しになってしまうが、だからこそ情報をたくさん集めたり整理する過程で他の人の意見も聞いて小出しにして積み上げるのが遠回りのようで王道なのだと思った。集めた情報を誰かに伝えないとある意味その人の中での在庫となってしまい、抱えすぎるのはよくなさそうである。The Goal を読んだばかりなのでこういう発想になってしまいがちだがそこまで間違ってないとは思う。大きい情報を小さくすることで人間が理解するためのバッチサイズは圧縮され、理解のスループットが上がり、素早い意思決定とフィードバックサイクルが回せるのではないか。
大きいミーティングでみんながうーんという雰囲気を味わったことがあるので、この章で扱うトピックは痛いほどわかったという話と今後の対策を考えてみた。