以下の文章は、Jason YipによるIt’s Not Just Standing Up: Patterns of Daily Stand-up Meetingsの日本語訳である。Jasonの許可を得て、ここに掲載する。

立ってやるのはミーティングの時間を短くするためだ

朝会（デイリー・スタンドアップ・ミーティング、デイリー・スクラム、デイリー・ハドル(訳注：ハドルとは群になって集まること)、朝のロールコール(訳注：ロールコールとはメンバが順番に答えていく方式)を説明するのは簡単だ。チーム全員が毎日顔を合わせ、現在の状況を迅速に確認しあう。立ってやるのはミーティングの時間を短くするためだ。以上。 でもこれだけじゃあ、「良い朝会」と「悪い朝会」の微妙な違いは分からないだろう。

朝会の定義は非常に簡単なものなのに、 うまくいっていない朝会があって私はとても驚いた。 すぐに原因は分かったが、そのチームはそれが何なのか分かっていなかった。 朝会の基本原則と詳細を意識していなかったのだ。 そのために朝会の問題について診断や解決がなされていなかったわけだ。

良い朝会を経験した人たちは、 うまくいってないときに何をすればいいかを知っている。 朝会に慣れていない人たちは、 うまくいってないときに何をすればいいかに気づかない。 「暗黙知なんだから、とにかく良い朝会に参加してみるといい」。 そう言ってしまうのもひとつの方法だが、慣れていない人たちは何か支援がないとすぐに朝会をやめてしまうと思う。 良い朝会はプロジェクトに劇的な価値をもたらすというのに、これではあんまりではないか。

本論文は、これまでに恩恵を受けてきた暗黙知と朝会の一般的なプラクティスの重要性を伝えることを目的としている。 朝会のパターンは新参者への助けとなるように書かれているが、 熟練者にとってもこれまでの経験知への気づきとなるだろう。

基本テーマは「自己組織化」

朝会の基本テーマは「自己組織化」である。 自己組織化は生産性を向上させるだけでなく、おそらくそれ以上に、人間味のある、尊敬の念のある、成熟した仕事環境をもたらす。 朝会を実行する際に問題となるものの多くは、この自己組織化という動機付けをし損ねたことに起因している。

自己組織化とは、特定のチーム、組織、国などの文化固有の美徳ではない。 チーム全体が成功に対する責任にコミットしなければ、 チームのパフォーマンスは必然的に悪化するだろう。

朝会の目的は？

論文や参考文献（[Anderson, 2002], [Beedle et al., 2000], [Cochango, 2006], [OrgPatternsStandUp], [Rising, 2002], [Rising and Janoff, 2002], [Wells, 1999]）を要約すると、朝会は以下の目標を達成しなければならない。

  • コミットメントの共有
  • チームとオブザーバに対する日々の状況、進捗、計画の報告
  • 問題点を明確化し、チームがそれを乗り越えられるようにする
  • 進むべき方向と焦点の設定
  • チームの形成

コミットメントの共有

チームとしてのコミットメントを毎日確認し合うのは、朝会で最も重要な目的である。 コミットメントの共有は進捗や状況の共有よりも重要だ。 これは、オブザーバが進捗や状況を確認できないということではない。 お互いに公にコミットし合い、コミットメントを阻害する問題点を明確化しているチームメンバにとって、それは二次的なものなのだ。

状況の報告

ミーティングではアーキテクチャにおける技術的進捗と作業計画に着目する。[OrgPatternsStandUp]

状況の報告は普通の状況報告会議と大差がない。 決定的な違いは、マネージャではなく、チームがお互いに状況を更新し合うというメカニズムだろう。 状況を毎日更新することで、チームが今何をやっているかを少なくとも日次単位で確認することができる。

問題点を明確化

スクラムミーティングでチームメンバが問題点を共有すると、チームは一丸となって問題に立ち向かう。なぜならチームは共有した目標に向かって一緒に働いているからだ。チームメンバは目標に向かって協力し合わなければならない。個人の問題をすぐにチーム全体の問題にするのだ。[Rising and Janoff, 2000]

問題点の発見と除去を早期に行うと、チームは勢いを持続することができる。 朝会が問題点を除去するわけではないが、問題点を特定し、他のチームメンバがそれを助ける「場」を朝会は提供している。

進むべき方向と焦点の設定

朝会では、スクラムマスターがバックログアイテムの優先度を強調する。これは間違った方向に進みやすい新しいチームメンバにとって特に役に立つ。[Rising and Janoff, 2000]

我々はみんなに同じ方向に進んでもらいたい。 朝会は進むべき方向を頻繁に思い出させてくれる。

チームの形成

