デイリースタンドアップの代替案：根拠と、そのまま使える言い方

あなたのチームの誰かは、もうそのメッセージを打ち終えています。「デイリースタンドアップ、うちにはあまり機能していない気がします」みたいな一文です。そして自分で読み返し、これがどう受け取られるかを考え、消して、そのまま通話に入りました。

この記事の本題は、その「消した」ほうです。スタンドアップについての研究は探せばすぐ出てきますし、その多くは同じ方向を指しています。難しいのは研究ではなく、あの一文です。三つの社会的リスクを同時に背負う内容を言おうとしていて、しかも三つとも、あなた個人に跳ね返ってきます。

リスク1：怠けたいだけに聞こえる。 会議をなくしたいという要望は、放っておけば「見られる回数を減らしたい」という要望として読まれます。

リスク2：チームプレイヤーではないように聞こえる。 スタンドアップは、全員の足並みをそろえるためのものだとされています。それに異を唱えるのは、足並みをそろえること自体に異を唱えているように聞こえます。

リスク3：プロセスではなく、人を攻撃していることになる。 その会議には持ち主がいます。スクラムマスターか、マネージャーか、2年前にそれを始めた誰かです。その人は、儀式への批判を自分の判断への批判として受け取ります。たいていの現場では、実際にそうだからです。

だからみんな黙り、会議は「誰も言葉を見つけられなかった」というだけの理由で回り続けます。

いい知らせは、その言葉はちゃんと存在していて、しかも複雑ではないということです。決まった順番で組み立てる必要があるだけで、そしてその順番のほうが、根拠そのものより効きます。

議論に勝つための言い換え

スタンドアップは時間の無駄だ、という主張はやめてください。その主張は、さきほどの三つの理由で毎回負けます。

代わりにこう主張してください。うちのチームがやっているスタンドアップは、本来あるべき会議になっていない。そして、いつでも元に戻せる実験を提案する。

ここではScrum Guideがあなたの味方です。そして、ほとんどの人が原典を確認しない部分でもあります。2020年版のGuide¹ はデイリースクラムを、スクラムチームの開発者のために開かれる15分のイベントで、スプリントゴールへの進捗を検査し、計画を適応させるためのものだと定義しています。マネージャーへの報告の場だとは定義されていません。2020年の改訂では、いまも多くのチームが毎朝唱えている三つの質問も削除されました。¹

もしあなたのチームのスタンドアップが、その場でいちばん立場が上の人に向かって昨日と今日を順番に報告する会になっているなら、それを続けることはScrumを守っていることになりません。ルールブックがすでに手放したものを回しているだけです。しかもこれは、誰かを責めることなく口に出せます。

打ち手はこれだけです。責任を軽くしてほしいと言っているのではありません。フレームワークが書いているとおりに会議をやりたい、そしてもっと安く済む形でも成り立つかどうかを試したい、と言っているだけです。

パート1：検証に耐える理由

このテーマで出回っている数字は、かなりの数を落としました。どれをなぜ落としたかは、最後に注記として書いています。ここから並べるのは、私が懐疑的なマネージャーの前に出すものだけです。

1. 上へのステータス報告になっている。フレームワークが、そうであってはならないと言っているのに。 いちばん多く記録されている失敗の形です。Stray、Sjøberg、Dingsøyrによるデイリースタンドアップのグラウンデッド・セオリー研究では、参加者は情報共有と共同の問題解決を評価する一方、会議がマネージャーへのステータス報告になったときや、頻度が高すぎて長すぎるときには否定的な反応を示していました。² 同じ研究グループの実務者向けの文章にも、同じ指摘が出てきます。⁴

2. 三つの質問は、連携ではなく実況を生む。 「昨日はこのチケットをやりました、今日も続けます」。誰も追加で質問しません。その結果として何も変わりません。この形式が促すのは、ゴールへの進捗を検査することではなく、活動しているという演技のほうです。2020年版のGuideが質問を落としたのは、そのためです。¹

