CAD・CAM技術開発部の中でも、担当製品の異なる3つの開発課からお話を伺いました。いずれもWindowsデスクトップアプリケーションの開発チームで、3製品は同じインストーラーに同梱され、ライセンス形態に応じて組み合わせて利用されています。

I様：担当製品：BLANK CAM(レーザ・パンチング加工機用CAM)

H様：担当製品：VPSS 4ie ARBEND(ロボット曲げ加工用CAM)

A様：担当製品：VPSS 4ie ProductionDesigner(CAD)

なぜテスト自動化が必要だったのか

— Ranorex導入前は、どのような課題を抱えていらっしゃいましたか。

I様(BLANK CAM)：
最も大きな背景は、製品の品質と安全性を担保するために「過去の改訂に関する回帰テストを、リリースのたびに確実に行う必要がある」という点です。板金加工機を制御するソフトウェアであるため、不具合や先祖返りを見逃すと加工不良や機械の破損といった重大な問題につながりかねません。そのため、製品の機能追加やバージョンアップに伴う確認項目は多岐にわたり、BLANK CAMチームだけでもそのテスト項目数は膨大な量にのぼっていました。手動テストを行うことは運用上の限界を超えており、自動化なしには対応できない規模でした。

— 具体的には、品質面・開発面・組織面でどのような課題がありましたか。

I様：
・品質面
製品の機能拡張や高機能化に伴い、検証すべきテスト範囲が非常に広大になっていきました。既存機能を含めたソフトウェア全体の安定動作と高い品質を常に担保し続けるためにも、手動テストから自動化への移行による確実な検証体制の構築が不可欠でした。

H様(VPSS 4ie ARBEND)：
品質・開発面：品質確保のため、リリースごとに回帰テストを実施していました。しかし、検証すべき項目が雪だるま式に増加していくことが課題でした。手動テストでは工数が膨大となり、リリース毎に全項目の網羅的な回帰テストを実行し続けることが困難であるため、テスト自動化が不可欠になりました。

A様(VPSS 4ie ProductionDesigner)：
品質・開発面：製品の開発規模が大きく、修正による影響範囲が把握しきれないケースが多々ありました。改訂箇所は年数が経つにつれて累積していくため、確認項目は徐々に増加していきました。すべての改訂再確認に必要な工数を確保することが難しく、テスト業務の効率化が課題となっていました。

・組織面
手動でのテスト工数が膨大になり、本来注力すべき新機能の開発や改善業務に十分な工数を割けないことが課題でした。限られた人員の多くがテスト作業に奪われることで、開発スピードの低下やテストにかかる人的コストの増大につながっていました。

— 手動でのテスト運用は、開発チームの負担という意味でも大きかったのでしょうか。

A様：
過去の改訂確認や回帰テストのような同じ単純作業を長期間・繰り返し行うことは、工数だけでなくエンジニアのメンタル・モチベーションの面でも負担になっていました。 自動化以前は、この種の繰り返し作業に開発リソースが継続的に割かれてしまう状態が、各チームに共通する潜在的な課題でした。

Ranorexの選定経緯

— 数あるツールの中で、なぜRanorexを選んだのでしょうか。

I様：
比較対象としては、コードベースで記述する自動化ツール等を検討していました。コードベースのツールはスクリプトを直接コーディングする必要があり、作成・学習に時間がかかります。 一方Ranorexはキャプチャ＆リプレイ方式で、プログラミングスキルに依存せず素早くスクリプトを作成・維持できる点を評価しました。

H様：
他ツールとの比較検討を挟む必要がないほど社内での信頼と実績があり、スムーズな立ち上げが見込めると判断しました。自動化担当者はRanorex未経験の状態で配属されましたが、周囲にRanorexの知見を持つメンバーが多く、すぐにサポートを受けて自動化に着手できました。

A様：
開発業務の効率改善において自動化を検討した際、すでに部内で定評のあったRanorexを採用する流れでした。先行して導入しているチームのおかげで知見を共有できたため、導入自体のハードルは低かったように思います。

導入効果：数字が語る自動化のインパクト

項目	I様(BLANK CAM)	H様(ARBEND)	A様(ProductionDesigner)
自動化後の工数	拘束時間91.1%削減	夜間・休日に無人実行	約75%削減
運用フロー	土曜夕方にセット→複数環境で771時間分を完走→火曜出社時に確認	夜間・休日の無人実行で回帰テストを短時間化

— 開発サイクル全体としては、どのような効果がありましたか。

A様：
アマダ社内の開発工程は、動作確認用の社内リリースを経て最終版リリースに至るプロセスで進み、それぞれの工程で仕様通りに動作しているかを確認するテストが必要です。 さらに定期的なバージョンアップデートがあり、高頻度でのテスト実施が求められます。 Ranorexによる自動化以前は、これらの工程確認テストを手作業で行っていましたが、自動化によって全開発期間の終盤でのみ実施していた各種テストが初期段階でも適宜実施可能となり、不具合の前倒し検出(シフトレフト)が実現しました。

