レガシーなアーキテクチャからの脱却を――“テスト自動化”の挑戦と課題

alt

パーソルキャリアのテクノロジー本部 エンジニアリング統括部 第一開発部では、レガシーなアーキテクチャからの脱却を目指し、さまざまな課題に対して取り組みを進めています。そのうちの一つであるのは、テスト自動化。一見ユーザーにも見えない、地味な改善でありながらも、業務効率や品質向上には欠かせない同取り組みを行う3人に、スピーディーに基幹システムをブラッシュアップしていく面白さや第1開発部で働くやりがいについて話を聞きました。

登場人物

石井 孝典 リードエンジニア

本プロジェクトでは、リーダーを担い、プロジェクト進行やエンジニアのアサイン、コスト調整など、全般を取りまとめる。 

松井 英導 リードエンジニア

基幹システムARCS開発におけるリーダーを担い、本プロジェクトでは内製開発と外部ベンダーの併用における効率的な運用を行う。

久保木 翔一 エンジニア

 本プロジェクトでは主にテスト自動化の可視化を担当。日々のパフォーマンスを開発エンジニア全員で共有できるようにした。

歴史があるから構造が見えないーーまさに“ジェンガ状態“

――本日はよろしくお願いします。早速ですが、テスト自動化プロジェクトについて教えてください。

石井:よろしくお願いします。弊社の基幹システム、ARCS(アークス)内の開発ではテストの自動化を行い、エラーの見える化も合わせて行ったことで、運用工数やコストの削減を行ってきました。外からは少し見えにくい話なので、丁寧に説明しますね。

これまで基幹システムでは、「単体テスト」と「仕様書テスト」を使い分けて運用してきました。一般的に言われている単体テストは、作った仕様に基づいて条件分岐をテストし、正常系・異常系という条件分岐をテストしていきます。わかりやすくいうと、新しく開発したところだけをテストするには、こちらを使うことが多いんです。

alt

エンジニアリング統括部 第一開発部 システムアーキテクチャBITAグループ リードエンジニア 石井 孝典

一方で、仕様書テスト、というのは新しく開発したところ以外の、そのシステム全体で稼働に問題がないかどうかを確認するもので、何百ページもある仕様書のテストをやるとなると、それはもう…辛いことしかないんです(笑)。

最初はやはりきちんと動かないと困るので、開発者もチームもモチベーションを保ってテストをやり切ることができますが、新しく何かを開発するたびにテストとなると、仕様書を何枚も作ったり、となかなか耐えられないんですね。なので、それを人間の手でやるのではなくて、テストもプログラムにしてしまおうというのがテスト自動化です。プログラムでもできる作業は、プログラムに任せてしまおう、テスト仕様書はExcelに書くのではなく、プログラムに書いてしまおうということですね。

 

――基幹システムとしてのテストのタイミングや頻度ってどのように判断しているんですか?

石井:キャリアアドバイザーや法人営業が使うARCSには機能がたくさんあり、単発開発が絡み合う構造になっているんです。なので、開発中に設計ミスが見つかったり、また開発後半の結合テストやシステムテストのタイミングで不具合が見つかったりしたら、その不具合がプログラミングの問題であればすぐに直していますね。ただ、仕様に問題がありそのままシステムを作ってしまうと成立しない場合には、仕様変更が必要になるので、その時には「また何ヶ月もかけて仕様書テストをやるのか?」という話になりますよね。とても神経質なシステムの場合はもう一度単体テストを行うこともありますし、リスクとコストを加味して影響が出そうな範囲に限定してテストをするパターンもありますね。

 

――歴史あるシステムがだからこそ、なんですね。

松井:開発中に仕様やソースコードの変更によりテストをやり直すことも頻繁に発生しますよね。

alt

エンジニアリング統括部 第一開発部 システムアーキテクチャBITAグループ リードエンジニア 松井 英導

石井:そうそう。でもテスト自動化があればすべてやり直すことできるんです。前回取材してもらったARCS刷新では、後半に仕様の変更がかなり発生していたんですね。大規模な業務システムは関わっている人も多く、システムの専門家でない人も多くいるので、こうした人たちの要望や仕様が盛り込まれているとやはり仕様変更は増えてしまいます。リリース後に不具合が起きることもありますし、数千人の社員が使うシステムですから少しだけやり直すというわけにもいきません。ですから、ここでテスト自動化をやる意義というのは大きいと思ってました。

 

