理想の組織構造について

日帰りの東京出張。帰りの新幹線は電源が確保できたので、自分の思考の整理のためにこのブログエントリーを書いている。結論があるわけでも、何か語りたいことがあるわけでもなく、ただ考えや考えの筋道そのものを書きながら理解するために書いている。

3月が年度末のうちの会社では、だいたい年末からこの時期に来期の目標予算やそれにあわせた組織体制、人事などの議論が始まる。
また案件でも一番忙しい追い込み時期であり、且つ査定やらなんやらもやってくる、とにかく1年で最大級に忙しい四半期がこの1~3月なのだ。

この時期になると、ボクは必ずといっていいほどドラッカーの「現代の経営」を読み返す。とはいってもボクの場合は、悩んだらドラッカーという行動パターンなので時期に限らずではあるのだが、この時期はなおさらなのだ。この時期、特に毎年悩むのは、WEB制作やソリューションの会社にとってどのような組織形態が望ましいのかということだ。
もちろん、組織形態・体制は成果から導き出されなければならない、というのは、これもドラッカーの言葉ではあり、どれが唯一の正解というものはないのだろうけど、「原則」を踏まえておかなければ、そもそも思考の出発点から誤ってしまう可能性があるわけだ。

新訳 現代の経営〈上〉 (ドラッカー選書)
新訳 現代の経営〈上〉 (ドラッカー選書)Peter F. Drucker 上田 惇生

ダイヤモンド社 1996-01
売り上げランキング : 120626

おすすめ平均 starstar数々の問題点があるが、経営についてのポイントを押さえており、確かに役立つ。
starドラッカー本では「最初に読まれること」をお薦めします
starマネジメントとは?

Amazonで詳しく見る
by G-Tools

新訳 現代の経営〈下〉 (ドラッカー選書)
新訳 現代の経営〈下〉 (ドラッカー選書)Peter F. Drucker 上田 惇生

ダイヤモンド社 1996-02
売り上げランキング : 131434

おすすめ平均 starstar説得力は不十分だが、一読の価値はある。
star経営者のバイブル
star名著

Amazonで詳しく見る
by G-Tools
組織形態について言うと、ドラッカーは、ある条件をクリアすれば、組織の形態は「連邦型組織」が望ましいと述べている。

連邦型組織のメリットはマネジメントが機能しやすいというところに置かれている。連邦型組織の場合、各単一の組織の経営管理者は自身のマネジメント努力をそのまま直接「成果」にあわせることができる。一方「機能型組織」の場合は、個々の組織単位は、その単位だけでは「成果」を達成するには不十分で、横との関係、調整が必要だ。
例えば、メーカーならば「製造」「販売」「研究開発」というような機能単位組織があるだろうが、組織の成果を考えたとき「製造」部門も「販売」部門もお互いの部門の貢献がなければ、直接的な成果への貢献は難しい。

ドラッカーが言う連邦型組織の成立に必要な条件とは、そもそもその組織構造が可能、維持できるだけの「規模」だ。
ドラッカーは「あらゆる事業に、それよりも下の規模になると機能別組織によってしか組織できないというレベルがある。」と語っている。
例えば、制作会社で考えてみよう。数十名程度までは、1会社が連邦型組織における1組織単位レベルなので、連邦型組織を適応することはそもそも不可能だ。ありえるとするならば、全員がプロデューサー&コンサルタントみたいな感じで、自主独立型のソリューションモデルをとるケースぐらいで、この場合は、そもそもそ「組織」という言い方は相応しくはないが、1人1人が「組織単位」として働くということになるだろう。一種、擬似的な連邦型組織だ。

数十人レベルまでなら、普通は、「ディレクター」や「デザイナー」「プログラマー」とか、そういう職種レベルで組織されるだろうから、これは言うなれば「機能別組織体系」だ。基本的には、個々の組織はその組織単位で完結して直接的成果を設定することが困難だろう。なので、個々の組織単位では専門性のスキルアップやナレッジといった能力要素による評価がベースになる。
制作会社でも100人、200人といった規模になってくると、連邦型組織をとる場合もでてくるだろう。30人ぐらいを1組織単位として、その中に「ディレクター」や「デザイナー」など、必要な機能を有して、それぞれの組織で独立した事業体に近い構造になる。各組織のトップは、いわばその組織の「社長」と同じような立場になるわけだ。
規模が大きくなっていくなかで、機能別組織をとり続けると、経営管理者が育成しにくいとか、経営管理者を成果への貢献といった視点から評価するということが難しいなど、いろいろ問題がでてくるので、連邦型組織のほうが経営・マネジメント上も効果的ということになるだろう。

連邦型組織をとる場合の原則としてドラッカーは以下の5つをあげている。

