エンジニアリングチームに最適なスタンドアップ質問（ヒント：あの3つではない）
従来のスタンドアップ質問はステータス劇場を生むだけで、シグナルになりません。本当に重要なことを浮かび上がらせる、より良い質問を紹介します。
By Chris Calo · 2026-03-26
1790年、英国海軍は航海当直報告の規則を正式化しました。4時間ごとに、当直将校は後任者に簡潔な報告を行いました：海況、風向きの変化、目撃した船舶、そして着任する将校が即座に対応すべき事項。この形式は徹底的に効率的でした – 水兵たちの注意力が短かったからではなく、紛争海域のフリゲート艦には儀式的なムダを許す余裕がなかったからです。変化したこと、リスクのあること、次の人物の判断が必要なことを報告する。それ以外はノイズです。
約230年後、エンジニアリングチームのスタンドアップ質問はこれを完全に逆転させました。儀式は保ったまま（同じ時間、同じ人々、同じ部屋またはZoomコール）、シグナルを失いました。「昨日何をしましたか？」は当直報告ではありません。コードを書きたい人々に毎日公開で行われるパフォーマンスレビューです。
（そして、他の誰かが話している間、自分の更新を頭の中でリハーサルしていたスタンドアップに何度も立ったことがあります。あなたもそうでしょう。そうでないふりをするのはやめましょう！）
私は長年、スタンドアップをうまく進められていませんでした。正直に告白します。義務的に輪を回り、1時間以内に忘れてしまう更新を収集し、なぜレトロで同じ問題が繰り返し浮かび上がるのか疑問に思っていました。質問そのものがボトルネックだと気づくのに、恥ずかしいほど長い時間がかかりました – 答える人ではなく。
3つのデフォルト質問とその問題点
あなたも知っているはずです。「昨日何をしましたか？今日は何をしますか？ブロッカーはありますか？」
エンジニアリングチームのスタンドアップ質問としてこれらは、原則的にはひどくはありませんが、実際には非常に特定の機能不全を生み出します。「昨日何をしましたか」は関連性ではなく記憶を最適化します – 実際に重要な2つのことではなく、誰かの火曜日の時系列的な語りが返ってきます。「今日は何をしますか」は、昼食までに誰も覚えていない小さなプロジェクト計画を生み出します。そして「ブロッカーはありますか」はデフォルトで「ない」と答えられます – あるジュニアエンジニアが6日間連続で「ブロッカーなし」と言いながら、チーム全体の前で認めたくなかった認証問題に静かに行き詰まっていたのを見たことがあります。公開で行き詰まっていることを認めるには、ほとんどのチームがまだ築いていない心理的安全性が必要です。
結果はいわゆる「ステータス劇場」です – 15分間、人々がお互いに作業の要約を朗読し、その後全員がミーティング開始前と全く同じ情報を持って解散します。生産的に感じます。しかし、生産的ではありません。
従来の3つのスタンドアップ質問は、情報フローではなく説明責任を最適化しています。作業が行われた「こと」は伝わりますが、今すぐ注意が必要なことは伝わりません。
より良いスタンドアップ質問（何を明らかにするかによる分類）
以下の質問は普遍的なテンプレートではありません – チームの現在の課題に合った2〜3つを選び、毎月ローテーションし、リハーサルされた答えが返ってきたら廃止してください。
リスクを浮かび上がらせる質問
- 「今一番リスクの高いことは何ですか？」 – 私の最も好きなスタンドアップ質問です！昨日の成果を飛ばして、今日うまくいかないかもしれないことに直接着地します。人々はリスクを知っていますが、直接聞かなければ自発的に言いません。
- 「予想より時間がかかっていることはありますか？」 – 「ブロッカーはありますか」より控えめですが、はるかに示唆に富んでいます。予想より時間がかかっているタスクは、まだ名前がついていない問題の最初の症状であることが多いです。
- 「今週最も自信がないことは何ですか？」 – 日々のスタンドアップより週次の同期に適していますが、後ろ向きのアクティビティログではなく早期警告リストを与えます。
依存関係を浮かび上がらせる質問
- 「誰かを待っているところはありますか？」 – これが依存関係検出器です。私が関わってきたほとんどのチームで、エンジニアリング作業は技術的な複雑さよりも、認識されていない依存関係で行き詰まります。3日間開いているPR、行われていないデザインレビュー、静かに延期された決定 – これらが実際のブロッカーです、誰もそう呼ばなくても。
- 「今日誰と話す必要がありますか？」 – より短く、より行動につながります。2人が「お互い」と答えれば、1日分の非同期のやり取りを節約できます。（これは実際にスプリント全体を救ったことがあります – 人々は5メートル歩いて話すより何日も並行して混乱し続けることがわかりました。）
学びを浮かび上がらせる質問
- 「前回のスタンドアップ以降、何が驚きましたか？」 – アーキテクチャの誤解を早期に捉えるのに最適です。（信じてください、アーキテクチャの誤解は常にあります。）あるエンジニアがAPIがドキュメントと異なる動作をすることを発見した場合、またはマイグレーションがチケットが示唆するよりも多くのテーブルに影響することを発見した場合、その驚きはどんなステータス更新よりもチームにとって価値があります。
- 「月曜日に知っていたらよかったと思うことは何ですか？」 – 週次の方がより有用です。でも、次のスプリントまでに忘れられてしまう組織的な知識を捉えます。
モラールを浮かび上がらせる質問（控えめに使用）
- 「今日のエネルギーは1〜5のスケールでどうですか？」 – リードが何年もかけて信頼を築いたチームで一度だけうまくいくのを見たことがあります。ほとんどの場合、侵襲的に感じます。使う前にチームを理解してください。
- 「この仕事は面白いですか？」 – カジュアルに聞こえますが、継続的に退屈な仕事はリテンションのシグナルです。誰かが3スプリント連続でマイグレーションタスクをこなしているなら、この質問でそう言う許可を与えます。
グループスタンドアップ vs 1対1：異なる形式には異なる質問が必要
これらのエンジニアリングチームのスタンドアップ質問がすべて同じミーティングに属するわけではありません。グループ設定では、素早く答えられ、参加者全員にとって有用な情報を生む質問が必要です。1対1では、より長く、より反省的な質問の余地があります。
グループスタンドアップ（2つ選び、週次でローテーション）：
| 質問 | 明らかにすること | 1人あたりの時間 | |------|----------------|---------------| | 今一番リスクの高いことは？ | 前向きなリスク | 約30秒 | | 誰かを待っているところは？ | 依存関係 | 約20秒 | | 何が驚きましたか？ | 隠れた複雑さ | 約30秒 |
1対1チェックイン（2〜3つ選ぶ）：
| 質問 | 明らかにすること | 時間 | |------|----------------|------| | 月曜日に知っていたらよかったことは？ | 学習のギャップ | 2〜3分 | | 予想より時間がかかっていることは？ | 新たなリスク | 1〜2分 | | この仕事は面白いですか？ | エンゲージメントとモラール | 1〜2分 | | あなたのために解決できることは何ですか？ | マネージャーのアクション項目 | 1分 |
グループスタンドアップは短く有用である必要があります。1対1は探索の余地があります – 聴衆は聞いたことに実際に対応できるコンテキストを持つ一人の人物だからです。
アンチパターン：より多くの作業を生む質問
一部のスタンドアップ「改善」は実際に状況を悪化させます。形式がエンジニアに会議前に書面の更新を準備させるなら、スタンドアップ前のスタンドアップ – 儀式のための準備の儀式 – を作っています。タスク完了の数値見積もりを要求するなら（「APIマイグレーションは何パーセント完了ですか？」）、楽観的な四捨五入を奨励するマイクロトラッキング演習を構築しています。そして、通話中にLinearボードを更新させるなら、同期的な会話を人々がタイプするのを見る15分に変えています。
（皮肉なことに、これらすべては「スタンドアップをより効率的にする」ために導入されました。儀式は利用可能な時間を埋めるまで成長し、その後礼儀正しくさらに要求します。）
スタンドアップの改善に準備時間が必要なら、オーバーヘッドを削減したのではなく追加しています。最善のスタンドアップ質問は、30秒以内に有用な答えを生み出し、会議前に誰も宿題をする必要がないものです。
明日から始められる実践的なセット
2週間試すための具体的なものが欲しいなら、これをお勧めします：
日々のスタンドアップ（3つの質問、厳密な15分タイムボックス）：
- 「今一番リスクの高いことは何ですか？」 – ブロッカーになる前に問題を捉えます。
- 「誰かを待っているところはありますか？」 – 見えない依存関係を可視化します。
- 「チームが知るべきことはありますか？」 – オープンエンドのキャッチオール、しかし「重要なことのみ」と枠組みされています。
それだけです。「昨日何をしましたか」はなし – ツールはすでにその情報をLinearボード、GitHubのアクティビティフィード、Slackスレッドに持っています。「今日は何をしますか」もなし – スプリント計画が最新なら、この質問は何も追加しません。ただ：何がリスクか、何が行き詰まっているか、何が驚きか。
2週間後もスタンドアップが儀式のように感じるなら、問題はおそらく質問ではありません。毎日の同期チェックインがチームに適した形式ではないかもしれません – これは到達すべき完全に合理的な結論です。英国海軍は18世紀に当直報告の形式を確立し、そして重要なことに、四半期ごとに再設計するのをやめました。時には最善のプロセス改善は、プロセスが必要ないと認めることです。
「英国海軍は18世紀に当直報告の形式を確立し、そして重要なことに、四半期ごとに再設計するのをやめました。時には最善のプロセス改善は、プロセスが必要ないと認めることです。」 – Chris Calo
the standup pattern for modern engineering teams what an effective engineering standup is actually optimising for standup updates assembled from real tool activity why status updates stop being useful Sugarbugがチームのアクティビティを自動的に表示します – スタンドアップがステータス報告をスキップして重要なことに集中できるように。
Q: エンジニアリングチームに最適なスタンドアップ質問は何ですか？ A: 正直に言うと、「今一番リスクの高いことは何ですか？」と「誰かを待っているところはありますか？」は、従来の3つよりはるかに効果的です。エンジニアリングチームの従来のスタンドアップ質問はステータス報告を最適化しています – 昨日誰が何をしたか – 実際に一日の進み方を変えるリスクと依存関係を浮かび上がらせるのではなく。
Q: Sugarbugはエンジニアリングのスタンドアップ自動化に役立ちますか？ A: SugarbugはLinear、GitHub、Slack、Figmaなどのエンジニアリングツールをナレッジグラフに接続し、前回のスタンドアップ以降の変更を自動的に表示します。昨日したことを朗読させる代わりに、Sugarbugが表示するので、スタンドアップはステータス報告ではなく、人間の判断が必要な会話に集中できます。
Q: エンジニアリングのスタンドアップはどのくらいの時間がかかるべきですか？ A: 5〜8名のチームであれば、15分が上限です。それ以上かかる場合、低価値な情報を多く生み出す質問をしているか（「昨日何をしましたか？」がその代表）、チームが別のミーティングが必要な問題を解決しています。1人あたり2分が目標として合理的です。
Q: Sugarbugは日々のスタンドアップミーティングを置き換えられますか？ A: Sugarbugはスタンドアップを置き換えるのではなく、その中のステータス報告の部分を置き換えます。GitHub、Linear、SlackからのアクティビティをSugarbugが一つのビューに集約することで、「昨日何をしましたか」という質問は自動的に答えが出ます。残るのは、同期的であることから実際に恩恵を受けるスタンドアップの部分です：リスク、依存関係、そして部屋全体の注意が必要な決定。
Q: スタンドアップ質問を効果的にするものは何ですか？ A: 30秒以内に新しい情報を生み出し、準備がゼロで、チームがまだ知らなかったことを浮かび上がらせることです。人々が毎日同じリハーサルされた答えを出し始めたら（わかります – 聞こえます）、その質問を廃止して別のものを試してください。最善のスタンドアップ質問には有効期限があります、それで問題ありません。
スタンドアップがステータス報告よりも実際の決定に多くの時間を費やしているなら、Sugarbugが報告部分を自動的に処理できます – 15分間が本当に人間が必要なことに使われるように。