インパクト10倍を目指すB2B SaaSマルチプロダクトなサイボウズ開発組織の取り組み

インパクト10倍を⽬指す B2B SaaS マルチプロダクト 開発組織の取り組み サイボウズ株式会社 開発本部⻑ 佐藤 鉄平 2024年3⽉18⽇ #開発⽣産性_findy

⾃⼰紹介: 佐藤 鉄平 @teppeis l サイボウズ - 2007年 新卒⼊社 - Webアプリエンジニア - 2016年 開発本部⻑ - 技術、デザイン、 プロダクトマネジメントなど、 製品開発全般を担う l Fav - JavaScript - 🍛🥟🍺⛷👦 2

Agenda l 『製品進化スピード10倍︕インパクト10倍︕』を組織⽬標に l どうしてそれを掲げたのか︖ l 何をやった / やってる︖ l 開発⽣産性とは︖ 3

サイボウズ株式会社 4

サイボウズの理念 チームワークあふれる 社会を創る 私たちはチームワークを⽀える 情報共有サービスを提供しています。

開発の知識がなくても 業務に合わせたシステムを ⾃分たちで作成し改善できる クラウドサービス

スケジュール共有 ワークフローなど 中⼩企業の情報共有を ⽀援するサービス

管理者も現場も使いやすい 中⼤企業向けの 情報共有を ⽀援するサービス

サイボウズ株式会社 l 『チームワークあふれる社会を創る』を理念として、 チームワークを⽀える情報共有ツールを提供 l 1997年創業 - 当初はパッケージソフトウェアの形式で製品を販売 - 2011年にリリースしたSaaS事業が現在の主⼒ l 社員数: 連結1,200名超 - 開発本部: 国内300名, 海外100名 9

『製品進化スピード10倍︕インパクト10倍︕』を組織⽬標に 10

『製品進化スピード10倍︕インパクト10倍︕』 l 2023年の開発本部全体の組織⽬標に掲げた l 製品進化スピード - 検証・学習サイクルを⾼速に回すための基礎的ケイパビリティ - ⼿段、先⾏指標、アウトプット l インパクト - 事業、顧客、社会へのポジティブな影響の⼤きさ - ⽬的、結果指標、アウトカム l 具体的な定義は各製品・チームに任せる 11

なぜこれを掲げたのか︖ 12

事業構造の変化（連結売上推移） 30,000 （百万円） パッケージ他 クラウド 25,000 20,000 15,000 10,000 5,000 0 2011 2012 2013 2014 2015 2016 2017 2018 2019 2020 2021 2022 2023 13

様変わりした事業と組織の環境 l 売上規模、ユーザー数 → クラウド290万契約ユーザー l 事業内容: パッケージ製品からクラウド (SaaS) へ l パートナーエコシステム（API, プラグイン）の発展 l 開発組織の規模 → 400名規模 l 製品の機能数 l コード⾏数 14

15

成⻑すると⾃然と開発は困難になる l 成⻑に伴って、規模に⽐例するタスクが増⼤ - 問い合わせや障害の数 - ライブラリやインフラのアップデートへの対応 - ⼤規模で複雑なコードを読み解く時間 l 分業によりオペレーションの効率化は進むが、 コミュニケーションパスは増⼤ l 慣性が⼤きくなり、変化を起こすコストが上がる l 開発時に気にすることが増えて、スピードが落ちる - あのチームに依頼したけど時間かかりそう 影響範囲の調査にあと1スプリントとろう 問い合わせが来ないよう、完璧に仕上げてからリリースしよう 採⽤したけど覚えること多くてオンボーディング⼤変 16

17

⾝軽にスピーディになってインパクトを l ソフトウェアも組織も、時間や成⻑と共にエントロピーが増⼤し て開発スピードは低下していく - “物理システムの秩序を維持するには、エネルギーを加えなければならな い。ソフトウェアシステムも同じことが⾔える。アーキテクトは、偶然に ⾝を任せるのではなく、構造を良い状態に保つために常にエネルギーを費 やし続けなくてはならない” 『ソフトウェアアーキテクチャの基礎』 l エントロピー増⼤に負けないよう、意識的に荷物を下ろしてス ピーディに動けるようにしていく必要がある l 最終的なインパクトを意識することで、中間的なアウトプット指 標に固執し過ぎず、開発組織の枠を超えてより効果的な施策に取 り組みたい 18

なんで10倍か︖ l いわゆるストレッチな⽬標 - ⽇常の改善の延⻑では到達できないところに点を置く - 書けるコードの⾏数が突然10倍にはならないよね l レバレッジがかかる点はどこか︖ - パレートの法則 l ボトルネックはどこか︖ - TOC 19

何をやった︖やってる︖ 20

スピードとインパクト l スピードが10倍になってもインパクトは10倍にならない - 価値の無い施策にいくら⾼度な技術を注ぎ込んでも無駄 l スピードを出せないと⼤きなインパクトは⽣み出せない - 仮説検証や学習のフィードバックサイクルを⾼速に回すことで価値 が作り込まれる l 後者を意識しながら、前者を改善していくことが⼤事 21

