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

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

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

※ スクラムフェス仙台2023 で登壇した際の資料です。

スタートアップでの開発形態は、ウォーターフォールに依存しがちなJTCと違って、プロダクトバックログやカンバンぽいものを使ったアジャイル風の開発をしていることが多いです。

しかし一方で、そういったスタートアップにはプロダクトバックログはあっても、たいていPBIの1つ1つがやたらでっかくて、1つ1つにしっかり担当者がアサインされてて、何ならデッドラインまで記されています。

これを引き起こすのは、スタートアップ特有の個人分担制です。
多くのスタートアップ企業はたいてい、エンジニア1〜2名からスタートし、個々のエンジニアの馬力で開発をこなしていくところから始まります。このときのバリバリ個人開発なノリが、エンジニアが増えても継続してガチガチの個人分担制に移行しがちです。

このセッションでは、個人開発をこじらせたスタートアップ企業がどうやって個人開発からスクラム流のチーム開発に移行すればいいのか、を、実際そういった傾向を持った複数のスタートアップ企業にアジャイルコーチ/スクラムマスターとして関わった経験を元にお話します。

Takeo Imai

August 26, 2023
Tweet

More Decks by Takeo Imai

Other Decks in Technology

Transcript

  1. 今井健男(ぼのたけ) スクラムフェス仙台2023 フリーランスアジャイルコーチ • スクラムの導⼊⽀援、改善 • プロダクトマネジメント⽀援 • 開発組織づくり、特にBiz/Dev連携⽀援 •

    ソフトウェア⼯学研究者 • 南⼭⼤学 ⾮常勤講師(冬だけ) • ⽇本ソフトウェア科学会 機械学習⼯学研究会(MLSE)主査 2023/8/26 2
  2. 本⽇のテーマ:スタートアップとスクラム スクラムフェス仙台2023 2023/8/26 3 実例として、私が社員として/外部委託のアジャイルコーチとして関わった • Idein株式会社 • matsuri technologies株式会社

    の2社での事例を、両社の同意のもとお話します (両社のご厚意に感謝します) また、ishiyさんによる 本⽇13:30〜 『モブコードリーディング 〜コンポーネントチームからフィーチャーチームを⽬指して〜』 は関連するIdeinでの取り組みです
  3. スタートアップと個⼈開発:草創期 スクラムフェス仙台2023 2023/8/26 6 • 多くの場合、エンジニアが1〜 2名 • 創業者が開発していたりする •

    しかし、開発アイテムはたん まり積まれている • MVPの概念は知られていない • 当然のように個⼈ベースの開 発になる 創業者CEO 兼 営業 創業者CTO 兼 エンジニア
  4. スタートアップと個⼈開発:ちょっと⼈が 増える スクラムフェス仙台2023 2023/8/26 7 • ⼿が⾜りないので、エンジニ アを何とか採⽤する • 構想しているプロダクトの未

    着⼿なところを丸ごとエンジ ニアに任せる • 各エンジニアには、⼤きな裁量 とともに担当が割り振られる • 担当は⼤きく分かれていて、1⼈ 1⼈の開発の独⽴性はかなり⾼い • → チームを作れる⼈数に達し ても、実質個⼈開発のまま 創業者 〇〇のとこ誰も⼿を付けて ないから、任せるわ 新⼈エンジニア は〜い
  5. 開発がスケールしない(と感じる) スクラムフェス仙台2023 2023/8/26 11 • 今まで、プロダクトを⼤きくし ながら成⻑してきた • 事業を⼤きくしたければ、プロ ダクトもスケールさせないとい

    けない!(と考える) • そのためにはエンジニアをもっ と採⽤しないと…… • 実は必ずしもそんなことはない • が、こう思わせる状況に追い込 まれている ⼈が⾜りない…
  6. 症状1:エンジニアを増やさないと 新しいことができない構造 スクラムフェス仙台2023 2023/8/26 12 • 今まで、⼈を増やし ては新規の箇所を担 当してもらっていた •

    同じ要領だと、⼈を 増やせないと新しい ことができない • 既にいるエンジニア はもう担当があり、 新しいことをやれな い …
  7. 症状1.5:1⼈あたりのメンテできる 担当規模は⼩さくなっていく スクラムフェス仙台2023 2023/8/26 13 • ⼈を増やしたところ で、1⼈あたりが担当 できる領域は徐々に ⼩さくなっていく

    • 1⼈が⾒渡して把握で きる範囲の相対的な 減少 • コミュニケーション コスト増⼤ • ⼈とプロダクト両⽅ のマネジメントコス ト増⼤ • etc. …
  8. 症状3:ホットスポット/コールドスポットの 発⽣ スクラムフェス仙台2023 2023/8/26 15 • 開発が⼀段落すると、 • 開発がまだまだ必要な 箇所

    (ホットスポット) • 安定して、追加の開発 があまり発⽣しない箇 所 (コールドスポット) が⽣まれる • エンジニアの負荷にバ ラツキが⽣まれ、⼀部 のエンジニアに負荷が 集中する PMF前 PMF後
  9. 症状4:リードタイムの⻑さが気に なり始める スクラムフェス仙台2023 2023/8/26 16 • ユーザー/顧客がつくと、 ステークホルダーからの 要望にどれだけ⾼いレス ポンスで応えられるかが

    求められる • しかし、クソデカPBIを 1⼈で担当していると、 リードタイムはなかなか 短縮できない = レスポンスが上がら ない
  10. Ideinの場合(〜 2021/12頃) スクラムフェス仙台2023 2023/8/26 17 Service Auth&Pay agent SDK •

    4チーム+マネージャー • 全体でプロダクトバックログ (のようなもの)1つ • チーム内でも担当領域がはっきり分 かれていて、事実上の個⼈分担制 • 特定のメンバーに負荷が集中 • チームをまたぐPBIを実施するためにい つも特定のメンバーばかりが稼働 • 更に、PBIを担当できるメンバーが誰か を探してアサインし、それぞれの進捗管 理をするコストも過⼤ マネージャー ※ 各チーム内の⼈数は適当です
  11. 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
  12. 今こそスクラムの出番 スクラムフェス仙台2023 2023/8/26 19 • チーム開発の導⼊ • トラックナンバーを上げ、SPOFをなくす • 開発者の流動性を上げ、ホットスポットに開発リソースを集中できるように

    • 分担から協働へ • 開発の量よりリードタイム優先 • ステークホルダーからの要望に対してなるたけレスポンスを上げる • 俗にいう「リソース効率よりフロー効率を重視」
  13. フロー効率重視の開発へ スクラムフェス仙台2023 2023/8/26 20 • PBIをこなすよりスプリントゴールを重視 • よくばったゴールにしない & PBIを沢⼭こなそうとしない

    • それより、設定したゴールを絶対達成するように • 達成しなかったら、次以降は着実に達成するよう徹底的に⼯夫・改善 • スプリントゴールを達成したら、そのスプリントの残りは何をしても良い • 協働(スウォーミング)の意識 • 「1つのタスクを複数⼈でやったっていい」 • ⾃分のやるタスクがなくなったら、ゴール達成のために他の⼈を⼿伝う • ゴール未達成の間はゴールに関係ないタスクに⼿を付けない • それで多少⾮効率だと感じても気にしない(フロー効率的にはそっちの⽅が速い) • 積極的な同期コミュニケーションの勧め「⼀緒にやったらどう?」 • ペアプロ/モブプロを直接勧めなくても、⾃然と皆がやるように
  14. スプリントバックログはかなり重要 スクラムフェス仙台2023 2023/8/26 21 • SBI/タスクを細かく分割する! • 個⼈開発前提での「ちょうどよい⼤きさ」は、フロー効率の観点からは⼤きすぎる • SBIが⼩さいほど協働はしやすくなる

    • いったん着⼿した後で他の⼈に⼿伝ってもらう分を切り出すのはかなり⼤変 • ⼩さく分けられないなら「⼀緒にやる」 • スクラムガイド2020 「スプリントプランニング 」トピック3 の説明: これは多くの場合、プロダクトバックログアイテ ムを 1 ⽇以内の⼩さな作業アイテムに 分解することによって⾏われる。 • PBIをそのままSBIにしてはいけない
  15. チーム開発体制への移⾏(2022/2) スクラムフェス仙台2023 2023/8/26 23 Service Auth&Pay agent NIT • Nexusベースの体制に

    • 全体で1⼈のPO、1つのPBL • 全体SM • 統合チーム(NIT) • ただし不完全 • 全体でのスクラムイベントは実施す る⼀⽅、各チーム内では「スクラム してもしなくてもいい」とした • 「トラックナンバー1の箇所をな くしてください」 PO SDK SM
  16. 最初は開発がまったく進まなかった スクラムフェス仙台2023 2023/8/26 24 • 当初はWIPがゆうに10を超えた • 最優先のPBIが全く進まなかった • あるスプリントで確認された状況

    • 最優先のPBIが1⼈の開発者Aに全部 任されていた • 開発者Aは、PBI以外に多数のタスク を抱えていた ⾃分のチームの最優先タスク 開発者A個⼈のタスクリスト
  17. 最初は開発がまったく進まなかった スクラムフェス仙台2023 2023/8/26 25 ⾃分のチームの最優先タスク 他チームから頼まれたタスク 他チームから頼まれたタスク 他チームから頼まれたタスク 他チームから頼まれたタスク 開発者A個⼈のタスクリスト

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

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

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

    彼だけができる専⾨のタスク 彼だけができる専⾨のタスク 開発者A個⼈のタスクリスト ・ ・ ・ ここだけしか ⼿を付けられな かった • 当初はWIPがゆうに10を超えた • 最優先のPBIが全く進まなかった • あるスプリントで確認された状況 • 最優先のPBIが1⼈の開発者Aに全部 任されていた • 開発者Aは、PBI以外に多数のタスク を抱えていた 最初のスプリントレビューができ るまで3ヶ⽉かかった
  21. スクラムの本格導⼊(2022/7 頃) スクラムフェス仙台2023 2023/8/26 29 • 開発者がスクラムを理解しないままスク ラムイベントの運営するのは流⽯に無理 が出てきた •

    「みんなにスクラムをやってもらうしか ない」 • NITをスクラム推進チームに • 福利厚⽣として、希望者にCSM取得を会社 で⽀援 • 社外からアジャイルコーチ招聘
  22. 更に:フィーチャーチーム化 スクラムフェス仙台2023 2023/8/26 30 • 4チームは担当コンポーネントごとに 区切られたコンポーネントチーム • コンポーネントごとに開発要望が全 く違っており、チーム内でトラック

    ナンバーを上げただけでは負荷の偏 りを是正できなかった • よってフィーチャーチームを作り、 チーム間でPBIを交換可能にできるよ うにしていった • 1年近くかかった Auth&Pay agent PO SDK Service
  23. ステップ1:2022/7ごろ スクラムフェス仙台2023 2023/8/26 31 Service Auth&Pay • 新⼈が⼊ってくるタイミングで、 ServiceチームにいたSMが Auth&Payチームへ

    • 元々技術スタックの似ていた両 チームの担当コンポーネントを共 通化 • Serviceチーム → ServiceAチーム に • Auth&Payチーム → ServiceBチーム に ServiceA agent SDK 新⼈ ServiceB
  24. ステップ2:2022/9〜12 スクラムフェス仙台2023 2023/8/26 32 ServiceA ServiceB agent • 度重なるインシデント対応でagent チームに負荷が集中

    ⇓ • ServiceBチームが積極的にagentコ ンポーネントのPBIを取るように • 加えて、ServiceAチームには元々 agentチーム出⾝が多く、agentの PBIを担当できる能⼒があった SDK
  25. ステップ3:2023/1〜3 スクラムフェス仙台2023 2023/8/26 33 • 同じコンポーネントを共有するagent チームとSDKチームを合併することに • 私とishiyさんで相談しつつ、3ヶ⽉か けて慎重に合併を進めていった

    • Ishiyさんが両チームのSMに • 両チーム間で、合併後のスクラムイベ ントその他の進め⽅を少しずつ協議、 合意を取っていった • 本⽇13:30〜「モブコードリーディン グ」でishiyさんが話したのはこの頃の 取り組み agent SDK Auth&Pay Service
  26. "Dynamic Reteaming: The Art and Wisdom of Changing Teams" スクラムフェス仙台2023

    • このとき参考にした書籍 • チームの分割、合併など、チームの再編時に 取りうるべき対応を詳細に解説している
  27. matsuri technologiesでの施策 スクラムフェス仙台2023 2023/8/26 37 • プロダクトのユーザーごとに3チーム に分割 • トラベラー1⼈

    • ⼀部のプロダクトを統合 • ⼀般消費者向け(toC)チームにスク ラムを導⼊ • 他のチームもtoCを参考にプラクティス を都度輸⼊ • 複数プロダクトを1チームで担当して いるが、時期によってプロダクト単位 の優先度を設定して今のところしのげ ている m2m-checkin Sumyca m2m-cleaning m2m-systems m2m-core m2m-inventory toC 現場対応 システム系 トラベラー
  28. まとめ スクラムフェス仙台2023 2023/8/26 38 • スタートアップでは個⼈開発からスタートし、 強い個⼈分担制になりがち • PMFを過ぎてグロース期に⼊るところで問題が顕在化 する

    • このタイミングでスクラム導⼊が役に⽴つ • チーム開発、協働、フィーチャーチーム ……ということを、Ideinとmatsuri technologies の事例を通し てお話しました