単なる立っているだけではない：デイリースタンドアップミーティングのパターン

全員参加

さまざまな分野（マーケティング、生産サポート、上級管理職、トレーニングなど）の人々や代表者は、プロジェクトの状況や進捗状況を知りたい、または貢献したいと考えています。複数のミーティングやレポートで状況を伝えるには、多くの重複作業が必要です。

したがって

ミーティングやレポートの一部またはすべてをデイリースタンドアップに置き換えます。プロジェクトの日常業務に直接関与している、または知りたいと思っている人は誰でも、単一のデイリースタンドアップミーティングに参加する必要があります。

しかし

直接関与していない人は、期待される行動が不明瞭な場合、スタンドアップを妨害する可能性があります。これは、事前に新しい参加者や観察者に期待される規範を知らせるだけで対処できます。

すべてのレポート形式が、スタンドアップ形式でカバーされるべきではありません。たとえば、全体的なプロジェクトの進捗状況は、バーンダウン、バーナップ、累積フロー図などの大きな見えるチャートでより適切に伝えられます。

作業項目が参加する

別名：ストーリー重視のスタンドアップ

ストーリーがプロジェクトにとって非常に重要である場合、それらはスタンドアップで話すべきです。

-- Brian Marick、「Latour 3：炭疽菌とスタンドアップ」

人々はランナーに焦点を当て、バトンに焦点を当てないことに集中しすぎている。つまり、誰もが忙しいが、必ずしも作業項目を進めているわけではない。

したがって

デイリースタンドアップを人々の儀式と考えるのではなく、作業項目が参加する（たとえば、アジャイルのコンテキストではユーザーストーリー）儀式であり、人々は作業項目のために話すためだけに参加すると考えましょう…明らかに作業項目が実際に話すことはできないためです。

昨日、今日、障害の質問は引き続き使用できますが、人の視点ではなく、作業項目の視点から行われます。これは、すべての人が話す必要がないことも意味します。作業の進捗状況に関連しないことは何も言う義務はありません。

より明確な焦点のため、促しなしに人々が障害を提起し、障害の解消にサインアップする可能性が高くなります。

しかし

話す義務がないと、恥ずかしがり屋の人やそうでない人など、何も言わない傾向のある人の問題が見過ごされる可能性があります。これは、作業項目に焦点を当てていると検出するのがより困難になります。

昨日、今日、障害

別名：3つの質問

話し好きで、物語を語ることに迷う人もいます。一部の人は、問題を聞いた直後に問題解決に取り組みたいと考えています。時間がかかりすぎるミーティングは活気が低く、長い議論に直接関係のない参加者は気を散らしがちです。

したがって

次の形式を使用して貢献を構成します。

1. 昨日は何を行いましたか？
2. 今日は何を行いますか？
3. 私の進捗を妨げている障害は何ですか？

これらは、デイリースタンドアップの目標を満たす最小限の質問の数です。その他の議論のトピック（デザインの議論、噂話など）は、ミーティングの後まで延期する必要があります。

Olve Maudalは、重要性の正しい順序を強調するために、質問の順番を逆にする必要があると提案しました。

1. 何か障害はありますか？
2. 今日は何に取り組んでいますか？
3. 昨日以来、何を完了しましたか？

-- Olve Maudal, "Daily Stand-up Meetings - Perhaps the third question should go first?"

Lasse Koskelaは、チームメンバーが**リーダーへの報告**にならないよう、これらの質問の別の形式を提案しました。

各チームメンバーは、同僚に状況をアップデートします。

順番に、各チームメンバーは同僚に3つの情報を提供します。

1. 昨日のミーティング以来行ったこと
2. 今日行うこと
3. 誰かに解決してもらわなければならない障害

-- Lasse Koskela, "On Scrum and the curse of the three questions"

Jonathan Rasmussenは、スタンドアップのダイナミクスを変えるために、異なる言い回しを提供しました。

• 昨日世界を変えるために何をしましたか？
• 今日はどのように成功させますか？
• あなたの邪魔をする不幸な障害をどのように突破しますか？

このような質問に答えることで、スタンドアップのダイナミクスが完全に変わります。ただ立ってアップデートするのではなく、すべてを明らかにし、宇宙に自分の意図を宣言することになります。

