Tweet
Tweet

Slide 1

Slide 1 text

CEOという武器を失った僕たちが 得た、スクラムという武器 Kazuaki Shibuya Tebiki, Inc. 2023/08/23 プロダクトづくりの壁を乗り越えた話 vol.2

Slide 2

Slide 2 text

自己紹介 渋谷 和暁 2018.3 ～ Tebiki株式会社 CTO & Co-Founder 現在は「tebiki」開発チームの PO 兼 CTO として、 組織づくりとサービスづくりの両面で活動しています エンジニアの成長機会はリリースサイクルの計測にあった | Spreaker Deck https://speakerdeck.com/shibukk/enziniafalsecheng-chang-ji-hui-ha-ririsusaikurufalseji-ce-niatuta

Slide 3

Slide 3 text

about a year ago…

Slide 4

Slide 4 text

Howに注力していればよかった日々 解像度の高い CEO が、何をどの順番でやるべきかマイクロマネジメントしてく れている世界で、私たち開発チームは平和に過ごしていた CEO が決めてくれた仕様や優先順位にそって開発していけばうまくいくので、 CTO のマネジメントのもとで開発チームは How をいかに小さくリリースすれば よいかに注力さえしていればよかった（当時の TechBlog はこちら） https://techblog.tebiki.co.jp/speed-and-scope-de753ef83253

Slide 5

Slide 5 text

開発チームの体制（2022.07頃） ※人数はイメージです

Slide 6

Slide 6 text

プロダクトがグロース期に CEO と CTO の二人三脚で開発をスタートさせたプロダクトが、グロースの フェーズにいよいよ突入してきた

Slide 7

Slide 7 text

複数のプロダクトを提供して 課題の解決度合いをさらに高めたい

Slide 8

Slide 8 text

CEOが次の顧客課題に挑戦することに 顧客課題の解決度合いをさらに高めるために、今のプロダクトだけではなく 周辺の課題もあわせて解決する必要がある その第一歩として、次のプロダクトに挑戦するぞ！ と経営陣は意思決定をしたが…

Slide 9

Slide 9 text

CEOという武器を失った

Slide 10

Slide 10 text

マイクロマネジメントどうしよう

Slide 11

Slide 11 text

ドメインエキスパートだけでもなんとか🙏 マイクロマネジメントだけでなく、CEO が持っていた高いドメインへの解像度も 失ってしまうことを恐れて、仕様策定のときだけでも参加してほしいと打診 だが、プロダクトを横断した二足のわらじ状態になることで、新規プロダクトが うまくいかなってしまうことはうすうす感じていた

Slide 12

Slide 12 text

新プロダクトを成功させるためにも CEO離れをしなければ…

Slide 13

Slide 13 text

スクラムとの出会い 開発チームに権限をもたせるスクラムなるものがあるらしい このフレームワークを使えば、これまで CEO がマイクロマネジメントでやって きた何をどの順番でやるべきかという部分も代替できるし、 スプリントレビューでドメイン観点でのアドバイスも 得れるのでは？ ↓ CTO がプロダクトオーナーになることに POやるぞ！

Slide 14

Slide 14 text

スクラムやってみた ぎこちなくも、スクラムガイドを頼りに走り出した （全員が「Professional Scrum Master I」というスクラムマスターの資格を 取ったりもした）

Slide 15

Slide 15 text

やったか!? PBIが可視化され、スプリントレビューでフィードバックをもらえる体制を作る ことができたぞ！

Slide 16

Slide 16 text

実態はこうだった スクラムのルールからは逸脱していないが、 ・CEO と CTO とでやりたい機能の優先度付けをして、ベロシティから逆算して　 スプリントゴールを決めているだけ ・スプリントレビューでこういう機能をつくったんですよ～、と説明をするだけ という状態だった

Slide 17

Slide 17 text

マイクロマネジメントする人が 変わっただけじゃん

Slide 18

Slide 18 text

スクラムは銀の弾丸ではなかった それはそう 意思決定は CEO と CTO のままで、意思決定がなされた順番でバックログアイテ ムをスプリント内でこなしていくだけのチーム スクラムのルールがなぜそうなっているのか分からずに、スクラムに乗っかって いるKPTやプランニングポーカーといったプラクティスを、忠実に実行すること にのみ囚われているチーム

Slide 19

Slide 19 text

スクラムのプロセスがストレスフル 結果としてルールへの議論にのみ終始し、スクラムそのものがストレスフルなプ ロセスだとチームは感じ始めていた… それってルール的にどうなんでしょう？スクラムガイドでは こう書いてありそうですけど… ◯◯◯さんは3ポイントですが、△△△さんは2ポイントで どっちがより正確そうですかね？

Slide 20

Slide 20 text

サーベイから漂うもやもや感

Slide 21

Slide 21 text

アジャイルの価値観への気づき 　　　　　　　　　　　　　開発チームはアジャイルの価値観に基づいて 　　　　　　　　　　　　　意思決定がなされていないと、 　　　　　　　　　　　　　リーダーやメンバーから率直なフィードバックを 　　　　　　　　　　　　　もらって初めて気づいた 「われわれはアジャイルを実践できていない！」

Slide 22

Slide 22 text

そうだ…！

Slide 23

Slide 23 text

アジャイルソフトウェア開発宣言 に立ち戻ろう

Slide 24

Slide 24 text

No content

Slide 25

Slide 25 text

プロセスやツールよりも個人と対話を ・プロダクトがどこに向かっていくべきかというビジョンを、ステークホルダー 　を巻き込んで定義し、なぜそれを目指すかチームと対話する ・PBI から逆算するのではなく、心から今のスプリントでやりたいと思えること 　を、スプリントゴールとしてチームに掲げて、チームと一緒に磨き込む ・ゴールを達成さえできれば、全ての PBI を完璧にこなさなくてもいいという、 　アウトカム主義をチームで徹底する ・仮説として持っているアウトカムが実現されているかを、スプリントレビュー 　の場でチームとステークホルダーが対話を通じて確認する

Slide 26

Slide 26 text

価値についての対話に時間を使えるように アジャイルの価値観を理解した上で活動することで、スクラムの守破離における “守” を意識せずともできていることが多くなった （= ルールを守らねばという高ストレスから解放された） その結果、スクラムのルールを守れているかどうかに時間を使わずに、ユーザー にとって何が嬉しいの？という対話がチームでできるようになった

Slide 27

Slide 27 text

「ユーザーの行動が全て」 振り返ってみると、Tebiki社の「ユーザーの行動が全て」、このバリューに賛同 する仲間を採用してきた つまり、顧客の価値を自分たちで考えられるメンバーが、すでに自分たちの 周りにいた

Slide 28

Slide 28 text

CEO個人の能力から Tebikiという組織全体の能力へ

Slide 29

Slide 29 text

次の旅へ… サーベイでの気づきに対して、次のアクションをしていくリーダーたち（つづく）

Slide 30

Slide 30 text

We are hiring! プロダクトデザイナーを積極採用中です！ 「Tebiki 採用」でご検索ください🙌

Slide 31

Slide 31 text

〒160-0023 東京都新宿区西新宿3-2-4 JRE西新宿テラス6F https://tebiki.co.jp/