Regional Scrum Gathering Tokyo 2024 (RSGT2024) で、ゆのんさんと一緒に登壇してきました。
資料
https://speakerdeck.com/kakehashi/develop-a-new-product-with-bad-practices
話したこと
ゆのんさんがエンジニアリングマネージャ兼スクラムマスター、僕がフルスタックエンジニアとして4人のチームを作って、新規プロダクトの立ち上げにスクラムで取り組んだ。
その中で、Badプラクティスと呼ばれる「あまりやらないほうがいいと言われていること」も選んで開発に取り組んだのだけど、どうしてそんなことをしたのかってお話。
新規開発と見積もり
今回はReadyになるのを待たずに、見積もりをせずに開発に取り組んだ。
新規開発って、分かっていないことがたくさんあるし、開発を進める中でも新しい情報がどんどん入ってくる状況。（しかも今回は、ゆのんさんも僕も入社したてだし、新しく立ち上がったチームだし、僕にとっては新しい技術ばかりだったので、何から何まで分かっていないという状況）。
そんな「分かっていないこと」がたくさんある状況では、まず、しっかり調査をして情報を集めて、「Readyになった！」ってなってから、見積もりをして予定を立てて、開発に入る、という流れかなと思う。そうすると、先の見通しもある程度立つし、安心・安全に進められそう。
ただ、このやり方は、時間がかかっちゃうなぁと。それに、開発を進めていく中でどんどん入ってくる新しい情報への対応が、少し遅れてしまう。
進め方が安心・安全、よりも、よりよいプロダクトをいちばん速い方法で届けることに挑戦したいなと思ったので、今回は、Readyになるのを待たずに、見積もりをせずに、調査と実装に突入することにした。
見積もり
特に新規開発みたいに「分かっていないこと」が多い状況って、こまかな見積もりをする意味があんまりないなと思っている。どうせ当たらない。
むしろ、見積もりをしてしまうことで良くない流れになることもある。見積もりに引っ張られて実装が雑になってしまったり、より良い方法が見つかったのにそれをするべきかどうかを考えるんじゃなくて「見積もりどおりに進まないから」という理由でそれをやらなかったり。
僕らは、見積もりよりプロダクトのことを見ていたいよね。見積もりが当たったか当たらなかったかではプロダクトは良くならない。より良いプロダクトを作ることが、このチームでやりたいことだよね。だからそっちを見ようよって気持ち。
そもそも、見積もりをしてもしなくても、僕らの持っている力でひたすら前に進むのは変わらない。そう考えると、今回はReadyになるのを待たずに、見積もりをせずに取り組む方がいいなってなった。
でも、マネージャにはつらそう
といっても、見積もりがないと、不安と危険の中を進むことになる。この状況は特にマネージャにとってはつらそう。
だから、ゆのんさんに「見積もりがないとマネージメントが難しくなるし、調査しながらの実装だから『できるかどうか分からない』って状態がしばらく続いて、不安を抱えながらになると思うんだけど、どう思う？」って聞いてみた。
そしたら「椎葉さんがいちばんいいと思うやり方でやろうよ。マネージメントは任せて」って迷いなく返事してくれて、やったー！ってなったのだった。
開発中は、エンジニアが開発に集中できるようにって、ゆのんさんが自分で集められる情報はデイリースクラムなどで集めてくれたり、GitHubのコードを自分で見にいってくれたりとかしてくれてたので、とても助かった。
追加開発と見積もり
セッションの中では時間の関係で触れられなかったけど、新規開発が終わって、追加開発に切り替わるタイミングでは、見積もりとまではいかないけど、ある程度予測を立てながら進めるスタイルに切り替えた。
「分かってないこと」が少なくなってるから「それなら2,3日でできます」とか「2週間くらいかな」とか言って進めてる。
全体マップ
見積もりはしないことにしたけど、全体の認識合わせは必要だと考えたので、全体マップを作った。
機能のレーンを並べて、先につくるものを上に、後でつくるものを下に置いていって、ユーザーの体験がどうなるかを見ながらみんなで上下させたりして、認識を揃えた。ユーザーストーリーマッピングに似たやり方。
新規開発と全体マップ
特に新規開発では、プロダクトマネージャ目線の上下の並び替えだけでなく、どういう順番で作るべきかというエンジニア目線の上下もとても重要になる。
今回でいうと、プロダクトマネージャはログイン機能を先に作る必要があると思ってくれていたけど、エンジニアから「そこはモックにしておいて、まずは機能の実現可能性を見るほうがよさそう」と、メインの機能を上にしたりした。ログイン画面は、技術的な不確実性が少ないから、後でも大丈夫というエンジニアの判断。
そんな風に、プロダクト視点とエンジニア視点の両方から、ユーザー体験の物語とプロダクト開発の物語を作っていった。
エンジニア目線のタスクを追加
ユーザーストーリーのマッピングが終わったら、これも新規開発特有かなと思うんだけど、土台作りとリリース前のあれこれをどーんとマップに追加した。
そうすると、MVP全部を開発するのは難しそうだねってなって、MVPをさらに削って、MVPの中のMVPというラインを決めた。このラインまで開発ができていなかったらリリース日を延期する、というライン。
そして開発へ・・・
いや、まだ前半だこれ。こんなに詳しく書くつもりなかったｗ
このあと、リスケをしたり、毎日のデイリースクラムでプランニングをしたり、見積もりがないぶんスプリントレビューで動くものを見せることをエンジニア2人がめちゃくちゃ意識してたり、予定より遅れてるのにバックエンドを2.5回くらい作り直したりしてた話をしました！（突然、雑）
エンジニアリングマネージャとしてどういうチームづくりをしたかや、リスケのハンドリングなどの話もあったりして、面白い内容だったなぁと思います。
RSGTで登壇できて楽しかった！2024年が始まりました！