――どうしても仕様の変更やソースの変更などは避けられないと思うんですが、、、不具合が出てしまうのはどのあたりに課題を感じていましたか?

石井:刷新する前のシステムはもう13年ほど使っているシステムで、当然ですが複雑になっていました。どこか触るとどこかが壊れる状況でしたね。

 

久保木:わかりやすくいうと、ジェンガみたいなものです。最初は綺麗にできているのでわかりやすいですが、色々と手を加えたり、新しく追加すると形がいびつになってしまい、最適解が見えなくなってしまう。どこか触ると崩れてしまうのと同じです。

 (全員激しくうなずく。笑)

alt

エンジニアリング統括部 第一開発部 システムアーキテクチャBITAグループ エンジニア 久保木 翔一

石井:そうなんです。それでもシステムを変えていくためには触らなければなりません。不具合が起きる原因の多くは、いわゆる影響調査漏れです。どこを触るとどこに影響する調べ切ることができていなくて、漏れた部分が壊れてしまうのです。だからこそ、今回のARCS刷新でも当然何年かは継続して使うと思いますが、テスト自動化をしなければ、何年か後の修復が大変になることは目に見えていました。なので、このテスト自動化を一つとして、長く使うシステムだから「継続的インテグレーションと継続的デリバリー」のCI/CDを意識しないといけないと感じていました。

リリース後に待っていたのはエラーの数々――大事なのは見える化

石井:今回、フルリプレイスのタイミングだったということもラッキーな点でした。古い機能からコピーしたものもありますが、それらはあらかじめコピーする際に自分たちでテストを作っておくようにして、テスト自動化自体は完成しました。

ただ、自動で動きこそしますが何百個というエラーが出てしまうんです。すべてのテストケースで「○」が出なければいけないのに、完成したテスト自動化には何百個という×がありました。テストコードはあるけれども、組み合わせやタイミングなどさまざまな問題があり、テストを1つだけ実行するとOKで返ってきますが、すべてをテストするとなぜかOKで返って来ない。プログラミングなので、テストプログラムがバグっている可能性もありました。

そもそも、自動テストをする件数が毎日同じではないので、エラーの増減もわからない状況がどうにも気持ち悪さが残っていて。。。傾向が見えなかったので、今後の方向性を話す中で久保木さんに「一旦、どうにかなっているということがわかるようにしてほしい」とお願いしました。みんなで頑張ってエラーを0に近づけていくけれども、エラーが減らない理由が分からないとモチベーションが保てなくなってしまうと考えたからです。

alt
久保木:
石井さんはリアルタイムで全体を見ているので、課題がたくさんあると感じているようでしたが、他のメンバーは「石井さんが何か言っているな」という感じだったんですよね。問題に対する意識が人によってバラバラになっていたのだと思います。

エラーが数百件残っている状況に対して、ただ「数百件残っているだけ」と感じる人と「数百件もあって大変だ」と感じる人と、温度感が明らかに違いました。ここをまず見える化することで全員に共通認識を持たせ、数値化・定性化・定量化することが、最初のステップでした。500件のエラーがあって、人の力で100件直したと報告があっても、次の日に450件のエラーがあるという状況だったんですよね。

石井:そうそう。それが100件減って50件増えた結果なのか、100件直したと思っていたけれど50件しか減らなかったのか、がわかんなかったんだよね 

久保木:一旦全員のベクトルや温度感を合わせるため、全員が見ている場所に同じような認識を得られるような結果を出すことが今回の意義のひとつです。毎日自動テストを回すことで、修正していなくてもエラーが増減していることが毎日わかるようになります。

 

――「見える化が必要」という共通認識が持てたということでしょうか?

石井:そもそもこれは最終的には運用に引き継がなければならないものです。毎日テストをして、日々エラーが0なので今日もシステムの機嫌が良いね、となり、システムの状態を気にせずに新たな開発に集中できることが僕たちの目指すところです。それを実現するには、「今日もエラーが0」という状況が続かなくてはそもそも始まりません。なので、まずはそこに取り組むしかありませんでした。何が起こっているかを明確に把握できなければ、対策もできません。

 

