個人分担性がスタートアップの成長を殺す〜協働でチームがめっちゃ進化する話〜

by Takeo Imai

Slide 1

Slide 1 text

個⼈分担性がスタートアップの成⻑を殺す〜協働でチームがめっちゃ進化する話〜 2023/8/26 スクラムフェス仙台2023 ぼのたけ今井健男（@bonotake）

Slide 2

Slide 2 text

今井健男（ぼのたけ）スクラムフェス仙台2023 フリーランスアジャイルコーチ • スクラムの導⼊⽀援、改善 • プロダクトマネジメント⽀援 • 開発組織づくり、特にBiz/Dev連携⽀援 • ソフトウェア⼯学研究者 • 南⼭⼤学⾮常勤講師（冬だけ） • ⽇本ソフトウェア科学会機械学習⼯学研究会（MLSE）主査 2023/8/26 2

Slide 3

Slide 3 text

本⽇のテーマ：スタートアップとスクラムスクラムフェス仙台2023 2023/8/26 3 実例として、私が社員として／外部委託のアジャイルコーチとして関わった • Idein株式会社 • matsuri technologies株式会社の2社での事例を、両社の同意のもとお話します（両社のご厚意に感謝します）また、ishiyさんによる本⽇13:30〜『モブコードリーディング〜コンポーネントチームからフィーチャーチームを⽬指して〜』は関連するIdeinでの取り組みです

Slide 4

Slide 4 text

スタートアップとスクラムの話スクラムフェス仙台2023 2023/8/26 4 でも全然アジャイルっぽくない……なぜ？スタートアップは結構アジャイルっぽい開発をしていることが多いプロダクトバックログ、カンバンライクな開発アイテム管理毎週〜隔週でプランニング的なミーティング

Slide 5

Slide 5 text

スタートアップで起こりがちなことスクラムフェス仙台2023 2023/8/26 5 • PBIがやたら⼤きい • PBIごとに担当者がアサインされている • 締切、納期まで⼊ってることもある • 1つのPBIがいつまで経っても終わらない ……それは、個⼈分担制になっているから

Slide 6

Slide 6 text

スタートアップと個⼈開発：草創期スクラムフェス仙台2023 2023/8/26 6 • 多くの場合、エンジニアが1〜 2名 • 創業者が開発していたりする • しかし、開発アイテムはたんまり積まれている • MVPの概念は知られていない • 当然のように個⼈ベースの開発になる創業者CEO 兼営業創業者CTO 兼エンジニア

Slide 7

Slide 7 text

スタートアップと個⼈開発：ちょっと⼈が増えるスクラムフェス仙台2023 2023/8/26 7 • ⼿が⾜りないので、エンジニアを何とか採⽤する • 構想しているプロダクトの未着⼿なところを丸ごとエンジニアに任せる • 各エンジニアには、⼤きな裁量とともに担当が割り振られる • 担当は⼤きく分かれていて、1⼈ 1⼈の開発の独⽴性はかなり⾼い • → チームを作れる⼈数に達しても、実質個⼈開発のまま創業者〇〇のとこ誰も⼿を付けてないから、任せるわ新⼈エンジニアは〜い

Slide 8

Slide 8 text

例：Ideinにジョインしたばかりの私（実話）スクラムフェス仙台2023 2023/8/26 8 SDK作ってえっ

Slide 9

Slide 9 text

例：Ideinにジョインしたばかりの私（実話）スクラムフェス仙台2023 2023/8/26 9 何もない全部任せるから1⼈で考えて 1⼈で作ってえっ SDKってどんなのですか？今決まってる仕様とか構想とかあります？

Slide 10

Slide 10 text

PMFを終えるとスクラムフェス仙台2023 2023/8/26 10 • 作りたかったものが⼀通り完成する • それなりの顧客／ユーザーがつく • 次は事業をグロースさせ、会社もグロースさせたい！ ……どうなるか？

Slide 11

Slide 11 text

開発がスケールしない（と感じる）スクラムフェス仙台2023 2023/8/26 11 • 今まで、プロダクトを⼤きくしながら成⻑してきた • 事業を⼤きくしたければ、プロダクトもスケールさせないといけない！（と考える） • そのためにはエンジニアをもっと採⽤しないと…… • 実は必ずしもそんなことはない • が、こう思わせる状況に追い込まれている⼈が⾜りない…

Slide 12

Slide 12 text

症状１：エンジニアを増やさないと新しいことができない構造スクラムフェス仙台2023 2023/8/26 12 • 今まで、⼈を増やしては新規の箇所を担当してもらっていた • 同じ要領だと、⼈を増やせないと新しいことができない • 既にいるエンジニアはもう担当があり、新しいことをやれない …

