ROI事件ファイル No.485『人が見ていた十万行』
人が見ていた十万行
第一章：制度変更は、いつも突然来る
「先週、税制改正の情報が入りました。対応期限は三ヶ月後です」
TechFlow社のCTO、マイケル氏は、そう言いながら開発ボードを広げた。付箋が何十枚も貼られている。青はテスト項目、赤は未完了、緑は完了。赤の数が圧倒的に多い。
「改修自体は一週間で終わります」とマイケル氏が続けた。「問題はテストです。制度変更は、影響範囲が読みきれない。給与計算の一箇所を直すと、社会保険の計算にも、年末調整のロジックにも、帳票出力にも影響が波及する。全パターンを潰すためには、十万行以上のテストが必要になります」
「テストは現在どう実施していますか」とClaudeが確認した。
「九割以上が人力です」とマイケル氏が答えた。「パワーオートメイトを使っていますが、活用率は全体の十パーセント未満。ボリュームテストのような繰り返し作業だけ自動化している。細かい分岐、外部サービスとのデータ連携、UI確認——これらは全てエンジニアが画面を見て、手でパターンを入力して、結果を目視確認している」
「制度変更が来るたびに、どのくらい人員を投入しますか」とGeminiが尋ねた。
「直近の改修では、エンジニア七名が三週間、テストだけに張り付きました」とマイケル氏が答えた。「その期間、新機能開発はすべて止まります。競合が新機能を出している間、うちはテストに人員を取られている」
「テスト期間中に、バグの発見漏れは」と私が確認した。
「あります」とマイケル氏が答えた。「直近の改修後、本番リリースから二週間以内に三件の不具合が出ました。人間のテストでは、どうしても見落としが発生する。疲れてくると、同じパターンを何度もチェックしてしまったり、逆に飛ばしてしまう」
「自動化ツールを導入しようとした経緯は」とClaudeが尋ねた。
「何度か検討しました」とマイケル氏が答えた。「ただ、どのツールを選んでいいか分からなかった。AutoTestPro、Selenium系、Playwright、商用ツール——選択肢が多すぎて、社内で比較の基準が作れなかった。決められないまま、次の制度変更が来る」
「決める基準がないから、決められない」と私が静かに言った。「それがDESCが解決する領域です」
第二章：DESCが問う四つの段階
「この案件には、DESCが必要です」
Claudeがホワイトボードに四つの文字を書いた。D・E・S・C。
「DESCとは、Describe・Express・Specify・Chooseの四段階で、状況を整理し、選択肢を絞り込むフレームワークです」と私が説明した。「元はコミュニケーションの技法ですが、ツール選定にも応用できます。現状を記述し、自社の要件を表明し、必要条件を特定し、その上で選ぶ——この順序を踏むと、『選択肢が多すぎて決められない』状態から抜け出せます。TechFlow社は、この順序を踏まずにカタログ比較から始めていた」
「まず現状のコストを測りましょう」とGeminiがROI Polygraphを開いた。マイケル氏から提供されていた業務ログを入力する。
「月間のテストコストが出ました」とGeminiが読み上げた。「エンジニア平均十五名体制で、月間テスト工数が七百二十時間——全業務時間の約三十パーセント。時給五千円で月三百六十万円。制度変更対応時のテスト集中期間に発生する新機能開発の停滞——機会損失を月平均八十万円と試算。リリース後の不具合対応——本番障害の復旧・顧客対応・追加テストで月平均四十万円。合計で月四百八十万円が、テスト関連コストです。年間換算で五千七百六十万円」
マイケル氏がしばらく黙って画面を見ていた。「年間五千万円以上を、テストに使っているんですね」
「では、DESCで設計します」と私が続けた。
[D——Describe：現状を具体的に記述する]
「まず、テスト対象を分類します」とClaudeが言った。「マイケル氏のチームで実施しているテストを、四つに分ける。第一に、単純な繰り返し処理——ボリュームテスト、既に自動化済み。第二に、画面UI操作——ログイン、入力、ボタンクリック系。第三に、データ連携——APIを介した外部サービスとのやり取り。第四に、分岐条件——条件によって結果が変わるビジネスロジック」
「どれを自動化の対象にしますか」とマイケル氏が確認した。
「全部ではなく、優先順位を付けます」と私が答えた。「自動化に最も向くのは、繰り返し頻度が高く、パターンが明確なもの。この基準でランク付けすると、データ連携テストが最優先、次が画面UI、最後に分岐条件です。分岐条件は最も複雑で、自動化の費用対効果が低い領域です」
[E——Express：自社の要件を表明する]
「TechFlow社が自動化ツールに求める要件を言語化します」とGeminiが続けた。「マイケル氏、どんな特徴を最も重視しますか」
マイケル氏が少し考えた。「導入後のメンテナンス性です。テストスクリプトを書くのは大変でも、メンテナンスが大変すぎると結局人力に戻ってしまう」
「メンテナンス性が最重要」とClaudeが書き留めた。「次に、データ連携テスト——API呼び出しやレスポンス検証が標準機能にあること。三番目に、既存のパワーオートメイト資産との共存」
「表明すると、評価軸が三つに絞れます」と私が続けた。「選択肢を絞る前に、選ぶ基準を絞る。これがDESCの順序です」
[S——Specify：必要条件を特定する]
「三つの評価軸それぞれに、合否ラインを設定します」とGeminiが続けた。「メンテナンス性——コードに近い形式でテストスクリプトを書けること、GitでのバージョンTime管理が可能であること。データ連携——REST API、GraphQL、認証トークン管理に標準対応していること。既存共存——パワーオートメイトのワークフローを呼び出せるか、データを受け渡せること」
「この合否ラインを満たさない製品は、いくら他の機能が優れていても除外します」とClaudeが補足した。「完璧な製品はありません。TechFlow社にとって欠かせない要件だけを通過基準にすることで、選択肢が実質三、四製品に絞れます」
[C——Choose：絞り込んだ上で選ぶ]
「三製品に絞ったら、PoC——概念実証を実施します」と私が続けた。「各製品で、一番痛いテストケースを実際に自動化してみる。例えば、データ連携テストの代表的な一パターンを、三製品それぞれで構築する。構築時間、実行時間、保守のしやすさを比較すると、カタログ比較では見えない差が浮き彫りになります」
「ROI Proposal Generatorで試算しましょう」とGeminiが提案した。
- 初期費用：ツール導入・初期スクリプト構築・エンジニア研修費用合計四百二十万円
- 月次費用：ツールライセンス月十八万円
- 月次削減効果：テスト工数削減——初年度三十パーセント削減で月百八万円、制度変更対応時の機会損失削減＝月六十万円、不具合発生削減＝月二十五万円、合計月百九十三万円
- 月次純削減：百九十三万円－十八万円＝月百七十五万円
- 投資回収期間：四百二十万円÷百七十五万円＝約二・四ヶ月
「二・五ヶ月以内の回収です」とGeminiが整理した。「二年目以降、自動化範囲が広がると削減効果はさらに上積みされます。制度変更対応時にエンジニアを取られない状態が作れれば、新機能開発のペースが競合と並ぶ可能性があります」
マイケル氏が数字を確認しながら言った。「選択肢が多すぎて決められなかったのは、選ぶ基準を決めていなかったからだと分かりました」
第三章：自動化しない領域を、決める
「進め方を整理します」と私がホワイトボードの前に立った。
「第一・二週——テストの四分類と優先順位付け。自動化対象と人力継続対象を明確化。第三週——要件定義と合否ライン設定。第四・五週——三製品の絞り込みとPoC実施。第六週——製品決定と契約。第七週から八週——初期スクリプト構築と研修。第九週以降——段階的な自動化範囲拡大」
「分岐条件テストを自動化しない選択は、本当に正しいですか」とマイケル氏が確認した。
「段階によります」とClaudeが答えた。「初期一年間は、データ連携とUI操作に注力します。分岐条件は二年目以降の検討課題。初期段階で全てを自動化しようとすると、複雑な部分で詰まって、全体が動かなくなります。自動化しない領域を決めることは、自動化を成功させる条件です」
マイケル氏がノートを閉じながら言った。「人が見るべき領域と、機械が見るべき領域がある——それを決めるのが、ツール選定の前にやるべきことだったんですね」
第四章：エンジニアが、新機能に戻った日
八ヶ月後、マイケル氏から報告が届いた。
ツール選定では、PoCの結果、当初検討していなかった候補が採用された。「カタログ上位の製品ではなく、PoCで最速・最保守性だった製品が選ばれた」とマイケル氏は記していた。DESCの順序を踏んだことで、想定外の選択が可能になった。
自動化範囲はデータ連携テストから着手。三ヶ月で全APIテストケースの約七十パーセントが自動化された。続いてUI操作テスト——稼働五ヶ月時点で全体の四十五パーセントが自動化。テスト工数は月七百二十時間から五百時間に減少、削減幅は月二百二十時間、マイケル氏の当初予測を上回った。
最大の変化は制度変更対応時に現れた。八月に税制改正対応があり、テスト期間はエンジニア三名、二週間で完了。従来は七名三週間だったものが、人員・期間ともに半減以下になった。「その間、新機能開発を止めずに済んだ」とマイケル氏は書いていた。
本番リリース後の不具合は、稼働後六ヶ月でゼロ件を維持。「機械のほうが、疲れない。人間が見落としていたパターンを、機械は見落とさない」と報告書にあった。
エンジニア全体のアンケートでは「テスト業務への苛立ちが減った」と答えた人数が十五名中十三名。「新機能開発に集中できる時間が増えた」が十二名。マイケル氏の言葉でこう締められていた。「エンジニアを、エンジニアらしい仕事に戻せた」
人が見ていた十万行が、機械に預けられた日だった。
「選択肢が多すぎて決められないのは、選ぶ基準が決まっていないからだ。DESCが問う四段階——記述・表明・特定・選択——は、選定の前に基準を作る作業を強制する。TechFlow社にとっての基準は『メンテナンス性』『データ連携』『既存共存』の三つだった。基準が決まると、選択肢は自然に絞られる。自動化しない領域を決めることは、自動化を成功させる前提条件だ。人が見ていた十万行は、機械が見たほうが正確だった。エンジニアは、新機能に戻った」
関連ファイル
使用ツール
- ROI Polygraph — テスト工数・機会損失・不具合対応コストの可視化
- ROI Proposal Generator — テスト自動化ツール導入の投資回収シミュレーション
