こんにちは、decoponです。
「仕様書の修正、今日中にお願いね」
──その一言で始まった1日。
でも実際は、操作の理解から始めて、仕様の確認、観点の整理、レビュー対応までで、まるっと1日かかってしまいました。
この記事では、そんな 「仕様書修正に1日かかった」背景を分解しながら、
“操作理解から始めるテスト設計”でどこに時間がかかるのか を整理してみました。
🧠 そもそも、なぜそんなに時間がかかったのか？
| ステップ | 実際にやっていたこと | 時間がかかった理由 |
|---|---|---|
| 操作理解 | システムを触って動作確認 | UIが直感的でなく、前提知識が必要だった |
| 仕様確認 | 仕様書・過去チケット・口頭情報を確認 | 情報が分散していて、読み解くのに時間がかかった |
| テスト観点の整理 | 正常系・異常系・境界値などを洗い出し | 仕様が曖昧な部分が多く、想定パターンが膨らんだ |
| 修正作業 | テスト仕様書の修正・追記 | フォーマットが複雑で、整合性を保つのに神経を使った |
| レビュー対応 | 指摘を受けて再修正 | 「観点わかってますか？」的な抽象指摘に翻弄された |
🛠️ 操作理解から始めるテスト設計で気をつけたいこと
✅ 1. 「操作理解」も立派な作業として見積もる
- 仕様書修正＝“書くだけ”ではない
- 「理解する」フェーズに時間がかかるのは当然
✅ 2. 情報ソースを“一覧化”しておく
- 仕様書、画面設計書、過去チケット、口頭伝承…
- → どこに何が書いてあるかを最初に整理するだけで時短になる
✅ 3. テスト観点を“見える化”して伝える
- 「この修正は〇〇の観点を意識しました」
- → 意図が伝わると、レビューの指摘も減るし、“観点わかってますか？”防止にもなる
💬 おわりに
仕様書修正に1日かかるのは、“理解しようとしている証拠” です。
むしろ、操作も仕様も曖昧なまま書いた方が、後で手戻りが大きくなる。
この記事が、
- 同じように「修正に時間かかってしまった…」と落ち込んでいる人
- 「操作理解から始めるテスト設計って、どこが大変なの？」と感じている人
の、小さな安心材料になれば嬉しいです📓🌿