複数のプロジェクトをスクラムで回していると、当然、時間的に厳しくなり、スクラムのイベント(会議)も、より効率化して時間短縮できないか？と考えてしまいます。本来なら、関わるプロジェクトを減らして、よりプロジェクトに注力できるようにするべきですが、現状、その方法は難しいので、イベント(会議)の効率化(時間短縮)を検討することにしました。
スクラムイベントの時間
そもそもスクラムのイベントに費やすべき時間は、スクラムガイドに下記ように記載されています。
Sprint Planning is time-boxed to a maximum of eight hours for a one-month Sprint.
スプリントが 1 か月の場合、スプリントプランニングのタイムボックスは最大で 8 時間である。
This is at most a four-hour meeting for one-month Sprints
スプリントが 1 か月の場合、スプリントレビューのタイムボックスは 4 時間である。
This is at most a three-hour meeting for one-month Sprints.
スプリントが 1 か月の場合、スプリントレトロスペクティブのタイムボックスは 3 時間である。
Scrum Guide | Scrum Guides
上記は1ヶ月スプリントの時間なので、下記に1週間スプリントに換算した時間も表でまとめておきました。(1ヶ月スプリントの時間を4で割っただけですが)
| イベント | 1ヶ月 | 1週間 |
| スプリントプランニング | 8.00時間 | 2.00時間 |
| スプリントレビュー | 4.00時間 | 1.00時間 |
| スプリントレトロスペクティブ | 3.00時間 | 0.75時間 |
この1週間スプリントの各種イベントの時間を、さらに短縮する手段は無いか？と考えていきたいと思います。
ファシリテーター
会議の効率化には、ファシリテーターの存在が非常に重要です。今回は、下記の二冊の書籍を参考にしており、それぞれのファシリテーターの記述を紹介します。
一般的にファシリテーションとは「グループによる活動が円滑に行われるための支援」のような意味で使われることが多いのですが、僕は、「アウトプットを出すプロセスを前へ進めること」といつも説明しています。ファシリテーターは、そのプロセスを推進する人です。
ファシリテーターは単に会議中の「議論の整理役」と考えられがちですが、会議が何らかの「アウトプット」を出すことを目的とする以上、それに近づけようとするプロセスは、すべてファシリテーションにあたります。ですから、厳密に言えば、ファシリテーションの力が問われるのは、会議の場にとどまりません。事前にアジェンダを用意したり、参加者に何らかのインプットやアウトプットを求めたりすることもファシリテーションの一環です
グーグル、モルガン・スタンレーで学んだ 日本人の知らない会議の鉄則
アマゾンの会議では、基本的にプロジェクトリーダーやプロジェクトを推進する人が、会議のオーナー兼ファシリテーターとなります。なぜなら、効率よく、質の高い意思決定をするためには、それが必要不可欠だからです。
会議のオーナーと進行役が別だと、進行役はオーナーにお伺いを立てたり、他の人の意向を慮って進めようとして論点がぶれたり、声の大きな人に引きずられたりしがちです。意思決定の会議は、円滑に進めることも大事ですが、成否のポイントはなんと言っても「アウトプット（意思決定）」です。ここがまずければ、もちろん会議は失敗です。
そういう意味で、アウトプットに責任を持つ人、プロジェクトリーダーが「こうしたい」と方向性を示し、議論をリードするほうが、会議の方向性が定まり、みんなに熱も伝わります。
ａｍａｚｏｎのすごい会議
上記を簡単にまとめると、「会議のファシリテーターはプロジェクトの中心人物がなるべきで、会議でアウトプット(意思決定)を出すために、会議の進行だけでなく、そのための準備も責任を持って実施する。」と言ったところでしょか？
スクラムに当てはめると、「ファシリテーター = (プロダクト)オーナー(プロジェクトリーダー)」と考えるのが良さそうです。
対象のイベント(会議)
今回の対象イベント(会議)は下記を想定しています。
- スプリントプランニング
- 中間レビュー
- スプリントレビュー&レトロスペクティブ
中間レビューという聞き慣れないものもありますが、下記の記事で、テレワーク時代ということで追加したイベントになります。ここでのスクラムはソフトウェア開発ではなく、経営や組織運営に応用したものなので、効率化による時間短縮も可能じゃないか？と思っています。
引用に対するコメント
上述した二冊の書籍から、効率化(時間短縮)のポイントを引用しました。
ファシリテーションの心構え
ファシリテーションは、会議の前からすでにはじまっているのです。
グーグル、モルガン・スタンレーで学んだ 日本人の知らない会議の鉄則
上述もしていますがファシリテーターの責任は、会議の進行だけでなく、会議でアウトプット(意思決定)を出すための準備からとなります。
どんなに理想論を語っても、会議に「全会一致」はありえません。いや、思い切って言ってしまえば、全会一致を追い求めるのは、時間の無駄ですらあるのです。僕がいままで働いてきた職場には、”Disagree, but commit (賛成せずともコミットする)”という暗黙のルールがありました。意見に賛同していようがいまいが、チームでひとたび結論が決まれば、メンバー全員でそれを達成するために最大限のパフォーマンスを発揮するのです。
グーグル、モルガン・スタンレーで学んだ 日本人の知らない会議の鉄則
どこかでトップダウンの決定が必要で、ファシリテーター(=プロジェクトリーダー)が、時間を無駄にしないように、判断する必要があります。
「全員で決めた」という形をつくるためだけに、発言がなくても困らないメンバーを参加させてはいけません。
グーグル、モルガン・スタンレーで学んだ 日本人の知らない会議の鉄則
会議は参加者が増えるたびにコストが増えることを意識して、常に参加者を必要十分な状態に保つ努力をする必要があります。
グーグルでは、ほとんどの会議が25分単位で設定されていました。25分の会議が終われば、5分は移動時間に充てます。
グーグル、モルガン・スタンレーで学んだ 日本人の知らない会議の鉄則
事前準備を増やし、トップダウンの決定を程よくすることで、ここでのスクラムのイベントも30分で終わらせることができるのでは、と妄想しています。
会議を形骸化させないようにマネジメントする視点が会議には必要なのです。
グーグル、モルガン・スタンレーで学んだ 日本人の知らない会議の鉄則
自分の時間、チームの時間の価値を考え、会議の形骸化を防ぎ、また形骸化した会議を廃止できる文化にするべきです。
資料の準備
アジェンダは会議の進行を決める上で基本となるものです。
グーグル、モルガン・スタンレーで学んだ 日本人の知らない会議の鉄則
アジェンダがない会議は禁止です。
結論を最初に書く。それを後段で、ファクトベースで説明する。
ａｍａｚｏｎのすごい会議
「空 → 雨 → 傘」の順番で思考して結論を出し、説明は逆の「傘 → 雨 → 空」の順番で行うという、大好きな考え方です。
本質的なことに集中するためにも、リーダーはメンバーにテンプレートの利用を促すのが得策です。
グーグル、モルガン・スタンレーで学んだ 日本人の知らない会議の鉄則
個別に資料のフォーマットを考え見やすく装飾するのは、時間の無駄です。まずはアジェンダと議事録のテンプレートが用意できるはずです。
議事録には、長々と経過を書く必要はありません。書くべきことはシンプルで、
・決まったこと(必要に応じて議論の経緯)
・次のアクション(誰が、いつまでに、何をやるのか)
の2つのみ。
グーグル、モルガン・スタンレーで学んだ 日本人の知らない会議の鉄則
ここまで割り切ると、議事録を書くのに必要なスキルや知識のハードルを非常に下げることができます。さらにファシリテーターが上記の2点を会議中にノートテイカー(議事録係)が書きやすいように取りまとめてくれると、内容の確認にもなり、一石二鳥になるのでは、と思っています。
クラウドの利用
最新のデータが常にクラウドにアップされていれば、資料のバージョン管理に気を取られることもなくなります。
グーグル、モルガン・スタンレーで学んだ 日本人の知らない会議の鉄則
Googleスプレッドシート、Googleスライド、Googleドキュメントを使えってことです。
ローカルで作業した資料を使っている時点で、生産性への意識が低いと言われてもしょうがない時代になってきているのです。
グーグル、モルガン・スタンレーで学んだ 日本人の知らない会議の鉄則
同上。
会議の内容
会議のオーナーは、関係者に事前に聞いて、数字に異常がないときや、指摘すべき点や共有すべき内容がないときは、その週の進捗管理会議は中止にしてもかまいません。
ａｍａｚｏｎのすごい会議
究極は、異常や課題、問題がなければ会議は中止する、ってことなのかもしれません。しかし、ここまでやるには、異常や課題、問題が迅速に打ち上がってくる仕込みが必要なはずです。
新しいことを始めたときには、定着するまである程度の期間、見続ける必要はあるのですが、安定軌道に乗って異常値が起こらない状況になったら、見るのをやめることも大切です。
ａｍａｚｏｎのすごい会議
安定するまでは、会議の議題にしてモニタリングするが、安定後は上記の引用の状態になるまでは、議題にしないって勇気を持つ必要があります。
資料に書かれている情報がすべてなら、プレゼンは禁止。事前に全員に共有して、当日はいきなりトップスピードで議論をはじめればいいのです。
グーグル、モルガン・スタンレーで学んだ 日本人の知らない会議の鉄則
資料は事前に配布して、全員、資料を読み込んだ状態で会議が始めれるようにすべきです。
まとめ
と言うことで検討の結果、具体的に下記を実施して効率化(時間短縮)できそうです。
- 会議の中心人物をファシリテーターとする。
- ファシリテーターは要所要所でトップダウンの決定を行い無駄な時間を減らす。
- ファシリテーターは事前に異常や課題、問題を確認して会議の進行を考える。
- アジェンダと議事録のテンプレートをGoogleスプレッドシートで用意する。
- アジェンダと会議資料は会議前に参加者に展開して事前に読み込んでもらい、その状態を前提に会議を進める。
- 議事録は「決まったこと」と「次のアクション」のみ記載する。
- ファシリテーターは議事録がとりやすいように会議を進める。
- 会議資料は結論が最初にわかるようにする。
現状、上記で効率化(時間短縮)したい会議があるので、実際に試してみようと思います！
