こんにちは。 エンジニアの濱田( @hamakou108 )です。
弊社の開発チームでは特定の役割をうまく果たすための知見を「型」として文書化し、チーム内で共有しています。
今回はその一つである「ファシリテーター & 議事録係の型」を紹介します。
弊社の開発チームでは週に1回、加えて隔週に1回のタイミングで定例ミーティングが開催され、ファシリテーターはエンジニアが担当しています。 ファシリテーターを担当したことがある方であれば、会議の中で様々な問題に直面することは想像に難くないと思います。 議論するのに十分な情報が事前に収集されていない、議論が発散し続けて結論が得られない、会議後に誰がいつまでに何をすべきなのか記録されていない、などなど。
弊社の開発チームではこういった問題に対する解決策の一つとして、ファシリテーターが議事録係を兼ねるという取り組みを実践しています。 その戦略の意図と狙っている効果、またファシリテーターと議事録係のそれぞれの役割において望まれる振る舞いについて「型」を通して紹介できればと思います。
これは何
開発チームにおいて会議を回すファシリテーターと主書記は同じ人がセットでやることになっている。 会議をスムーズに進行し、有用なものとするために何をしたら良いかの型を模索するための資料。
前提説明: ファシリテーターと主書記について
主書記とサブの役割について
議事録係には主書記と、サポートするサブがいる。 それぞれの役割は以下の通り。
- 主書記
- 議論の骨格を書く人
- ファシリテーターと同じ人がやる
- サブ
- 主書記が書かなかった(書けなかった)議論や情報の細部を書いていく人
議事録係を分割した理由
議事録係(ファシリテーターと分離されている「全ての記録を残す」役割)は難しい。 何が難しいか。
- 議事録のリアルタイム性が重視されているので、会議の議論に遅れずについていかなければいけない
- 全ての発言を書くのは現実的ではないので、話していることを正しく要約する必要がある
- 上記のため、議事録係は積極的に議論を止め、話している方向を確認し、要約や結論を促す必要がある
この役割を果たすにあたって、ファシリテーターと議事録係が別だと以下のような不都合が起こる。
議事録係を専任でやるのは、会議をファシリテーター同様にコントロールすることと、記録を残すことの両方をやる必要があり、高いスキルが要求される。
ファシリテーターと主書記を同じ人がやるメリット・デメリット
- メリット
- 会議の骨格を作っている人と、骨格を書いている人が一緒なのでニュアンスがずれない
- 議論の内容を要約しながら進めるので、ファシリテーター自身が会議の方向性を自覚しやすい
- 言葉で説明され、要約を文字で読めるのでメンバーが話について行きやすい
- 上記のことから、会議が暴走しずらいことを期待する
- デメリット
将来的な話
将来的には、ファシリーテータ & 議事録係のセットで経験を積んだら、議事録係単体でも上記の難しさを乗り越えるスキルが付くはずなので分離しても良い。
一番重要なこと
参加者の時間を使っていることを意識する
会議の参加者が多ければ多いほど、その出席者の時間を有効に使うことが求められる。
その会議をやることで、やらないよりチームにリターンがある場合に開催すること。 リターンがなければ解体する。
会議の目的をはっきりさせる
会議が何を目的にしているかはっきりさせる。 複数の目的が含まれている場合、必要に応じて会議を分離する。
誰を呼ぶか
会議の目的に合わせて過不足ない人を呼ぶ。
事前準備
誰も何も考えていない、または決めていない時間は無駄な時間となってしまうので、事前準備が大事。 誰の持ち込みの議題で、何を相談したいかはっきりさせてから会議に臨むのが望ましい。
ファシリテーターの仕事は参加者にこれを促し、やってもらうこと。 必要に応じてチャットツール上であらかじめ議事録を共有し、必要な内容を書いてもらえるようにメンバーに促す。
議題が用意されたら、会議内で議論する必要があるポイントを整理し、それ以外を会議の外に持っていく。
- 議題の起案者に論点を明確にしてもらう
- 場合によってはたたき台を用意してもらう
- 一部の関係者のみでチャットや会話で議論し、結論だけ持ってきてもらう
議論する内容が定まったら、優先度に応じて議題の順序と目標時間を整理し、会議のゴールを設定しておく。
進行
会議のゴールを共有する
会議のゴールを参加者全員がわかるように共有する。 定例などでも、たまに忘れ去られてそうだったら改めて共有する。
また議題の順序と目標時間を共有し、参加者に議論を時間内に収めてもらうよう促す。
まず情報を集める
情報を持っている人を明確にして、ヒアリングをする。 会議の参加者が同じ前提の情報を持って話せるように議事録に落とし込む。
意見を募る
たたき台があればそれを使う。 なければ雑でもいいので自分で捻り出す。たたき台もないとみんなが発言しづらいので、自分の案が 💩 だと思っても何か出す。
情報を持ってそう or ちゃんと考えてそうなのに話していない人がいたら話をふる。 うまく参加できていない人がいたら、突然のボールでもあえて振ってみるのもいいかもしれない。 その後会議に積極的になってくれたらもうけもの。
今は何の時間か?
ファシリテーターは今何の時間なのか明確に発言し、遊びの時間を減らす。 察してもらえるだろう、というレベルのものも明確にする方が良い。
たとえば
- 「画面共有しますね」みたいな数秒で終わる発言
- 「この資料を見て〇〇をする時間です。✖️✖️分までです」
- 「〜〜の立場として△△さんの意見を聞いてもいいですか?」
着地点を探す
情報や意見が集まったら着地点を探す。 結論は明記しておく。
結論の書き方はフォーマットは自由だが、チームとして共通認識のある表現にする。 「誰が、何を、いつまでに」の3点が要素として含まれていると望ましい。
- 結論: 〜〜 みたいな書き方で明記しておく
- (これは弊社の開発チームのみで定着している)議論の過程でこれが結論になったというところを太文字にしておく
時間内に収まらないような長い議論の場合でも、中間地点として方向性が決まることもあるので「中間結論」を明記できると良い。 次の会議に議題を持ち越す場合は、以下の点を明確にしておく
- 今回は何が決定されたか(中間結論)
- 次回は何を決定するか
- 次回までに何をする必要があるか(宿題)
会議の結論と宿題を共有する
会議の終わりに、出た結論を振り返り、本当にその結論でよかったのか確認する。
次に「誰が、何を、いつまでに」する必要があるかを共有する。 次のアクションが決まっていないものをはっきりさせる。
議論が白熱すると共有のための時間がなくなる可能性があるので、ファシリテーターは余裕を持って時間管理をしておく。
議事録
意識
ミスタイプを恐れない。 会議を進めることを重視する。 サブがサポートする。
役割
ファシリテーターが議論の骨格を書く。 得たい結論の方向性から逆算して、大まかな話を誘導し、議事録係としてリアルタイムに反映させる。 他のメンバーが同時編集できる一つの議事録を見て現在地点がわかるのが理想。 例えば esa であれば編集モードでカーソル位置がわかるので、より明確にどこを見ているかわかる。編集モードでみんなが編集、閲覧するのを促す。
議論が明後日の方向に行ってしまったり、ファシリテーターを置き去りにして進んでしまう場合には、一旦止めて「こういう話ですよね?」がはっきりするまでメンバーを待たせる。
発言者について
同じ職種や近い情報を持っている人のみの会や、意思決定者で無い人の発言は匿名発言として名前を書くことは強制されない。
全て書いてもいいが、慣れていないと大変なので必要なポイントに絞るのも良い。 以下のパターンで名前を明記しておくと良い。
- それぞれの意見を順番に聞いたパターン
- 役職として決定権がある人の結論
- 最終的に議論が割れたケースで、決定者がえいやと決めた場合に、後から振り返ってなぜそうなったか分からないケースがあるため
- ただし、決定権がある人が決めたとしても、理由も無しに決めたわけでは無いはずなのでちゃんと理由を明記しておく。理由がなかったらメンバーは納得できていないことが常なので、それを積極的に聞いて議事録に残す。
- 最終的に議論が割れたケースで、決定者がえいやと決めた場合に、後から振り返ってなぜそうなったか分からないケースがあるため
終わった後の処理
会議の後に議事録は必要に応じて整形する。 次のアクションとして振り分けたタスクが進むように改めて通知したり、自分で作業したりする。
- Try ボード 1 に積む
- issue を作る
- 調査する
- 次週までに決めておく
伝える
議事録を整形し終わったら、宿題をまとめてそれぞれの担当者に通知する。
次の会議でやること
前回の会議で決まったもので、置き去りになっているアクションをはっきりさせて、アクションを促す。
おわりに
エンジニア、デザイナー積極募集中です! ぜひカジュアルにご応募ください!