会議のデザインパターン化という発想

# LT;DR 「会議をデザインパターン化すべき」という問題提起。

- 業務時間に占める会議時間は短くない。
- 「なんとなく会議」「だらだら会議」が多すぎる。
- デザインパターン化して、「悪くない会議」のフォーマットを作るべきなのかもしれない。

Work in progressだけど、まあ悪く無い発想なのでここまででアイデアをまとめておく。

# なぜ会議の時間がこんなに長いのだろうか？

会社においては、例えどんなに腕が良いプログラマーやSEであっても、他者との意思疎通、コミュニケーションを全くせずに仕事を進めることはできない。

+ [要求] 何を必要なのか/何を求めているのか。
+ [制約] 何が制約/条件なのか
+ [成果] 何ができたのか/成果なのか。
+ [課題] 何ができていないのか/課題なのか。

業務に関する情報のやり取りをすることで、チームメンバー一人ひとりが高い専門性を発揮し、組織全体として生産性を高めることが、現代の知的労働者に求められている業務スタイルであると言える。

だがしかし。仕事として行う業務でありコミュニケーションをとるからこそ、**生産性が落ちている**、そんな場面がある。

## あなたの労働時間のうち、会議が占める割合は？

一週間の労働時間は、35～40時間くらいだろう。その中で、あなたは何時間会議をしていますか？

例えば、ある部門で毎朝朝会を開き、委託先と定例もする。火曜日は眺めの昼会を会議する。２つのチームに所属し、それぞれミーティングがある。など等があれば、気が付いたら下記のようなスケジュールになっていたりする。

- 月曜日：朝会(**15分**) + 委託先定例(**45分**)
- 火曜日：朝会(**15分**) + 昼(**45分**) + チームAミーティング(**60分**)
- 水曜日：朝会(**15分**) + プロジェクト進捗会議(**60分**)
- 木曜日：朝会(**15分**) + 部門定例(**60分**)
- 金曜日：朝会(**15分**) + チームBミーティング(**60分**)

これでも「１回の会議は60分まで」という制限を課しているケースである。実際にはもっと長引いたりするだろうが…

結局、月曜日60分、火曜日120分、水曜日75分、木曜日75分、金曜日75分。合計で、 **405分**。

一日8時間労働 = 480分、完全週休5日制だとしたら、2400分の労働時間。そのうち405分も会議をしてたら、**16.875%** も会議をしている事になる。

更にこれは「定例会議」だけである。それ以外に「突発的な打ち合わせ」で**75分**会議やったら、実に**20%**に達しかねない。

我々は考えなければならない。**なぜ会議を開催したがるのか、会議が有効に働く方向とは何か、そして、どうやれば会議を開催せずに業務を勧められるのか。**

## 単純に会議時間を短くするだけで問題は解決しない

仮にだ。会議時間を最大45分にすれば問題は解決するのだろうか？

例えば上記の例では、4回の会議で60分から45分に短縮すれば、1週間あたり合計60分短くなる。これで問題は解決するかもしれない、少なくとも短期的には。

だが、中長期的にはどうなるのか？「**パーキンソンの法則**」としてよく知られている。

https://ja.wikipedia.org/wiki/%E3%83%91%E3%83%BC%E3%82%AD%E3%83%B3%E3%82%BD%E3%83%B3%E3%81%AE%E6%B3%95%E5%89%87

１回１回の会議が短くなり時間が空けば、底に別の会議がねじ込まれる、ただそれだけの話である。何も問題は解決しない。

# 「なんとなく会議」「だらだら会議」という悪

## なんとなく会議

例えば、こんな会議はないだろうか？

- これから、何をしたらいいのかわかりません。
- だけど定例会議なので、毎週やるということは決まってます。
- だから会議開催します。何か問題があったら共有しましょう。

一見すると「課題共有のための会議」のようにもみえるが、これは単に時間の無駄にしかならない。

- その課題の優先度は誰が決めるのか？
- その課題よりもより優先度の高い課題は本当にないのか？
- その会議の参加者は、課題の当事者だけで構成されているのか？

こんな **なんとなく会議** だったら、やらない方がよい。

## だらだら会議

例えば、こんな会議はないだろうか？

- 上位部門で共有された内容を、下位部門で共有するための会議。
- 当該部門に関係ない話題も多く含まれる。
- ただただ、資料に書かれている文字を読み上げるだけ。

こちらも「情報共有のための普通の会議」のように見えるが、これも時間の無駄でしかない。

- 自部門に関係ない話題も１字１句伝える必要が本当にあるのか？
- 資料を読み上げるだけだったら、別の全員が揃っている場でなくてもいいのではないか？

こういう **だらだら会議** もやるべきではない。

## なぜ(ダメ)人間は無意味な会議を開きたがるのか？

では、なぜこのような無駄な会議を開きたがるのか？

- どうしたらいいのかわからないから、とりあえず前のやり方を繰り返す。
- 責任を取りたくないから、情報の取捨選択を自分でしない。受け手に任せる。

「なにをどうしたらいいのか分からないし、判断もしたくないので、現状維持しかしたくない」のではないだろうか……

こんなことをしている暇なんてないのに！！

ではどうしたら会議運営を改善できるのだろうか？　どうすれば先人の知恵を上手く使えるのか、
そこで、もしかすると「デザインパターン」という発想を取り入れることができるかもしれない、と考えた。