定期的にコミュニケーションしたり、仕事をしたり、助け合ったりすることで、有能なチームが形成されていく。 見せかけだけの“チーム形成”トレーニングなんかよりもずっと効果的だろう。 助け合ったり、問題点を共有したりすることで、チームはより強力に結びつくのである。

毎日（問題が解決するまで）話を聞くため、チームはメンバの問題に気付くことができる。 このような環境だと、問題が起こったときに他のメンバが助けてくれるんだという実績が作られ、それによって問題を報告しやすくなる。

良い朝会には特別な雰囲気がある

毎日全員が立ってミーティングをすれば、“デイリー・スタンドアップ・ミーティング”になるのかもしれない。 だが、良い朝会には特別な雰囲気があり、形だけの儀式なんかとは全然違うのだ。

最初の説明で、朝会はデイリー・スクラム[Beedle et al., 2000]とも呼ばれると述べた。これは意図的にラグビー用語を使ったものである。 朝会のエネルギーレベルはラグビーのスクラムほど高くなくてもよいが、ある程度は高める必要がある。 迅速さと高エネルギーによって、設定したゴールに向かうのだ。 長く、低エネルギーの朝会では、気持ちがまとまらず、弱々しい一日となる。

良い朝会には「支えてくれる感」がある。 問題が起こるたびにノックダウンされていては、次第に問題を報告しなくなるだろう。 支えてくれない朝会は問題点を除去できないどころか、チームのダイナミックさにも悪影響を及ぼす。 そうなると、朝会は恐怖の儀式になり下がってしまう[LaPlante, 2003]。

物事がうまくいっていれば、朝会にディレクションやファシリテーションは必要ない。 良い朝会には「自己管理してる感」があるのだ。

朝会のパターン

朝会に出席する人は？

総動員

様々な分野（マーケティング、製品サポート、管理職、トレーニング部門など）の人たちや代表者がプロジェクトの状況や進捗を知りたいと思っている。プロジェクトに貢献したいと思っていることもあるだろう。 複数のミーティングで報告やレポートを行うと、余計な作業が発生してしまう。

だから

すべての会議やレポートを朝会に置き換える。 プロジェクトに直接関わっている人、 プロジェクトの日々の業務を知りたいと思っている人は、 みんなで単一の朝会に参加すべきである。

ただし

直接関わってない人が参加すると、朝会が崩壊する可能性がある。 外部の人は朝会以外のところで疑問を投げかけるようにすべきだ。

人が多すぎると混乱を招き、情報共有の場としての居心地が悪くなってしまう。 通常、朝会のメンバは多くとも10人だろう。 それ以上のメンバがいる場合は、豚と鶏とオフラインでやるを課して、すべての貢献者が時間通りにインプットを得られるようにする。

すべての報告会が朝会の形式で行われる必要はない。 むしろ、行われるべきではない。 たとえば、プロジェクトの進捗などは、バーンダウン・チャート、バーンアップ・チャート、累積フローダイアグラムなどの「巨大見える化チャート」[Jeffries, 2004]を使うべきだ。

豚と鶏

あるところに鶏と豚がいました。すると、鶏がこう言いました。「一緒にレストランを始めようよ！」豚はしばらく考えてこう答えました。「レストランのオススメメニューは何にするの？」鶏は言いました。「ハムエッグだよ！」豚はこう答えました。「そりゃないよ。君は卵を提供すればいいだけだけど、こっちは身を削るんだよ！」[Schwaber and Beedle, 2001]

朝会におけるオブザーバの妨害は、チーム内でのコミュニケーションに混乱を与える。 妨害とは、割り込みをかけてきたり、勝手に参加してわけわからん情報を提供したりするといったようなことだ。 そういった妨害が激しいと、チームメンバはわざわざ朝会でプロジェクトに関するやり取りをしたいとは思わないだろう。そうなると、朝会の代わりのものを作ってしまうか、まったくコミュニケーションをしなくなるか、いずれかになるだろう。

だから

「身を削った」人だけが参加でき、「ちょっと関係している」人は見ることしかできないルールを作るべきだ。 「身を削る」とは、現在のイテレーションの完遂に身をささげている人を指す（開発者、テスター、直属のマネージャなど）。 言い換えるなら、バックログアイテム／機能／ストーリーのデリバリーに直接影響する人たちのことだ。 「関係している」人はイテレーションの状況に関心はあっても、その完遂に直接貢献しない。たとえば、他の部門のマネージャや営業、他のプロジェクトの開発者などが含まれる。 「関係者」の質問や問題提起は、朝会のあとで処理する（オフラインでやる）か、他の手段でやり取りする。

ただし

