【アジャイルFAQ 第8回】スプリントレビューにステークホルダーが来なくなりました

 この記事を読んでいただきありがとうございます。アジャイルグループに所属する、藤井智弘です。
 デイリー、レトロと続けてきたイベントの話、3つ目はスプリントレビューです。前の2つはチームの内側で完結する会でしたが、レビューはチームの外の人が主役です。だからこそ、形骸化の仕方も、直し方も、少し様子が違います。

 スクラムを始めた当初は、スプリントレビューに関係部署の方々が（物珍しさもあって）来てくれていました。ところが4ヶ月経った今、参加者はほぼチームメンバーだけです。毎回きちんとデモを準備しているのに、見てもらえない。
 先日、発注側の担当者からは、「デモは動画か資料で送ってもらえれば見ておきます。細かい確認は検収のときにまとめてやりますので」と言われました。悪気はなさそうですし、忙しいのも分かります。
 でも…、「チーム内デモ会」と化したレビューを、これ以上続ける意味はあるのでしょうか？

 「資料で送ってください」という一言に、答えが入っています。相手は、レビューを「報告」だと思っている。報告なら、わざわざ会に出なくても資料で足ります。その判断は、相手の立場ではまったく合理的です。問題は、レビューが本当に報告の会になっていることのほうです。
 この相談を受けるとき、相談者はたいてい三つのことを考えています。

• 来なくなったのは、忙しいからか、興味を失ったからか
• 資料で済むなら、それで済ませてしまってよいのか
• チーム内だけのレビューにも、やらないよりはましな価値があるのか

 順に答えます。

• 来なくなったのは、忙しいからでも興味を失ったからでもなく、来ても何も決まらない、と学習されたからです。完成したものを見せられ、拍手して帰る会に、2度目から出る理由はありません。

    図1: 準備は万端、席は空——4ヶ月後のスプリントレビュー

• 資料で済むかどうかは、会の中身によります。報告なら資料で済みます。しかし「この代替フローは踏襲するか捨てるか」「次はどの業務領域から検証するか」という判断は、資料を送っても返ってきません。
• チーム内だけのレビューは、残念ながらレビューではありません。検査してくれる相手がいないからです。
   処方は出席の督促ではなく、会の再定義です。レビューを「完成報告会」から「次に何を作るかを、外の人の言葉で決める会」に変えれば、自分の発言が製品を動かすと分かった人は、呼ばなくても来ます。見るべき場所は二つ。誰に何を決めてもらうか。もらった意見が、その後どうなったか。

 研修や現場で、「スプリントレビューは承認や検収の場ではありません」「デモをする会ではなく、検査する会です」と教わった方はすくなからずいらっしゃるでしょう。でも、こう思いませんでしたか？

• 完成したものを見せて確認してもらう。それの何が悪いのか。発注側は検収したがっているのに
• 毎回ステークホルダーの意見を聞いていたら、計画がぶれたり、おさまらなかったりするのではないか
• 来ない人をどうやって呼ぶのか。督促のほかに、何があるのか

 これらの疑問はもっともです。結論から言うと…

• 見せることは悪くない、見せて終わることが問題
• 計画が揺れるのは、まさに目的どおり期待通り。ただし揺れるのはスプリント単位。
• 人は、督促では来ず、自分の影響が及ぶ場にだけ来続ける。

各々を深ぼる前に、まずレビューがどんな姿になりがちかを眺めてから、順に説明します。

 形骸化したレビューには、いくつかの型があります（レトロの時は”顔”でしたが、深い意味はありません）。どれが自分たちの会に近いか、思い浮かべながら読んでください。

その１：完成報告会型——最もよく見る型です。チームが「今スプリントでできたこと」を順に披露し、ステークホルダーは「ありがとうございます」と拍手して帰る。質問が出ても答えて終わり。次のスプリントでやることは、会の前から決まっています。「資料で送ってください」は、この型への、相手からの正直な評価です。

    図2: 拍手して帰る会。「資料見ときますねー」

その２：検収型——業務系の現場で起きやすい型です。発注側の担当者や、内製でも事業部門の担当者が「納品確認」のつもりで来ます。見るのは「言った通りにできているか」であり、「これでいいのか、次はどうするか」は議題に上がりません。第6回で、発注側や管理職がデイリーに顔を出す「顧客報告型」を見て、判断に関わりたい人の席はレビューだと書きました。席を用意しても、検収型のままでは、デイリーの報告会がレビューに引っ越しただけです。

