プロダクトオーナーと開発チームのギャップを埋める(Scrum Masters Night!の参加記録メモ)
はじめに
こんにちは。
IT企業でスクラムマスターをしている@rilmayerです。
今回、Scrum Masters Night!に初参加したので、そこでの学びなどをシェアしたいと思い記事を書きました。
（当日はfurufuruと名乗っていたものです。）
Scrum Masters Night!
Scrum Masters Night!はいくつかの法人から集まった有志の方によって運営されているイベントで、オープンスペーステクノロジー(OST)と言う会議運営手法を用いている、スクラムマスターのための、スクラムマスターによる課題解決型イベントです。
OSTと言う会議運営手法は以下のスライドで概要を掴めます。
当日はOSTの手法に沿って、以下のような流れで進んでいきました。
1. ディスカッションテーマ投票・決定
2. ディスカッション開始
3. 各ディスカッションの共有
4. 振り返り、クロージング
様々なディスカッションテーマが提案され投票の結果以下の3つのテーマが取り上げられました。
・POと開発メンバーのコンテクストや理解のギャップをどう埋めるか
・いわゆるTryと言われるものの扱い。たまりがち。
・Jiraなどプロジェクト管理ツールどこまで使ってるか（バーンダウンチャートなどのレポート、エピックとか）
そのほかにも「リモート状況下でのスクラム開発」、「ジュニアプログラマーの育成」、「プロダクトロードマップの作り方」など非常に興味深いテーマがたくさん出ていました。
各テーマについてのトークルームが作成され、それぞれのトークルームに興味のある人が参加し議論が進められていきました。
実際のディスカッションですが、これが非常に進めやすかったと思いました。
よかったと思うポイントがみなさんリモート参加だったため、ホワイトボードツールとしてmural、会話ツールとしてDiscordが利用されたのですが、まるで会場をフラフラと移動する感じで利用できてとてもよかったです。
（自分は一つのセッションに張り付いていましたが。笑）
今回は自分が張り付いていた1つのセッションで議論した内容について紹介しようと思います。
POと開発メンバーのコンテクストや理解のギャップをどう埋めるか
まずは参加した人たちがどのような課題感を持っているかと言うことを話しました。（なお、以下の議論で登場するプロダクトオーナー、開発チーム、スクラムチームについてはこちらの記事が詳しいです。）
このテーマについては、私自身課題感を持っていたため、コンテキストを含めて「今こんなことで困っているんだ」と言う話をしました。例えば以下のような内容です。
筆者が感じる悩みポイント
・プロダクトオーナーは様々なステークホルダーと話しながらROIを元に意思決定しているが、そういった部分について開発メンバーが見えていない部分があったりしてコミュニケーションが齟齬る
・逆に、開発メンバーの持つ固有なドメイン知識についてプロダクトオーナーが見えていない場合があり、開発メンバーがプロダクトオーナーの意思決定に反対した時にうまく合意形成ができない場合がある
・開発メンバーが長期的に達成したいと思っていることと、プロダクトオーナーが長期的に達成したいことにギャップがあるために、両者のモチベーションが下がってしまう気がする
その他参加者からも似たような課題感があると言うことで、以下のような内容を聞くことができました。
・プロダクトオーナーのプロダクトに対するコンテクストが開発メンバーとシェアできていないために、互いにどう関われば良いか互いにわかにくい
・何を作るか考えてる人たちと、どう作るかを考える人たちが分断されており、完成後に「こんなんじゃなかった・・・」となってしまう
などなど
そんな時はみんなどうしてる？
次にそんな状況に陥った場合はどうしてるのかといったことを話しました。ディスカッションでは以下のような対処をしているといった意見が出ました。
POと開発チームの考えにギャップを感じたらどうする？
・POと開発チームのMTGの設定し、間に立ってファシリテーションする
・POがプロダクトの背景を開発メンバーに説明できる機会を作る
・スクラムチームの各人がどんな期待を持っているかを明らかにして、ギャップを見えるようにする
・スクラムマスター対各開発メンバーで1on1して各々が持っている各開発メンバー及びプロダクトオーナーに対する期待値を調整する
・POの話た内容を開発チーム向けに噛み砕いて再度説明
・単純にコミュニケーションの量を増やせるようにする（フリートークの施策など）
・POと開発者が喋っているのを横から客観的に見て状況をきちんと理解する
セッション参加者から、実際にこんな場面に出くわした時の様々な対処方法など知ることができました。もちろんこれら行動はコンテキストによって効果があったり、逆効果になったりすることはあるのですが「こういうこともできるのか！」と言う学びが多かったです。
また、実際に「ギャップがある！」となってしまう前にお互いのコミュニケーションを促して、対立が生まれる前に対処しておくという高度なことをしている人もいるようでした。自分もそうなりたいと思ったりするのでした。
こうした議論を経て、特に「チームメンバーの期待値を合わせるのって大事だよね」と言う話になり、セッション参加者の方から以下のプラクティスを紹介してもらえました。
ドラッガー風エクササイズ
ドラッガー風エクササイズは以下のような質問に答えていく中でチームメンバーの期待値を可視化する方法です。
・自分は何が得意なのか？
・チームメンバーは自分にどんな成果を期待していると思うか？
・他のチームメンバーに期待することは何か？
こうした活動を通して期待値のすり合わせができるそうです。
また、以下のような形で進めていくこともできるようで、実際に試したら結構楽しそうだと思いました。
開発者とスクラムマスターの兼任は難しい
上記のテーマについてある程度まとまった話ができ、最後にちょこっと開発者とスクラムマスターの兼任について議論もすることができました。
自分は現在、開発者とスクラムマスターを兼任しており「対開発チーム」と「対プロダクトオーナー」と会話する時にどのロール（スクラムマスターか開発チームか）で会話するかを意識している話をしました。
そうした話の中で、兼任でうまく働いていると思っている時、「開発チーム」もしくは「プロダクトオーナー」がスクラムマスター的な働きをしている場合があるかもと言う話が出て、これが個人的に刺さりました。
こうした状況の場合、プロダクトオーナーや開発チームが100%自身のロールに専念できていないかもしれないのです。（スクラムマスターとして頑張りたいものだ・・・
より、プロダクトオーナーがプロダクトオーナーの仕事を、開発チームがより開発チームの仕事を、それぞれ集中して最高の成果が出るようにこれからもサポートしていきたいと思うのでした。
セッションの終わり
そうこうしているうちにディスカッションの時間が終わり、それぞれのセッションの内容が各ファシリテーターかまとめられていき「なるほど隣のセッションではこんな話をしていたのか」と理解していくことができました。
最後に次の会のためのフィードバックを参加者全員で行いイベントは御開きとなりました。
おわりに
個人的には参加して本当に良かったと思いました。
同じスクラムマスターとして頑張っている人がいることに勇気付けられた面もありますし、様々な角度から現状をより深く分析できるようにもなりました。
また新たな視点も得ることができとても学びが深かったです。
他の方の課題に対しても処方箋が出せるようにこれからも勉強とトライアンドエラーを続けていきたいなと思います。
イベントを主催してくださった有志のみなさま、ありがとうございます。
この記事が気に入ったらサポートをしてみませんか？