DevOpsDays Tokyo 2023 でのセッション発表資料です。 サイボウズ/kintone開発チームでのチーム体制の変革事例について紹介しています。 https://confengine.com/conferences/devopsdays-tokyo-2023/schedule/rich#session-30884-info
肥⼤化・モノリス化するプロダクト開発組織を⾃律的で⼩さなチーム群に変えていく太⽥ 絵⼀郎（サイボウズ株式会社）2023年4⽉18⽇ / DevOpsDays Tokyo 20231―kintone開発チームの事例―
View Slide
⾃⼰紹介太⽥ 絵⼀郎（おおた かいいちろう）• 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に相談しないと進められない仕事が増える• コミュニケーションが噛み合いづらくなる21Core/Why世界観、戦略、ユーザーストーリーHow技術、UI、設計/実装、デリバリーPdM開発者 開発スピードの低下組織の成⻑（採⽤、改善、etc.）の妨げPdMと開発者の過度な分業オーナーシップ/モチベーションの低下⾃律・熟達・⽬的が、内発的モチベーションの重要な要素（ダニエル・ピンク）
問題をできるだけ整理22開発スピードの低下組織の成⻑（採⽤、改善、etc.）の妨げ組織の肥⼤化/モノリス化オーナーシップ/モチベーションの低下意思決定・改善の重さ決める上で、認識を揃えるべき⼈が多い⼈/チームが増え、「⾃分がここを作っているんだ」感が減る
問題をできるだけ整理23開発スピードの低下組織の成⻑（採⽤、改善、etc.）の妨げ技術のレガシー化 ⽣産性向上の機会を逃がす採⽤アピールの困難さ例）フロントエンドで普及しているTypeScriptやReactではなく、ClosureLibrary を利⽤している
問題をできるだけ整理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.html50
kaiichiro
geeforr
eileencodes
aarron
phodgson
wjessup
philhawksworth
lara
jacobian
jennybc
tenderlove
lemiorhan