-- Jonathan Rasmusson, The Agile Samurai

追加の質問を追加したチームも数多くあります。

Bufferでは、自己改善に取り組んでいることを共有するセクションを追加しました。

Thomas Cagleyはリスクの洗い出しを提案しています。

Mark Levisonは、よりターゲットを絞った改善に関する質問を追加することが有用であることを発見しました。最後の2つの質問は、特定のコンテキストに合わせて変更されます。

1. 昨日何を完了しましたか？
2. 今日何に取り組みますか？
3. 障害は何ですか？
4. 昨日、どのようなコードの臭い/不足している単体テスト…を発見しましたか？
5. 昨日、コードにどのような改善を行いましたか？

-- Mark Levison, "Daily Stand-Up Variations"

しかし

構造は、質問への回答が提供する情報ほど重要ではありません。情報がより構造化されていないプロトコルで提供されている場合、チェックリストに固執する必要はありません。チームが成熟するにつれて、このパターンがすでに進化してきたように、構造を調整したいと思うかもしれません。

より大きな問題は、**昨日、今日、障害**が、適切なことに注意を払うことよりも個人のコミットメントに過度に焦点を当てているかどうかということです…これは**ボードを巡回する**につながります。

改善ボード

**別名:** 障害ボード、カイゼン新聞

スタンドアップで提起された障害は、タイムリーに解決または対処されません。

したがって

提起された障害を**改善ボード**に投稿します。これは、提起された障害を特定し、その解決の進捗状況を追跡する、公開されているホワイトボードまたはチャートです。**改善ボード**はスタンドアップ以外でも更新でき、障害を最初に提起するより直接的で、おそらくより対立が少ない方法として機能します。よくある間違いは、遠くから障害を読み取れるように十分に大きく書かないことです。

問題を書き留めるという単純な行為、そしてそれによって明示的に認識することは、長引く会話を減らす非常に信頼できる方法です。したがって、特定の項目が障害であることに全員が同意するわけではない場合でも、会議終了後に話し合うために書き留める価値があります。

提起された各障害に発生回数を追加することで、一般的に最初に処理する必要がある問題を強調表示します。

ボードのデザインはいくつかの方法で異なる場合があります。たとえば、次の表のような構造です。

別のスタイルは、タスクボードのようなものです。

しかし

チームが解決に影響を与えない多くの障害が**改善ボード**に提起されると、**愚痴ボード**に退化してしまうリスクがあります。

最後に到着した人が最初に話す

スタンドアップ中、参加者は誰が最初に話すのかを知る必要があります。ファシリテーターが誰が最初に話すかを決定することは、自己組織化に対する微妙ながらも明確な力です。チームは、介入なしに誰が最初に話すかを知るべきです。

したがって

**最後に到着した人が最初に話す**ことに同意します。これは、スタンドアップへの参加を促すという追加の利点もあるシンプルなルールです。

しかし

最後に到着した人は、会議をうまく開始する準備が最もできていない人である可能性もあります。

ラウンドロビン

スタンドアップ中、参加者は誰が次に話すのかを知る必要があります。ファシリテーターが誰が次に話すかを決定することは、自己組織化に対する微妙ながらも明確な力です。チームは、介入なしに誰が次に話すかを知るべきです。

したがって

**ラウンドロビン**のような事前に決められたシンプルなルールを使用して、誰が次に話すかを決定します。時計回りか反時計回りかは問題ではありません。重要なのは、ファシリテーターやマネージャーではなく、チームが会議を運営することです。

トークンを渡す

シンプルで予測可能な順序付けメカニズム（例：**ラウンドロビン**）では、参加者が自分の順番が近づくまで、他の発言者を無視することが非常に簡単です。他の人が言っていることに注意を払うのではなく、他のことを考えがちです。

したがって

発言トークン（例：ボール）を投げて誰が次に話すかを決定するなど、予測不可能な順序付けメカニズムを導入します。発言トークンがあれば、誰が最初に話すかを決定することも簡単になります。トークンを取得した人（またはトークンを最初に投げた人）が最初に話すからです。

