組織のフェーズに合わせてマネジメントも進化する、サイボウズが実践する3階層5分類のマネジメント設計

日本企業においては、9割の管理職がプレイングマネジャーといわれる時代。マネジャーの役割や在り方についてあらためて問い直す動きが広がっています。

本シリーズ（望ましい管理職の姿とは？プレイングとマネジメントのバランスを再考する）の第3回では、企業の実践事例として、独自の組織づくりで知られるサイボウズ株式会社を取材しました。同社は2019年に開発本部でマネジャー職を廃止し、2022年に復活。さらに2025年の「組織づくりアップデートプロジェクト」で、ラインマネジメントの役割が「理想／業務／組織／人材／投資」の5軸に整理されました。

お話を伺ったのは、開発本部長の佐藤鉄平さんと、人事本部マネジメントデザインチームでマネジャーを務める匠史朗さん。マネジャー職の廃止と復活の経緯、5軸整理の意図、そしてAI時代を見据えた今後の展望まで、実践のなかで見えてきた示唆をお聞かせいただきました。

職能部を廃止し、プロダクトチームに一本化

Q：2019年に開発本部でマネジャー職がを廃止された背景と、その判断に至るまでの経緯について教えてください。

佐藤：当時の開発本部は、いわゆるマトリックス組織の構造でした。開発本部のなかに、エンジニアの部やデザイナーの部といった職能ごとの部があり、それを横のラインとすると、縦のラインとしてプロダクトのラインがありました。

たとえばkintone（キントーン:業務改善プラットフォーム）のラインやGaroon（ガルーン: 中堅・大規模組織向け）のラインといったように、それぞれのラインにはプロダクトマネジャーがいて、そのなかで職能の部から、エンジニアが何名、デザイナーが何名といった形でアサインされる。横に職能部と縦にプロダクトラインがある、いわゆる典型的なマトリックス組織という構造でした。ただ、（縦ラインと横ラインがある）”マトリックス”といっても、実際の縦横のバランスは企業ごとに異なります。

当時の当社の課題認識としては、横の職能部のバランスが強めだったのです。職能ごとに境界があって、プロダクトチームとして一体になり、プロダクトや事業としての成果をより高めていこうというモチベーションよりも、それをこなすための各職能部門としての動きの要素が強くなっていた。よりプロダクトや事業を伸ばしていくという側面を強めたい、というのが背景にありました。

 そこで、その職能部そのものをなくして、縦のプロダクトのチームだけを残しました。これが2019年当時にやったことです。当社のブログでは、少しキャッチーに「マネジャーをなくしました」と表現しているのですが、そこで言っているマネジャーというのは、横の職能部のマネジャーをなくしたということが実態です。プロダクトのラインには、プロダクトを統括するプロダクトマネジャーがもともといて、その役割はなくしていません。

もっとも、こうした判断ができたのは、開発本部の組織構造にマッチしていた面があるからです 。開発本部は、1つの本部のなかに複数の職能のメンバーが在籍しており、プロダクト開発は、異なる職能のメンバーが1つのチームを構成して進める仕事です。いわゆるクロスファンクショナル（部門横断的）なチームを作ってプロダクトを推進していくタイプの仕事なので、開発本部のなかに複数の職能がありマトリックスになっていた背景は、営業職などとは状況が違いました。

 一方、営業職はメンバーが集まって営業活動を行うのが基本で、他部門との連携はあっても、職種内で完結する構造です。開発本部はこうしたビジネス系の部門とは状況が異なるため、よりクロスファンクショナルなチームというところに着目して、業務と成果を追求する単位としてより強固にしよう、というのが目的になりました。

マネジャー不在の約3年間で見えてきた課題

Q：マネジャー不在の約3年間で見えてきた組織運営上の示唆と課題、そして2022年にマネジャー職を復活させる際に「残した役割」と「手放した役割」について教えてください。

育成や評価は事業やプロダクトチームとより連動するのが望ましい

