はじめに
昨今、エンジニアリングやプロダクトチームにおける組織論の書籍や記事は数多く世に出ており、私も大変参考にしております。
これらを読み進める中で、組織論で重要なトピックである「分業」について、より理解すべきと痛感することがあり、私なりに調べたり、整理した内容を記事として書いていきたいと思います。
実は今年3月に、私が組織長を務める事業本部(主にエンジニアやデザイナーが所属)で大きな組織再編をしたのですが、そこでも分業についての理解が、組織構造を検討するうえで非常に役に立ちました。
今回の記事では、「組織デザイン」を読んで、図や考え方を参考にしています。昨今の議論からすると、やや古典的に感じられる方もいるかもしれませんし、書籍では製造業を前提としている部分が多く、IT/Web業にそのまま適用できない部分もあります。
ただ、後述するように組織と分業は切っても切れない関係にあるので、どのような分業パターンが存在し、それぞれにどういった特徴があるのかを述べていきたいと思います。
そもそも組織とは？
そもそも「組織」とは何でしょうか?
Wikipediaでは組織の特徴を下記のような定義が記載されています。
共通の目標
「成員間で共有される共通目標が存在する」ことが、組織を定義づける要素の1つである[4]。共通の目標がなければ、同じ時刻・同じ場所に居て同じ行動をとる人々の集まり（例えば劇場に集う観客など）も、組織とは言わない。分業と調整のメカニズム
組織には、複数人で共通の目標を達成するにあたって必要な組織全体の仕事やタスクの分業と調整を行うメカニズムが必要である。共通の目標が人々によって共有されていても、個々人が個別的に仕事を遂行するならば、それは組織とは言わない。
「個々人が個別的に仕事を遂行するならば、それは組織とは言わない。」と記載の通り、企業の組織においては、何らかの形で仕事が分化（分業）され、それらを統制/調整する機構が存在します。
以下で、どのような分業パターンが存在するかを述べていきます。
4つの分業パターン
分業には様々なパターンが考えられますが、大まかに足し算的発想の加算的集計と、掛け算的発想の機能的統合に分けることができます。さらに、分業された仕事のアウトプット/インプットをどう繋げるかという観点から直列型・並列型も考えられ、これらを考慮すると下図で分業パターンを整理することができます。
(「組織デザイン」図2-3を参考に筆者が作成)
本記事では、国内のIT/Web企業でよく見られる
- 並行分業 (上図の左下)
- 機能別分業 (上図の右側)
について解説していきます。
並行分業と機能別分業
並行分業と機能別分業の概要について解説します。
例として、パンを製造・販売する企業があったとして、「食パンAの製造/販売」、「食パンBの製造/販売」、...といった具合に、同一あるいは類似の作業を分散し、量的な分担を行うのが並行分業です。
この分業パターンを企業全体に実装した組織構造が「事業部制組織」といえるでしょう。
一方で、こねる/成形する/焼く、といった工程で分業していくのが機能別分業です。
企業全体では「機能別(職能制)組織」として実現されることが多いです。
以下で、並行分業と機能別分業のメリット/デメリットを述べていきます。
「機能別分業」について
機能別分業は、異なる役割や職能で分業するパターンです。
例えば、ウォーターフォール型開発のように「要件定義」→「設計」→「実装」→...と作業を直列に結んで分業するパターンもありますし、「フロントエンドチーム」「バックエンドチーム」...というように職能別に並列で分業するパターンもあります。
(直列型)
(並列型)
機能別分業には様々なメリット/デメリットがありますが、特にIT/Web業界に関連あるものをピックアップして述べていきます。
「機能別分業」のメリット
経済的スタッフィングが実現しやすい
各人が自身のできることに専念しトータルの人件費を抑えることが、経済的スタッフィングです。
例えば、高い技術やノウハウをもつエンジニアに、単体テストの結果(スクリーンショット)をExcelに貼り付けるような作業を行わせるのは、直感的に合理的でないと感じられると思います。
高い技術力をもつ技術者は一般的に高い賃金を受け取っていますので、誰でもできるタスクはより低賃金の別の人に依頼することで、トータルの人件費を抑えることができます。機能別分業は、経済的スタッフィングを実現しやすい分業パターンといえるでしょう。
スキルの習熟が効率化され、専門性が強化されやすい
機能別分業は、特定の業務や技術に特化した人員配置を行います。これを個人からみると、特定の技術を短期間で習得することができたり、より専門性を強化することに繋がります。
例えば、バックエンドチームに所属していれば、当然バックエンドに関連するタスクが集中的にアサインされ、短期間で関連する技術やスキルを獲得し、より専門性を高められることができます。
「機能別分業」のデメリット
リーダーやマネージャーの負担が増える
事業は、最終的に顧客に製品やサービスを提供することを目的としていますが、機能別分業では最終的な成果物まで責任を負いません。つまり、分業されたそれぞれのチームのリーダーやマネージャーは、他のチームと調整する必要が出てきます。
例えば、「モバイルアプリチーム」が新しい機能を実装するときに、「バックエンドチーム」に新たなAPIエンドポイントの作成を依頼したり、「インフラチーム」にサーバー設定の調整をお願いしたり...といった調整業務が考えられますね。
事業規模が大きくなってくると、調整すべき項目や相手が増えることで現場管理者であるリーダーやマネージャーの負担が著しく増加します。
「なぜやるのか？」モチベーションの低下
仕事が高度に分業されると、作業者は最終的なアウトプットをみる機会が少なくなるため、自分のタスクの意味や目的がわからなくなります。自分たちの製品やサービスがどのように使われているかわからない、お客さんが見えない、といった状況に置かれ、ただ漫然と作業を行うだけとなってしまいがちです。
製品やサービスに対する責任が曖昧になりがち
機能別分業では各々のチームが最終的な製品やサービスに対する責任を持たない場合が多いため、責任が曖昧になりがちです。例えば、バグや障害/故障といった品質責任が曖昧になったり、製品・サービスごとの採算が不透明になりがちです。
「並行分業」について
並行分業は、それぞれの仕事が独立しており、他のチームのアウトプットに依存することなく、自チームが成果を上げることができます。例えば、「メディア系プロダクト」「SNS系プロダクト」...という提供するサービスごとに分ける場合やtoCやtoBというように提供相手ごとに分ける場合も考えられます。
基本的には、機能別分業のメリット/デメリットが逆に現れる形になりますが、特筆すべき点を下記で述べていきます。
「並行分業」のメリット
変化への適応
業界や市場の不確実性が高い場合に、自社の製品・サービスもそれに適合させていく必要があります。並行分業は、基本的には必要な作業はチーム内で完結できるため、少ない調整回数で素早く変化に適応することができます。
1つのチームが全体に与える影響が少ない
並行分業は、仮にあるチームのアウトプットが滞ったとしても、全体のアウトプットが量的に減るだけで、組織全体の活動がストップしてしまったり、全体の業務フローが壊滅してしまうということは起こり得ません。
（一方で、機能別分業では一部の分業されたタスクが滞ると全体がストップしてしまうため、組織的な脆弱性に繋がります。）
事業ドメインに対する知識や経験を蓄積しやすい
並行分業では、作業者が最終的な成果物であったり、それに近しい部分まで責任を持つことが多くなります。これによって、自社の製品・サービスの知識や事業に関連する経験を得る機会が増え、蓄積しやすくなります。
例えば、EC系サービスにチームメンバーとして携わっているのであれば、決済や配送の業務知識や関連する法令(特定商取引法など)を知る機会が多くなり、またECサイトで起きがちなトラブルにもよく遭遇し、事業ドメインに特化した知識・経験を蓄積していくことになります。
「並行分業」のデメリット
基本的には、機能別分業のメリットの逆になりますが、下記のみ解説します。
チーム間の協力関係が欠如しやすい
並行分業では、分業しているチーム間で同じ基準で比較できる（例：サービスごとの売上やPV数など）ため、良くも悪くも競争心を持つことになります。
それ故に、分業された各チームが協調せずに、業務を進めてしまうことが起こりやすいです。気づいたらチームAとチームBで同じことをやっていた、ということはよくある話ですね。
最後に
今回の記事では、分業のパターンやIT/Web業界においてよく見られる「並行分業」と「機能別分業」のメリット/デメリットについて解説しました。
ここまでで疑問になると思われるのが、どのように分業パターンを選ぶか？ということです。その答えの１つで、特に重視すべきなのが、その分業パターンが 「競争上の武器になるか？」 という点です。逆をいえば、組織図を見るとその組織が何を競争上重視しているかがわかります。
例えば、卓越したAI技術やWeb技術のそれぞれの技術力を市場競争における武器にしていくとすれば、「機能別分業」を選ぶのが望ましいですし、逆に、事業ドメインに精通していることを武器にしていくとすれば、「並行分業」のほうが向いているかもしれません。これについては、いずれ別の記事で詳細を書きたいと思います。
この記事が、組織やマネジメントにおける新たな洞察や発見に繋がりましたら幸いです。