3. シニアエンジニアと大きなチームほど、得るものが少ない。 Strayらはプロの開発者に調査を行い、評価は全体としては中立あたりに集まっていて、ジュニアの開発者ほど肯定的、シニアの開発者や大きなチームのメンバーほど価値が薄いと感じやすい、という結果を得ています。³ いちばん経験のある人たちがその場でいちばん関心を失っているなら、それは本人ではなく形式についてのサインです。

4. 午前が二つに割れる。 Paul Grahamが2009年に書いた話¹³ は、いまも通用します。ものをつくる人には、途切れない長い時間のかたまりが要ります。午前の真ん中に会議がひとつ入るだけで、午前ぜんぶが、難しい仕事には短すぎる二つの断片に切り分けられます。10:30のスタンドアップは、その典型です。しかも、始まる前にもコストがかかります。その45分前から、人は深い作業に手をつけなくなります。

5. タスクの切り替えが、会議の前後どちらの仕事も劣化させる。 Sophie Leroyの研究は、アテンション・レジデュー（注意の残留）という考えを持ち込みました。あるタスクから別のタスクへ切り替えると、注意の一部は前のタスクに残ったままになり、次のタスクのパフォーマンスが落ちる、というものです。⁵ スタンドアップは、参加者全員にその切り替えを二度、入るときと出るときに強います。

6. 仕事に戻るには、それなりの時間がかかる。 Gloria Markの中断研究は、「中断されたタスクに戻るまでおよそ23分」という、よく引かれる数字の出どころです。GudithとKlockeとの研究では、人は中断を取り返そうとして速く働き、その代わりにストレスや苛立ち、負荷の感じ方が高まることも示されています。⁶ ただしこれは慎重に引用してください。生産性の議論でいちばん乱暴に扱われている数字で、反証を見たことのあるマネージャーなら、そこを突いてきます。

7. ブロッカーは名指しされるが、解決はされない。 これは自分のチームで観察してみてください。誰かが詰まっていると言い、全員がうなずき、実際の解決は40分後にふたりのDMで起きます。もしそれがパターンなら、その会議はブロッカーを解決していません。解決した会話の予定を入れただけです。

8. 会議の負荷は、生理的に積み上がる。 MicrosoftのHuman Factors Labは、会議が連続する参加者の脳波を計測し、ストレスの指標が連続のなかで積み上がっていくこと、短い休憩がその積み上がりを抑えることを見つけました。⁸ Steven Rogelbergの会議研究は、調査の側から同じことを記録していて、ひどい会議のあとに人が気持ちを立て直すために使う回復時間についても書いています。それは会議そのものの長さの上に、さらに乗ります。⁷

9. 分散したチームには合わない。 必ず誰かが、つらい時間帯に出ることになります。GitLabのオールリモート・ハンドブック¹⁴ は、ステータスを非同期で扱うことについて公開されているいちばん完成度の高い主張です。ブログではなく、実際にその方式を大規模に運用している会社から出ている、という点でこそ参考になります。

10. 毎日という頻度は、調整すべきことがあってもなくても毎日ぶんの料金を取る。 仕事の結合がゆるいチームでは、本当に調整が必要になる場面は断続的です。固定された会議は、何もない日にも払いすぎます。

パート2：反対側の根拠は、自分から出す

自分に不利な言い分を、自分で用意して持っていってください。まともに受け取ってもらういちばんの近道ですし、マネージャーに「自分ひとりでこの会議を守らないといけない」と感じさせずに済みます。

うまく運用されたスタンドアップには、代わりを用意しにくい働きが三つあります。

ブロッカーが早く表に出ます。放っておけば一日を丸ごと食べていたはずの問題が09:30に出てくるなら、それだけで15分の価値があります。あなたの代替案が絶対に引き受けなければならないのは、この働きです。

誰が何をしているかの共通像ができ、重複や衝突する作業が減ります。StrayとDingsøyrは、これを人々が実際に挙げる本物の利点のひとつとして記録しています。²