Slide 13

Slide 13 text

症状1.5：１⼈あたりのメンテできる担当規模は⼩さくなっていくスクラムフェス仙台2023 2023/8/26 13 • ⼈を増やしたところで、1⼈あたりが担当できる領域は徐々に⼩さくなっていく • 1⼈が⾒渡して把握できる範囲の相対的な減少 • コミュニケーションコスト増⼤ • ⼈とプロダクト両⽅のマネジメントコスト増⼤ • etc. …

Slide 14

Slide 14 text

症状２：エンジニア全員がSPOF スクラムフェス仙台2023 2023/8/26 14 … • 担当箇所がばっちり分かれているので、誰かが抜けるとたちどころにプロジェクトが危機に直⾯する • 俗にいうトラックナンバーの問題

Slide 15

Slide 15 text

症状３：ホットスポット／コールドスポットの発⽣スクラムフェス仙台2023 2023/8/26 15 • 開発が⼀段落すると、 • 開発がまだまだ必要な箇所（ホットスポット） • 安定して、追加の開発があまり発⽣しない箇所（コールドスポット）が⽣まれる • エンジニアの負荷にバラツキが⽣まれ、⼀部のエンジニアに負荷が集中する PMF前 PMF後

Slide 16

Slide 16 text

症状４：リードタイムの⻑さが気になり始めるスクラムフェス仙台2023 2023/8/26 16 • ユーザー／顧客がつくと、ステークホルダーからの要望にどれだけ⾼いレスポンスで応えられるかが求められる • しかし、クソデカPBIを 1⼈で担当していると、リードタイムはなかなか短縮できない＝レスポンスが上がらない

Slide 17

Slide 17 text

Ideinの場合（〜 2021/12頃）スクラムフェス仙台2023 2023/8/26 17 Service Auth&Pay agent SDK • 4チーム＋マネージャー • 全体でプロダクトバックログ（のようなもの）1つ • チーム内でも担当領域がはっきり分かれていて、事実上の個⼈分担制 • 特定のメンバーに負荷が集中 • チームをまたぐPBIを実施するためにいつも特定のメンバーばかりが稼働 • 更に、PBIを担当できるメンバーが誰かを探してアサインし、それぞれの進捗管理をするコストも過⼤マネージャー ※ 各チーム内の⼈数は適当です

Slide 18

Slide 18 text

matsuri technologiesの場合（2022/12 頃）スクラムフェス仙台2023 2023/8/26 18 • 7つのプロダクトを9⼈のエンジニアで⽀えている状態 • 特にチームなどはなく、 1プロダクトにつきほぼ1⼈が担当 • 深刻な⼈⼿不⾜ m2m-checkin Sumyca m2m-cleaning inspection m2m-systems m2m-core m2m-inventory

Slide 19

Slide 19 text

今こそスクラムの出番スクラムフェス仙台2023 2023/8/26 19 • チーム開発の導⼊ • トラックナンバーを上げ、SPOFをなくす • 開発者の流動性を上げ、ホットスポットに開発リソースを集中できるように • 分担から協働へ • 開発の量よりリードタイム優先 • ステークホルダーからの要望に対してなるたけレスポンスを上げる • 俗にいう「リソース効率よりフロー効率を重視」

Slide 20

Slide 20 text

フロー効率重視の開発へスクラムフェス仙台2023 2023/8/26 20 • PBIをこなすよりスプリントゴールを重視 • よくばったゴールにしない＆ PBIを沢⼭こなそうとしない • それより、設定したゴールを絶対達成するように • 達成しなかったら、次以降は着実に達成するよう徹底的に⼯夫・改善 • スプリントゴールを達成したら、そのスプリントの残りは何をしても良い • 協働（スウォーミング）の意識 • 「1つのタスクを複数⼈でやったっていい」 • ⾃分のやるタスクがなくなったら、ゴール達成のために他の⼈を⼿伝う • ゴール未達成の間はゴールに関係ないタスクに⼿を付けない • それで多少⾮効率だと感じても気にしない（フロー効率的にはそっちの⽅が速い） • 積極的な同期コミュニケーションの勧め「⼀緒にやったらどう？」 • ペアプロ／モブプロを直接勧めなくても、⾃然と皆がやるように

Slide 21

Slide 21 text