参加者を過度に区別しすぎると、敵対関係を作りかねない。 オブザーバはチームとコミュニケートしてはいけないということではない。 これは、朝会でやるのは適切ではないということを意味しているだけだ。

代理参加

チームメンバは全員参加する必要がある。何らかの理由で本人が参加できない場合は、電話で参加するか、他のチームメンバに状況を報告してもらうようにする。[Cochango, 2006]

チームメンバが気分よさそうに朝会に参加してきたら、 チームへのコミットメントは重要ではないという印だ。 だが、チームメンバが正当な理由（個人的な理由、製品サポート問題）でミーティングに参加できない場合は、何らかの形でコミットメントを表明してもらいたい。

だから

チームメンバが朝会に参加できない場合は、代理参加できないか模索する。 代理人を使ったり、電話で参加したり、事前にEメールで通知したりという方法でもよい。 いずれにしても欠席よりはマシである。

ただし

チームメンバが定期的に朝会に参加できない場合は、 朝会の時間や場所がチームにとって不便だということかもしれない。 あるいは、そのメンバにはチームに関係のない責任や問題が割り当てられていて、実際にはチームの一員ではないということかもしれない。 もちろん、代理参加は本人が参加することよりも劣る。

朝会で何を話す？

昨日やったこと・今日やること・問題点

おしゃべり好きな人は講演会を始めてしまう。 問題を聞いたらすぐに問題解決したがる人もいる。 朝会が長すぎるとエネルギーが低下し、議論に直接関係のない参加者たちは注意散漫になりがちだ。

だから

以下のフォーマットを利用して、貢献を体系化するとよい：

  • 昨日やったことは？
  • 今日やることは？
  • 進捗を妨げている問題点は何？

これらは朝会の目標を達成するための最小限の質問である。 他の議論（設計についての議論やゴシップなど）はあとでやるべきだ。

Losse Koskelaはチームメンバがリーダーに報告しないようにするために、 別のフォーマットを提案している。

各チームメンバは仲間の情報を更新する：各メンバが順番に3つの情報を提供していく。

  1. 昨日のミーティングから今までに行ったこと
  2. 今日これからやろうとしていること
  3. 除去すべき問題点 [Koskela, 2006]

コミットメントに着目すると、 この問いは以下のように言い換えられるだろう。

  1. コミットしたことを達成できたか？
  2. 今日コミットできることは何だろう？
  3. コミットメントを達成するために問題となるものは何だろう？

オリジナルの問いのほうがシンプルだが、 私はこちらのフォーマットのほうが好みだ。

ただし

質問のフォーマットは質問の答えによって得られる情報ほど重要ではない。 情報が形式化されていない場合、チェックリストにこだわっても仕方ない。 チームが成熟していくにつれ、フォーマットも調整していく必要があるだろう。 たとえば、私は4つ目の問いを設けている。

「コミットメントを達成するために役に立つこと（あるいは邪魔になること）は何だろうか？」

バックログに注目

プロジェクトの状況を覚えておくのは難しいと感じる人もいるだろう。 これは、朝会から離れるときにイテレーションやリリースでやり残していること、朝会で挙がった直接関係しない問題点、イテレーションやリリースの進捗などを明確に認識していない参加者に見られる症状だ。

プロジェクトの状況を把握するには「見える化」ツールを使うのが簡単だ。

だから

朝会参加者にバックログに注目させること。 バックログとは、行うべきタスクや機能がリストになっているものだ。 たとえば、「情報ラジエーター（別名、巨大見える化ツール）」[Cockburn, 2001]を朝会の場所の傍に置いて、イテレーションやリリースの状況を示すようにする。 すると、これからやるべきことを明確に思い出させてくれる。

ただし

バックログに注目すると、どうしても人よりタスクに注目してしまう。 タスクの状況にばかり注目していると、重要かつ繊細な「人の問題」が見過ごされてしまう。

ブロッケージ・ボード(Blockage Board)

朝会で起こった問題が除去されなかったり、逆にすぐに対処されたりする。

だから

問題をブロッケージ・ボードにポストする。 これはみんなに見えるホワイトボード（またはチャート）で、発生した問題の明確化と解決の進捗を追跡するために使用される。 ブロッケージ・ボードは、ちょっとした問題を書き留めるなど、朝会以外でも更新される。 よくやってしまうのが、遠くから読めないくらい小さな字を書いてしまうことだ。

問題を書きとめて明確に分かるようにしておくというこのシンプルな方法は、 冗長な会話を短縮するための非常に信頼のおける代物である。 みんなが問題だと思わなくても、とりあえず書いておいて、あとで話し合うことは重要である。

朝会はいつどこでやる？

同じ場所、同じ時間