何かを投げ回すことは、デイリースタンドアップの儀式に少し楽しみを導入し、他の観察チームへの良い感染メカニズムとして機能します。

私はSimon Stewartと一緒にいたプロジェクトで初めてこのパターンを学びました。私たちは小さなジャグリングボールを使用しましたが、ほとんど何でもトークンとして使用できます。ラグビーボールやぬいぐるみを使用しているチームもあります。

しかし

チームが大きくなると、誰がすでに話したかを覚えるのが難しくなる場合があります。そのような場合は、**ラウンドロビン**のようなよりシンプルなメカニズムに固執する方が簡単かもしれません。

組織やチームの文化によっては、ボールを投げ回すことが非専門的と見なされ、根本的な儀式に対する不必要な否定的な認識を生み出す可能性もあります。

カードを取る

スタンドアップ中、参加者は誰が最初に話すのか、そしてその後誰が次に話すのかを知る必要があります。ファシリテーターが誰が話すかを決定することは、自己組織化に対する微妙ながらも明確な力です。チームは、通常は手にコーヒーカップを持っているため、**トークンを渡す**ことに熱心ではありません。

したがって

各チームメンバーが話す順番を決めるために**カードを引く**ことを想像してください。それぞれに番号が書かれたカードの山があるとします。各チームメンバーが会議に来ると、カードを選択し、そのカードが話す順番を示します。

ボードを巡回する

**別名:** ウォールを巡回する

スタンドアップは全員を忙しくさせます。ボードを巡回することで、全員が最も重要なことに集中できるようになります。

-- Bret Pettichord via Twitter

従来の形式のもう1つの問題は、タスクやワークストリームが首尾一貫して議論されないことです。代わりに、各トピックは、チームメンバーが話す順番に応じて簡単に取り上げられます。これにより、何が実際に起こっているのかを判断するのが難しくなる可能性があります。

-- Dave Nicolette, "An alternative format for the daily stand-up"

人々は実際に作業を進めるよりも忙しいことに集中しているため、**作業項目が参加する**モデルに切り替えました。しかし、この作業項目に焦点を当てたスタンドアップでも、**ラウンドロビン**や**トークンを渡す**などの一般的な順序付けメカニズムを使用すると、何が起こっているのかを理解するのが困難です。

したがって

**ボードを巡回する**、つまり、ビジュアルマネジメントボードに表示されている各作業項目を順番に見ていくことでスタンドアップを構成します。

ほとんどのアジャイルとリーンチームは、作業中の内容を明らかにするためにビジュアルマネジメントシステムを使用します。アジャイルソフトウェア開発では、これは「タスクボード」、「ストーリーウォール」、または「カンバンボード」と呼ばれる場合があります。これらのボードは、作業項目が移動するプロセスを示します。進捗状況は、通常、カードをボード上で物理的に移動させることで表されます。理想的には、垂直方向の位置付けが優先順位を示します。

このボードがあれば、スタンドアップはプロセスの終わりから始まりまで（例：右から左）、そして最高から最低の優先順位まで（例：上から下）各作業項目を順番に見ていきます。ボード上に使用する順序を明示的に示すこともできます。

Pawel Brodzinskiはデフォルトのシーケンスを提案しました。

1. ブロッカー
2. 緊急事項
3. 前回のスタンドアップ以来移動していない項目（おそらく詰まっている項目）
4. 優先順位によるその他のすべて

しかし

明らかに、ボードがあることが前提条件であり、すべてのチームが持っているわけではありません。その場合は、一人ずつ構造の方が適切です。

**ボードを巡回する**は、**ファシリテーターをローテーションする**など、自己組織化のパターンが適用されていない場合、**リーダーへの報告**に陥る傾向がはるかに高くなります。

作業が行われる場所でミーティングを行う

会議室ではなく、現場でミーティングを行います。

-- Marc Graban, "Video of a Daily Huddle at Everett Clinic"

職場には、何が起こっているかについての多くの記憶のトリガーがあります。

また、デイリーミーティングで多くのオーバーヘッドを調整、検索、部屋への移動を必要とすることも望んでいません。

したがって

会議室ではなく、**作業が行われる場所でミーティング**を行います。「ストーリーウォール」や「カンバンボード」がある場合は、その前でミーティングを行います。