I様：
また、お客様からのご要望や仕様改善へ迅速に対応するリリースサイクルを採用しており、その都度、全項目のテストが必要になります。手動テストではこのスピード感に対応しきれず、自動化なしには維持できない規模でした。

複数部署への定着・展開の工夫

─ 貴社では複数部署様でのご利用をいただいておりますが、導入後の組織展開に関してお聞かせください。

①ライブラリ化(技術的標準化)
A様：
共通の画面操作(ファイルを開く、データ入力、部品配置など)を「部品(モジュール)」としてライブラリ化し、テストシナリオはこれらを組み合わせて構築しています。 チームで構築した操作ライブラリは、後工程にあたるCAM側(H様のARBENDなど)へも展開して活用しています。 ARBENDは仕様上、必ずPDでパーツを開いてから起動するため、PD操作が前提として挟まる構造になっており、 PDのライブラリを流用することで、CAM側は一からPD操作スクリプトを作る手間を省けています。

他チームが自チームのライブラリを使うことで、「ここまでは用意できているので、残りはこの部分を実装してください」という形で役割分担を明確にできます。これにより、「それなら自分たちも自動化に取り組んでみよう」という動機づけにつながりやすくなります。横展開は必要に応じて個別に相談を受け、都度提供する形で運用しています。

② 自動化手順書の整備(プロセスの標準化)
I様：
スクリプト作成ルール・テスト実行手順・ログ確認フローを「自動化手順書」としてナレッジデータベース化。新規参画者でも手順書を見れば作業できる体制を整え、脱属人化を図っています。

③ QAシートによるナレッジ蓄積
I様：
自動化に関する不明点や過去のトラブルシューティングをQAシートに集約。日々の確認作業の中で発生した課題・対応ノウハウを蓄積し、チームで共有・改善するサイクルを回しています。

④ ベテラン／若手の役割分担(人材育成)
A様：
ライブラリ(共通部品)の作成は経験豊富なベテランが担当し、若手はそのライブラリをブロックのように組み合わせてテストケースを組み立てる、という分業体制です。若手がベテラン同様にライブラリ自体を開発できるようになるための教育は今後の課題ですが、現状は既存ライブラリの微修正から少しずつ担当してもらい、構造理解を優先させています。

⑤ 部署間コミュニケーション(ノウハウの横展開)
H様：
「画像の微妙な違いでNG判定になる」「リモート環境でテストが失敗する」といった課題について、他部署との日常的なコミュニケーションを通じて解決策(判定方法の見直し、Ranorex Agentの導入)を共有しました。

個別インタビュー：I様(BLANK CAM)

— 今、Ranorexの運用でどんな課題を感じていますか。

I様：
画像の微細な差分によるNG判定が課題です。実質的には問題がない場合でも、数ピクセルレベルの描画差分でNG判定になるなど、発生する失敗の一部は画像差分に起因するものがあります。類似度の閾値を下げることも検討しましたが、本当に検出すべき改訂まで見逃すリスクがあるため、閾値は下げたくないと考えています。運用上は、NGになった箇所のキャプチャ画像を出力しておき、テスト担当者が目視で確認してOK/NGを判定し直す、という人手による最終確認でカバーしています。

もう一つは「二重実行」の悩みです。休業日に自動実行し、出社後に確認するという運用のため、誤NGが出ると再実行が必要になり、結果的に工数が倍近くかかってしまうことがあります。改善案として「失敗箇所だけ再実行できる機能」や「失敗原因の可視化（画像差分以外のエラーで、再実行すれば通るケースがある）」を期待しています。

個別インタビュー：H様(VPSS 4ie ARBEND)

— リモート環境でテストが失敗する課題は、どのように解決しましたか。

H様：
リモートデスクトップ経由でRanorexを起動するとテストが失敗するケースが増えていました。当時のテスト担当者はRanorex未経験の新人だったため原因が分からなかったのですが、 知見を持つ他チームに相談したところ「Ranorex Agent」の活用でリモートデスクトップ環境でも安定して動作することが分かり、解決しました。

— 自動化率をさらに引き上げていく方針ですか？

H様：
全テスト件数の約80%を自動化していますが、今後の方針は自動化率を数値として引き上げることよりも、 「毎回失敗する(安定しない)テストの改善」を優先したいと考えています。成功し続けるテストをそのまま維持するより、 失敗を繰り返すテストにこそ改善の価値があるからです。

