自動化“しやすい”テストと、‟しにくい”テストがある

――まずは「自動化コンサルタント」の業務内容について教えてください。 

松吉：名前の通り、テストの自動化に特化したコンサルタントです。

一般的にソフトウェアテストには、テストの実施と結果の確認、テスト進捗の管理、それからレポートの作成といった作業があり、ここでいう「自動化」とは、これらの作業のすべて、または一部を専用の支援ツールを用いて自動化することを指します。 

自動化コンサルタントは、お客様のシステム構成や開発業務プロセス、テスト業務プロセスなどを把握して、自動テストスクリプトの開発が実現可能かどうかを判断し、どういう仕組みがつくれるかを計画立てたうえで、お客様のシステムにあわせた効果の高い自動化ツールの開発／選定などを進めていきます。 

開発工程全体で見ると、「実装」から「テスト」の領域が私たちの活動フェーズになりますね。 

――活動フェーズが幅広いですね！ 自動化の導入は少しずつ普及してきている印象ですが、一方で上手くいかないといった声も多く耳にします。なぜ企業は自動化に失敗するのでしょうか？ 

松吉：大前提として、構造がシンプルで自動化“しやすい”テストと、反対に自動化“しにくい”テストがあると考えています。

やろうと思えば何でも自動化できてしまうのですが、後者を無理やり自動化してしまうと、何かを変えたときに動かなくなったり、何回か実行すると落ちてしまったりと、メンテナンスの面での課題が出てきます。 

そういった事象が複数回発生すると、自動化への信頼度も落ちていき、結果として「自動化しても変わらないね」となってしまうわけです。 

――だからこそ、ベストプラクティスを知るSHIFTの自動化コンサルへのニーズが多いと。松吉さんはいつごろから自動化に携わるようになったのですか？ 

松吉：SHIFTに入社してからです。それ以前もテストフェーズを担当するにあたって自動化に触れることもありましたが、専門のコンサルになったのはSHIFTからですね。 

――なぜSHIFTへの入社を決意されたのでしょう？ 

松吉：もともと11年ほどソフトウェア開発会社にいて基本的なプログラム開発からチームリーダー、PMなどをやらせてもらい、その後GIS（地理情報システム）を活用したシステムを提供する会社に転職して3年ほど保守運用をしていました。 

そんななか、もっとITコンサル的な立ち位置でお客様の課題解決をしていきたいと思って入社を決めたのがSHIFTでした。

もちろん、ほかの会社も検討はしましたが、転職した2017年の時点ですでにかなりの成長会社だったこともあり、ここなら裁量をもってやりたいことができそうだと思い、入社を決めました。 

失敗は、次なるチャレンジへの学び

――SHIFT入社後は具体的にどんな業務に従事されたのですか？ 

松吉：結果として、入社直後から現在に至るまで7年強、ずっとテスト自動化を担当しています。

といっても、最初に担当したプロジェクトは、残念ながら上手くいきませんでした。 

――どんな案件だったのでしょう？ 

松吉：お客様のオンプレ環境をクラウド化するという内容で、現行環境における品質担保の仕方がわからないという課題感からご相談をいただいたものでした。

機能追加をつづけていったが故に、いわゆるブラックボックス化したシステムだったので、「本番といっしょの動きが正解」「本番と違った動きになったら間違い」という状態の案件でした。 

こういった場合は一般的に現新比較テストをつくり込んでいくのですが、断面テストだと年単位で時間がかかってしまうので、リアルタイムの現新比較をご提案したわけです。 

――リアルタイムの現新比較ということは、本番のデータを定期的に同期するということですか？ 

松吉：そうですね。お客様が操作する処理データ以外は新環境で同期させて、操作するデータに関しては一旦別の場所に格納し、検証時に流して比較を進めるというやり方を採用しました。 

大きく5つくらいのシステムがあるなかで、中核システムに関しては現新比較が90％ほどの精度で一致する状態までもっていけました。

残りの10％ほどは本番環境からのデータ同期の遅延や、タイミングなどに起因したものだということも判明し、概ね品質としては問題がないといえる状態になったのです。 