――見える化はすぐにできるものだったんですか?

久保木:最初は「こういう感じにしたい」とふんわり要望を伝えられました。パーソルキャリアの基幹システム周りは、Azure DevOpsやTeamsなどMS製品を使っています。自動化や見える化について調べたところ、Microsoft Flowの親和性が高く、システム連携の手間も省ける状態でした。これを使い、PoC感覚でやってみると数字をグラフ化したり見た目をかっこ良くしたいといったようなさまざまなオーダーが来るようになって(笑)こうしたオーダーに応えるのも楽しくなり、石井さんと盛り上がりながら最終的に自動テストの結果を自動でお知らせするプロセスを作りました。

alt

実際の見える化ツール

石井:自動テストの結果が出て、もしエラー数が0でない場合はその理由をすぐに検知することが重要です。たとえば何も触っていないのに急にエラーが出るのはおかしいので、その理由を考えます。一般的には自動テストを行う際データベースは使用しませんが、BADパターンや複雑なデータ構造をもつ機能をテストする際は、データベースを使用したほうが効率が良いためARCSでは自動テスト用のデータベースを使用しています。また、ARCSは複数のシステムがひとつのデータベースを使用しているため、急にエラーが出る理由は誰かがデータベースを触ったことによる影響と推測することもできます。こうして当たりどころを検知するにも有用なんです。

 

――見える化によってNG理由を探すというアクションも根付いたきたということでしょうか?

久保木:土台固めと対応方針が決まってからは、やはり皆さんそこそこの経験があるので意識が変わりましたね。今はエラーが上がってくるとみんな自発的に動くようになりました。その人の性格にもよりますが、ずっと気にかけてくれている人もいます。それによって「本格的に動かしたら大きなエラーになるかも」といった大きな課題が事前に見つかることもありますね。

 

石井:今までは本番リリースしてから、課題が見つかったり、または本番でも気づかずに別のリリースの時に見つかり、そこから理由を探す、という「エラーが起きてから動く」というのが常でした。ただ今回の見える化によって、起きるかもしれないエラーを未然に防げているので、誰からも褒められないことではありますが、エンジニアの中では盛り上がっています。

 

――エラーを未然に防げるのは事業としても大きいですね。

 石井:そうですね。どうしてもエンジニアリングは事業から見るとコストがかかってしまっていますが、本番環境でエラーが起きれば事業はもちろんのこと、お客さまにもご迷惑をかけてしまいます。エラーは起きないことを当たり前にしなければなりません。なので、事前に検知できることはとても大きいですね。

 

松井:見える化の効果はもう1つありまして、人が作ったテストコードを人の手で来る日も来る日も修正するのは、これまた精神的なダメージも大きい作業なんです。自分が作ったならまだしも、人のコードって読み取るの大変なんですよ(笑)しかし見える化をしておけば、自分が改修したものに対するエラー件数の増減を見ることができます。これはモチベーションにもつながります。

alt

石井:エラーが初めて0件になった時は、みんなで喜びましたね。

 

松井:そうそう。あれは盛り上がりましたね。ただ見える化が進んだ今もエラーは出ているので、その中で運用も回していかなければなりません。僕らは内製開発チームなので柔軟に対応ができ、エラーが出ているところも一緒に直していくことができるので、この辺りもクイックに動ける点はよかったですね。たとえばこれをベンダーにお願いするとなると、エラーが出ている状態の調査から始めなければいけないので、テストを使わなければならない状況なのにエラーが出ていてどうしよう、と立ち止まってしまいます。ベンダーさんの見積もりにもこうしたケースを想定したものはありませんから、コストも膨らんでしまいます。

 

石井:ベンダーさんももちろん見積もりを出すための調査をする際に、テストを回しているのでエラーが出ていること自体は見えています。ただ僕らからすると、バグでも単発で動いていればそんなに大きな影響はないと読んでいても、傍目にはただバグっているように見えます。バグっているソースコードだと、そもそも仕事を受けてもらえないことも多いんです。

 

