プロダクトの品質に コミットする / Commit to Product Quality

2024/12/4 スタートアップ5社集合！開発スピードと品質における各社の取り組み LT

Transcript

1. © 2024 Loglass Inc. 0 © 2024 Loglass Inc. 開発スピードと品質についての考え方 プロダクトの品質に コミットする 石畑 翔平 @pekepek 2024.12.04
2. © 2024 Loglass Inc. 1 自己紹介 2014 年に新卒で Sansan 株式会社に入社 データ統括部門で名刺のデータ化や名寄せサービスなどを開発。 その後、新規事業開発に異動し、EM となる。 2024 年 4 月に新たなチャレンジを求めて、ログラスにジョイン。 数年ぶりに楽しく実装中。 技術書典で「Loglass Tech Frontiers Vol.1」という本を出して、 自分は SQL の話を書いたので、ぜひダウンロードして下さい！ 開発部 エンジニア 石畑 翔平 Ishihata Shohei
3. © 2024 Loglass Inc. 2 Loglass について
4. © 2024 Loglass Inc. 3 はじめに 今日する話 ✅ 手戻りを無くす、無駄なものを作らないことで生産性を高くする ✅ そのためには検証段階から技術面も含めて、不確実性を取り除くことが重要 ✅ ログラスではどのようにディスカバリー（顧客価値の探索）からエンジニアが入り、 デリバリーにつなげているか具体例を紹介
5. © 2024 Loglass Inc. 4 はじめに 今日しない話 ❌ 品質を高めるためのアーキテクチャ、CI/CD の構築 ❌ バグを減らすためのテスト手法 ❌ 生産性指標の話
6. © 2024 Loglass Inc. 5 本日のテーマ 「開発スピードと品質」
7. © 2024 Loglass Inc. 6 開発スピードと品質 開発スピードが早い状態とは？ • リードタイムやリリース数も大事だが、生み出した顧客価値が最も重要 • 売上・ビジネス価値に貢献する ◦ いわゆるレベル 3 の生産性 ◦ ここの生産性を上げたい 広木 大地. 開発生産性について議論する前に知っておきたいこと. https://qiita.com/hirokidaichi/items/53f0865398829bdebef1
8. © 2024 Loglass Inc. 7 高品質なプロダクトを作るの難しい... でも、価値の高いプロダクトを作るの難しい... • 何が正解かわからない • 上手く行かないことだらけ ◦ 画期的なアイディアだが、いざ開発したら難しくていつまでも実現できない ◦ なんとか実装できたけど、動作が遅すぎて使う気にならない ◦ リリースされたけど、思ったより売れない・使われない ◦ 使ってもらえたが、バグだらけで障害が多発する
9. © 2024 Loglass Inc. 8 高品質なプロダクトを作るの難しい... ベント・フリウビヤ; ダン・ガードナー. BIG THINGS どデカいことを成し遂げたヤツらはなにをしたのか？. サンマーク出版 “ 99.５％のプロジェクトが、予算超過か工期遅延、 便益過小、またはそれらの組み合わせに終わる。
10. © 2024 Loglass Inc. 9 高品質なプロダクトを作るの難しい... PJ が予想通りに進むことはない • ほとんどの PJ は想定以上のコストがかかる、予定通りリリースされない、 期待通りの価値を出せずに失敗する • どうすればいいのか？ → 失敗する前提で機能開発する
11. © 2024 Loglass Inc. 10 Fail First 失敗は成功の基 すべての失敗が悪いわけではない • 良い失敗 : ダメージが小さく、学びが大きい • 不確実性の高い世界では、経験しないとわからない 失敗から学び、 軌道修正をすることが大切
12. © 2024 Loglass Inc. 11 Fail First PJ 後半の失敗は致命的 • 実装後に仕様が変わる ◦ 複数のエンジニアが実装に関わり、既に多くのコストがかかっている ◦ コードを戻すにも多くのコストがかかる → 開発規模によっては致命的に • リリース後に問題が発生する ◦ ユーザー影響があるため、機能変更・削除のコストが大幅に上がる → 不要な機能が残り続け、長期的なコストになることも ◦ セキュリティやデータに問題があると、一発で致命傷になり得る
13. © 2024 Loglass Inc. 12 Fail First Fail First • 検討段階での失敗はコストが低い ◦ アイディアやモック作成は小さく試せる ◦ 手戻りも小さい • いかに早い段階で失敗できるかが重要
14. © 2024 Loglass Inc. 13 Fail First どう進めていくか？ • 急いで実装せず、検証に時間をかける • アイディアの段階から様々な視点からレビューする ◦ ユーザー ◦ ビジネス ◦ 技術 • ログラスでは、ディスカバリーから PdM、CS、デザイナー、エンジニアでタッグを組む ◦ ソリューションと技術は切り離せない ◦ 技術的困難が合った際に、エンジニアも深い顧客理解が必要 • 実装をする前にいかに不確実性を減らせるか
15. © 2024 Loglass Inc. 14 ログラスでの取り組み
16. © 2024 Loglass Inc. 15 ログラスの取り組み例 カスタマー ジャーニーマッ プ 実例 マッピング テスト分析 ドメイン モデリング スパイク 受け入れ基準 なぜやるのか？ 目的の明確化 要件・ストーリー の精度を上げる リスクの洗い出し ※ 実際は単純なフローではなく、 横断的に実施したり、行ったり来たりする システムのための 抽象化 技術的な 仮説検証 バックログの 明確化 ログラスの取り組み例 PBI の作成 設計 実装
17. © 2024 Loglass Inc. 16 ログラスの取り組み例 カスタマー ジャーニーマッ プ 実例 マッピング テスト分析 ドメイン モデリング スパイク 受け入れ基準 なぜやるのか？ 目的の明確化 要件・ストーリー の精度を上げる リスクの洗い出し ※ 実際は単純なフローではなく、 横断的に実施したり、行ったり来たりする システムのための 抽象化 技術的な 仮説検証 バックログの 明確化 ログラスの取り組み例 PBI の作成 設計 実装 様々な取り組みでレビュー・認識合わせをして 実装前に不確実性を減らしていく
18. © 2024 Loglass Inc. 17 ログラスの取り組み例 カスタマー ジャーニーマッ プ 実例 マッピング テスト分析 ドメイン モデリング スパイク 受け入れ基準 なぜやるのか？ 目的の明確化 要件・ストーリー の精度を上げる リスクの洗い出し ※ 実際は単純なフローではなく、 横断的に実施したり、行ったり来たりする システムのための 抽象化 技術的な 仮説検証 バックログの 明確化 ログラスの取り組み例 PBI の作成 設計 実装 今日は実例マッピングに ついて取り上げる
19. © 2024 Loglass Inc. 18 実例マッピング 実例マッピング • 具体例からストーリーについて話し合い、確定・未確定なことについて明確にする • 実際の数値やユースケースを当てはめて議論することで、気づきや共通認識を得る • 作成したマップはテストやモデリング時にも使える
20. © 2024 Loglass Inc. 19 実例マッピング どのように実施しているか紹介
21. © 2024 Loglass Inc. 20 実例マッピング 実施タイミング・参加者 • 実施タイミング例 ◦ ソリューションが見えて簡単なモックが出来たので、懸念点を洗い出したい ◦ 顧客価値の検証が完了し、モデリングを行うために要件を明確にしたい ◦ バックログを作成し、受け入れ基準を作成したい • 参加者 ◦ PdM、CS、デザイナー、エンジニア、QA など
22. © 2024 Loglass Inc. 21 実例マッピング やることイメージ 4 色の付箋を用意
23. © 2024 Loglass Inc. 22 実例マッピング やることイメージ 議論するストーリーについて書く
24. © 2024 Loglass Inc. 23 実例マッピング やることイメージ 事前にわかっている要件などがあれば Rule に置いていく
25. © 2024 Loglass Inc. 24 実例マッピング やることイメージ Example に疑問や具体例を書いていく
26. © 2024 Loglass Inc. 25 実例マッピング やることイメージ 質問に答えながら議論していく
27. © 2024 Loglass Inc. 26 実例マッピング やることイメージ 新たに確定した仕様があれば、Rule の更新や追加を行う
28. © 2024 Loglass Inc. 27 実例マッピング やることイメージ その場で決められなかった論点を Question に残す
29. © 2024 Loglass Inc. 28 実例マッピング やることイメージ 議論を進めていくことで、確定・未確定なことが明確になる 未確定部分は優先度を決めて ディスカバリーを行う
30. © 2024 Loglass Inc. 29 実例マッピング その他のおすすめ観点 • 未確定の議論に時間を取りすぎない → まずは論点を洗い出すことが価値 • 参加者で実例マッピングの目的を揃える → 顧客価値検証や受け入れ基準作成で抽象度が大きく違う • Rule や Example に画面・図があれば紐づける • 議論した背景や関連情報、質問なども残しておく → 後でドキュメントとなる
31. © 2024 Loglass Inc. 30 実例マッピング やってよかった事例
32. © 2024 Loglass Inc. 31 実例マッピング 事例 1 : 抽象的に捉えていたことによる考慮漏れの発見 • 「非財務科目階層化」という機能を開発 • 既に別機能で階層化は行っており、「同じ体験」が提供できればいいと考えていた • しかし、実例を挙げていくことで非財務科目特有の体験が必要なことが発覚 • モデリングに影響する観点だったため、実装前に気づけたことで手戻りを防げた https://www.loglass.jp/news/press-20241112
33. © 2024 Loglass Inc. 32 実例マッピング 事例 2 : データや条件による体験の考慮漏れの発見 • ある機能開発で、UI も含めて体験設計が完了 • 設定項目の多い画面の改修のため、パターンごとの実例を挙げていった • 特定のケースでは顧客体験が十分でない可能性があり、特定の UI パターンについて 再検討することに
34. © 2024 Loglass Inc. 33 実例マッピング 事例 3 : ドメイン知識の共有 • 複数の機能を横断的に改修する PJ • 影響範囲が大きく、個人で全ての機能を把握するのは困難 • 各ドメインに詳しいエンジニア複数人で、実例マッピングを行うことで 現状の仕様のキャッチアップになった
35. © 2024 Loglass Inc. 34 実例マッピング やってよかった実例マッピング • 具体を考えることで価値・アイディアのレビューが可能 • 一人では気付けない発見がある • 議論した結果がそのままドキュメントになる このような取り組みで 実装後の「想像と違った」を無くす
36. © 2024 Loglass Inc. 35 まとめ
37. © 2024 Loglass Inc. 36 まとめ 今日した話 • プロダクト開発は不確実性が高く、理想通りに進めることはできない • 失敗は早い段階で経験し、可能な限り不確実性を減らした状態で実装に入りたい • そのためにログラスではディスカバリーからエンジニアが入り、さまざまな取り組みを 行っている • 一例として実例マッピングについて紹介
38. © 2024 Loglass Inc. 37 参考資料 • 実例マッピング : nihonbuson. ブロッコリーのブログ. これから実例マッピングを使おうと思っている人へお伝えしたい 日本語情報のリンク集. • その他の取り組み ◦ カスタマージャーニーマップ : 及川 卓也, 小城 久美子, 曽根原 春樹. プロダクトマネジメントのすべて ◦ テスト分析 : Janet Gregory, Lisa Crispin, and Yuya Kazama. Agile Testing Condensed Japanese Edition ◦ ドメインモデリング : little_hands. little hands' lab. 簡単にできるDDDのモデリング - ドメイン駆動設計
39. © 2024 Loglass Inc. 38