しかし

近くの他のユーザーは、ミーティングのノイズが邪魔になる可能性があります。これは通常、根本的なワークスペース設計の悪さを示していますが、それでも認識する必要があります。

同じ場所、同じ時間

チームにスタンドアップの所有権を持たせたいと考えています。また、関心のある人がスタンドアップを観察するために立ち寄ることができるようにし、別の状況報告会議をスケジュールする必要がないようにしたいと考えています。特定のチームメンバーがスタンドアップの遅延や場所の変更を強制することを許可している場合は、これは困難です。

したがって

チームに**同じ場所、同じ時間**でデイリースタンドアップを行うことに同意させ、運営させます。建築家やマネージャーを含む、遅れてくる人を待つ必要はありません。会議は特定の個人ではなく、チーム全体のためです。これは、**スタンドアップを使用して1日を始める**場合に特に重要です。

より厳格なチームでは、遅刻者に対して「罰金」を科す場合があります。私はどのような種類の罰則メカニズムにも警戒しており、話し合いを好みます。

しかし

**同じ場所、同じ時間**は、盲目的に柔軟性がないことを意図したものではありません。重要なのは、開始時間がほぼ一貫していて、再スケジュールがまれであることです。再スケジュールが必要な場合が多い場合は、開始時間を変更する必要があることを示している可能性があります。特定の場所が全員にとって行きにくい場合は、場所を変更する必要があることを示している可能性があります。

スタンドアップミーティングで1日を始める

デイリースタンドアップミーティングは、未解決の問題に焦点を当て、認識を高めます。それが1日の後半に行われる場合、この焦点と認識は無駄になります。

したがって

1日の開始をスタンドアップミーティングで始める フレックスタイム制の場合、チームメンバー全員が同時に勤務を開始するとは限りません。フレックスタイム制における一般的な慣習として、コアタイムを設定することがあります。ミーティング開始時間は、このコアタイムの開始時間に設定する必要があります。同様に、チームメンバーが個人的な理由（子供の学校への送迎など）で遅れて到着する必要がある場合は、全員が出席できる時間帯に開始時間を設定する必要があります。

しかし

スタンドアップミーティングまでプロジェクト関連のタスクに取り組まない傾向があるかもしれません。スタンドアップミーティングが遅れて開始した場合、この無駄な時間は大きくなる可能性があります。ある程度は、メールチェックやタイムシートの記入などに充てることもできますが、スタンドアップミーティングを1日の「開始」儀式としてではなく、1日の後半にスケジュールすることで、この儀式を取り除くことを検討する価値があるかもしれません。

スタンドアップミーティングで1日を始めてはいけない

特に1日の開始をスタンドアップミーティングで始める場合、スタンドアップミーティングは1日の焦点を設定する儀式として機能する傾向があります。このため、チームメンバーはスタンドアップミーティングまで機能開発に取り組まない傾向があります。ミーティングが実際には最初に開催されない場合、この傾向は生産性に大きな影響を与える可能性があります。

したがって

1日の開始をスタンドアップミーティングで始めない デイリースタンドアップミーティングを1日のかなり後の時間帯にスケジュールして、心理的に1日の開始と関連付けられないようにします。

しかし

デイリーミーティングが1日の開始ではない場合、それはもはや1日の開始時にチームの焦点を設定する共有された儀式として使用することはできません。チームによっては、この犠牲は、見かけ上の効率の向上に見合う価値がない可能性があります。

スタンドアップミーティングを使用するプロジェクトが多い場合、複数のスタンドアップミーティングが同時に発生する可能性があります。複数のプロジェクトに関心のあるオブザーバーは、出席できるようにスタンドアップミーティングの時間を変更したいと思うかもしれません。これは、オブザーバーが自分のスケジュールに合わせてスタンドアップミーティングの調整を強制できる場合、チームのオーナーシップ感が損なわれるリスクがあるため、問題となります。それにもかかわらず、デイリースタンドアップミーティングをいつ行うかを決める際には、これも考慮する必要があります。

ハドル