チームには朝会を所有している感覚を持ってもらいたい。 また、別の状況報告会議をスケジュールに入れなければならないなんてことはイヤなので、利害関係者たちがちょっと立ち寄って見学できるようにしたい。 だが、誰かが朝会の時間を遅らせたり、場所を変更できるような権限を持っていると難しいだろう。

だから

朝会は同じ場所、同じ時間で開くこと。 ウロウロしてる人たち（アーキテクトやマネージャも含む）を待たせてはいけない。 朝会はチーム全体のものだ。 特定の個人のものではない。 朝会で一日を始める場合は、特に重要だ。

遅刻者に「罰金」を課している厳格なチームもある。 私はあまり罰を課さないほうがよいと思う。 それよりも話し合いのほうが好きだ。

ただし

同じ場所、同じ時間は柔軟性がないということではない。 重要なのは開始時間が一定していて、あまり変更されないということだ。 たびたび変更が必要であれば、開始時間を変更したほうがよいだろう。 参加しにくい場所で開かれているなら、場所を変更したほうがよいだろう。

朝会で一日を始める

朝会では未解決の問題に注目し、気づきを与える。 朝会が一日の終わりに開かれてしまうと、その注目や気づきが無駄になってしまう。

だから

朝会で一日を始める。 “フレックスタイム制”だと、みんな同じ時間にはやってこないだろうから、そういうときはコアタイムの開始時間を朝会の開始時間にする。 同様に、チームメンバが個人的な理由（子供を学校に送るなど）で遅れる場合、朝会の開始時刻はその時刻に合わせ、全員が参加できるようにすべきだ。

ただし

これだと、朝会が始まるまでプロジェクトに関係するタスクをやらなくなってしまいがちだ。 朝会で一日を始める……遅くにだと、その余分な時間が致命的になる。 たいていは、Eメールをチェックしたりタイムシートを記入したりするのだろうが、 朝会が“一日を始める”儀式になっているのであれば、 もっと後ろにズラせないか調査してみることは無駄ではないだろう。

「朝会で一日を始める」を使わない

朝会は一日のフォーカスを設定する儀式の役割を担っている。 朝会で一日を始める場合は特にそうだ。 そのため、チームメンバは朝会まで機能に取り掛からないことが多い。 朝会が一日の始めに開かれないと、生産性に重大な影響をあたえかねない。

だから

「朝会で一日を始める」を使わない。 朝会を一日の開始だと感じないような時間に設定する。

ただし

その日のフォーカスを設定する共有儀式として朝会を使うことができない。 これでは効率化にならないというチームがでてくるかもしれない。

朝会のエネルギーレベルを維持するにはどうすればよいか？

朝会を使うプロジェクトが多いと、複数の朝会を同時に行うことは不可能だ。 複数のプロジェクトに興味のあるオブザーバはすべての朝会に参加できるよう時間を調整したくなるだろう。 だがこれは問題である。 オブザーバのスケジュールに合わせて朝会の時間を調整してしまうと、チームの所有感がなくなってしまうからだ。 そうはいっても、朝会の時間を決定する際に考慮する必要はあるだろう。 朝会のエネルギーレベルを維持するにはどうすればよいだろうか？

集まる

声の大きさは、コミュニケーションの効率もそうだが、記銘力に影響する。 物理的な距離によってコミュニケーションしやすい声の大きさが違ってくる。 大声を出さない人もいるし、そうすることを心地よいと思わない人もいる。

だから

朝会は通常の会議よりも密着して集まる必要がある。 声が聞こえにくければ、もっと近くに集める。 リラックスできる声の大きさはあるにしても、 物理的に近づけばそれだけ人の話をよく聞けるようになる。 物理的な距離が小さいということは、チームへの信頼感が高いということの表れでもある。

朝会にまだ不慣れな場合は、手招きをしたり、「みんな集まって」と声に出したりするとよい。 円の大きさがすでに決まってしまっている場合は、 小さくしようと努力する前に、集まることの理由を説くとよいだろう。

ただし

チームは各自のコンフォート・ゾーン（快適に感じられる範囲）を考慮しなければならない。 信頼度の高いチームであっても、近づきすぎて快適に感じられない場所があるはずだ。 参加者が緊張したり、落ち着かなかったりするのが兆候だ。

スタンドアップ

おしゃべり好きな人は講演会を始めてしまう。 問題を聞いたらすぐに問題解決したがる人もいる。 朝会が長すぎるとエネルギーが低下し、議論に直接関係のない参加者たちは注意散漫になりがちだ。

だから

参加者は全員スタンドアップする必要がある。 スタンドアップによって、肉体と精神的な準備とを結びつけるのだ。 ミーティングが長くなると、肉体的な不快感が参加者たちを襲う。 手っ取り早くこれを強制するには、椅子を取っ払ってしまうことだ。