佐藤：実際に運用してみて、業務を進めるプロダクトチーム強化し、そのチームを中心にプロダクトや事業を推進していく方針自体は、当初の目的どおりに進められたと考えています。ただし、プロダクトの事業推進のラインでは、評価や育成、採用までは担っていませんでした。

職能のマネジャーを廃止した後は、組織運営チームを別に設け、少人数のマネジメントチームを構成して、そのチームが本部全体のピープルマネジメントも行う構造としていました。この体制の良かった点は、マネジャー自身がチームを構成することで、マネジメントチームとして連携が取れるようになったことです。少人数でノウハウが凝集しやすい面もありました。

ただ、問題点として、プロダクトのラインとの距離感が生じてしまいました。育成や評価は、事業やプロダクトチームとより連動した形で進めたい、完全に分離するのはうまくいかない部分もある、という課題が見えてきたのです。そこで、従来型と新しい形を組み合わせる方向に切り替えました。プロダクトのラインは維持したまま、そのなかに職能や組織、ピープルをマネジメントするマネジャーを配置していく形で、人材マネジャーを復活させていったのが、その後の流れです。

従来は完全にマトリックスで縦横があり、極端に言えばそれがバラバラだったことが問題点でした。それをいったん、チーム側や事業ラインに全部振ってしまい、その後、事業ラインのなかにもう1回職能のマネジャーを入れ込んでいって、そこが一体となり、連動して動けるようにしたのが、その後の流れです。

復活させなかったのは”勤務地”ごとのマネジメント

佐藤：一方で、手放した役割は、勤務地ごとのマネジメントです。組織変更の前後には、コロナ禍がありました。2019年の組織変更までは、一定程度リモートワークや地域分散での開発は実践していたものの、大部分の社員が出社するのが実際の働き方でした。当時の職能の部門は、正確には「職能と地域を掛け合わせた部門」で、東京開発部や松山開発部など、地域と職能の組み合わせによる部が存在していました。この部分は、職能とピープルマネジメントを再導入した際にも、復活させませんでした。

理由は、フルリモート化がすでに完了しており、プロダクトチームが職能や地域に縛られずに構成される状況が生まれていたからです。1つのチームのなかに、東京、大阪、福岡、松山と、異なる勤務地のメンバーが集まって働くのが当たり前になっていたため、地域と職能を掛け合わせた区分は、その時点で復活させる必要がなかったのです。もちろん、採用やイベントなど、対面の要素が求められる場面では、その都度、各拠点のメンバーに協力を依頼することもあります。ただ、日常のマネジメントに関しては、この体制は復活させませんでした。

現在は、地域に縛られず、必要な人材をアサインできる自由度を重視しています。地域ごとにチームを作ることには利点もありますが、当社の開発では、地域を超えてアサインできる自由度や柔軟性を優先しているという状況です。組織構造は、まずプロダクトのラインで大きく分かれ、たとえばプロダクト単位に区分されます。そのなかにさらにエンジニアリング部などが構成され、さらにサブチームが事業単位で分かれ、そのなかに職能のマネジャーが配置される、という形になっています。

サイボウズが掲げる「理想マネジメント」の意味

Q：2024年頃から取り組まれていた「組織づくりアップデートプロジェクト」において、ラインマネジメントの役割を「理想マネジメント／業務マネジメント／組織マネジメント／人材マネジメント／投資マネジメント」の5軸で言語化しました。この整理に至った背景と意図についてお聞かせください。

匠：このプロジェクトは、役割を言語化するところから始まりました。チーム内でラインマネジャーの役割を分解していった結果、この5つの分類にたどり着いたのです。もともと「人材マネジメント」や「業務マネジメント」という言葉は、社内でも一般的に使われていました。

