dodaサイトが抱える技術負債を解消すべく始まったdodaリビルドプロジェクト。前回は、課題の特定と3つの方針による解決施策について聞きました。
Step1,2で得られた結果をもとに、最終Stepの本番環境導入に向けて、どのような選択・判断を行ったのか。Step1,2を乗り越えた佐藤・中澤だからわかる開発現場での検討プロセスについて聞いてみました。
※撮影中のみマスクを外しています。
技術負債の解消に向けて、検証も大詰め
――まずは、改めてプロジェクト概要から教えてください。
中澤:dodaサービス開始時からの長い年月の中で蓄積された、技術負債を解消するために始動したプロジェクトです。「開発の生産性向上」「サイト速度の改善」「内製エンジニアチームが責任を持ってデータベースを管轄していく仕組みづくり」の三つの柱を立てて進めてきました。
Step1の調査フェーズでデータベースの利用状況を可視化し、システム課題を抽出。Step2の技術検証フェーズでは①API統合環境の構築、②KVS環境の構築、③コンテナ環境の構築 の3つの検証を行ってきたところです。
――最終的な検証結果はどのようになりましたか?①API統合環境の構築から教えてください。
中澤:そもそも、各システムで同一のテーブルを使っていることによる開発生産性の低さが課題になっていました。これを解決するために、バラバラに存在している複数のWeb APIの前面にAPI統合環境を作ることで、各Web APIの使われ方を見える化し、不要なものを削れるようにしようと動いていたのが①です。
PoCで実際に構築してみると「古い通信方式がクラウドに対応していないこと」「ログ出力の情報が不足していること」などからシステムに変更が必要で、環境をつくること自体に想定以上の工数がかかると判明したんです。本来①では新たに基盤を作るのではなく、呼び先を集約するポイントをひとつ立てる想定であり、そのために新規の基盤作りと同程度のコストを払うべきではないと、方針を変更することにしました。
最終的には見える化の別の手段として、アクセスログ・SQLログを統合し、CRUD図の自動生成ツールを構築することで「どのシステムがどのようにデータベースでデータ操作を行っているのか」を可視化する方法に着地しました。
――佐藤さんが担当された②KVS環境構築についてはいかがですか?
佐藤:KVS環境については、サイトの速度劣化を解決するために新たに環境を構築し、必要な情報を反映することですばやくデータを提供できるようにしようと取り組んでいるものです。方法としては、CDC(Change Data Capture)を使ってデータベース上のテーブルにおけるレコードの変更を検知し、その変更を新しい情報としてKVSに流そうと考えており、PoCでは実際にこの仕組みをST環境の中に作り込みました。
まだ本番適用はされていませんが、現在は運用を見据えたシステムテストのフェーズを迎えています。レコード変更の適切な反映など機能面で問題がないことは確認できており、あとは大量データが更新された場合を想定した負荷テストなどを行っていく予定です。
――③コンテナ環境構築についてもお聞かせください。
中澤:コンテナ環境構築については、システム間連携を行う際に技術負債が発生することを防ぐために、内製エンジニアが管理できる環境を新しく作ろうというもので、一通りプロトタイプを作り終えています。実はdodaのトップページについても別でリビルドプロジェクトが走っており、アーキテクチャを大幅に変更したいという要望があるので、ここと共同で進めることにしました。現在部署のメンバーがプロトタイプを持ってプロジェクトにジョインし、新たなアーキテクチャを作っているところです。
佐藤:ソースを見ましたが、「クリーンアーキテクチャ」に則ってアプリケーションが作られているので、保守性や拡張性も含めて良いものができそうだなと感じています。
検証結果をもとに、目的とコストのバランスをとった最善策を選択
――ここからは、技術検証を振り返って具体的にお話を伺っていきたいと思います。まずはAPI統合環境の構築について、どのような思いで方針転換の判断をくだされたのでしょうか。
中澤:CRUD図を作ることになるとは想定していなかったですし、エンジニア個人としては古い通信仕様をなくしたいという思いが強かったんですよね。30以上のシステムを一つひとつ私の手で直していくことも考えたのですが、やはり工数を考えると現実的ではないという結論に至りました。また今は内製エンジニアチームとして動いているので、このような「環境を整える」活動ができていますが、システム修正の外注も視野にプロジェクトとして始動するなら、業務観点でのROIを追求していく必要があります。
検証結果をもとに達成すべき目的とコストのバランスをとって選択した、あくまで今回の最善策であり、この既存の仕様についてはまだ課題が残ると捉えています。
――KVS環境構築については、前回の取材でも手応えを感じていると伺っていましたが、検証をさらに進める中での感触や気づきがあればお聞かせください。
佐藤:新しい仕組みなので、オープンソースのバグが発生したりと壁はありましたが、なんとか乗り越えてきてあと一踏ん張りというところですね。
今の段階ではKVS環境に反映されたデータが足りておらず、その点が性能をテストするにあたっての不安要素ではありますが、今後必要な情報を全てKVS環境に反映できるようになれば、サイト速度は劇的に改善されるだろうと想定しています。
中澤:速度はもちろんのこと、KVS環境があれば情報をキャッシュして参照できるようになるため、業務的な観点からも変化が大きいはずです。
例えば、現在はメッセージのページを回遊する機能がなく毎回一覧に戻らなければいけないのですが、ここでキャッシュができるようになれば、一覧に戻るのに数秒かかっていた時間が短縮されることも期待できます。個人のユーザーにとっても、メッセージを送ってアプローチする側にとっても、大きな変化が生まれるのではと思いますね。
――コンテナ環境の構築を、dodaトップページのリビルドと連携させようと考えられた背景には、どのような意図があるのでしょうか。
中澤:新しい環境を作って実際に皆さんに使ってもらうためには、適切なタイミングで業務のプロジェクトと連携することが重要になります。そうした中で、トップページのフロントを大幅に変えるというインパクトの大きなプロジェクトがあったことは、非常にタイミングがよかったんです。
またトップのフロントを変更するにあたって「バックエンドのレガシーな構造が障壁になっている」という声があり、要件も一致したことが決め手になりました。
新たに作り替えたフロントの構造が、内製エンジニア主導の環境とサーバー構成でうまく機能すると確認できれば、今後は既存機能の移設をはじめとしたアクションで、環境を「育てて」いくことができるようになります。最終的に、リビルドの当初の目的であった「内製エンジニアが管理している、開発生産性の高い環境」に近づけていけると期待しています。
エンジニアの価値を正しく伝えられる組織を目指す
――このようなプロジェクトを推進する中で感じるプロダクト開発統括部のカルチャーや、プロジェクトをやり遂げるために必要な“組織カルチャー”について、お二人の考えをお聞かせください。
佐藤:今のプロダクト開発統括部では、事業貢献やROIを出すことは一人ひとりがもちろん大切にしていますが、それ以上にエンジニアとして「ベースとなる“保守や拡張がしやすい環境”を自分たちで整え、作っていこう」とレガシーな仕組みに立ち向かう心意気を感じます。
トップページのリビルドについても既存の仕組みのままでやろうと思えばできたけれど、やはり内製エンジニアとして皆がやりやすい仕組みを整備することにチャレンジしたいという思いで、新たに作った仕組みを適用させようとしています。そういった環境への意識を持つエンジニアが多い印象ですね。
組織としても、マネジャーの言葉で動くというよりは一人ひとりの提案や考えを尊重してもらえる文化なので、だからこそ皆も「ここを直したい」と声をあげていくのかなと思います。
中澤:エンジニアの中では、言いたいことを言って、やりたいことに挑戦していこうという話ができるようになっていますよね。
その次の段階として、エンジニアの自由でやりたいことに挑戦するのに加え、やはり説明責任を果たして周りを巻き込むことをしっかりと意識していかなければいけないと思っています。いかにROIを示して業務的なメリットを見せていくか、事業側の方々とどうやりとりしていくのか、という部分でもカルチャーを作っていかなければ、という部分が今の課題ですね。
佐藤:これまでそういったカルチャーやルールが明文化されていませんでしたが、コーディングガイドラインなどができたことをきっかけに、今後動きが出てくると思うので、今がちょうど転換期なのだと思います。
中澤:そうですね。「直すべきところを直していこう」というチーム力と実績が出てきたので、今後はエンジニアの価値を周囲に正しく伝えられるように。ITコンサルタント、エンジニア、プロダクトオーナー、それぞれの役割の中で守るべきものを守りながらも、価値観を正しくぶつけ合っていく必要があるのかなと思います。
――それでは最後に、dodaリビルドプロジェクトの今後についてお聞かせください。
佐藤:KVS環境について、まずは性能的に問題ないことをしっかり示し、本番適用まで着実に進めていきます。今度は「dodaプラス」への展開や、他の機能に対しての実装などの話も上がっているので、今回の取り組みを広げていけたらと思います。
中澤:今回のリビルドが本番適用まで進んだ先では、個人的にはやはりレガシーな既存のデータベースに対してアクションしていきたいと思っています。実現可能性を考えて今回はマイクロサービス化する手をとりましたが、もう少し広い視点でデータベースを切り分けられないかという考えはまだ持っているので、今回見える化された課題を具体化して、直せるところを見つけられればまたリビルドプロジェクトとして着手していきたいです。
また今回の検証を含む一連の取り組みによって、既存の仕組みの改善にはdodaだけでなく周りを巻き込んでいかなければいけないということが改めてよくわかったので。個別最適ではなく、パーソルキャリア全体として良い方向に進む絵を皆が描けるように、部を超えた知識や課題の標準化にも取り組んでいきたいと思います。
――プロダクト開発のカルチャーも含めて理解が深まりました!ありがとうございました!
(取材=伊藤秋廣(エーアイプロダクション)/文=永田遥奈)
佐藤 政美 Masami Sato
プロダクト開発統括部 エンジニアリング部 dodaエンジニアリンググループ シニアエンジニア
SIer、会計パッケージベンダーを経て、2020年7月にパーソルキャリアに入社。入社後は、dodaサイト開発に携わりつつ、AWSを活用した新たな開発に取り組んでいる。
中澤 勝 Masaru Nakazawa
プロダクト開発統括部 エンジニアリング部 dodaエンジニアリンググループ リードエンジニア
前職は独立系SIer。携帯キャリアの業務システム開発など幅広い業務システムに携わる。2018年6月にパーソルキャリアに入社し、EFOなどdodaサイト開発に携わる。
※2021年11月現在の情報です。