スプリントバックログはかなり重要スクラムフェス仙台2023 2023/8/26 21 • SBI／タスクを細かく分割する！ • 個⼈開発前提での「ちょうどよい⼤きさ」は、フロー効率の観点からは⼤きすぎる • SBIが⼩さいほど協働はしやすくなる • いったん着⼿した後で他の⼈に⼿伝ってもらう分を切り出すのはかなり⼤変 • ⼩さく分けられないなら「⼀緒にやる」 • スクラムガイド2020 「スプリントプランニング」トピック3 の説明：これは多くの場合、プロダクトバックログアイテムを 1 ⽇以内の⼩さな作業アイテムに分解することによって⾏われる。 • PBIをそのままSBIにしてはいけない

Slide 22

Slide 22 text

スクラムの導⼊〜Ideinの場合〜スクラムフェス仙台2023 2023/8/26 22

Slide 23

Slide 23 text

チーム開発体制への移⾏（2022/2）スクラムフェス仙台2023 2023/8/26 23 Service Auth&Pay agent NIT • Nexusベースの体制に • 全体で1⼈のPO、1つのPBL • 全体SM • 統合チーム（NIT） • ただし不完全 • 全体でのスクラムイベントは実施する⼀⽅、各チーム内では「スクラムしてもしなくてもいい」とした • 「トラックナンバー1の箇所をなくしてください」 PO SDK SM

Slide 24

Slide 24 text

最初は開発がまったく進まなかったスクラムフェス仙台2023 2023/8/26 24 • 当初はWIPがゆうに10を超えた • 最優先のPBIが全く進まなかった • あるスプリントで確認された状況 • 最優先のPBIが1⼈の開発者Aに全部任されていた • 開発者Aは、PBI以外に多数のタスクを抱えていた⾃分のチームの最優先タスク開発者A個⼈のタスクリスト

Slide 25

Slide 25 text

最初は開発がまったく進まなかったスクラムフェス仙台2023 2023/8/26 25 ⾃分のチームの最優先タスク他チームから頼まれたタスク他チームから頼まれたタスク他チームから頼まれたタスク他チームから頼まれたタスク開発者A個⼈のタスクリスト • 当初はWIPがゆうに10を超えた • 最優先のPBIが全く進まなかった • あるスプリントで確認された状況 • 最優先のPBIが1⼈の開発者Aに全部任されていた • 開発者Aは、PBI以外に多数のタスクを抱えていた

Slide 26

Slide 26 text

最初は開発がまったく進まなかったスクラムフェス仙台2023 2023/8/26 26 ⾃分のチームの最優先タスク他チームから頼まれたタスク他チームから頼まれたタスク他チームから頼まれたタスク他チームから頼まれたタスク彼だけができる専⾨のタスク彼だけができる専⾨のタスク彼だけができる専⾨のタスク開発者A個⼈のタスクリスト・・・ • 当初はWIPがゆうに10を超えた • 最優先のPBIが全く進まなかった • あるスプリントで確認された状況 • 最優先のPBIが1⼈の開発者Aに全部任されていた • 開発者Aは、PBI以外に多数のタスクを抱えていた

Slide 27

Slide 27 text

最初は開発がまったく進まなかったスクラムフェス仙台2023 2023/8/26 27 ⾃分のチームの最優先タスク他チームから頼まれたタスク他チームから頼まれたタスク他チームから頼まれたタスク他チームから頼まれたタスク彼だけができる専⾨のタスク彼だけができる専⾨のタスク彼だけができる専⾨のタスク開発者A個⼈のタスクリスト・・・ここだけしか⼿を付けられていなかった • 当初はWIPがゆうに10を超えた • 最優先のPBIが全く進まなかった • あるスプリントで確認された状況 • 最優先のPBIが1⼈の開発者Aに全部任されていた • 開発者Aは、PBI以外に多数のタスクを抱えていた

Slide 28

Slide 28 text

最初は開発がまったく進まなかったスクラムフェス仙台2023 2023/8/26 28 ⾃分のチームの最優先タスク他チームから頼まれたタスク他チームから頼まれたタスク他チームから頼まれたタスク他チームから頼まれたタスク彼だけができる専⾨のタスク彼だけができる専⾨のタスク彼だけができる専⾨のタスク開発者A個⼈のタスクリスト・・・ここだけしか⼿を付けられなかった • 当初はWIPがゆうに10を超えた • 最優先のPBIが全く進まなかった • あるスプリントで確認された状況 • 最優先のPBIが1⼈の開発者Aに全部任されていた • 開発者Aは、PBI以外に多数のタスクを抱えていた最初のスプリントレビューができるまで3ヶ⽉かかった

Slide 29

Slide 29 text