松井:バグっているソースコードは、仕事を受ける側からすると瑕疵の範囲が曖昧になってしまいます。なので、ベンダーに依頼している箇所は、開発する範囲のテストで落ちているところを優先的に直し、ソースコードを取り込んでもらう形で運用を始めています。

この運用により、ベンダーが開発した範囲はしっかりとチェックしてもらえていますが、結局テスト自動化の効果は全体で回してみて、他に影響がないかを見ていくものです。これが難しいところで、実際にスタートラインのエラーが0だったにもかかわらずベンダーのソースコードを取り込んだ結果エラーが増えたとしたら、それはベンダー側のコードにエラーの理由があるとわかりますが、今はスタートラインにもエラーがある状態なので、それができません。なのでそれは一旦、内製開発チームで受け入れて、エラーが出たところに関しては調査を行い、確実に瑕疵だと分かるものはベンダーに依頼しますが、グレーゾーンであればこちらで直すという運用法を今は取っています。

 

――運用フェーズをパーソルキャリアのみでやるという可能性はありますか?

石井:それは今のところ検討していないですね。今ARCSを見ている内製開発チームは8人です。アウトソースしている保守チームは30人~40人いまして、さらに単発で発生する開発プロジェクトが常時2~3本、多いときで5本は走っています。この状況で内製開発チームで保守もやるとなると、自動化の力も借りても難しいんです。

よく聞かれるのは「内製開発チームを50人規模にするんですか?」と言われますが、基幹の性質上、常に50人分の仕事があるわけではないので、通年で50人を抱えることも現状は難しいんですよね。そうなるとやはり多かれ少なかれパートナーや開発ベンダーと協力しながらやっていくことが重要で、その中で内製開発チームがどうあるべきか、開発にどのように関与するのが一番レバレッジポイントとして効くのかを考えて動くことが必要です。テスト自動化を活用するのも、内製開発メンバーが少ないからという理由もあります。

alt

エラーの可視化は、受け入れする際にも僕らがクイックに動けるようになるという利点があります。これまではエラーが見つかってからベンダーを探して見積もりを取って……としていましたが、これからは自分たちで直してすぐに終わらせることもできるようになります。これは結構重要なことです。

また、事前に影響調査をすると100~200ヵ所影響が見つかり、時間やコストもそれなりにかかってしまいます。しかしテストドリブンになれば、先に開発してテストを回せばOKです。テストで数ヵ所エラーが出たとしても、そのエラーは数日で直すことが出来ます。200ヵ所すべての影響調査を人間の手で行おうとすると、数日では終わりません。

 

――開発しながらテストをかけていくことで他への影響もチェックでき、効率的に進められるということでしょうか。

石井:そうですね。やはりこちらもクイックに開発とテストを回していかなければならないと感じています。先に影響チェックをしながら進めれば、怪しいものは全て確認してから開発をしなければならないので、なかなか前に進めません。先に直しながら、自動テストを回して、開発を進めれば、怪しかったけれども問題がなかったものに関してはOKになりますし、怪しいところだけをあぶり出せますよね。

テストは続ければ続けるほど良くなっていくと考えています。dodaに関してはもっと細かくチェックが可能なテストプログラムをかける必要がありますが、1つをマニアックに細かく対応するくらいならば、全量を網羅できるように力を割いています。そこがうまくできるようになると、頻繁にバグるところや、事業としてインパクトが大きなところだけプログラムを改修してテストを手厚くするといったような形にシフトしていけると思います。

 

――テスト自動化のフェーズを考えながら、外部ベンダーとの仕事のあり方を模索し、目の前の開発をクイックに進める。常にその時々での判断が求められそうですね。どんなふうにしてベストな方法の見つけたんですか?

松井:試行錯誤もあったとは思いますが、石井さんと相談しながら進めていきましたね。

石井:松井さんがリアリストなんですよ。僕が「こうしたい」と理想の世界観を伝えると、松井さんがその時の状況などを鑑みて落としどころを見つけてくれます。最終的には松井さんの方がリアルなので、僕が負けていましたね(笑)。でもそのおかげで前に進めることができているので、本当に助かっています。

 

内製開発の価値ーー長く使うシステムこそ継続的な改善を

