品質は設計でつくり込む / design in quality

Transcript

1. 品質は設計でつくり込む 株式会社グロービス 大沼和也 1
2. こんな悩みありませんか？ テストケースが多すぎる プロジェクト後期にテストの量が多いことに気づく プロジェクト後期に不具合に気づいてプロジェクトが遅延 2
3. 本日のテーマ 品質は設計で作り込むことで、 プロダクト運用コストを大幅に減らす 3
4. 0. 品質を設計で作り込むとは 4
5. シフトレフトが大事ってこと？ 5
6. 不具合発見の早さと修正コスト In general, the earlier you get rid of a bug, the less it costs you. 翻訳: 不具合発見が早ければ早いほど、修正コ ストは安くなる 6
7. 早期発見しないと、文脈の喪失によ りコストが増大する Bringing testing forward in the software development life cycle decreases the cost and complexity of fixing bugs because they are found closer to when they were created, which establishes more of a context for what could have caused things to go wrong. 翻訳: 早い段階でテストを行うことは、バグ修 正のコストと複雑さを低減させます。なぜな ら、バグが作られた時点に近い場所で発見され るため、何が問題を引き起こしたかの文脈がよ り明確になるからです。 7
8. コストの増大は指数関数的なのでシ フトレフトが重要 Shifting problem detection to the "left," earlier on this timeline, makes it cheaper to fix than waiting longer, … 翻訳: 問題の発見をタイムラインの「左」 、つま りより早い段階にシフトすることで、後で待つ よりも修正コストが安くなります。 8
9. シフトレフトの考え方に立ち戻る 熟練したテスターは、開発サイクルの最初から 関与している Skilled testers are involved from the start of the development cycle and are given time and resources to do an adequate job of all necessary forms of testing. 本書の序文で、成功するチームの共通点として 「熟練したテスターが開発サイクルの最初から 関与している」ことを挙げています。 9
10. 散々言われている「シフトレフト」という言葉に、少し引っかか りを感じていた シフトレフトはもちろん重要で、不具合を早期に見つけるのは良いこと とはいえ「早期発見のためにとにかく早く関わればいい」という解釈が広がっている 気がしており、そこに少し違和感を感じていた 10
11. 「シフトレフト」と「品質を設計で作り込む」は少し違います 11
12. 元ネタ トヨタ生産方式の 「品質を工程でつくり込む」 12
13. 「シフトレフト」よりも、トヨタ生産方式の「品質は工程で作り 込む」のほうがしっくりきた 13
14. 品質を設計で作り込むとは 「バグが出たらテストで潰す」 ではなく、 「そもそもバグを生まない構造を設計する」こと 14
15. トヨタ生産方式における「品質を工程でつくり込む」とは、 不良を後で検査で見つけるのではなく、各工程で発生させないようにする考え方 各工程の作業者が自ら品質を保証する「自工程完結」の実践 結果として、後工程に不良を流さず、全体の生産性と信頼性を高める仕組み 15
16. ソフトウェア開発に置き換えると バグをテストで見つけるのではなく、要件定義・設計・実装の段階で生まれない ようにする 各工程（要件・設計・実装）が自分の工程の品質を保証する 設計上の制約・責務分離・テスト容易性を最初から考慮し、後工程の生産性を下 げない 16
17. 「品質は工程で作り込む」 「自工程完結」の考え方例 「次工程はお客様」思想 自分の後に続く工程（たとえば組立ラインの次の人）を「お客様」と見な し、 　“お客様に不良を渡さない”という倫理を日常的に内面化する 　→アジャイル開発だと細かいプロセスを頻繁にまわしていくので、ウォータ ーフォールのように進める必要はない 　　しかし、前のプロセスで気づけたであろうことは仕組み化が大事 自分の工程で完結＝前工程を責めない 「不良は自分の工程で潰す」ことを前提とし、問題を後回しにしない 前工程への文句ではなく、自分の工程を変えて防ぐ 参考：https://www.toyota.co.jp/jpn/company/history/75years/data/company_information/quality/explanation02.html 17
18. 1. なぜ設計で品質を作り込む必要があるのか 18
19. テスタビリティレビューの経済的効 果 At least half of your testing costs can be cut before anybody ever runs a test, if only your systems are designed with testability in mind. 翻訳: テストのしやすさを念頭に置いて設計さ れているだけで、実際にテストを実行する前 に、テストコストの少なくとも半分は削減でき る 19
20. テスタビリティは設計段階で考えた い Failing to review designs and code for testability: At least half of your testing costs can be cut before anybody ever runs a test, if only your systems are designed with testability in mind. 翻訳: もしシステムがテストのしやすさを念頭に置い て設計されているだけで、実際に誰かがテスト を実行する前に、テストコストの少なくとも半 分は削減できるのです。 20
21. 2. 要件定義/仕様決定でテスタビリティが漏れやすい のはなぜか 21
22. エンジニアの視点 「どう実装するべきか」を考えながら参加していることが多い 自分が実装するので、技術的な実現方法（プロダクションコード）に意識が向く 「プロダクションコードに分岐を追加する」というコーディングコストは非 常に低い テストケースの爆発には意識が向きづらい QAの視点が補完できる（もちろんエンジニアもこの視点があると良い） 「この仕様だと何パターンのテストが必要か」 「どのような制約があればテストが減るか」 22
23. 3. 品質を作り込むためにはどうすればいいのか 23
24. QAとして品質を作り込みやすいのは 要件定義/設計段階 24
25. 実例：設計段階でのQAの介入 During one iteration planning meeting that I was in, the programmers started talking about implementation and drawing pictures on the whiteboard to show what they were thinking. 翻訳: イテレーション計画ミーティングで、プ ログラマーたちが実装について話し合い、ホワ イトボードに図を描いていた。 25
26. QAからの問いかけ I thought about it for a bit and asked the question, "Can it be done more simply? The permutations and combinations for testing your proposed implementation will make testing horrendous." 翻訳: 少し考えてから質問した。 「もっとシンプ ルにできませんか？その実装案だと、テストの 順列組み合わせが膨大になり、テストが地獄に なります。 」 26
27. その後の展開 The programmers thought about it for a couple of minutes and suggested an alternative that not only met the customer's needs, but was simpler and easier to test. It was a win-win combination for everyone. 翻訳: プログラマーたちは数分考え、顧客のニ ーズを満たしつつ、よりシンプルでテストしや すい代替案を提案した。全員にとってWin-Win の結果となった。 27
28. 実例1：外部アプリとのデータ連携 Before: 共通基盤からサービスにデータ連携する場合のPush型連携 各サービスの受信状況・再送制御・失敗時のリトライなど、共通基盤側に多くの 条件分岐が必要 データ連携エラーがあったときに、各サービス起点で復帰できない（共通基盤の job実行を待つ必要がある） 28
29. Push型の仕組み 29
30. Push型連携 メリット: リアルタイム性高くデータ連携が可能 リソースの問題: 共通基盤のアプリチームが全ての連携実装を担当 3サービス分の実装・テスト・保守でリソース枯渇 ドメイン知識の問題: 各アプリの仕様は、それぞれのプロダクトチームほど理解していない 仕様変更のたびに確認・調整コストが発生 うっかり分岐で対応すると3サービスすべてに影響が出てしまう可能性がある 30
31. After: Pull型連携 シンプルな設計: 一つのエンドポイント（GET /users）を提供 各サービスが必要な時にデータを取得（or ポーリング）する メリット: 各サービスは自分のタイミングで取得 共通基盤チームの負担が大幅に軽減 副作用の心配がない（取得するだけ） デメリット: リアルタイム性の高いデータ同期には向かない 31
32. After: Pull型の仕組み 32
33. 実例2：申込情報の扱い 申込機能移管プロジェクト 33
34. 申込機能移管プロジェクトの背景 申込情報は基幹システムに連携する必要がある 売上速報に使われている 不具合を起こすと影響が大きい 34
35. Before: 移管前の申込管理（旧システム） 問題のある設計: キャンセル期限後も申込情報を編集できた 確定済みの申込に人を追加できる 名前やメールアドレスを変更できる 35
36. After: 移管後の申込管理（新システム） 復元力の高い設計: キャンセル期限後は申込情報を確定（イミュータブル） 確定後は編集不可 履歴として保持できる →過去の申込をもとに売上データを再生成できる 36
37. イミュータブル設計のメリット 冪等性の担保: 同じ申込データから何度実行しても同じ結果 リトライ時に「入力値が変わっていた」という問題が起きない テストの容易性: テストデータが不変なので、テストが安定する デバッグの容易性: 「あの時どんな値が送信されていたか」が確実にわかる 過去の障害を当時の状態で再現できる 「今のデータと違う」という辛さがない 37
38. 実例3：管理者削除機能 法人管理者向け管理画面 38
39. 管理者削除機能の仕様 シンプルそうな機能: 管理者一覧画面がある 各管理者の横に「削除」ボタンがある ボタンを押すと削除される 39
40. テストケース考え始めると意外と考慮ポイントがある 誰でも削除可能な仕様だと: いろいろと条件分岐のための考慮が発生する： 最後の1人を削除できるか？ 　→組織に管理者がいなくなると困る 自分で自分自身を削除した場合の挙動は？ 他の人から消されたときと挙動に差はある？ 削除後のリダイレクト先は？ 削除実行者が消えた場合のログは？ 40
41. 仕様をシンプルにするための制約を追加すると... 本人は削除できない このシンプルなルールだけで： 自分以外の管理者は削除可能 自分自身は削除不可 　→「最後の1人」問題も自動的に解決 　→説明しやすい 41
42. これらの事例に共通する考え方 2つの設計原則 42
43. 原則1：決定性の向上 決定性とは: 同じ入力に対して、常に同じ出力が得られること ソフトウェアの振る舞いが： 説明しやすい 再現可能である 外部の状態変化に影響されない 43
44. 原則2：条件分岐の削減 シンプルなルールにする: 複雑な条件分岐を削減し、理解しやすい設計にする 動的な状態依存を減らす エッジケースを減らす テストすべき組み合わせを減らす 44
45. 決定性を高めるとテストが減る理由 決定性が低い設計: タイミング依存のバグが発生しやすい リトライ時の動作が予測困難 副作用のテストが必要 決定性が高い設計: 同じ入力なら同じ結果 → テストケース削減 冪等性が保証される → テストが容易 45
46. 要件定義段階で複雑性を下げるには 非常に限られたケース用に、 「一応」 「念のため」で対応すると複雑になりかえっ て不具合のもとになる 46
47. YAGNI原則 You Aren't Gonna Need It YAGNI stands for "You aren't gonna need it" and advocates against investing time in functionality that's not needed right now. 翻訳: YAGNIは「どうせそれは必要にならない」 の略で、今すぐ必要とされていない機能に時間 を投資することに反対します。 47
48. YAGNIが言及しているコスト The less code in the project, the better. Introducing code just in case without an immediate need unnecessarily increases your code base's cost of ownership. 翻訳: プロジェクトのコードは少ないほど良 い。差し迫った必要性がないのに「念のため」 にコードを導入すると、コードベースの所有コ ストを不必要に増大させます。 48
49. YAGNIと品質保証 コード量が少ないほど、バグが潜む場所も 少なくなる 機能が少ないほど、システムの複雑さが抑 えられ、テストすべき組み合わせも減る 不要な機能は、将来の変更時に予期せぬ不 具合（デグレード）の原因となりうる 49
50. 僕が実際に使っている問いかけ方例 「この要件/仕様ってなんで必要なんでしたっ け？」 要件/仕様がなんの価値と結びついているの かわからなくなったときに聞いている 「 【梅案】だとこういう感じで【竹案】だとこ んな感じでして、 【梅案】のほうが実装コスト は軽いんですが困ることってありそうです？」 隅付き括弧の中は案に名前をつけて言うこ とが多い 梅からいくと、上位の松竹にした理由を回 収しやすい 50
51. 松竹梅メソッドを使うとき になぜ梅から考えると良い か コストは精緻に計算しやすい一方 で、価値（顧客がどれくらい満足し たのかなど）が本当にあったのかは 計測しづらい 　→価値ある最小限の機能を提供 し、起きた反応を経験して判断材料 をためると良い 51
52. 4. おわりに 52
53. 明日からはじめやすいアクション Claude Code や Codex CLI などのAIツールを使って、普段コード読まない方でもコ ードを落としてきて 「hogeというパスの機能はどの程度複雑？また、どんなテストが存在してい る？」 などざっくり聞くことから始めても少しずつ理解できていける 開発が進んでいく中で、どんな価値を実現する機能なのかは抜けることがあるの で 「自分だけわかってなかったらすみません、このデータ連携でリアルタイム性が 必要な理由はなんでしたっけ？」 とMTGやslackで疑問を潰しておくと、チームとしても再認識できて良い 53
54. まとめ QA（にかかわらずチーム全員）は 設計段階から品質を作り込むことで最大の価値を発揮できる 54