心理的安全性を支えます。RietzeとZacherは、デイリースタンドアップと心理的安全性のあいだに正の関連を見つけ、その心理的安全性は仕事の満足度やチームのパフォーマンスの受け止め方とも関連していました。¹⁰ その土台には、心理的安全性とチームの学習行動を結びつけたEdmondsonの基礎研究があります。⁹ 気負わずに定期的に顔を合わせる場は、たしかに信頼のために何かをしています。とくに新しいチームや分散したチームでは効きます。

だから、当たっているところは認めてください。チームが小さい、結合が強い、経験が浅い、あるいは発足してまだ3週間。そういう状況なら、スタンドアップはたぶんコストに見合っています。そう言ってしまいましょう。

パート3：口を開く前に、自分のデータを取る

2週間。三つのこと。話を持ちかける前にやってください。意見と儀式の勝負では意見が負けますが、算数と儀式の勝負では負けません。

予定の長さではなく、実際の長さを測る。 毎日、時間を計ってください。たいていのチームは、15分の会議が22分の会議だったことに気づきます。

人件費を計算する。 参加人数×実際の所要時間（時間単位）×年間の稼働日数。8人のチームで本当に15分なら、1日2人時、週におよそ10人時、年でおよそ460人時です。人件費が1時間あたり60ユーロなら約27,000ユーロで、しかもこの数字は会議の前後にかかる回復コストを含んでいません。入力の値で揉めないように、自分のチームの数字を使ってください。

ブロッカーを数える。 10営業日のあいだ、スタンドアップで挙がったブロッカーを全部書き出して、それが会議のなかで解決したのか、あとで別の場所で解決したのかに印をつけてください。たいていは、この数字が議論を終わらせます。

チームに匿名で聞く。 質問はひとつ。スタンドアップは自分の仕事の役に立っているか、はいかいいえ、そしてその理由。本当の答えが返ってくるのは匿名だからですし、これでもうひとつ、あなたは自分のためではなくチームのために話していることになります。冒頭のリスク2が消えます。

パート4：言い方

四つの場面、四つの台本です。中身は自分の状況に合わせて変えて、構造はそのまま残してください。効いているのは構造のほうです。

どれも同じ四拍子です。相手が本当に必要としているものを認める。コストを相手の言葉で示す。元に戻せて、期限の決まったものを提案する。立証の責任と準備の手間を、自分で引き受ける。

マネージャーに、1on1で

「見えなくなるのは避けたいので、そこは守ったうえでチームの集中時間を確保したいと思っています。うちのスタンドアップが実際どう使われているか、2週間分のデータを取りました。15分ではなく22分かかっています。8人だと、年におよそ675人時です。10日間でブロッカーは6件挙がって、会議のなかで実際に解決したのは1件でした。残りは、あとからDMで解決していました。

これを4週間試させてください。共有チャンネルに09:30までテキストで更新を書く形（好きなタイミングで読めます）、詰まった瞬間に直接メンションできるブロッカー専用チャンネル、それと週1回のライブの同期です。ブロッカーが解決するまでの時間を、いまの状態と比べて記録します。悪くなったら元に戻しますし、レトロでそう報告します。準備はすべて私がやります」

スクラムマスターに

「2020年版のGuideを読み直していました。デイリースクラムは開発者のためのイベントだと定義されていて、三つの質問はなくなっています。うちのは、その場でいちばん立場が上の人に向けた報告の順番待ちになってきていて、それはGuideがまさに防ごうとしていることなんですよね。

1スプリントだけ、円になって順番に話す代わりにボードをたどる形にしてみて、そのあと開発者に、前より役に立つようになったか聞いてみませんか」

ここで何が起きているかに注目してください。権威をあなたではなくフレームワークに渡していますし、相手を「壊れた版を守る人」ではなく「本来のプラクティスを取り戻す人」にしています。

同僚に、何よりも先に