私が頻繁に見かける問題は、人々がデイリースタンドアップミーティングを単なる個別の報告とみなす傾向があることです。「私はこれを行い…、次はこれを行う」—そして、次の参加者へ。より最適なアプローチは、フットボールのハドル（作戦会議）に近いです。

-- ジェフ・サザランド、「デイリースタンドアップの起源」

発言量も、注意力のレベルとコミュニケーションの有効性に影響を与えます。物理的な距離は、効果的なコミュニケーションに必要な音量のレベルを変えます。大声で話せない、またはそうするのが快適ではない人もいます。

発言量も、注意力のレベルとコミュニケーションの有効性に影響を与えます。物理的な距離は、効果的なコミュニケーションに必要な音量のレベルを変えます。大声で話せない、またはそうするのが快適ではない人もいます。

したがって

スタンドアップミーティングは、ミーティングというよりハドルであるべきです。聞き取りにくい場合は、全員を近づけてください。よりリラックスした音量を可能にするだけでなく、物理的に近づくことで、参加者は自発的により注意深くなる傾向があります。物理的に近づくことができることは、チーム内での信頼性の向上も表しています。スタンドアップミーティングが新しいものであれば、身振りで参加者を招き入れ、「もう少し集まりましょう」と言うだけで十分です。円がしばらくの間確立されている場合は、円を小さくしようとする前に、その理由を説明することを検討してください。

しかし

チームは、親密さと個人的な快適ゾーンのバランスを取らなければなりません。非常に信頼し合っているチームでも、人が近すぎるために不快に感じる場合があります。症状としては、参加者が緊張したり、落ち着きがなくなったりすることがあります。

立ち上がる

話し好きで、ストーリーテリングに話が逸れる傾向のある人もいます。問題を聞いた後すぐに問題解決に取り組みたい人もいます。長すぎるミーティングは、エネルギーが低下し、長い議論に直接関係のない参加者は気を散らしがちです。

したがって

ミーティング中は、すべての参加者に立ち上がってもらう。身体的準備と精神的準備を結びつけるために立ち上がることを使用する。身体的不快感も、ミーティングが長すぎることを参加者に思い出させます。これを促す簡単な方法は、単に椅子がない場所でミーティングを開催することです。

しかし

立ち上がるとミーティングが短くなる傾向がありますが、最適な長さになることを保証するものではありません。不快感を我慢することを学ぶ人もいるかもしれません。また、ミーティングが長すぎず、話題が逸れていない場合は、立ち上がるのは不必要な儀式です。

15分以内

ほとんどの人は、長いミーティング中に精神的にさまよいます。長く退屈なミーティングは、1日を始めるのに最悪で、エネルギーを消耗するやり方です。具体的な数字は、ミーティングの時間を短縮するために調整を検討する時期を思い出させてくれます。

したがって

デイリースタンドアップミーティングを15分以内に保つ。一般的なルールとして、15分後には、平均的な人の心はさまよい始め、焦点を設定するのに役立ちません。

しかし

15分でも、小規模なチームには長すぎる可能性があります。心がさまよってしまう効果のために、大規模なチームにとっても15分は良い制限です。また、ミーティングが短すぎて、終了時に参加者が何が起こっているのか、またはそれを知るために誰と話すべきなのかが分からなくなる可能性もあります。

終了を知らせる

最後の人が話を終えた後、チームはミーティングが終わったことにすぐに気付かないかもしれません。立ち去る時間になったという漸進的な認識は、ミーティングを有終の美で終わらせることができず、エネルギーの低下に繋がる可能性があります。

したがって

何気ない言葉（例：「では、皆さん、ランチ楽しんでください」）やその他の行動で、スタンドアップミーティングの終了を知らせる。

ミーティングの時間を計る

スタンドアップミーティングが長すぎるかどうかを質的に判断するのは困難です、特に長さが徐々に増加している場合。

したがって

ミーティングの時間を計測するとその結果を公開する。ほとんどの場合、参加者は、ストーリーテリング、オフラインで対処する準備ができていないこと、または準備不足がミーティングにかかる時間の長さに与える影響に気づいていません。定量化しましょう。

しかし

すべての測定と同様に、エネルギーレベルの問題のために達成すべき具体的な目標がない限り、ミーティングの時間を計測することは導入すべきではありません。目標が達成されたら、測定は中止する必要があります。特に理由もなく測定すると、疑念と指標への無関心が生まれます。

