@sunaot です。前に一緒に働いていた同僚からこんな質問が来ました。
組織が肥大化しすぎてアレコレうまく行かない事が増えてきたので『ユニコーン企業のひみつ』を読みました。 他にも他社の事例とかも見ていたりするのですが組織の布陣とか参考になるおすすめの書籍などありますか？
今はマネージャーをやっていて組織の設計に困っているようです。回答をするために考えてみたのですが、開発組織の組織デザインをピンポイントで語った本というのがありません。『ユニコーン企業のひみつ』は Web のサービス会社のチーム開発について語った良い本なのですが、組織論ではないためほしいところとやや違ってきそうです*1。
そこで、同じような悩みを抱えている人に向けてサービス会社の開発組織の組織デザインについて、実際に6年以上試行錯誤してきた立場から考えるべき観点というのをまとめてみようと思います。
結論から言ってしまうと、開発組織ゆえの特殊性というのはあまりありません。考えるときの原則を書くとすると、開発組織でなくても同じ内容になりそうなとても普遍的な内容になります。つまり、
「マネジメントの意思として取り組みたいテーマに対して、その実行とモニタリングに適した組織形態をとり、複数のテーマの兼ね合いの中で出るトレードオフに対して、総合的に一番やりやすい形をとっておく。不都合があればチューニングする」
という基本のところに落ち着きます。ただ、その中で「プロダクトの単位で同じ目的や目標を追って一丸になって動けること」はテーマに負けないくらい重要な視点になってくるので、かなり力強い制約として考える必要があります。
以降はこの説明をもう少し解像度を上げて説明していきます。重要になってくる点は、「使命中心編成と機能別編成の組織」「マネジメントの意思の視点」「フェアプロセスと3つの要素」です。
HIGH OUTPUT MANAGEMENT の使命中心編成と機能別編成の組織
一つのヒントとなるのはアンディ・グローブによる著書『HIGH OUTPUT MANAGEMENT*2』に載っている使命中心編成の組織と機能別編成の組織です。
使命中心型の編成だと、事業の単位で組織を編成しそれぞれの単位のやるべきことにフォーカスして働きます。事業が必要とする機能は一通りその組織に所属して、同じ目標（やるべきこと）を目指して動くようになります。たとえば、製品開発やセールス、マーケティング、購買のような機能をすべて持つ形です。この形態を選択する場合、全員が事業の顧客や目標に対して働くことになるので、市場への即応性が高まります。
続いて、機能別の編成だと、使命中心型とは反対に機能の効率性に注目して組織を編成します。製品開発やセールス、マーケティングといった仕事の機能を組織単位として、関わるそれぞれの事業に対して責任を持ちます。規模の経済による効率性や専門性の横展開といった点では機能別組織を志向するメリットがあります。一方、事業のやるべきことに対して当事者としてのスタンスが弱まりやすいのがデメリットです。書籍では使命中心型の組織の持つ即応性の特徴に対して、機能別組織にはテコ作用が得られるという特徴があると書いています。
『HIGH OUTPUT MANAGEMENT』ではこの2つの組織モデルに対して、両者を組み合わせ、フロントに立って市場に向き合う使命中心の組織とそれをバックアップする機能別組織を混合したハイブリッド組織という編成について解説し、「共通の事業目的を持つすべての大組織は、最後にはハイブリッド組織形態に落ち着くことになる」という「グローブの法則」を提唱しています。
書籍ではハイブリッド組織を運営していく場合の長所、短所とその中での注意点についてかなり詳細な説明*3があるので、より詳しい内容を知りたい方は書籍を読むことをおすすめします。*4
マネジメントの意思のレイヤー
使命中心編成と機能別編成の組織のメリット・デメリットはある程度『HIGH OUTPUT MANAGEMENT』に倣うとしたときに、もう一つ開発組織を考えるときに重要なポイントがあります。それが、チームを主役に据えたときの製品開発の組織レイヤーと、マネージャーによるマネジメント意思、マネジメント範囲の視点で見たときの組織レイヤーです。
一つにはこれを一致させて、日常はすべて製品開発を軸とした組織レイヤーで済むような組織デザインがあります。Spotify Rhythm や Alignment at Scale を見ると、日常の製品開発の中である種のマネジメントの意思というのが紡がれ繋げられている様子が読み取れます。
一方でまさにこういった組織デザインの話などもそのカテゴリに入ってきますが、使命中心組織のレイヤーでは拾いきれない (そして、トライブでもチャプターでもギルドでも拾えない *5 )、組織に対してのマネジメントのレイヤーというのが欲しくなることがあります。機能別編成の組織の観点で出てくることもあるかもしれませんが、それだけとも限りません。従来のピラミッド型組織であればラインのトップダウンでつなげていくことができるマネジメントの意思ですが、使命中心編成と機能別編成のハイブリッド型の組織形態や、ユニコーン企業のひみつで語られるような使命中心編成を中心にしながら機能の要素をオーバーラップさせていくような組織形態をとっている場合、不都合が生じるときがあります。
不都合があっても必要なことは実行していかねばならないので、それは別のレイヤーとして描いている組織図に対してオーバーラップさせていくというのが現実解になります (チャプターやギルドといった仕組みも、スクワッド＋トライブという土台となる使命中心編成の姿に、別の意思としてかぶせているレイヤーという見方もできます)。
チームが主役で中心だと言いながら、少し軸が別の活動をかぶせていくということで、巻き込みや納得、関係性や位置づけがやや複雑で難易度が髙いものになってきます。そのため、単純なピラミッド型組織でのマネジメントの意思の浸透とは違う性質の問題を解くことになります。
製品開発をしていく開発組織にとって、使命中心編成をベースにして機能別組織を組み合わせたり、チャプターやギルドを組み合わせていくスタイルはミッションを共有し、同じ目標を追いかけるための姿として自然なものです。
そこで、自然なものに対してオーバーラップしてくる自然ならざるマネジメントの意思というのは、ただ「ユーザーに良いものを届けて、価値を提供し、ビジネスの成長へ貢献しよう」という題目よりも扱いが難しく、それゆえに伝え方、進め方に注意が必要だと言えます。
最後に、このチームを中心とした組織に対してオーバーラップしてマネジメントの意思を注入していくときに必要な態度のヒントになるフェア・プロセスというものについて説明をしてこの文章を終わりにします。
フェア・プロセスと3つの要素
フェア・プロセスは『ブルーオーシャン戦略』で有名なチャン・キム、レネ・モボルニュの二人の教授が発表した論文に載っているコンセプトです。また、ブルーオーシャン戦略の実践プロセスの一部としても言及されています。
フェア・プロセスは、人間の基本的欲求に訴えるものだ。だれもが、組織のなかでの役割が何であれ、一個人として評価されたいと思い、「人員」「人的資産」などと評価されたくはない。だれもが、自分の知性を尊重してもらいたい。自分のアイデアを真摯に検討してもらいたい。そして、それぞれの意思決定が合理的である理由を理解したい。
HBR 2008年8月号『フェア・プロセス：協力と信頼の源泉』（再掲論文。初出は January 2003 “Fair Process: Managing in the Knowledge Economy by W. Chan Kim and Renee Mauborgne”）
フェア・プロセスというのは七〇年代半ばから研究がされてきた結果に至るまでの公正なプロセスのことです。
人は、結果にもこだわるが、それに至るまでのプロセスにもこだわる。 つまり、その結果がいかに満足できるものでも、そのプロセスが不条理で、 公正さに欠けるものであれば、不信感を抱き、やる気を失う。 逆に、プロセスが公正で納得できるものであれば、意に沿わない結果でも甘受する。 このような「フェア・プロセス」の重要性は、ますます高まっている。 人々の協力と信頼関係こそ、組織能力やイノベーションの源泉だからである。
論文の中ではフェア・プロセスを実現するための三原則というのが挙げられています。
- エンゲージメント
- 説明
- 具体的な期待
それぞれを順に説明します。
エンゲージメント
社員たちに影響が及ぶ意思決定について、彼ら彼女を巻き込み、意見を求め、それをアイデアや仮説を交換し合うことである。このことは、社員一人ひとりの存在について、またそれぞれのアイデアを尊重するという意思表示といえる。
これはわかりやすいでしょう。全員に等しく意見を言う機会があるということです。ただ、全員の意見を聞くべきという話とは違います。現実問題、時間や物理的制約があるのですべての人から意見を集めるというのは不可能です。それでも、過程で意見を言う機会というのはあり、出した意見は誰が言ったかによらず等しく検討されるチャンスがあるという点が重要だというのがこの原則です。
説明
社員たちが、なぜこのような意思決定に至ったのか、その理由を理解することである。すなわち、意思決定の根底にある考え方を説明することは、社員たちの意見を考慮し、全社の利益から考えて、そのような意思決定を下したことを、社員たちに納得させることである。
「納得させることである」と言われてしまうと、あまり好みではなく「おう、そうか」という気持ちになってしまいますが、その手前の「意思決定の根底にある考え方を説明することは、社員たちの意見を考慮し、全社の利益から考えて、そのような意思決定を下した」という部分はエンゲージメントからの流れとして、このように全員の理解をそろえていく努力をするプロセスとして非常に重要と感じます。
現代的にいうと、これは透明性の話でもあります。ただやはり意思決定をした当事者がそのロジックを説明するという意味で、説明こそ重要であるというのは、今回読み返しながらあらためて身にしみるものがあります。
具体的な期待
いったん意思決定を下したならば、ゲームの新しいルールを明らかにしなければならない。期待は上から寄せられるものだが、その際、どのような基準で評価し、失敗にはどのような罰が待っているのかについて、社員たちに知らせる必要がある。 フェア・プロセスにおいては、新しいルールや方針が何かよりも、新しい目的やその中間目標は何か。だれが何に責任を負うのかを理解されることがよほど重要である。
「失敗にはどのような罰が」というよりも、現代では失敗は学習の機会であり、罰は待っていないということについて知らせる必要と読み替える必要はありそうですが、主旨としては意思決定の結果がアクションへつながるように組織の期待 (ミッション・目標) を書き換えるということです。意思決定の結果、自分たちへの期待がどう変わったのかまで説明がされて、初めてその意味が理解されます。
フェア・プロセスが全員合意の合意形成プロセスではなく、リーダーシップの発揮をしていくために、優れたアイデアをすべてのアイデアから見つけ出そうという過程であり、そこからの実行のためのプロセスであるという点は最後に強調をしておきたいところです。
おわりに
さて、こうやって書いてきてしまうとさもうちの会社はこういった組織デザインの原則に従い大変うまく運営されているかのように見えてしまうと思います。実際のところはまったくそんなことはなく、こうして理屈はわかっているにも関わらず組織は生き物で基本的なことを一つ徹底するだけでも本当に難しいと感じているのが正直なところです。
とくに個人的な課題としては、フェアプロセスのうちの「説明」や「具体的な期待」のあたりは組織のスケールで実践するには個人の技能というのでは不十分で、組織での実践のための仕組みというのが必要だと感じ、現在の開発組織としても課題意識があります。
それでも自分もふくめて働く人が気持ちよく働き、自分の能力を発揮して充実して働ける組織にしていきたいと思いながら日々やっているので、一緒に組織づくりをしていってくれるエンジニアリングマネージャーの方やマネージャーではなくともそういった組織に共感して働いていってくれる方を募集しています。
*1:参考になるような要素は多々書かれています。
*2:インテルの元 CEO アンディ・グローブによるマネジメントの実践書です。論理的な思考がエンジニアにとっても親しみやすい内容で、開発会社でマネージャーの役割をする人にとっては必読の内容と言っていいと思います。
*3:非常に有用な議論がされていますが、2点だけ気になる部分があるのでコメントしておきます。
一つは機能組織を規模の経済の視点で社内下請けと評した点。これはバックアップの役割と明確なラインを引くことでわかりやすさを上げる効果があると思いますが、この定義にしてしまうことで機能組織の限界を決め、目的を狭くし、より市場への即応性が落ちるコンセプトだと感じます。自分であれば、仮に機能組織のマネージャーの立場をとるにしても、そのコンセプトの中で市場へ近い形の組織役割を置くだろうと感じました。
気になる箇所の2点目は、リソース最適化の視点が強い点。これも機能組織の規模の経済と集約による最適化のメリットをとろうとしているためだというのはわかるのですが、組織の成果を付加価値よりも費用効率へ向かわせやすいなと感じました。自分がやるのであればテコ作用のほうへより多く注目して、そちらを軸にして組織のコンセプトを考えると思います。
*4:さらに言えば、どの組織形態をとるのであれ、その上で組織が提供するべき機能（採用、育成、評価、リーダーシップ・パイプライン、キャリア開発など）を誰がどのような役割で提供していくのかを設計する必要があります。組織ではなく個人のほうを起点としたときに、その人がどの形の組織へ所属していても組織からのバックアップを受けられているようにしていくことが必要です。
*5:トライブやチャプター、ギルドといった用語については『ユニコーン企業のひみつ』に書かれているので気になる方は参照してください。
