Upgrade to Pro — share decks privately, control downloads, hide ads and more …

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

kakehashi
January 11, 2024

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

kakehashi

January 11, 2024
Tweet

More Decks by kakehashi

Other Decks in Business

Transcript

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

    View full-size slide

  2. © KAKEHASHI Inc.
    いきなり質問
    新しいプロダクト開発の立ち上げを
    経験したことある方ー?

    View full-size slide

  3. © KAKEHASHI Inc.
    はじめに
    本題に入る前に・・・
    ● 新規開発の話をあまり聞いたことない
    ● ふりかえってみると、成功のためにBadプラクティスを選択していた
    → 実践例として、コミュニティに還元出来るのでは?

    View full-size slide

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

    View full-size slide

  5. © KAKEHASHI Inc.
    カケハシの紹介
    Mission
    日本の医療体験を、しなやかに。
    Vision
    明日の医療の基盤となる、エコシステムの実現。

    View full-size slide

  6. © KAKEHASHI Inc.
    カケハシの紹介

    View full-size slide

  7. © KAKEHASHI Inc.
    本セッションの前提
    今日の話はこんな背景があるよ
    ● 2023年4〜10月の話
    ● 薬局向けの新規プロダクト、3月に出来たばかりの新しいチーム
    ● フルリモート

    View full-size slide

  8. © KAKEHASHI Inc.
    Badプラクティス?
    どんなBadプラクティスをやったのか?
    ● Readyを待たない
    ● 見積もりをしない
    ● スプリント内でタスクが終わらない
    ● 仕掛中のユーザーストーリーがたくさんある

    View full-size slide

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

    View full-size slide

  10. © KAKEHASHI Inc.
    新規開発とスクラム
    新規開発
    開発中にも新しい情報がたくさん!
    分かっていないことがたくさん!
    前もってきっちり決めてもうまくいかない!

    View full-size slide

  11. © KAKEHASHI Inc.
    新規開発とスクラム
    新規開発とスクラム
    調査用のスプリントを実施
    わりと好き!
    1. 調査する
    2. Readyになる
    3. 見積もりをする
    4. 実装する
    5. 繰り返す

    View full-size slide

  12. © KAKEHASHI Inc.
    新規開発とスクラム
    新規開発とスクラム
    Readyになるのを待たない
    これに挑戦したいなー!
    1. 調査する
    2. Readyになる
    3. 見積もりをする
    4. 実装する
    5. 繰り返す

    View full-size slide

  13. © KAKEHASHI Inc.
    新規開発とスクラム
    どう思う?
    いいね!やってみよう!

    View full-size slide

  14. © KAKEHASHI Inc.
    新規開発とスクラム
    Readyを待たない・見積もりをしない開発
    「分かっていないこと」を解決しながら「新しい情報」にも素早く対応するぞー!

    View full-size slide

  15. © KAKEHASHI Inc.
    新規開発とスクラム
    全体マップづくり

    View full-size slide

  16. © KAKEHASHI Inc.
    新規開発とスクラム
    全体マップづくり

    View full-size slide

  17. © KAKEHASHI Inc.
    新規開発とスクラム
    ユーザーストーリー以外のタスク
    インフラ構築や
    技術選定など
    全体のテストや
    本番環境の準備など

    View full-size slide

  18. © KAKEHASHI Inc.
    新規開発とスクラム
    え?1ヶ月?
    みじかっ!!!
    ユーザーストーリー以外のタスク
    インフラ構築や
    技術選定など
    全体のテストや
    本番環境の準備など

    View full-size slide

  19. © KAKEHASHI Inc.
    新規開発とスクラム
    MVPをスライス

    View full-size slide

  20. © KAKEHASHI Inc.
    新規開発とスクラム
    全体マップ

    View full-size slide

  21. チーム作りの話
    ドリームチーム!
    どんなチーム作ったの?

    View full-size slide

  22. © KAKEHASHI Inc.
    役割について
    湯前のチームにおける役割
    Engineering Manager(EM) 兼 Scrum Master(SM)
    EM = 組織の構築・成長に責任を持つ
    → 人を集めて開発体制をつくる
    SM = スクラムの推進・改善に責任を持つ
    → 集めた人で開発を進める・改善する

    View full-size slide

  23. © KAKEHASHI Inc.
    チームコンセプト
    こんなチームにしたい
    “良いチームが良いプロダクトを作る”
    を体現するドリームチーム

    技術力 × 顧客価値

    View full-size slide

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

    View full-size slide

  25. © KAKEHASHI Inc.
    開発チーム
    船に乗った人たち
    EM/SM Eng Eng
    PdM

    View full-size slide

  26. © KAKEHASHI Inc.
    開発チーム
    船に乗った人たち
    大丈夫です!!
    EM/SM Eng Eng
    PdM
    人数を増やさなくて
    大丈夫ですか?

    View full-size slide

  27. © KAKEHASHI Inc.
    開発チーム
    船に乗った人たち
    うまくいかなかったら
    どうしよう
    EM/SM Eng Eng
    PdM
    人数を増やさなくて
    大丈夫ですか?

    View full-size slide

  28. © KAKEHASHI Inc.
    ここまでEngineering Managerとしての話
    ここからScrum Masterとしての話

    View full-size slide

  29. © KAKEHASHI Inc.
    チームコンセプト
    こんなチームにしたい
    “良いチームが良いプロダクトを作る”
    を体現するドリームチーム

    技術力 × 顧客価値

    View full-size slide

  30. © KAKEHASHI Inc.
    チームコンセプト
    Scrum Masterとしてやったこと
    チームの置かれる状況の変化に合わせて
    チームの動きを変化させていく

    View full-size slide

  31. © KAKEHASHI Inc.
    4つのフェーズ
    リリースまでの4つのフェーズ
    立ち上げ期
    (4〜5月)
    リズム形成期
    (6〜7月)
    機能量産期
    (7〜8月)
    リリース
    準備期
    (9〜10月)
    チームの状況を見ながら滑らかに変化

    View full-size slide

  32. © KAKEHASHI Inc.
    立ち上げ期
    立ち上げ期(4〜5月)
    課題
    やることが不明瞭
    どんな技術を使う?
    得られたこと
    漏れ・だぶりない調査
    ゴールまでの道筋
    調査のタスク化
    情報の透明性担保
    やったこと

    View full-size slide

  33. © KAKEHASHI Inc.
    課題
    どれぐらいで
    開発できる?
    得られたこと
    間に合わない
    という理解
    おおよその見積もり
    目の前の開発推進
    やったこと
    リズム形成期
    リズム形成期(6〜7月)

    View full-size slide

  34. © KAKEHASHI Inc.
    課題
    機能開発以外の
    タスクが山積み
    得られたこと
    開発スピード安定
    タスクが終わってく
    機能開発以外は
    スクラムマスターが
    巻き取る!
    やったこと
    機能量産期
    機能量産期(7〜8月)

    View full-size slide

  35. © KAKEHASHI Inc.
    課題
    予期せぬ不具合や
    考慮不足の発生
    得られたこと
    リリース前に
    不具合見つけた!
    バッファを設ける
    普段から気になりを
    話せるように
    やったこと
    リリース準備期
    リリース準備期(9〜10月)

    View full-size slide

  36. © KAKEHASHI Inc.
    4つのフェーズ
    リリースまでの4つのフェーズ
    立ち上げ期
    (4〜5月)
    リズム形成期
    (6〜7月)
    機能量産期
    (7〜8月)
    リリース
    準備期
    (9〜10月)
    チームの状況を見ながら滑らかに変化

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

  44. © KAKEHASHI Inc.
    Badプラクティスを選んで進めた新規開発
    遅れ
    まだまだやることを残して
    6月が終わってしまった・・・
    ←イマココ

    View full-size slide

  45. 再計画まわりの話
    怒ってないよ!
    怒った?

    View full-size slide

  46. © KAKEHASHI Inc.
    計画が常に正しいわけではない
    現状の延長線でゴールを考える

    View full-size slide

  47. © KAKEHASHI Inc.
    再計画
    スケジュールの見直しは大胆に
    スケジュールの見直しは何度もやるもんじゃない
    ● 計画づくりに時間がかかる
    ● ステークホルダーへの説明コストも発生する
    見直しは1回で済ます!

    View full-size slide

  48. © KAKEHASHI Inc.
    再計画
    もっと早くわからなかったのか?
    正直、もっと早い段階で見直し必要ありとは思っていた
    スケジュールの見直しに必要な条件
    ● やらなければいけないことが全て洗い出せているか?
    ● チームのベロシティが安定しているか?
    ● チームの危機感は十分上がっているか?

    View full-size slide

  49. © KAKEHASHI Inc.
    再計画
    再計画づくり
    1. 全体マップを眺めながら、ストーリーの洗い出し・確認
    2. 三点見積もり法(楽観値・最頻値・悲観値)により、機能開発の着地点を算出
    3. リリース準備期間も含めて1ヶ月のバッファを取る
    a. 思わぬ課題が見つかるので厳密な見積もりはあえてしない
    4. リリース予定日の肌感のすり合わせ
    5. ステークホルダーへ説明

    View full-size slide

  50. © KAKEHASHI Inc.
    8月末リリース

    10月中旬リリース
    この後は大きなスケジュール変更リスクもなく、
    10月中旬に無事クローズドβとしてリリースできました
    🎉

    View full-size slide

  51. まとめ
    いろいろあったね
    ふりかえりだよ

    View full-size slide

  52. © KAKEHASHI Inc.
    まとめ
    Badプラクティスも武器にする
    ● 新規開発をスクラムでどう進めてきたか
    ● 一番良いと思って信じたやり方は、いわゆるBadプラクティスだった
    ○ Readyを待たない
    ○ 見積もりをしない
    ○ スプリント内でタスクが終わらない
    ○ 仕掛中のユーザーストーリーがたくさんある
    ● 状況に合わせて最適化し続ける、現状の延長線上で考える

    View full-size slide

  53. © KAKEHASHI Inc.
    ふりかえってみて
    全体マップはとても有効だった
    ● 全体マップのおかげで、開発を始める前からMVPを削る話が出来た
    ● 今どこにいて、あと何をやらなければいけないか、現在地をチーム全員で把握
    できた → 結果、全員で助け合えた
    ● 新規開発をやるなら、特におすすめ

    View full-size slide

  54. © KAKEHASHI Inc.
    チームのその後
    チームにエンジニア2人とメタラー1人がjoinした
    種岡さん
    (RSGT初!)
    ogijunさん
    1/11 14:00〜
    “他者と働き、チームで成果
    を出す方法 〜人との関係から
    みるカケハシ〜”
    小田中さん
    1/11 15:15〜
    “スクラムとデッドライン、
    壊れゆくチームをつなぎとめ
    るもの”
    オンラインで
    参加してるよ!

    View full-size slide