この記事は、CYBOZU SUMMER BLOG FES '24 (kintone Stage) DAY 5 の記事です。
こんにちは、開発本部 kintone 開発チームでマネージャーをしている太田 @kigh です。 この記事では、サイボウズ開発本部で進めている組織再編について、特に kintone 開発チームの取り組みを中心に紹介します。 何かの参考になれば幸いです。
背景：開発本部での組織再編
本記事の主題である kintone 開発チームでの取り組みは、開発本部全体の組織再編と関連があります。 そこでまず、本部全体の取り組みを背景として簡単にご紹介します。
問題意識
サイボウズは、おかげさまで売上・導入社数とも伸びていますが、グローバルを含めた理想の実現にはまだまだ超えるべき壁がいくつもあります。 そうした議論のなかで、開発本部として「事業戦略を実行する能力を強化したい」という問題意識に至りました。 事業戦略を実行するには、戦略に沿った開発組織の目標・計画を策定し、それが現場のチームやメンバーの活動に反映される必要があります。 これを「学習する組織」を参考に「アラインメント」と表現し、開発組織のテーマとして目指しています。
これまでの状況
開発本部では、業務を遂行する組織の単位は製品チームであり、従来、それが本部直下に多数ぶらさがる形でした。 しかし開発本部は、兼務を含めると400名を超える（2024年8月現在）規模になっており、本部-製品チームの一対多の構造では、個々の製品チームへの戦略の展開や浸透、迅速な意思決定が難しくなっていました。
戦略の展開や浸透は、一般にはマネージャーの責務とされるケースも多いと思います。開発本部では、マネージャーロールを2019年にいちど廃止した後、2022年に復活させました（参考）。しかし、明確な担当領域は人材マネジメントであり、事業戦略の実行までは責務とは置かれませんでした*1。 この点も、事業戦略の浸透しづらさに繋がっていたように思います。
変えたこと
そこで、2024年初頭に2つの変更を行い、アラインメントの強化を目指すことにしました。 一つが、マネージャーの責務に事業戦略に沿った業務遂行や業務・組織マネジメントを明記すること、 もう一つは、事業戦略に基づく「ライン」ごとに製品チーム群を再編しそれぞれに責任者（副本部長）を置くことです。 特に前者が、この後紹介する kintone 開発チームでの取り組みとつながりが強い変化です。 以上が、開発本部全体で2024年初に始めた取り組みです。
kintone 開発チームでの取り組み
ここからは、上述した本部全体の方針も踏まえて、kintone 開発チームで進めている取り組みを紹介します。 基本的に本部全体と同様、アラインメントの強化が狙いですが、チーム特有の問題意識もあります。 背景説明が若干長めになりますが、取り組みそのものと同じ位、あるいはそれ以上に重要な情報と思いますので、お付き合いください。
背景・問題意識
kintone 開発チームは、本部内で最も大きい規模の製品チームです（2024年8月現在、兼務含め120名超）。 kintone は、2011年のイニシャルリリースから10年以上経過した製品ですが、さらに顧客価値を高めて製品を広めるべく、機能をアップデートし続けています。
しかし、特に製品のアップデートを担う機能開発チームにおいて、時間とともに
- 実装・プロセス・組織の改善の停滞
- 現場チームでのエンジニアリングに関する意思決定（タスク優先度、仕様・設計判断、etc.）のやりにくさ、精度低下
という2つの問題が顕在化してきました。
原因については仮説も含みますが、一つには、2020年頃からフロントエンドやインフラの刷新に工数を重点配分したこともあり、機能開発を担うチームから、ベテラン層のメンバーが徐々に減ったことがあります。 その結果、自然なリーダーシップがチームから徐々に生じづらくなってきました。 機能開発チームでは明示的なリーダーロールを置いておらず、リーダーシップを発揮すべき個人は決まっていませんでしたが、従来、ベテランメンバーが自然とそこを担ってきました。 しかしそこが減少したことで、暗黙の役割が宙に浮いてしまう形になったのではと思います。
別の要因として、製品の仕様や実装が肥大化・複雑化してきたこともあります。 作るモノが大きく複雑になったことで、エンジニアが精度の高い判断を下すのが難しくなったり、そもそも判断を下そうという気概が持ちづらくなったと思います。 また製品チーム自体も人数的に大きくなり、特に基盤的なチームにおいて、プロダクトマネージャー (PdM) との距離感が遠くなり、戦略を踏まえたチーム計画が立てづらい、という声もありました。
上記の2つの問題のうち1つめ、実装・プロセス・組織の改善の停滞については、製品横断で責任者を置き、改善の取り組みを推進することで一定の改善ができました。 具体的には、2021年時点では、製品横断の責任者としては製品戦略に責任を持つ PdM のみでしたが、そこに
- 技術 → テックリード
- デザイン → デザインリード
- 組織/チーム → チーム運営
というロールを定義し、意思決定の責任者としてリードを担いました。 これにより、プロジェクト制による改善の加速、フロントエンドの刷新、チームの認知負荷低減を目指すチーム分割などの取り組みを実現することができました。
もう1つの問題、現場チームでのエンジニアリングに関する意思決定については、現場チームに対し、外から具体的に仕事の進め方を提示するなどしてカバーしていました。 特に機能開発のチームでは、PdM がエンジニア出身ということもあり、この戦術は一定ワークし、アウトカムにつながっていました。 しかしこの戦術を続けるにつれ、現場チームが PdM への確認なしに仕事が進めづらい、というケースが目立ってきました。 これは、以下の2つの面で無理があります：
本記事の執筆も機に改めて振り返ると、複数の理由で現場チームのリーダーシップが発揮しづらくなり、チームの自律的に価値を生み出す能力が伸び悩むようになったと思います*4。 ここを改善していくことが、今後の製品の成長にも、本部として目指すアラインメントの強化にも必要でした。
変えたこと：Engineering Manager (EM) の新設
現場チームでのアラインメント・リーダーシップを向上するための試みとして、今年2月から、階層的なチームの各所に責任者を置き、そのロールを Engineering Manager (EM) と呼ぶことにしました*5。 EM の責務は、担当するチーム(群)の成果最大化のため、業務・組織・人材・投資のマネジメントの説明責任を負うことです。
実際には全てのチームに均等に EM を置いたわけではなく、上述したような問題があると思われるチームから徐々に始めました。 それでも、10名以上の EM がチーム内に誕生することになりました。 初期の動きとして、
- PdM から EM 向けに、事業/製品戦略のインプットを行う座学の会
- 各チームでやろうとしていること（戦略・方針）の資料を EM が作成し、PdM・上位の EM・デザインリードからフィードバックを受ける会
- 各チームの EM が集まり、直近の進捗や今後の見通しを報告、軌道修正する定例ミーティング
など、PdM からの提案をもとに具体的なアクションを提示し、実際にやってみる所からスタートしました。
得られた気づき
取り組みを始めて半年ほどが経過し、まだ変化の真っ最中ではありますが、様々なことが見えてきました。
ポジティブな影響
EM を中心として、現場チームでの活動に対してフィードバックや支援を行う体制が強化され、以前よりも意思決定がスムーズになりました。 例えば従来、フレームワークの移行などの大きめな改善は、現場チームからの提案はオーナー/意思決定者が不明確で進めづらく、いざ方針を決めても、事業への価値の説明がこなれておらず、製品全体レベルの意思決定が停滞する、という流れがしばしばありました。 しかし EM の取り組み後、例えばモバイルアプリの開発チームで、従来よりもスピード感を持ってフレームワーク置き換えの着手を開始できています。 EM が責任者として、戦略をインプットして目線を揃え、PdM と開発チームの橋渡しとなって議論を進めた結果だと思います。
また、プロトタイプフェーズのような不確実要素の高い機能開発要件に対し、以前よりも機動的にプロジェクトチームを組み、ゴールを決め達成する、という動きもできるようになりました。 従来も開発チーム主導のプロジェクトは複数ありましたが、内部的な改善が中心で、顧客価値に関わる機能アップデートを見据えた開発には踏み込めていませんでした。 総合的な責任を持つ EM ロールがいることで、PdM の連携を含めて複数のプロジェクトの立ち上げが実現できており、これは事業戦略の遂行の意味で大きな進歩といえます。
課題
一方で、課題も複数見えてきています。 既存のプロダクトオーナーやスクラムマスターといった現場チームのロールには、EMの責務と重なる部分があり、それらのメンバーからは一部戸惑いの声も出ています。 プロダクトオーナーやスクラムマスターが EM と一致するかというと、一般にはそうでないケースも多いと思います。 例えば、EM はエンジニアリング全般の意思決定に責任を持つ一方で、プロダクトオーナーが人材マネジメントを明確に担うことは少ないと思いますし、スクラムマスターが意思決定に責任を持つことも少ないと思います。 では線を引いて分担できるかと言うとそれも難しく、結局境界は引けず、重なるものではないかと考えています。 チームによっても異なる曖昧な境界を持ちつつ、チームの成果最大化という理想は共有し、お互いに協力する形を目指したいです。 ここはスクラムマスター職能とも連携しながら、理想の形を探求していきます。
また、これはかなり社内特有の話にはなりますが、「EM」と職能の「マネージャー」が別ロールである、というややこしさもあります。 本記事ではここまで敢えて触れませんでしたが、開発本部は 職能 × 開発チーム のマトリックス型組織であり、マネージャーは職能に、今回新設したEMは業務を遂行するチームにおける責任者です。 EM の中には、職能のマネージャーを兼務しているメンバーもいれば、そうでないメンバーもいて、この2つのロールには区別があります。 冒頭で述べた通り、開発本部では今年から、マネージャーも事業戦略の遂行に責任を負うことになったわけで、「マネージャーと EM を一致させるべきでは」という声もあります。 そこを一旦見送った背景としては、サイボウズにおいてマネージャーは、給与評価・採用などの人材マネジメント上の責任を付与された、全社的なロールとなっています。 現場チーム(群)の成果最大化をリードして欲しい EM 全員に、評価などの責任も持ってもらうことは、従来との差分や負担が大きいと考え、まずは別の役割として運用することにしました。 ここは可能であれば整理したいところではあります。
最後に、新しく EM を担ってくれたメンバーは責任持って役割に取り組んでいただいていますが、上述の通り、過去にマネージャーを廃止/復活した経緯もあって、マネジメントの実務経験が豊富なメンバーは多くなく、戸惑うケースも多いように感じています。 そのため、EM の経験値アップに向けた支援・育成も重要な課題です。 ある程度規模が大きくなった組織にマネジメント体制を構築する、ということ自体、取り組みがいのあるチャレンジだとも感じています。
終わりに
kintone 開発チームでのアラインメント・リーダーシップ向上に向けた EM ロール新設の取り組みについてご紹介しました。 こういった組織上の変更は、メンバーへの影響も少なからずありますが、チームのポテンシャルを引き出す上では、取り組むべき大切なチャレンジだと考えています。 今回の取り組みについては、他のマネージャーや EM、プロダクトマネージャーなどと議論し、軌道修正をすることで、日々前に進むことができています。 仲間に感謝しながら、今後も製品・事業の成長に向けた活動を続けていきたいと思います！
*1:もちろん、事業戦略から人材マネジメントを完全に分離することはできませんし、マネージャーが貢献しているケースも少なからずあったと思います。ただ、責務として明記されないことで、一定の距離を置く力は働いていたようにも思います。
*2:実際、後述するEMロールの設置を強く希望したのも PdM メンバーでした。
*3:一種の負のスパイラルであり、これは、2023年のRegional Scrum Gathering Tokyoでの森さんの発表で述べられている「考える人と作業する人の分離」という現象に近いと思います。
*4:kintone 開発では多くのチームでスクラムを採用しており、プロダクトオーナーやスクラムマスターロールのメンバーがいます。それらのメンバーは、現場チームの中で、一定のリーダーシップを果たしてくれています。ただ、事業戦略を浸透させたり、チーム外も巻き込んだ改善を進めたりといった部分は、文化やプロセスを変えていく必要もあって、ある所で壁にぶつかるような印象もありました。
*5:上述した横断的ロールのうちチーム運営とテックリードは、EM や職能マネージャーと区別する強い必要性が明確でなかったため、このタイミングで解散しました。
