肥⼤化・モノリス化するプロダクト開発組織を ⾃律的で⼩さなチーム群に変えていく 太⽥ 絵⼀郎（サイボウズ株式会社） 2023年4⽉18⽇ / DevOpsDays Tokyo 2023 1 ―kintone開発チームの事例―

⾃⼰紹介 太⽥ 絵⼀郎（おおた かいいちろう） • 2015年 サイボウズ / kintone開発チーム にジョイン • 6年ほど Webアプリケーションエンジニア • 2021年〜 マネージャー • コーディングから離れ、今⽇お話しするチーム変⾰の取り組みを 中⼼に活動 2

⽬次 会社・プロダクトの紹介 開発チームのあゆみと問題 「⾃律的で⼩さなチームへの移⾏」の取り組み • ⽬的・狙い • どのように進めているか • 現状と今後 • 変化を進める上での学び・反省点 3

4 会社・プロダクトのご紹介

会社・プロダクトのご紹介 • サイボウズ企業理念 • kintoneとは • 国内中⼼のシェア拡⼤とグローバルへの挑戦 5

チームワークあふれる 社会を創る 6 サイボウズの理念は「チームワークあふれる社会を創る」こと。 私たちはその理念に沿ってチームワークを⽀えるソフトウェアを 開発し続けてきました。 企業理念

とは サイボウズが世界中にチームワークを広めるため開発している 「業務改善プラットフォーム」 のクラウドサービスです 7

ドラッグ&ドロップで簡単に作成できる Webデータベース（＝”アプリ”） 8 業務データを柔軟に蓄積し、社内で共有・⾒える化できる 運⽤しながらの変更も容易

データやプロジェクトに紐付けた コミュニケーション機能 9 アプリにデータを溜めるだけでなく、業務の円滑化も⽀援

顧客の業務に合わせて拡張可能な ノーコード/ローコード開発プラットフォーム 10 外部サービスとのスムーズな連携などを可能にするAPIを提供

※2023年3⽉末時点 全体では、28,500社が kintone を利⽤中 国内プライム上場企業の 3社に1社が kintone を利⽤中

社数： 1,320 社数： 1,120 顧客数： 850 中華圏 SEA US ※2023年3⽉末時点 の合算 グローバルでも積極展開、成⻑中 12

国内中⼼のシェア拡⼤とグローバルへの挑戦 • 2011年11⽉ 販売開始 • 導⼊ 1,000社 (2013) → 10,000社 (2018) → 20,000社 (2021) • US含むグローバル → これからの挑戦 • 0→1は既に過ぎたが、まだまだ価値を⾼めていくフェーズ 13

14 開発チームの現状と問題

開発チームの現状と問題 • チーム体制の現状 • 徐々に蓄積してきた負債とその影響 15

2022年前半のチーム状況 • ⼈数は全体で約80名、10年強かけてチーム/役割も増えた 16 障害調査/改善 チーム 新機能開発 フロントエンド 刷新チーム インフラ基盤 刷新チーム プロダクト マネージャー (PdM) デザイナー/ ドキュメント クラウド基盤 (AWS) 開発/運⽤チーム SDK/ツール開発 チーム エンジニアチーム ×4

うまくやってきたこと • ⼤⼩の機能アップデートをコンスタントに毎⽉リリース • 新機能開発エンジニアチームのスケールアップ • 1チーム → 4〜6チーム • 「全体を全員で開発する」体制 • チーム間でも柔軟にタスクをやりくり • 属⼈化しにくい 17 プロダクトの成⻑に適応してきた部分

少しずつ起きてきたこと 18 具体的に何が起きていた？ スムーズに開発が進まないことが 増えた？ ふりかえりの雰囲気が重い チームの魅⼒が薄いのでは

問題をできるだけ整理 19 開発スピードの低下 組織の成⻑ （採⽤、改善、etc.） の妨げ “モノ”の 肥⼤化/モノリス化 組織の 肥⼤化/モノリス化 技術のレガシー化 「認知負荷」の増⼤ PdMと開発者の 過度な分業 ⽣産性向上の 機会を逃がす 採⽤アピールの困難さ オーナーシップ/ モチベーションの低下 意思決定・改善の 重さ

問題をできるだけ整理 20 開発スピードの低下 組織の成⻑ （採⽤、改善、etc.） の妨げ “モノ”の 肥⼤化/モノリス化 「認知負荷」の増⼤ PdMと開発者の 過度な分業 オーナーシップ/ モチベーションの低下 • 実装変更時の影響範囲が⼤きい • 学習コストが⾼い（特に新メンバー） • 機能や仕様、コードなど • 10年強かけて徐々に⼤きく複雑化

