いつものミーティングをアジャイル開発手法「スクラム」で再設計した感想

via chelmsfordpubliclibrary

後輩から質問されたので、上手にチーム運営する上で必要となってくるミーティング設計について考えてみた。

ミーティングを侮るなかれ。ミーティングは、プロジェクトにとって諸刃の剣といえる、時間をかければいいわけでもなく、短ければいいわけでもない。ミーティング設計するときは、

なんのためにミーティングを開くか？
どの周期でミーティングを開くか？
どれぐらいの時間をかけるか？
どういった内容にするか？
だれを参加者とするか？
どうファシリテーションするか？

などなど、考えることがたくさんあり、組み合わせもいろいろあることに気がつくはず。

「チームで情報共有」ができて、「チームの状況確認」ができて、「ゴールの共通認識」を確認出来れば自分は満足。しかし、それだけのことがとても難しい。今回は、チーム内や横のラインでつなぐ「ミーティング」を考えた。

伝統的なミーティング設計

僕自身の経験では、週に１回１時間のミーティングでなんとかするケースが一番多かった。プロジェクトに火がつくと、毎日定時後に緊急ミーティングという名の進捗確認をするところもあった。この1時間のミーティング。僕自身による個人的な調査によると、「なぜ1週間に一時間か」説明できる人がすごく少ない。

今回は、横のレポートラインを考えるだけなので、部があれば部会が１時間。その下に課があればさらに１時間・・・と、組織構造の深さだけ倍増する縦のレポートラインについては、別途考えてみよう。

スクラムのミーティング体系

これはイノベーションスプリントでのジェフ・サザーランド氏の資料。スクラムでは、

デイリースクラム（朝礼）により、毎日、チームのやることをチェックする
スプリントレビューにより、スプリントごとにふりかえる（デモとかも）
スプリント計画により、スプリントごとに次のスプリント計画をする

という流れになっている。そして、それぞれのボリュームは（資料によってまちまちなのでざっくりだけど）

デイリースクラムは15分以内？
スプリントレビューは1時間ぐらい？
スプリント計画づくりは2時間ぐらい？

の時間配分。スプリントレビューや計画づくりは、準備の状況（バックログの精度とか）にもよるので、これ以上の時間がかかる可能性があるのだろう。普通に考えると、毎日の共有が求められるので、チェックするポイントは多い。スプリントのふりかえりや、計画づくりに１日かけることもある。シンプルだが、週次のミーティングでなんとかしているところに比べると「ヘビーなミーティング設計」ともいえる。

さらに、タスクをタスクボードや流行りのRedmine/Tracなどで管理することになると、さらにヘビーになるのは間違いないだろう。しかし、必要な時間を必要なところにかけているとも考えられる。このへんは、各プロジェクトの状況や規模にも影響するので、カスタマイズが必要だと思う。スクラムを組んでみた感想をちょっとだけ

これまで「アジャイル開発」を意識したことのないメンバーでもすんなりプロセスに入ることができた。この「はじめやすさ」が今日のスクラムムーブメントになっているのかなぁと実感。

それ以外では、チームの一体感を実感した。ふりかえりでは「楽しかった」という意見が多かったので、コミュニケーションの時間が増えた分、雰囲気をチームで共有できたということかもしれない。

デイリースクラムをやってみた感想

よかったことは、進捗会議とかをしなくてよくなったこと。週に一度集まって進捗を確認するより、朝気になった人を捕まえて対策を考えるほうが、早く対応できるし、伝搬しやすい。トピックスに関係ある人間が自然と集まるようになってくる。また、毎朝メンバーの顔色を確認できるので、「気遣う」雰囲気が生まれる。

いまいちだったことは、大きいタスクだと報告が短調になってしまうこと。例えば「バッチ処理」デモもしにくいし、分割も難しかしいバッチもあるので、より、ストーリー作成やタスク化、完了の定義を気にする必要がある。また、朝来ない人がいることは致命的。本人も来る気がないのだろうが、朝礼の価値を伝えきれてないのも問題としてある。朝礼での共有がうまくいかないと、チームの首も絞めるし、その人の首も絞めることを理解してもらう必要がある。そもそもフェアじゃないよね。

あと、１０人以上だと運用が厳しいことがわかった。自分の感覚だと、７人ぐらいが限界で、これ以上でやると一体感が出ない。人数が多いときは、スクラムマスター的な人同士のデイリースクラム、その後、解散してチームのデイリースクラムなど、いろいろ試していこうと思っている。

運用する上で気をつけたのが、準備をしてきてもらうこと。「えーっと」とか沈黙がでてしまうと、朝からすっきりしない朝礼になってしまう。なんだかうまく報告できないメンバーには、

やったこと全部ではなく、大事なことを2つずつぐらいに絞る
準備をする

と伝えた。朝礼はすぐなれるので、いい雰囲気になるまでは様子を見ながら伝えていくしかない。

スプリントレビューをやってみた感想

よかったことは、デモによりマイルストーンごとに求められる成果を摺り合わせることができること。求めているものとの違いがはっきりわかるので、デモは開発にとっても、ビジネスサイドにとってもいい刺激になる。

いまいちだったことは、デモの準備でスプリントの最終日がつぶれてしまうことがあった。ライトなかんじでデモするためには「常に動くアプリ」を作るしかないことがよくわかった。そのためにはテストと、環境が重要。動かすことに手間がかかるアプリじゃだめだ。

デモ以外では、ふりかえりが重要。課題とその解決、Tryを明文化し、チーム全体はもちろん、個別タスクなら誰がいつまでに担当するかを明確にすることが重要だと感じた。僕の場合は、ふりかえりごとに仕事が増え、仕事が増えないふりかえりは不安になってしまう。意見をいうだけで何もしないケースが多いからアサインするのだが、あまりやりすぎると「意見が言いにくい場」になるのかもしれない。