もう二度と目覚ましのアラームを無視する愚挙は繰り返しません。ちゃんと7時に起きました。

チームの共通理解を深める

方向性を見失っているチーム

プロダクトオーナーの思いつきのような判断で開発対象の機能が決まっていく。

「これは経営サイドの優先度が高いものだ」という殺し文句が出るとそれ以上何も言えない。

　プロダクトオーナーとしてユーザの離脱を何とかしないといけない思いから新機能の追加を急いでおり、経営判断として機能追加が現場に降ってくる状況ですね。なんとなく親近感を覚えるのはなぜでしょうか。

　「経営判断だから」と一方的に言ってしまうと「なぜ」その機能が必要なのかの判断に至った経緯が共有されず、開発チームも漠然とした思いで開発していくことでしょう。

プロダクトオーナーからの新たなプレッシャー

「昨日、経営との会合があったのだけど、経営サイドからタスク管理にボットを組み込んでみたいというオーダーが上がった。」

「これ以上の議論の余地はないよ。どんなボットサービスを使うといいか、調査から始めてください。」

　😇

　経営判断として本当に顧客のためになっているのか分からない機能が降ってきてますね。

　チーム内からも以下のセリフが出る始末。

「このツール、一体どこに向かっているんでしょうねー。」

　そんな状況なのでパフォーマンスも上がらず、「開発本当にやってるの？」「やってるわ！」なんて小競り合いも起こってしまっています。

「スプリントを中止します。」

　スクラムガイドに載ってる通り、プロダクトオーナーによってスプリントが中止されてしまいます。理由は「プロダクトオーナーの方針とチームの考えのズレに向き合うため」です。

　私自身は今のところスプリント中止に出会ったことはないです。その場での補足話を聞く限り、やはり中止となるとそこそこ大事みたいですね。

（中止に出会ったことは無いのはスプリントをうまく運用できていないから……）

チームでプロダクトについての理解を合わせよう

プロダクトオーナーと開発チームが一緒になってスプリントごとの成果をながめる場をつくることから始めた。

上記の取り組みによって、透明性に課題があることが判明します。

チームが何についてどう活動しているのかがまったくみえず、かなり透明性が低い。その見えなさ加減が信頼感の情勢を阻んでいるところがある。

チームの外側に対する透明性もまた確保できなければ、チームはその外側との関係性をうまく構築できず、壁にぶち当たってしまう。

　私自身が割と「なぜ作るのか」「なぜ必要なのか」を重要視して開発をするタイプなので透明性の話はすごく理解できます。ただ解消となるとすごく難しく、外側のチーム毎求めている情報が異なるのでコミュニケーションコストがどうしても高くなってしまい、結果後回しにされたり、小さく始めても長続きしなかったりする経験があります。その辺りを仕組み化したいと考えてもどうすればいいのかいい案も浮かんできていません……。

　次に「ユーザのために何が必要なのかについてお互いの理解を深めていくようにしたい」とプロダクトオーナーと開発チームの共通理解を得るために「仮説キャンバス」を用いていました。

　「仮説キャンバス」は「リーンキャンバス」に目的とビジョンを付けてカスタマイズしたものでしょうか。その仮説キャンバスをプロダクトオーナーと開発チームで進めていっていたのですが、

「もう、このミーティングやめよう。」

　えっ。

　「よくわからん」「片づけたい課題の幅も広い」「どんなユーザーがこのツールを使っているのか、見たことがない」このような会話が続けられた末にミーティングが解散してしまいます。大丈夫かこれ！？

プロダクトチームには無数の分断が生まれる

　3つの分断が挙げられています。
✔ 開発チーム内部の分断
✔ 開発チームとプロダクトオーナーの間での分断
✔ 開発チームとPOを合わせたプロダクトチーム（あるいはスクラムチーム）と、その外側の分断

　各チームが自分たちが見ているところしか見ていないと、このような分断がおこります。かといって他のチームの状況を見ようとしても見えなかったら見えません。それによって分断が生み出されることは容易に想像できます。

　そしてこれらの分断は突如発生してしまうことがあります。プロダクトが形になっていく過程でお互いの理解や期待は変わっていくためです。ただそれは悲観することではなく、プロダクトを通じて新たな発見を得て学べる機会でもあります。大切なのはそれらの状況を検知し動けるようにしておかなければならないことですね。「チーズはどこへ消えた？」を思い出しました。

チームの共通理解を深める3つの原則

「透明性が高い」とは、チームの活動の中で何が起きているのか、プロダクトはどのような状態になっているのかという把握が容易になっている状態の事だ。
　逆に「透明性が低い」とは、知りたいと思ったことを把握するのに何かと調べたり、情報にたどり着くのに手順が多かったり、人に聞いて回ったりする必要があったりと、時間を要してしまう状態のことである。

　人に聞きにくい状況は心理的安全性が低いとも言えますし、チームのコミュニケーションにも問題があることが推測できますね。

　透明性を高め、さらにチームの共通理解を深めるための3つの原則
✔ 見える化
✔ 場づくり
✔ 一緒にやる

　例えばドキュメント化されていない「Why」については、知ってる人と知らない人がペアになって、「今から1時間で『Why』をドキュメントにまとめます！」と宣言して、「こんだけできた！」「やったね！」「ありがとう！」「そうだったのか！」みたいな活動はありですね！

　またビジネスサイドの人が「Why」を持っていたりするので、モブプロに招いて一緒に開発するのもいいですね。

共通理解を深める具体的な作戦＜開発チーム編＞

　ここでは上記で挙げたモブプロを含んださまざまな作戦が挙げられています。あの有名なバーンダウンチャートもあります。割込みタスクのせいで変なグラフになっていてもそれを見える化することが大事です。

共通理解を深める具体的な作戦＜プロダクトチーム編＞

　バリューストリームマッピングや MMF(Minimum Marketable Feature) は初めて聞きました。　MMF は実際にユーザに使ってもらい、立てていた仮説が妥当であったかを評価する施策だそうです。使ってもらってナンボ。

　あとプロダクトチームとして「一緒にやる」ことの重要さも説いています。後でチャットで聞くなどは時間が掛かるし意図が伝わらない可能性もあるので。

情報の解像度の上げ下げをマネジメントする

　開発チームは実装面に詳しく、プロダクトオーナーはビジネス面に詳しいので、お互いの専門分野が異なりプロトコルがかみ合わないでしょう。そのため自分が分かってるから相手もわかっていると思わずに、情報の解像度を適切に揃える工夫や、情報をつくっていく過程をともにすることで乗り越えていきましょう。

自分たちが何を知っていて、何を知らないかを知る

　無知の知！

　来週の第8話で第1部が終わり読書会もそこで終わる予定っぽかったみたいですが、第2部以降も読書会続けて欲しいです！

　チャットで参加者同士が自分たちのチームの課題を話し合っているのを見て、素晴らしい場を提供してくれているのだと実感しました！　本当にありがとうございます！