Upgrade to Pro — share decks privately, control downloads, hide ads and more …

肥大化・モノリス化するプロダクト開発組織を自律的で小さなチーム群に変えていく ―kintone開発チームの事例―

Kaiichiro Ota
April 18, 2023
660

肥大化・モノリス化するプロダクト開発組織を自律的で小さなチーム群に変えていく ―kintone開発チームの事例―

DevOpsDays Tokyo 2023 でのセッション発表資料です。
サイボウズ/kintone開発チームでのチーム体制の変革事例について紹介しています。
https://confengine.com/conferences/devopsdays-tokyo-2023/schedule/rich#session-30884-info

Kaiichiro Ota

April 18, 2023
Tweet

Transcript

  1. ⾃⼰紹介 太⽥ 絵⼀郎(おおた かいいちろう) • 2015年 サイボウズ / kintone開発チーム にジョイン

    • 6年ほど Webアプリケーションエンジニア • 2021年〜 マネージャー • コーディングから離れ、今⽇お話しするチーム変⾰の取り組みを 中⼼に活動 2
  2. 社数: 1,320 社数: 1,120 顧客数: 850 中華圏 SEA US ※2023年3⽉末時点

    の合算 グローバルでも積極展開、成⻑中 12
  3. 国内中⼼のシェア拡⼤とグローバルへの挑戦 • 2011年11⽉ 販売開始 • 導⼊ 1,000社 (2013) → 10,000社

    (2018) → 20,000社 (2021) • US含むグローバル → これからの挑戦 • 0→1は既に過ぎたが、まだまだ価値を⾼めていくフェーズ 13
  4. 2022年前半のチーム状況 • ⼈数は全体で約80名、10年強かけてチーム/役割も増えた 16 障害調査/改善 チーム 新機能開発 フロントエンド 刷新チーム インフラ基盤

    刷新チーム プロダクト マネージャー (PdM) デザイナー/ ドキュメント クラウド基盤 (AWS) 開発/運⽤チーム SDK/ツール開発 チーム エンジニアチーム ×4
  5. うまくやってきたこと • ⼤⼩の機能アップデートをコンスタントに毎⽉リリース • 新機能開発エンジニアチームのスケールアップ • 1チーム → 4〜6チーム •

    「全体を全員で開発する」体制 • チーム間でも柔軟にタスクをやりくり • 属⼈化しにくい 17 プロダクトの成⻑に適応してきた部分
  6. 問題をできるだけ整理 19 開発スピードの低下 組織の成⻑ (採⽤、改善、etc.) の妨げ “モノ”の 肥⼤化/モノリス化 組織の 肥⼤化/モノリス化

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

    過度な分業 オーナーシップ/ モチベーションの低下 • 実装変更時の影響範囲が⼤きい • 学習コストが⾼い(特に新メンバー) • 機能や仕様、コードなど • 10年強かけて徐々に⼤きく複雑化
  8. プロダクトマネージャーと開発者の過度な分業 PdMと開発者が⽐較的独⽴して分業 • コミュニケーションは随時取るが、同じチームではない 分業⾃体は必要と考えている • kintoneはユースケースが多様 • 顧客理解に思考が必要 しかし、⽬線が離れすぎると…

    • PdMに相談しないと進められない仕事が増える • コミュニケーションが噛み合いづらくなる 21 Core/Why 世界観、戦略、 ユーザーストーリー How 技術、UI、設計/実装、デリ バリー PdM 開発者 開発スピードの低下 組織の成⻑ (採⽤、改善、etc.) の妨げ PdMと開発者の 過度な分業 オーナーシップ/ モチベーションの低下 ⾃律・熟達・⽬的が、内発的モチベー ションの重要な要素 (ダニエル・ピンク)
  9. 問題をできるだけ整理 22 開発スピードの低下 組織の成⻑ (採⽤、改善、etc.) の妨げ 組織の 肥⼤化/モノリス化 オーナーシップ/ モチベーションの低下

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

    技術のレガシー化 「認知負荷」の増⼤ PdMと開発者の 過度な分業 ⽣産性向上の 機会を逃がす 採⽤アピールの困難さ オーナーシップ/ モチベーションの低下 意思決定・改善の 重さ ⾊々な要素が絡み合って、開発スピードと組織の成⻑を妨げている 銀の弾丸は無さそう、改善の⼿を⾊々打っていく
  11. 狙いは? • ⼀番やりたいのは、開発チームの価値創造スピードを⾼めること • そのために、組織(と”モノ”)の肥⼤化にともなう問題を改善していく 28 開発スピードの低下 組織の成⻑ (採⽤、改善、etc.) の妨げ

    “モノ"の 肥⼤化/モノリス化 組織の 肥⼤化/モノリス化 「認知負荷」の増⼤ PdMと開発者の 過度な分業 オーナーシップ/ モチベーションの低下 意思決定・改善の 重さ
  12. ⽅法 • 「全員が全機能を作る」体制から、「機能ごとにチームで分担開発 する」体制に変える • 全体を詳細に⾒る必要がない→認知負荷が減る • オーナーシップを⾼める • もちろんオーバーヘッドは増える

    • 同時に、チームで決められることを増やす • チームの組織的 and/or 技術的な⾃律性を⾼める 29 (全体を全員で開発) チーム ⚙ チーム 🍮 チーム 🐤 チーム 🐰
  13. どのように進めてきたか 30 マイクロサービス化 PoC プロジェクト (2021/6〜10) チーム分割 (2022/6〜) ⽅針転換 &

    準備 “モノ”とチームを分割する 技術含め移⾏可能かプロジェクトで検証 チームごとに担当する機能領域を分ける コード/アーキテクチャは初⼿では変えない
  14. マイクロサービス化 PoC プロジェクト • チームを分割する⼿段として、マイクロサービス化の可否をプロ ジェクトとして検証 • 結果 • 技術的/組織的に何が必要か?の解像度は⾼まった

    • マイクロサービス化をゴールにすると、⻑期間かかることもわかった • 理想の状態が実現できる希望はあるものの、差分/リスクの⼤きさが無視でき ず、マイクロサービス化は継続しない判断 31
  15. ⽅針転換 & 準備 • 現状理解 & ⽬線合わせのため、ほぼ全メンバーと1on1実施 • チームの現状の問題は何か?分割についてどう思う?を訊いて回る •

    ⼤変だったが価値のある活動だった • ⼀次情報が増える、メンバーと⽬線を揃える • マネージャー・アジャイルコーチと⼀緒に問題を整理しつつ、 具体的なアクションを検討 32
  16. 「チームトポロジー」から学ぶ • この頃、「チームトポロジー」本の邦訳が出版され話題に • 本の内容: • チームの構成と関係性は、常に進化させていく必要がある • 4種のチーム、3種のインタラクションモードでチーム体制をモデル化 •

    逆コンウェイ戦略:まずチーム設計を変えることで、望むアーキテクチャを実現し ていく戦略(コンウェイの法則を逆に利⽤してやる) • チームで広く勉強会を実施 • チームの共通⾔語にもなった 33
  17. 転換後の⽅針:チーム分割 チームごとに担当する機能領域を分ける • 「全体を作る」状態よりも認知負荷を下げる • 技術カットでの分割は避けた • 最終的に⾼めたい顧客価値との結びつきが弱まるため • コード/アーキテクチャの変更は無しで始める

    • 進める中で不都合が出た所から優先的に整えていく想定 • コードのオーナーシップは明確にできないが、そこはMUSTではないと考えた • 「モノから変える」ではなく「ヒトから変える」(≒逆コンウェイ戦略) チームの⾃律性が⾼まるような⼟台づくり・⽀援 • チームの⼈数を少なく保つ • スクラムマスターをチームに置く(実は⻑い間不在だった) 34
  18. シーズン1:1チームだけ分割 • ゴール設定:分割チームを1つ作って、得られた知⾒をまとめること • やったこと • 1チームの担当する領域を決め、そこに専任 • チームにスクラムマスターを置く •

    チームをクロスファンクショナルにするため、全職能所属に • 従来:エンジニア + QAエンジニアのみ • 追加:PdM、デザイナー、ドキュメント 36 (全体を全員で開発) チーム ⚙ (残りの領域を 全員で開発)
  19. シーズン1:結果 • 👍良かった • 担当領域を決めた → ⾃分ごとになり、知識が⾼めやすい、集中しやすい、わくわく感 • スクラムマスター →

    チームの課題解決を促進できた • 全職能が所属 → 相談しやすい、⾒通しが良い • 🤔課題 • チームを横断する問題解決・調整をどう進めるかが不明 • 「全職能が所属」は、全チームで実現できるのか 37 認知負荷の軽減やオーナーシップの⾼まりなど、⽬的に沿う効果が得られた → 取り組みを継続していくことに
  20. シーズン2:全体を4チームに分割 • ゴール:チーム横断の課題が取り扱える⾒通しを⽴てること • 分割のメリットをオーバーヘッドが上回るなら厳しい → 実際どうなるか検証したかった • やったこと •

    全体を4チームで分担開発 • デザイナーは⼈数が⾜りないので、チームに所属しないことに • チーム横断で必要となるプロセスや役割を定義 • 例:全体PdM、全体スクラムマスター、チームの境界を⾒直す会、代表者による横断のふりかえり 38 デザイナー チーム ⚙ チーム 🍮 チーム 🐤 チーム 🐰 全体PdM チームPdM、エンジニア、QA、ド キュメント、スクラムマスター 全体スクラ ムマスター チーム ⚙ (残りの領域を 全員で開発)
  21. シーズン2:結果 • 👍良かった • 認知負荷減少、オーナーシップの実感は引き続き得られた • チーム横断のタスクや課題解決は連携しつつ扱えた • 時間がかかる場合はあるものの、慣れていけそう •

    チーム内での⾃律的なプロセス改善が促進された • 実装の進め⽅、テスト⽅針の独⾃化、コードのモジュール分割活動、チームふりかえりのや り⽅など • チームを分割しないとやりにくいことも、そうでないことも 39 分割そのものは良さそうなので、継続
  22. シーズン2:結果 • 🤔課題 • 全チームと連携する必要があるデザイナーの負荷が増えた • チームに所属した PdM が、チームの活動 or

    全体の戦略どちらにフォーカス すべきかで困った • 枠組みも⽰せていなかった • ドキュメント担当メンバーがチーム所属すべきかに疑問符 • チームでの活動が少ない時期がしばしばあった 40
  23. 現状と今後 • 新機能開発のチーム体制 • シンプルにチームに全職能を揃えるだけでは、うまく回らなかった • これまでの経緯や状況(どんなメンバーが何⼈いるのか?)も含めて良い形を考える 41 デザイン/ ドキュメント

    チーム ⚙ チーム 🍮 チーム 🐤 チーム 🐰 プロダクト マネージャー 全体スクラム マスター 各チーム、担当領域の開発に責任 エンジニア、QA、スクラムマス ターが所属 領域横断でプロダク ト戦略に責任 領域横断でデザイン/ ドキュメントを担当 チーム横断のプロセ ス改善・⽀援
  24. 現状と今後 • 「PdMと開発者の過度な分業」は? • 単純に「PdMがチームに所属」という形での解決は我々に合わない • 1年前と⽐べて、問題の認識はクリアになってきている • 理想を意識して、次どんなことができるか?を⼀緒に考える 42

    デザイン/ ドキュメント チーム ⚙ チーム 🍮 チーム 🐤 チーム 🐰 プロダクト マネージャー 全体スクラム マスター Core/Why 世界観、戦略、 ユーザーストーリー How 技術、UI、設計/実装、デリ バリー PdM 開発者
  25. 現状と今後 • 👍体制を変えてから1年弱で改善できたこと • 担当領域の学習しやすさ、ノウハウ蓄積 • オーナーシップの実感 • チーム独⾃でのプロセス改善の促進 •

    💪次に取り組むべきこと • チーム/役割を横断した連携をさらに洗練させる • チームで独⾃に改善が進むと、横断で関わるメンバーへのインタフェースが多様になる問題 • チームの⾃律性を最⼤化しつつ、必要な所は共通化 → 全体最適 43
  26. 「説明」の難しさ • ⼿段を提⽰すると伝わりやすいが、⼿段が独り歩きしやすい • 「チームごとに分担」はわかりやすいが、セクショナリズム重視と受け取られる可能性もある • ⽬的/ビジョンの⼤事さ • ⼿段よりも伝わりづらい(問題が複合的だとなおさら) •

    気をつけないと、⾃分⾃⾝も⼿段にとらわれる • 伝わるように⼯夫する • 同じことでも繰り返し⾔う • ⾃分が⾔われる側だったら⼀発で腹落ちできるか? • できるだけ説明をシンプルにする • 図や⾔葉遣いで伝わりやすく 45
  27. 参考資料 分割チームの活動紹介 • 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