今後の要望としては、動画のシミュレーション比較によるOK/NG判断の自動化、複数PCにまたがる操作の同期 (サーバーPCでの変更をクライアントPCで検証し、再度サーバーPCで確認するような一連の操作)の自動化を期待しています。

個別インタビュー：A様(VPSS 4ie ProductionDesigner)

— 自動化によって、開発プロセスはどう変わりましたか。

A様：
これまで数回しか実施できなかったテストを、リリースごと・気になる修正のたびに実施できるようになり、改訂の早期発見につながりました。 また、テスト手順をスクリプト化したことで、担当者の経験値によるチェック観点のばらつきがなくなり、属人的な品質のばらつきを解消できました。

— Ranorexに対して、技術的に期待することはありますか。

A様：
3Dビューワ上のクリック精度： 3Dモデル上の面・頂点をクリックする操作は現状「座標」でしか指定できず、ドーナツ形状など複雑な形状では狙った箇所をクリックできず失敗してしまいます。モデルの面に色を付け、その色を目印に選択できる仕組みを期待しています。

画像比較の精度： 3D表示結果を前バージョンと比較する際、数ピクセルのズレだけでNG判定になってしまう(一部でこの現象が発生)。類似度を下げると本来検出すべき改訂を見逃すリスクがあるため、閾値調整だけでは解決が難しいです。
コーディング負荷の軽減： 標準コマンドだけでは思った処理ができず、C#でのコード記述が必要になる場面が多く、結果としてコーディングスキルを持つベテランに作業が偏り、若手による自動化の推進が遅れがちになっています。
また、開発規模が大きくなるにつれ、Ranorexの動作が重くなる(特にソリューション起動時・テスト実施時)との指摘もありました。

品質文化・開発プロセスへの影響

─導入後の開発プロセスへの影響はありましたか。

H様：
複数回実施するテストは必ず自動化する、という考え方が部内の大前提・文化として定着しています。自動化率などの指標は、開発プロセスの中の品質チェック会議・リリース報告プロセスで報告項目の一つになっています。

自動化によって開発初期段階からテストを回せるようになり、「最後の最後で慌てなくて済む」体制(シフトレフト)が実現しています。

S様：
Ranorex導入前は、限られた時間の中で確実にやらなければいけないテストに絞って行っていましたが、導入後はテストを計画的に実施し、それに基づいて開発計画を立てられるようになりました。 社内で導入されたツールの中でも「最も購入(投資)が成功しているツールの一つ」だと感じています。

マウス操作の記録のようなシンプルな使い方から始められる導入のしやすさと、必要に応じて高度な作り込み(コーディングなど)にも対応できる懐の深さを両立している点。幅の広いグラデーションで利用できるバランスの良さがあると評価しています。

今後の展望

─今後の展望についてお聞かせください。

I様：
CI/CD連携によるテストプロセスの改善、ナイトリービルドでの不具合早期検知、AI技術を活用したテスト運用のスマート化(メンテナンス省力化、原因特定の自動化)を目指していきます。

H様：
自動化率のさらなる向上。特に動画比較・複数PC同期操作など、これまで自動化が難しかった領域への挑戦をしていきます。

A様：
手動テストの自動化範囲拡大、テスト結果と課題管理ツールとの連携(失敗時の自動チケット起票)、テスト以外のルーチン作業への自動化応用による業務効率化を目指していきます。

これからRanorex導入・テスト自動化に取り組む方へ

─ 今後Ranorexを導入し、テスト自動化に取り組む方へメッセージをお願いします。

I様：
手動テストと比較して、Ranorexの導入により大幅な効率化と不具合・影響箇所の早期検出(前倒し)が実現できており、非常に心強いツールだと感じています。ただし、単にツールを入れるだけで完了するわけではなく、自社製品やシステムの仕様・作りに合わせて自動化スクリプトを最適化していく試行錯誤が必要であり、一朝一夕には実現できません。 自社の環境に即した初期構築や運用の工夫をじっくり計画して臨むことが、成功への鍵になると感じています。

H様：
生産年齢人口の減少に伴いベテラン社員の確保が難しくなる中、Ranorex等のツール導入により、若手担当者であっても高品質なテストを迅速に実行可能となります。これにより、貴重なベテランリソースをより高度な業務へシフトできます。一方で、テスト自動化は自社製品の作りに合わせた試行錯誤が必要で、一朝一夕には完了しません。そのため、チーム構成を含めたプロセス構築を丁寧に行うことが導入成功のカギとなります。

A様：
マイナーバージョンも含めて同じようなテスト(再発防止テストなど)を繰り返し実施するソフトウェアであれば、自動化ツールは非常に重要です。一度部品(ライブラリ)を作ってしまえば、以降はその組み合わせで自動化できるので、組み合わせやすいソフトウェアという観点でRanorexを選ぶのは良い選択だと思います。