単体テストのエビデンスはExcelにスクショ？SES現場の取り方

単体テストが終わったら、画面をキャプチャしてExcelに貼り、次のケースに移る。この繰り返しに、テストそのものより時間を取られた経験はないでしょうか。

私はSESエンジニアとして5年ほど、4社の客先常駐現場を渡り歩いてきましたが、そのうち4社目では、この証跡作業がほぼ毎日の作業として組み込まれていました。

今回は、その現場で実際にどんな粒度・手順でエビデンスを作っていたか、なぜExcelとスクショなのか、そして自衛のためにやってきた工夫を、実体験からお伝えします。

目次

1. SESの単体テストでエビデンスをExcelに貼るとはどういう作業か
2. なぜエビデンスはExcelとスクリーンショットなのか
3. 誰も経緯を知らない、フレームワークだけじゃない
4. 1テストケースに何枚のスクショが必要なのか、粒度の実態
5. 元請けと客先、温度差のある要求
6. 見本にしたのは3年以上前のファイル
7. 実際にどれくらい時間がかかったのか
8. 差し戻しをくらった話
9. ツールを使えない現場での自衛の工夫
10. 効率化の議論はどこにあったのか
11. まとめ

SESの単体テストでエビデンスをExcelに貼るとはどういう作業か

4社目は二次請けとして入った、社内向け業務システムの改修案件でした。客先は独自の社内フレームワークを使っていて、なぜこのフレームワークを選んだのか、経緯を知っている人がプロパー社員を含めて現場に誰も残っていませんでした。単体テストのエビデンス作りは、この現場で最初にまとまった単体テストを任されたときに、初めて経験することになりました。

渡されたのは、客先指定のExcelテンプレートです。

エビデンスという言葉自体、狭い意味ではこの「操作の証跡としてのスクリーンショット」を指しますが、広い意味では設計書やテスト仕様書とのひも付けまで含めて、後から誰が見ても「その通りに動いたこと」を確認できる一式を指します。今回書くのは、そのうち一番手間のかかる、狭い意味でのスクリーンショットのほうです。

なぜエビデンスはExcelとスクリーンショットなのか

結論客先側が「Excelさえ開ければ確認できる」ことと、開発者を全面的には信用しない文化・責任所在の可視化が組み合わさって、この形式が続いていると私は見ています。

この形式そのものは、4社目に限らず業界で広く見られるものだと思います。似た経験を書いているブログを読むと、Excelが選ばれる理由として、客先側が特別なツールを入れなくても「Excelさえ開ければ確認できる」という点が挙げられています。実際、4社目でも客先側の確認担当は開発環境に直接アクセスできる人ばかりではなく、共有フォルダに置かれたExcelを開いて確認する運用でした。

SIerでエクセルにスクリーンショットで証跡を取らせる理由を扱った記事では、この慣習の背景が次のように指摘されています。

開発者を信用しきらない「性悪説」に近い文化と、何か問題が起きたときに誰の責任かをはっきりさせておきたいという、責任所在の可視化という側面がある。

自分の現場で見ていても、これは的外れではないと感じます。テストをやったと口で言うだけでは、後から検証できません。画面のキャプチャという形で残すことで、少なくとも「その時点でその画面がこう表示された」という一点だけは客観的な事実として残ります。

同じ記事では、成果物の検証を自動テストで担保するインターネット企業と、目視の証跡に頼りがちな受託開発の文化との対比にも触れられていました。私がこれまで経験した現場は例外なく後者で、CI上で自動テストが回っている環境に配属されたことは一度もありません。だからこそ人の目と手が最後の砦になっていて、Excelとスクショという原始的な方法が今も生き残っているのだと思います。

誰も経緯を知らない、フレームワークだけじゃない

もっとも、なぜこの3点セット(操作前・入力後・実行結果)という粒度なのか、テンプレート自体にも手順書にも書かれていませんでした。リーダーからは「基本はこの3点で、前任もそうやっていました」と口頭で説明されただけです。

参画から半年ほど経ったころ、共有フォルダの奥で「エビデンス取得_自動化検討」という趣旨のファイル名の古い資料を見つけたことがあります。更新日は2年以上前で止まっていて、内容は自動キャプチャツールの導入を検討した形跡があるだけでした。

