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

[遠藤文康，＠IT]

APMを「共通言語」に、保守運用の進め方を変える

パーソルキャリアの後藤拓馬氏（DX開発統括部 エージェントプロセス&システムデザイン部 エージェントアーキテクトグループ マネジャー）[

　保守運用の進め方にもAPMの活用が変化をもたらしたという。同社の保守運用は、グループ会社に全面的に委託されていたため、自社内でタイムリーかつ詳細に状況を把握にするには限界もあった。「何か問題が起これば報告は上げてくれますが、実際に何が起きていて根本原因は何なのかについて自分たちで把握することはできませんでした」。転職エージェントサービス基幹業務システムの開発・運用を統括する後藤拓馬氏はこう語る。

　セキュリティの観点からもログファイルによって全てが管理されていたので、ログファイルを見られる人と解析できる人しか状況を把握できていなかった。

　エンジニアもプロジェクトマネジャーも企画担当もしっかり入り込んだ方がいいという場合には、“APMツールで共通言語化できる”ことが重要だと後藤氏は指摘する。「保守にとっては、ログを集約して調べるというコストのかかる作業を減らますし、われわれにとっては、生のデータを見ながら一緒に会話できる。全員の思惑が合致した形で進められます」

　一方、システム開発の優先順位は業務要望に引っ張られがちだが、そうした中で「適切ではない状態」を指摘するのが難しいという課題もあると石井氏は言う。システムは業務要望だけで成り立っているわけではなく、保守運用の観点で動いているものもあれば、開発者の観点で動いているものもある。「何が良くないのかが可視化されれば、『このボトルネックを次のリリースまでに直しておきましょう』といったように、戦略的に対応策を検討できるようになります」（石井氏）

利用実態を基に性能要件や拡張を議論

　システムの性能や設計を適切に見直していく上では、システムが実際に「どれだけ使われているか」も可視化できるようになったことが役立ったという。以前はユニークユーザー数を継続的に把握する仕組みが十分ではなく、利用規模を正確に把握することが難しかった。

　転職エージェントサービスの基幹業務システムを刷新した際の非機能要件定義では、利用規模に関する一定の前提を置いていた。しかし、New Relicによって実際の利用状況を可視化した結果、その前提と利用実態との間に乖離（かいり）があることが明らかになった。これにより、システムの性能要件や将来的な拡張について、実データに基づいて議論できるようになったという。

「数値で語る」エンジニアが増えた

　パーソルキャリアでは、本番環境だけでなく検証環境でもAPMを活用し、開発途中でもエラーが見えるようにしている。「本番と同じものが出ていれば、エラーが瞬時に分かるので、リリースのリスクがかなり減りました」と久保木氏は語る。

　システムを継続的に改善していく上では、現場のエンジニア自身が日常的にデータを見て、数値を基に議論できるようになることも意義のあることだ。以前は本番環境のデータは、保守担当者やプロジェクトマネジャー、あるいは障害対応時の関係者だけが扱うようなものだったが、開発中からデータに触れられるようになったことで、エンジニアの側にも変化が生まれているという。

　「開発メンバーのデータに対する価値観が大きく変わった、というのが重要だと思っています。数値でものを語るエンジニアやPMがどんどん増えていく。私が見る限りでも、導入前後でKPIをきちんと語れる人が増えました」（久保木氏）

　後藤氏は、システムの状態を素早く把握し、データを基に仮説を立てて検証できることが重要だと話す。「『New Relicを見ればそれは載っているよ』という会話は日常的にされます。細かい情報はデータベースや分析基盤を見に行きますが、ぱっと傾向を見るのであれば5秒ほどで見られる。そこから企画の仮説を立てて検証するところが、かなりスピードアップしています」

---

　死活監視が中心だった運用から、システムの状態を継続的に観測し、データを基に改善の優先順位を判断する運用へ。パーソルキャリアがAPMの導入を通じて進めてきたのは、単なる監視の強化ではなく、システムとの向き合い方そのものの転換だったと言える。可視化されたデータは、保守ベンダーとの関係、開発現場の議論、そして事業側との対話の共通言語になっている。

　この仕組みは、グループ共通のデータセンター廃止に伴うクラウド移行も支えることになる。前編となる本稿に続き、後編ではクラウド移行においてオブザーバビリティーの基盤がどう生かされたのかを取り上げる。