ただし

スタンドアップは朝会の時間を短くする。 しかし、最適な長さにするわけではない。 その場に応じた適切な対処よりも、不快感への対処を優先したくかもしれない。 また、時間が短かったり、話が脱線しない場合は、スタンドアップする必要はないだろう。

15分以内

朝会が長すぎると、心がさまよい始める。 長く、単調な朝会で一日を始めるのはひどいものだし、エネルギーを吸い取られてしまう。 朝会時間を決めておくと、調整しやすいだろう。

だから

朝会は15分以内にする。 一般に15分経つと心がさまよい始めるそうだ。 そうなると、フォーカスの設定の邪魔になる。

ただし

15分も小さなチームにとっては長すぎるかもしれない。 もっと大きなチームの場合でも、やはり15分経つと心がさまよい始めるので、15分がちょうどよい制限になるだろう。 朝会の終わりに近づいてから時間が足りなくなってしまい、 チームの状況を把握できなかったり、問題を解決するために誰に話しかければよいのか分からなかったりすることもあるだろう。

終了の合図

最後の人が話し終えても、朝会が終了かどうかは分からない。 じょじょに「あ、終わったんだ」と思ってバラバラに解散してしまうと、 高エネルギーの朝会にならないし、逆に低エネルギーになってしまうかもしれない。

だから

キマリ文句を使って終了の合図を示そう。 たとえば、「楽しいランチを！」[Gibbs, 2006, Signal]と言ってみたり、決まった行動をとったりするなどだ。

時間を計測

定性的に朝会が長かったかどうかを判断するのは難しい。 少しずつ時間が長くなっている場合は特にそうだ。

だから

朝会の時間を計測しよう。 参加者は講演会で時間がつぶれたり、オフラインでやることを前提にしないで話し込んだり、朝会がどれだけ時間がかかるか見積もらないことの影響を理解していない。そこはきちんと定量化しよう。

ただし

エネルギーレベルの問題が原因でなんとか目標を達成しなければならないとき以外は、時間を計測しないほうがよい。 目標が達成できれば、計測は中断しよう。 明確な理由もなく計測すると、疑惑や計測への無関心を助長するだけだ。

オフラインでやる

問題を聞いたらすぐに問題解決したがる人がいる。 朝会が長すぎるとエネルギーが低下し、議論に直接関係のない参加者たちは注意散漫になりがちだ。 議論がさらに必要だということを認めることも大切だ。 なかには朝会の仕組みがくずれるのを快く思わない人たちもいるからだ。

だから

「あとでオフラインでやるよ」みたいなフレーズを使って、朝会が終わったあとに議論するよう仕向けよう。 仲良しこよしの話だったら、続きは必要ない。 問題解決の話だったら、ファシリテータ（最終的にはチーム）が、適当な人にサインアップしてもらって、あとで処理してもらうようにする。

ただし

問題解決と論点の明確化は違う。 理解されていない情報は役に立たない。 どれくらいまで明確にすればよいかは、チームの大きさや15分以内への影響によって違ってくる。

自己組織型朝会にする方法は？

最後に来たひとから話す

朝会では、参加者は最初に話す人を知る必要がある。 ファシリテータが最初に話す人を決めてしまうと、自己組織化の考えに反してしまう。 何もせずに最初に話す人が誰なのか分かるようにすべきだ。

だから

最後に来たひとから話すとよい。 このシンプルなルールには、時間通りに参加するようになるという付加的なメリットもある。

ラウンドロビン

朝会では、参加者は次に話す人を知る必要がある。 ファシリテータが次に話す人を決めてしまうと、自己組織化の考えに反してしまう。 何もせずに次に話す人が誰なのか分かるようにすべきだ。

だから

ラウンドロビンのようなシンプルなルールを使って決めるとよい。 時計回りでもいいし、反時計回りでもいい。 ファシリテータやマネージャではなく、チームが朝会を運営できればそれでよい。

トークンを渡す

ラウンドロビンのようなシンプルで予測可能な順番メカニズムを使うと、 自分の順番になるまでスピーカーのことを無視することができてしまう。 他の人たちが何を言っているかに注意を払わずに、 何か他のことを考えているのだろう。

だから

予期できない順番メカニズムを導入するとよい。 スピーキングトークン（ボールなど）を使って次に話す人を決めるのだ。 これで最初に話す人も簡単に決まる。 トークンを取り出した人（あるいはその人がボールを渡した人）が最初に話す人だ。

何かを投げると、朝会がちょっと楽しくなる。 またこれは、他のチームへの（いい意味での）感染メカニズムにもなる。