Four keys 指標の活⽤ l 低コストに安全に息を吸うようにデプロイできるように - 「これ⽉例メンテに⼊れますか︖（ビッグバン︕）」 「（コストかけて）即時リリースしますか︖」という議論をなくす l 各数値は異なるチーム間で単純な相対⽐較はできないが、 少なくとも不具合改修等を⼀個流しでデプロイする世界を⽬ 指したい l 『Four keysやっていき委員会』を横断組織として発⾜ - 計測・可視化の仕組み整備 - 改善活動の共有 - やっていき感を出す︕ 22

デプロイ回数が⾶躍的に向上︕５倍︕ 23

リリース戦略の⼯夫 l 事業規模拡⼤により、不確実な機能を⼤きな変更を試す敷居 が⾼かったり、過度な作り込みをしがちな問題に対して l アップデートオプション機能 - 顧客が管理画⾯から特定機能をオプトイン/アウトできる 開発中のベータ的な先⾏提供により、素早くフィードバックを得る パートナーはいち早く担当顧客への影響を検証できる 顧客にとって⼤きな変更の移⾏期間ができる l 特定ユーザーへのリリース - 特定のターゲットユーザーからのみフィードバックを得る - 他のユーザーへの影響を気にする必要なく敷居が低い 24

開発組織に閉じない l インパクトをもたらすには開発だけでは限定的 l 製品チームへの問い合わせフローの⾒直し l 障害対応フロー（SLO周り） l プロダクトポートフォリオの整理 l ライセンスや制限値 25

モブプロ / モブ作業 l サイボウズではモブプロ、モブ作業が頻出 l 情報を共有しながら⼀気に仕事を終わらせる、 待ち時間なし、リードタイムの短縮 l フロー効率 vs. リソース効率 l リモートでのオンボーディングにも有効 26

横断⽀援系チーム l 複数の製品チームを横断して⽀援する専⾨家チーム - ⽣産性向上チーム - - Four keys やっていき委員会の⺟体 - CIやGitHub Copilotなど開発⽀援ツールの導⼊や⽀援など フロントエンドエキスパートチーム アジャイルコーチ PSIRT People Experience （採⽤オンボーディング⽀援） … l 共通的な関⼼事や専⾨領域について、各製品チームが独⼒で 解決しなくても、相談できたりサービスを提供してくれる 27

チームトポロジー l チーム構造が複雑化してきたので、輪講してみた l 製品開発チームと⽀援系のチームがどう関わるか︖などの議 論で、語彙とパターンが整理された - ストリームアラインドチームには、イネーブリングとして関わろう、 など l 依頼 is スメル - 適切な境界と関わり⽅になっているか︖ - ⾃チームの主たる関⼼事を前進させるために、外部がブロッカーに なっていないか︖ l 製品チームと⽀援系チームはアライメントできているか︖ 28

アラインメント l 組織の各チーム、個々のメ ンバーが共通の⽬標やビ ジョンに向かって協⼒し、 それぞれの能⼒を発揮しな がら、組織全体として最⼤ の成果を⽣み出す状態 l 上下左右で揃えていく必要 がある。今年の開発組織と してのテーマ Spotify Rhythm - how we get aligned (slides from my talk at Agile Sverige) - Crisp's Blog 29

• https://blog.crisp.se/2016/06/08/henrikkniberg/spotify-rhythm

「開発⽣産性」との関連 30

開発⽣産性という概念の難しさ l もう皆さんに語り尽くされてる感がありますが… l スピードやインパクトは「⼤きさ」、⽣産性は「割合」 l 分⼦ (IN) と分⺟ (OUT) の認識が違うとすれ違う l IN - 労働⼈数(時間): チーム - 事業コスト: 経営 - 開発コスト: 開発マネージャー l OUT - 仕事量: チーム - 期待付加価値: プロダクト - 実現付加価値: 事業・経営 参考: @hirokidaichi『開発⽣産性について議論する前に知っておきたいこと #開発⽣産性 – Qiita』 31

• https://qiita.com/hirokidaichi/items/53f0865398829bdebef1

⽣産性とスピードの概念 l ⽣産性は定義的には「スループット」寄りの概念 l 「リードタイム」的なスピードの表現が苦⼿ l 現代的なSaaS開発においては、後者の重要性も⾼い l この辺りの認識を合わせながら取り組んでいくのが⼤事 32

まとめ 33

まとめ l 成⻑とともに⾃然と開発スピードは低下していくので、 ⻭を⾷いしばって抵抗していく必要があるよ l 最終的なインパクトを意識しながら、開発に閉じずに、さま ざまな⾓度から製品の進化スピードを⾼めていきたい l 採⽤してます︕ 34

参考⽂献 35

参考⽂献 l Mark Richards, Neal Ford著『ソフトウェアアーキテクチャの基礎』 https://www.oreilly.co.jp//books/9784873119823/ l Spotify Rhythm - how we get aligned (slides from my talk at Agile Sverige) - Crisp's Blog https://blog.crisp.se/2016/06/08/henrikkniberg/spotify-rhythm l 開発⽣産性について議論する前に知っておきたいこと #開発⽣産性 – Qiita https://qiita.com/hirokidaichi/items/53f0865398829bdebef1 36

• https://www.oreilly.co.jp//books/9784873119823/
• https://blog.crisp.se/2016/06/08/henrikkniberg/spotify-rhythm
• https://qiita.com/hirokidaichi/items/53f0865398829bdebef1