🧪
【Test】試験項目と全く関係ない不具合は、責任者に確認した上で別件として上げるのが基本

2025/07/04に公開
 はじめに
試験項目と無関係なバグ報告が現場に及ぼす影響と対策。

 対象チケット駆動型の開発体制で、開発と試験の混線に悩んでいる方向け。

 失敗事例これはTwitterでも常々言及していますが。
事例をあげるときは、複数の現場で目撃した事象を出しています。アンチパターンも、アンチパターンを形成する土壌も、ある程度パターン化されているように見えます。

 失敗事例：別件で不具合報告
チケットの内容は画像素材の差し替えのみでした。開発者視点で不具合が起きるとすれば、差し替え対象の画像を取り違えるか、既存のキャッシュ設定の不備くらいでしょうか。開発環境はもちろん検証環境にデプロイした後も試験項目を確認してから、試験担当者に渡しています。
ところが全く関係のないアニメーション処理のCSSやJavaScript側のバグがいくつも追記されることになりました。バリエーションのある画像のうち、ある種類の画像に別の種類の画像が表示されているだとか。ある画面幅でデザインが崩れてしまうとか。
URL直打ちでは素材は正しく表示されており、作業は仕様通りに完了しています。画像の差し替え作業の有無に関わらず、この現象は発生します。
別チケットとして起票して、修正方針を決めてから対応しましょうと打診すると。ここから先は現場によって様々なのですが、「ついでにパパッと直してよ」パターンで追加の工数や期日調整すらない現場はヤバかったですね。

 失敗事例：同じチケットで仕様変更
それなりに大きな改修で、親チケットの下にいくつもの小チケットが登録されているようなケースです。リリースのタイミングなど調整が必要なため、feature用のmainブランチに集約した変更を、時期が来たらmainにマージ、検証環境にデプロイするようなフローです。
アジャイルとはいいつつも、ここだけ切り出すとウォーターフォールのよう。このためどうしても検証環境での動作確認が後手に回ります。そしてある子チケットの修正と既存機能との兼ね合いで、より使いやすくするための仕様変更がしたいという要望が出ました。
このとき同チケットのステータスを差し戻して修正するパターンと、新しく仕様変更用のチケットを作成して検討から入るパターンとありました。結論からいくと後者がベストプラクティスです。前者は要件や仕様の考慮漏れ、スケジュール調整が上手くいかないなど、問題が多発しました。

 影響と問題点
 タスクのゴールが変更され続ける
開発者はチケット単位でタスクを進めます。開発者はチケットを受け取ると、作業内容と終了条件を確認します。現場によって仔細は異なりますが、開発チケットであれば通常はmainブランチにマージするまでで一区切りです。
ところがチケットの本題に全く関係のない、仕様変更や不具合を一緒に対応してしまうと、終了条件にそれらの追加事項が追加されます。仕事がいつまで経っても終わりません。つまりゴールポストを後から動かす、マネジメントのアンチパターンです。
後から条件を付け加えたため、元々発生しない作業が追加されていますが、「ついで」で期日や工数の見直しが入らなかったり、今後の計画に支障が出たり。状況把握が難しくなるためです。開発者のモチベ低下はもちろん、試験実施者やマネージャーへの信用も減ります。

 要件・仕様・実装・試験観点に差異が生じる
この手の仕様変更・不具合報告がされるタイミングは、試験段階に入ってからです。多くは検証環境にデプロイされた後、開発者ではない誰かが確認します。この段階での軌道修正は想定以上にコストがかかるものですが、大抵は場当たり的に目に付く部分だけを取り入れようとします。
すると一部の実装と試験観点だけが増築されたアンバランスな状態です。要件や仕様を含めての見直し、アプリ全体を見たときの整合性は担保されていません。開発者は気が付いているかもしれませんが、先述のモチベ低下が原因で深く言及はしないでしょう。
結果、責任者が修正する段階になって仕様不備が見つかったり、全く別角度からの解決策が後で見つかって、増築部分の削除という仕事が増えたりします。

 コミュニケーションコストが増加する
日本語は主語を省略しがちな言語です。これが英語なら必ず主語が必要なため、多少なりともマシだったかもしれません。同じチケットやスレッドで複数の議題について触れ始めると、議題が増えすぎてどれのことを言っているのか分からなくなっていきます。
開発者も試験実施者も、マネージャーでさえ混乱するでしょう。「直りました！」という報告に対し「どれが？」という言葉を堪え、特に問題がなければと空気を読んで終了すると、別件が直ってなかったというオチが付く二段構え。
試験観点にも関係のない項目が増えているので、試験実施者も混乱します。試験漏れが発生したり、本来実施すべき試験がおろそかになったり。それがそのまま他のメンバーの作業にも伝播してしまいます。

 対策
 仕様相談チャンネルを設置する
『不具合・障害報告チャンネル』では駄目でした。チャンネルに投稿する前にバグかどうかの判断が求められますし、仮に確認のために投稿したとしても容疑者の疑いをかけていることになってしまうためです。
誰でも気軽に投稿ができる、気になる動作の相談という体でチャンネルを作成しておきましょう。こうすることで不透明な仕様も怪しい挙動も、全てこのチャンネルにスレッドを立てて確認ができるようになります。新規参画者も迷ったら聞ける場所として活用できます。
こうして場所を用意すれば、作業チケットや試験スレッドとの切り離しができます。履歴としても追いやすく、後から見ても主題が明確で分かりやすいです。チケット1つにつき1つの改修、スレッド1つにつき1つの話題は、会話が混乱しないためのノウハウです。

 疑わしきは罰せず
試験中に見つけたおかしな動作は、本当に不具合なのでしょうか。これもよくある話ですが、確認をする前にバグや仕様漏れだと決めつけ、起票までしてしまう方は一定数観測されます。容疑者扱いされて気に障らない開発者なぞいません。相談という形であれば角も立ちません。
まずはプロジェクトの責任者や開発者に相談です。既存バグや仕様であればそこで話は終わりですし、対象のチケットに関係があるかないかは調べないと分からないこともあります。
バグかどうかの判断は発見者が独断で即断するものではなく、チームで議論しながら行うべき判断です。また開発者もよく調べずに「仕様です」と即答するのはやめましょう。

 半分は配慮と優しさ
伝え方一つで、現場のコミュニケーションが円滑になりもすれば、殺伐としたギスギスしい空気にもなります。『バグを憎んで人を憎まず』という言葉があるように、犯人探しや責任の所在の追求をするのではなく、バグが発生しないように組織の仕組としてどう改善していくかです。
個人的な感情や仕事が終わらない苛立ちを、個々の開発担当者にぶつけるのではなく、次に同じことを繰り返さないために自分にできる範囲のことをします。裁量が少なく責任者も重要視していないのであれば、改善の見込みはないので早めに見切りを付けた方がいいかもしれません。

 方針決定が済んでから別チケットで
仕様変更が必要になった場合、まずは方針決定のためのチケットを作成します。議論の中で対応が必要だと判断された時点で、新たな設計チケットや開発チケットを起票すればよいのです。
もしプロジェクト予算的に厳しいようであれば、来期への見送りもあるでしょう。事業計画によってはリリース時期の調整も必要かもしれません。
関連チケットや発見場所の試験スレッドURLを記載しておけば検索性も確保できます。

 おわりに
試験中に不具合を見つけてもらえるのは有り難いことです。ベテランテスターの方には何度助けられたか分かりません。開発者やマネージャーへの情報連携もスムーズで、彼ら曰く「報告が活きるところまでがテスト」らしいです。受け売りです。見習いましょう。