2025.09.17
SCOグループ 情報システム本部の榊です。
2021年4月に入社し、現在は5年目になりました。
表題のとおり、入社1年目のころにテスト項目書の運用でとても苦労した経験があります。
本稿では当時の状況と、5年目の今だからこそ言語化できる学びをまとめます。
はじめに
当時の情報システム本部は、今と比べると小所帯で業務を回していました。
私が作成したテスト項目書は、 部内メンバーなら問題なく実行できる程度の抽象度にとどめていました。
属人化を避けつつ、効率よく進めたい──そんな思いがありました。
ところが……
テスト開始のタイミングで案件が重なり、部内だけでテストの打鍵（実操作による実行）を賄えないことが判明。
営業部門の新人メンバーにも参加してもらうことになりました。
その瞬間、「これはまずい」と直感したのを、今でも鮮明に覚えています。
私の項目書は、部内の前提知識がある人向けに書かれていたからです。
結果は……
スケジュール自体はなんとか守れました。
しかし、想定工数を大幅に超過し、最終的には勤務時間を延ばす力技の対応で乗り切る形に。
現場は疲弊し、効率化どころかコスト増に。これが当時の正直な結末です。
原因と事象（1年目の私のつまずき）
主な要因は大きく2つでした。
– 実行者がシステムの専門家だという思い込み
– 抽象度が高すぎる項目
この結果、例えば「〜〜〜画面に遷移することを確認」とだけ書かれた項目に対して、次のような疑問が頻発しました。
– 「その画面ってどの画面？（正式名称や到達パスが不明）」
– 「前の画面にはどうやって行くの？（前提ログインや権限、メニュー位置が不明）」
当たり前”が当たり前ではないことを、痛いほど思い知りました。
失敗の本質
今振り返ると、課題の本質は次の一点に尽きます。
＞ テスト項目書を”誰でも実行できるオペレーション設計”として書かなかった。
抽象化そのものが悪いわけではありません。
実行者の前提知識と経験値に適合していない抽象化が問題でした。
改善のヒント（次に同じ失敗をしないために）
下記2点を意識し、テスト開始前に実行することにより、工数の増大を避けることができたように思えます。
1. 用語集を作成する
– 「一覧画面」「検索結果画面」などの 呼称ルールをドキュメント先頭に
– 未経験者が実行することを踏まえ、迷いゼロを目指す（固有名詞・画面名・メニュー階層・ボタンラベルを明記）。
– 経験者が打鍵するにしろ、あって困ることはありません。
2. 最初の30分で疑問の解決・試しに一緒に実行する
– 代表ケースを一緒に1〜2本走るだけで、以降の解釈ズレを激減させることが可能。
– テスト開始よりまえにわからない箇所の認識を合わせる。
おわりに
誰もが迷わず実行できる──その視点を最初に置くだけで、後工程の混乱は驚くほど減ります。
私の1年目の失敗が、皆さんの現場での設計改善のヒントになれば幸いです。