Badプラクティスを選んで失敗しながら進めた新規プロダクト開発/Develop a new product with bad practices

Transcript

1. 日本の医療体験を、しなやかに。 © KAKEHASHI Inc. Badプラクティスを選んで失敗しながら 進めた新規プロダクト開発 2024.01.10 @ Regional Scrum Gathering Tokyo 2024 湯前慶大　椎葉光行
2. © KAKEHASHI Inc. いきなり質問 新しいプロダクト開発の立ち上げを 経験したことある方ー？
3. © KAKEHASHI Inc. はじめに 本題に入る前に・・・ • 新規開発の話をあまり聞いたことない • ふりかえってみると、成功のためにBadプラクティスを選択していた → 実践例として、コミュニティに還元出来るのでは？
4. © KAKEHASHI Inc. 自己紹介 湯前 慶大 (@yunon_phys) • VP of Engineering 兼 Engineering Manager • カケハシ(2023年3月〜) • ビール、チーズ、ワインが好き • 子どもが生まれて、てんやわんやな 日々を過ごす 椎葉 光行 (@bufferings) • フルスタックエンジニア • カケハシ（2023年4月〜） • RSGT2021登壇 • Scrum Osaka 2021キーノート • コーヒー、ビール、ラーメンが好き
5. © KAKEHASHI Inc. カケハシの紹介 Mission 日本の医療体験を、しなやかに。 Vision 明日の医療の基盤となる、エコシステムの実現。
6. © KAKEHASHI Inc. カケハシの紹介
7. © KAKEHASHI Inc. 本セッションの前提 今日の話はこんな背景があるよ • 2023年4〜10月の話 • 薬局向けの新規プロダクト、3月に出来たばかりの新しいチーム • フルリモート
8. © KAKEHASHI Inc. Badプラクティス？ どんなBadプラクティスをやったのか？ • Readyを待たない • 見積もりをしない • スプリント内でタスクが終わらない • 仕掛中のユーザーストーリーがたくさんある
9. 新規開発とスクラム なぜ、見積もりをしないことにしたのか 見積もりの代わりに何をしたのか 遅れられない！ わかるー！
10. © KAKEHASHI Inc. 新規開発とスクラム 新規開発 開発中にも新しい情報がたくさん！ 分かっていないことがたくさん！ 前もってきっちり決めてもうまくいかない！
11. © KAKEHASHI Inc. 新規開発とスクラム 新規開発とスクラム 調査用のスプリントを実施 わりと好き！ 1. 調査する 2. Readyになる 3. 見積もりをする 4. 実装する 5. 繰り返す
12. © KAKEHASHI Inc. 新規開発とスクラム 新規開発とスクラム Readyになるのを待たない これに挑戦したいなー！ 1. 調査する 2. Readyになる 3. 見積もりをする 4. 実装する 5. 繰り返す
13. © KAKEHASHI Inc. 新規開発とスクラム どう思う？ いいね！やってみよう！
14. © KAKEHASHI Inc. 新規開発とスクラム Readyを待たない・見積もりをしない開発 「分かっていないこと」を解決しながら「新しい情報」にも素早く対応するぞー！
15. © KAKEHASHI Inc. 新規開発とスクラム 全体マップづくり
16. © KAKEHASHI Inc. 新規開発とスクラム 全体マップづくり
17. © KAKEHASHI Inc. 新規開発とスクラム ユーザーストーリー以外のタスク インフラ構築や 技術選定など 全体のテストや 本番環境の準備など
18. © KAKEHASHI Inc. 新規開発とスクラム え？１ヶ月？ みじかっ！！！ ユーザーストーリー以外のタスク インフラ構築や 技術選定など 全体のテストや 本番環境の準備など
19. © KAKEHASHI Inc. 新規開発とスクラム MVPをスライス
20. © KAKEHASHI Inc. 新規開発とスクラム 全体マップ
21. チーム作りの話 ドリームチーム！ どんなチーム作ったの？
22. © KAKEHASHI Inc. 役割について 湯前のチームにおける役割 Engineering Manager(EM) 兼 Scrum Master(SM) EM = 組織の構築・成長に責任を持つ → 人を集めて開発体制をつくる SM = スクラムの推進・改善に責任を持つ → 集めた人で開発を進める・改善する
23. © KAKEHASHI Inc. チームコンセプト こんなチームにしたい “良いチームが良いプロダクトを作る” を体現するドリームチーム ↓ 技術力 × 顧客価値
24. © KAKEHASHI Inc. 採用基準 どんな人をチームに入れるべきか？ 新規開発において重要なこと → 開発コストを可能な限り抑えること 1. コミュニケーションが円滑に出来ること(コミュニケーションコスト) 2. フルスタックに活躍出来ること(人件費、コミュニケーションコスト) 3. 技術力が高いこと(技術的負債、安定性、コミュニケーションコスト) 特に開発初期の段階は どっちに進めば良いかわからない・・・
25. © KAKEHASHI Inc. 開発チーム 船に乗った人たち EM/SM Eng Eng PdM
26. © KAKEHASHI Inc. 開発チーム 船に乗った人たち 大丈夫です！！ EM/SM Eng Eng PdM 人数を増やさなくて 大丈夫ですか？
27. © KAKEHASHI Inc. 開発チーム 船に乗った人たち うまくいかなかったら どうしよう EM/SM Eng Eng PdM 人数を増やさなくて 大丈夫ですか？
28. © KAKEHASHI Inc. ここまでEngineering Managerとしての話 ここからScrum Masterとしての話
29. © KAKEHASHI Inc. チームコンセプト こんなチームにしたい “良いチームが良いプロダクトを作る” を体現するドリームチーム ↓ 技術力 × 顧客価値
30. © KAKEHASHI Inc. チームコンセプト Scrum Masterとしてやったこと チームの置かれる状況の変化に合わせて チームの動きを変化させていく
31. © KAKEHASHI Inc. 4つのフェーズ リリースまでの4つのフェーズ 立ち上げ期 (4〜5月) リズム形成期 (6〜7月) 機能量産期 (7〜8月) リリース 準備期 (9〜10月) チームの状況を見ながら滑らかに変化
32. © KAKEHASHI Inc. 立ち上げ期 立ち上げ期(4〜5月) 課題 やることが不明瞭 どんな技術を使う？ 得られたこと 漏れ・だぶりない調査 ゴールまでの道筋 調査のタスク化 情報の透明性担保 やったこと
33. © KAKEHASHI Inc. 課題 どれぐらいで 開発できる？ 得られたこと 間に合わない という理解 おおよその見積もり 目の前の開発推進 やったこと リズム形成期 リズム形成期(6〜7月)
34. © KAKEHASHI Inc. 課題 機能開発以外の タスクが山積み 得られたこと 開発スピード安定 タスクが終わってく 機能開発以外は スクラムマスターが 巻き取る！ やったこと 機能量産期 機能量産期(7〜8月)
35. © KAKEHASHI Inc. 課題 予期せぬ不具合や 考慮不足の発生 得られたこと リリース前に 不具合見つけた！ バッファを設ける 普段から気になりを 話せるように やったこと リリース準備期 リリース準備期(9〜10月)
36. © KAKEHASHI Inc. 4つのフェーズ リリースまでの4つのフェーズ 立ち上げ期 (4〜5月) リズム形成期 (6〜7月) 機能量産期 (7〜8月) リリース 準備期 (9〜10月) チームの状況を見ながら滑らかに変化
37. Badプラクティスを選んで進めた新規開発 1. Readyを待たない・見積もりをしない 2. スプリント内でタスクが終わらない 3. 仕掛中のユーザーストーリーがたくさんある このパートはモジモジ（文字文字）してるよー！
38. © KAKEHASHI Inc. Badプラクティスを選んで進めた新規開発 Readyを待たない・見積もりをしない 例：土台作り • 分かっていないことだらけの中で毎週違う課題に飛び込んだ ◦ Terraform + AWS、コンテナ実行環境の構築、GitHub Actionsで自動デプロイなど ◦ 調査→実装の素早い繰り返しで作り上げた ◦ 見積もりが可能になったときには実装が終わってる • 実装してみて気づいたことにも、その場で対応 ◦ 例：ARM64 DockerイメージのビルドはAWS CodeBuildに逃した それによって • 新しい情報にも対応しつつ、一番速い方法で土台を構築できた
39. © KAKEHASHI Inc. Badプラクティスを選んで進めた新規開発 スプリント内でタスクが終わらない そもそも、スプリント（１週間）という区切りを気にしないことにしてた • やることをTODOに並べておいて、全力で１つずつ終わらせていくことに集中 • スプリント（１週間）は、日々状況が変わる新規開発には長すぎる • デイリースクラムで今日は何をするのがいちばんいいかを毎朝チームでプランニング • だから、スプリント終わりでタスクが残っていても気にしない それによって • スプリントという区切りは気にせずに、今日何をするべきかを大切にしていた じゃあスクラムじゃなくていいのでは？ ってのには後でふれるからちょっと待ってね
40. © KAKEHASHI Inc. Badプラクティスを選んで進めた新規開発 仕掛中のユーザーストーリーがたくさんある バックエンド開発：２回実装するほうがいいと判断 • １回目：技術的に実現可能かどうかを素早く確認するための最小の実装 ◦ １メソッドに全部を詰め込んで動作検証・エラー処理なし・ロギングなし ◦ １回目の実装が終わった段階では、すべてのユーザーストーリーが仕掛中 • ２回目：本番環境で使えるレベルで実装しなおし ◦ どのロジックをどこに置くべきかなどの構造を整備 ◦ エラー処理やロギングの設計と実装 それによって • 実現可能性を早い段階でチェックできた・全体を見ながら本番レベルの実装ができた
41. © KAKEHASHI Inc. Badプラクティスを選んで進めた新規開発 Badプラクティスを選んで進めた新規開発 1. Readyを待たない・見積もりをしない → 飛び込んで素早く実装するため 2. スプリント内でタスクが終わらない → 日次でプランニングをしていたため（スプリントを気にしなかった） 3. 仕掛中のユーザーストーリーがたくさんある → ２回実装することにしたため ただ、Badプラクティスは一歩踏み外すと危ない・・・
42. © KAKEHASHI Inc. Badプラクティスを選んで進めた新規開発 毎週のスプリントレビューで「動くモノ」を見せる これをエンジニア２人は、めちゃくちゃ意識してた • 開発の区切りとしてのスプリントは気にしなかったけど • レビューの区切りとしてのスプリントをとても意識していた • 言葉ではなく動くモノで見せる ◦ 何ができていて、何ができていないのかをハッキリさせるため それによって • 毎週チームで全体マップを見ながら現在地を更新できた ふりかえりも毎週やってたし スクラムはいいなぁってなった
43. © KAKEHASHI Inc. Badプラクティスを選んで進めた新規開発 動くモノ・新しい情報・方針転換 フロントエンドは早い段階で動くモックを見せていた • プロダクトマネージャが薬局を訪問（※薬局向けのプロダクトなので） ◦ 画面のモックを触った感触＋実際に見てきた薬剤師さんの業務 ◦ 「デザインの方針を変更したほうが薬剤師さんにとって使いやすそう・・・」 • チームで「それは、やるべき！」 ◦ 僕じゃない方のエンジニア「すぐに仮実装を作ってみる！」 ◦ 僕「いいぞいいぞー！」 それによって • リリース前からプロダクトの方針転換ができた！
44. © KAKEHASHI Inc. Badプラクティスを選んで進めた新規開発 遅れ まだまだやることを残して ６月が終わってしまった・・・ ←イマココ
45. 再計画まわりの話 怒ってないよ！ 怒った？
46. © KAKEHASHI Inc. 計画が常に正しいわけではない 現状の延長線でゴールを考える
47. © KAKEHASHI Inc. 再計画 スケジュールの見直しは大胆に スケジュールの見直しは何度もやるもんじゃない • 計画づくりに時間がかかる • ステークホルダーへの説明コストも発生する 見直しは1回で済ます！
48. © KAKEHASHI Inc. 再計画 もっと早くわからなかったのか？ 正直、もっと早い段階で見直し必要ありとは思っていた スケジュールの見直しに必要な条件 • やらなければいけないことが全て洗い出せているか？ • チームのベロシティが安定しているか？ • チームの危機感は十分上がっているか？
49. © KAKEHASHI Inc. 再計画 再計画づくり 1. 全体マップを眺めながら、ストーリーの洗い出し・確認 2. 三点見積もり法(楽観値・最頻値・悲観値)により、機能開発の着地点を算出 3. リリース準備期間も含めて1ヶ月のバッファを取る a. 思わぬ課題が見つかるので厳密な見積もりはあえてしない 4. リリース予定日の肌感のすり合わせ 5. ステークホルダーへ説明
50. © KAKEHASHI Inc. 8月末リリース ↓ 10月中旬リリース この後は大きなスケジュール変更リスクもなく、 10月中旬に無事クローズドβとしてリリースできました 🎉
51. まとめ いろいろあったね ふりかえりだよ
52. © KAKEHASHI Inc. まとめ Badプラクティスも武器にする • 新規開発をスクラムでどう進めてきたか • 一番良いと思って信じたやり方は、いわゆるBadプラクティスだった ◦ Readyを待たない ◦ 見積もりをしない ◦ スプリント内でタスクが終わらない ◦ 仕掛中のユーザーストーリーがたくさんある • 状況に合わせて最適化し続ける、現状の延長線上で考える
53. © KAKEHASHI Inc. ふりかえってみて 全体マップはとても有効だった • 全体マップのおかげで、開発を始める前からMVPを削る話が出来た • 今どこにいて、あと何をやらなければいけないか、現在地をチーム全員で把握 できた → 結果、全員で助け合えた • 新規開発をやるなら、特におすすめ
54. © KAKEHASHI Inc. チームのその後 チームにエンジニア2人とメタラー1人がjoinした 種岡さん (RSGT初!) ogijunさん 1/11 14:00〜 “他者と働き、チームで成果 を出す方法 〜人との関係から みるカケハシ〜” 小田中さん 1/11 15:15〜 “スクラムとデッドライン、 壊れゆくチームをつなぎとめ るもの” オンラインで 参加してるよ！