【アジャイルFAQ 第7回】レトロスペクティブが機能しません…ToDo会議と再放送からの脱出法

 この記事を読んでいただきありがとうございます。アジャイルグループに所属する、藤井智弘です。
 人生にはときに「反省すること」も必要です。しかし、それは、常に「前にすすむために」で、なければなりません。
 デイリースクラムの次は、レトロスペクティブへの質問を扱います。

 KPT（Keep=続けること・Problem=問題・Try=次に試すことの3観点で振り返る手法）でレトロスペクティブを4ヶ月続けています。PもTryもたくさん出ますし、出たTryはだいたい実行しています。それなのに、チームが良くなっている実感がありません。
 中身を見ると、Pは「◯◯の設計ドキュメントがない」「△△のテストが書かれていない」のような作業の抜けが多く、Tryは「◯◯ドキュメントを作る」。一方で「情報の伝達漏れがあった」のようなPには、毎回「コミュニケーションを改善する」というTryが付きます。
 これって改善なのでしょうか？
 先日、上司にこう言われました。「『◯◯ドキュメントがない』が毎回出てくるなら、最初に設計書を全部書くウォーターフォールのほうがいいんじゃないか」。私は答えられませんでした。違う気がするのに、何が違うのか言えなくて、もやもやしています。

 最後のもやもやから片づけましょう。上司の指摘は、半分当たっています。ウォーターフォールには「設計工程で設計書を書く」という決まりがあり、その決まりがある限り「設計書がない」は起きにくい。つまり上司は、「あなたたちのチームには、抜けを防ぐ決まりがない」と言っているのです。これは正しい観察です。ただ、そこから「だからウォーターフォール」に飛ぶのは早い。決まり事は、工程表から引っ張らなくても、自分たちで作れます。そして、自分たちで作る場が、レトロスペクティブです。もやもやの正体は、「レトロが決まりを作る場として働いていない」ことを、上司が外から言い当てたことにあります。

 残りの二つも、同じところに根があります。「PもTryも出て、実行もしている」のに実感がないのは、出た数と実行した数は増えても、チームのやり方が一つも変わっていないからです。「◯◯ドキュメントを作る」は、ドキュメントを一本増やしますが、次のスプリントには「△△ドキュメントがない」が出ます。消えたのは一つの事象（インスタンス）で、その根底にある同様な事象を繰り返し生んでいる仕組み——書く役割も、書くタイミングも、完成の基準も決まっていないこと——は、そのままだからです。これは改善ではなく作業です。逆に「コミュニケーションを改善する」は、来週誰が何を変えるのかが入っていないので、実行のしようがありません。こちらは改善ではなく願望です。質問者のレトロは、作業と願望の間にあるはずの「やり方の変更」を、一度も決めていません。

  レトロの仕事は、思わしくない出来事を一つずつ消すことではなく、その出来事を繰り返し生んでいるチームのやり方を、一つ、小さく、次のスプリントで試せる形で変えることです。良いことについても同じで、今回はたまたまうまくいったことを、意図して起こせる形に変えることです。

 以下、Tryの「粒度」と「置き場」の二つを手がかりに、質問者のレトロを組み立て直します。

     図1: 出しては片づけ、また同じ付箋——列挙会と再放送

 研修では、こう習います。

• レトロは毎スプリント行う。
• Tryは少数に絞り、必ず実行する。

 質問者はこれを守っていて、それでも効かない。
 守っている人ほど、こんな疑問を持つはずです。

• PもTryも、たくさん出るのは良いことではないのか。出ないチームより、よほど健全では
• Tryの実行率は高い。それでも駄目だと言うなら、何を見て「機能している」と言えばいいのか
• 上司の「それならウォーターフォール」に、どう答えれば正しかったのか

 私の答えはこうです。出る量は健全さの証ですが、レトロの成果ではありません。見るべきはTryの実行率ではなく、やり方が変わった数です。そして、上司には「おっしゃる通り、決まりがありません。来スプリントから、自分たちで一つずつ決めます」と答えればよかった。
 理由はこの先で、まず効かないレトロのあるあるを眺めてから説明します。

 効かなくなったレトロには、決まった顔があります。質問者のチームがどれに近いか、思い浮かべながら読んでください。

