長い打ち合わせを短くするためにやったこと

はじめに（前提など）

打ち合わせが長くて、すごく辛かったので短くするために頑張った

チーム

僕のチームではスクラム開発をしていて、スプリントの期間は1週間

7人いて、2人は企画、5人は開発

週のスケジュール

まず前提として週のスケジュールはこんな感じ

以前それぞれのイベントにかかっていた時間と （今回の話で書いている努力の結果として）短くなった今の所要時間も書いている

イベント	頻度	予定時間	以前の所要時間	今の所要時間	備考
プランニング	週1	2h	3h	1.5h	短くなった！
レビュー	週1	1h	1h	1h
レトロスペクティブ	週1	1h	2h	1h	短くなった！
朝打ち合わせ(進捗報告)	毎日	15m	1.5h	15m	間延びしなくなった！
夕打ち合わせ(困ってること報告)	毎日	0.5h	0.5h	0.5h	報告内容に依る
突発打ち合わせ(仕様や実装の相談)	週2くらい	決まってない	0.5h ~ 2h	~ 1h	短くなった！

※スクラムイベントとかの用語の雑な説明

• スプリント：開発の期間。僕のチームでは1週間
• プランニング：スプリントの期間にこなす作業の計画を立てる打ち上わせ
• レビュー：スプリントの期間にこなした作業の報告を偉い人にして、フィードバックをもらう打ち合わせ
• レトロスペクティブ：スプリントの期間の反省会

やったことの概要

基本的に施策をひたすら打ちまくることでヒットを狙っていった

以下にそれらを列挙するので参考にしてね

打ち合わせのルール、司会として頑張ることの2軸になっている

やったことの詳細

ルール編

チームのルールとして設けてみたこと

打ち合わせの司会なんてものは役割でしかなくて、本来誰かがやればいいし何なら毎回交代でもいい
誰でも司会ができるように（やりやすいように）ルールを構築しておくと良い

他所では暗黙の状態で成立しているであろうモノ（率直に言うと程度が低いモノ...）も多いと思う。正直

会話を被せるのを止めてもらう

喋りやすくなるから

残念ながらうまく定着しなかった

打ち合わせの際に口頭で話を整理しない。テキストエディタに書き出し画面共有する

文章で捉えたほうが絶対に分かりやすい
っていうか社会人なら打ち合わせ中にメモくらいとるでしょ、ということでそれを画面共有する

• 頭がいい人は時として論理が飛躍するのでその対策
• 話についていけない人の救済手段
• そのまま議事録にもなる
• 実装の話とか書いておかないと忘れがち
• 複数人が同じメモをとる手間が省ける

書き出しは自然言語に堪能で、要約・構造可がうまい人がやるといい

※新卒で入ったSIerにいた時は50歳くらいのベテラン部長がやっていた
　辞めた今思えばあの人の書き出しは非常に優れていたし、巨大なプロジェクトを束ねる素養の一部は間違いなくそこにあった

打ち合わせの議題・所要時間、資料を事前に共有する。必要に応じ打ち合わせの前にコメントを投げておく

打ち合わせ直前の資料共有はよしとしない。前もって回覧させる

「持ち帰って確認します」をなるべく事前に解消する

打ち合わせを行う前に共有の場か議論の場か明確にする

共有の場では極力議論をさせない
上に書いたとおり論点はなるべく打ち合わせ前に処理しておく

逆に考えると議論の場ってのはあんまりなくて、実装の相談とかブレストとかになるかな

場の区切りを明確にする

打ち合わせから打ち合わせへのナアナアな移行を許容しない

必ず打ち合わせ一つ一つを打ち切ってから別の議題に進む

例えば「一旦、朝の定例はこれで終わります。続いて定例で出た実装の疑問点についてですが～」

いちいち打ち合わせの場を設けない（打ち合わせにしない）

急いでない場合には打ち合わせじゃなくてチャットだとか、資料の回覧＋コメントで済む場合が多い
前述の「打ち合わせの議題・所要時間、資料を事前に共有する。必要に応じ打ち合わせの前にコメントを投げておく」を進めていった延長線上にあるルールかも

打ち合わせをすると元の作業から打ち合わせに移って、その後元の作業に戻って...と切り替えの手間が発生するというのもあるし（まあこれは打ち合わせタイミングの調整で多少マシになるけど）

※とはいえ、これはチームによってはNGかも、というかアジャイルソフトウェア宣言の以下の内容に反している

