小さな会社から大きな会社に移って、良い意味でも悪い意味でも色々なカルチャーショックを受けました。
転職して2年半経ちますが、未だになじめないのが【長時間の会議】と【大人数での会議参加】。
みんな、会議好き過ぎぃぃぃ。
1週間のスケジュールのうち、8割ぐらいが定例の会議で埋まっている人もいます。
毎週行われる定例の会議だけでですよ。
同じような人たちが集まり、同じような状況報告して、同じように時間だけが過ぎていく。
もちろん、多くの会議に呼ばれている人はそれなりの役職に就いていたりするので、物事を判断する場面では意思決定してもらうことは重要ですが、大した議題もないルーティーンの会議まで出席するってあるんですかね？
絶対にないですよね。
その証拠に会議には参加しているものの、大半の時間はノートPC開いてカタカタカタカタ。
もう、自席に戻って作業しなよ、、、
会議に参加しておいてひたすら内職する姿勢も悪いけど、わざわざその人を呼ぶ人もどうかしてます。
おそらく、これまでの慣例に習って思考停止でアレンジしているんでしょう。
もうアホかと。
今回は大きな組織にありがちな会議の場面において、無駄にコストを垂れ流さないための会議設定について書いてみたいと思います。
余裕をもった時間設定をしない
よくやってしまいがちなのは、余裕を持った長めの会議時間を設定するケース。
議論したい内容が途中で終わってしまわないよう、十分な余裕を持ちたくなる気持ちは分かりますが、時間を気にせずダラダラ進行することになり効率悪いです。
議題に対してギリギリ（或いはちょっと足りないと思われるぐらい）の時間設定をすることで、進行スピードを意識しながら効率の良い会議運営が可能となります。
なによりも、参加者の集中度合いが格段に上がります。
経験上、1時間を超える打合せで集中力が保てたことがありません。
自分がメインスピーカーの時でさえそんな状態なので、とりあえず呼ばれて参加しているだけの人なんかは良くて30分が限界でしょう。
また、長時間の会議の場合、PCを持ち込む人がほとんどです。
そして、議論に参加せずにひとすらPCをカタカタカタカタ…
私が主催する会議はだいたい30分以内に終わらせるように心がけています。
議論が白熱して30分で終わらないこともありますが、どんなに長くても1時間です。
そんなことを考えていたら、先日とても共感できるツイートが目に留まりました。
こういうのを表立って掲げるのは地味にすごいと思う。 https://t.co/QxshQk9Nfa
— 渡邉正人＠IT屋×柔術家 (@mw1919jp) 2018年12月14日
なにがすごいって、社内の打合せだけでなく、来客者に対しても堂々と宣言してしまうこのスタイル。
これを見ただけで、この会社は【時間】に対する意識が高くて良い会社だなと思ってしまいます。
因みに、この会社はフリマアプリのCASHを運営している会社です。
代表の光本さんの経歴が凄まじいので、気になった方は調べてみて下さい。
Twitterアカウントはコチラ↓↓↓
twitter.com
「とりあえず参加しておいて」をやめる
長時間会議に並んで「なんだそれ？」と思った文化の一つが、大勢で会議に出席するスタイル。
議題の幅が広いからなのか、或いは会議後に設計者やプログラマーへ会議内容を伝達するのが面倒からなのかは分かりませんが、とりあえず皆で仲良く会議に参加します。
おいおい、待ってくれよ。発言もせず、終始うつむいたままノートPCを叩きまくっている輩が半数ぐらいいるぞ、、、
このとりあえず参加しておいて精神は何なんですかね？
ただでさえ会議多いのに、議論に参加しないメンバーがゾロゾロと会議室に吸い込まれていく。
まるでサ●エさんのエンディングのようだ、、、
大人数で参加することで安心感が得られるのかも知れないけど、これは絶対にやめた方がいい。
システム開発などをしていると、顧客との打合せの中でそのシステム（機能）を作るための業務背景や課題を掘り下げて聞ける場面はありますが、その内容を全SEや全PGが知っておく必要はありません。
もちろん、SEやPGも知識として持っておくことは非常に大切なことですが、そのような核心に迫る話になるのは感覚として会議時間の5～10%ぐらい。
残りの時間は知ってっても知らなくてもいいような内容について議論していることがほとんどです。
そういった打合せにはリーダーや一部のキーマンのみが出席し、残りのメンバーは自分が本当にすべき作業を黙々と集中してやってもらった方が間違いなく全体の生産性は上がります。
会議終了後、要点を絞って重要な決定事項のみをメンバーに伝えて適切な指示を出す。
このプロセスがきちんと回れば、生産性は飛躍的に向上します。
プロジェクトのリーダー格であれば、多少不安があっても単身ユーザー先に乗り込んでハッタリを交えながら切った張ったが出来る度量が欲しいものです。
人はそうやって成長していきます。
報告するだけの会議はやめる
システム開発の現場でよく目にするのは毎週のプロジェクト報告会。
ユーザーに対して、毎週決まった日時にこの1週間の作業状況を報告します。
これは完全に廃止することは難しいとは思います。
ただし、やり方は考えた方がいいです。
毎週毎週、決まったフォーマットの資料が配布され、進捗率が何パーセントで全体進捗は前倒しだの後ろ倒しだのを報告する会であれば、資料配布のみの非対面にしてみたり、或いは開催頻度を下げることを検討してみても良いかも知れません。
そもそも、ユーザーは個々のタスクの進捗率が何パーセントとか聞きたいんですかね？
私が発注者側であれば、毎週毎週そんな細かい報告をされるためだけに拘束されたくはないです。
思考停止で毎週会議を開催するのではなく、「この会議は本当に必要なのか？」ということを自問した方がいいです。
もちろん、全ての会議を全否定している訳ではありません。
【課題解決の場】としての会議体運営は非常に重要です。
プロジェクトで発生した課題に対しては、関係者でどう解決するか知恵を出し合ったり、内容次第では責任者に意思決定の判断を仰ぐ必要があります。
会議を開催する場合には、その目的も明確にした上で運営方法を検討しましょう。
まとめ
会議は【開催時間・参加人数・運営方法】の3点を見直すことで、劇的に効率が上がります。
会議自体には何の生産性もありません。
それにも関わらず、会議に参加しただけで仕事をしている感を覚える人が大勢います。
一週間のスケジュールを埋めることで仕事した気になっている人もチラホラいます。
プロジェクトメンバーの生産性（能力）を向上させるには時間がかかります。
プロジェクト全体の無駄なコスト削減は一瞬です。
習慣化しているプロジェクト内の会議運営を見直すことで、無駄をなくした生産性の高いチーム運営を目指しましょう。