その１：列挙会型——Pに作業の抜けが並び、Tryでその一つひとつを「やる」に変え、あとの時間は担当の割り振りに消える顔です。終わった直後は片づいた感じがしますが、翌スプリントには別の抜けが（ときに同じ数だけ）並びます。

その２：再放送型——「コミュニケーションを密に」「テストを増やす」「早めに相談する」のような、誰も反対しないが誰も着手できないTryが、スプリントをまたいで同じ文言で現れる顔です。実行したつもりでも、何をもって実行したと言うのかが曖昧なので、消えません。

その３：消化率型——付箋の枚数とTryの消化率がレトロの指標になっている顔です。たくさん出て、たくさん片づく。数字は毎回良好、でもチームの働き方は何も変わらない。質問者のチームは、おそらくここにいます。

その４：反省会型——付箋の主語が「誰が」になっている顔です。「◯◯さんの実装が遅れて」「△△の確認漏れで」。話し手の視線はチームメイトではなくリーダーに向き、発言は無難なものに寄っていきます。前回のデイリーで見た、宛先が管理者に向いた報告会と同じことが、レトロで起きている形です。

その５：手法遍歴型——KPTからFun/Done/Learnへ、次は…、と「出し方」を変え続ける顔です。新しい手法は数回は新鮮で、確かに違う付箋が出ます。しかし出した後の扱いが同じなら、数回で元に戻ります。

    図2: 出し方を変えても、出した後が同じなら数回で戻る

 五つの顔はばらばらに見えて、同じ思い込みから出ています。**「出て、実行されれば、レトロは機能している」**という思い込みです。そう思っていると、たくさん出れば成功で、実行率が高ければなお良く、出なくなったら手法を変えればよい、という判断が次々に導かれます。五つの顔は、その判断を忠実に積み上げた先の姿です。

 この思い込みを前にして、先ほどの三つの疑問に戻ります。

 たくさん出るのは良いことではないのか——良いことです。出ないチームには、出させる工夫が先に要ります。ただし、出ることはレトロの入口であって、出口ではありません。付箋は、繰り返し起きていることを見つけるための材料です。「◯◯ドキュメントがない」は、それ単体では一つの出来事にすぎません。同じ種類の抜けが過去3回のレトロで何回出たかを数えたとき、初めて仕組みの問題——「書く役割と時点が決まっていない」など——が見えてきます。材料が多いのは良い。材料のまま終わるのが問題です。

 実行率が高くても駄目なのか——実行したTryの粒度によります。Tryには粒度があって、細かすぎると作業、粗すぎると願望になります。「◯◯ドキュメントを作る」は細かすぎて、出来事を一つ消すだけ。「コミュニケーションを改善する」は粗すぎて、来週の誰の振る舞いも変えない。改善と呼べるのは、その間——「設計変更の連絡は受付チャンネルに集約して当番が起票する」「完成の定義に『誰向けの何』を書き、レビューで確認する」——のように、チームのやり方そのものを一つ変えるものです。見分け方は一つで、「それをやったら、同じ種類のPが次のスプリントで出なくなるか」。実行率が高くても、作業と願望しか実行していなければ、やり方が変わった数はゼロです。

 上司にどう答えればよかったか——「決まりがない」という観察には、そのまま同意してよいのです。違うのは、決まりをどこからもらうかです。ウォーターフォールは、工程表と開発標準が「いつ、誰が、何を書くか」を最初に決めてくれます。スクラムは、第2回で見たとおり「どう作るか」を定義していません。その代わり、やり方を決める権限と責任をチームに渡していて、決める場がレトロです。レトロが決まりを作れていないチームは、工程表から決まりをもらっていたときより頼りなく見えます。上司の目にはそう映っていて、それは正しい。ただし、ウォーターフォールに戻れば解決するわけでもありません。第3回で見たように、工程で書かれた設計書は、書いた時点の現物しか写していません。「ドキュメントがない」が「ドキュメントはあるが古い」に変わるだけで、困りごとの中身は変わらない。そして工程表の決まりは最初に一度しか作れませんが、レトロの決まりはスプリントごとに直せます。だから答えはこうなります。「おっしゃる通り、いまのレトロは決まりを作れていません。設計工程に当たるものを、完成の定義として自分たちで定義します。来スプリントから、抜けを種類で数えて、仕組みを一つずつ改善していきます」。上司の指摘は、外からの検査として、むしろ有用だと言えます。

 なぜ「出て、実行されれば機能している」と思い込むのか——導入初期には、それで本当に機能するからです。始めたばかりのチームには「あからさまな無駄」が転がっていて、拾えば効く。出来事を一つ消すだけで、チームは目に見えて良くなる。その成功体験が、「出す・実行する」をレトロの型として固定します。無駄を拾い尽くし、残った問題が仕組みに根ざしたものになった頃、同じ型は空回りを始めます。もう一つ、多くのメンバーはスクラム以前に「反省会」の作法を身につけています。問題を挙げ、担当を決め、「以後気をつけます」で締める作法です。誰かが怠けているわけではなく、新しい器に古い作法が注がれているだけです。

 ではレトロは本来、何をする時間か。前回、スクラムの基本は経験主義で、その柱は透明性・検査・適応の3つだと書きました。デイリーが「今日の動き」を毎日回す小さなループなら、レトロは「チームのやり方」をスプリントごとに回すループです。
 透明性——このスプリントで何が起きたかが、意見ではなく事実として見えていること。ゴールの達成状況、持ち越しや割り込みの件数、待ち時間、そして「同じ種類のPが何回出たか」。付箋は、この事実の上で読まれて初めて意味を持ちます。
 検査——事実を、スプリントゴールと完成の定義に照らして、繰り返し起きているものと、それを生んでいるやり方を見つけること。単発の抜けと、仕組みの問題を仕分けるのはここです。
 適応——やり方を一つ変えると決め、担当者と完了条件をつけて、次のスプリントの計画に積むこと。変更は仮説で、効いたかどうかは次のレトロで確かめます。

 この三つに照らすと、質問者のレトロで何が抜けているかが見えます。出来事の透明性はあるが、繰り返しを見つける検査がなく、やり方を変える適応が計画に積まれていない。レトロを「出来事を消す会」から「やり方を一つ変える会」に置き直す。本稿の処方は、そのための手順です。

 なお、スクラムガイド2017には「前回のレトロスペクティブで特定した改善を、少なくとも1つスプリントバックログに含める」という一文がありました。スクラムガイド2020でこの一文は削除されましたが、レトロの成果物は意見ではなく計画に積まれたやり方の変更だ、という趣旨は、いまも有効な指針だと私は考えています。

 ここから挙げるのは、どれも道具です。以前にも指摘させていただきましたが、形だけなぞって「できている感」で満足していると、手法遍歴型がひとつ増えるだけです。試したあとは、やり方が変わった数と、同じ種類のPが減ったかどうかで、効き目を確かめてください。