――テスト自動化や、それにまつわるエラーの見える化に対して、どのような意識で取り組んでいたのでしょうか。

久保木:テスト自動化も見える化も、「こういうことをやりたい」と言われて調べていくうちに、どんどん面白いと自分でも思うようになりました。基本的に負けず嫌いな性格でもあるので、さまざまなオーダーに応えるのも楽しくなってきましたね。「あれやって、これやって」と無理難題を振られる方が燃えるタイプです(笑)。

言われたことは一旦やってみて、その過程で自分の成長性を感じるのであればそこで吸収をして、別なものにつなげていくことを繰り返しています。今回のテスト自動化のプロセスは、ナレッジもたくさん溜まりましたし、結果が目に見えるので楽しいですね。「みんなが毎日盛り上がっているものを作ったのは自分だ」と思えるのは楽しいです。

alt

モチベーションは結構大事だと思っています。それがないと突き詰められません。言われたことをやるだけでは楽しくないですよね。前職でSIerをやっていた際に「お金がないからそれ以上はダメ」と言われることがありました。こうすればもっと良くなる、操作性が良くなると伝えてもお金がないからと断られるのが今までの経験だったので、今回のように課題の本質に着目して、良くしていくことを突き詰めることができる環境は楽しいですね。

 

松井:内製開発チームが立ち上がってまだ3年ということもあり、我々の価値はこれから測られてくると思っています。会社としても内製開発を進めていく動きがありますが、ビジネスに直結する仕事も、間接的に影響があるものが混在していることから、事業側から見た時に内製開発にしたことでどれだけ良くなったのかは実感が薄いのではないかと思っています。なので、我々の価値を高めつつ、せっかく事業会社に来たのだから、我々も事業側に対して内製開発のメリットをどんどん出していくということをやっていきたいですね。

テスト自動化もその1つです。きちんと回ればこんなに効果の高いものはない、と開発側は考えています。1つの共通処理をすることによってそれぞれに発生するテストをカバーできたり、保守性の良いコードに直したいけれども影響範囲が大きくて直せないという問題も、自動テストでカバーできたりします。テスト自動化をきっかけにして、継続的なインテグレーションや継続的なデリバリーを実現することで、エンジニアのチャレンジを後押しできる仕組みだと思います。

 

――運用をこれまで以上に適切に行うことで、テスト自動化の価値を一段と伝えることができそうですね。

松井:まさにそうだと思います。将来的には「自動テストがなかったら、どれだけコストがかかるか」という話になると思います。

石井:もちろん逆のイメージがつかないようにも注意が必要です。僕たちは「こんなに不具合が出るなら、自動テストはやめればいいじゃないか」と言われないようにしなければなりません。コストをかけているのにバグの発生が続き、少しでも疑念を抱かれると「やはりテスト自動化は必要ない」と言われてしまいます。僕たちはソースコードを触る側なので重要性はわかりますが、ソースコードを触らない人たちにとってはイメージの問題になってしまいます。

 

――イメージはどのようにして伝えていくのでしょうか。

alt

松井:「自動テストがなかったら、どれだけの工数がかかったか」という予防の話をします。

石井:起こらなかった事件の話をしなければならないので、結構難しいんですよね。これには、しばらくやり続けることが重要で、そのあいだに「テストしているのに不具合が出た」といった疑念が出ないようにすることは僕たちの責務ですし、アピールできるタイミングでしっかりとアピールもしていきます。そうすれば1〜2年経った後にきっと「最近不具合が少ないな」と気づいてもらえると思うんです。その時に不具合の数や僕らが直した数、減った障害の数をグラフなどで示せるようにしなければいけない。一定期間やり続けなければ、周りにはわからないと思っています。表向きには新しい機能を作っている印象が強いかもしれませんが、運用の手を抜かないというのはとても重要です。基幹システムとはそういうものです。

 

――今後実現したいことをお聞かせください。

久保木:基本的に私も、これまではテスト項目900個も手で叩けばいいと考えていたレガシーの人でしたが、今回自動テストに携わり、開発の仕組みを作ることは面白いし楽しいと感じました。今後は仕組みづくりの勉強も重ねて、より力を入れていきたいです。

