私がこれまで関わってきたほぼ全ての開発チームでスクラム開発を行ってきましたが、その中でハドル・ミーティング（別名スタンドアップ・ミーティング）はやはり欠かせないものだという思いを強くするに至りましたので、その理由や、色々試してみた結果どのようなフォーマットが自分達にとって一番良かったのかについて書いてみます。
なお、この文章ではハドルの定義として、毎日行なうおよそ15分前後の短い打合せを意味しています。問題解決のためにその場ですぐに行なう単発の臨時ミーティングも一般的にはハドルに含まれますが、この文章では定期的に開催するもののみを対象とします。
なぜハドルを行なうのか
スクラムと言えば毎日のハドルがデフォルトでついて来るほど一般化していますが、形骸化して思考停止にならないよう、なぜ自分のチームで毎日ハドルを行なうべきなのかを考えてみました。
問題が発生したらすぐに対応出来る
日次のハドルではなく週次の打合せで進捗を共有すると、当然ですが１週間の間はメンバーが担当している各タスクについてどのような進捗なのか、なにか問題は発生していないのかの把握が遅れることになります。実際、１週間後の定例打合せで、「まだそれだけしか進んでないの？なぜ？」となったことは一度や二度ではありませんでした。問題があっても一週間放置されるというのは、プロジェクト管理の上で致命的になりかねない状態です。
良いプレッシャーになる
日次ハドルには心理的プレッシャーを促進する効果があると考えています。どういうことかと言うと、自分を含め人間は怠惰なので、報告するまで１週間余裕があると、まだ余裕があると思って週の始めはゆっくりめに仕事をし、次の定例が近くなる週の後半になって本腰を入れだす、ということもあるのではないかということです。逆に毎日ハドルが開催されて、メンバーの前で進捗を共有しなければならない状況だと、何も進みませんでしたと言って恥を書きたくないので、毎日少しでもタスクを進めようという自己プレッシャーが働くからです。実際、自分自身の感覚としても、ハドルを行った時の方が良い意味で自分自身を追い込めるので、作業の進みは早い印象を持っています。
質疑応答が捗る
ハドルの代わりにチャットツールで毎日進捗共有してもらったこともありますが、やはり実際にハドルを開催するのには劣りました。メンバーのタスク進捗を表面的に確認することは出来ても、あまりチャット上でそのことについての質疑応答に発展することはありませんでした。チャットツール上のコメントで質疑応答が可能だとしても、です。
理由を考えてみると、これは非同期と同期コミュニケーションの会話の呼吸の違いなのかもと思いました。チャットでコミュニケーションをしていると、共有されたものに対してわざわざ質問をしようと思わないのに対し、ハドルでリアルタイムで話していると自然と会話の流れの中で不明点をいますぐ確認しておきたい、となるから不思議なものです。
また、ハドルを行わないと、問題が発生していてもその場で相談出来ないので、選択肢としては別途打合せを調整する、チャットツールで相談する、タスクツールのコメントで相談する、になります。いずれにしても、相談相手が忙しいとなかなか回答を得られず、一次回答を得られるまでの時間はハドルでその場で聞く時よりも長くなりがちです。
自動的にTodoリスト作成、前日の振り返りが出来る
ハドルがない場合、その日のTodoリストを作らずにいきあたりばったりで仕事をしてしまうこともあるのですが、ハドルがあるとチームに共有する今日の作業予定が自動的に自分のTodoリストになってくれます。
また、同様に前日行った作業についてもチームに共有するため、自分の前日の行動を振り返り、時間の使い方について反省・改善するという作業が自動的に行えます。
これで、なぜそもそもハドルを行なうべきなのかを再確認できたので、次は話すべき内容について整理してみます。
ハドルで話すべき内容
私がこれまで関わったチームで共通していた内容は、以下の通りです。
前日にやったこと
作業だけでなく、参加した会議があればその内容や決定事項も共有しています。
例：
「昨日は営業部との定例に参加し、〜のプロジェクトについての要件をヒアリングしました」
「昨日は〜のタスクの実装を進め、プルリクエストを作成して〜さんにレビューをお願いしています。」
本日の作業予定
前日にやったことと同様、予定されている会議も共有するようにしています。
例：
「今日は外部ベンダーとの打合せを予定しています。」
「今日は〜プロジェクトについて、管理画面の設計を行なう予定です。」
タスクで発生している問題
いわゆるブロッカーのことです。
例：「担当しているタスクで、ライブラリーのメジャー・バージョンを上げないと実装が複雑になり工数があがりそうなのですが、バージョンアップしてしまっても問題ないでしょうか？」
スプリント進捗
ここまではハドルで話す内容としてはおそらく一般的かと思いますが、私が関わっていたチームのいくつかではそれに加えてスプリントに含まれている各タスクの進捗も全て確認するようにしていました。
各メンバーのタスク共有だけだと、スプリント内で終わらせなければいけないのにまだ未着手のタスクが漏れたり、ハドルに参加していないビジネス部門のメンバーからフィードバックがあったりということを見逃してしまう可能性があるからです。
もちろんタスクによってはメンバーが共有した内容と被ることもありますが、それでも日次で全てのタスクの進捗を確認することで、スプリントが計画通り進行しているのかをチームメンバー全員で共有でき、良い意味でのプレッシャーを持つことが出来ます。
ハドルで話さないこと
逆に、私がハドルで話すのを避けているものとしては、以下のようなものがあります。
・特定のプロジェクトの仕様策定。
・バグの原因についての詳細なディスカッション。
いずれもハドルでの作業共有から派生しがちなトピックですが、往々にして長くなりがちなので、メンバー間の情報共有を短時間で行なうというハドル本来の目的からは外れています。
いつハドルを行なっているか
多くのチームで同様かと思いますが、私の所属するチームでもハドルは朝一に行なうことが多いです。チームの各メンバーがその日にやることを明確にして方向性を合わせ、もしブロッカーがあったら朝一で解決して、日中の作業に支障が出ないようにするためです。
また、個人的にハドルを行なうと自動的に仕事モードになるので、チームの他のメンバーにも同様の効果を発揮してくれることを期待して朝一で設定しています。
なお、メンバーがそれぞれ違うタイムゾーンにいて、全員揃って朝一でハドルを行なうのが難しいという場合はひと工夫必要です。
実際、過去の私のチームでも日本とヨーロッパにチームが分かれてしまっていたため、朝に全員参加のハドルは難しいという状況もありました。対策として、朝に日本チームで一回、夕方に日本チームとヨーロッパチームを合わせて一回というように、１日に２回ハドルを行なうようにしていました。一日のうちそれなりの時間を費やしましたし、朝と夕方のハドルで内容が重複することもありましたが、情報共有の観点からは効果が高かったので、時間をかけてでもやって良かったと思っています。
ハドルの形式
話す特定の順番は決めておらず、その日に立っている順番、もしくはオンラインツールで表示されている順番に、それぞれ数分で口頭で情報共有を行うようにしています。
また、チームの人数によりますがハドルは15〜20分程度で終わるように心がけています。もし特定の議題が長引いてそれ以上になりそうだったら、他の人の時間を奪わないように一旦ハドル自体は終了し、関係者だけ残って打合せを行うか、別途打合せを設定するようにしています。チームの人数が多すぎて常に長い場合は、チームを分けることも検討します。
どこでハドルを行なっているか
もし実際のオフィスで皆が働いている環境なら、スタンドアップという名前の通り立ってミーティングを行ないます。お互いの席が近ければ自分の席の前で立って行いますが、お互いの席が離れていたりする場合は、廊下に皆で出て行なうこともありました。
立ってミーティングを行なうことのメリットは、立っていると皆疲れてくるため、ミーティングを簡潔に終わらそうというモチベーションが働くからです。
リモートチームだとオンラインでハドルを行なうので、その場合は机に座っていることがほとんどです。立って行なうことも可能だとは思いますが、スタンディングデスクで作業している人以外はあまり見たことはありません。オンラインだと画面共有が出来るというメリットはありますが、座っていることと相まってハドルが長くなりがちなので、皆が意識して時間内で終わらせるようにしています。
ハドルに参加するメンバー
理想は開発チーム全員が参加すべきですが、組織の事情によって違ってきます。
例えば、私が参加していたある組織では人数が少なかったため、メインはビジネス職だが開発部のテスターという職種も兼任しているという方もいらっしゃいました。そのような場合、その方に毎日のハドルに参加してもらうとメインの仕事がおろそかになってしまうため、週一でハドルに参加してもらい、後はタスク管理ツールやチャットで情報共有するということもありました。
そのような個々の組織の事情も考慮しつつ、これまでに私の経験した組織で参加していたメンバーの役割ごとに、なぜそのメンバーがハドルに参加すべきなのかをまとめてみました。
・CTO：チームマネージメント。スプリントのスケジュール把握に加え、現在の体制で無理は発生していないか、タスクボリュームや難易度に対してエンジニアのアサインメントは適切か、技術的な問題は発生していないかの確認。
・PjM/PdM：スプリントのスケジュール把握。仕様上の問題の把握。
・エンジニア：自身のタスクの進捗共有。また、他のエンジニアからのプルリクエスト依頼や相談事項の確認。
・デザイナー：デザインタスクの進捗共有。
・テスター：どのタスクがテスト完了してリリース可能か、どのタスクのテストをいつ頃行なう予定か。どのタスクがもうすぐテスト可能になるかの把握。
まとめ
スクラム開発で行なうハドルについて、自身の経験を基にまとめてみました。ここに書かれているやり方が必ずしも正解ではないですが、自分自身の組織について、なぜハドルを行なうべきなのか、行なうならどのようなやり方がベストなのかを定期的に振り返ってみるのはおすすめです。もしかしたら、現状よりもっと良いハドルのやり方が見つかるかもしれません。