まず、過去3回のPを種類で数える
 手を入れる前に、現状を数字にします。直近3回のレトロのPを、「ドキュメント系」「テスト系」「伝達漏れ系」のように種類で束ね、同じ種類が何回出たかを数えてください。あわせて、その間に出たTryのうち、チームのやり方（手順・基準・経路・道具）を変えたものが何個あったかも数えます。多くのチームで、前者は「3回とも」、後者は「ゼロ」になります。この二つの数字があるだけで、「レトロが機能していない気がする」は「同じ種類のPが3回続き、やり方の変更はゼロだった」という事実に変わり、上司への説明もそのままできます。

（1）単発と繰り返しを仕分ける
 付箋が出そろったら、議論の前に全員で仕分けます。初めて起きた単発の抜けは、議論せずバックログへ直行。レトロではもう扱いません。繰り返し起きているもの、仕組みに原因がありそうなものだけを議題に残します。「これは初めてですか、前にもありましたか」をファシリテーターの最初の口癖にしてください。

（2）Tryの粒度を揃える
 議題に残ったものからTryを作るとき、細かすぎるものは一段粗く、粗すぎるものは一段細かくします。「◯◯ドキュメントを作る」なら、「それがなかったせいで誰が何に困ったか」「それはいつ誰が作ることになっていたか」と問い、完成の定義やチェックリストの変更に引き上げる。「コミュニケーションを改善する」なら、「どの情報が、誰から誰へ、いつ届くべきだったか」「その情報はいまどの経路を通っているか」と問い、経路の変更に引き下げる。前回見た兼務メンバーの時間宣言は、「コミュニケーションを密に」を正しい粒度に下ろした一例です。ちょうどいい粒度のTryは、いつ・誰が・何を、が言えて、やったかどうかが判定できて、同じ種類のPが減ったかで効き目を測れます。