実際に導入された様子はなく、なぜ立ち消えになったのかも分かりません。フレームワークの選定経緯だけでなく、証跡の取り方の経緯までもが誰にも説明できない状態だったわけです。

仕組みだけが残り、理由は失われていく。この現場で何度も見た構図でした。

1テストケースに何枚のスクショが必要なのか、粒度の実態

結論決まった正解はなく、プロジェクトごと、あるいはリーダー個人の判断でばらついています。私の4社目は、操作前・入力後・実行結果の3点セットでした。

これは検索してもはっきりした正解が出てこないテーマだと思います。実際、明確な基準は存在せず、プロジェクトごと、あるいはリーダー個人の判断でばらついているのが実態です。4社目で決まっていたのは、次のようなローカルルールでした。

異常系のケースでは、この3枚に加えてバリデーションメッセージの再表示確認用に1枚を追加することもありました。テンプレートの列自体は決まっていても、実際に何を撮るかは現場の慣習頼みだったのです。

元請けと客先、温度差のある要求

粒度に正解がないことを一番実感したのは、客先と元請けとで求める内容が微妙にずれたときでした。

客先のリーダーは3点セットで十分だと繰り返していましたが、あるとき元請けの担当者からチャットで依頼が来たことがあります。

客先向けの成果物としては求められていなかった内容でしたが、元請けが客先に納品する前の社内チェックとして、独自に基準を上乗せしていたようでした。結局、以降の異常系ケースにはエラーログのキャプチャも1枚追加することになりました。

同じプロジェクトの中でも、成果物を直接受け取る客先と、その手前でチェックする元請けとでは、求める粒度が違うことがあります。二次請けの立場では、どちらの基準に合わせるかを自分で決める権限はなく、結局は言われた方に両方合わせるしかありませんでした。

見本にしたのは3年以上前のファイル

参画したての頃、「とりあえず前任がやってたやり方を真似してください」と言われ、共有フォルダの過去フェーズのエビデンスファイルを見本として渡されました。開いてみると、画面のボタン配置が現行バージョンと微妙に違っていました。

この現場のフレームワークの手順書は最終更新が約3年前で止まっていて、実際の画面と食い違う箇所があると分かっていましたが、エビデンスの見本も同じように更新されないまま参照され続けていたのです。

手順書とエビデンスの見本、どちらも「更新する係」が決まっていないという同じ構造の問題が、別の場所で同時に起きていたのだと今は思います。

実際にどれくらい時間がかかったのか

数字で書いた方が実感が伝わると思うので、実際にあった1件のチケットを例に出します。テストケースは13件で、そのうち12件が通常のケースで3枚ずつ、残り1件の異常系だけ4枚必要だったため、スクリーンショットの合計は40枚でした。

13ケース・スクリーンショット40枚のチケット1件にかかった時間。

内訳をざっくり計算すると、40枚のうち1枚あたり2分ほどです。キャプチャして、余分な部分をトリミングし、Excelのセルに合わせて貼り、隣の列にケース番号のキャプションを打ち込む。

この一連の動きを40回繰り返した数字です。証跡作業の方が、テスト消化そのものより2倍以上長くかかっていたことになります。

日経xTechの「いまだはびこるExcelスクショ」という記事でも、レガシー現場での証跡作業がテスト実施者の大きな負担になっている実例が紹介されていて、NTTコムウェアがSeleniumやImageMagickを使って自動化を進めた事例が取り上げられています（出典: いまだはびこるExcelスクショ｜日経xTECH）。

裏を返せば、それだけ自動化したくなるほど、証跡作業は時間を食う作業だということです。自分の現場ではそこまでの自動化には手が届きませんでしたが、負担の重さは業界で共有されている実感なのだと確認できました。

差し戻しをくらった話

金曜日、リモート勤務の日に、ある改修チケットの単体テストを進めていました。異常系のケースで「実行結果」だけキャプチャして、「操作前」を撮り忘れたまま提出してしまったことがあります。

週明け、客先のリーダーからチャットが届きました。

撮り直そうとしたところ、比較対象にしていたテストデータが月曜朝のバッチ処理でリセットされる仕様だったため、金曜時点と同じ状態をもう一度作れません。

