レガシーシステムのテスト自動化

レガシーシステムを放置すると、レガシーコードは複雑化しセキュリティリスクの増加やシステム障害のリスク上昇、運用・保守コストの増大、競争力の低下など、さまざまな問題に直面します。レガシーコードの改修では、徹底したテスト戦略と自動化することが、品質担保を確実に行い、システムを安全に維持･発展するために不可欠な要素です。

テスト自動化の必要性

システムの複雑化

全国の企業でDXが普及する中、アプリケーションの仕様は複雑化の一途をたどっています。短いスパンでの機能改善や改修も珍しくなく、特定の箇所を修正した際に、別の領域で意図しない不具合が発生する「リグレッション（回帰）」リスクが高まっています。このリグレッションを防ぐためには、小さな修正であっても広範囲の機能についてテストすることが必須です。その結果、テストケースが膨大となり、コスト増大や開発遅延を招くという大きな課題が生じています。製品を市場に投入した後の不具合は、自社の信頼性低下に直結します。短期間で頻繁に改良が行われる現在の開発サイクルにおいて、開発期間とテスト作業の労力を削減し、品質を向上させるためのテスト自動化は、レガシーシステムにとって最適な方法といえるでしょう。

アジャイル開発

市場の変化に対応するため、開発手法としてアジャイル開発（スクラムなど）を採用する企業が増えています。アジャイル開発は、2週間程度の短い期間（スプリント）で開発とテストを繰り返します。従来のウォーターフォール開発とは異なり、短期間で頻繁にリリースを繰り返すため、既存機能のテスト（回帰テスト）が増大することは避けられません。手作業によるテストでは時間も手間もかかり、アジャイルのスピード感を阻害してしまいます。そのため、アジャイル開発の成功にはテスト自動化が不可欠であるという考えが一般的となっています。

シフトレフトで工数削減

シフトレストとは、開発中に自動テストを使い、機能が働くかをチェックしながら開発を進める動きのことです。従来のような開発の後工程で品質保証のQAエンジニアやテスターがテストを行う方法とは異なり、開発時点で自動テストを行うことでバグを減らします。

後工程ではより品質を高めるためのテストを行うこともでき、工数削減ができます。

レガシーシステムのテスト自動化事例

テストコードなし、すべて手動テストからの脱却

長年にわたり使用してきたレガシーシステムは、急速に変化するビジネス要求に対応するにはさまざまな制約がかかり、足かせとなっていたのです。手動テストやリリースに多大な時間と手間を割かれ、新機能開発が停滞してしまうという課題に悩まされていました。

このレガシーシステムはJavaバージョン8で構築されており、数年前にオンプレミスからAWS EC2へ移行されました。ただし、その移行過程ではクラウドネイティブの設計思想は採用されていませんでした。

テストコードは一切存在せず、動作確認はすべて手動で行われていました。デプロイは深夜の作業が常態化し、担当者にも大きな負担が強いられていたのです。

成功要因

テスト自動化の導入には、初期コストや学習コストがかかるため、経営陣など上層部の理解を得ることが必要でした。そのため、過去に発生したリリース後の障害対応やバグ修正のコストを数値化し、手動テストに依存している現状のリスクと非効率性を可視化しました。

自動化することで障害率が低下し、結果的にリリースサイクルが短縮でき、ビジネスへ直接的なメリットになることを具体的に示し、上層部を説得。

また、開発メンバー全員が一丸となり、協力体制を構築することで負担を分散し、成功事例を共有。フィードバックの文化を醸成しながら、チーム全員で改善を実感できる仕組みを構築しました。

失敗要因

開発チーム内でテストを書く範囲を決める際、始めにどこから行うかで意見が分かれました。テスト対象の優先順位を設定するルールを明確化することで、すべてのカバーではなく優先的に何をすべきかがわかり、議論を収束させることができました。

初期段階ではメンバーのスキルや経験値の差により、テストコードの品質にばらつきが発生しました。品質を一定水準以上に保つためのサンプル集（ひな形やガイドライン）を参考にすべきでした。

また、どうしても特定のメンバーが自動化作業の主導をとることとなり、一部の人に作業が集中してしまった点が挙げられます。

テスト自動化によってレガシーなアーキテクチャを打破

これまでは基幹システムは「単体テスト」と「仕様書テスト」を使い分けて運用していました。単体テストでは新しく開発した部分だけをテストします。一方、仕様書テストは新規開発以外のシステム全体で稼働に問題がないかをテストするものであり、何百ページもある仕様書のテストを手動で行うのは気の遠くなる作業でした。

これを人間の手でやるのではなく、テストもプログラムにして自動化しようという試みがテスト自動化だったのです。

失敗要因

テスト自動化自体は完成したものの、動くことは動いても何百個ものエラーが出てしまいました。すべてのテストケースで「〇」が出なければならないのに、「×」ばかりが出てしまうばかりか傾向もわからない状態に陥りました。エラーが減らない原因がわからず、さらにその事実に対してメンバーの認識が異なっていたのです。

そのため、エラーを数値化・定性化・定量化することで、全員に共通意識を持たせることにしました。全員のベクトルと温度感を合わせて、毎日自動テストを回すことで何が起こっているかを明確に把握することから始めました。

今後の取り組み

テスト自動化はきちんと回れば大変効果の高いものです。一つの共通処理に手を入れることで発生するテストをカバーできたり、保守性の良いコードに修正したいけれど影響範囲が大きくて直せないなどの問題も、自動テストでカバーすることが可能です。

テスト自動化をきっかけに、継続的なインテグレーションやデリバリーを実現できれば、エンジニアのチャレンジを後押しできる仕組みにもつながります。

今後は自動テストがいかにコスト削減に貢献しているかという価値を維持する必要があります。従来のルールを払拭し、さらに良い仕組みにするためにも、テスト自動化を引き続き行っていきます。

まとめ

レガシーシステムを使い続けることは、進化しつづける最新のセキュリティ基準に準拠しておらず、脆弱性が高まります。またシステム障害の増加、運用・保守コストが高騰するなど、企業イメージを悪くする可能性があります。

そのためテストおよびテスト自動化は極めて重要です。社内での対応が難しい場合には、移行や開発を手がけている基幹システム開発会社へ相談してみるのも選択肢の一つです。