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

Slide 1

Slide 1 text

日本の医療体験を、しなやかに。 © KAKEHASHI Inc. Badプラクティスを選んで失敗しながら進めた新規プロダクト開発 2024.01.10 @ Regional Scrum Gathering Tokyo 2024 湯前慶大　椎葉光行

Slide 2

Slide 2 text

Slide 3

Slide 3 text

Slide 4

Slide 4 text

© KAKEHASHI Inc. 自己紹介湯前慶大 (@yunon_phys) ● VP of Engineering 兼 Engineering Manager ● カケハシ(2023年3月〜) ● ビール、チーズ、ワインが好き ● 子どもが生まれて、てんやわんやな日々を過ごす椎葉光行 (@bufferings) ● フルスタックエンジニア ● カケハシ（2023年4月〜） ● RSGT2021登壇 ● Scrum Osaka 2021キーノート ● コーヒー、ビール、ラーメンが好き

Slide 5

Slide 5 text

Slide 6

Slide 6 text

Slide 7

Slide 7 text

Slide 8

Slide 8 text

Slide 9

Slide 9 text

新規開発とスクラムなぜ、見積もりをしないことにしたのか見積もりの代わりに何をしたのか遅れられない！わかるー！

Slide 10

Slide 10 text

Slide 11

Slide 11 text

Slide 12

Slide 12 text

Slide 13

Slide 13 text

Slide 14

Slide 14 text

Slide 15

Slide 15 text

Slide 16

Slide 16 text

Slide 17

Slide 17 text

Slide 18

Slide 18 text

Slide 19

Slide 19 text

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

© KAKEHASHI Inc. 採用基準どんな人をチームに入れるべきか？新規開発において重要なこと → 開発コストを可能な限り抑えること 1. コミュニケーションが円滑に出来ること(コミュニケーションコスト) 2. フルスタックに活躍出来ること(人件費、コミュニケーションコスト) 3. 技術力が高いこと(技術的負債、安定性、コミュニケーションコスト) 特に開発初期の段階はどっちに進めば良いかわからない・・・

Slide 25

Slide 25 text

Slide 26

Slide 26 text

Slide 27

Slide 27 text

Slide 28

Slide 28 text

Slide 29

Slide 29 text

Slide 30

Slide 30 text

Slide 31

Slide 31 text

Slide 32

Slide 32 text

Slide 33

Slide 33 text

Slide 34

Slide 34 text

Slide 35

Slide 35 text

Slide 36

Slide 36 text

Slide 37

Slide 37 text

Badプラクティスを選んで進めた新規開発 1. Readyを待たない・見積もりをしない 2. スプリント内でタスクが終わらない 3. 仕掛中のユーザーストーリーがたくさんあるこのパートはモジモジ（文字文字）してるよー！

Slide 38

Slide 38 text

© KAKEHASHI Inc. Badプラクティスを選んで進めた新規開発 Readyを待たない・見積もりをしない例：土台作り ● 分かっていないことだらけの中で毎週違う課題に飛び込んだ ○ Terraform + AWS、コンテナ実行環境の構築、GitHub Actionsで自動デプロイなど ○ 調査→実装の素早い繰り返しで作り上げた ○ 見積もりが可能になったときには実装が終わってる ● 実装してみて気づいたことにも、その場で対応 ○ 例：ARM64 DockerイメージのビルドはAWS CodeBuildに逃したそれによって ● 新しい情報にも対応しつつ、一番速い方法で土台を構築できた

Slide 39

Slide 39 text

© KAKEHASHI Inc. Badプラクティスを選んで進めた新規開発スプリント内でタスクが終わらないそもそも、スプリント（１週間）という区切りを気にしないことにしてた ● やることをTODOに並べておいて、全力で１つずつ終わらせていくことに集中 ● スプリント（１週間）は、日々状況が変わる新規開発には長すぎる ● デイリースクラムで今日は何をするのがいちばんいいかを毎朝チームでプランニング ● だから、スプリント終わりでタスクが残っていても気にしないそれによって ● スプリントという区切りは気にせずに、今日何をするべきかを大切にしていたじゃあスクラムじゃなくていいのでは？ってのには後でふれるからちょっと待ってね

Slide 40

Slide 40 text

© KAKEHASHI Inc. Badプラクティスを選んで進めた新規開発仕掛中のユーザーストーリーがたくさんあるバックエンド開発：２回実装するほうがいいと判断 ● １回目：技術的に実現可能かどうかを素早く確認するための最小の実装 ○ １メソッドに全部を詰め込んで動作検証・エラー処理なし・ロギングなし ○ １回目の実装が終わった段階では、すべてのユーザーストーリーが仕掛中 ● ２回目：本番環境で使えるレベルで実装しなおし ○ どのロジックをどこに置くべきかなどの構造を整備 ○ エラー処理やロギングの設計と実装それによって ● 実現可能性を早い段階でチェックできた・全体を見ながら本番レベルの実装ができた

Slide 41

Slide 41 text

© KAKEHASHI Inc. Badプラクティスを選んで進めた新規開発 Badプラクティスを選んで進めた新規開発 1. Readyを待たない・見積もりをしない → 飛び込んで素早く実装するため 2. スプリント内でタスクが終わらない → 日次でプランニングをしていたため（スプリントを気にしなかった） 3. 仕掛中のユーザーストーリーがたくさんある → ２回実装することにしたためただ、Badプラクティスは一歩踏み外すと危ない・・・

Slide 42

Slide 42 text

© KAKEHASHI Inc. Badプラクティスを選んで進めた新規開発毎週のスプリントレビューで「動くモノ」を見せるこれをエンジニア２人は、めちゃくちゃ意識してた ● 開発の区切りとしてのスプリントは気にしなかったけど ● レビューの区切りとしてのスプリントをとても意識していた ● 言葉ではなく動くモノで見せる ○ 何ができていて、何ができていないのかをハッキリさせるためそれによって ● 毎週チームで全体マップを見ながら現在地を更新できたふりかえりも毎週やってたしスクラムはいいなぁってなった

Slide 43

Slide 43 text

© KAKEHASHI Inc. Badプラクティスを選んで進めた新規開発動くモノ・新しい情報・方針転換フロントエンドは早い段階で動くモックを見せていた ● プロダクトマネージャが薬局を訪問（※薬局向けのプロダクトなので） ○ 画面のモックを触った感触＋実際に見てきた薬剤師さんの業務 ○ 「デザインの方針を変更したほうが薬剤師さんにとって使いやすそう・・・」 ● チームで「それは、やるべき！」 ○ 僕じゃない方のエンジニア「すぐに仮実装を作ってみる！」 ○ 僕「いいぞいいぞー！」それによって ● リリース前からプロダクトの方針転換ができた！