今までは、システム開発をしてお客さんから喜びの声を聞くのが嬉しかったのですが、今は開発者のためのシステムを作っているようなもの。なので、開発者に「すごい」と言ってもらえるとさらに嬉しいですね。経由して聞くよりも、直接喜びを聞く方がやはり嬉しいです。そういう自分はやっぱりエンジニアで、ものづくりの人なんだと思いますね。

松井:我々エンジニアにとってよくあるジレンマとして、長年開発をしていると、ソースコードは積み重ねでどんどん劣化していきます。そのためにリファクタをしますが、テストに工数がかかるからと止められることが多くあります。「手を入れると壊れるかもしれないから、動いているコードは触るな!」という理論ですね。その理論があると、不具合が起こりやすい作りになっていても触ることができない。これはエンジニアにとってとても辛いことです。なのでそうしたルールをどんどん取っ払っていきたいです。そのためのテスト自動化だと思っているので、さらにより良い仕組みにしていきたいと考えています。

石井:テスト自動化に関して言うと、ARCS刷新の自動化も初級編を脱せるかどうかという域だと思っているので、ここからどんどん改善をしていきたいと思っています。粒度や細かさの問題など、今後はよりインパクトのある部分に効く施策をやりたいですし、プロジェクトの途中でコストカットのために止めてしまったフロントエンドの自動テストもやりたいです。

また、パーソルキャリア内にはまだレガシーなシステムがあります。ARCSは偶然にも、テスト自動化の時期と事業のニーズが合ったので今回刷新することができましたが、まだまだ10年以上稼働している他のシステムもいます。そのシステムも、いよいよ老朽化している中で、ここ数年の間にきっと改善・刷新するプロジェクトが動くはずです。その際にこのプロジェクトが良いプラクティスになり、他のシステムでもテスト自動化を導入できたら良いなと思います。

僕らはこの案件で社内にテスト自動化を導入する際のノウハウを得ることができました。良かったことも悪かったこともありますが、それは別のシステムを刷新するときにも活かせるので、この会社でテスト自動化が当たり前になり、長く使う基幹システムだからこそ、CI/CDを意識した最適なシステムの開発、運用を作れる世界を築いていけるようにしたいですね。

alt

――ありがとうございました!

(インタビュー・編集=伊藤秋廣(エーアイプロダクション)/執筆=The Text Factory(エーアイプロダクション)/撮影=古宮こうき)

alt

石井 孝典 Kousuke Ishii

エンジニアリング統括部 第1開発部 システムアーキテクチャBITAグループ リードエンジニア

2017年中途入社。 新卒で独立系SIerに入社。宇宙開発/自動車R&D/製薬・製造/金融/物流など業種を問わず様々なシステム開発プロジェクトに従事。 プログラマからSE/プロジェクトマネージャーを経て、事業目線で業務システムの未来像を描き推進できる環境を求めてインテリジェンス(現パーソルキャリア)に入社。 基幹業務システムの刷新にシステムアーキテクトとして参画。現在は同システムの改善や、周辺システム連携のアーキテクチャ構築を担当。

alt

松井 英導 Hidemichi Matsui

エンジニアリング統括部 第1開発部 システムアーキテクチャBITAグループ リードエンジニア

2018年中途入社。学生時代はDTM(デスクトップミュージック)を学んでいたが、いつのまにかエンジニアに。開発ベンダーで約17年ソフトウェア開発に従事。自社サービスの開発に携わり、長期間同じサービスの成長に貢献したいと思い、パーソルキャリアへ転職。基幹業務システムの刷新に内製開発チームとして参画し、リリース後も継続して改善および運用を担当。

alt

久保木 翔一 Shoichi Kuboki

エンジニアリング統括部 第1開発部 システムアーキテクチャBITAグループ エンジニア

2020年中途入社。新卒で独立系SIerに入社後、主に金融係の行内システム開発プロジェクトに従事。開発を請け負う立場から、事業側からの立場で自社サービスを開発するエンジニアになりたいと考え、パーソルキャリアへ転職。業務基幹システムの内製開発チームとして参画し、システムの改善や運用のための仕組みづくりを主に担当。

※2020年8月現在の情報です。