そこを起点にしつつ、当社としてもっとも特徴的なのが「理想マネジメント」を置いている点だと考えています。マネジャーが方向性を示し、その理想にメンバーが共感して、ともに取り組んでいくのが、当社の仕事の進め方の中心にある考え方です。したがって、理想や方向性を作る役割は、マネジャーにとって不可欠だという判断で、「理想マネジメント」を組み入れました。

この「理想マネジメント」に沿って業務を進めるために「業務マネジメント」があり、そのために組織を構築する必要があるので「組織マネジメント」があり、組織を構成する人に関わる部分として「人材マネジメント」があり、これらを総合的に推進するために「投資マネジメント」が必要になります。マネジャーの役割を分解していった結果、この5分類に落ち着いた、という形です。

マネジメントの5分類	内容
理想マネジメント	理想づくり、理解・浸透
業務マネジメント	業務の設計、業務の実行リード
組織マネジメント	組織構造の設計、組織運営
人材マネジメント	人材リソースの確保（配置・育成、採用）、マッチング（業務内容、働き方、給与評価）、再マッチング/契約終了　※成長支援や安全配慮なども契約形態に応じて行う。
投資マネジメント	投資の見積もり（予算策定）、投資の実行

マネジャーは「役割」であり「役職」ではない

Q：トップマネジメント（本部長）／ミドルマネジメント（部長）／フロントラインリーダー（チームリーダー）という3レイヤーで、それぞれが意識すべき視点や役割の範囲をどのように分担されているのでしょうか。また、各レイヤーのマネジャーは、プレイング業務や現場との接点をどのように持っているのでしょうか。

匠：当社では、トップマネジメントが本部長、ミドルマネジメントが部長職、フロントラインリーダーが各チームのチームリーダーという3層構造です。トップマネジメントは本部長にあたるため、本部単位で役割を遂行します。ミドルマネジメントは部長のため部単位、フロントラインリーダーはチームリーダーのためチーム単位と、マネジメントの対象範囲の大きさに違いがあります。

また、それぞれが意識すべき視点ですが、トップマネジメントが意識するのは、全社横断の経営目線です。ミドルマネジメントは、中間管理職として間に立つ立場となるため、上位組織の理想や、他部門とのアラインメントを意識する役割を担います。フロントラインリーダーは、上位組織や他部門とのアラインメントは部長が担うことを前提に、自分が受け持つチームの成果を最大化することに意識を向けます。

マネジメントの3階層	レイヤーごとの役割
本部長（トップマネジメント）	経営層として、全社横断/経営目線を意識して、本部単位で役割を遂行する。
部長 （ミドルマネジメント）	中間層として、上位理想/他部門とのアラインメントを意識して、部単位で役割を遂行する。
チームリーダー （フロントラインリーダー）	最前線のリーダーとして、現場の成果最大化を意識して、チーム単位で役割を遂行する。

プレイング業務との関係についてですが、チームリーダーはほとんどプレイヤーです。取りまとめも担う立場のため、自身も現場で動きながら、他のメンバーとコミュニケーションしたり、チーム内で業務の割り振りなどを行うのがチームリーダーの役割です。

マネジメントだけを担当しているというメンバーはチームリーダー層にはおらず、ほとんどがプレイングマネジャーという構図になっています。ミドルマネジメントにおいては、マネジメントのみを担う人も一部にはいますが、こちらも大半はプレイングマネージャーというのが現状です。

当社では、役職に就くという形ではなく、マネジャーも1つの役割として位置づけています。マネジャーという役割がその人に加わった、という考え方です。そのため、マネジャーになりたての段階では、プレイヤーとして動く部分はそのまま担ってもらい、それに加えてマネジャーという役割を担う、という形が、マネジャーになりたての段階では多く見られます。そこから徐々に現場の実務から離れていく場合もあります。

基本は、トップ・ミドル・フロントラインの3層構造ですが、その間に「サブマネジャー」を置いている場合もあります。人数の多い組織では、副本部長や副部長を配置し、副本部長に一部のチームを任せる形で権限を委譲して、副本部長にマネジメントを担ってもらいます。部長は副本部長と連携を取っていきます。

