進むテスト自動化、一方で効果が出ない／実現できないのはなぜ？
矢野氏は長らくテスト自動化の現場に携わってきた。機能テストの現場では「より早い段階から品質に取り組みたい」、負荷テストの現場では「負荷テスト実施後の問題解析をより楽にしたい」、またどちらの現場でも「デプロイ待ちの時間をなくしたい」、「テスト環境、テストデータ準備の待ち時間が長い」という課題が指摘されてきた。こうした課題は近年登場しているDevOpsツールチェーンにより「ほぼ解決できる時代となりました」と矢野氏は言う。
多くのプロセスで自動化が実現できるようになったものの、それでもまだ「すぐに取り組めない」「効果を出せない」と逡巡する現場も少なくない。現実的な悩みどころを矢野氏は3つ挙げる。
課題１：ツールは入れたが効果が出ない
回帰テストツールを導入して自動化したものの、課題はテスト作業だけではなくテスト設計にもあるなど、ツールの適用範囲が限定的で十分な効果が発揮できない。
課題２：品質担保の範囲が限定的
テスト環境の要因で品質保証が十分行われないこともある。例えば、大規模負荷テストを実施しようとしたものの、端末の調達や計画が十分ではなく、想定以下の負荷量でテストを実施。結果的にリリース後に想定以上の負荷がかかりシステムダウンを引き起こしてしまった。
課題３：どこから始めたらいいか分からない
アプローチはいろいろとあるものの、逆にどこから始めたらいいのか分からず足踏みしてしまう。そこで「他社の成功事例を知りたい」「どのプロセスから着手するのが最適か」と正解を模索する。
迷っていても容赦なく時代は変化する。かつてウォーターフォール型の開発では時間をかけて高品質を担保していた。ところが近年では営業がタブレットで商談するなどIT環境の変化は激しく、かつてのように半年から数年規模も時間をかけられず、短納期のプレッシャーは強くなっている。従来のように品質は担保しつつも、スピードアップを求められる。矢野氏は「ツールを入れれば一定の効果は出せるが、十分な要求を満たすレベルにはまだ至らない。お客様もアジャイルやDevOpsの勉強をしているが、実際にどこから着手すべきか分からない。そんな話をよく聞きます」と話す。
3つの課題を解決し、アジャイル・DevOpsを推進！
現状における課題に対して、アシストでは次のような仮説を立てて考えている。「開発工程の早い段階から品質を上げるには、ソースコード解析が有効ではないか」「アプリケーション構造を可視化できれば、アプリケーション改修時の影響調査分析が楽になるのでは」、「開発プロセスの各タスクを自動化できれば、開発者は開発に注力できるのでは」、「課題を整理する手段があれば、問題の所在が明確化できるのでは」など。
そうしてソリューションを組み立てた。開発プロセスのボトルネックとなる課題を可視化するためとしてアシストではValue Stream Mapping（VSM）ワークショップを実施している。ここでは価値を提供する流れを可視化することで、潜在的な課題を明確にして、理想的な姿を模索するためのワークショップとなる。目的は自社の開発プロセスにおけるリードタイムを短縮するためのヒントを見いだすこと。一般論を座学で学ぶのとは異なり、自社の問題をワークショップ形式で行うため実践的なものとなる。おおよそ5～10名が集まって実施する。
課題が明確になると、それぞれのプロセスで何をすべきかが見えてくる。プログラムの変更時点では、効率的な影響を分析する。コーディング段階では、脆弱性の点検を行う（SAST：静的解析）。テスト段階では、回帰テストや負荷テストの高度化を行う。同時にテスト段階以降には、DAST（動的解析）やインフラの脆弱性管理を行う。また開発プロセス全体をカバーする自動化も必要だ。
それぞれの段階や目的別に具体的なツールをあてはめると、次のようになる。プログラムの変更分析には「ChangeMiner」、SASTには「Fortify SCA」、テストには「UFT One・PAIC」や「LoadRunner」や「JENNIFER」、DASTには「Tenable.io」、開発プロセスの自動化にはCI/CDの「Jenkins」や「GitLab」となる。テスト環境の構築から展開フェーズでは「Ansible」を使う。
さらに全ての段階において、実現に近づくための情報収集からはじまり、試行、展開、定着のための支援も組み込む。「他社事例を知りたい」というようなニーズに対してはDevOpsユーザー会を開催している。互いに情報交換することで、それぞれが課題解決できるようにしている。
テストやデリバリーの自動化、セキュリティのシフトレフト……活用シーン別にみる効果
ここからは活用シーンごとに課題と効果を見ていこう。
活用シーン①：テスト設計とテスト自動化
テストを自動化するにあたり「自動化対象となるシナリオが決まらない」。逆に「全てのテストケースを実施する」ために非効率で時間がかかってしまうこともある。そこでアプリケーションや構造の可視化を行うことで、どの機能を改修するとどこに影響があるのかを把握し、テストで注力すべき部分が明確化してくる。
結果的にテスト自動化対象の選別が経験や勘といったものではなく、ツールを通じて効率的かつ正確に行えるといった効果が得られる。具体的に見ると、プログラムの変更分析にはChangeMiner、テスト自動化にはUFTを用いる。
活用シーン②：セキュリティのシフトレフト
日々脆弱性が発見されており、開発段階でも脆弱性診断が必要だ。しかし脆弱性診断を開発の最終段階となるリリース直前に行うと、問題を発見しても改修の手戻りが大きくなり、コストもかかってしまう。そこで「シフトレフト」、いかに早い段階で実施していくかが課題となっている。
実際にはコーディング段階でSASTツールで脆弱性チェックを自動化、加えてCIツールと連携することでコードのコミットからレビューまで自動化する。また指摘された課題の真偽も診断する。そして結果的にシフトレフトが実現する。つまり開発の早期段階で脆弱性の問題を発見できて、改修も効率的にできる。開発者は開発に専念できるようになる。
具体的には、開発者がバージョン管理ツール（GitLab）にコードをプッシュやコミットすると、それをCIツール（Jenkins）にフックし、そこからソースコード解析ツール（Fortify SCA）に実行命令をかけ、解析結果が開発者に戻る。これにより大きくリードタイムを削減することが可能となる。
活用シーン③：アプリケーションデリバリーの自動化
テストと本番で環境に差があると、リリース前のテストをクリアしても、本番環境で問題が生じる場合がある。またUIのテストケースが多く、リリースまでにテストケースを網羅できないという課題がある。そこでテスト環境構築手順をコード化（IaC）し、環境構築作業を自動化することが有効となる。結果的にテスト、検証、本番で同じ環境の構築が可能となる。また膨大なUIテストを自動化できて、コストがかかりがちなUIテストの省力化を実現できる。
具体的には、活用シーン②同様に開発者がバージョン管理ツール（GitLab）にコードをプッシュまたはコミットすると、そこからCIツール（Jenkins）を通じて構成管理ツールに渡り、ステージング環境が構築される。続いてUIテスト（UFT）を実行し、結果を開発者に戻す。ここでもリードタイムが削減し、開発者は開発に専念できる。
活用シーン④：負荷テストとアプリケーションチューニング
大規模負荷テストを実施するには負荷テストツールの環境準備が大変で、実運用を想定した負荷テストを実施するのは難しい。アプリケーションチューニングも環境準備の面では同様だ。こうした場合、汎用（はんよう）性のある負荷テストツールが有効だ。アプリケーションサーバーの分析にアプリケーションサーバーにAPMのエージェントを追加し、アプリケーションの遅延状況を把握できるようにする。結果的に、問題解析や改修の時間を削減できたり、運用時の適切な監視項目を割り出すことができる。
具体的には、負荷テストツール（LoadRunner）で負荷をかける。近年クラウド版も登場し、大規模ユーザーの負荷テストも環境を用意せず実行することが可能となっている。アプリケーションサーバーにはJENNIFERのエージェントをインストールしておき、ここから性能情報を収集し、アプリケーション性能監視やボトルネック解析を行う。これにより性能問題の調査を迅速に行うことが可能となる。
冒頭に述べた通り、近年では従来通りの品質を維持しつつも開発の高速化が求められており、いかにアジャイルやDevOpsを社内に浸透させるかが課題になっている。どこから着手すればいいか。矢野氏が考える改善ステップとしては、まずはアジャイル研修や各種勉強会などで情報収集を行い、次に社内プロセスの課題を整理し、改善し、同時にCI/CDの技術検証も行いながら、アジャイル開発や基盤構築の自動化も実践していくという順番になる。
どの企業も今は開発プロセスの自動化に取り組んでいるところだろう。矢野氏の感覚だと「ここ1～2年、本格的なCD/CDパイプラインにチャレンジしているお客様が増えてきていると捉えています」と話す。また矢野氏は「DevOpsの取り組みは最初のきっかけと改善サイクルが重要です。我々アシストでは最初のステップとその後のステップアップをご支援させていただきたいと思っております」と述べてセッションを締めた。
