MECEで役割分担をしがち問題
DevLOVE Advent Calendar 2020の12日目です。
※空きがあるので興味のある方はぜひご参加ください！
今年はテーマが2つあり、僕は「テーマ① 自分の周りの○○問題を問題提起する！」を扱います。会社の先輩と数分の話をしたくらいのネタなので全く深く考えられていないですが、面白い観点なので書いてみようと思います。
MECEに役割分担をしがち問題
問題提起する内容は「チームでも組織でもMECEに役割分担をしがちである」ということです。MECEというのはMutually Exclusive、Collectively、Exhaustiveの頭文字を取った言葉で、「漏れなく、ダブリなく」という意味をもっています。よくロジカルシンキングの文脈で出てくる考え方です。図書館の本の分類を想像してもらえるとMECEがわかりやすいかもしれません。
チームや組織でも役割ごとに人、部署を変えて漏れなく、ダブリない構造をとることが多いと思います。「漏れなく」はやるべきことの抜け漏れがなくなるので重要ですが、「ダブリなく」については疑問が残ります。ダブリのない構造は一見すると効率が良く見えますが、ダブることによるメリット、ダブらないことによるデメリットがありそうです。
例① ペアプログラミング
例えば、ペアプログラミングがそうでしょう。ペアプログラミングというのは二人一組でプログラミングを行うことです。プログラミングにピンとこない人は数学の問題を解くことをイメージするといいかもしれません。
一人ではなく二人で行うと時間がかかりそうに思えますし、実際にかかります（単純に倍ではないですが）。しかし、書籍「XPエクストリーム・プログラミング検証編」に載っているデータをみるとデメリットよりもメリットの方が多そうです。
▼ペアプログラミングのメリット
・後からミスに気づく確率が下がる
⇒常にお互いがチェックし合う状態であるため
・より良い設計（プログラミングの書き方）になる
・楽しい！
（リンクを貼ってみたものの、値段が高騰していますね…）
例② 伝言ゲーム
情報伝達は人を介するごとに正確に伝えられる確率が落ちていきます。伝言ゲームをやったことがある方はイメージがつくのではないでしょうか。
間違った解釈で仕事が進んでしまったり、手戻りがあったりして余計な時間がかかってしまうことはよくあります。これはダブリなく人や組織を細かく区切ってしまい、情報伝達する回数が増えてしまっているからではと想像しています。
例③ 受発注の関係で忖度が発生
ダブリがないということは、それぞれの境界がハッキリしているということです。僕が最近感じているのは、仕事における受発注の関係がチーム活動の邪魔をしているのではないかということです。
受注者側が発注者側に必要以上の忖度をし、作業量が増えてチームの負荷が上がる。チャット上で、チーム全員に関わることだから全員へアナウンスすればいいのに発注側にだけメンションする。そういった微妙な動きをしてしまうのも「ダブリなく」の構造があるからなのかなと感じています。
バランスが大事そう
もちろん、分割ゼロを目指すべしということではありません。分けるべき所と分けないべき所のバランスが重要なポイントになりそうです。
例えば、会社の広報に関しては組織全体を見渡すようにするため、役割を担う部署を作った方が良いでしょう。しかし、社員全員が広報に関する十分なリテラシ－を持ち、同じ考えのもとで行動できるのであれば、専門部署は必要なさそうです。
----
チーム・組織におけるMECEな役割分担という観点は奥が深そうですが、より良いチーム・組織を作るためのヒントになりそうだなと感じています。引き続き考えていきたいと思っています。
この記事が気に入ったらサポートをしてみませんか？