副部長を複数配置して組織が階層化されている状況では、部長は副部長とコミュニケーションすることで現場の状態を把握できるため、部長が現場にはほとんど関わらない状態となることもあり、人数の多い組織では、そうした形になっている部分もあります。

佐藤：プレイング業務や現場との接点の持ち方は、5分類の性質にもよります。たとえば、開発本部の技術職の業務マネジメントなど、専門性の高い業務マネジメントとなると、その分野の専門性がない人が担うのは、おそらく難しいでしょう。

一方で、会社全体のなかでも人材マネジメントは、専門性のバックグラウンドが異なる人がアサインされることもあります。専門性が異なっても、ジェネラルなマネジメントスキルとして、組織や人材への貢献が可能な領域だからです。

プレイングや専門性、バックグラウンドといった要素は、マネジメントの性質、役割の性質、規模、階層のどの位置にいるかによって変わってくる、という感覚があります。

AI時代に再定義される職能の境界

Q：実際に運用していくなかでの課題（理想と現実のギャップ含む）や、その課題解決のために工夫されていることがあればお聞かせください。あわせて、今後マネジメントの在り方をさらに更新していかれる方向性についても、お考えをお聞かせください。

佐藤：ここまでお話したのは、本部という大きな単位の基本構造、つまりどのようなラインを設け、どのようなマネジャーを配置したかという内容でした。この大枠の構造については、現状の形でおおむね機能しており、当面はこのまま運用していけると考えています。

現在の課題は、そのなかでさらに細かい単位、具体的には数名から十数名程度で構成される現場のサブチームが、どのような関係性で、どのように仕事を進めていくのか、役割分担をどう設計するのか、という点にあります。実際の業務に直接関わる領域をどう高めていくかが、多くのチームで課題になっていると感じています。

こうした課題を考えるうえで、社内でよく読まれている書籍があります。『チームトポロジー 価値あるソフトウエアをすばやく届ける適応型組織設計』（マシュー・スケルトン、マニュエル・パイス著／日本能率協会マネジメントセンター／2021年）という、技術系の分野で話題となった書籍で、4年ほど前に出版された本です。

この書籍のなかでは、チームの責務が3、4パターンに類型化されており、他のチームと関わるときの関わり方についても、いくつかのパターンで言語化されています。社内でも輪読や勉強会が行われており、この考え方を参考にしながら、それぞれのチームがどのように価値を発揮していくのか、というところに議論の焦点が移ってきていると感じています。

たとえばプロダクトチームは、プロダクトを開発して顧客に届けることが責務ですが、プロダクト開発を担うチームだけでなく、周辺にはセキュリティの専門家チームなども存在します。

セキュリティチームは、プロダクトを直接開発するのではなく、開発チームをセキュリティ面で支援する役割を担っています。この2つのチームの関係、責務の分担、日常のコミュニケーションをどう設計すれば、最終的な顧客への価値提供を最大化できるのか。

セキュリティチームは顧客と直接接していないため、ともすればプロダクトチームの本来の目的から乖離してしまう可能性もあります。一方で、セキュリティチームは良かれと思って専門的なアドバイスを行い、プロダクトチームもセキュリティチームに依頼をすることがある。しかし依頼の仕方や情報の共有方法によっては、専門家チームがプロダクトチームの状況を十分に把握できず、かみ合わないケースも生じます。こうした状況でどう協働していくか、あらゆるチームで関係性を改善し、定義し、整理していくことに、現場での議論の焦点が向かっています。

現場での議論のもう1つの焦点は、AIによって職能の境界が変わりつつあることです。開発のなかでも、プロダクト開発チームはクロスファンクショナルなチームであり、異なる職能のメンバーが1つのチームを構成し、それぞれが専門家として役割を担ってきました。しかし、AIが実用段階に入り、実際に活用され始めている状況のなかで、これまでの専門性の捉え方が変わりつつあります。