私が初めてこのパターンを知ったのは、Simon Stewartとのプロジェクトだった。 私たちは小さなジャグリングのボールを使ったが、トークンは何でもいい。 ラグビーボールや[Gibbs, 2006, Rugby] ビロードのおもちゃを使うチーム[Mar, 2006]もあるようだ。

ただし

チームが大きいと、誰が話してないか分からなくなることもある。 その場合はラウンドロビンのようなシンプルなメカニズムのほうがよいだろう。 組織やチームの文化によっては、ボールを投げるという行為はプロフェッショナルではないと見なされることもある。そうなると、朝会に対しても不要なネガティブの認識をされてしまう。

カードを引く

朝会では、参加者は最初に話す人、それから次に話す人を知る必要がある。 ファシリテータが最初に話す人を決めてしまうと、自己組織化の考えに反してしまう。 トークンを渡すことはできない。 手にはコーヒーカップを持っているからだ。

だから

チームメンバがカードを引くことで話す順番を決める[Russell, 2006]。

ファシリテータを持ち回りにする

チームメンバがリーダーに報告している。 つまり、他のメンバではなく、朝会のファシリテータにだけ話しかけているのだ。 ファシリテータは朝会に関するプロセスの問題について取り上げたり指し示したりするだけだ。 朝会の所有権はチームに持ってもらいたい。 そのためには、一人のファシリテータに頼らないようにする必要がある。

だから

ファシリテータを持ち回りにする。 メンバを確実に出席させ、合意のとれたルールを遵守する責任を持つ役割を持ち回りにする。

ただし

経験の少ないチームは経験豊かなコーチから多くのことを得るだろう。 だが、チームは乳離れをして、朝会を自分達でコントロールすべきだ。 その時点ではまだファシリテータは必要ない。

アイコンタクトをやめる

チームメンバがリーダーに報告している。つまり、他のメンバではなく、朝会のファシリテータにだけ話しかけているのだ。

だから

ファシリテータはアイコンタクトをやめるべきだ[Nicolette, 2006]。 これは、個人ではなくチームとして取り組むことをスピーカーに思い出させるちょっとした方法だ。 そのためのひとつの方法として、辺りを歩き回って[Shimp, 2006]、スピーカーがファシリテータを見れないようにするというのがある。

臭いがしたら、それ間違ってるから

定例の朝会を3年間続けている。朝会をツマんなくしてるのは上司だ（ここではウォリーと呼ぶ）。彼の主な目的は、成果物に直接関係しない人間のやり取りを少なくして、効率を上げたりXPを採用したり……ということじゃあない。ウォーリーにとって朝会は（月曜7時からの朝礼や、金曜17時からの会議なんかと同じで）雇用者と被雇用者との関係をより強固にするための、忠誠心の試金石でしかないのだ[LaPlante, 2003]。

効果的な朝会とは、うまくいってることが分かる状態のことだ。 臭いとは、うまくいってないことが分かる状態のことだ。 臭いに気づかないからといって、必ずしも朝会がうまくいってるわけではない。 臭いが「悪臭」じゃないというだけのことだ。

以下の臭いは前述のパターンとつながっている。 パターンとつながっていないものは、根底の問題が微妙なものだったり、朝会の範囲外のものだったりするので、自分達のソリューションを探す必要があるだろう。

×リーダーに報告

チームメンバはチームに向かうべきだ。これは「スクラムマスターへの報告」会ではない。[Cochango, 2006]

チームメンバがチームではなくマネージャやファシリテータに向かって話すこと。 これだと、本来チームのためであるべき朝会がマネージャやファシリテータのものであるかのようになってしまう。この従属関係を断ち切る方法がいくつかある。ファシリテータを持ち回りにする、アイコンタクトをしない、昨日やったこと・今日やること・問題点の形を変える、トークンを渡すなどだ。

×遅刻

これは同じ場所、同じ時間に直接、関係している。 遅刻があるのは、先ほども述べたように、朝会を間違った場所、間違った時間に開いている可能性がある。

×朝会で一日を始める……遅くに

朝会は一日の始まりなので、朝会の前に仕事を行うことがない。 朝が遅く始まると、稼動できる労働時間に重大な影響を与えかねない。 これは「朝会で一日を始める」を使わないにつながる。

×オブザーバが邪魔をする

オブザーバによって度々邪魔されると、 朝会は納品チームのものであるという前提がゆるぎ、 混乱をきたしてしまう。 邪魔されると15分以内に収まらない。 この場合、豚と鶏を発動する。

×仲良しこよし