スクラムの本格導⼊（2022/7 頃）スクラムフェス仙台2023 2023/8/26 29 • 開発者がスクラムを理解しないままスクラムイベントの運営するのは流⽯に無理が出てきた • 「みんなにスクラムをやってもらうしかない」 • NITをスクラム推進チームに • 福利厚⽣として、希望者にCSM取得を会社で⽀援 • 社外からアジャイルコーチ招聘

Slide 30

Slide 30 text

更に：フィーチャーチーム化スクラムフェス仙台2023 2023/8/26 30 • 4チームは担当コンポーネントごとに区切られたコンポーネントチーム • コンポーネントごとに開発要望が全く違っており、チーム内でトラックナンバーを上げただけでは負荷の偏りを是正できなかった • よってフィーチャーチームを作り、チーム間でPBIを交換可能にできるようにしていった • 1年近くかかった Auth&Pay agent PO SDK Service

Slide 31

Slide 31 text

ステップ１：2022/7ごろスクラムフェス仙台2023 2023/8/26 31 Service Auth&Pay • 新⼈が⼊ってくるタイミングで、 ServiceチームにいたSMが Auth&Payチームへ • 元々技術スタックの似ていた両チームの担当コンポーネントを共通化 • Serviceチーム → ServiceAチームに • Auth&Payチーム → ServiceBチームに ServiceA agent SDK 新⼈ ServiceB

Slide 32

Slide 32 text

ステップ２：2022/9〜12 スクラムフェス仙台2023 2023/8/26 32 ServiceA ServiceB agent • 度重なるインシデント対応でagent チームに負荷が集中 ⇓ • ServiceBチームが積極的にagentコンポーネントのPBIを取るように • 加えて、ServiceAチームには元々 agentチーム出⾝が多く、agentの PBIを担当できる能⼒があった SDK

Slide 33

Slide 33 text

ステップ３：2023/1〜3 スクラムフェス仙台2023 2023/8/26 33 • 同じコンポーネントを共有するagent チームとSDKチームを合併することに • 私とishiyさんで相談しつつ、３ヶ⽉かけて慎重に合併を進めていった • Ishiyさんが両チームのSMに • 両チーム間で、合併後のスクラムイベントその他の進め⽅を少しずつ協議、合意を取っていった • 本⽇13:30〜「モブコードリーディング」でishiyさんが話したのはこの頃の取り組み agent SDK Auth&Pay Service

Slide 34

Slide 34 text

"Dynamic Reteaming: The Art and Wisdom of Changing Teams" スクラムフェス仙台2023 • このとき参考にした書籍 • チームの分割、合併など、チームの再編時に取りうるべき対応を詳細に解説している

Slide 35

Slide 35 text

現在の姿スクラムフェス仙台2023 • 3つのフィーチャーチームによる LeSSライクな体制に • 全チームがすべての領域を担当可能に • 個⼈開発による担当領域や負荷の偏りはほぼ消滅 Penguin Owl PO Dodo (元 Service） (元 Auth&Pay） (元 agent ＋ SDK）

Slide 36

Slide 36 text

スクラムの導⼊〜matsuri technologiesの場合〜スクラムフェス仙台2023 2023/8/26 36

Slide 37

Slide 37 text

matsuri technologiesでの施策スクラムフェス仙台2023 2023/8/26 37 • プロダクトのユーザーごとに３チームに分割 • トラベラー1⼈ • ⼀部のプロダクトを統合 • ⼀般消費者向け（toC）チームにスクラムを導⼊ • 他のチームもtoCを参考にプラクティスを都度輸⼊ • 複数プロダクトを1チームで担当しているが、時期によってプロダクト単位の優先度を設定して今のところしのげている m2m-checkin Sumyca m2m-cleaning m2m-systems m2m-core m2m-inventory toC 現場対応システム系トラベラー

Slide 38

Slide 38 text

まとめスクラムフェス仙台2023 2023/8/26 38 • スタートアップでは個⼈開発からスタートし、強い個⼈分担制になりがち • PMFを過ぎてグロース期に⼊るところで問題が顕在化する • このタイミングでスクラム導⼊が役に⽴つ • チーム開発、協働、フィーチャーチーム ……ということを、Ideinとmatsuri technologies の事例を通してお話しました

Slide 39

Slide 39 text

最後に：スクラムの実証研究をしていますスクラムフェス仙台2023 2023/8/26 39 • インタビューを通じて、社会科学的な⼿法でスクラムチームの有効性を調査しています • いったい何が上⼿くいく要因なのか？を科学的に発⾒しようとしています • おまけで（必要なら）フィードバック、コーチングもします • もしご協⼒いただける⽅は、Discord or にDM or 現地で直接声をおかけください

Slide 40

Slide 40 text

ありがとうございましたスクラムフェス仙台2023 2023/8/26