エンジニアリングの技術者の専門性、つまりコードを書き、プロダクトを開発するというソフトウエア開発の領域は、以前はその職能を持つ人以外はほぼ触れない世界でした。しかし現在は、デザイナーやプロダクトマネージャーがAIを活用することで、それに近いことが可能になっています。言葉で指示を出せば、不具合の修正や機能の追加をAIが実行できるようになってきています。

これまでは複数の専門性を束ねてチームを構成してきましたが、職能の境界そのものが従来の定義とは変わってきているのです。そうなると、どのような専門性を持つメンバーで、どのようなチームを構成して活動していくべきなのかが、これまでとは異なってきます。この模索を今年から本格化させるプロジェクトを立ち上げ、実験的なチームからチャレンジを始めているところです。

こうした状況のなかで、5軸のうち特に組織マネジメントの難度が上がっていると感じています。人員と規模が拡大するのに伴ってチーム数も増加し、関係性が複雑化しているため、それぞれのチームがしっかり機能し、最終的な成果に結びついている状態を作ることは、以前より難しくなっています。

匠：「組織づくりアップデートプロジェクト」は、まだ道半ばで、これからも継続的に取り組むべきものだと考えています。現時点では3階層5分類という形に整理していますが、これで完成ではなく、継続的にブラッシュアップしていくものです。この整理で運用していくなかで、どこで問題や課題が出てくるかを意識しながら、ブラッシュアップの方向性を検討していきたいと考えています。

5分類は、マネジャーの間では少しずつ浸透してきており、日常の会話のなかでもこの言葉が使われるようになっています。一方で、メンバー側にも「マネジャーとはこういう仕事だ」と理解してもらう必要があり、そのためにこの役割の言語化を進めてきたので、メンバー側への浸透にはまだ課題があります。たとえば、マネジャーへのフィードバック施策のなかで、設問を5分類に沿って設計するなどの取り組みを進めることで、少しずつメンバー側への浸透を図っていきたいと考えています。運用のなかで課題意識が生まれてきたら、それに応じて内容を見直していく予定です。

フロントラインリーダー、すなわち各チームのチームリーダーは、このプロジェクトのなかで新たに設けた役職です。それまで社内の役職は部長層までで、チームリーダーが公式な役職として認識されるようになったのは、このプロジェクトを進めるなかで実現したことでした。

ただ、チームリーダーにはさまざまなパターンがあることも見えてきています。5分類のうち業務マネジメントのみを担うリーダーもいれば、大きなチームを率いて多面的なマネジメントを担うリーダーもいる。この層のなかにさらに階層があるかもしれず、分類をより細かくした方が良いのではないか、というのが現在の課題です。育成の観点でも、多様な属性が混在していると育成の方向性を定めにくいため、リーダー育成の見直しと合わせて、この構造の見直しにも取り組んでいく予定です。

現状では、部長層以上は5つのマネジメントを基本的にすべて担う形になっています。ただ、1人のマネジャーがすべてを担うと負荷が大きくなるため、たとえば2人や3人で分担して部の運営を行える形が望ましいのではないか、とも考えています。実際にそうした運用になっているチームもあります。この裁量は本部や部ごとに自由に設計できる体制のため、同じ部に部長を2人置くようなことはしませんが、間に副部長を置いて権限を一部委譲するといった運用は、実際に行われています。

---

編集後記
今回の取材を通じて感じたのは、マネジメントに普遍的な正解はないということです。サイボウズ株式会社は、組織のフェーズや働き方の変化に応じて、マネジャーを廃止し、復活させ、さらに役割を再定義してきました。そこにあるのは、制度を維持することではなく、組織の目的に合わせてマネジメントを進化させ続ける姿勢です。AIによって職能やチームのあり方が変わりつつある今、その挑戦はまだ続いています。今回の事例が、自社のマネジメントを問い直すきっかけになれば幸いです。