時間は、エネルギー、注意、ペースの代理指標です。時間よりも、これらのことに注意を払いましょう。

オフラインで対応する

問題を聞いた後すぐに問題解決に取り組みたい人もいます。長すぎるミーティングは、エネルギーが低下し、長い議論に直接関係のない参加者は気を散らしがちです。提起された問題を解決するためには、さらなる議論が必要であることを認識することが依然として重要です。割り込みによってスタンドアップミーティングの構造を強制することを不快に感じる人もいるかもしれません。

したがって

デイリースタンドアップミーティングの外でそのような議論を行うべきであることを思い出させるために、「オフラインで対応する」などの簡潔で一貫したフレーズを使用する。議論が雑談であれば、それ以上の対応は必要ありません。議論が問題解決であれば、ファシリテーター（そして最終的にはチーム）は、適切な人が指名されるか、後で問題に対処するために登録するようにする必要があります。

あるいは、より間接的な合図を使用するチームもあります。

例えば、マイク・コーンは、「我々は間違った方向に進んでいる」ことを示すためにゴム製のネズミを使用する方法について説明しています。

ベンジャミン・ミッチェルは、ツーハンドルールについて説明しています。

…現在の会話が話題から外れた、またはもはや効果的ではないと考えている人がいたら、手を上げます。2人目が手を挙げたら、会話に終止符を打ち、残りのスタンドアップミーティングを続ける合図となります。発言者は、スタンドアップミーティング終了後に会話を続けることができます。

-- ベンジャミン・ミッチェル、「長すぎるアジャイルスタンドアップミーティングに悩まされていますか？ ツーハンドルールを試してみてください」

しかし

問題解決と明確化のための質問には違いがあります。理解されていない情報は役に立ちません。明確化のための質問が許容される範囲は、チームの規模と15分以内に影響を与えるかどうかによって異なります。

ファシリテーターをローテーションする

チームメンバーはリーダーに報告している、つまり、互いにではなく、ミーティングのファシリテーターのみに話している。ミーティングのファシリテーターだけが、スタンドアップミーティングに関連するプロセス上の問題を提起し、対処している。チームにスタンドアップミーティングのオーナーシップを持たせたいので、単一のファシリテーターへの依存を取り除く必要があります。

したがって

ファシリテーターをローテーションする。スタンドアップミーティングへの参加と合意されたルールへの遵守を保証する役割の割り当てをローテーションする。

しかし

スタンドアップミーティングを経験していないチームは、このプロセスに精通したコーチがいることで大きな恩恵を受けます。チームがスタンドアップミーティングをよりコントロールできるようにする必要があります。ある時点で、明示的なファシリテーターはまったく必要なくなります。

視線を切断する

チームメンバーはリーダーに報告している、つまり、互いにではなく、ミーティングのファシリテーターのみに話している。チームにスタンドアップミーティングのオーナーシップを持たせたいので、単一のファシリテーターへの依存を取り除く必要があります。

したがって

ファシリテーターは、話している人にチーム全体に話しかけるべきであることを優しく思い出させる方法として、視線をそらすべきです。そのためには、現在の発言者がファシリテーターを見ることができないように移動するなどがあります。

ランナーに焦点を当て、バトンに焦点を当てない

人々は自分が行っていることに集中しすぎているものの、自分の活動が実際に作業を進めているかどうかを検討することを怠っています。スタンドアップミーティングを、作業項目が参加するように再構成します。

リーダーへの報告

チームメンバーは、チームではなく、マネージャーまたはミーティングのファシリテーターに目を向け、話しかけています。これは、デイリースタンドアップミーティングが実際にはチームのためであるべきなのに、マネージャー/ファシリテーターのためになっていることを示しています。この依存性を解消する方法はいくつかあります。ファシリテーターをローテーションする、視線をそらす、Yesterday Today Obstaclesの形式を変更する、トークンを渡すなど。

人が遅刻する

これは同じ場所、同じ時間によって直接的に対処されますが、前述のように、スタンドアップミーティングが間違った時間または間違った場所で開催されていることを示している可能性があります。

