Link
Embed
Share
Beginning
This slide
Copy link URL
Copy link URL
Copy iframe embed code
Copy iframe embed code
Copy javascript embed code
Copy javascript embed code
Share
Tweet
Share
Tweet
Slide 1
Slide 1 text
肥⼤化・モノリス化するプロダクト開発組織を ⾃律的で⼩さなチーム群に変えていく 太⽥ 絵⼀郎(サイボウズ株式会社) 2023年4⽉18⽇ / DevOpsDays Tokyo 2023 1 ―kintone開発チームの事例―
Slide 2
Slide 2 text
⾃⼰紹介 太⽥ 絵⼀郎(おおた かいいちろう) • 2015年 サイボウズ / kintone開発チーム にジョイン • 6年ほど Webアプリケーションエンジニア • 2021年〜 マネージャー • コーディングから離れ、今⽇お話しするチーム変⾰の取り組みを 中⼼に活動 2
Slide 3
Slide 3 text
⽬次 会社・プロダクトの紹介 開発チームのあゆみと問題 「⾃律的で⼩さなチームへの移⾏」の取り組み • ⽬的・狙い • どのように進めているか • 現状と今後 • 変化を進める上での学び・反省点 3
Slide 4
Slide 4 text
4 会社・プロダクトのご紹介
Slide 5
Slide 5 text
会社・プロダクトのご紹介 • サイボウズ企業理念 • kintoneとは • 国内中⼼のシェア拡⼤とグローバルへの挑戦 5
Slide 6
Slide 6 text
チームワークあふれる 社会を創る 6 サイボウズの理念は「チームワークあふれる社会を創る」こと。 私たちはその理念に沿ってチームワークを⽀えるソフトウェアを 開発し続けてきました。 企業理念
Slide 7
Slide 7 text
とは サイボウズが世界中にチームワークを広めるため開発している 「業務改善プラットフォーム」 のクラウドサービスです 7
Slide 8
Slide 8 text
ドラッグ&ドロップで簡単に作成できる Webデータベース(=”アプリ”) 8 業務データを柔軟に蓄積し、社内で共有・⾒える化できる 運⽤しながらの変更も容易
Slide 9
Slide 9 text
データやプロジェクトに紐付けた コミュニケーション機能 9 アプリにデータを溜めるだけでなく、業務の円滑化も⽀援
Slide 10
Slide 10 text
顧客の業務に合わせて拡張可能な ノーコード/ローコード開発プラットフォーム 10 外部サービスとのスムーズな連携などを可能にするAPIを提供
Slide 11
Slide 11 text
※2023年3⽉末時点 全体では、28,500社が kintone を利⽤中 国内プライム上場企業の 3社に1社が kintone を利⽤中
Slide 12
Slide 12 text
社数: 1,320 社数: 1,120 顧客数: 850 中華圏 SEA US ※2023年3⽉末時点 の合算 グローバルでも積極展開、成⻑中 12
Slide 13
Slide 13 text
国内中⼼のシェア拡⼤とグローバルへの挑戦 • 2011年11⽉ 販売開始 • 導⼊ 1,000社 (2013) → 10,000社 (2018) → 20,000社 (2021) • US含むグローバル → これからの挑戦 • 0→1は既に過ぎたが、まだまだ価値を⾼めていくフェーズ 13
Slide 14
Slide 14 text
14 開発チームの現状と問題
Slide 15
Slide 15 text
開発チームの現状と問題 • チーム体制の現状 • 徐々に蓄積してきた負債とその影響 15
Slide 16
Slide 16 text
2022年前半のチーム状況 • ⼈数は全体で約80名、10年強かけてチーム/役割も増えた 16 障害調査/改善 チーム 新機能開発 フロントエンド 刷新チーム インフラ基盤 刷新チーム プロダクト マネージャー (PdM) デザイナー/ ドキュメント クラウド基盤 (AWS) 開発/運⽤チーム SDK/ツール開発 チーム エンジニアチーム ×4
Slide 17
Slide 17 text
うまくやってきたこと • ⼤⼩の機能アップデートをコンスタントに毎⽉リリース • 新機能開発エンジニアチームのスケールアップ • 1チーム → 4〜6チーム • 「全体を全員で開発する」体制 • チーム間でも柔軟にタスクをやりくり • 属⼈化しにくい 17 プロダクトの成⻑に適応してきた部分
Slide 18
Slide 18 text
少しずつ起きてきたこと 18 具体的に何が起きていた? スムーズに開発が進まないことが 増えた? ふりかえりの雰囲気が重い チームの魅⼒が薄いのでは
Slide 19
Slide 19 text
問題をできるだけ整理 19 開発スピードの低下 組織の成⻑ (採⽤、改善、etc.) の妨げ “モノ”の 肥⼤化/モノリス化 組織の 肥⼤化/モノリス化 技術のレガシー化 「認知負荷」の増⼤ PdMと開発者の 過度な分業 ⽣産性向上の 機会を逃がす 採⽤アピールの困難さ オーナーシップ/ モチベーションの低下 意思決定・改善の 重さ
Slide 20
Slide 20 text
問題をできるだけ整理 20 開発スピードの低下 組織の成⻑ (採⽤、改善、etc.) の妨げ “モノ”の 肥⼤化/モノリス化 「認知負荷」の増⼤ PdMと開発者の 過度な分業 オーナーシップ/ モチベーションの低下 • 実装変更時の影響範囲が⼤きい • 学習コストが⾼い(特に新メンバー) • 機能や仕様、コードなど • 10年強かけて徐々に⼤きく複雑化
Slide 21
Slide 21 text
プロダクトマネージャーと開発者の過度な分業 PdMと開発者が⽐較的独⽴して分業 • コミュニケーションは随時取るが、同じチームではない 分業⾃体は必要と考えている • kintoneはユースケースが多様 • 顧客理解に思考が必要 しかし、⽬線が離れすぎると… • PdMに相談しないと進められない仕事が増える • コミュニケーションが噛み合いづらくなる 21 Core/Why 世界観、戦略、 ユーザーストーリー How 技術、UI、設計/実装、デリ バリー PdM 開発者 開発スピードの低下 組織の成⻑ (採⽤、改善、etc.) の妨げ PdMと開発者の 過度な分業 オーナーシップ/ モチベーションの低下 ⾃律・熟達・⽬的が、内発的モチベー ションの重要な要素 (ダニエル・ピンク)
Slide 22
Slide 22 text
問題をできるだけ整理 22 開発スピードの低下 組織の成⻑ (採⽤、改善、etc.) の妨げ 組織の 肥⼤化/モノリス化 オーナーシップ/ モチベーションの低下 意思決定・改善の 重さ 決める上で、認識を揃えるべき ⼈が多い ⼈/チームが増え、「⾃分が ここを作っているんだ」感 が減る
Slide 23
Slide 23 text
問題をできるだけ整理 23 開発スピードの低下 組織の成⻑ (採⽤、改善、etc.) の妨げ 技術のレガシー化 ⽣産性向上の 機会を逃がす 採⽤アピールの困難さ 例)フロントエンドで普及している TypeScriptやReactではなく、Closure Library を利⽤している
Slide 24
Slide 24 text
問題をできるだけ整理 24 開発スピードの低下 組織の成⻑ (採⽤、改善、etc.) の妨げ “モノ”の 肥⼤化/モノリス化 組織の 肥⼤化/モノリス化 技術のレガシー化 「認知負荷」の増⼤ PdMと開発者の 過度な分業 ⽣産性向上の 機会を逃がす 採⽤アピールの困難さ オーナーシップ/ モチベーションの低下 意思決定・改善の 重さ ⾊々な要素が絡み合って、開発スピードと組織の成⻑を妨げている 銀の弾丸は無さそう、改善の⼿を⾊々打っていく
Slide 25
Slide 25 text
実際に取り組んでいること 25 “モノ”の 肥⼤化/モノリス化 組織の 肥⼤化/モノリス化 技術のレガシー化 プロジェクト制度 ⾃律的で⼩さなチームへの移⾏ コードを機能ごとにモジュール分割 クラウド基盤の刷新 フロントエンド実装の React 移⾏ +マイクロフロントエンド化
Slide 26
Slide 26 text
26 「⾃律的で⼩さなチームへの移⾏」 の取り組み
Slide 27
Slide 27 text
「⾃律的で⼩さなチームへの移⾏」の取り組みについて • 狙い、⽅法 • どのように進めてきたか • 現状と今後 • 変化を進める上での学び・反省点 27
Slide 28
Slide 28 text
狙いは? • ⼀番やりたいのは、開発チームの価値創造スピードを⾼めること • そのために、組織(と”モノ”)の肥⼤化にともなう問題を改善していく 28 開発スピードの低下 組織の成⻑ (採⽤、改善、etc.) の妨げ “モノ"の 肥⼤化/モノリス化 組織の 肥⼤化/モノリス化 「認知負荷」の増⼤ PdMと開発者の 過度な分業 オーナーシップ/ モチベーションの低下 意思決定・改善の 重さ
Slide 29
Slide 29 text
⽅法 • 「全員が全機能を作る」体制から、「機能ごとにチームで分担開発 する」体制に変える • 全体を詳細に⾒る必要がない→認知負荷が減る • オーナーシップを⾼める • もちろんオーバーヘッドは増える • 同時に、チームで決められることを増やす • チームの組織的 and/or 技術的な⾃律性を⾼める 29 (全体を全員で開発) チーム ⚙ チーム 🍮 チーム 🐤 チーム 🐰
Slide 30
Slide 30 text
どのように進めてきたか 30 マイクロサービス化 PoC プロジェクト (2021/6〜10) チーム分割 (2022/6〜) ⽅針転換 & 準備 “モノ”とチームを分割する 技術含め移⾏可能かプロジェクトで検証 チームごとに担当する機能領域を分ける コード/アーキテクチャは初⼿では変えない
Slide 31
Slide 31 text
マイクロサービス化 PoC プロジェクト • チームを分割する⼿段として、マイクロサービス化の可否をプロ ジェクトとして検証 • 結果 • 技術的/組織的に何が必要か?の解像度は⾼まった • マイクロサービス化をゴールにすると、⻑期間かかることもわかった • 理想の状態が実現できる希望はあるものの、差分/リスクの⼤きさが無視でき ず、マイクロサービス化は継続しない判断 31
Slide 32
Slide 32 text
⽅針転換 & 準備 • 現状理解 & ⽬線合わせのため、ほぼ全メンバーと1on1実施 • チームの現状の問題は何か?分割についてどう思う?を訊いて回る • ⼤変だったが価値のある活動だった • ⼀次情報が増える、メンバーと⽬線を揃える • マネージャー・アジャイルコーチと⼀緒に問題を整理しつつ、 具体的なアクションを検討 32
Slide 33
Slide 33 text
「チームトポロジー」から学ぶ • この頃、「チームトポロジー」本の邦訳が出版され話題に • 本の内容: • チームの構成と関係性は、常に進化させていく必要がある • 4種のチーム、3種のインタラクションモードでチーム体制をモデル化 • 逆コンウェイ戦略:まずチーム設計を変えることで、望むアーキテクチャを実現し ていく戦略(コンウェイの法則を逆に利⽤してやる) • チームで広く勉強会を実施 • チームの共通⾔語にもなった 33
Slide 34
Slide 34 text
転換後の⽅針:チーム分割 チームごとに担当する機能領域を分ける • 「全体を作る」状態よりも認知負荷を下げる • 技術カットでの分割は避けた • 最終的に⾼めたい顧客価値との結びつきが弱まるため • コード/アーキテクチャの変更は無しで始める • 進める中で不都合が出た所から優先的に整えていく想定 • コードのオーナーシップは明確にできないが、そこはMUSTではないと考えた • 「モノから変える」ではなく「ヒトから変える」(≒逆コンウェイ戦略) チームの⾃律性が⾼まるような⼟台づくり・⽀援 • チームの⼈数を少なく保つ • スクラムマスターをチームに置く(実は⻑い間不在だった) 34
Slide 35
Slide 35 text
段階的に進める • 領域の切り⽅、チーム間の連携の仕⽅など、開始前はすべてが不確実 • 分担によるデメリット/オーバーヘッドがメリットを打ち消すリスクもあった • 機能開発は極⼒継続したい • スモールスタートで、知⾒を得ながら徐々に変えていく 35 従来 2022/6〜10(シーズン1) 2022/10〜(シーズン2) (全体を全員で開発) チーム ⚙ チーム 🍮 チーム 🐤 チーム 🐰 チーム ⚙ (残りの領域を 全員で開発)
Slide 36
Slide 36 text
シーズン1:1チームだけ分割 • ゴール設定:分割チームを1つ作って、得られた知⾒をまとめること • やったこと • 1チームの担当する領域を決め、そこに専任 • チームにスクラムマスターを置く • チームをクロスファンクショナルにするため、全職能所属に • 従来:エンジニア + QAエンジニアのみ • 追加:PdM、デザイナー、ドキュメント 36 (全体を全員で開発) チーム ⚙ (残りの領域を 全員で開発)
Slide 37
Slide 37 text
シーズン1:結果 • 👍良かった • 担当領域を決めた → ⾃分ごとになり、知識が⾼めやすい、集中しやすい、わくわく感 • スクラムマスター → チームの課題解決を促進できた • 全職能が所属 → 相談しやすい、⾒通しが良い • 🤔課題 • チームを横断する問題解決・調整をどう進めるかが不明 • 「全職能が所属」は、全チームで実現できるのか 37 認知負荷の軽減やオーナーシップの⾼まりなど、⽬的に沿う効果が得られた → 取り組みを継続していくことに
Slide 38
Slide 38 text
シーズン2:全体を4チームに分割 • ゴール:チーム横断の課題が取り扱える⾒通しを⽴てること • 分割のメリットをオーバーヘッドが上回るなら厳しい → 実際どうなるか検証したかった • やったこと • 全体を4チームで分担開発 • デザイナーは⼈数が⾜りないので、チームに所属しないことに • チーム横断で必要となるプロセスや役割を定義 • 例:全体PdM、全体スクラムマスター、チームの境界を⾒直す会、代表者による横断のふりかえり 38 デザイナー チーム ⚙ チーム 🍮 チーム 🐤 チーム 🐰 全体PdM チームPdM、エンジニア、QA、ド キュメント、スクラムマスター 全体スクラ ムマスター チーム ⚙ (残りの領域を 全員で開発)
Slide 39
Slide 39 text
シーズン2:結果 • 👍良かった • 認知負荷減少、オーナーシップの実感は引き続き得られた • チーム横断のタスクや課題解決は連携しつつ扱えた • 時間がかかる場合はあるものの、慣れていけそう • チーム内での⾃律的なプロセス改善が促進された • 実装の進め⽅、テスト⽅針の独⾃化、コードのモジュール分割活動、チームふりかえりのや り⽅など • チームを分割しないとやりにくいことも、そうでないことも 39 分割そのものは良さそうなので、継続
Slide 40
Slide 40 text
シーズン2:結果 • 🤔課題 • 全チームと連携する必要があるデザイナーの負荷が増えた • チームに所属した PdM が、チームの活動 or 全体の戦略どちらにフォーカス すべきかで困った • 枠組みも⽰せていなかった • ドキュメント担当メンバーがチーム所属すべきかに疑問符 • チームでの活動が少ない時期がしばしばあった 40
Slide 41
Slide 41 text
現状と今後 • 新機能開発のチーム体制 • シンプルにチームに全職能を揃えるだけでは、うまく回らなかった • これまでの経緯や状況(どんなメンバーが何⼈いるのか?)も含めて良い形を考える 41 デザイン/ ドキュメント チーム ⚙ チーム 🍮 チーム 🐤 チーム 🐰 プロダクト マネージャー 全体スクラム マスター 各チーム、担当領域の開発に責任 エンジニア、QA、スクラムマス ターが所属 領域横断でプロダク ト戦略に責任 領域横断でデザイン/ ドキュメントを担当 チーム横断のプロセ ス改善・⽀援
Slide 42
Slide 42 text
現状と今後 • 「PdMと開発者の過度な分業」は? • 単純に「PdMがチームに所属」という形での解決は我々に合わない • 1年前と⽐べて、問題の認識はクリアになってきている • 理想を意識して、次どんなことができるか?を⼀緒に考える 42 デザイン/ ドキュメント チーム ⚙ チーム 🍮 チーム 🐤 チーム 🐰 プロダクト マネージャー 全体スクラム マスター Core/Why 世界観、戦略、 ユーザーストーリー How 技術、UI、設計/実装、デリ バリー PdM 開発者
Slide 43
Slide 43 text
現状と今後 • 👍体制を変えてから1年弱で改善できたこと • 担当領域の学習しやすさ、ノウハウ蓄積 • オーナーシップの実感 • チーム独⾃でのプロセス改善の促進 • 💪次に取り組むべきこと • チーム/役割を横断した連携をさらに洗練させる • チームで独⾃に改善が進むと、横断で関わるメンバーへのインタフェースが多様になる問題 • チームの⾃律性を最⼤化しつつ、必要な所は共通化 → 全体最適 43
Slide 44
Slide 44 text
44 変化を進める上での 学び・反省点
Slide 45
Slide 45 text
「説明」の難しさ • ⼿段を提⽰すると伝わりやすいが、⼿段が独り歩きしやすい • 「チームごとに分担」はわかりやすいが、セクショナリズム重視と受け取られる可能性もある • ⽬的/ビジョンの⼤事さ • ⼿段よりも伝わりづらい(問題が複合的だとなおさら) • 気をつけないと、⾃分⾃⾝も⼿段にとらわれる • 伝わるように⼯夫する • 同じことでも繰り返し⾔う • ⾃分が⾔われる側だったら⼀発で腹落ちできるか? • できるだけ説明をシンプルにする • 図や⾔葉遣いで伝わりやすく 45
Slide 46
Slide 46 text
意思決定が⼤変なトピックはなくせないが、 減らしていくことはできる • チーム横断のトピックは常に出てくる • そこの意思決定はどうしても⽐較的⼤変になる • 「これは横断で決めないといけない」「これはチーム毎に⾃由 に決めて良い」とわかりやすく線を引くことで、チームの⾃律 性を⾼められる 46
Slide 47
Slide 47 text
チームを信じて「お任せ」することの⼤事さ • 背景:機能開発を⽌めずにチームの変化を進めている • 現場は忙しいし、良かれと思って⼿段まで具体的に検討して提⽰ → 思っ た以上にチームに受け⼊れられない… • 理想とする「チームの⾃律性」を、⾃ら削る形になってしまっていた • 実現したいこと/⽬的を⽰して、⼿段はチームで考えてもらう、というア プローチ • とはいえ、エイヤで決めてあげた⽅が良い場合もある。使い分けできると良い 47
Slide 48
Slide 48 text
相談/壁打ち相⼿がいる⼼強さ • 良いこと • 軌道修正してもらえる • 「チームにとってマイナスのことをやっているのでは?」という気持ちを和 らげる • 誰に? • チームメンバー、アジャイルコーチ、マネージャー、社外コミュニティ 48
Slide 49
Slide 49 text
ご清聴ありがとうございました! • 10年強かけて、組織の肥⼤化/モノリス化などによる問題がチームに 溜まってきた • 認知負荷を減らし、チームの⾃律性を⾼めるため、チームを担当領 域ごとに分割する取り組みを実施 • 段階的に、学びながら変えていく • 1年弱で:認知負荷の減少、オーナーシップの向上、チームごとの改 善促進 49
Slide 50
Slide 50 text
参考資料 分割チームの活動紹介 • 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