朝会の目的のひとつは、チームの社会化である。 だが、朝会はプロジェクトに関係しないことについて「情報交換」する場ではない。 どこまでがチーム形成で、どこから無駄話なのかはチームによって違うので、例を挙げるのは難しい。 だが、「仲良しこよし」の範囲外にいる参加者たちの振る舞いから検知することができる。 彼らのエネルギーが高いままであれば、それはチーム作りだ。 彼らのエネルギーが下がったら、オフラインでやるか、ウォータークーラーOrgPatternsWaterCoolerをする別の会を提供する。

×覚えてない

「昨日やったこと？……覚えてない。今日やること？……えーと」

朝会はミーティングである。 ミーティングに参加する者は準備を行う責任がある。 朝会では参加者すべてが昨日やったこと・今日やること・問題点について答える責任がある。 今日やることが決まってなくて、優先順位の高いものからタスクを選ぶ場合は、答えられなくても仕方ない。

準備していないとペースが落ちて、エネルギーも低下する。 15分以内にならない可能性もあるし、そうなれば、さらにエネルギーが低下する。

×講演会

十分すぎるくらいの詳細や背景を説明してしまうと、 他の人は飽きてしまう。 朝会では問題を明確化することを第一のルールとすること。 詳細については朝会の後で行うこと。 まとめると「見出しを伝えよ。全文は要らない」ということだ。 あるいは、オフラインでやること。

×問題解決

15分以内に終わるには講演会に制限をかけること。 それから朝会で問題解決をしないことである。 それらはオフラインでやること。

×元気がない

元気がないことは、講演会、問題解決などによってペースが落ちたことの表れである。 この場合、オフラインでやること。 あるいは、単にチームサイズの問題かもしれない。 あるいは、朝会で一日を始めるまたは「朝会で一日で始める」を使わないについて考える時なのかもしれない。

×問題が起こらない

問題が起こらないのにはいくつかの理由がある。 覚えてない、閾値が高すぎる、問題を挙げることへの信頼が欠けている（問題が解決しない、オブザーバが邪魔をするなどが理由）。 コンテキストに依存するため、 昨日やったこと・今日やること・問題点を導入したり、 豚と鶏を強化したりするだけでは十分ではない。 ブロッケージ・ボードを導入すると、あまり対立関係が起こらずに問題を挙げることができるだろう。 ふりかえり（レトロスペクティブ）[Kerth, 2001]は、問題が挙がらない根本的な理由を見つけ出す効果的な方法だ。

×問題が解決しない

罰を課すような環境だと話は別だが、 問題が起こらなくするには問題を削除しないことである。 問題を忘れたり無視したりできないようにするには、 ブロッケージ・ボードで公に追跡する。

×朝会だけで問題が起こる

朝会はセーフティネットの役割を果たす。 最悪1日あれば、問題はチーム全体に伝わる。 だが、朝会は問題を挙げるためのものではない。 問題を1日で解決するというものでもない。 問題を挙げるにはブロッケージ・ボードを使うとよいだろう。 または、根本的な原因がふりかえりの中で判明するかもしれない。

雰囲気がよければ、たぶんOK

できればもう少し、効果的な朝会のプラクティスの詳細に関する見解やよくある問題への指針を提供したいところだが、朝会が毎日一緒に立つだけじゃないことは明らだ。

大切なのは、パターンを全てやっていないとか、臭いがまだ残っているとか、あまり意識しすぎないことである。 目標が達成でき、「雰囲気」がよければ、たぶんOKだ。 それなら、本当の意味で、一緒にデイリースタンドアップしていると言える。

他の人は何と言っているか？

コアとなるアイデアは参考文献に載っていたが、 私が知っている限り、その他のローレベル・パターンについて書かれた論文はなかった。 朝会のアンチパターンや臭いについては、 どちらも限定されたスコープではあるが、 いくつかのオンライン記事が存在している（[Miller, 2003]、[Cohn, 2003]）。

謝辞

Ivan MooreとAlan Francisには、私が伝えたいと思っていたことを明確にする手助けをしていただいた。 Owen Rogersには、いくつかのパターンを手伝ってもらった。 Susan Newtonは、朝会には「支えてくれる感」がなければならないことを気づかせてくれた。 James RossとRebecca Parsonsには、編集を手伝ってもらった。 Brian Marickには、指導をしていただいた。 PLoP 2004のライターワークショップのメンバ（Dick Gabriel, Linda Rising, James Coplien, Lise Hvatum, Cecilia and Terje Haskins, Danny Dig, David Hecksel, and Ali Arsanjani）にも感謝したい。 Bill Wakeには、詳細なコメントをいただいた。 PLoP 2006のライターワークショップのメンバ (Ralph Johnson, Pau Arumi, David Garcia, Leon Welicki, Djamal Bellebia, Dirk Riehle, Hesham Saadawi, and Paddy Fagan)にも感謝したい。 Karthik Chandrasekarialには、朝会の写真を提供していただいた。 最後に、私がこれまでに参加した朝会のメンバみんなに感謝したい。