その３：全員集合型——「関係者各位」への一斉招待で開かれる型です。「あなたが来る理由」を誰にも伝えない招待は、全員に薄く扱われます。初回は物珍しさで集まり、数回で「出なくてもいい定例」に分類されます。

その４：判子型——チームが「これでよろしいでしょうか」と承認を取りに行く型です。ステークホルダーの役割は「はい」と言うことだけで、選択肢は提示されません。承認は下りますが、方向は何も動きません。検収型が発注側の作法だとすれば、判子型は受注側の作法です。

その５：チーム内デモ会型——その１〜４の行き着いた姿です。外の人が来なくなり、チームだけでデモをして終わる。記録が残る点は悪くありませんが、検査する相手がいません。質問者のチームは、いまここにいます。

 五つの型に根を張るのは、**「レビューは成果物を見せる場だ」**という前提です。もしそうなら、見せられれば会は成功であり、来ないならデモの見せ方を磨けばよく、承認がもらえれば完了、ということに（素直に）なります。五つの型には、何もおかしなところはありません。素直に到達点に至ったのです。
 そして「見せるだけの場」なら、資料で済む。相手の言い分は、この前提の上では完全に正しいのです。

 さあ、三つの疑問に戻りましょう（※この記事の展開もパターン化してきたね）。

• 完成したものを見せて確認してもらうことの何が悪いのか。
   悪くありません。動くものを見せるのはレビューの出発点です。問題は、見せた後に何もしないことです。ステークホルダーが動くものを前にして提供できるのは、「言った通りか」の確認ではなく、チームが持っていない情報——現場の実感、市場や他部署の状況、次に困ること——です。それを聞かずに終わる会は、チームにとっては報告、相手にとっては検収でしかなく、どちらにも次を決める材料が残りません。検収（完成の定義や受け入れ条件との突き合わせ）は必要な仕事ですが、レビューの中でやることではありません。突き合わせは会の前に済ませ、会では「これを踏まえて次をどうするか」を話す。この分担があると、レビューは検収に食われずに済みます。

• 毎回意見を聞いていたら計画が揺れるのではないか。
   揺れます（もちろん）。そして、それこそが目的です。スプリントごとに動くものを見せるのは、方向を早く修正するためであり、方向が一度も変わらないレビューは、何も検査していないのと同じです。ただし、揺らすのはスプリント単位です。会の中で出た意見は、その場で開発チームの作業に割り込むのではなく、プロダクトバックログの並び順の変更として受け止め、次のスプリントの計画で拾う。この受け皿があれば、意見は「計画を壊すもの」ではなく「計画を更新する材料」になります。第4回の言い方をすれば、スライスの入替はこの受け皿の中で日常的に起き、ユースケース一覧の足し引きだけが、発注側の明示的な判断として手続きに載ります。