1.連邦型組織においては、中央と分権化された部分の双方が、強力である必要がある。
分権化しても、「中央」が明確かつ意味のある高度の目標を設定して、各部分に対して強力な方向づけを行わなければならない、ということだ。

2.連邦型組織における単位組織は、自らのマネジメントを維持できるだけの規模をもつ必要がある。
3.連邦型組織における単位組織は、それ自体が成長していける必要がある。
4.連邦型組織における単位組織の経営管理者には、広い活動領域と挑戦の機会が与えられることが必要である。

5.連邦型組織では、あらゆる単位組織が、自らの事業と市場と製品をもち、対等の立場に立つ必要がある。重複する領域では、GMやフォードの事業部のように、お互いに競争関係にある必要がある。例外的な場合を除き、共同して事業を行ってはならない
単位組織間の関係は、密接かつ友好的でなければならないが、あくまでも取引関係としての関係でなければならない。自立できないための補完関係であってはならない。
単位組織を自立したものとして組織できない場合、すなわち一方が扶養し、他方が依存せざるをえない場合においても、それぞれの単位組織に対し、アメリカの政治理論に倣って私が名づけたところの「実施拒否権」を与えることが必要である。

2~5はほぼ1セットみたいな感じだ。連邦型組織体系をとる以上は、それぞれの単位組織は、自らが事業を行い成長していける規模や権限が必要だし、また個々の組織は同じ会社ではるけれど、あくまでも取引関係としての関係を持ち、どっちかがどっちに頼るというような構造を持ってはならない、ということ。

これはしかし、一見、いろいろ非効率なところがある。100人の制作会社で30人単位の事業部が3つ、10人のバックオフィスが1つ、みたいな組織体制をとるとしよう。
連邦型組織の場合は、その3つの事業部は30人規模の1つの制作会社みたいなものになる。もちろん事業部ごとに特色があったり、得意領域やミッションが定められていたり、担当するクライアントや案件の性質みたいなものも分かれていたりはするのかもしれない。でも、ソリューションと言う仕事の性質上、完全な切り分けというのはやはり難しいだろうから、実質的にはこの3つの事業部はそれぞれ競合関係に置かれるわけだ。

このときある事業部は好調で仕事があふれるほどあり、ある事業部ではそうでもない、という状況はよくある。忙しい事業部ではデザイナーが不足して困っている。内製だけではどうにもならず外部パートナーへの発注も多い。一方で、そうでもない事業部内のデザイナーは暇だったりする。忙しい事業部側から見ると、そうでもない事業部のデザイナーにも仕事を御願いしたいと思う。同じ会社だし。マネジメントの立場から見ても、それで外部に出て行く原価が、労務費で済むなら、そっちほうが効率的だと考えるだろう。

あるいは、いういう例。あるチームにそのチームでは手におえない案件がやってきた。他のチームに聞いても、今は稼動状況は厳しく各チーム単位で考えると、受けるのは難しい。でもそれぞれ3チームの比較的稼動が高くないスタッフを集めてプロジェクトチームを組めば受注できなくもない。なし崩し的に事業部の枠を超えた人事とプロジェクト組織に傾く。

というようなシチュエーションは、ボクも経験したことがあるし、ある程度の規模の制作会社ではよくあることなんじゃないかと思う。

しかし、連邦型組織の原則にのっとると、「自立できないための補完関係」というのはNGであり、そうでもない側は「実施拒否権」も有しておかなければならない。忙しい側もそうでない側も対等な立場にたつので、基本的には会社内部とはゆえ、受発注関係で仕事をしていくことが望ましいということになるだろうか。上の例でも、3チームのそれぞれのスタッフが集まるようなプロジェクト体制においても、連邦型形態を蔑ろにしてしまっては意味がないので受発注関係をとるのが望ましいということか。

なんで同じ会社なのに、そんな面倒なことを、となるだろうけれど、連邦型組織形態をとって、そのメリットを最大限享受していくには、そういう原則を持たないと駄目ということだろう。マネジメントの責任や挑戦、役割といった領域に焦点をあわせるならば。
内部だからと優遇措置をとれば、当然、それにお互いが甘えることになるし、競争が発生しなくなればイノベーションへの意識も低下していくだろう。行き着くところは、お互いがお互いに依存するような関係にしか行き着かない。連邦型組織としては破綻している。

個々の事業部のマネジャーは、最終的には成果への貢献というところで評価されるわけで、そこから見て、状況が厳しければ1クライアントとして、忙しい事業部からあふれでる仕事をとりにいくことも必要だろう。ただ、この場合も、あくまでも対等な立場でなければいけない。中央が忙しい方からそうでもない方に無理矢理仕事をスライドさせたり、あるいは同じ会社内での受発注なのだからと、甘い条件で受発注を行ったり、ということは避けなければいけないわけだ。