「正直に言ってほしいんだけど、スタンドアップって実際に役に立ってる？　それとも、とりあえずやり過ごしてるだけ？　この話を持ち出そうと思ってるんだけど、自分のためじゃなくてチームのために言えるときだけにしたくて」

これを最初にやってください。必ずです。もしふたりが「スタンドアップだけが助けを求められる場だ」と言うなら、あなたの提案はそれを残さなければいけませんし、人前で立場を固める前にそれを知ることができます。

レトロスペクティブで

「今日はひとつ検査したいことがあります。2週間、うちのスタンドアップを記録しました。かかっているコストはこれ、実際に解決したブロッカーの数はこれです。やめようと言っているのではありません。1スプリントだけ形式を変えて、恒久的なことを決める前に数字を見ませんか、という提案です」

文章で提案するなら

件名：4週間の実験、非同期スタンドアップ

いま、うちのデイリースタンドアップは8人で22分かかっていて、年におよそ675人時になります。直近の10営業日では、そこで挙がったブロッカーが6件、会議のなかで解決したのが1件でした。

提案です。4週間、いつでも完全に元に戻せます。

#team-standup に09:30までテキストで各自3行。スプリントゴールへの進捗、今日の集中先、詰まっていること。ブロッカーは翌朝まで持ち越さず、出た瞬間に該当する人へ直接メンション。月曜に30分のライブ同期を1回。計画と、会話が必要なことはすべてそこで。

ブロッカーの解決時間、サイクルタイム、それと短いチームパルスを記録して、三つとも[日付]のレトロに持っていきます。ブロッカーの解決時間が悪化したら、元に戻します。ツールの設定と試行の運用は私がやります。

あのメッセージでいちばん大事な一行は、元に戻す条件をはっきり書いたところです。それが、あなたの提案を「変更」から「テスト」に変えます。イエスを引き出すのは、たいていそこです。

パート5：返ってくる言葉

「みんなが何をしているか、把握しておきたい」 テキストの更新のほうが、会議より多くを渡せます。検索できて、あとに残って、09:30にその場にいなくても、07:00でも19:00でも読めます。

「ブロッカーが放置される」 逆です。出た瞬間に投稿されたブロッカーのほうが、翌朝まで抱えられたものより早く人の目に入ります。まさにそこを記録しようと提案していますし、それが悪化したら私自身が試行を止めます。

「たった15分でしょう」 15分かける8人を、毎営業日です。さらに、それぞれがやっていた作業に戻るまでの時間が乗ります。年間だとこの数字になります。

「Scrumはデイリースクラムを求めている」 Scrumが求めているのは、開発者のためのデイリースクラムです。そして2020年版のGuideは、私たちがいまも使っている三つの質問を削除しました。うちがやっているものは、Guideが書いているものではありません。¹

「チームの一体感がなくなる」 それは実際にあるリスクで、だから週1回の同期は残します。試行のあいだはチームパルスも記録するので、一体感が落ちたら、推測ではなく数字で見えます。

パート6：この議論の負け方、五つ

仕事を減らしたい話として組み立てる。相手が最初から抱いていた疑いを、そのまま裏づけてしまいます。

代わりを決めないまま会議をなくす。そのあとの混乱は、あなた個人のせいになります。そしてそれは当然です。

ひとりで決める。チームの儀式は、チームの決定として変わるか、1か月以内に戻ってくるかのどちらかです。

試行と指標を飛ばす。検証できる提案が、現状維持との意見のぶつけ合いに変わります。そして、その勝負では現状維持が勝ちます。

役に立っている人を無視する。チームのジュニアがそれを頼りにしているなら、その人を前提に設計して、その場でそう言ってください。何のコストもかかりませんし、いちばん強い反論を、誰かが口にする前に消せます。

パート7：代わりに何を置くか

	毎日のライブ・スタンドアップ	非同期のテキスト更新	週1同期とブロッカーチャンネル