• 来ない人をどうやって呼ぶのか。
   督促ではもう来ないでしょう。人が会議に出続けるのは、その場に自分の影響が及ぶときだけです。読者の皆さんも、発言の機会も必要もない報告会議への出席は、できれば減らしたいはずです。
   初期のレビューに人が来ていた理由と、来なくなった理由は、実は同じものです。始めたばかりのころ、ステークホルダーは「新しいやり方で何が起きるのか」を確かめに来ます。数回見て、こう学習します。デモは整っている、質問すれば答えてくれる、しかし自分が何を言っても言わなくても、次のスプリントでやることは変わらないらしい…。この学習が完了した時点で、レビューはカレンダーの中で「出なくてもよい定例」に分類され、「資料で送ってください」が口から出ます。これはステークホルダーの怠慢ではなく、合理的な行動です。
   呼ぶ方法はひとつしかありません。「来ると、何かが自分の言葉で決まる会」にすることです。

 ここで、更改案件を扱った第3〜5回を思い出してください。あの3本で見たとおり、更改案件には、発注側にしか決められないことが毎スプリントのように出てきます。検証で見つかった「謎の挙動」を踏襲するか、直すか、捨てるか。あるユースケースの検証の深さを、最小集合で止めるか、主な代替フローまで広げるか。次にどの業務領域から現物を動かすか。どれも、動くものを前にして、業務を知っている人が決める判断です。つまり更改案件のレビューには、議題が足りないはずがありません。それでも「報告会」になっているなら、これらの判断は、レビューの外——メールや別の定例——で決まっているか、誰も決めないまま開発者の推測で埋められているかのどちらかです。前者ならレビューに戻せばよく、後者なら、それこそがレビューで決めるべきことです。

 それにしても、なぜ「見せる場」という前提がこれほど自然に入り込むのか。多くの組織には、スクラム以前から「進捗報告会」「成果報告会」「検収」の文化があります。動くものを前にして人が集まる、という見た目が似ているので、レビューはその既存の型の上に上書きされ、古い目的——報告する、確認する、承認をもらう——がそのまま生き続けます。業務系の現場では、もう一段根深い事情が絡むこともあります。内製化を進めた事業会社でも、発注先のシステム会社と向き合うときと同じ役割分担と上下関係——いわば「社内外注」の構図——が、ビジネス部門とIT部門の間に持ち込まれているケースが少なくありません。この関係のもとでは、レビューは「対等なパートナーと次を決める場」ではなく「発注先の納品確認」として扱われます。誰かが手を抜いているわけではありません。関係の形が、会の形を決めているだけです。

 それでは、本来のスプリントレビューは何をする時間か。透明性・検査・適応に当てはめてみます。
 透明性——スプリントの成果が、資料ではなく動くもの（インクリメント）として、チームの外の人にも同じように見えていること。スプリントゴールに対して何ができ、何ができなかったかも隠さずに示します。デモはこの透明性の手段であって、目的ではありません。資料で済むのは、ここまでです。
 検査——見えているものを、プロダクトのゴールと、ステークホルダーが持ち寄った市場・現場の状況に照らして、「このまま進んでよいか」「何が変わったか」を確かめること。ここで初めて、チームの外の情報が入ってきます。資料を送っても、これは返ってきません。
 適応——検査の結果を受けて、次に何を作るかを決めること。プロダクトバックログを並べ替え、方向を変える。レビューの成果物はデモではなく、フィードバックと、それを踏まえたバックログの方向づけです。

 この三つに照らすと、完成報告会型のレビューの正体が見えてきます。透明性（デモ）に会の時間を使い切り、検査も適応も行われていない。報告会型のデイリーと、出しっぱなしのレトロと、同じ構図です。「成果物を見せる場」から「次に何を作るかを外の人と決める場」へ。置き換えるのはこの一点です。ここが変わらなければ、処方はどれも効きません。

 処方は手段です。レビューの進め方にも有識者の提案は多く、どれを選んでもかまいません。ただ、なぞって「できてます」感を得るだけなら、判子型と変わりません。レビューへの評価は出席者の数ではなく、レビューを機にバックログが動いた回数で判定してください。

まず、レビューでバックログが動いた回数を数える
 手を打つ前に、まず数えます。直近3〜4回のレビューについて、その会を機にプロダクトバックログの並びや中身が変わった件数を数えてください。ゼロが並ぶなら、レビューは検査も適応もしていない、という事実が手に入ります。「ステークホルダーが来ない」という嘆きは、「過去4回のレビューで、バックログが動いた回数はゼロでした」という報告に変えたほうが、次の処方が通ります。レトロで前回Tryのその後を数えたのと同じ理屈です。

意思決定の場として再設計する
 アジェンダの中心を「デモ」から「決めること」に移してください。毎回1つでいい、ステークホルダーの判断を要する問いを用意し、招待状にそれを明記します。「今回のレビューで決めたいこと: ◯◯」の一行があるだけで、会の性質は変わります。更改案件なら問いには事欠きません。「検証で見つかったこの挙動は、踏襲しますか、直しますか」「請求書発行の検証は最小集合で止めてよいですか、月初の一括発行まで広げますか」「次に動かすのは入金照合と月次締めのどちらからにしますか」。新規開発なら「この機能はこの形でリリースしてよいか」「AとBのどちらの方向で次を進めるか」「この仮説は現場の実感と合っているか」等々…
 冒頭はスプリントゴールに対して何ができたかから始め、その上で問いを置く。そして決めたことは議事録やバックログに記録し、組織に正式な変更手続きがあるなら、そこへつないでください。口頭の合意のままにしないことが、この運用を続ける肝になります。
 なお、その場で決めきれない議題（稟議事項など）は、「レビューでは方向の推薦までを決め、正式決定は既存の手続きに乗せる」と明示しておくと、会議体の位置づけや権限を巡る混乱を避けられます。

 図3: 動くものを前に、外の人の言葉でバックログが動く

