この記事を読んでいただきありがとうございます。アジャイルグループに所属する、藤井智弘です。  人生にはときに「反省すること」も必要です。しかし、それは、常に「前にすすむために」で、なければなりません。  デイリースクラムの次は、レトロスペクティブへの質問を扱います。 質問 #  KPT（Keep=続けること・Problem=問題・Try=次に試すことの3観点で振り返る手法）でレトロスペクティブを4ヶ月続けています。PもTryもたくさん出ますし、出たTryはだいたい実行しています。それなのに、チームが良くなっている実感がありません。  中身を見ると、Pは「◯◯の設計ドキュメントがない」「△△のテストが書かれていない」のような作業の抜けが多く、Tryは「◯◯ドキュメントを作る」。一方で「情報の伝達漏れがあった」のようなPには、毎回「コミュニケーションを改善する」というTryが付きます。  これって改善なのでしょうか？  先日、上司にこう言われました。「『◯◯ドキュメントがない』が毎回出てくるなら、最初に設計書を全部書くウォーターフォールのほうがいいんじゃないか」。私は答えられませんでした。違う気がするのに、何が違うのか言えなくて、もやもやしています。 回答 #  最後のもやもやから片づけましょう。上司の指摘は、半分当たっています。ウォーターフォールには「設計工程で設計書を書く」という決まりがあり、その決まりがある限り「設計書がない」は起きにくい。つまり上司は、「あなたたちのチームには、 抜けを防ぐ決まりがない 」と言っているのです。これは正しい観察です。ただ、そこから「だからウォーターフォール」に飛ぶのは早い。決まり事は、工程表から引っ張らなくても、自分たちで作れます。そして、自分たちで作る場が、レトロスペクティブです。もやもやの正体は、「レトロが決まりを作る場として働いていない」ことを、上司が外から言い当てたことにあります。  残りの二つも、同じところに根があります。「PもTryも出て、実行もしている」のに実感がないのは、出た数と実行した数は増えても、チームのやり方が一つも変わっていないからです。「◯◯ドキュメントを作る」は、ドキュメントを一本増やしますが、次のスプリントには「△△ドキュメントがない」が出ます。消えたのは一つの事象（インスタンス）で、その根底にある同様な事象を繰り返し生んでいる仕組み——書く役割も、書くタイミングも、完成の基準も決まっていないこと——は、そのままだからです。これは 改善ではなく作業 です。逆に「コミュニケーションを改善する」は、来週誰が何を変えるのかが入っていないので、実行のしようがありません。こちらは 改善ではなく願望 です。質問者のレトロは、作業と願望の間にあるはずの「やり方の変更」を、一度も決めていません。   レトロの仕事は、思わしくない出来事を一つずつ消すことではなく、 その出来事を繰り返し生んでいるチームのやり方を、一つ、小さく、次のスプリントで試せる形で変えること です。良いことについても同じで、 今回はたまたまうまくいったことを、意図して起こせる形に変える ことです。  以下、Tryの「粒度」と「置き場」の二つを手がかりに、質問者のレトロを組み立て直します。      図1: 出しては片づけ、また同じ付箋——列挙会と再放送 「Tryは絞って、必ず実行しなさい」に、引っかかりはありませんでしたか？ #  研修では、こう習います。 レトロは毎スプリント行う。 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）が回り始めた上でなら、テーマ型レトロ（今回は品質だけ）、タイムライン振り返りなど、手法の変更が効いてきます。順序を間違えないでください。「出した後」の扱いが同じまま「出し方」だけ変えても、数回で元に戻ります。 なぜこの質問は30年繰り返されるのか #  長いあいだ、「いつ、誰が、何を書くか」という決まりは、工程表と開発標準が外から与えてくれるものでした。チームが自分でやり方を決める、という仕事は、多くの現場で経験されたことがありません。スクラムはその仕事をチームに渡しましたが、だからといって渡された側が十分に訓練されているわけではありません。だから最初は「あからさまな無駄」を拾って成功し、拾い尽くしたあとで、やり方を決める段階に入れずに止まります。そして止まったチームを外から見た人は、決まりを与えてくれる古い方法を思い出し、「それならウォーターフォール」と言う。この問答は、世代が替わるたびに繰り返されるでしょう。  レトロの価値は、出た付箋の枚数でも、Tryの消化率でもなく、チームのやり方が何個変わったかで測られます。今回のレトロで、やり方が一つ変わり、それが次の計画に積まれたか——それだけ確かめれば、レトロが生きているかどうかは分かります。この基準さえ持てば、レトロにネタ切れはありません。チームが完璧になるまで、変えるべきやり方は無限に見つかるからです。そして完璧なチームには、少なくとも私は、まだ会ったことがありません。 次回: 「スプリントレビューにステークホルダーが来なくなりました」

 この記事を読んでいただきありがとうございます。アジャイルグループに所属する、藤井智弘です。  デイリー、レトロと続けてきたイベントの話、3つ目はスプリントレビューです。前の2つはチームの内側で完結する会でしたが、レビューはチームの外の人が主役です。だからこそ、形骸化の仕方も、直し方も、少し様子が違います。 質問 #  スクラムを始めた当初は、スプリントレビューに関係部署の方々が（物珍しさもあって）来てくれていました。ところが4ヶ月経った今、参加者はほぼチームメンバーだけです。毎回きちんとデモを準備しているのに、見てもらえない。  先日、発注側の担当者からは、「デモは動画か資料で送ってもらえれば見ておきます。細かい確認は検収のときにまとめてやりますので」と言われました。悪気はなさそうですし、忙しいのも分かります。  でも…、「チーム内デモ会」と化したレビューを、これ以上続ける意味はあるのでしょうか？ 回答 #  「資料で送ってください」という一言に、答えが入っています。相手は、レビューを「報告」だと思っている。報告なら、わざわざ会に出なくても資料で足ります。その判断は、相手の立場ではまったく合理的です。問題は、レビューが本当に報告の会になっていることのほうです。  この相談を受けるとき、相談者はたいてい三つのことを考えています。 来なくなったのは、忙しいからか、興味を失ったからか 資料で済むなら、それで済ませてしまってよいのか チーム内だけのレビューにも、やらないよりはましな価値があるのか  順に答えます。 来なくなったのは、忙しいからでも興味を失ったからでもなく、 来ても何も決まらない、と学習された からです。完成したものを見せられ、拍手して帰る会に、2度目から出る理由はありません。     図1: 準備は万端、席は空——4ヶ月後のスプリントレビュー 資料で済むかどうかは、会の中身によります。 報告なら資料で済みます 。しかし「この代替フローは踏襲するか捨てるか」「次はどの業務領域から検証するか」という 判断は、資料を送っても返ってきません 。 チーム内だけのレビューは、残念ながらレビューではありません。検査してくれる相手がいないからです。  処方は出席の督促ではなく、会の再定義です。レビューを「完成報告会」から「次に何を作るかを、外の人の言葉で決める会」に変えれば、 自分の発言が製品を動かすと分かった人は、呼ばなくても来ます 。見るべき場所は二つ。誰に何を決めてもらうか。もらった意見が、その後どうなったか。 「レビューは検収の場ではありません」——その指導、腑に落ちていましたか？ #  研修や現場で、「スプリントレビューは承認や検収の場ではありません」「デモをする会ではなく、検査する会です」と教わった方はすくなからずいらっしゃるでしょう。でも、こう思いませんでしたか？ 完成したものを見せて確認してもらう。それの何が悪いのか。発注側は検収したがっているのに 毎回ステークホルダーの意見を聞いていたら、計画がぶれたり、おさまらなかったりするのではないか 来ない人をどうやって呼ぶのか。督促のほかに、何があるのか  これらの疑問はもっともです。結論から言うと… 見せることは悪くない、見せて終わることが問題 計画が揺れるのは、まさに目的どおり期待通り。ただし揺れるのはスプリント単位。 人は、督促では来ず、自分の影響が及ぶ場にだけ来続ける。 各々を深ぼる前に、まずレビューがどんな姿になりがちかを眺めてから、順に説明します。 スプリントレビューのあるある #  形骸化したレビューには、いくつかの型があります（レトロの時は”顔”でしたが、深い意味はありません）。どれが自分たちの会に近いか、思い浮かべながら読んでください。 その１：完成報告会型 ——最もよく見る型です。チームが「今スプリントでできたこと」を順に披露し、ステークホルダーは「ありがとうございます」と拍手して帰る。質問が出ても答えて終わり。次のスプリントでやることは、会の前から決まっています。「資料で送ってください」は、この型への、相手からの正直な評価です。     図2: 拍手して帰る会。「資料見ときますねー」 その２：検収型 ——業務系の現場で起きやすい型です。発注側の担当者や、内製でも事業部門の担当者が「納品確認」のつもりで来ます。見るのは「言った通りにできているか」であり、「これでいいのか、次はどうするか」は議題に上がりません。第6回で、発注側や管理職がデイリーに顔を出す「顧客報告型」を見て、判断に関わりたい人の席はレビューだと書きました。席を用意しても、検収型のままでは、デイリーの報告会がレビューに引っ越しただけです。 その３：全員集合型 ——「関係者各位」への一斉招待で開かれる型です。「あなたが来る理由」を誰にも伝えない招待は、全員に薄く扱われます。初回は物珍しさで集まり、数回で「出なくてもいい定例」に分類されます。 その４：判子型 ——チームが「これでよろしいでしょうか」と承認を取りに行く型です。ステークホルダーの役割は「はい」と言うことだけで、選択肢は提示されません。承認は下りますが、方向は何も動きません。検収型が発注側の作法だとすれば、判子型は受注側の作法です。 その５：チーム内デモ会型 ——その１〜４の行き着いた姿です。外の人が来なくなり、チームだけでデモをして終わる。記録が残る点は悪くありませんが、検査する相手がいません。質問者のチームは、いまここにいます。 五つの型の底にあるもの #  五つの型に根を張るのは、**「レビューは成果物を見せる場だ」**という前提です。もしそうなら、見せられれば会は成功であり、来ないならデモの見せ方を磨けばよく、承認がもらえれば完了、ということに（素直に）なります。五つの型には、何もおかしなところはありません。素直に到達点に至ったのです。  そして「見せるだけの場」なら、資料で済む。相手の言い分は、この前提の上では完全に正しいのです。  さあ、三つの疑問に戻りましょう（※この記事の展開もパターン化してきたね）。 完成したものを見せて確認してもらうことの何が悪いのか 。  悪くありません。動くものを見せるのはレビューの出発点です。 問題は、見せた後に何もしないこと です。ステークホルダーが動くものを前にして提供できるのは、「言った通りか」の確認ではなく、チームが持っていない情報——現場の実感、市場や他部署の状況、次に困ること——です。それを聞かずに終わる会は、チームにとっては報告、相手にとっては検収でしかなく、どちらにも次を決める材料が残りません。 検収（完成の定義や受け入れ条件との突き合わせ）は必要な仕事ですが、レビューの中でやることではありません 。突き合わせは会の前に済ませ、会では「これを踏まえて次をどうするか」を話す。この分担があると、レビューは検収に食われずに済みます。 毎回意見を聞いていたら計画が揺れるのではないか 。  揺れます（もちろん）。そして、それこそが目的です。スプリントごとに動くものを見せるのは、方向を早く修正するためであり、方向が一度も変わらないレビューは、何も検査していないのと同じです。ただし、揺らすのはスプリント単位です。会の中で出た意見は、その場で開発チームの作業に割り込むのではなく、プロダクトバックログの並び順の変更として受け止め、次のスプリントの計画で拾う。この受け皿があれば、意見は「計画を壊すもの」ではなく「計画を更新する材料」になります。第4回の言い方をすれば、スライスの入替はこの受け皿の中で日常的に起き、ユースケース一覧の足し引きだけが、発注側の明示的な判断として手続きに載ります。 来ない人をどうやって呼ぶのか 。  督促ではもう来ないでしょう。 人が会議に出続けるのは、その場に自分の影響が及ぶときだけ です。読者の皆さんも、発言の機会も必要もない報告会議への出席は、できれば減らしたいはずです。  初期のレビューに人が来ていた理由と、来なくなった理由は、実は同じものです。始めたばかりのころ、ステークホルダーは「新しいやり方で何が起きるのか」を確かめに来ます。数回見て、こう学習します。デモは整っている、質問すれば答えてくれる、しかし自分が何を言っても言わなくても、次のスプリントでやることは変わらないらしい…。この学習が完了した時点で、レビューはカレンダーの中で「出なくてもよい定例」に分類され、「資料で送ってください」が口から出ます。これはステークホルダーの怠慢ではなく、合理的な行動です。  呼ぶ方法はひとつしかありません。「来ると、何かが自分の言葉で決まる会」にすることです。  ここで、更改案件を扱った第3〜5回を思い出してください。あの3本で見たとおり、更改案件には、発注側にしか決められないことが毎スプリントのように出てきます。検証で見つかった「謎の挙動」を踏襲するか、直すか、捨てるか。あるユースケースの検証の深さを、最小集合で止めるか、主な代替フローまで広げるか。次にどの業務領域から現物を動かすか。どれも、動くものを前にして、業務を知っている人が決める判断です。つまり更改案件のレビューには、議題が足りないはずがありません。それでも「報告会」になっているなら、これらの判断は、レビューの外——メールや別の定例——で決まっているか、誰も決めないまま開発者の推測で埋められているかのどちらかです。前者ならレビューに戻せばよく、後者なら、それこそがレビューで決めるべきことです。  それにしても、 なぜ「見せる場」という前提がこれほど自然に入り込むのか 。多くの組織には、スクラム以前から「進捗報告会」「成果報告会」「検収」の文化があります。動くものを前にして人が集まる、という見た目が似ているので、レビューはその既存の型の上に上書きされ、古い目的——報告する、確認する、承認をもらう——がそのまま生き続けます。業務系の現場では、もう一段根深い事情が絡むこともあります。内製化を進めた事業会社でも、発注先のシステム会社と向き合うときと同じ役割分担と上下関係——いわば「社内外注」の構図——が、ビジネス部門とIT部門の間に持ち込まれているケースが少なくありません。この関係のもとでは、レビューは「対等なパートナーと次を決める場」ではなく「発注先の納品確認」として扱われます。誰かが手を抜いているわけではありません。関係の形が、会の形を決めているだけです。  それでは、本来のスプリントレビューは何をする時間か。透明性・検査・適応に当てはめてみます。   透明性 ——スプリントの成果が、資料ではなく動くもの（インクリメント）として、チームの外の人にも同じように見えていること。スプリントゴールに対して何ができ、何ができなかったかも隠さずに示します。デモはこの透明性の手段であって、目的ではありません。資料で済むのは、ここまでです。   検査 ——見えているものを、プロダクトのゴールと、ステークホルダーが持ち寄った市場・現場の状況に照らして、「このまま進んでよいか」「何が変わったか」を確かめること。ここで初めて、チームの外の情報が入ってきます。資料を送っても、これは返ってきません。   適応 ——検査の結果を受けて、次に何を作るかを決めること。プロダクトバックログを並べ替え、方向を変える。レビューの成果物はデモではなく、フィードバックと、それを踏まえたバックログの方向づけです。  この三つに照らすと、完成報告会型のレビューの正体が見えてきます。透明性（デモ）に会の時間を使い切り、検査も適応も行われていない。報告会型のデイリーと、出しっぱなしのレトロと、同じ構図です。 「成果物を見せる場」から「次に何を作るかを外の人と決める場」へ 。置き換えるのはこの一点です。ここが変わらなければ、処方はどれも効きません。 処方 #  処方は手段です。レビューの進め方にも有識者の提案は多く、どれを選んでもかまいません。ただ、なぞって「できてます」感を得るだけなら、判子型と変わりません。レビューへの評価は出席者の数ではなく、レビューを機にバックログが動いた回数で判定してください。 まず、レビューでバックログが動いた回数を数える  手を打つ前に、まず数えます。直近3〜4回のレビューについて、その会を機にプロダクトバックログの並びや中身が変わった件数を数えてください。ゼロが並ぶなら、レビューは検査も適応もしていない、という事実が手に入ります。「ステークホルダーが来ない」という嘆きは、「過去4回のレビューで、バックログが動いた回数はゼロでした」という報告に変えたほうが、次の処方が通ります。レトロで前回Tryのその後を数えたのと同じ理屈です。 意思決定の場として再設計する  アジェンダの中心を「デモ」から「決めること」に移してください。毎回1つでいい、ステークホルダーの判断を要する問いを用意し、招待状にそれを明記します。「今回のレビューで決めたいこと: ◯◯」の一行があるだけで、会の性質は変わります。更改案件なら問いには事欠きません。「検証で見つかったこの挙動は、踏襲しますか、直しますか」「請求書発行の検証は最小集合で止めてよいですか、月初の一括発行まで広げますか」「次に動かすのは入金照合と月次締めのどちらからにしますか」。新規開発なら「この機能はこの形でリリースしてよいか」「AとBのどちらの方向で次を進めるか」「この仮説は現場の実感と合っているか」等々…  冒頭はスプリントゴールに対して何ができたかから始め、その上で問いを置く。そして決めたことは議事録やバックログに記録し、組織に正式な変更手続きがあるなら、そこへつないでください。口頭の合意のままにしないことが、この運用を続ける肝になります。  なお、その場で決めきれない議題（稟議事項など）は、「レビューでは方向の推薦までを決め、正式決定は既存の手続きに乗せる」と明示しておくと、会議体の位置づけや権限を巡る混乱を避けられます。  図3: 動くものを前に、外の人の言葉でバックログが動く 問いを事前に配る  当日その場で「ご意見は？」と聞かれても、人は答えられません。デモで見せるもの、判断してほしいことを事前に短く共有し、考えてくる時間の余裕を提供してください。フィードバックの質は、準備時間に比例します。「資料で送ってください」と言われたら、この事前共有をその資料にしてしまえばよいのです。 送るのは報告ではなく、「当日、これを決めてほしい」という問い です。 名指しで、理由つきで招待する  一斉招待をやめ、今回の議題に関係する人を絞って呼びます。「経理部の◯◯さん、今回の帳票出力はお手元の月次業務に直結するので、実際の画面で確認してほしい」。呼ぶ理由を言えない相手は、今回は呼ばなくていい相手です。少人数でも、影響力と意味のあるフィードバックが出る会のほうが、大人数の沈黙の場よりも、何倍も価値があります。第6回で、デイリーに顔を出す発注側や管理職に「判断に関わりたいなら、その場所はレビューです」と席を用意する話をしました。その席に呼ぶときも同じで、「この判断をあなたにしてほしい」と理由をつけて呼びます。 検収は会の前に済ませる  検収型に寄っている現場では、受け入れ条件との突き合わせを、レビューの前に担当者と済ませておきます（受け入れ条件が事前に明文化されていれば、大部分は条件との突き合わせで済みます）。レビュー当日は「言った通りできているか」の確認ではなく、「これを踏まえて次をどうするか」に時間を使う。このようなステークホルダーの関わり方を最初に合意しておくと、レビューが納品確認の時間に食われなくなります。 持ち帰れる一枚を渡す  発注側の担当者は、レビューの後、社内に報告する仕事を抱えています。「資料で送ってください」の半分は、その報告用の材料が欲しい、という意味です。第3回で、「検証済みリスト」「残リスク」「業務影響順」という語彙を担当者と共有する話をしました。レビューの終わりに、今回の検証で検証済みリストがどこまで伸び、何が決まり、残リスクがどう変わったかを一枚にして渡してください。担当者はそれをそのまま社内に持ち帰れます。 判断は会で、報告は一枚で 。この分担ができると、「資料で」という要望は消えます。 フィードバックの「その後」を見せる  もらった意見がどうなったかを、次回レビューの冒頭で必ず報告してください。「前回の◯◯さんの指摘は、この形でバックログに入り、今回のデモに反映されています」「△△のご要望は検討の結果、今期は見送りました。理由は…」。採用でも見送りでもいい、自分の以前の発言が追跡されていることが伝われば、発言は「言い損」ではなくなります。これが次回の出席の最大の動機になります。  この再設計は、チームとステークホルダーの共同作業です。チームは問いを用意して意見の行方を追跡し、招かれた側は判断を持って席に着き、自分の意見がどうなったかを次回確かめる。この往復が回り始めると、レビューは呼ばなくても人が来る会になります。「社内外注」の上下関係を対等な協働に組み替えていく、地道な働きかけでもあります。 なぜこの質問は30年繰り返されるのか #  「動くソフトウェアを定期的に見せる」という形は、導入初日から真似できます。しかし「見せたものを材料に、外の人と一緒に次を決める」という中身は、チームの外の人間関係と組織の意思決定様式に踏み込む必要があり、格段に難しい。だから多くのチームが、まず形から入り、形のまま止まります。そして数ヶ月後、空席の並んだ会議室で同じ疑問を抱くのです。  レビューの出席者数は、チームと組織の接続の健全さを示すバロメータです。空席が続くなら、それはチームの外との対話が途絶えかけているサインであり、デモの出来栄えより先に直すべきものがあります。今回のレビューで、外の人の言葉で何かが決まり、バックログが動いたか——この一つの問いが、スプリントレビューを測る計器になります。  え？やってみたけど、ステークホルダー側がどうしても動いてくれない？ ムムム、そんな環境での戦い方も、いずれこの連載のどこかで扱いましょう。 次回: 「ストーリーポイントの人日換算を上司に求められます」

