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

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

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. 自己紹介 湯前 慶大 (@yunon_phys) • VP of

    Engineering 兼 Engineering Manager • カケハシ(2023年3月〜) • ビール、チーズ、ワインが好き • 子どもが生まれて、てんやわんやな 日々を過ごす 椎葉 光行 (@bufferings) • フルスタックエンジニア • カケハシ(2023年4月〜) • RSGT2021登壇 • Scrum Osaka 2021キーノート • コーヒー、ビール、ラーメンが好き
  2. © KAKEHASHI Inc. Badプラクティス? どんなBadプラクティスをやったのか? • Readyを待たない • 見積もりをしない •

    スプリント内でタスクが終わらない • 仕掛中のユーザーストーリーがたくさんある
  3. © KAKEHASHI Inc. 役割について 湯前のチームにおける役割 Engineering Manager(EM) 兼 Scrum Master(SM)

    EM = 組織の構築・成長に責任を持つ → 人を集めて開発体制をつくる SM = スクラムの推進・改善に責任を持つ → 集めた人で開発を進める・改善する
  4. © KAKEHASHI Inc. 採用基準 どんな人をチームに入れるべきか? 新規開発において重要なこと → 開発コストを可能な限り抑えること 1. コミュニケーションが円滑に出来ること(コミュニケーションコスト)

    2. フルスタックに活躍出来ること(人件費、コミュニケーションコスト) 3. 技術力が高いこと(技術的負債、安定性、コミュニケーションコスト) 特に開発初期の段階は どっちに進めば良いかわからない・・・
  5. © KAKEHASHI Inc. 課題 予期せぬ不具合や 考慮不足の発生 得られたこと リリース前に 不具合見つけた! バッファを設ける

    普段から気になりを 話せるように やったこと リリース準備期 リリース準備期(9〜10月)
  6. © KAKEHASHI Inc. Badプラクティスを選んで進めた新規開発 Readyを待たない・見積もりをしない 例:土台作り • 分かっていないことだらけの中で毎週違う課題に飛び込んだ ◦ Terraform

    + AWS、コンテナ実行環境の構築、GitHub Actionsで自動デプロイなど ◦ 調査→実装の素早い繰り返しで作り上げた ◦ 見積もりが可能になったときには実装が終わってる • 実装してみて気づいたことにも、その場で対応 ◦ 例:ARM64 DockerイメージのビルドはAWS CodeBuildに逃した それによって • 新しい情報にも対応しつつ、一番速い方法で土台を構築できた
  7. © KAKEHASHI Inc. Badプラクティスを選んで進めた新規開発 スプリント内でタスクが終わらない そもそも、スプリント(1週間)という区切りを気にしないことにしてた • やることをTODOに並べておいて、全力で1つずつ終わらせていくことに集中 • スプリント(1週間)は、日々状況が変わる新規開発には長すぎる

    • デイリースクラムで今日は何をするのがいちばんいいかを毎朝チームでプランニング • だから、スプリント終わりでタスクが残っていても気にしない それによって • スプリントという区切りは気にせずに、今日何をするべきかを大切にしていた じゃあスクラムじゃなくていいのでは? ってのには後でふれるからちょっと待ってね
  8. © KAKEHASHI Inc. Badプラクティスを選んで進めた新規開発 仕掛中のユーザーストーリーがたくさんある バックエンド開発:2回実装するほうがいいと判断 • 1回目:技術的に実現可能かどうかを素早く確認するための最小の実装 ◦ 1メソッドに全部を詰め込んで動作検証・エラー処理なし・ロギングなし

    ◦ 1回目の実装が終わった段階では、すべてのユーザーストーリーが仕掛中 • 2回目:本番環境で使えるレベルで実装しなおし ◦ どのロジックをどこに置くべきかなどの構造を整備 ◦ エラー処理やロギングの設計と実装 それによって • 実現可能性を早い段階でチェックできた・全体を見ながら本番レベルの実装ができた
  9. © KAKEHASHI Inc. Badプラクティスを選んで進めた新規開発 Badプラクティスを選んで進めた新規開発 1. Readyを待たない・見積もりをしない → 飛び込んで素早く実装するため 2.

    スプリント内でタスクが終わらない → 日次でプランニングをしていたため(スプリントを気にしなかった) 3. 仕掛中のユーザーストーリーがたくさんある → 2回実装することにしたため ただ、Badプラクティスは一歩踏み外すと危ない・・・
  10. © KAKEHASHI Inc. Badプラクティスを選んで進めた新規開発 毎週のスプリントレビューで「動くモノ」を見せる これをエンジニア2人は、めちゃくちゃ意識してた • 開発の区切りとしてのスプリントは気にしなかったけど • レビューの区切りとしてのスプリントをとても意識していた

    • 言葉ではなく動くモノで見せる ◦ 何ができていて、何ができていないのかをハッキリさせるため それによって • 毎週チームで全体マップを見ながら現在地を更新できた ふりかえりも毎週やってたし スクラムはいいなぁってなった
  11. © KAKEHASHI Inc. Badプラクティスを選んで進めた新規開発 動くモノ・新しい情報・方針転換 フロントエンドは早い段階で動くモックを見せていた • プロダクトマネージャが薬局を訪問(※薬局向けのプロダクトなので) ◦ 画面のモックを触った感触+実際に見てきた薬剤師さんの業務

    ◦ 「デザインの方針を変更したほうが薬剤師さんにとって使いやすそう・・・」 • チームで「それは、やるべき!」 ◦ 僕じゃない方のエンジニア「すぐに仮実装を作ってみる!」 ◦ 僕「いいぞいいぞー!」 それによって • リリース前からプロダクトの方針転換ができた!
  12. © KAKEHASHI Inc. 再計画 再計画づくり 1. 全体マップを眺めながら、ストーリーの洗い出し・確認 2. 三点見積もり法(楽観値・最頻値・悲観値)により、機能開発の着地点を算出 3.

    リリース準備期間も含めて1ヶ月のバッファを取る a. 思わぬ課題が見つかるので厳密な見積もりはあえてしない 4. リリース予定日の肌感のすり合わせ 5. ステークホルダーへ説明
  13. © KAKEHASHI Inc. まとめ Badプラクティスも武器にする • 新規開発をスクラムでどう進めてきたか • 一番良いと思って信じたやり方は、いわゆるBadプラクティスだった ◦

    Readyを待たない ◦ 見積もりをしない ◦ スプリント内でタスクが終わらない ◦ 仕掛中のユーザーストーリーがたくさんある • 状況に合わせて最適化し続ける、現状の延長線上で考える
  14. © KAKEHASHI Inc. チームのその後 チームにエンジニア2人とメタラー1人がjoinした 種岡さん (RSGT初!) ogijunさん 1/11 14:00〜

    “他者と働き、チームで成果 を出す方法 〜人との関係から みるカケハシ〜” 小田中さん 1/11 15:15〜 “スクラムとデッドライン、 壊れゆくチームをつなぎとめ るもの” オンラインで 参加してるよ!