問いを事前に配る
 当日その場で「ご意見は？」と聞かれても、人は答えられません。デモで見せるもの、判断してほしいことを事前に短く共有し、考えてくる時間の余裕を提供してください。フィードバックの質は、準備時間に比例します。「資料で送ってください」と言われたら、この事前共有をその資料にしてしまえばよいのです。送るのは報告ではなく、「当日、これを決めてほしい」という問いです。

名指しで、理由つきで招待する
 一斉招待をやめ、今回の議題に関係する人を絞って呼びます。「経理部の◯◯さん、今回の帳票出力はお手元の月次業務に直結するので、実際の画面で確認してほしい」。呼ぶ理由を言えない相手は、今回は呼ばなくていい相手です。少人数でも、影響力と意味のあるフィードバックが出る会のほうが、大人数の沈黙の場よりも、何倍も価値があります。第6回で、デイリーに顔を出す発注側や管理職に「判断に関わりたいなら、その場所はレビューです」と席を用意する話をしました。その席に呼ぶときも同じで、「この判断をあなたにしてほしい」と理由をつけて呼びます。

検収は会の前に済ませる
 検収型に寄っている現場では、受け入れ条件との突き合わせを、レビューの前に担当者と済ませておきます（受け入れ条件が事前に明文化されていれば、大部分は条件との突き合わせで済みます）。レビュー当日は「言った通りできているか」の確認ではなく、「これを踏まえて次をどうするか」に時間を使う。このようなステークホルダーの関わり方を最初に合意しておくと、レビューが納品確認の時間に食われなくなります。

持ち帰れる一枚を渡す
 発注側の担当者は、レビューの後、社内に報告する仕事を抱えています。「資料で送ってください」の半分は、その報告用の材料が欲しい、という意味です。第3回で、「検証済みリスト」「残リスク」「業務影響順」という語彙を担当者と共有する話をしました。レビューの終わりに、今回の検証で検証済みリストがどこまで伸び、何が決まり、残リスクがどう変わったかを一枚にして渡してください。担当者はそれをそのまま社内に持ち帰れます。判断は会で、報告は一枚で。この分担ができると、「資料で」という要望は消えます。

フィードバックの「その後」を見せる
 もらった意見がどうなったかを、次回レビューの冒頭で必ず報告してください。「前回の◯◯さんの指摘は、この形でバックログに入り、今回のデモに反映されています」「△△のご要望は検討の結果、今期は見送りました。理由は…」。採用でも見送りでもいい、自分の以前の発言が追跡されていることが伝われば、発言は「言い損」ではなくなります。これが次回の出席の最大の動機になります。
 この再設計は、チームとステークホルダーの共同作業です。チームは問いを用意して意見の行方を追跡し、招かれた側は判断を持って席に着き、自分の意見がどうなったかを次回確かめる。この往復が回り始めると、レビューは呼ばなくても人が来る会になります。「社内外注」の上下関係を対等な協働に組み替えていく、地道な働きかけでもあります。

 「動くソフトウェアを定期的に見せる」という形は、導入初日から真似できます。しかし「見せたものを材料に、外の人と一緒に次を決める」という中身は、チームの外の人間関係と組織の意思決定様式に踏み込む必要があり、格段に難しい。だから多くのチームが、まず形から入り、形のまま止まります。そして数ヶ月後、空席の並んだ会議室で同じ疑問を抱くのです。

 レビューの出席者数は、チームと組織の接続の健全さを示すバロメータです。空席が続くなら、それはチームの外との対話が途絶えかけているサインであり、デモの出来栄えより先に直すべきものがあります。今回のレビューで、外の人の言葉で何かが決まり、バックログが動いたか——この一つの問いが、スプリントレビューを測る計器になります。

 え？やってみたけど、ステークホルダー側がどうしても動いてくれない？
ムムム、そんな環境での戦い方も、いずれこの連載のどこかで扱いましょう。

次回: 「ストーリーポイントの人日換算を上司に求められます」