停滞を越えて、再び合流へ。「象・死んだ魚・嘔吐」がつないだチームとPOの関係｜ABEJA Tech Blog

こんにちは、ABEJA でスクラムマスターをしている小川です。
この記事はABEJAアドベントカレンダー2025の22日目の記事です。

今回は、プロダクトオーナー（PO）との関わり方を模索する中で、チームの動きが一時的に噛み合わなくなっていた時期を振り返ってみたいと思います。

補足として、この記事で登場する役割について簡単に整理します。

プロダクトオーナー（PO）：プロダクトの価値最大化に責任を持ち、何を作るかをチームと共に考え、意思決定する役割
スクラムマスター：チームやPOがスクラムをうまく活用できるように支援し、対話や改善の場を整える役割

本来、レトロスペクティブはこの両者と開発者が揃い、「どうすればより良いプロダクト作りができるか？」をスクラムチームで振り返るための場です。しかし当時の私たちのチームでは、その前提が少しずつ崩れていきました。

「最近、レトロスペクティブが盛り上がらない」「POへの不満はあるけれど、その場にPOがいないから何も変わらない」「もう諦めてしまっている...」

もし、そんな空気に心当たりがある方がいたら、私たちのチームの経験が、何かのヒントになるかもしれません。

1. チームを覆っていた「学習性無力感」

当時の私たちのチームでは、「レトロスペクティブで改善の話は出るけれど、どこか手応えがない」そんな小さな違和感が重なっていました。

一つひとつは些細に見えるものの、それらをうまく言葉にできず、整理もできない。そんな状態が続いていたのです。

ある期間、レトロスペクティブの進め方が定まらず、改善の議論は行われているものの、どこか手応えのない状態が続いていました。

「仕様が曖昧だよね」「もっと早く相談してほしかったよね」そんな課題が頭をよぎっても、

「POは忙しいから、今は声をかけるべきではないかもしれない」「決断が必要な話題だから、慎重になった方がいいかもしれない」

そんな“配慮のつもりの遠慮”が、少しずつチームの中に積み重なっていきました。

そんな空気がチームを支配し、次第に誰も口に出さなくなっていったのです。

今振り返ると、こうした状態はチームの学習や対話のエネルギーを少しずつ弱めていたように思います。当時は違和感はありつつも、それを明確な課題として捉えきれていませんでした。

2. 劇薬「象・死んだ魚・嘔吐」と、安全装置

こうした「言葉にできない違和感」をそのままにしないために使ったのが、「象・死んだ魚・嘔吐」でした。

📝「象・死んだ魚・嘔吐」とは*1

🐘 象：みんなが見て見ぬふりをしている大きな問題
🐟 死んだ魚：放置されて悪臭を放つ過去のしこり
🤮 嘔吐：今ここにある、吐き出したい感情

これは非常に強力な手法ですが、一歩間違えると「誰かを責める場」になりかねない劇薬でもあります。

そして、何より私が大切にしたかったのは、「問題 vs 私たち」*2 という構図でした。

だからこそ、実施前にはかなり時間をかけて、参加者に以下の安全装置の理解を徹底しました。

「その時点において、最善を尽くしたと信じる（Prime Directive*3）」への合意や、「事実・行動・影響（SBIモデル*4）」で話すルールの徹底。 「これは誰かを責める会ではない。私たちが次に進むために、膿を出し切る手術なんだ」 というセットアップを丁寧に行うことで、ようやく私たちは「象」や「死んだ魚」と向き合う準備が整いました。

このセットアップを経て、「象・死んだ魚・嘔吐」を、いつも通りPO不在のレトロスペクティブで実施しました。

振り返りの中で改めて言語化していくと、私たちが当たり前のように受け入れていた「POがレトロスペクティブに参加していない状態」そのものが、大きな「象」だったことに気づけたのです。

3. スクラムマスター単独での「特攻」、そしてPOの本音

「象・死んだ魚・嘔吐」では、POとのコミュニケーションに関するペインや生の声が数多く出てきました。

しかし、私たちのチームは根が優しく真面目です。「これをこのままPOにぶつけたら、集団リンチになってしまうのではないか？」という懸念の声も挙がりました。

そこで、まずはスクラムマスターである私が、まずチームの声を預かり、POと1on1で話すことにしました。

正直、かなり緊張しました。
それでも腹を割って話した結果、返ってきた言葉は意外なものでした。

プロダクトオーナー 「もっと、意見を言ってほしかった」

POもまた、開発者から意見が出てこないことに孤独とペインを感じていたのです。

「言われた通りに作るだけになっていないか？」「もっとプロとして突っ込んでほしい」。

互いに相手を気遣い、遠慮し、その結果として溝ができていたことがわかった瞬間でした。

スクラムマスター 「じゃあ、そのための場所を作りましょう。レトロスペクティブが最適です」

そうした流れの中で、気づけばPOと腰を据えて振り返る機会が減っていたことに、改めて向き合うことになりました。

4. 再会、そして「共同戦線」へ

そして迎えたPOも参加したレトロスペクティブ。
そこには、以前のような「諦め」も、心配していた「対立」もありませんでした。

あったのは、「どうすれば良いプロダクトを作れるか」という健全な議論でした。

レトロスペクティブには、チームの変化が如実に表れていました。

💡 実際のディスカッショントピック例

課題の結合
- 技術的な内部品質とPBI品質が、別々の問題ではなく繋がっていることを全員で言語化して共通認識を持った。
仕組みでの解決
- 「事前Sync」や「調査タイム」といった小さいけど確実に遂行できて具体的なステップをチーム全員で考えて、POが「What」を、開発者が「How」の精度を高めるプロセスに合意した。

POからは「ユーザー体験の表現をシンプルにする」という改善案も出され、開発者からも「技術的負債へのアプローチ」が出される。一見役割は違いますが、それは「良いものを届けるための共同戦線」が張られた証でした。