（3）Tryは1個に絞り、バックログに積む
 粒度を揃えたTryは、1個に絞ります。5個の「そのうちやる」より、1個の「次スプリントで必ずやる」。選んだ1個には担当者と完了条件を付け、プロダクトバックログに正式な項目として積み、次のスプリントの計画で拾います。改善を「レトロの中の善意」から「計画された仕事」に格上げすること。これが再放送を止める最重要の一手であり、レトロの「適応」そのものです。

    図3: 変えるのは出来事ではなく、やり方の歯車

（4）レトロの冒頭は「前回Tryのその後」から
 アジェンダの先頭を固定します。前回のTryは実行されたか。同じ種類のPは減ったか。減っていないなら、粒度が外れていたのか、実行されなかったのか。この5分があるだけで「出しっぱなしにならない」ことがチームに伝わり、改善の実行率と、やり方が変わった数は、ここで毎回更新されていきます。

（5）SMの問いかけを、出来事からやり方へ向ける
 メンバーの視線は、放っておくと出来事に向きます。スクラムマスターの仕事は、問いで視線をやり方に移すことです。使える問いをいくつか挙げます。

• 「これは初めてですか？　過去3回のレトロで、同じ種類のPは何回出ましたか？」
• 「それがなかったせいで、誰が、何に困りましたか？」
• 「それを作る手順は、完成の定義やチェックリストのどこに書いてありますか？」
• 「それは来週、誰が、何を、今までと違うようにやることですか？」
• 「同じ状況に別の人が置かれていたら、違う結果になっていましたか？」
• 「今回うまくいったのは、たまたまですか、それとも私たちが何かを変えた結果ですか？」
• 「これをやると、同じ種類のPは次のスプリントに出なくなりますか？」

 逆に、「なぜやらなかったのですか」「誰の担当でしたか」「次からどうしますか」は避けてください。答えが「気をつけます」にしかならず、視線を出来事と人に戻してしまいます。

（6）やり方の変更を、上司に見える形で示す
 「ウォーターフォールのほうがいいのでは」と言われたチームへの処方です。完成の定義の改定、受付経路の変更、チェックリストの追加——レトロで決めたやり方の変更を一覧にし、「同じ種類のPが何回から何回に減ったか」を添えて見せてください。工程表の代わりに、チームが自分で決まりを作っていることが見えれば、上司の問いは「決まりがないのでは」から「次は何を決めるのか」に変わります。上司の側も、設計書の枚数ではなく、この一覧と減り方を見てください。チームが決まりを作る力は、そこに現れます。

（7）それでも煮詰まったら、視点を変える
 （1）〜（6）が回り始めた上でなら、テーマ型レトロ（今回は品質だけ）、タイムライン振り返りなど、手法の変更が効いてきます。順序を間違えないでください。「出した後」の扱いが同じまま「出し方」だけ変えても、数回で元に戻ります。

 長いあいだ、「いつ、誰が、何を書くか」という決まりは、工程表と開発標準が外から与えてくれるものでした。チームが自分でやり方を決める、という仕事は、多くの現場で経験されたことがありません。スクラムはその仕事をチームに渡しましたが、だからといって渡された側が十分に訓練されているわけではありません。だから最初は「あからさまな無駄」を拾って成功し、拾い尽くしたあとで、やり方を決める段階に入れずに止まります。そして止まったチームを外から見た人は、決まりを与えてくれる古い方法を思い出し、「それならウォーターフォール」と言う。この問答は、世代が替わるたびに繰り返されるでしょう。

 レトロの価値は、出た付箋の枚数でも、Tryの消化率でもなく、チームのやり方が何個変わったかで測られます。今回のレトロで、やり方が一つ変わり、それが次の計画に積まれたか——それだけ確かめれば、レトロが生きているかどうかは分かります。この基準さえ持てば、レトロにネタ切れはありません。チームが完璧になるまで、変えるべきやり方は無限に見つかるからです。そして完璧なチームには、少なくとも私は、まだ会ったことがありません。

次回: 「スプリントレビューにステークホルダーが来なくなりました」