時間コスト	高い。人数に比例して増える	同期のコストはほぼゼロ	低い
中断コスト	高い。毎日、午前の真ん中	最小。自分の都合で書ける	低い。固定の1点だけ
ブロッカーの速さ	最大24時間の待ち	メンションすれば即時	メンションすれば即時
記録	誰かが書かないかぎり残らない	標準で検索できる	部分的
時差への強さ	弱い	強い	まずまず
一体感	うまく回せば良い	それだけでは弱い	良い

選択肢は七つ。それぞれに、正直な欠点をつけておきます。

ボットによる非同期のテキストチェックイン。 Geekbot、StanduplyやRangeが各自に問いかけて、共有チャンネルに投稿します。¹⁷ 時差に強く、検索できる記録が残ります。投稿された内容に誰も反応しないと、読まれないステータス劇場に劣化することがあります。

週2回のスタンドアップ。 ライブの同期は残しつつ、頻度を落とします。変更が小さいので通しやすいです。急ぎのことのために、別のチャンネルが必要になります。

円になる代わりに、ボードをたどる。 作業項目を右から左へ順に見て、人ではなくチケットについて話します。個人が報告する構図が一気に消えます。ボードが実際に最新である場合にかぎって機能します。

ブロッカー専用チャンネル。 いちばん価値が高くて、いちばん安く足せる一手です。投稿する習慣と、それを見ている人が必要です。

必要なときのペア作業。 解決はいちばん速く、観客もいません。チーム全体からの見えやすさは下がるので、書き残す仕組みが要ります。

週1回の深い同期。 15分の会議では抱えきれない会話のための場所です。これ単独では頻度が足りません。

会議のない日。 Shopifyが2023年に行ったカレンダーの一掃が、いちばんよく引かれる企業の例で、社内カレンダーから数千件の定例会議を消したと報じられました。¹⁵ これは調整の仕組みではなく集中のための方針なので、上のどれかと組み合わせる必要があります。

いちばんよく機能する組み合わせはこれです。日々の把握はテキストの更新、急ぎのものはブロッカーチャンネル、残りは週1回のライブ同期。

パート8：レトロに耐える試行を設計する

成功の指標は始める前に決めて、しかもマネージャーがすでに信じている指標を選んでください。

デリバリー。 DORA系の指標をひとつ。ふつうは変更のリードタイムか、デプロイ頻度です。¹² デプロイの回数が少ないなら、サイクルタイムでもかまいません。

ブロッカーの解決時間。 いちばん大きなリスクに対する安全装置です。これは実験を止められる指標であるべきですし、それを声に出して言うことが、実験に信用を与えます。

チームパルス。 質問はひとつ、毎週、匿名で。これはSPACEフレームワークの満足度の次元に対応します。SPACEは、単一の指標で生産性を測るとうまくいかないからこそ存在するものです。¹¹ これがないと、スループットを改善しながら静かに人を燃やし尽くしていても、気づけません。

長さは4週間がちょうどいいです。2週間では、目新しさの向こう側が見えません。8週間になると、元に戻すことが公開の失敗のように感じられはじめて、人は試行を正直に読む代わりに守りはじめます。

本当に難しいのは、ここから

ここまでのことは、午後を半日使って読めば誰でも手に入ります。それでも、必要としている人のほとんどは、そのメッセージを送りません。

足りないのは根拠ではありません。足りないのは、「この会議は機能していない」と言いながら「これを回している人が機能していない」とは聞こえない、そういう一文です。それは、出典を並べるよりずっと難しい作業です。Slackの入力欄で6回書き直されて、そのまま捨てられます。

その隙間があるから、私たちはSubtextをつくっています。人が送れずにいるメッセージの多くは、内容が複雑なわけではありません。正しいだけでは足りなくて、リスクをまるごと言い方が背負っている、そういうメッセージです。スタンドアップの提案は、そのなかでは小さいほうです。同じ形は、昇給を頼むとき、依頼の範囲を断るとき、創業者にロードマップが間違っていると伝えるとき、友人にノーと言うときにも出てきます。

