スプリントレトロスペクティブでなぜチームの開発がよくならないのか？〜よい答えはよい問いから生まれる〜
この記事はふりかえりアドベントカレンダー2025裏 Advent Calendar 2025の1日目です。
明日は ktnyt さんです。
前書き
「スクラムやってるけどチームの開発がよくならないよ〜」 という声をよく聞きます。
何しろ私の過去の現場ではよく聞きました。
その点を反省しまして、スクラムマスターとしてスプリントレトロスペクティブでチームの開発をよりよくするために中間ゴールという概念を導入したのですがなんでそんなことをしたのか、という話を言語化していきたいと思います。
アジャイルにおけるゴールの設定の仕方であるオニオンモデルに基づいて中間ゴールを設定しています。
本文
「スクラムを始めたから1年経ちます」
「最初はよかったんですけど、途中から全然チームの開発がよくなっている感じがしないんです」
「うちはスクラム開発やってます」というチームでよく聞くセリフですね。
「毎スプリントごとに改善アクションを決めているし、実行できているはずなんですが……」
こう続けるチームもいるでしょう
なぜチームの開発がよくならないのでしょうか？
考えられる理由はいくつかあると思います。
- ふりかえり（レトロスペクティブ）を実施していない
- ふりかえりでよくするためのアクションを決めていない、改善のために行動していない
原因がこの2つのようなケースなら「よくなっていない」のも納得です。
しかしおそらくほとんどのチームでそうではないでしょう。
では何が原因なのでしょう？
今回の前提条件では以下の条件を満たしているものとして考えます。
- チームの開発をよくしたいと考えている
- ふりかえり（レトロスペクティブ）を実施している
- ふりかえりでよくするためのアクションを決めていおり、改善のためにアクションを実行に移している
なるほど間違ったことはしていないように思えます。
他にも可能性は考えられます。
2つ挙げるとすれば以下の通りです。
- 見当違いの方向に努力をしている（例：TOEICのスコアを上げるために毎日ウサギ跳びをしている）
- 努力の量が所要量に比べて少なすぎる（例：お腹のぽっこり感をなくすためにたった1日30分の運動を1週間だけ継続した）
なるほどそれも可能性のうちには入るでしょう。
しかし1年間も見当違いの努力をするほどチームは愚かなのか。あるいは1年間の努力ではよくできないほどチームの開発は難しいものなのでしょうか？
とりあえず今回はその可能性は除外しましょう。
ではなぜチームの開発がよくならないのでしょう？
よくなっていない＝本当に変化が起きていないのか
まず原因を考える前に、現状について調べてみましょう。
アクションを実行に移しているというのが今回の前提ですよね？
でも「チームの開発がよくなっていない」ということは何も変化が起きていないのでしょうか？
可能性は2つ考えられます。
1つは本当に何の変化も起きていないケースです。
アクションを実行するぞ！と決めるけどアクションを実行してどう変わったか？そもそも実行されたのか？を検証せずに、アクションを実行することを決定するところまでがゴールとなっている場合です。
それではチームの開発がよくなるわけがありません。
でもこんないい加減なチームはきっと少ないでしょう。
（そうですよね？ あなたのチームは違いますよね？）
もう1つは実際には小さな変化は起きているけど、小さすぎて「チームの開発がよくなっている」と思えないケースです。
「スクラムを始めたから1年経ちます」
今回のケースでは1年間スクラムをされているわけですよね？
1年間は52週あります。2週間スプリントなら26スプリント、1週間スプリントなら52スプリントが反復されています。
1スプリントにつき最低1アクションを実行しているならスプリントの数だけアクションが実行されているわけで、ということはそれだけの変化が1年前に比べて起きているはずです。
最低26だか52だかの違いがあるはずなのにメンバーが「チームの開発がよくなっていない」と感じるのはなぜでしょうか？
1年前と現在の違いを見てチームの開発がよくなっていないと感じるのはなぜでしょうか？
それはサイゼリヤの間違い探しのように、全体にはいくつもの違いがあるにもかかわらず、概して言えば「ほぼ同じ」だからです。
目標を決めずにリソースを投入しても意味がない
スクラムにおいてプロダクトの開発で「集中の原則」という言葉が使われます。
1チームのリソースが限られるため、数週間や数ヶ月という短い期間で結果を出すために我々はこの方向を目指す、とプロダクトのゴールを定めたらスプリントごとに「（プロダクトのゴールへと向かうための）中間ゴール」を定めてそこにリソースを集中させるのです。
つまり「限られたリソースを効率よく使うためにスプリント単位でチームメンバーの向きを揃えて同じ方向に投資し続ける」わけです。
逆に言えば今週はこっち、来週はあっちと移り気にリソースをばら撒いても、よく見れば細部に多少の変化は出るかもしれませんが全体として大きな変化は起きません。
そしてこれはプロダクトの進化だけでなくチームの進化も同様です。
チームがよくならないと主張されているチームは往々にしてチームのゴールか、中間のゴールを定めません。
ただ目の前にある選択肢の中からパッと目についた「なんかよさげなアクション」を毎スプリントで選択しているだけに過ぎません。
このやり方では実感できるよい変化がチームに起きるわけがありません。せいぜいできるのは「サイゼリヤの間違い探し」にすぎません。
そもそも「チームがよくなる」とはなにかを説明できるのか
「最初はよかったんですけど、途中から全然チームの開発がよくなっている感じがしないんです」
こう訴える多くのチームで「「チームがよくなる」とはなんなのか」と問うと統一された回答が返ってきません。
理由は簡単で「チームとしてどのような状態になるのが理想なのか？」についてチームで合意形成がなされていないからです。
それどころか「現状のチームはどういう状態なのか。理想の状態とのギャップは何か。そのギャップはなぜ生まれるのか？」について「チームで同じものを見ておらず」「それどころか言語化すらできていない」ケースも多々あります。
これは前述のプロダクトのゴールに相当する組織のゴールがはっきりしていないことと同義です。
これでは中間目標である「数スプリント単位での組織の改善のゴール」も設定することはできません。
スプリントのふりかえりごとに場当たり的に目についた改善アクションを設定して、次のふりかえりでそれが実行されたことを確認して「やってる感」だけ出すのが関の山です。
まず「チームがよくなる」と「我々は今どこにいるのか」を決めよう
ここについてチームメンバー全員の合意が取れないと話が始まりません。
理想と現実を知ることはアジャイルの基本です。
野中郁次郎先生だってシスティーナ礼拝堂を例に出してそう言ってます。
現実と理想を決めなければ、どこに足場を組んで「床（現実）」から「天井（理想）」に上がっていくかを議論することなんてできません。
理想と現実を定義せず、この2つについてチーム内で合意形成もせずに「チームをよくしたい」と語るのはまさに地に足がついていない考えと言えるでしょう。
理想を決めたら、次にどこを目指すかを決めよう
山に登るときに道から外れていたときに早めに気づけるように中間目標点を定めます。
同様に数スプリント単位で目指すべき中間ゴールを定めるべきです。
理想はあくまで理想でありそう簡単に辿り着けません。
スプリント単位のチームの改善が本当に理想につながっているかを確認するために、そして数スプリント単位で方向性をブラさないために中間ゴールを設定すべきです。
それができたら今度は中間ゴールを達成するための次スプリントでのチームの改善アクションが決められます。
これはふりかえりで議論すべき内容です。
スプリントが終わったら改善アクションは実施されたか？本当に中間ゴール達成に寄与したか、あとはなにができたら中間ゴールが達成されるのか？が議論できます。
中間ゴールがあるからこそ1つの方向に絞って改善を集中させることができます。
また次の中間ゴールに何を設定すべきか？の議論は理想に対する優先度の議論となります。
これはすなわちバックログの優先度の議論と同じ効果が得られます。
中間ゴールとは何か。ほかにどんなゴールがあるのか
アジャイルにおけるプロダクトの複数のゴールの話をしましょう
アジャイルにおいてはプロダクトのゴールについて最終ゴール、中間ゴール、スプリントゴールを設定するやり方があります。
オニオンモデルという言葉で表現されたりもします。
棲み分けとして
という差異があります。
この書き方だと中間ゴールとスプリントゴールの差異がわかりませんね。
スプリントゴールは1スプリントで終わらせなければいけないという制約があります。
しかし1スプリントで捻出できるリソースで実現できるUXには限りがあります。
プロダクトが中間ゴールで目指すべき姿には複数のUXの実現が含まれる場合があります。
この複数のUXの実現には1スプリントで捻出できるリソースでは不足することもあります。
そこでスプリント単位で検証するためのスプリントゴールと、リリースなどの単位で検証されるべき中間ゴールを設定します。
しかしふりかえりのアクションについてスプリントゴールは設定されません。
理由は後述します。
中間ゴールにもとづいてふりかえりで決めた改善アクションを決める
チームを最終的に持っていきたい理想の形が「最終ゴール」ならその過程としてチームが現在地から次に目指すべき場所が「中間ゴール」です。
中間ゴールを達成するためにふりかえりの中で改善アクションを探します。
もちろん中間ゴールに紐づかない、改善アクションが見つかることもあります。
スプリントの中で新しいことを始めると特に見つかりやすくなります。
この際に中間ゴールに紐づく改善アクションとそうでない改善アクション、どちらを選ぶかはチームに委ねられます。
なぜならどちらの問題の解消が価値が高いかはチームにしか判断できないからです。
またプロダクト改善においてスプリントゴールが設定されるのにチームの改善においてスプリントゴールが設定されないことには理由があります。
私が担当したチームでは主にチームのリソースの大半は機能を追加すること、UXを実現することについて費やされます。
するとスプリントにおいて改善アクションを打てる数には限りがあり、スプリントゴールを設定しても実現するほどの改善アクションが打つことが難しい。
あるいは限られた改善アクションで実現できるスプリントゴールを定めることには無理があるからです。
認識すべきこと： チームをよくすることはプロダクトをよくすることと短期的にはコンフリクトする
標題の通りです。
理由は有限であるチームのリソースを奪い合う関係にあるからです。
チームの改善が失敗する例として、プロダクトの機能追加にリソースを極振りしてしまい、チームの改善に手が回らないままに負債が溜まっていくケースもよく見ます。
しかし長期的にはチームをよくすることはプロダクトをよくすることに資することになります。
また逆もまた然りです。プロダクトがよくなれば経営陣やステークホルダーからの信頼を稼げるためチームの裁量が大きくなるからです。
そのためチームとしてはチームをよくすることとプロダクトをよくすること、そしてそれ以外のことで構成されるチームのポートフォリオをどうするか
さらに言えばチームをよくすることとプロダクトをよくすることをさらに細分化した内訳をどういう構成にするかを意思決定する必要があります。
細分化の例を出せば、プロダクトをよくすることは「機能を追加すること、プロダクト品質を上げること、学習コストを低下させること、運用コストを低下させること.... etc」などに細分化できます。
ポートフォリオを組む前にこの細分化の議論をチームでしてみるのもいいと思います。
またこの点を裏返せばスクラムチームを崩壊させるベストプラクティスも見えてきます。
過早な締切のプロジェクトを絶え間なく設定し、チームに過大な負荷を強いることでチームの改善を停滞させプロダクト品質を際限なく引き下げることができます。
まとめ
「チームをよくする」行為には「現在チームはどこにいて、最終的にどの状態にありたいのか？」という前提を決めること。
そして理想を目指すための中間ゴールの設定と中間ゴール達成のための改善アクションの設定と実施が不可欠です。
なぜならチームを改善するためのリソースは限られており、リソースを向ける先を発散させず散漫にしないように、一つの方向に向けて投入するようにしたい。
そうすることで中間ゴールによる改善の方向性や実現について検証と評価をすることができるからです。
スプリントレトロスペクティブにおいては以下のような「問い」が不可欠です。
- 「改善アクションは実施できたか、想定された効果はあったか、中間ゴール達成に寄与したか」
- 「中間ゴールは達成できそうか、中間ゴールの達成は理想への前進に寄与するか」
- 「中間ゴールの達成に向けて、次は何が達成されるべきか。そのための改善アクションは何か」
こうした「よい問い」があってこそ「よい答え」としての改善アクションや中間ゴールが出てきます。
前提も問いもなくしてただ漫然と改善アクションをこなすだけではチームはよくなりません。
また理想と中間ゴール、中間ゴールと改善アクションが実はリンクしていないのではないか、あるいは達成不能なのではないかという建設的な批判の目線は不可欠です。
スクラムの知識が浅いメンバーだけでチームが構成された場合、「単に毎回のふりかえりでKPTを実施して改善アクションを決めて実行していればそのうちチームもよくなるんじゃない？」という楽観的な考えのまま時間を浪費しがちです。
しかし時間をいくら使っても改善につながらない状態が長期間続くとメンバーのモチベーションが萎びてしまいます。
これを防ぐためにスクラムマスターとして、早期にチームが自走できる体制を作る。そのために時間をかけて理想と現実をチームで合意させ、中間ゴールを設定させるやり方を始めてもらいました。
蛇足：アンチパターン「ダイダロスの羽」
また理想と中間ゴール、中間ゴールと改善アクションが実はリンクしていないのではないか、あるいは達成不能なのではないかという建設的な批判の目線は不可欠です。
達成不可能な中間ゴールとはなんでしょう？
その点について語ってこの記事を終えたいと思います。
「鳥のように自力で空を飛びたい。具体的にはギリシャ神話のダイダロスの逸話に倣い、鳥の羽を蝋で固めて腕につけ、腕をバッサバッサと鳥のように羽ばたかせて飛びたい」
みたいなゴールを掲げているチームをよく見ます。
（ゴールとソリューションが密に結合していますが今回は目を瞑ってください）
こういうチームは努力をされています。
「飛べなかった。問題点は翼が小さかったに違いない。もっと鳥の羽を集めよう」
「また飛べなかった。問題点は翼が重かったに違いない。もっと少ない蝋で翼を作ろう」
「それでも飛べなかった。問題点は腕の力が弱かったからに違いない。もっと筋力を鍛えよう」
このような改善アクションを繰り返しますが結局ゴールである「鳥のように自力で空を飛びたい」には辿り着けません。
なぜなら人間の構造では腕に翼をつけても飛べないからです。
最初からゴールが間違っています。
このような最初から誤ったゴールを設定して永遠に辿り着けないゴール目掛けて足掻いているチームを見ることがあります。
具体的に言えば、同じメンバーと同じ期間で出力する中間成果物の量を最大化させる方法を探す「開発生産性向上」のようなゴールです。
こういう誤ったゴールを設定してしまったチームや組織に対して、どうやって誤ったゴールを撤回させるか。あるいはゴール設定が誤っていたことに気づいてもらうか。
もっと言えば設定される前にどうやって誤ったゴールを設定させないか。
そこを考えて動くこともまたスクラムマスターの仕事だと思います。
Discussion