hidekatsu-izuno 日々の記録

プログラミング、経済政策など伊津野英克が興味あることについて適当に語ります(旧サイト:A.R.N [日記])

組織についてのエトセトラ

先日、「HIGH OUTPUT MANAGEMENT」を読んだ。インテルの創業者であるアンドリュー・S・グローブが書いた本で、当時の経営者はみんな読んでいたらしい。他の本で任天堂の岩田元社長などが実践していると書かかれていたワン・オン・ワン*1などはもしかするとこの本が元ネタなのかもしれない。

全体としてはなかなか面白い本ではあるのだけれども、さすがに1980年代に書かれただけあって古臭いところも多い。例えば、第一章の内容はTOC(制約理論)の方がわかりやすいと思うし、計測の重要性が強調される一方でどうやれば計測できるかという説明はまったくない。昨今書かれたものであれば、この本で書かれているような話を前提として、もう一歩進んだ議論がなされていると思う。

とはいえ、変な内容が書かれているわけでもなく、根拠は薄いものの興味深い話もあり、なかなか面白く読めた。しかし、これは問題なのでは、という記述もなかったわけではない。それは、二重所属組織、いわゆるマトリックス組織の推奨だ。

マトリックス組織とは、職能別の組織と事業分野別の組織でマトリックス上に配置し、各社員はふたつの組織に常に属すような組織形態のことを言う。

このマトリックス組織、どうも1980年代には大流行をしたらしいのだが、その後、実際の運用が難しすぎ、大半の企業では廃止されたようだ(今でもやっているのはIBMくらいか)。

マトリックス組織の問題は、誰でもすぐに気付くだろうけれども、上司が二人いることで指示命令系統に競合が発生してしまうことにある。提唱する人々が言うには、二人の上司がうまくコミニケーションを取り協力することでより組織が活性化するはずだ、ということらしいのだが楽天的すぎやしないだろうか。だいたい、上司同士がうまく協力できたとしても、部下からすれば両方の顔色を伺いながら作業をしなければならないのだから非効率の極みである。

とはいえ、ではなぜ、明らかに問題があるマトリックス組織を聡明なグローブが推奨するに至ったのか。不思議に思い、該当箇所を何度か読み返してみた。

ひとつ気付くのは、グローブは必ずしもマトリックス組織を「素晴らしいから導入すべき」と述べているわけではないということだ。むしろ、他の方法では対応できないからセカンド・ベストとして導入するしかない、と書かれている。

なぜ他の方法ではダメなのか。その理由は職能別組織、事業分野別組織というふたつの組織形態は両方とも無くてはならないからだ。システム開発会社を例に考えてみよう。職能別組織の例は営業部、開発部などがそれにあたる。このような組織形態は、社内の人的リソースを職能に応じて特化して管理することで目標設定、評価、教育を効率化するために必要となる。一方で事業分野別組織の例は、プロジェクトと言い換えてもよいだろう。市場の要請、すなわち受注した案件の規模に応じて組織を柔軟に構成することが求められる。どちらの組織形態も重要であり、一方を切り捨てることはできない。

沼上幹組織戦略の考え方」でも触れられているように、職能別組織と事業分野別組織というのは不可分なものではなく、どの会社でも組み合わせた組織形態を取るのが一般的だ。職能別組織を基本としながら、その時々の状況に応じて事業分野の重要度に応じて組織を組み替えるということが行われている。

このとき、どこまで事業分野別組織の組み換えが必要なのかは、その企業が市場のニーズにどこまで迅速な対応を求められるか、によることになる。グローブはインテルでの経験から組織構造が市場ニーズに柔軟に対応できることを目指したということなのだろう。

ここでふと、最近の業績評価の流れとこの議論が関係していることに気がついた。近年、アドビやマイクロソフトなど業績評価そのものをやめ個人への頻繁なフィードバックに変える企業が増えている。Googleのように採用や昇進・昇給を従来の管理職から取り上げ、独立させている企業もある。もしかすると、このような流れは、市場のニーズに沿って事業分野別の組織形態の自由度を高くする(すなわち組織=プロジェクト)ために、職能別組織を解体しようとする動きなのかもしれない。

社内の要請と市場の要請では後者の方が重要なのは自明だろう。市場の要請に応えるための組織はどのような形態を取るべきか。なかなか面白い論点のように思える。


【2017/05/05 追記】

「How google works」で著者らは、組織は独立採算制にせず、機能別組織(この記事で言う職能別組織)にすべだと主張している。その理由として特定のプロダクトで組織化すると、自分の事業部のことだけしか考えなくなり、情報や人々の流れが阻害されることをあげている。

ただし、これは組織化することに共通するデメリットではないかと思う。営業機能を分割することで、技術者は営業のことを考えなくなるし、その逆も同じだろう。いずれにせよデメリットを理解した上で、組織構造は検討する必要があるということではある。

*1:上司と部下の一対一面談を頻繁に行う手法。