パーソルキャリアがAPMで実践する“先回り”の改善サイクル システムが「動いている」から「良い状態」へ：doda基幹システムの監視改革（1/2 ページ）

システムの問題をどう見つけ、改善効果をどう測り、次の投資判断にどうつなげるか――。パーソルキャリアはAPMを軸としたオブザーバビリティーを実践し、継続的なシステム改善を進めてきた。オブザーバビリティーを組織に根付かせ、改善のサイクルを回してきた同社の取り組みについて聞いた。

[遠藤文康，＠IT]

　システムに潜む問題を、ユーザーからの問い合わせを待たずにどう見つけるか。アーキテクチャの変更や改善が効果を生んだのかどうかを、どう見極めるか。稼働データを次の改善や投資の判断にどうつなげるか――。システムを安定して動かすだけでなく、継続的に改善していく上では、こうした問いに向き合う必要がある。改善のサイクルをどう回すかが事業の競争力にも跳ね返る。

　その土台となり得るのが、システムの状態を継続的に把握するオブザーバビリティー（可観測性）だが、その価値はツールを導入しただけでは生まれない。何を指標として観測し、そのデータを誰と共有し、どのような意思決定につなげるのかという実践が重要だ。

　転職サービス「doda」を提供するパーソルキャリアは、2019〜2020年に実施した転職エージェントサービスの基幹業務システム刷新を機に、APM（アプリケーションパフォーマンス監視）を中心としたオブザーバビリティーによってシステムの状態を可視化し、改善効果を客観的に説明できる仕組みづくりに取り組んできた。その取り組みはクラウドへの全面移行や、保守運用プロセスの改革にも広がっている。

　パーソルキャリアはオブザーバビリティーをどのように活用し、システムの改善や意思決定の在り方を変えてきたのか。その歩みを聞いた。

システムが「動いている」から「良い状態」へ

　dodaは、求人情報を掲載する求人広告サービスと、キャリアアドバイザーが転職希望者の相談に応じながら支援する転職エージェントサービスの2つを軸としている。このうち転職エージェントサービスを支える基幹業務システムは、営業やキャリアアドバイザー、アシスタント部門など数千人規模の従業員が日常的に利用するものだ。同社は2017年ごろからこの基幹業務システムの刷新に着手し、十数億円を投じた「ビッグバンリプレース」を2019年に完了させている。

パーソルキャリアの石井孝典氏（ITアーキテクチャ統括部 アーキテクチャ管理部 エンタープライズアーキテクチャグループ　マネジャー）

　2017年に中途入社し、2026年現在は事業横断でシステムのアーキテクチャ改善を統括する石井孝典氏は、この基幹業務システムの刷新プロジェクトにアーキテクトとして参画した。当時から業界でも有数の規模を持つ事業会社（当時の社名はインテリジェンス）でありながら、システムを見る仕組みは十分とは言えなかったという。「非機能要件定義を進める中で、アプリケーションの保守やモニタリングに求められているものが十分ではないと感じました」と石井氏は振り返る。

　当時は死活監視が最優先で、「システムが動いているかどうか」以上の議論や、性能や利用状況、ユーザー体験まで継続的に捉える発想はまだ十分に根付いていなかった。

「システムが正常動作している」の先にある改善を目指す

　状況が変わり始めたのは、転職エージェントサービスを支える基幹業務システムの刷新が完了してからだ。安定性が向上した結果、運用に求められるものもまた変わってきた。何か起きた後の対症療法ばかりになるのではなく、「システムが正常に動作していることだけではなく、ユーザーにとって良い状態で提供できているかどうかを把握し、データを基に改善していく必要があるという問題意識が強くなりました」（石井氏）

　また石井氏らは社内の業務システムのアーキテクチャを横断的に改善する取り組みを推進しており、そうしたアーキテクチャ改善では、通常のテストだけでは気付きにくい性能劣化や負荷の増加といった変化も生じる可能性がある。改善が本当に効果を生んでいるのか、安全に進められているのかを判断するには、システムの状態を継続的に観測し、変更前後を客観的に比較できる仕組みが必要だった。

　そうした中で同社は、アーキテクチャ改善の一環でNew Relicのオブザーバビリティーツールを導入し、中でもAPMの活用によりシステムの状態を可視化してデータを基に継続的な改善につなげる活動を社内で推進してきた。

「問い合わせがない＝問題がない」ではない

パーソルキャリアの久保木翔一氏（ITアーキテクチャ統括部 アーキテクチャ管理部 エンタープライズアーキテクチャグループ　サブマネジャー）

　APMを推進する以前は、社内のユーザーから問い合わせがない限り、問題として表面化しないケースも少なくなかった。アーキテクチャ改善やAPMの活用推進を主導する久保木翔一氏は、ユーザーからの改善要望や問い合わせがないことが、必ずしもシステムが正常であることを意味しない点を挙げる。「当時は、利用者が問題として認識していないものの、システム内部ではエラーが継続的に発生しているケースがありました。APMにより、そのような潜在的な問題を可視化できるようになりました」

　性能についても同様だ。「レスポンスは理論上3秒以内、といった一般的な基準はありますが、実際にはユーザーが普通に1分ほど待っているようなケースもありました」（久保木氏）。潜在的な課題を掘り起こすためにも、システム内部の見える化は必要だった。

「アーキテクチャ改善の効果」をどう見るか

　APM導入の背景には、アーキテクチャ改善の効果をどう説明するかという問題もあったと石井氏は説明する。事業要望に基づくシステム改修であれば、売り上げや利用者数といった企画側の数字で投資対効果を判断できる。一方、技術的な改善はそうはいかない。

　「例えば特定のライブラリを置き換えることでパフォーマンスが向上した。耐障害性が上がった。あるいはお金をかけてシステム構成を変更した結果、可用性が上がって開発生産性も上がった。こうした話は、効果を説明するのが難しいのが実情です」（石井氏）

　さらに厄介なのは、改善したつもりの変更が、実は新たな問題を生んでいるかもしれないことだった。「業務機能であれば、ボタンを押してエラーが出るので分かりやすいのですが、アーキテクチャの構成変更は、安全面を確保する一方で少しずつCPU負荷が上がることもあり、気付きにくい問題や対応の手間が増えることもあります」（石井氏）

　こうした変化は、通常のテストでは見つかりにくい。改善が本当に効いているのか、それとも気付かないうちに別の問題を招いているのか。それを判断するには、システムの状態やインフラの負荷を定点観測し、変更の前後を客観的に比較する必要がある。