ひとつだけ持ち帰るなら、これです。元に戻す条件を入れたメッセージを送ってください。「ブロッカーの解決時間が悪化したら元に戻しますし、私がそう報告します」。この一節が、相手がノーと言う理由を消します。

落とした数字についての注記

このテーマで広く出回っている数字のいくつかは、私が責任を持てなかったので、本文には入れていません。

開発者の80%がスタンドアップの最大の不満として「関係のない報告」を挙げている、という主張は、その出典とされるStrayの調査には出てきません。会議のアクションアイテムの80%は完了しない、という主張は、出典のないまま出回っています。最近のJournal of Experimental Psychologyの論文に帰されることが多い「40%長くかかり、エラーが50%増える」という数字は、2001年のRubinstein、Meyer、Evansが崩れて伝わったもののようです。あの研究が測ったのは実験室でのタスク切り替えで、朝の会議にそのまま延長できる話ではありません。¹⁸ 会議の無駄を金額にしたチームあたりの年間数値もいろいろ出回っていますが、どれも背後にある前提しだいです。パート3の計算が、代わりに自分のチームの数字を使うのはそのためです。

もうひとつ、正直に穴を書いておきます。非同期のテキストによるステータス更新と、同期のステータス会議を、デリバリーの成果で直接比べた厳密な対照研究は見つけられませんでした。GitLab、Doist、Basecampはいずれもテキスト派ですが、三社とも守るべき立場があります。マネージャーにその比較を求められたら、正確な答えはこうです。まだ存在しないようです、そしてあなたの4週間の試行こそが、自分のチームのためにそれをつくる方法です。

うちのスタンドアップはコストに見合っている、あるいは私が根拠を読み違えている。そう思ったらLinkedInで教えてください。

Samet DurgunはSubtextの共同創業者です。Subtextは、メッセージににじむ感情を読み取って、あなたの言葉のまま書き直すアプリ。拠点はベルリンです。

出典

本文中のリンクは、一次資料があるものはすべてそこへ向いています。