罰則を課すなど、これに対応するための他のパターンもありますが、一般的にはお勧めしません。なぜなら、それは問題が外的な動機付けに関するものであることを示唆しているのに対し、実際にはもっと他の何かである可能性が高いからです。

スタンドアップミーティングが遅れて始まる

スタンドアップミーティングは1日の仕事の開始とみなされるため、それ以前には仕事は行われません。スタンドアップミーティングが午前中の遅い時間に行われる場合、利用可能な労働時間に大きな影響を与える可能性があります。このことから、**スタンドアップミーティングを1日の開始に利用しない**という結論に至ります。

雑談

スタンドアップミーティングの目的の1つは、チームの交流を増やすことです。しかし、毎日のスタンドアップミーティングは、チームメンバーがプロジェクトに関連しない事項について「近況報告」をするための場ではありません。チームによって交流がチームビルディングから気を散らすものへと移行する度合いが異なるため、これの例を挙げるのは困難です。その閾値は、交流に直接関わっていない参加者の行動から検知できます。彼らのエネルギーレベルが高いままだとすれば、それは単なるチームビルディングでしょう。彼らのエネルギーレベルが低下するならば、**オフラインで対応**し、ウォータークーラーのような役割を果たす別の場を提供することを検討すべきです。

思い出せない

昨日何をしたか…思い出せない…今日は何をやるか…わからない…

準備不足はペースの低下を引き起こし、エネルギーレベルの低下につながります。また、**15分以内**という目標の達成を危うくし、さらにエネルギーレベルを低下させます。

この問題を回避する良い方法は、**作業項目が参加**し、私たちが**ボードを巡回**するスタンドアップミーティングに切り替えることです。

そうでない場合、これは**昨日の障害、今日の対応**に対する責任感の期待の問題です。

物語を語る

問題の簡単な説明をする代わりに、参加者が詳細と文脈を十分に提供することで、他の人が注意を逸らす原因となります。一般的なルールは、スタンドアップミーティング中に障害を特定し、詳細についてはスタンドアップミーティング後に議論することです。「見出しを伝え、全体のストーリーは伝えなくて良い」または**オフラインで対応**と要約できます。

問題解決

問題提起とアイデアの提示のための時間であり、詳細な問題解決のための時間ではありません。

-- Marc Graban, "Video of a Daily Huddle at Everett Clinic"

スタンドアップミーティングを**15分以内**に収める鍵は、会議中に**ストーリーテリング**を制限し、**問題解決**に陥らないようにすることです。**オフラインで対応**。

活気が低い

**ストーリーテリング**、**問題解決**などによるペースの低下を示唆している可能性があります。その場合は**オフラインで対応**してください。単にチームの規模の問題かもしれません。時間帯の問題である可能性もあり、その場合は**スタンドアップミーティングを1日の開始に利用する**ことと**スタンドアップミーティングを1日の開始に利用しない**ことのどちらかの代替案を試してみることを示唆しています。

障害が提起されない

**別名：**旅日記

障害が提起されない理由はいくつか考えられます。覚えていない、耐痛閾値が高い、問題提起への信頼の欠如（**障害が解消されない**ため）、問題提起の便利な方法がないなどです。ファシリテーターは、人々が障害を提起するよう促すよう注意する必要があります。

**改善ボード**を導入することで、より対立が少ない手段を提供できる可能性もあります。レトロスペクティブは、**障害が提起されない**根本的な理由を発見する効果的な方法です。

障害が解消されない

非難の環境を除けば、人々が障害を提起するのを止める最も確実な方法は、障害を除去しないことです。障害を忘れやすくしたり、無視したりするのを難しくするために、**改善ボード**を使用して公開して追跡します。

スタンドアップミーティングでのみ障害が提起される

スタンドアップミーティングはセーフティネットとして機能します。最悪の場合でも、障害は1日以内にチーム全体に伝えられます。しかし、スタンドアップミーティングを行うことは、日中に問題が提起され解決されるのを妨げることを意図したものではありません。**改善ボード**などの障害提起のための代替手段を導入することで役立つ場合があります。そうでない場合は、レトロスペクティブを使用して根本的な理由を発見できる可能性があります。