プロダクトマネージャーと開発者の過度な分業 PdMと開発者が⽐較的独⽴して分業 • コミュニケーションは随時取るが、同じチームではない 分業⾃体は必要と考えている • kintoneはユースケースが多様 • 顧客理解に思考が必要 しかし、⽬線が離れすぎると… • PdMに相談しないと進められない仕事が増える • コミュニケーションが噛み合いづらくなる 21 Core/Why 世界観、戦略、 ユーザーストーリー How 技術、UI、設計/実装、デリ バリー PdM 開発者 開発スピードの低下 組織の成⻑ （採⽤、改善、etc.） の妨げ PdMと開発者の 過度な分業 オーナーシップ/ モチベーションの低下 ⾃律・熟達・⽬的が、内発的モチベー ションの重要な要素 （ダニエル・ピンク）

問題をできるだけ整理 22 開発スピードの低下 組織の成⻑ （採⽤、改善、etc.） の妨げ 組織の 肥⼤化/モノリス化 オーナーシップ/ モチベーションの低下 意思決定・改善の 重さ 決める上で、認識を揃えるべき ⼈が多い ⼈/チームが増え、「⾃分が ここを作っているんだ」感 が減る

問題をできるだけ整理 23 開発スピードの低下 組織の成⻑ （採⽤、改善、etc.） の妨げ 技術のレガシー化 ⽣産性向上の 機会を逃がす 採⽤アピールの困難さ 例）フロントエンドで普及している TypeScriptやReactではなく、Closure Library を利⽤している

問題をできるだけ整理 24 開発スピードの低下 組織の成⻑ （採⽤、改善、etc.） の妨げ “モノ”の 肥⼤化/モノリス化 組織の 肥⼤化/モノリス化 技術のレガシー化 「認知負荷」の増⼤ PdMと開発者の 過度な分業 ⽣産性向上の 機会を逃がす 採⽤アピールの困難さ オーナーシップ/ モチベーションの低下 意思決定・改善の 重さ ⾊々な要素が絡み合って、開発スピードと組織の成⻑を妨げている 銀の弾丸は無さそう、改善の⼿を⾊々打っていく

実際に取り組んでいること 25 “モノ”の 肥⼤化/モノリス化 組織の 肥⼤化/モノリス化 技術のレガシー化 プロジェクト制度 ⾃律的で⼩さなチームへの移⾏ コードを機能ごとにモジュール分割 クラウド基盤の刷新 フロントエンド実装の React 移⾏ ＋マイクロフロントエンド化

26 「⾃律的で⼩さなチームへの移⾏」 の取り組み

「⾃律的で⼩さなチームへの移⾏」の取り組みについて • 狙い、⽅法 • どのように進めてきたか • 現状と今後 • 変化を進める上での学び・反省点 27

狙いは？ • ⼀番やりたいのは、開発チームの価値創造スピードを⾼めること • そのために、組織（と”モノ”）の肥⼤化にともなう問題を改善していく 28 開発スピードの低下 組織の成⻑ （採⽤、改善、etc.） の妨げ “モノ"の 肥⼤化/モノリス化 組織の 肥⼤化/モノリス化 「認知負荷」の増⼤ PdMと開発者の 過度な分業 オーナーシップ/ モチベーションの低下 意思決定・改善の 重さ

⽅法 • 「全員が全機能を作る」体制から、「機能ごとにチームで分担開発 する」体制に変える • 全体を詳細に⾒る必要がない→認知負荷が減る • オーナーシップを⾼める • もちろんオーバーヘッドは増える • 同時に、チームで決められることを増やす • チームの組織的 and/or 技術的な⾃律性を⾼める 29 （全体を全員で開発） チーム ⚙ チーム 🍮 チーム 🐤 チーム 🐰

どのように進めてきたか 30 マイクロサービス化 PoC プロジェクト (2021/6〜10) チーム分割 (2022/6〜) ⽅針転換 & 準備 “モノ”とチームを分割する 技術含め移⾏可能かプロジェクトで検証 チームごとに担当する機能領域を分ける コード/アーキテクチャは初⼿では変えない

マイクロサービス化 PoC プロジェクト • チームを分割する⼿段として、マイクロサービス化の可否をプロ ジェクトとして検証 • 結果 • 技術的/組織的に何が必要か？の解像度は⾼まった • マイクロサービス化をゴールにすると、⻑期間かかることもわかった • 理想の状態が実現できる希望はあるものの、差分/リスクの⼤きさが無視でき ず、マイクロサービス化は継続しない判断 31

⽅針転換 & 準備 • 現状理解 & ⽬線合わせのため、ほぼ全メンバーと1on1実施 • チームの現状の問題は何か？分割についてどう思う？を訊いて回る • ⼤変だったが価値のある活動だった • ⼀次情報が増える、メンバーと⽬線を揃える • マネージャー・アジャイルコーチと⼀緒に問題を整理しつつ、 具体的なアクションを検討 32