参考

  • [Anderson, 2002] Anderson, D., “Morning Roll Call”, The Coad Letter: Process, Issue 101 (August 2002), URL: http://bdn.borland.com/article/0,1410,29686,00.html
  • [Beedle et al., 2000] Beedle, M. et al., “SCRUM: An Extension Pattern Language for Hyperproductive Software Development”, Pattern Languages of Program Design 4, N. Harrison, B. Foote, and H. Rohnert, eds., Addison-Wesley, 2000, pp. 637-651
  • [Cockburn, 2001] Cockburn, A., Agile Software Development, Addison-Wesley, 2001
  • [Cochango, 2006] “Daily Scrum Meeting”, URL: http://scrumforteamsystem.com/ProcessGuidance/Process/DailyScrumMeeting.html
  • [Cohn, 2003] Cohn, M., “Toward a Catalog of Scrum Smells”, October 2003, URL: http://www.mountaingoatsoftware.com/articles/ScrumSmells.pdf
  • [Gibbs, 2006, Leaderless] Gibbs, E., “Leaderless Standups”, 10 August 2006, URL: http://edgibbs.com/2006/08/10/leaderless-standups/
  • [Gibbs, 2006, Rugby] Gibbs, E., “Passing A Rugby Ball in Standups”, 14 August, 2006, URL: http://edgibbs.com/2006/08/14/passing-a-rugby-ball-in-standups/
  • [Gibbs, 2006, Signal] Gibbs, E., “Signaling the End of a Standup”, 7 August, 2006, URL: http://edgibbs.com/2006/08/07/signaling-the-end-of-a-standup/
  • [Jeffries, 2004] Jeffries, R., “Big Visible Charts”, March 2004, URL: http://www.xprogramming.com/xpmag/BigVisibleCharts.htm
  • [Kerth, 2001] Kerth, N., Project Retrospectives, Dorset House, 2001
  • [Koskela, 2006] Koskela, L., “On Scrum and the curse of the three questions”, May 7, 2006, URL: http://radio.javaranch.com/lasse/2006/05/07/1147034972559.html
  • [LaPlante, 2003] Laplante, Phillip A., “Stand and Deliver: Why I Hate Stand-up Meetings”, ACM Queue, 1, 7 (October 2003)
  • [Mar, 2006] Mar, K., “Controling the flow of daily meetings with a team mascot”, 13 May 2006, URL: http://kanemar.wordpress.com/2006/05/13/controling-the-flow-of-daily-meetings-with-a-team-mascot/
  • [Miller, 2003] Miller, C., “Stand-up Meeting Antipatterns”, 19 November 2003, URL: http://fishbowl.pastiche.org/2003/11/19/standup_meeting_antipatterns
  • [Nicolette, 2006] Nicollete, D., “Re: On Scrum and the curse of the three questions”, May 8, 2006, URL: http://radio.javaranch.com/lasse/2006/05/07/1147034972559.html#comment1147110635098
  • [Rising, 2002] Rising, L., “Agile Meetings”, STQE, May/June 2002, pp. 42-46
  • [Rising and Janoff, 2000] Rising, L. and N. Janoff, “The Scrum Software Development Process for Small Teams”, IEEE Software, July/August 2000, pp. 2-8
  • [Russell, 2006] Russell, R., “The Daily Stand Up, Part 2”, 30 May 2006, URL: http://www.robbyonrails.com/articles/2006/05/29/the-daily-stand-up-part-2
  • [OrgPatternsStandUp] “Stand Up Meeting”, Org Patterns, 7 October 2003, URL: http://www.easycomp.org/cgi-bin/OrgPatterns?StandUpMeeting
  • [OrgPatternsWaterCooler] “The Water Cooler”, Org Patterns, 18 November 2003, URL: http://www.easycomp.org/cgi-bin/OrgPatterns?TheWaterCooler
  • [Schwaber and Beedle, 2001] Schwaber, K. and M. Beedle. (2001) Agile Software Development with Scrum, Prentice-Hall
  • [Shimp, 2006] Shimp, D., “An Overview of ScrumMaster ? Part 2”, July 18, 2006, URL: http://www.netobjectives.com/podcasts/last20060719_podcasts.mp3
  • [Wells, 1999] Wells, D., “Daily Stand Up Meeting”, Extreme Programming: A gentle introduction., 1999, URL: http://www.extremeprogramming.org/rules/standupmeeting.html

翻訳：kdmsnr

  • 2007/04/02: 推敲終了
  • 2007/04/01：翻訳