担当のプロパー社員にデータを個別に戻してもらう依頼を挟むことになり、撮り直しが完了するまで3日ほどずれ込みました。

ポイント： エビデンスの抜けは、テストのやり直しよりも「同じ状態をもう一度再現できるか」というところで詰まります。

テストデータが日次やバッチで変わる仕様の環境では、撮り忘れに気づいた瞬間に動くのが一番早く、翌日以降に回すほど再現コストが上がっていきます。

ツールを使えない現場での自衛の工夫

見た目がよく似た画面が続くテストほど、後でまとめて処理すると事故が起きやすいのだと、この一件で身をもって学びました。

この現場は独自フレームワークの縛りとセキュリティ上の制約があり、外部の自動化ツールやオンラインサービスを導入する選択肢はありませんでした。それでも、手元でできる工夫はいくつかあります。

どれも地味な工夫ですが、証跡作業にかかる時間の総量そのものは減らせなくても、事故の確率と手戻りの規模は確実に減らせます。ツールを導入する権限がない立場でも、手を動かす順番を変えるだけでできることは意外とありました。

この4つを回すようになってから、証跡がらみの差し戻しは体感で目に見えて減りました。効率化というより、事故を起こさないための工夫だったというのが実感です。

効率化の議論はどこにあったのか

結論現場には見当たりませんでした。二次請けの立場では、テスト工程のやり方を変える提案は契約範囲の外側の話になりがちで、口を出せる余地がなかったからです。

先ほど触れた「エビデンス取得_自動化検討」という古い資料は、誰が作ったのか、なぜ立ち消えになったのか、現場に残っている情報からは分かりませんでした。二次請けという立場では、テスト工程のやり方そのものを変える提案は、契約範囲の外側の話になりがちです。

日経xTechの記事にあったSeleniumやImageMagickによる自動化にしても、テストの実行基盤そのものに手を入れる話です。改修チケット単位で作業を請け負う二次請けの立場では、そこに口を出せる契約範囲にも、時間的な余裕にもなっていませんでした。

3社目のときに出したバリデーション処理の共通化のような技術寄りの提案は、課題票に載るところまで進んだことがあります。一方で、証跡の取り方という運用寄りの話にまで手を伸ばす余地は、どの現場でもありませんでした。3社目の保守改善では、リリース手順の証跡・ドキュメントの作成が多く、重いと感じていました。リモートは週1〜2日でしたが、証跡の取り方という運用面まで手を伸ばす余地はありませんでした。

リモートの運用ひとつを見ても、現場によって働き方の幅は違います。証跡作業に割ける裁量の幅も、現場ごとに違うのだと思います。

まとめ

SESの単体テストでExcelにスクリーンショットを貼るという作業は、私が経験した4社目に限らず、業界で広く定着している慣習のようです。Excelさえ開ければ客先側も確認できるという実務上の理由と、開発者を全面的には信用しない性悪説に近い文化が組み合わさって、この形式が続いているのだと理解しています。

一方で、1テストケースに何枚のスクショが必要かという粒度には、決まった正解がありません。4社目では操作前・入力後・実行結果の3点セットというローカルルールがありましたが、これは手順書にも明文化されておらず、口頭と過去の見本ファイルだけで伝承されているものでした。しかも客先と元請けとで求める粒度がずれることさえあり、二次請けの立場ではその都度合わせるしかありませんでした。

これから客先常駐でこの作業に入る方は、テンプレートの列だけを見て粒度を推測せず、リーダーに次の2点を早めに確認しておくことをおすすめします。

撮り忘れに気づいてから動くよりも、最初に基準を聞いておく方が、結果的に手戻りは少なくて済みます。証跡作業そのものをなくす権限は、私のようなメンバーの立場にはありませんでした。

それでも、ショートカットの見直し、命名規則の統一、操作直後に貼る運用、データそのものの置き換えといった、手元でできる工夫を積み重ねることで、事故の確率と手戻りの規模は自分の裁量でも減らせます。地味な作業だからこそ、そこにどれだけ手間をかけて向き合うかで、証跡作業にかかる総時間は現場ごとに変わってくるはずです。