つらつら読んでみて、よくありがちな勘違いだなあって思った。
下記エントリにも書いたように会議の進め方を間違っている。
１つ目の理由は、民主的であるがゆえにコミュニケーションコストが爆発的に増えたことです。
「民主的なチーム」では、基本的に物事は話し合いで決まります。リーダーが勝手に決めたら、それは民主的とは言えません。ちょっとしたことでも話し合いが必要になるので、必然的に会議に割かれる時間が多くなります。会議、会議、会議の連続で、業務時間中は朝から晩まで全部会議！なんてひどい日もありました。
このようにして会議に時間が取られるようになると、肝心な他の作業のための時間が削られます。
(中略)
2つ目の理由は、「話し合い」を重ねることによって、とんがった意見がすべて丸くなってしまったことです。
ある人が「すごく面白い」と考える案も、他の人が見た場合には「全然面白くない」ように見えることは結構よくあります。そういう時に「話し合い」で解決しようとすると、最終的には無難な案に落ち着くのは目に見えています。無難な案は確かに万人から悪い評価を受けないものではありますが、誰かの心に深く突き刺さるようなこともありません。
会議についても学び直すべき ─『仕事が早くなる文章作法 - ［1］日本人のSE/プロマネが日本語を学び直すべき理由：ITpro』について - いろいろやってみるにっき
以降、あくまで鍵カッコ付の「民主的」「民主的なチーム」と会議の進め方について書いていく。まず、辞書としては民主的をどう表記しているんだろうということでgoo辞書。
［形動］民主主義、または民主政治の趣旨にかなっているさま。「―な選出方法」
そういうわけ民主主義がリンクされているので、民主主義も同じくgoo辞書から引用する。
人民が権力を所有し行使する政治形態。古代ギリシャに始まり、17、18世紀の市民革命を経て成立した近代国家の主要な政治原理および政治形態となった。近代民主主義においては、国民主権・基本的人権・法の支配・権力の分立などが重要とされる。現代では政治形態だけでなく、広く一般に、人間の自由と平等を尊重する立場をいう。デモクラシー。
元ブログの”上司”は辞書的には一見民主的だったと思う。自由と平等を守っているように見えるし。例えば次の例。
「民主的なチーム」では、基本的に物事は話し合いで決まります。リーダーが勝手に決めたら、それは民主的とは言えません。ちょっとしたことでも話し合いが必要になるので、必然的に会議に割かれる時間が多くなります。会議、会議、会議の連続で、業務時間中は朝から晩まで全部会議！なんてひどい日もありました。
この「民主的なチーム」はどのように構成員が決まったんだろうか。元ブログのように何か(プロダクト、ITサービス、ITシステムなど)を作り上げる場合、何を作るのかを決めるフェーズで同じ職種同じ職能のメンバーでチームを組むことはあり得ない。
同じ職種の要員は確保できても全員を同じ職能に合わせるのは難しい。通常であれば、下図のように様々な要員をメンバーにするはず。
総員が一人増えたのは気のせいなので気にしないように。図を直せっていう話だけどｗ。
本当に「民主的なチーム」ということであれば、リーダーだってチーム内で互選すべきである。元ブログにはそういう記述は無いので、リーダーは多分会社側で決めた人間がやっている。何らかのレベルの役職者だろう。そういう意味ではチームの成立時点ですでに民主的ではない「民主的なチーム」ということになる。
そして異なる職種異なる職能のメンバーで構成しているチームでは、それぞれの専門分野・得意分野などを意見に加味することが本来的に民主的。一般的に民主国家では三権分立しているわけで、単に「平等」ではなく役割や責任、権限を分散して持つもの。きちんと役割や責任、権限を分散していないということは、表層的・辞書的には「民主的」であるが、実質は本来の民主主義の目指すところの民主的ではない。
ということでこのリーダーがやったような会議会議会議…(以下省略)、みんなの意見が合意に達するまで会議をすることが「民主的」という勘違い。そもそもプロジェクトというのは”段階的に詳細化される”ものなので、なんでも合議っていうのは意味が分からない。会議会議会議…(以下省略)ってハンス・フォン・ゼークトが言ったとか言ってないとかっていう組織論で言えば、このリーダーは処刑対象だな。
理想のチームは元ブログに書いてある通りなので、同じことをなぞっても意味がない。ポイントを引用する。
このあたりはバランスが非常に難しいのですが、やはり重要なのはリーダーの果たす役割です。リーダーのすべき仕事は、メンバーの言いなりになることではありません。一方で、メンバーをコマのように強引に動かすことでもありません。ビジョンをメンバーに示し、そのビジョンをメンバー全員が納得するように働きかけること、それこそがリーダーの果たすべき役割だと僕は思います。
(中略)
メンバーがリーダーの描いたビジョンを自分のものとして共有できるようになれば、「すべて話し合いで決める」ような形はとらなくて済みますし、一方でリーダーの方針に従うことについて必要以上に不満を蓄積させることもありません。このようによいビジョンを描き、さらにそれを周囲に納得させられるかどうかが、リーダーの一番重要な能力と言っても過言ではないでしょう。
そこで『会議についても学び直すべき ─『仕事が早くなる文章作法 - ［1］日本人のSE/プロマネが日本語を学び直すべき理由：ITpro』について』の続きとして、こういう場合の会議の進め方について書いておく。
なにかITサービスやITプロダクトを上梓するITプロジェクトで言えば、ビジネスとしてのビジョンはリーダーだし、アーキテクチャについてはリーダーが示すビジネスとしてのビジョンに沿った形でアーキテクトがビジョン(アーキテクチャ)を示し、それをメンバーが納得して各々の担当分野にブレイクダウンしていくというのが理想形。
でもふつー、この手の話は上位組織や上位者(管掌役員など)から指示が出てスタートしていることが多いんで、ビジネスのビジョンのレベルで鍵カッコ付きの「民主的」って難しいような気もするけど。
まずビジネスとしてのビジョン。会議の形式としては、初期の段階ではディスカッション。たたき台をリーダーが提示し、メンバーからの質疑や意見を受け付ける。ここで、書記行為は書記として誰かを指名してもいいが、あくまでビジョンとしてはリーダーの責務で取りまとめる。つまり書く行為は誰かにやらせてもいいけど、中身の責任はリーダーのものってこと。異なる職種異なる職能のメンバーで構成されているチームなので、このディスカッションは、異なる職種ごとにサブリーダーだけを相手にやってもいい。このディスカッションの回数を多くとらないとまとめきれないリーダーは、リーダー向いてない。0回はダメだけど3回以上だとちょっとねえのレベル。
集約段階ではレビュー。初期のディスカッションで出た質疑に対する穴埋めや意見の反映あるいは意見を反映しない理由の明確化。ここできちんとレビューを完了できないと、このビジネスを管掌する上位組織及び上位者(管掌役員など)にきちんと説明できるレベルにならない。
最終段階はブリーフィング。レビューでの指摘事項を反映し、これで行くぞという宣言。ここまで各1回でチーム内のコンセンサスが取れていると望ましい。
アーキテクチャについてはもう少し細かい話になるので、ディスカッションやレビューの回数は多くなるし、最後のブリーフィングの場は必要ないかも。ドキュメントで示せばいいんで。
もっと細かい仕様についてはレビューだけでもいい。設計者がリーダーやアーキテクトや関連するメンバーからのレビューを受ける形式。全員参加は必要ない。
といったわけで、本当にこんなに会議会議会議…(以下省略)って、元ブログの人は少し大げさに書いたのかもなあというのが感想。では。
