月に一度の機能改修。リリース予定日の3日前になると、システム担当の田中さん(仮名)は自分のデスクにノートパソコンとチェックリストを広げ、全画面を一つずつクリックして回る作業に入る。ログイン画面、受注一覧、見積書発行、在庫引当、請求書出力。画面数にして47。項目にして200近く。ひとつひとつ「表示されるか」「保存できるか」「計算が合っているか」を目で確認し、紙のチェックリストに手書きでレ点を入れていく。
3日間、ほぼこの作業だけに時間を使う。途中、電話が鳴れば手を止め、確認していた場所を忘れないように付箋を貼る。集中力が切れる夕方には、同じ画面を二度見ているのに気づかないまま次に進んでしまうこともある。それでも田中さんは、この地道な確認作業こそが会社のシステムの品質を守っている自負があった。
ところがある改修で、事件が起きた。単価計算のロジックを一部変更した際、影響が及ぶはずのない「見積書の消費税端数処理」にまで波及していたのだが、チェックリストにその項目がなかったため誰も気づかなかった。本番リリース後、得意先から「見積金額が1円合わない」と指摘が入り、原因調査に丸一日、修正とお詫びの連絡に半日を費やすことになった。田中さんに落ち度があったわけではない。200項目を3日間かけて確認し続けた結果、たまたますり抜けた一箇所だった。それだけの話だ。しかし本人は「自分の確認が甘かったのでは」と何日も引きずっていた。
この記事は、そんな田中さんのような担当者に向けて書いている。手動での動作確認に限界を感じ始めている人、あるいは開発会社から「テスト自動化を導入しませんか」と提案されたものの、費用と効果が釣り合うのか判断がつかずにいる人。テスト自動化は魔法の杖ではないが、正しく使い所を見極めれば、田中さんが背負ってきた重荷を確実に軽くできる。逆に見極めを誤ると、投資しただけで何も変わらない、ということも起こり得る。判断のための軸を、順を追って整理していく。
なぜ手動テストは、ある時点から限界を迎えるのか
手動でのテストが機能しなくなるのは、担当者の能力が落ちるからではない。システムというものの性質上、避けられない構造的な理由がある。
第一に、確認すべき範囲は改修のたびに積み上がっていく。新しい機能を1つ追加すれば、その機能単体の動作確認だけでなく、既存の機能との組み合わせで問題が起きていないかも確認する必要が出てくる。運用を始めた当初は画面数も少なく、確認に半日もあれば足りていたはずのシステムが、3年、5年と改修を重ねるうちに、気づけば全画面確認に3日かかる規模に膨れ上がっている。これは特定の会社の管理不行き届きではなく、システムが育っていく過程で誰にでも起こることだ。
第二に、手動確認の品質は、確認する人の集中力と体調に依存してしまう。人間である以上、1日目の午前中と3日目の夕方とでは、同じ丁寧さで画面を見られているとは限らない。しかも確認項目が多くなるほど「毎回同じことをやっている」という感覚が生まれ、注意力が慣れによって鈍る。これは個人の意識の問題ではなく、単純作業を繰り返す人間の脳の仕組みそのものだ。
第三に、確認する担当者が特定の一人に集中しやすい。会社の業務システムの隅々を把握しているのはたいてい一人か二人で、その人が休めばリリースが止まる、あるいはその人が退職すればシステムの品質を守れる人がいなくなる、という属人化のリスクを抱え込むことになる。田中さんが3日間つきっきりで確認作業をしているあいだ、本来やるべき別の業務改善や問い合わせ対応は後回しにされている。それもまた、見えないコストだ。
テスト自動化とは何か、何ができて何ができないのか
テスト自動化と聞くと「システムのテストを全部AIやツールに任せて、人は何もしなくてよくなる」というイメージを持たれることが多いが、これは誤解だ。実態はもっと地味で、もっと限定的なものだ。
テスト自動化とは、あらかじめ「この操作をしたら、この結果が返ってくるはずだ」という確認手順をプログラムとして書いておき、それをボタン一つ、あるいはスケジュールで自動的に実行させる仕組みのことを指す。たとえば「見積書入力画面で単価1000円・数量3個を入れたら、合計金額が3000円と表示される」という確認を、人間がクリックして目で見る代わりに、プログラムが自動でクリックして結果を検証する。
ここで重要なのは、自動化できるのは「あらかじめ想定できる、決まった手順の確認」に限られるという点だ。人間が「ここは何か変だぞ」と違和感を覚えて追加で調べるような、想定外の探索的な確認は自動化にはできない。田中さんが3日間かけていた作業のうち、決まりきった入出力の確認は自動化に置き換えられるが、「この画面、なんとなく表示が崩れている気がする」といった感覚的な違和感の発見は、依然として人の目に頼らざるを得ない。
また、自動化のプログラム自体もメンテナンスが必要な資産である。画面のレイアウトが変われば、確認手順のプログラムも書き直す必要がある。導入すれば未来永劫メンテナンスフリーになる、というものでもない。この点を理解せずに導入すると「思ったより手がかかる」という不満につながりやすい。
自動化に向いている業務、向いていない業務の見極め方
すべての確認作業を自動化しようとすると、費用も労力もかさむ割に効果が薄い。見極めるべき軸は次の3つだ。
- 繰り返しの頻度が高いか。月に1回程度しか実行しない確認より、リリースのたびに毎回必ず通す確認のほうが自動化の恩恵は大きい。
- 結果が明確に「正解・不正解」で判定できるか。金額計算、在庫の増減、ステータスの変化など、数値や状態が一意に決まるものは自動化しやすい。逆に「デザインの見た目が美しいか」「文言の言い回しが適切か」といった感覚的な判断は自動化に向かない。
- 一度不具合が出た場合の影響が大きいか。請求金額の計算、受発注データの連携など、間違えると得意先や取引先に直接迷惑がかかる箇所は、優先的に自動確認の対象にする価値が高い。
逆に、月に一度しか使わない管理画面の細かい設定項目や、頻繁にデザインが変わるトップページのような箇所は、自動化のプログラムを書く労力に見合わないことが多い。田中さんの会社であれば、受注・見積・請求まわりの金額計算は自動化の優先候補になり、社内向けのお知らせ機能のような使用頻度の低い画面は、当面は手動確認のままでよい、という判断になる。
中小企業が自動化に踏み切るべきかどうかの判断軸
「テスト自動化は大企業のもの」と思われがちだが、実際には規模よりも次の3つの数字で判断すべきものだ。
- 改修の頻度。月に1回以上、システムに手を入れているなら自動化の投資は回収しやすい。年に1、2回程度の改修であれば、手動確認のままでも大きな支障は出にくい。
- 確認が必要な画面数。おおよそ20画面を超えてくると、人力での網羅的な確認に無理が出始める境界線になる。
- 手動確認に実際どれだけの工数がかかっているか。田中さんの例で言えば「3日間×日給換算」を年間の改修回数分だけ掛け合わせると、見えていなかった人件費が数字として立ち上がってくる。この数字と、自動化の導入・保守にかかる費用を並べて初めて、投資判断ができる。
逆に言えば、月1回未満の改修頻度で、画面数も10程度、確認工数も半日で済んでいるようなシステムであれば、今すぐ自動化に踏み切る必要はない。無理に導入して、使わない仕組みのメンテナンス費用だけがかかる、という本末転倒を避けるためにも、この見積もりは必ず自社の数字で行ってほしい。
導入のステップと現実的な始め方
自動化を検討する会社が最も陥りやすい失敗は「全画面、全項目を一気に自動化しようとすること」だ。これは費用も期間も膨らみ、途中で頓挫する典型的なパターンになる。現実的な始め方は、次の順序を踏むことだ。
- まず、自社にとって金銭的な影響が最も大きい機能を1つか2つに絞る。見積・請求・在庫連携など、間違えたときの被害が大きい箇所からで良い。
- その機能について「入力したら、こう表示されるはずだ」という確認手順を、これまで手作業でやっていたチェックリストをもとに書き出す。この段階では新しく発想する必要はなく、既存のチェックリストの言語化で十分だ。
- その手順を自動で実行してくれるツールや仕組みを、開発会社と一緒に構築する。最初は範囲を小さく、確実に動くものを作る。
- 実際に1、2回のリリースで運用してみて、確認漏れが減ったか、確認にかかる時間がどう変わったかを数字で振り返る。
- 効果が確認できた範囲から、対象の機能を少しずつ広げていく。
いきなり完璧な仕組みを目指すのではなく、田中さんが最も苦労している一箇所、最も不安を感じている一箇所から始めることで、投資対効果を早い段階で実感できる。その実感が、次の投資判断の材料になる。
よくある失敗パターン
導入を検討する際、事前に知っておくと避けられる失敗がいくつかある。
- 最初から全機能を対象にしてしまい、構築期間が半年以上に伸びて、その間に画面仕様のほうが変わってしまい、作りかけの自動化が使えなくなる。
- 自動化を導入すれば担当者の仕事がゼロになると期待してしまい、実際には手順の見直しや保守が発生することに気づいてがっかりする。
- 自動化の仕組みを外部の開発会社に完全に任せきりにしてしまい、社内に運用のノウハウが残らず、担当者が変わった途端に仕組みが機能しなくなる。
- 感覚的な見た目の確認まで無理に自動化しようとして、細かい調整に時間を取られ、本来自動化すべき金額計算などの確認が後回しになる。
これらはいずれも、自動化を「魔法の一括解決策」として捉えてしまうことから生まれる。自動化は、手動確認という営みの一部を機械に肩代わりさせる技術であって、確認という仕事そのものをなくす技術ではない。
まとめ
田中さんが3日間かけて画面をクリックして回る作業は、決して無駄な仕事ではなかった。むしろ、そこまでして品質を守ろうとしてきた姿勢こそが、会社のシステムをここまで運用できてきた土台だ。テスト自動化は、その姿勢を否定するものではなく、田中さんの努力のうち機械に任せられる部分を引き受け、本当に人の目と判断が必要な部分に時間を使えるようにするための道具にすぎない。
自社が自動化に踏み切るべきかどうかは、改修の頻度、画面数、そして今実際にどれだけの工数を手動確認に使っているかという3つの数字で判断できる。すべてを一度に変える必要はない。まずは最も被害の大きい機能から、小さく始めてみることだ。その一歩が、次の改修のたびに徹夜に近い確認作業に追われる担当者を、一人でも減らすことにつながる。