はじめに

こんにちは、クラシル開発チームでエンジニアリングマネージャーをしているtakaoです。この記事を書いているタイミングは4月なのですが、ちょうどクラシルの開発チームでは年度の変わり目ということもあり組織体制のアップデートをしたタイミングでした。私自身はマネジメント経験が特に長いわけでもなく組織全体のマネジメントをするようになってからは日も浅いのですが、プロダクト開発をするチームにとってどのように組織をデザインするかというのは重要な課題の一つだと感じています。今回はその過程で情報を整理していくにあたり役に立った考え方や実際に組織体制を考える際に考慮したポイントなどについてご紹介します。

組織形態のパターン

組織形態には基本型と呼ばれている3つのタイプが存在しています。本来これらのパターンは開発組織というよりは一つの会社の括りで見たときの設計パターンを指すことが多いのですが、大小あれど開発組織も「組織」に変わりないので、開発組織を考える際にも同じ考え方が役に立つと思い参考にしています。

機能別（職能別）組織

機能別組織は一つの開発組織に当てはめるとフロントエンド、バックエンド、インフラなど業務内容の意味での機能（職種）で分けたパターンのことです。基本的に同じ職種のメンバーが同じチームに属しており、レポートラインの上長なども同じ職種の人を想定します。この設計をした場合のメリットとしては各チームが専門性を高めやすくなり、効率的な業務遂行が可能になると思います。一方デメリットとしては、部門間のコミュニケーションや連携が不足しがちになり、開発全体のスピードが落ちてしまったり、余計な手戻りが発生しやすくなるリスクが大きくなります。また、事業会社の場合はこの体制に寄せ過ぎると社内受託感が強くなってしまう可能性もあります。

事業部制組織

事業部制は一般的には会社の事業（製品など）ごとに組織を分割するような形態を表しています。一方プロダクト開発組織に当てはめてみると、大きい組織の場合は各プロダクトごと、小さい組織の場合は一つのプロジェクトやドメイン、機能単位などで分けるようなパターンに該当すると思います。このパターンの場合は、一つのチームに複数の職種のエンジニアやデザイナーが存在している点が特徴です。メリットとしては各エンジニアやデザイナーが担当する領域やドメインに詳しくなるため、コミュニケーションコストが低く議論や意思決定のスピードが早くなることが多いです。また、要件定義の段階から各職種のメンバーで議論が進められるので手戻りが少なかったり懸念の洗い出しなども容易になることが予測されます。一方でデメリットとしては横の連携をうまくしないと独立したそれぞれのチームで同じ課題に取り組んでしまったり、各チームが独自の方針や戦略を持つことで組織全体の一貫性が欠けてしまうことが考えられます。

マトリクス組織

マトリクス型の組織は、機能別組織と事業部制組織を組み合わせたもので、一人のメンバーが複数のチームに所属するパターンです。これにより、機能別組織の専門性の高さと、事業部制組織の柔軟性やチーム間の連携を同時に享受できることが特徴です。マトリクス組織のメリットとして、リソースの最適化が図れることが挙げられます。各プロジェクトで必要とされるスキルセットや専門性が変わるため、メンバーが複数のチームに所属することで適切なリソースを割り振ることができます。また、組織全体での知識共有が容易になり、組織の柔軟性が向上します。一方でデメリットも存在します。上長に当たる存在が複数になるため、指揮命令が複雑になりメンバーが適切な優先順位を判断しづらくなることがあります。また、メンバーが複数のチームに所属するため、スケジュール管理やタスクの調整が困難になることがあります。これにより、効率が低下するリスクが生じます。

実際に組織形態・チーム体制を検討したときのポイント

では実際に開発チームの組織形態・チーム体制を考える際にどのようなことを考えたり議論したりしているかという点ですが、個人的には以下のようなポイントを考慮して適切な形を設計するように意識しています。

事業・組織の規模

事業のサイズやフェーズを考慮します。初期段階（0→1）であればスピードが重要で、成長段階（1→10）ではスケーリングと効率化が求められ、安定期（10→100）では最適化やイノベーションが重要になるなどがあると思います。
組織の人数や各職種の人数も考慮に入れて、適切な組織構造を選びます。小規模ならばフラットな組織が適していることが多く、大規模になると権限移譲が必要になるので階層型の組織が適切になることが多いです。

チームの専門性とスキルセット

チームメンバーが特定の領域に特化しているか、幅広いスキルを持っているかも重要です。特化型の場合は機能別組織が適していることが多く、幅広いスキルを持つ場合はプロジェクト型組織が適していることが多いでしょう。

組織として何を重要視しているか

組織のミッションやビジョンに基づいて、組織形態を選択しています。例えば、開発スピードや自律性を重視する場合はアジャイルな組織が適していることがありますし、効率性や組織自体のスケーラビリティを重視する場合は階層構造が必要になってきます。

チームとしての機動性

コミュニケーションの複雑性を考慮します。例えば、連携が必要なメンバーがいろいろなチームに散らばったりすると会議が多くなり効率が落ちるため、適度なコミュニケーションができる組織が望ましいです。
また、delyでは組織のグローバル化を行っており、チームによっては英語を使う機会も発生するのでその点も考慮すべき点になります。
組織の変更を行ったときに、どういう役割とどういうコミュニケーションが必要になるか予測を立てるのが良いと思います。
1チームの人数は、多くても8人までの範囲になるようにします。これにより、チーム内のコミュニケーションが円滑に行われ、効率的な意思決定が可能になります。

成長とキャリアパス（目標設定、評価）

適切な目標設定・評価がしやすいレポートラインになっているかも重要視しています。ここを考慮することで、社適切な評価やキャリアアップの機会を提供できると考えています。
成長やキャリアアップのための支援やフィードバック、マネジメントができる体制になっているかを確認します。

おわりに

組織形態やチーム体制の選択は、その組織の事業規模や目的、チームの専門性、スキルセット、機動性、成長やキャリアパスなど様々な要素を考慮して慎重に行われるべきだと考えています。機能別（職能別）組織、事業部制組織、マトリクス組織という３つの基本的な組織形態がありますが、それぞれにメリットとデメリットが存在します。

そんな中でどの組織形態を選択するかは、組織の目的やニーズに応じて決定することが重要です。また、組織形態だけでなく、適切な目標設定や評価、成長支援などのマネジメント体制も整えることで、より効果的な組織運営が可能になるでしょう。

クラシルの開発チームでは共に組織・プロダクトの成長を描いていける仲間を募集しています！特にSREのポジションを積極採用中ですので、興味がある方は以下のリンクをご覧いただければ幸いです！ careers.dely.jp