# 会議をデザインパターン化しよう

現代に生きるソフトウェアエンジニアの多くは、デザインパターンという単語を少なからず聞いた事があるはずだ。

https://ja.wikipedia.org/wiki/%E3%83%87%E3%82%B6%E3%82%A4%E3%83%B3%E3%83%91%E3%82%BF%E3%83%BC%E3%83%B3_(%E3%82%BD%E3%83%95%E3%83%88%E3%82%A6%E3%82%A7%E3%82%A2)

デザインパターンは言うならば、経験知である。常に最善の解決策であるとは限らない。だが、多くの場合にはトレードオフが十分考慮されたそこまでズレていない、典型的な解決策となるだろう。

我々はソフトウェアの設計や構造だけにデザインパターンの発想をとどめる必要はない。会議だ。我々は会議においてもデザインパターンを取り組み、それぞれの組織において最適化するためのきっかけを生み出す必要があるのではないだろうか？

というあたりをちょっと色々考えたい。。。

## 参加者のメリット

- 会議の流れが毎回同じだと、自分が次何をやるべきなのかが想像しやすい。
- 話がぐるぐる回らないので、効率的な会議になる。
- 発言が求められるので、きちんと参加しないといけない意識で取り組める、　など等…？

## ただしあくまでも「ベター」解でしかない

会議はその目的によって、やりかた、進め方を変えるべきである。

よって、デザインパターン化するという考え方は「及第点以下の会議を開催させないためのアイデア」であって、
間違っても「最高の会議を開催するためのアイデア」ではない、ということは名言しておく。

## 例）前提条件（会議のスーパークラス）

全ての会議開催におけるスーパークラス的な約束事、

- ファシリテーターを置く。
    - 会議の目的を共有する。
    - 議論の方向性があらぬ方向へ行かないようにする。
- タイムキーパーを置く
    - 会議開催時間を共有する。
    - 進捗状況を共有する。
- 議事録担当を置く
    - 発言ができなくなるので **新人には絶対にやらせない**
    - 何を記載するべきなのかは事前に共有しておく。
        - 開催日時
        - 参加者一覧
        - 議題一覧
        - それぞれの結論
        - Action Item

## 例）Discussion Pattern(議論パターン)

### 目的
Discussion Patternを用いると、参加者間で既知の共通認識に基づいて新しい発想や解決策を見出すことができる。

### テンプレート

このあたりの時間の使い方や流れをテンプレート化したい。

- 情報の共有
    - ゴールの共有：最終結論で行動する責任が誰かを確認する。
        - 最終結論は会議参加者全員の責任である（言いっぱなしは許容しない）
    - 課題の共有：具体的に何を解決したいのか？
    - 前提条件の共有：考慮しなければならない前提条件は何か？
- 討議（数セット）
    - 意見出し
        - 会議に参加できなかった人間の意見は、事前にヒアリングしておいて紹介する。
        - 共有した情報に基づいて、各自が考えたことを共有する。
        - あくまでも「100点」の回答を言わなくてもよい。
            - 誰かの40点の回答を他の人が強化して80点にするかもしれない。
            - 「このアイデアでは、こういう課題があるのはわかっている」などがあれば、積極的に述べる。
    - コメント出し
        - あくまでも論理的に、共有した前提条件・課題・ゴールを意識して発言する事。
        - 発言者が誰であっても平等に取り扱う。
        - 否定的な意見を言う場合には、同等以上に肯定的な意見を述べる事。批判し合うための場ではない。
- クロージング/合意形成
    - 多数決ではなく、参加者全員で納得できる最終結論を形成する事。

### 変形パターン１：強制意見

- 会議参加者は必ず自分で考えて意見を発言するように求める。
    - ケース１：ファシリテーターが参加者を順番に指定する。
    - ケース２：発言者が次のコメント者を指定する。
    - ケース３：参加者は１会議１回以上の発言を義務付ける。
        - 例えば、発言をしていない人間は帽子をかぶらせるなど、明確にわかると強制力が高まる（ただしやりすぎない事）。
- 課題によっては前に発言した人間と同じ意見・結論となる場合もある。その際に「あとは同じ意見です」で終わらせずに、自分で考えた発言には責任もって発言をさせる事。
    - できれば、どこまでは同じなのか、どこから先が違うのか、差異はなかったのかを考えさせる。
    - また、その結論に帰着するまでのプロセスなどを述べさせる。


### 変形パターン２：グループ化

- 討議を行う場合、個人単位で行う以外にグループ単位で行う事もできる。
    - １グループのメンバーは最大でも4～5人（それ以上多くなると全く参加しない人間が出てくる）。
    - グループ内で役割を決めて、仕事を回す事。
    - 発言者はグループ内でできるだけ持ち回りにさせる。
    - グループ内で発言者が偏らないように気を付けさせる事。特定個人の意見ばかりが通らないようにすること。


などということを色々考えてみた。。。

# まとめ　「会議をデザインパターン化すべき」という問題提起。

- 業務時間に占める会議時間は短くない。
- 「なんとなく会議」「だらだら会議」が多すぎる。
- デザインパターン化して、「悪くない会議」のフォーマットを作るべきなのかもしれない。

以上になります。