The Scrum Guide (2020), Ken Schwaber and Jeff Sutherland, scrumguides.org. この議論にとって、いちばん役に立つ一冊です。Daily Scrumの節を直接読んで、そのまま引用してください。このイベントが開発者のためのものであること、15分であること、三つの質問が2020年の改訂で削除されたことが確認できます。
Stray, V., Sjøberg, D. I. K., and Dingsøyr, T. (2016). “The daily stand-up meeting: A grounded theory study.” Journal of Systems and Software, volume 114. 査読あり。価値（情報共有、共同の問題解決）と、失敗の形（マネージャーへのステータス報告、頻度と時間の過剰）の両方を記録しています。スクラムマスターに送るならこれです。
Stray, V., Moe, N. B., and Bergersen, G. R. (2017). “Are Daily Stand-up Meetings Valuable? A Survey of Developers in Software Teams.” XP 2017, Lecture Notes in Business Information Processing. プロの開発者への調査。報告されている数字には、アジャイルチームの87%がデイリースタンドアップを実施していること、評価の平均が中立あたりであること、ジュニアの開発者ほど肯定的で、シニアの開発者や大きなチームほどそうではないことが含まれます。私は割合ではなく方向性のほうを使いました。
Stray, V. and Moe, N. B., practitioner writing in IEEE Software on adapting daily stand-up practice. 硬直したスタンドアップの儀式は、そのまま踏襲するのではなくチームに合わせて適応させるべきだ、と論じています。正確なタイトルと年は確認できていません。ネット上に出回っている版には、私が確認できなかった参加者数が含まれています。
Leroy, S. (2009). “Why is it so hard to do my work? The challenge of attention residue when switching between work tasks.” Organizational Behavior and Human Decision Processes, volume 109, issue 2. アテンション・レジデューの出発点。タスクの切り替えが、そのあとに来る仕事の質を落とすことを示した、アジャイル圏外からの強い証拠です。
Mark, G., Gudith, D., and Klocke, U. (2008). “The Cost of Interrupted Work: More Speed and Stress.” CHI 2008. および Mark, G. (2023). Attention Span. Hanover Square Press. 中断された仕事についての知見と、どこでも引かれる「およそ23分」という復帰時間の出どころです。この数字自体は本物ですが、元の研究が支えている以上の精度で引用されがちなので、一次資料を引いたうえで「20分以上」と書くのが安全です。
Rogelberg, S. G. (2019). The Surprising Science of Meetings. Oxford University Press. 会議の無駄と、会議後の回復についての定番の参考文献。数字は調査によってばらつくので、私は特定の割合ではなく定性的な知見のほうを使いました。
Microsoft Human Factors Lab, EEG study on breaks between meetings, published via Microsoft WorkLab and the 2021 Work Trend Index. 連続する会議のあいだにストレスが積み上がること、休憩がそれを減らすことを示した生理学的な証拠。調査ではなく計測である点が役に立ちます。
Edmondson, A. (1999). “Psychological Safety and Learning Behavior in Work Teams.” Administrative Science Quarterly. 心理的安全性の基礎文献。スタンドアップに限った話ではなくチーム一般についての研究なので、因果関係を言いすぎないでください。
Rietze, S. and Zacher, H., research on daily stand-up meetings, psychological safety, work satisfaction and team performance perceptions, European Journal of Work and Organizational Psychology. スタンドアップを支持する、公表されているなかでいちばん強い論拠です。だからこそ、自分から持っていくべきものです。刊行年は確認できていません。出回っている版は2025年という日付を出していますが、独自に確認することはできませんでした。
Forsgren, N., Storey, M.-A., Maddila, C., Zimmermann, T., Houck, B., and Butler, J. (2021). “The SPACE of Developer Productivity.” ACM Queue. 無料で読めます。デリバリーの指標と並べてチームパルスを測る根拠として、満足度とウェルビーイングの次元を使ってください。
Forsgren, N., Humble, J., and Kim, G. (2018). Accelerate: The Science of Lean Software and DevOps. IT Revolution Press. DORAの四つのデリバリー指標の出どころ。そのうちのひとつをスループットの指標に使えば、その場しのぎで発明した指標ではなく、擁護できる指標になります。
Graham, P. (2009). “Maker’s Schedule, Manager’s Schedule.” paulgraham.com/makersschedule.html. 短く、無料で、迷っている同僚に転送するのにいちばん効きます。
GitLab all remote handbook, about.gitlab.com/company/culture/all-remote. 非同期のステータス更新で動いていることを公開している大組織。このモデルが大規模でも機能する証拠ですが、GitLab自身がこの主張に利害を持っている点は割り引いてください。
Shopify calendar purge, January 2023, as reported by Bloomberg, Fortune and others. 社内カレンダーから数千件の定例会議を削除し、水曜は3人以上の定例会議を禁止したと報じられました。取り戻した時間の具体的な数字は会社の発表なので、計測された事実としてではなく、Shopifyの主張として扱ってください。
Atlassian Agile Coach, standup guidance. スタンドアップは短く保ち、非同期の形式も含めてチームの必要に合わせて適応させるべきだ、という業界向けのガイダンス。あなたのマネージャーがアジャイルの実践についてすでに信頼している出どころなので、その分だけ効きます。
ツール： SlackとTeamsでの非同期スタンドアップにはGeekbotとStanduply、チームのチェックインにはRange。社内で薦める前に、現在の価格と提供状況を確認してください。
Rubinstein, J. S., Meyer, D. E., and Evans, J. E. (2001). “Executive Control of Cognitive Processes in Task Switching.” Journal of Experimental Psychology: Human Perception and Performance. タスク切り替えで「生産的な時間の最大40%」が失われるという主張の、本当の出どころ。崩れて伝わった版を繰り返す代わりに、自分で確かめられるように挙げておきます。