株式会社ラフティ | Time Craft Consulting
Chapter 5 テスト・受け入れ
「 問題を見つける工程」を壊さない
テスト工程は、ITプロジェクトにおいて
最も誤解され、最も軽視され、最も責任を押し付けられる工程です。
多くの現場では、テストはこう扱われます。
-
開発が終わった後にやる作業
-
スケジュールが厳しければ削ってよい工程
-
バグが出たら誰かを責めるための工程
しかし断言します。
テストが壊れているプロジェクトは、すでに失敗しています。
どれだけ設計や開発が正しくても、
テストが「正しく機能していなければ」プロジェクトは破綻します。
5-0. テスト工程が壊れる典型パターン
失敗プロジェクトでは、テスト工程が次のように扱われます。
-
テスターが足りないまま開始される
-
スケジュール最優先で実施される
-
バグが出ると責任追及が始まる
-
仕様漏れと不具合が混同される
-
すでに「リリース前提」で進行している
この状態で行われるテストは、
**テストではなく「儀式」**です。
問題を見つけること自体が歓迎されず、
見つければ見つけるほど、現場から嫌われます。
5-1. テストは「品質を証明する工程」ではない
まず、この誤解を完全に捨てる必要があります。
テストは品質を証明する工程ではありません。
テストの本質はただ一つです。
問題を見つけて、止めること
テストで何も問題が出なかったとしても、
それは「品質が高い証明」ではありません。
-
テスト観点が足りない
-
テストケースが甘い
-
時間や人が足りない
この可能性の方が、圧倒的に高いのです。
5-2. テスターが悪者になる構造
多くの現場で、テスターはこう扱われます。
-
「そんなところまで見る必要ある？」
-
「それ、今さら言われても困る」
-
「もう直してる時間ないから」
これは、テスト工程の失敗ではありません。
プロジェクト設計の失敗です。
問題は、テスターではなく、
-
テスト人員を計画に含めていない
-
テストの目的を共有していない
-
バグを成果として扱う文化がない
この3点です。
5-3. バグは「責任」ではなく「成果」である
テストでバグが出ると、
誰が悪いかの議論が始まるプロジェクトは、必ず壊れます。
正しい考え方は、真逆です。
バグは成果です。
-
本番で事故を起こさずに済んだ
-
利用者を守れた
-
会社の信用を守れた
これは、テストが正しく機能した証拠です。
テスト工程で責任追及が始まった瞬間、
誰も問題を見つけなくなります。
5-4. 仕様漏れと不具合を混同してはいけない
テスト工程が地獄になる最大の原因が、これです。
-
仕様に書いていない → 不具合
-
期待と違う → バグ
この混同が、すべてを壊します。
正しくは、こう分ける必要があります。
-
仕様漏れ：決めていなかったこと
-
不具合：決めた通りに動かないこと
仕様漏れは、設計・要件定義の問題です。
不具合は、実装の問題です。
ここを分離できないプロジェクトは、
永遠に議論が終わりません。
5-5. リリース可否を「テスト」に押し付けてはいけない
最もやってはいけないのが、これです。
「テストでOKが出たらリリースしよう」
これは一見正しそうに見えますが、完全に間違いです。
リリース判断は、経営判断です。
-
残っている不具合の内容
-
影響範囲
-
法的・業務的リスク
-
回避策の有無
これらを踏まえて、
誰がリリースを決めるのかを明確にしなければなりません。
テスト工程は、
「判断材料を揃える役割」であって、
「判断する役割」ではありません。
5-6. テスト・受け入れフェーズのまとめ
テストとは、
品質を証明する工程ではない。
問題を見つけて止めるための、最後の防波堤である。
この思想を共有できないプロジェクトは、
どれだけ努力しても、必ず同じ失敗を繰り返します。