「チームトポロジー」から学ぶ • この頃、「チームトポロジー」本の邦訳が出版され話題に • 本の内容： • チームの構成と関係性は、常に進化させていく必要がある • 4種のチーム、3種のインタラクションモードでチーム体制をモデル化 • 逆コンウェイ戦略：まずチーム設計を変えることで、望むアーキテクチャを実現し ていく戦略（コンウェイの法則を逆に利⽤してやる） • チームで広く勉強会を実施 • チームの共通⾔語にもなった 33

転換後の⽅針：チーム分割 チームごとに担当する機能領域を分ける • 「全体を作る」状態よりも認知負荷を下げる • 技術カットでの分割は避けた • 最終的に⾼めたい顧客価値との結びつきが弱まるため • コード/アーキテクチャの変更は無しで始める • 進める中で不都合が出た所から優先的に整えていく想定 • コードのオーナーシップは明確にできないが、そこはMUSTではないと考えた • 「モノから変える」ではなく「ヒトから変える」（≒逆コンウェイ戦略） チームの⾃律性が⾼まるような⼟台づくり・⽀援 • チームの⼈数を少なく保つ • スクラムマスターをチームに置く（実は⻑い間不在だった） 34

段階的に進める • 領域の切り⽅、チーム間の連携の仕⽅など、開始前はすべてが不確実 • 分担によるデメリット/オーバーヘッドがメリットを打ち消すリスクもあった • 機能開発は極⼒継続したい • スモールスタートで、知⾒を得ながら徐々に変えていく 35 従来 2022/6〜10（シーズン1） 2022/10〜（シーズン2） （全体を全員で開発） チーム ⚙ チーム 🍮 チーム 🐤 チーム 🐰 チーム ⚙ （残りの領域を 全員で開発）

シーズン1：1チームだけ分割 • ゴール設定：分割チームを1つ作って、得られた知⾒をまとめること • やったこと • 1チームの担当する領域を決め、そこに専任 • チームにスクラムマスターを置く • チームをクロスファンクショナルにするため、全職能所属に • 従来：エンジニア + QAエンジニアのみ • 追加：PdM、デザイナー、ドキュメント 36 （全体を全員で開発） チーム ⚙ （残りの領域を 全員で開発）

シーズン1：結果 • 👍良かった • 担当領域を決めた → ⾃分ごとになり、知識が⾼めやすい、集中しやすい、わくわく感 • スクラムマスター → チームの課題解決を促進できた • 全職能が所属 → 相談しやすい、⾒通しが良い • 🤔課題 • チームを横断する問題解決・調整をどう進めるかが不明 • 「全職能が所属」は、全チームで実現できるのか 37 認知負荷の軽減やオーナーシップの⾼まりなど、⽬的に沿う効果が得られた → 取り組みを継続していくことに

シーズン2：全体を4チームに分割 • ゴール：チーム横断の課題が取り扱える⾒通しを⽴てること • 分割のメリットをオーバーヘッドが上回るなら厳しい → 実際どうなるか検証したかった • やったこと • 全体を4チームで分担開発 • デザイナーは⼈数が⾜りないので、チームに所属しないことに • チーム横断で必要となるプロセスや役割を定義 • 例：全体PdM、全体スクラムマスター、チームの境界を⾒直す会、代表者による横断のふりかえり 38 デザイナー チーム ⚙ チーム 🍮 チーム 🐤 チーム 🐰 全体PdM チームPdM、エンジニア、QA、ド キュメント、スクラムマスター 全体スクラ ムマスター チーム ⚙ （残りの領域を 全員で開発）

シーズン2：結果 • 👍良かった • 認知負荷減少、オーナーシップの実感は引き続き得られた • チーム横断のタスクや課題解決は連携しつつ扱えた • 時間がかかる場合はあるものの、慣れていけそう • チーム内での⾃律的なプロセス改善が促進された • 実装の進め⽅、テスト⽅針の独⾃化、コードのモジュール分割活動、チームふりかえりのや り⽅など • チームを分割しないとやりにくいことも、そうでないことも 39 分割そのものは良さそうなので、継続

シーズン2：結果 • 🤔課題 • 全チームと連携する必要があるデザイナーの負荷が増えた • チームに所属した PdM が、チームの活動 or 全体の戦略どちらにフォーカス すべきかで困った • 枠組みも⽰せていなかった • ドキュメント担当メンバーがチーム所属すべきかに疑問符 • チームでの活動が少ない時期がしばしばあった 40