こんにちは。株式会社エス・エム・エスの人材紹介開発グループの藤井と申します。 以前、看護師向け人材紹介サービス「ナース専科　転職」のWEBエンジニアとして取り組んだスクラムの改善についてご紹介しました。 現在は、複数のWEB開発チームを横断して伴走する「イネイブリングチーム」の立ち上げと推進を担っています。 本稿でご紹介するのは、このイネイブリングチームの立ち上げから現在までの半年間です。この半年で、私たちは自分たちのスコープを一度大きく変えました。何を考えて始め、何をきっかけに、どう変えたのか。まだ道半ばの取り組みですが、考えたことを残しておきたいと思います。 ※本稿では、WEB開発を担当するエンジニアのチームを「開発チーム」、主には集客に責任を持ちつつ事業成長をミッションとするマーケティング組織を「マーケ」と呼ばせていただきます。 イネイブリングチームを立ち上げるまで 当社には、医療・介護などの分野で職種ごとに複数の人材紹介サービスがあり、それぞれにWEB開発のチームがあります。 各チームは、担当するサービスの事情に合わせて運用を磨き込んできました。マーケが施策を立案し、開発がそれを確実に形にする。役割が明確なぶん速く回せる進め方で、これまでの成果はその積み重ねの上にあります。 受け取って作る、から、一緒に事業を伸ばす へ 一方で、依頼を受けて実装するところに軸足が置かれていると、開発側が施策の「なぜやるのか（Why）」に踏み込む機会は限られていきます。見方を変えれば、次のような伸びしろがありました。 施策の背景や期待する成果を、着手する前にもっと深く握れる 作ったあとの効果を見届け、そこで得た学びを次の施策に活かせる 各チームが積み上げた工夫を、他のチームへ流していける 長く取り組んできた開発基盤の整備が一段落し、これまでより速いペースで改善を重ねられる土台が整ってきたタイミングでもありました。そこで次の段階として、 開発組織も事業責任を担い、マーケと一緒にサービスを改善して事業を成長させる状態 を目指すことにしました。 進め方の言葉にすると、変えたいのはここです。 これまで これから Why（なぜやるのか） マーケが定め、開発は依頼として受け取る マーケと開発で一緒に考える What（何を作る・試すか） 依頼の内容として決まっている 優先度も成果指標も一緒に決める How（どう作るか） 開発が担う 開発がリードする（ここは変わらない） WhyとWhatに開発が入っていくぶん、マーケにとっても技術観点からの提案を受け取りやすくなり、結果を一緒にふりかえりやすくなります。どちらか一方のための変更ではなく、双方に利のある形にしたいと考えていました。 立ち上げ時に置いた2つの方向性 以上を踏まえ、立ち上げ時の方向性は大きく2つとしました。 各 WEBチームの接続を強める — 違いを整理して見える状態にし、学びを橋渡しする マーケと一緒に Why から考えていける組織をつくる — 開発も事業成果に責任を持つ前提で、Whyから並走する 「イネイブリングチーム」という名前はどこから来たか この2つを進める役割として立ち上げたのが、イネイブリングチームです。名前も考え方も、 『チームトポロジー 価値あるソフトウェアをすばやく届ける適応型組織設計』（マシュー・スケルトン、マニュエル・パイス 著／原田騎郎、永瀬美穂、吉羽龍太郎 訳、日本能率協会マネジメントセンター） をもとにしています。 同書では、組織のチームを4つの基本タイプで捉えます。私たちの状況に当てはめると、各サービスのWEB開発チームは、ユーザーとビジネスへの価値提供に責任を持つ ストリームアラインドチーム にあたります。そして イネイブリングチーム は、ストリームアラインドチームが自律的に動けるよう、特定の領域で能力のギャップを埋める役割を担うチームです。 ここで最初に握っておいたのは、 代わりにやってあげるチームではない ということでした。同書でも、イネイブリングチームは支援する相手の作業を肩代わりするのではなく、相手が自分でできるようになることを目的とし、その関わり方も恒久的なものではないとされています。 この前提を先に置いたことが、後々まで判断の支えになりました。実際、チーム指針には「やらないことリスト」を用意し、その先頭に「各チームの代わりに、要件定義やバックログ整理を全部代行する」を置いています。成果は「自分たちで作った量」ではなく「各チームが自走できるようになったか」で測る、とも決めました。 こうして、決める立場ではなく各チームの隣で一緒に走る存在として、少人数のチームで活動を始めました。 なお、このあとご紹介するスコープの変更を経て、現在の私たちの実態は同書の定義そのままではなくなっています。その点は後半で改めて触れます。 最初の半年でやったこと ここからは、各チームへの働きかけとして実際に手を動かしたことを3つご紹介します。 1. まず「知ること」から始める いきなり共通化に進まず、各チームのリーダーへのヒアリングと定例への参加から始めました。あわせて、開発メンバー向けの説明会とマーケの皆さんとの対話会も実施し、目標・運用・強み・困っていることをフラットに聞かせてもらいました。 ヒアリングを重ねて分かったのは、チームごとに置かれた状況がかなり違うということでした。連携が成熟しているチーム、短期の目標がきびしいチーム、組織の再編が進行中のチーム。同じ型を同じ速度で当てはめてもうまくいかないことは明らかでした。 そこで、進め方の原則を3つ決めました。 どこまで踏み込むかの線は、暫定版から磨く — 机上で書き切らず、現場を見ながら更新していく前提で置く 抽象的な線引きより、1件の事例を先につくる — 実際にうまくいった例のほうが、話が早い 対象を絞って厚く入る — 全チーム同時展開はしない。成功確率の高いところに集中する 型から入らず、まず聞くことに時間を使ったからこそ、どこにどう入っていくかを、机上の想定ではなく各チームの実態に合わせて決められました。 2. 課題管理のフォーマットを揃える チームごとに起票の粒度や指標の定義が異なると、他チームの取り組みから学ぶことが難しくなります。そこで、管理のためではなく「お互いの工夫から学べるようにするため」という目的で、課題管理のフォーマットを共通化しました。 課題種別（機能開発／仮説検証／技術改善／調査／保守運用／不具合対応）を定義する サイズ・ターゲット・期待される効果の大きさ・緊急度などを、数値型ではなく選択リストで持つ 起票時にWhyを必ず言語化する運用に揃える 「そもそも何を課題として起票するか」の基準も言語化する（1行の修正まで起票するのか、など） 全チーム一斉ではなく、準備の整ったチームで先行導入して検証する 自由入力ではなく選択リストにしたのは、あとから比べられるようにするためです。自由に書けるほど記述は豊かになりますが、その代わり集計の段階で揃わなくなります。 もうひとつ、フォーマットを配っただけでは良い課題が自然に起票されるわけではない、という指摘がチーム内から出ました。起票の質は、書き手の慣れやそのときの時間の余裕に左右されます。そこで、導入したチームのリファインメントへ一緒に入って伴走しつつ、初稿づくりや一次レビューへAIを組み込む運用も試しています。人の指摘に頼らず一定の水準へ引き上げられれば、書き手の負担も、指摘する側の気疲れも減らせると考えました。 「比べられる状態」ができたことで、他チームの施策や学びを参照しやすくなりました。共通化するのは土台だけで、各サービスの戦略や専門性はそのまま維持しています。 3. 登録した先まで、ユーザーの体験を通して見られるようにする 私たちが担当している人材紹介サービスは、求職者がWEBサイトから登録したあと、キャリアパートナーが求人のご紹介や選考のサポートを行い、入職して働き始めるところまでがひと続きの体験になっています。WEBサイトはその入り口であり、登録は通過点にすぎません。ユーザーにとって本当に大事なのは、納得できる職場と出会えたか、入職して働き続けられているかです。 ところがデータの上では、登録の前と後が分かれていました。WEB側で見えるのは登録までの動きで、その先で何が起きたのかは別の場所にあります。これでは施策の評価が「登録がいくつ増えたか」に寄り、良い出会いにつながったのかどうかは見えません。 そこで取り組んでいるのが、 登録の前後を串刺しにして、ひと続きの体験として分析できる状態をつくること です。これが一本の線でつながると、「登録を増やす」ではなく「良い出会いにつながる登録を増やす」ほうに目標を置き直せます。あわせて、サービスごとに数え方の異なる指標の定義を揃えることも進めています。 この取り組みで大きかったのは、 データ基盤を担当するチームと組んで進められたこと です。同じ時期に近い領域の設計が両側で進んでおり、そのままではつながらないものが2つできるところでした。早い段階で合流し、こちらから叩き台を持ち込む形で、受け持つ範囲とデータの受け渡し方を一緒に決めていきました。 現在は、まず1つのチームで実装を進めているところです。ここが終わった段階で狙いどおりの状態になったかを検証し、他サービスへの横展開を検討します。 1つの基盤を一緒に設計したことで、データ基盤チームとの間に、細かいことでも聞き合える関係ができました。横断で取りにいく価値は、成果物そのものだけではありませんでした。 転機：『TRANSFORMED』の読書会 こうした取り組みを進めていた頃、プロダクト開発に関わる組織が向かう先として、 プロダクトオペレーティングモデルへの転換 という方向性が示されました。その考え方のもとになっているのが、 『TRANSFORMED イノベーションを起こし真の DX へと導くプロダクトモデル』（マーティ・ケーガン 著／横道稔 訳、日本能率協会マネジメントセンター） です。 そこで、人材紹介開発グループでも『TRANSFORMED』の読書会を行いました。 読書会を通じて私たちが受け止めたのは、 エンパワーされたチームは「文脈 × 能力」で成り立つ という考え方です。能力だけを引き上げても、向かう先が共有されていなければ「上手に、けれど違う方向へ進むチーム」になりかねません。逆に言えば、「なぜこの課題を解くのか」が届いて初めて、現場は「何をやらないか」を自分で判断できるようになります。 この観点で自分たちの半年をふりかえると、私たちが手厚く支援していたのは 能力の側 でした。フォーマットを揃える、リファインメントに伴走する、分析の土台を整える。どれも必要なことですが、文脈の側には十分に手が届いていませんでした。 スコープを、より上位レイヤーへ この半年で変わったことのひとつに、入ってくる情報があります。 横断で動くようになったことで、各チームのリーダーやマーケ、データ基盤のチームと話す機会が増えました。それに加えて事業やプロダクトの方針を決める意思決定者とのやりとりの頻度も上がり、これまで自分たちのところまで届いていなかった、より上のレイヤーで何が議論されているのかが見えるようになりました。 両側が見えるようになって、はっきりしてきたことがあります。 戦略は確かに存在している。ただ、それがメンバーの手元に届いて、日々の判断の材料になっているとは言いにくい状態だった ということです。 意思決定者が持っている検討の背景や根拠は、現場には決まった結論の形で届きます。その手前にある「なぜこれを選んだのか」までは共有されにくく、メンバーが自分の言葉で語れるところまでは届きません。 半年の活動を通して見えてきたボトルネックは、ここでした。 上位レイヤーで考えた戦略がメンバーの手元まで適切に降り、メンバー自身で成果へコミットできる体制になっていないこと 。いくら進め方の型を整えても、ここが埋まらないかぎりは近づきません。私たちが最初に置いた「各チームの進め方を支える」というスコープは、このつなぎ目そのものには届いていませんでした。 そこで、イネイブリングチームのスコープをより上位レイヤーへ変えることにしました。「翻訳」の役割を強め、意思決定者との方針すり合わせを密に行いながら、組織にとっての最善を判断して行動する、という立ち位置です。 これまで これから 主に見る層 各チームの進め方・運用 戦略と現場の意思決定のつなぎ目 果たす役割 型と仕組みを整えて伴走する 戦略を翻訳し、現場の意思決定に接続する 意思決定者との関わり 決まった方針を現場に届ける 方針そのものをすり合わせ、組織にとっての最善を判断する 方向を変えたというより、 どのレイヤーに手を入れるかを変えた という感覚に近いです。能力側の支援をやめたわけではなく、まだ誰も手をつけていなかった文脈側を、空白として引き受けることにしました。 「イネイブリングチーム」の定義から離れている点について 前半でご紹介したとおり、私たちのチーム名と出発点は『チームトポロジー』のイネイブリングチームにあります。ただ、スコープを上位レイヤーへ変えたことで、 同書の定義をそのまま当てはめると、実態はかなり違うものになってきています 。 同書のイネイブリングチームは、特定の領域における能力のギャップを埋めることに焦点があり、支援する相手や期間を区切って関わり、役目を終えたら離れていくことが前提とされています。一方で今の私たちは、戦略の翻訳や意思決定者との方針すり合わせ、プロダクトビジョンの言語化、体制の設計といったより上位の層に軸足を移しています。特定の能力を一定期間で引き上げて離れる、という形からは離れ、担い手のいない役割を恒常的に引き受けている状態に近いです。 そのため、本稿を「『チームトポロジー』のイネイブリングチームの実践例」としてお読みいただくと、定義とのずれを感じる部分があるかもしれません。 一方で、同書から受け取った核の部分 — 代わりにやってあげない 、成果は 各チームが自走できるようになったかで測る — は、スコープが変わっても変えていません。名前に実態を合わせにいくのではなく、組織にとって今必要なことに形を合わせた結果として、こうなっています。このこと自体が、この半年の学びの1つでもありました。 今、取り組んでいること プロダクトビジョン・プロダクト戦略を言葉にする 「なぜこの課題を解くのか」という文脈が開発メンバーに届き、各メンバーが根拠を理解した上で意思決定できる状態をつくることを狙っています。個別のサービスやWEBサイトの最適化に視点が閉じないよう、事業全体を1つのプロダクトと捉えるところから始めました。 ただし、実際に着手してみて、進め方そのものを組み替えることにしました。決め手になったのは、ビジョンは書けば届くというものではない、ということでした。どれだけ言葉を磨いても、受け取る側との間に「一緒に事業の成果に責任を持つ」関係ができていなければ、掲げただけで終わってしまいます。 だとすれば、先に必要なのはそちらです。そう考えて、ビジョンの言語化よりもパイロットを先行させることにしました。 パイロットチームで、マーケとの協業の形を探る どこまでを誰が持つのか。その線を抽象的に引こうとすると議論はいくらでも続けられてしまうので、取り組みやすい1チームを選び、 課題を決めるところから成果を見届けるところまでを一緒に一周する パイロットを準備しています。 ここで置いている見立ては、 戦略を言語化して共有し計測するだけでは、「背景をよく理解したうえで、渡されたものを作るチーム」で止まってしまう ということです。関係を変えるには、解く課題を決めるところから一緒にいる必要があります。 そのため、作るものを決める前に、次のようなことを先に置いてから始めるつもりです。 どんな課題を扱い、ユーザーのどんな行動が変われば前進と言えるのか 何を優先するかを、誰がどこまで決めるのか どのタイミングで、何を見て、続ける・変える・やめるを判断するのか ユーザーの実際の声や行動を、どこから確かめにいくのか ふりかえりで見たいのは、次のようなことです。 ユーザーの行動が実際に変わったか それが事業の成果につながると説明できるか それはこの進め方だからこそ出せた結果と言えるか もっとも、どういう形が私たちにとって良い協業なのかは、やってみて分かることのほうが多いはずです。今はその最初の一周を回そうとしているところです。 ふりかえって思うこと 半年やってみて、強く感じていることが3つあります。 1. 横断で動くと、入ってくる情報が変わる 横断で動くことの価値は、チーム間で学びを橋渡しすることだと思って始めました。ただ実際に効いたのは、整えた仕組みや型よりも、 事業の方針がどういう背景で決まっているのかを知れるようになったこと でした。 1つのチームの中にいると、方針は結論の形で受け取ることになります。横断の立場になると、その結論に至る前の議論や判断の材料にも触れる機会が増えます。そうなると、「たぶんこちらのほうが良さそうだ」ではなく「この背景があるから、いまはこちらを取る」と言えるようになる。今の状況で取れる最善を自分たちで考えられるようになったのは、始める前には見えていなかった変化でした。 2. 自分たちのスコープ自体も、検査と適応の対象だった スクラムでいう「検査と適応」は、個々のチームの進め方だけでなく、横断チームの存在意義そのものにも当てはまります。机上で正しい形を決めてから動き出していたら、戦略と現場のつなぎ目がボトルネックだとは特定できなかったはずです。動いたからこそ、手を打つべき場所が見えてきました。 半年でスコープを変えられたのは、仕組みよりもメンバーのマインドによるところが大きいと思っています。一度決めた形に固執せず、今の状態に合う形へ変えていこうとする姿勢があったからこそ、「自分たちのやってきたことは、本当に効くところに当たっているのか」と率直に問い合えました。当初思い描いた形からは変わりましたが、遠回りだったとは考えていません。課題を特定し、そこに手を打てる状態になったこと自体が、この半年の成果です。 3. 横断チームこそ、広げる前に1つ通す 横断で動く立場だと、全チームに同時に手を入れたくなります。ただ、少人数でそれをやると、どこも中途半端になります。 実際にやってみると、課題管理のフォーマットも、データを串刺しにする取り組みも、マーケとの協業もすべて「準備の整った1つ」から始める形になりました。1つ通すと、型が手に入るだけでなく、「これはうまくいった」という実例が残ります。他のチームに広げていく場面で効いてくるのは、正しさの説明よりも、その実例のほうだと思っています。 最後に 最後までご覧いただきありがとうございました。 イネイブリングチームの立ち上げから、スコープを上位レイヤーへ変えるまでの半年をご紹介しました。取り組みはどれもまだ途中ですが、「戦略と現場の間にある翻訳の余白は、誰かが引き受けるべきだ」という手応えを確かに得ています。 引き続き、各チームやマーケの皆さんと一緒に、プロダクトの力で事業の成果に貢献できる組織づくりを進めていきたいと思います。 参考文献 マシュー・スケルトン、マニュエル・パイス 著／原田騎郎、永瀬美穂、吉羽龍太郎 訳『チームトポロジー 価値あるソフトウェアをすばやく届ける適応型組織設計』（日本能率協会マネジメントセンター、2021年） マーティ・ケーガン 著／横道稔 訳『TRANSFORMED イノベーションを起こし真の DX へと導くプロダクトモデル』（日本能率協会マネジメントセンター、2024年）