新規事業立ち上げ、グロースで きちんと”デリバリー”も"ディスカバリー"も し続けられるアジャイル組織の作り方

2024/06/22 スクラムフェス大阪 2024 登壇資料

Transcript

1. 2024/06/22 @Scrum Fest Osaka 2024 松雪 俊 新規事業⽴ち上げ、グロースで きちんと”デリバリー”も”ディスカバリー”も し続けられるアジャイル組織の作り⽅
2. ⾃⼰紹介 2 松雪 俊（マツユキ タカシ）/ @applepine1125 BASE株式会社 BASE BANK Division (「BASE」の⾦融決済領域) のEM of EMs 開発組織全体を⾒たり新規プロダクトの開発リードしたり⾊々やってます
3. BASE, BASE BANKについて 3 個⼈‧スモールチーム等のショップ向け ショップオーナー向けにネットショップ作成サービス「BASE」、スタートアップ向けにオンライン決済サービス「PAY.JP」、 マーチャント向けに⾦融サービス「YELL BANK」をはじめとした複数サービスを提供しています。 決済⽀援 ‧ ショップ作成⽀援 誰でもかんたんにストアフロント型の ネットショップを無料で作れる ネットショップ作成サービス スタートアップ等の加盟店向け 決済⽀援 Webサービスにクレジットカード決済を かんたんに導⼊できる開発者向けの オンライン決済サービス マーチャント向け マーチャント向け⾦融サービス マーチャント向けに ⾦融サービスを提供するチーム
4. BASE, BASE BANKについて 2012年12⽉ BASE株式会社 設⽴ 2018年4⽉ 開設数 50万ショップ突破 2019年10⽉ 東証マザーズに上場 2020年5⽉ 開設数 100万ショップ突破 2021年6⽉ 開設数 150万ショップ突破 2022年1⽉ BASE BANK社を吸収合併 2018年 2019年 2020年 2021年 2022年 2018年1⽉ BASE BANK株式会社 設⽴ 2018年12⽉ 「YELL BANK」提供開始 2020年2⽉ 「お急ぎ振込」提供開始 2021年9⽉ 「BASEカード」提供開始 お急ぎ振込 BASEグループ内にて新たに⾦融サービスを⽴ち上げるため、BASE BANKが誕⽣しました。 6年以上にわたり、SMBにおける資⾦繰り課題の解決に取り組み続けるために⾦融サービスの開発‧提供を⾏っています。
5. 本発表で伝えたいこと 複数プロダクトの新規⽴ち上げ、グロースをしてきた経験をもとに “デリバリー”と“ディスカバリー”の両輪をどう回してきたかをお伝えし、 プロダクトに関わるすべての⽅々の新たなチャレンジの後押しができれば幸いです。 5
6. ”デリバリー”も”ディスカバリー”も し続けられるアジャイル組織とは?
7. デリバリーできる組織? ソフトウェアデリバリのパフォーマンスは組織全体の業績に影響する Nicole Forsgren / LeanとDevOpsの科学 少ない時間、少ないリソース、⼩さい予算で無駄なくアウトプットする 打席に⽴つ回数を増やすことができる 7 アウトプット 時間 1stリリース 1stリリース 2ndリリース 5thリリース 短いデリバリーサイクル ⻑いデリバリーサイクル 1回のアウトプットは⼩さくても、 時間軸が⻑くなるほどトータルの アウトプットは⼤きくなる
8. ディスカバリーできる組織? リーン‧スタートアップでは、スタートアップが⾏うことを「戦略を検証する実験」としてとらえなおす。戦 略のどの部分が優れていてどの部分が狂っているのかを検証する実験だ。 Eric Ries / The Lean Startup アウトカムを最⼤化するための探索、実験を⾼速で⾏える。 検証を起点としたプランニングと実⾏を⾏い続けることができる。 8 価値 時間 1stリリース 2ndリリース 3rdリリース 4thリリース ディスカバリーサイクルを回せている ディスカバリーサイクルを回せていない 仮説検証のサイクルがうまく回っていれば、 経験を価値に変えられる。 回せていないと⽬指すべき⽅向がわからない
9. “デリバリー”も”ディスカバリー”もできる組織? いわゆるデュアルトラックアジャイルのイメージ。 デリバリー: 予測可能性、システム品質、ベロシティの最⼤化を重視する ディスカバリー: 迅速な学習と検証を重視する BASE BANKでは⾼速な仮説検証のサイクルを追い求めたら結果的にデュアルトラックアジャイルっぽく なっていった。 9 https://jpattonassociates.com/dual-track-development/
10. “デリバリー”も”ディスカバリー”もできる組織? エンジニアリング的なデリバリーが必ずセットというわけではない。 ソフトウェアを作らずに検証できるものがあればやればよい。(ユーザーインタビューなど) どちらも柔軟にタイムボックスを設けて迅速に⽬的を達成できるようにする。 ディスカバリーフェーズ、デリバリーフェーズと⼀連の⼯程があるわけではない。あるのは継続的なサイクル。 10 https://jpattonassociates.com/dual-track-development/
11. デュアルトラックアジャイルの現実 短い時間軸で⾒ると結果的にディスカバリーフェーズ→デリバリーフェーズとなりうる。 - 両輪をどんな時間軸でも絶対同時に回さないといけないんだ！なんてことはない - 中⻑期的な時間軸でそれぞれのサイクルが継続して回っていることが⼤事 11 ミクロに⾒てみると‧‧‧ 仮説検証A 仮説検証B 時間 ディスカバリー ディスカバリー デリバリー
12. デュアルトラックアジャイルの現実 タイムボックスのサイズは状況によって変わりうる。 - “Discovery work uses irregular cycle lengths. It’s “Lean” in that we’re trying to make the discovery cycle as short as possible. “ - Dual Track Development is not Duel Track - ディスカバリーのタイムボックスは仮説検証の内容によって異なる - BASE BANKではデリバリーサイクルも状況によって変えたりする。リズムは作るがn週間1スプリントに とらわれない。 - ⽂字通りの”デリバリー”だけでなく、他職能とのsync、チェックポイントとしてのサイクル。振り返りと 向き直しのためのイテレーション。 12 よく⾒るとこの図も ディスカバリーサイクルの ⼤きさが異なる ⽴ち上げ時期は 不確実性も多いので 細かくイテレーションを リリース前は ⼤体バタバタするので、 柔軟に対応できるよう 細かくイテレーションを 安定してきたら サイクルをちょっと⼤きめに 時間
13. デュアルトラックアジャイルの現実 状況によってディスカバリーとデリバリーの⽐重は変わる - 0->1のタイミングではディスカバリーの⽐重がより⼤きい - 検証⽅法の⼿札の⼀つとして開発がある、そんなイメージ - デリバリーは仕組みじゃなくて気合、みたいな場⾯も正直ある 13 時間 時間 ⽴ち上げ期 ディスカバリーの⼿段としてのデリバリーという⽴ち位置。 ミニマムに。運⽤でカバーするケースも。 グロース期 継続的かつより⾼速にデリバリーのサイクルを 回していくための投資も増えていく。 気合じゃなくて仕組みとして整えていく。 ディスカバリー デリバリー
14. "デリバリー”と”ディスカバリー”の実現のために スクラムフレームワークは意図的に不完全なものであり、スクラムの理論を実現するために必要な部分のみが 定義されている。スクラムは実践する⼈たちの集合知で構築されている。スクラムのルールは 詳細な指⽰を提 供するものではなく、実践者の関係性や相互作⽤をガイドするものである。 スクラムガイド エンジニアとしては、デリバリーはスクラムや開発⽣産性などどうやってカイゼンのサイクルを 回していけばいいかイメージつきやすい イメージが付きやすいと逆にそのサイロの中に無⾃覚のうちにこもってしまう可能性がある。 あくまで仮説検証がメイン。 スクラムなど様々なプラクティスを、サイクルを回すための⼿札として持っておくことはよい。 課題解決のためのアプローチであることを忘れた状態でスクラムガイド通りに回そうとしてはいけない。 14
15. "デリバリー”と”ディスカバリー”の実現のために 実現するには? 15 https://speakerdeck.com/base/basebank
16. "デリバリー”と”ディスカバリー”の実現のために 実現するには? - フルサイクル - ソフトウェアのライフサイクル全体に関わり改善することで、デリバリーのサイクルをより⾼速に回す - 越境 - ディスカバリーとデリバリーの接合には職能やレイヤーを超えた越境が最重要 - 早期から越境しあい、サイロ化しないようにする。 - オーナーシップ - 各⼈が⽬標に対して周りを巻き込みながら意思決定し続けるためにはオーナーシップが不可⽋。⾃分の仕 事のリーダーは⾃分。これがないと改善のサイクルも誰かに回してもらっている状態になってしまう。 16
17. "デリバリー”と”ディスカバリー”の実現のために このあたりの考え⽅は”みんなでアジャイル”の影響を強く受けています 17 https://speakerdeck.com/applepine1125/jun-tatihadouyuzatoxiang-kihe-uka-44b631d1-1037-41b8-b375-50d45cc2b4b5?slide=14
18. 過去経験したケース: 0->1 でのチームのアドリブ⼒ 18
19. PAY.JP YELL BANKの⽴ち上げ (6/18にプレスリリース出したばかり!) チーム⼈数: BASE BANK: エンジニア 3, デザイナー 1, PdM 1, PMM 1 PAY社: エンジニア 1, PdM 1, マーケ 1 グループ会社も巻き込んだ新規プロダクト⽴ち上げ コミュニケーションの接点をとにかく増やした 過去経験したケース: 0->1 でのチームのアドリブ⼒ 19 https://pay.jp/yellbank
20. 過去経験したケース: 0->1 でのチームのアドリブ⼒ ディスカバリーで⼤事にしたこと - サイクルを回し始めるための呼び⽔ - まずは⼀歩、確実にディスカバリーのサイクルを回し始められるようにFBをもらう相⼿を決める - ミニマムにテストするために「PAY.JP」加盟店の中からテストユーザーとして協⼒してもらう。 - その先のサイクルを意識した仕込み - 他プロダクトでの仕組みづくりを通じてLookerの⺠主化が進んでいたので、データ連携などをエンジニア が、ダッシュボード作成はbizが、と協⼒しあい継続的なディスカバリーサイクルを回す準備を。 20
21. 過去経験したケース: 0->1 でのチームのアドリブ⼒ デリバリーで⼤事にしたこと - まずはベストエフォート - ⾒積もりはざっくり規模感すり合わせるくらい。ベロシティ計測は全くしない。 最初は調査などスパイクタスクが多いので、細かくsyncするタイミングを決めて壁打ち、 意思決定を繰り返す。リズム作るためにスプリントは回し始めるがタイムボックスは柔軟に。 - ちょっとずつコミットメント - 予測可能性が上がってきたらコミットメントのためのスプリントゴールを設定し、常にスコープ調整も できるように やってみながらやりやすい⽅法を探っていこう、くらいのノリ。⼩さくたくさん学ぶためのアドリブ⼒ 21
22. 過去経験したケース: 1->10 での仕組みづくり 22
23. 過去経験したケース: 1->10 での仕組みづくり BASEカードのグロース チーム⼈数: エンジニア 2~3, デザイナー 1, PdM 1, PMM 1 リリースして約3年。1年前までBASEカードの devチームリーダーを兼任。 キャンペーンや改善、新機能追加など、 よりPJ然とした動きが増えてくる 23 https://basecard-lp.thebase.com/
24. 過去経験したケース: 1->10 での仕組みづくり ディスカバリーで⼤事にしたこと - より具体的な数値⽬標を持った仮説検証を回す - LookerなどBIツールの重要性が更に⾼まる。その整備やカイゼンなども明⽰的に⾏う - 事業成⻑のための新たな仮説とそれを実現する新機能が本当に刺さるのか、ターゲットの解像度を 上げるためにユーザーインタビューを⾏いコンパクトにディスカバリーのサイクルを回す - ちゃんとPRD(プロダクト要求仕様書)を書き始めたり、よりドキュメンテーションにも注⼒ 24
25. 過去経験したケース: 1->10 での仕組みづくり デリバリーで⼤事にしたこと - 越境、相互の関⼼を促し、仕事の⽬的をきちんと浸透させる仕組み、場作り - Design DocやADRなどを導⼊し、意思決定の背景や根拠を広く明確に - 組織のスケールのために他職能にどこまで任せ、どこまで巻き込んでもらうかの線引を探索する - コミットメントを通じた信頼貯⾦ - 技術的な改善課題も出てき始める。説明責任だけでなく”あなたがいうならうまく調整しよう” と思ってもらえる信頼貯⾦も⼤事。 ゴールへの深い理解とコミットメントのため、プランニングやリファインメントの整備を進めていく 振り返りや仕事のsyncなどを通したサイロ化の脱却、学び続けられるような場作りを⼼がける 25
26. 10からその先へ、組織のこれから
27. 10からその先へ、組織のこれから 組織全体としては各事業を成⻑させつつ、新たな事業の⽴ち上げも。 事業的にアクセルを踏み続ける限り、仮説検証のサイクルの速度はむしろ上げていきたい。 組織全体が⼤きくなっても意思決定の中核を担うチームは最⼩に。 とはいえずっと広くフルサイクルにやり続ける難しさは感じ始めた。 27 https://speakerdeck.com/base/basebank?slide=12
28. 10からその先へ、組織のこれから ディスカバリーで⼤事にしていきたいこと - ディスカバリーのサイクルを並列でもっと回せるように。 - 中⻑期的な事業戦略から解像度⾼く施策などをブレイクダウンし各ディスカバリーサイクルを回せる⼈を もっと増やしていきたい。 デリバリーで⼤事にしていきたいこと - 事業のスケールに伴い、監視基盤の強化の必要性やメンバーのスキルセットの偏りによる特定領域の仕事 の⼼理的ハードルが。(BANK dev 全体としては⽐較的FEが弱いです!助けて!)。 - 事業のスケール、横展開に対して⼈が⾜りてない！チーム横断的なタスクを⼿分けしながら拾ってやって いるが、もうちょっと無理なくやれないものか。模索中。 28
29. 10からその先へ、組織のこれから どのフェーズでも結局これが必要。どこまでやれるかは挑戦。 29 https://speakerdeck.com/base/basebank
30. まとめ ⼤事なのは 越境、フルサイクル、オーナーシップ ありたい姿や課題と向き合って 乗り越えていける仲間がもっと増えたら嬉しい！ 30
31. We are Hiring! 31 https://herp.careers/v1/base/xp7TzNC89ZfT https://speakerdeck.com/base/basebank カジュアル⾯談 BASE BANK紹介資料