一方で、残りの4つのシステムに関しては中核システムのデータを前提に組まれているので、中核システムの10％のズレが、そのまま30〜40％にまで膨れてしまうということが判明しました。

これでは残り4つの検証がむずかしいということで、残念ながらプロジェクトとしてはそこで終了になったという流れです。 

――なるほど。むずかしいものですね… 

松吉：結果としてうまくいきませんでしたが、入社後最初の案件にも関わらず裁量をもって取り組ませてもらいましたし、何よりも失敗そのものが咎められることがなく、次なるチャレンジに向けた学びとして解釈されました。

SHIFTに入社したのは正解だったなと感じましたね。 

「楽をするための技術」というのが面白いポイント

――現在はグループ長として組織マネジメントが中心かと思いますが、現場に入ることはあるのですか？ 

松吉：ありますよ。ちょうど今月で一区切りになるマイグレーション案件における自動化計画の立案／推進プロジェクトでは、自動化コンサルタントとして入らせていただきました。やはり現場の仕事も楽しいですね。 

――具体的なプロジェクト内容を教えてください。 

松吉：マイグレーションなので、システムの完全なつくり替えです。継続的な改善を前提に組んでいくので、テストに関しても手動ではなく自動化することで効率を上げつつ、品質を高めていく必要がありました。 

具体的には、例えば単体テストではコードレベルのユニットテストでの検証をやらせてもらい、言語やフレームワーク、テスト基盤に応じたサンプルのテストコードを書いてご提供しました。 

また、結合テストや総合テストフェーズではAPIなどバックエンド側のテストや、GUIテストなどの自動化の計画立てを進めていきました。

お客様が非常に大きな企業グループのため、グループを含めた周辺のシステムや付随する業務フローなどを確認・整理していくところが大変でしたね。 

――自動化のお話をしているとき、松吉さん、すごく楽しそうですよね。 

松吉：え、そうですか？（笑） 「楽をするための技術」というのが自動化の面白いポイントなんですよね。必要なことを勝手にやってくれるという。 

手動でやらなければいけないところがなくなり、無人でも担保できるように設計するのが、自動化コンサルタントの腕の見せどころです。

SHIFTにはそういった自動化のご相談がたくさん寄せられるので、そういう意味で非常に恵まれた環境だなと感じています。 

つねに物事を「楽」にしたいと考えている人、求む

――どんな経歴であれば自動化コンサルタントになれるのでしょうか？プログラミングの知識はどれくらい必要になりますか？ 

松吉：プログラミングそのものは、知見が浅くても問題はないと思います。

それよりも、フロントエンドからバックエンド、インフラ、ネットワークまで幅広い領域での実務経験や勘所といったものの方が、より現場で活かしていただけると思います。 

というのも、お客様からのご相談は最初の時点ではざっくりとしていることが多いため、具体化していく部分で多様なシステム開発経験が役立つと考えています。 

――マインド面としては、どんなタイプが向いているとお考えですか？ 

松吉：つねに物事を「楽」にしたいと考えている人、ですかね。

もちろん、自動化って最終的な品質を担保するものなので、楽をしたいけどきっちりと物事をこなしていくようなマインドの人は向いているかなと思います。 

――今後、松吉さんがやってみたいこともお聞かせください。 

松吉：グループ長なので、自動化にまつわる新しいサービスづくりに注力していきたいと考えています。

まだ模索中ではありますが、SHIFTとして力を入れている生成AIの活用を、自動化領域でも進めていきたいですね。 

また、先ほどお伝えしたとおり現場も好きなので、引きつづき、自動化コンサルタントというプレイヤーとしての時間も確保しながら現場の感覚を維持していくつもりです。 

あとはなんといっても、自動化コンサルタント自体まだまだ人数が少ない状況なので、きっちりとメンバーを育てていきたいと考えています。

自分が見ているメンバーが活躍しているのは、やはり一番のやりがいですからね。 

（※本記事の内容および取材対象者の所属は、取材当時のものです）