こういうマネジメントを徹底させるというのは、実はものすごく難しいと思う。つい易きに流れるというか、経営状況がどの事業部も問題なければそれでいいのだが、うまくいかないところが出てくると、あるいは、それが許容範囲を超えそうになると、全体でのバランスを見たり、調整をとるということはせざるをえなくなるからだ。見方を変えれば、それでうまくいかないようになるということは、まだ連邦型組織をとっていくための前提条件に達してない組織なんだと考えてもいいのかもしれない。

また、ソリューションビジネスってのは、最適な1組織単位をどう設定するのかってのもけっこう難しい。2~3人でも独立した事業組織としては成り立つ場合もあれば、50人でも少ない場合もあるだろう。事業のモデルやクライアント、仕事内容と組織の職種構成、人数というものの最適解ってなかなか見出せないのだ。マーケティングや事業モデル、戦略とセットで考えなければならない要素ではあるが、ソリューションビジネスの場合、顧客側が圧倒的な力をもっていて、その要求や課題にどこまで対応していけるのかというところが、事業を伸ばすための鍵でもあって、こちら側が意図する事業範囲や要求範囲だけにこだわっていくというのは難しいということもある。

あと、問題になるのは同一職種でのノウハウ共有や師弟関係の構築部分だ。制作会社で純粋な連邦型組織をとると、各組織単位にディレクターやらデザイナーやらIAやら、プログラマーやらといった異なる職種の人間が集うという形になる。デザイナーという職種の人は全員で10人いるけど、事業部が5つあって均等に割り振られた結果、各事業部には2人しかデザイナーがいない。10人でまとまってる方が、ナレッジの共有もしやすいだろうし、スキルアップや教育制度などもとりやすい。あるいは10人のほうが2人しかいないよりも、大きい仕事ができる、みたいなことがある。
ということで連邦型組織をとりながら、一方で同職種や同工程の人を括るグループもつくるようなダブルボス型、マトリクス型の組織形態をとるところもあるだろう。
なんとなくうまくいきそうだが、経験ではマトリクス型組織をきちんと機能させるのは難しいという印象がある。どっちつかずになるというか、どっちもの形態がどっいもうまくいかないところの言い訳に使われてしまったりするとか。

このへんで機能型組織と連邦型組織のジレンマがある。
機能別組織でもいいんじゃないの、と考えてしまうのだが、ドラッカーは機能別組織には以下のような弱みがあると指摘する。

・機能別組織は、事業全体の成果に焦点を合わせることが困難
・機能別組織の経営管理者は、自らの部門の機能を最も重要と考え、その確立に力を入れがちになる。結果、自らの部門の利益のために事業全体の利益やあるいは他の機能別部門の利益を従属させてしまう
・機能別組織は必然的に専門性を重視し知識や能力の獲得を重視する。結果、専門家はマネジメントには適さないビジョン、技能、忠誠心が偏狭になる
・機能についての目標が設定しにくい。仕事の成果が評価測定しにくい
・機能別組織ではマネジメントの階層が増えていく
・これからの経営管理者の訓練、評価ができない

このへんはよく理解できる。会社が小さくて、自分の仕事や働きと、会社の成長や事業そのものとのシンクロが感じられる状態であれば特に問題にもならないのだが、ある程度の規模になっていくとだんだん直接的な繋がり感を失っていく。こういう状況になってくると、自分の頑張りと会社の目標だとか成果だとかの関係が薄くなってきてくる。

100人の組織で機能別組織をとって、仮にディレクター30人、デザイナー30人、システム陣30人、バックオフィス30人というようhな機能別組織体制をとる場合を考える。目標売上が10億だった場合、この10億という数字(成果:もちろん、成果は売上みたいな数値面だけのものではないが、ここでは単純化するためにそう設定している)を追いかけるのは誰だろうか?
この組織体制において、デザイナーやシステム陣は、自身の仕事と10億と言う目標に対しての貢献度を測ることができるだろうか? 難しいだろう。
しかし、先の連邦型組織体系のように30人1単位での事業部で、それぞれに3.3億の目標が割り振られていたらどうだろうか。これぐらいの数字、人数ならば、さっきよりも随分と自身の貢献と成果の関係を整理しやすくなるのではないか。どの程度、成果に貢献しているかも測りやすくなるだろう。(そういう会計制度やデータが用意され、公にされなければならないだろうが) 