情報を伝えるもっとも効率的で効果的な方法はフェイス・トゥ・フェイスで話をすることです。 https://www.ipa.go.jp/files/000065601.pdf

個人的な意見だけど、僕は優れた日本語文章は発話より遥かにまともに情報を伝達すると思っている。適切に日本語が書ければ誤解は生まれにくい。うまくやらないとスピード感はあんまりないかもしれないけど

打ち合わせの決定事項・次のアクションを整理する

新卒みたいな程度の話なので割愛

司会としての努力編

場を仕切るというのは骨が折れるけど、どうしても必要になってくる

僕のチームでは一旦技術を集約させるため司会を二人に固定した

沈黙をなるべく作らない。次に進む

以下のようなシーンが多々ある

「ではこれでいこうと思います。問題ないですか？」
「(...沈黙...)」
「いいですか？」
「(...沈黙...)」

こういう時には沈黙を合意に捻じ曲げる

「では特に異論がなければこれでいきます。問題ないですね？」
「(...沈黙...)」
「ではこれ決定します」

一旦雑に合意しても本当に問題がある場合には「ちょっと待って」とか「(後からになって)そういえばさっきの箇所だけど...」と言ってもらえる

適当な人に「**さん、これで大丈夫だよね？」と聞いてしまってもいい
とはいえちょっと抜き打ちテストみたいになって心苦しさもある

そもそも沈黙しないでよ。と思わないでもない
「人が話していたら頷くなり相槌を打つなりしろ」と僕は少なくとも小学生の時には教えられた

関係ない話が長くなりそうだったら切る

例えば進捗報告の場で難しい実装の話をし始めたら切る

「それ長くなりそうなので後にしましょう」

これを言えるようになるまでなかなかに心労が...

論点のズレに敏感になる

議論が白熱してきたらチームメンバーに喋らせておいて、静観・整理してみる

たまに論点がズレていたり、論点が2つに分裂していたりする

「申し訳ないですが論点ズレてきている気がします。課題は**ですよね？」

これを言えるようになるまでなかなかに心労が... part2

問題が不透明な状態で問題について議論させない

論点のズレに近いかも

例えば、こういう話があったりする

「さっきの会議の中で出た話でAの案件で仕様変更が発生しそう！明日にはわかりそうだけど...」
「明日から着手するBの案件のタスク色々積んでるけど仕様変更の規模が大きいとマズイ！」
「A, Bの作業の優先順位どうする？Bのスケジュールずらさないといけないんじゃない？！」

ここでいう「不透明な問題」は案件Aの仕様変更の内容
それが確定しないまま、それについての話をしたところで当然フラフラした話にしかならない

なので問題の内容が不透明な状態でその問題について議論させるべきではない
※因みに上の例では、話の翌日に仕様変更の規模も小さかったことが判明。全くの杞憂だった

でも、のっぴきならない状況であれば、仮説に基づいて複数の対応パターン考えることになるとは思う

説明を人に委譲する

何でもかんでも司会が喋ればいいわけじゃないので、ある話題について得意な人がいたら任せる

当然といえば当然の話

打ち合わせが長引いてきたら圧をかける

「そろそろお腹が空いてきたので結論を出したいところですが...」

打ち合わせをきちんと終わらせる

だらだら次の話次の話と続いてしまう場合が多い（Slackで済む話が多い）
そういう時は無理やり切る

「あ～～！時間です！時間なのでこの打ち合わせはここまで！ではお疲れ様でした！」

いつも喋りにくそうな人がいたら別途理由を聞く

公の場だと激詰めみたいになりそうだったらコッソリ聞いてみてもいいかも

そういう人に限って案外話をまとめられたり、いい疑問を出してくれるのでなるべく改善を図る
その人のためだけではなく人的リソースを利活用するという意味で

打ち合わせが長いという共通認識をもつ

「打ち合わせ長いよね？！」とコッソリとチームメンバーに聞いてみる

共通認識を確認した上で「僕が打ち合わせを短くするよう頑張ります」と伝えておけば当事者意識を共有できる（巻き込める）

おわりに

人間は自由すぎるし中身に個人差があるので基本的にルールで縛ったほうがいい
ルールは人間を補ってくれる

打ち合わせ時間が短くなってから、「前は打ち合わせが憂鬱でした」みたいな話が出たりする
頑張った甲斐があったなぁ...（でも憂鬱だったなら行動起こしてよ！）