'組織デザイン' を読んだ
組織デザイン という本を SNS などで何人かが読んでいたので気になって手に取ってみた。
全体通しての感想
今までの EM などの実務を通して断片的に感じてきた事が改めて整理されていた。
また、それについて新しい角度で書かれていたりなど発見がいくつかあった。
特にソフトウェアエンジニアリングに特化した本ではないものの、共通する事がたくさんあるということに気づけた。
読書メモ
(メモの見出しと添字は適当に付けていて書籍とは関連無いです)
1. 調整と分業について
役割を分化させることを分業と呼び、それらの多様な役割の時間的・空間的連動を確保する努力のことを調整と呼ぶ p.14
どのような組織であろうと、合理的に運営されようと意図されているのであれば、これら二つの要素を備えようと努力しようとしているはずである p.17
分業を行うメリットについて書かれていて、主に以下の2つがあった。
- 各タスクを完了させるためのパラメータがそれぞれにあるとして、全てを満たす人材はほとんどいない。いても賃金が高い
- それぞれ1つのパラメータを満たす人材であれば現実的、かつ賃金も前者に比べて安い。なのでスケールアウトが現実的
これが「組織」を形成するモチベーションの元なんじゃないかなと感じた。
これを考えついたのはコンピュータの父とも呼ばれるチャールズ・バベッジというのも面白かった。
アルゴリズムでも分割統治法という考え方があるので、似たような発想なのかなと思った。
2. プロフェッショナルについて
プロフェッショナルや熟練工を活用することでもたらされるマイナスもある。基本的にはプロフェッショナルの雇用は重要な競争源とはなりにくいという問題と、かえってプロフェッショナルと他の人々との間の統合・調整が難しくなる p.116
直感とは真逆で意外な視点だった、少しソフトウェア産業とは違う視点かもしれないと思った。
その一方で、スケールアウトや仕組み化・標準化しづらいという点から考えると理解しやすいかもと感じた。
そしてプロフェッショナルは自分の所属する組織よりも、自分の専門領域やそのコミュニティに対して忠誠心を持つので他の組織に移籍しやすいという点もあり納得感があった。
余談だけど、産業革命時にイギリスの熟練工のせいで工業化が遅れ、一方歴史の浅いアメリカは熟練工がいないので自動化に頼らざるを得ず、一気にライジングしたのと似てるのかなと思った。
3. ヒエラルキーを使った管理について
ヒエラルキーには「上司による部下の支配」といったマイナスのイメージがつきまとうこともあるが、例外に対する対応に関していえば、辿るべきコミュニケーションの経路が固定されているだけで対応の内容は幅広く選択可能であるため、本来、ある程度の柔軟性を備えた調整メカニズムだと評価されるべき p.167
｀調整に際して発生する例外に対しての処理機` という言語化に、改めて管理者の役割を再認識できた。
そしてそのためにある程度の Slack が必要で、それが調整弁として機能する。
調整にも予め可能なものとできないものがあって、前者に関しては標準化などで可能。
ただ、後者は監督者による例外処理などで対応するしかない。
管理者は例外処理の catch の方。
「なるほど、フラットな組織を設計したい場合には管理の幅を広くとれば良い」と考える人がいるかもしれないが、物事はそれほど簡単ではない。p.174
よくある 2-pizza rule や span of control などのマネジメントできる限界数の話がいくつかの指標で納得感ある説明がされていた。
例外の数が多い、例外の分析が難しい、例外の処理にかけられる時間が少ない、などのいくつかの制約条件があってその定数（人数）が決まってくるんだなと思った。
自分が忌み嫌っているタイプの秩序の下でやる気をみなぎらせられる人間は、滅多にいないだろう。だから本当はヒエラルキーの特徴そのものに問題があるわけではなくても、ヒエラルキーをみんなが嫌ってるが故に、みんなのモチベーションが低下し、ヒエラルキーのパフォーマンスが悪くなる可能性がある p.216
ヒエラルキーという言葉や概念自体が影響しているという話、トートロジーぽくて面白かった。
確かに例外処理の機構やコミュニケーションパスの固定化などメリットの方が多い気もするのに、なぜか嫌われていると感じるのはそういった背景もあるのかもしれない。
「スラック」とは「ゆるみ」とか「たるみ」のことである。組織ユニット同士が緊密に結びつけられているよりも、若干「ゆるみ」が設けられている方が、調整の仕事は楽になる。 p.223
An Elegant Puzzle: 2 Organizations のメモ でも似たような Slack についての話があった。
調整の観点でもこれがないと、ユニット間でドミノ倒しのように調整が起きてしまうので大事。
例では Slack を持たせる対象として時間だけではなく、納期目標や工程間在庫が上がっていてなるほどと思った。
また事業部組織と機能別組織という観点で、前者は後者に対してslackを持った組織形成という視点があって、これまたなるほどだった。
事業部長や管理部門などが事業部毎につくことになるので余計なコストを使って Slack を持っている。
4. マトリクス型組織の Cons
同等のパワーを持つ二人のボスという設定は、命令の優先度がフォーマルに確定せず、それ故にこそ部下が誰の命令を聞いているかが、部下たちの感情をストレートに表出しすぎることになり、組織内で嫉妬に基づく対立が多発する種をまいてしまうことになるp.278
筆者としても長期的にうまく動いている例を知らないのは意外だった。もちろん歴史が浅いのが関連しているとは思う。
とはいえ、管理者が増えレポートラインが複雑になったりするのは間違いないので、設計はしっかりしないといけないのは間違いないぽい。
5. 「組織が重い、遅い」の意味
「組織が重い」とか「組織が遅い」という問題に直面している場合、その原因はヒエラルキーそのものにあるというよりも、むしろ「決めるべき上司が決めてくれない」ということにあることが多い p.292
これは本当にその通り。
過去に経験した良い組織やリーダーは、決めるべきことをしっかり責任を持って決めていた。
誰が何を決めるのかそもそも誰も分からない、みたいなのもあると思っていて、それは設計の問題なので設計をしっかりするべき。