CEOという武器を失った僕たちが得た、スクラムという武器

プロダクトづくりの壁を乗り越えた話 vol.2
https://productkintore.connpass.com/event/289364/
で発表させていただいた内容です。

スライド内イラストはこちら
https://loosedrawing.com/

---
Tebiki株式会社
https://tebiki.co.jp/
Tech Blog
https://techblog.tebiki.co.jp/

Transcript

1. CEOという武器を失った僕たちが 得た、スクラムという武器 Kazuaki Shibuya Tebiki, Inc. 2023/08/23 プロダクトづくりの壁を乗り越えた話 vol.2
2. 自己紹介 渋谷 和暁 2018.3 ～ Tebiki株式会社 CTO & Co-Founder 現在は「tebiki」開発チームの PO 兼 CTO として、 組織づくりとサービスづくりの両面で活動しています エンジニアの成長機会はリリースサイクルの計測にあった | Spreaker Deck https://speakerdeck.com/shibukk/enziniafalsecheng-chang-ji-hui-ha-ririsusaikurufalseji-ce-niatuta
3. about a year ago…
4. Howに注力していればよかった日々 解像度の高い CEO が、何をどの順番でやるべきかマイクロマネジメントしてく れている世界で、私たち開発チームは平和に過ごしていた CEO が決めてくれた仕様や優先順位にそって開発していけばうまくいくので、 CTO のマネジメントのもとで開発チームは How をいかに小さくリリースすれば よいかに注力さえしていればよかった（当時の TechBlog はこちら） https://techblog.tebiki.co.jp/speed-and-scope-de753ef83253
5. 開発チームの体制（2022.07頃） ※人数はイメージです
6. プロダクトがグロース期に CEO と CTO の二人三脚で開発をスタートさせたプロダクトが、グロースの フェーズにいよいよ突入してきた
7. 複数のプロダクトを提供して 課題の解決度合いをさらに高めたい
8. CEOが次の顧客課題に挑戦することに 顧客課題の解決度合いをさらに高めるために、今のプロダクトだけではなく 周辺の課題もあわせて解決する必要がある その第一歩として、次のプロダクトに挑戦するぞ！ と経営陣は意思決定をしたが…
9. CEOという武器を失った
10. マイクロマネジメントどうしよう
11. ドメインエキスパートだけでもなんとか🙏 マイクロマネジメントだけでなく、CEO が持っていた高いドメインへの解像度も 失ってしまうことを恐れて、仕様策定のときだけでも参加してほしいと打診 だが、プロダクトを横断した二足のわらじ状態になることで、新規プロダクトが うまくいかなってしまうことはうすうす感じていた
12. 新プロダクトを成功させるためにも CEO離れをしなければ…
13. スクラムとの出会い 開発チームに権限をもたせるスクラムなるものがあるらしい このフレームワークを使えば、これまで CEO がマイクロマネジメントでやって きた何をどの順番でやるべきかという部分も代替できるし、 スプリントレビューでドメイン観点でのアドバイスも 得れるのでは？ ↓ CTO がプロダクトオーナーになることに POやるぞ！
14. スクラムやってみた ぎこちなくも、スクラムガイドを頼りに走り出した （全員が「Professional Scrum Master I」というスクラムマスターの資格を 取ったりもした）
15. やったか!? PBIが可視化され、スプリントレビューでフィードバックをもらえる体制を作る ことができたぞ！
16. 実態はこうだった スクラムのルールからは逸脱していないが、 ・CEO と CTO とでやりたい機能の優先度付けをして、ベロシティから逆算して　 スプリントゴールを決めているだけ ・スプリントレビューでこういう機能をつくったんですよ～、と説明をするだけ という状態だった
17. マイクロマネジメントする人が 変わっただけじゃん
18. スクラムは銀の弾丸ではなかった それはそう 意思決定は CEO と CTO のままで、意思決定がなされた順番でバックログアイテ ムをスプリント内でこなしていくだけのチーム スクラムのルールがなぜそうなっているのか分からずに、スクラムに乗っかって いるKPTやプランニングポーカーといったプラクティスを、忠実に実行すること にのみ囚われているチーム
19. スクラムのプロセスがストレスフル 結果としてルールへの議論にのみ終始し、スクラムそのものがストレスフルなプ ロセスだとチームは感じ始めていた… それってルール的にどうなんでしょう？スクラムガイドでは こう書いてありそうですけど… ◯◯◯さんは3ポイントですが、△△△さんは2ポイントで どっちがより正確そうですかね？
20. サーベイから漂うもやもや感
21. アジャイルの価値観への気づき 　　　　　　　　　　　　　開発チームはアジャイルの価値観に基づいて 　　　　　　　　　　　　　意思決定がなされていないと、 　　　　　　　　　　　　　リーダーやメンバーから率直なフィードバックを 　　　　　　　　　　　　　もらって初めて気づいた 「われわれはアジャイルを実践できていない！」
22. そうだ…！
23. アジャイルソフトウェア開発宣言 に立ち戻ろう
25. プロセスやツールよりも個人と対話を ・プロダクトがどこに向かっていくべきかというビジョンを、ステークホルダー 　を巻き込んで定義し、なぜそれを目指すかチームと対話する ・PBI から逆算するのではなく、心から今のスプリントでやりたいと思えること 　を、スプリントゴールとしてチームに掲げて、チームと一緒に磨き込む ・ゴールを達成さえできれば、全ての PBI を完璧にこなさなくてもいいという、 　アウトカム主義をチームで徹底する ・仮説として持っているアウトカムが実現されているかを、スプリントレビュー 　の場でチームとステークホルダーが対話を通じて確認する
26. 価値についての対話に時間を使えるように アジャイルの価値観を理解した上で活動することで、スクラムの守破離における “守” を意識せずともできていることが多くなった （= ルールを守らねばという高ストレスから解放された） その結果、スクラムのルールを守れているかどうかに時間を使わずに、ユーザー にとって何が嬉しいの？という対話がチームでできるようになった
27. 「ユーザーの行動が全て」 振り返ってみると、Tebiki社の「ユーザーの行動が全て」、このバリューに賛同 する仲間を採用してきた つまり、顧客の価値を自分たちで考えられるメンバーが、すでに自分たちの 周りにいた
28. CEO個人の能力から Tebikiという組織全体の能力へ
29. 次の旅へ… サーベイでの気づきに対して、次のアクションをしていくリーダーたち（つづく）
30. We are hiring! プロダクトデザイナーを積極採用中です！ 「Tebiki 採用」でご検索ください🙌
31. 〒160-0023 東京都新宿区西新宿3-2-4 JRE西新宿テラス6F https://tebiki.co.jp/