デザイナーやプログラマーが「売上」みたいな成果に照準をあわせるのは変だろう、そんなの知らないほうがいいし、そんなもんを意識してたらいい仕事ができない、というような考え方もあるかもしれない。正直、僕もどちらが良いのかよくわからないのだが、ただ、じゃぁ社長と営業マンや、ディレクターやプロデューサーという人間だけが成果を求めるということでよいのかどうかというと、そうでもないと思う。デザイナーやプログラマーは、売上や限界利益みたいな数値上の成果ではなく、別の「成果」に照準をあわせればいいということなのかもしれない。ただ、ボクは、そういう面は当然必要だとは思うが、デザイナーやプログラマーであっても売上だとか原価率だとか限界利益だとか、そういう会社の数値上の成果には感心や興味を持って、自身の働き方や能力との相応関係を意識してもらったほうが良いとは思っている。そっちのほうがスキルは上がるだろうし、業務への創意工夫や、自身の価値の客観的な把握などもやりやすくなるんじゃないかと思うからだ。

ということを考えていくと、ある規模を超えると、連邦型組織という形態をとっていくのが良いのだろうなとは思うわけだ。

少し脱線するが、京セラのアメーバ経営は、連邦型組織形態としての事業部構造は当然ながら、その下部組織としての機能別組織単位においても、(事業部によって異なるだろうがほぼ独立採算に近い形態がとられている。セラミックの部門などでは、製造工程単位での機能別組織単位を採用していると思われる)管理会計が導入されている。本で読んだだけなので、詳細まではわからないけれど、各事業部単位での受発注を厳密に設定して、それを稼動時間で割って1分あたりとか1時間あたりのスループットを産出し、個々の事業部でも採算を明確にしているようだ。

仕組みとしてはスゴイが、これを実際に機能させるのはかなりのパワーがいるし、また各事業部の経営管理者には高い倫理観や道徳観、そしてバランス感覚が求められることは間違いない。この仕組みを考え付いたのもすごいが、考えたものを実施して、そしてそれを企業の核として、どれだけ大企業になってもきちんと実践している、させているというところが京セラの、稲盛さんのスゴイところなんだろうなと思う。

制作会社が京セラ型のアメーバ経営を取り入れるとどうなるだろうかと何度も考えたことがあるのだが、ソリューションという形のないものを販売する形態ではかなり難しいんじゃないかということでいきなり思考が頓挫してしまうのだ。単純に考えれば、デザイナーやIAやシステムやらといった組織単位ごとに受発注関係をつくってみたいなことはできるのだろうが、お客さんに提供するものは、何か決まった形があるものではなく、そういった各職能や各工程の連なりによって決まってくるし、なかなか切り分けるのは難しい。


さて、原則に戻れば、組織は事業の目標達成のためにあり、そのための構造だ。どんな構造が必要かを知る方法は3つあるとドラッカーは言う。

1.活動分析
⇒「典型的機能」での分類は危険。事業の目標を達成するために必要な活動を分析して、そこから答えを導き出すこと
例)婦人服産業⇒エンジニア×、生産× 重要なのは「デザイン」/ある電球メーカー⇒新規客発掘><顧客当りの電球使用数の増大⇒照明用途と習慣の拡大⇒広報活動を独立した機能として組織。

2.意思決定分析
⇒事業の目標を達成するために、いかなる意思決定が必要かを、その意思決定を組織のいかなるレベルで行う必要があるかから考えること
意思決定に関わる権限と責任を正しく位置づけるには、意思決定を種類と性格によって分類すること。意思決定の分類には4つの基準がある。
意思決定の息の長さ他部門、他領域など事業全体への影響の大きさ行動規範、倫理的価値観など含まれる価値的要因の数、最後が反復して起きるか、稀にしか起きないか

3.関係分析
⇒それぞれの経営管理者はだれと協力して働かなければならないか。
昔は、経営管理者は「下」との関係において定義してきた。しかし今は、上位の部門に対しての貢献から出発しなければならない。上との関係を分析して、あわせて横との関係を分析すること。

まず、事業目標、事業目的があり、そこからこの3つの分析をしっかりと行うことで組織の構成の基本的な骨格をつくっていくことが必要であり、それが結果として機能別組織なのか、連邦型組織なのかは結果論だろう。

理想的には可能な規模を有するなら連邦型組織をとったほうがいいし、その場合は、上で書いたような原則をあてはめたオペレーションを徹底していくこと。機能別組織体系をとらざるをえないときにおいても、連邦型組織に近い形態、考え方をとる(京セラのアメーバ方式はそうだろう)ほうが、成果をあげるようになるだろう。

スポンサーリンク

シェアする

  • このエントリーをはてなブックマークに追加

フォローする

スポンサーリンク

コメントをどうぞ

メールアドレスが公開されることはありません。 * が付いている欄は必須項目です