現状と今後 • 新機能開発のチーム体制 • シンプルにチームに全職能を揃えるだけでは、うまく回らなかった • これまでの経緯や状況（どんなメンバーが何⼈いるのか？）も含めて良い形を考える 41 デザイン/ ドキュメント チーム ⚙ チーム 🍮 チーム 🐤 チーム 🐰 プロダクト マネージャー 全体スクラム マスター 各チーム、担当領域の開発に責任 エンジニア、QA、スクラムマス ターが所属 領域横断でプロダク ト戦略に責任 領域横断でデザイン/ ドキュメントを担当 チーム横断のプロセ ス改善・⽀援

現状と今後 • 「PdMと開発者の過度な分業」は？ • 単純に「PdMがチームに所属」という形での解決は我々に合わない • 1年前と⽐べて、問題の認識はクリアになってきている • 理想を意識して、次どんなことができるか？を⼀緒に考える 42 デザイン/ ドキュメント チーム ⚙ チーム 🍮 チーム 🐤 チーム 🐰 プロダクト マネージャー 全体スクラム マスター Core/Why 世界観、戦略、 ユーザーストーリー How 技術、UI、設計/実装、デリ バリー PdM 開発者

現状と今後 • 👍体制を変えてから1年弱で改善できたこと • 担当領域の学習しやすさ、ノウハウ蓄積 • オーナーシップの実感 • チーム独⾃でのプロセス改善の促進 • 💪次に取り組むべきこと • チーム/役割を横断した連携をさらに洗練させる • チームで独⾃に改善が進むと、横断で関わるメンバーへのインタフェースが多様になる問題 • チームの⾃律性を最⼤化しつつ、必要な所は共通化 → 全体最適 43

44 変化を進める上での 学び・反省点

「説明」の難しさ • ⼿段を提⽰すると伝わりやすいが、⼿段が独り歩きしやすい • 「チームごとに分担」はわかりやすいが、セクショナリズム重視と受け取られる可能性もある • ⽬的/ビジョンの⼤事さ • ⼿段よりも伝わりづらい（問題が複合的だとなおさら） • 気をつけないと、⾃分⾃⾝も⼿段にとらわれる • 伝わるように⼯夫する • 同じことでも繰り返し⾔う • ⾃分が⾔われる側だったら⼀発で腹落ちできるか？ • できるだけ説明をシンプルにする • 図や⾔葉遣いで伝わりやすく 45

意思決定が⼤変なトピックはなくせないが、 減らしていくことはできる • チーム横断のトピックは常に出てくる • そこの意思決定はどうしても⽐較的⼤変になる • 「これは横断で決めないといけない」「これはチーム毎に⾃由 に決めて良い」とわかりやすく線を引くことで、チームの⾃律 性を⾼められる 46

チームを信じて「お任せ」することの⼤事さ • 背景：機能開発を⽌めずにチームの変化を進めている • 現場は忙しいし、良かれと思って⼿段まで具体的に検討して提⽰ → 思っ た以上にチームに受け⼊れられない… • 理想とする「チームの⾃律性」を、⾃ら削る形になってしまっていた • 実現したいこと/⽬的を⽰して、⼿段はチームで考えてもらう、というア プローチ • とはいえ、エイヤで決めてあげた⽅が良い場合もある。使い分けできると良い 47

相談/壁打ち相⼿がいる⼼強さ • 良いこと • 軌道修正してもらえる • 「チームにとってマイナスのことをやっているのでは？」という気持ちを和 らげる • 誰に？ • チームメンバー、アジャイルコーチ、マネージャー、社外コミュニティ 48

ご清聴ありがとうございました！ • 10年強かけて、組織の肥⼤化/モノリス化などによる問題がチームに 溜まってきた • 認知負荷を減らし、チームの⾃律性を⾼めるため、チームを担当領 域ごとに分割する取り組みを実施 • 段階的に、学びながら変えていく • 1年弱で：認知負荷の減少、オーナーシップの向上、チームごとの改 善促進 49

参考資料 分割チームの活動紹介 • kintone アプリ設定チームの紹介 https://blog.cybozu.io/entry/2022/12/21/170000 • アプリ設定チームにおけるエンジニアの活動を紹介します！ https://blog.cybozu.io/entry/2023/03/03/080000 コードのモジュール分割の取り組み • 複雑性に⽴ち向かうためのサーバーサイドコード分割 https://blog.cybozu.io/entry/2023/03/14/110000 プロジェクト制度 • 組織と技術の両輪で開発を加速させるkintoneチームの取り組み https://speakerdeck.com/itchyny/jjug-ccc-2022-fall-cybozu-kintone • UrlRewriteFilterによるURL書き換え処理をSpring Frameworkの機能に移⾏する https://blog.cybozu.io/entry/2023/01/27/170000 フロントエンド刷新 • 採⽤ページ：フロントエンドエンジニア（kintoneアーキテクチャ刷新PJ） https://cybozu.co.jp/recruit/entry/career/front-end-engineer-kintone.html 50