dodaサイトが抱える技術負債を解消するべく、2020年11月にdodaリビルドプロジェクトが始動しました。
dodaサイトの適切な運用と顧客への価値提供、その先の事業成長に必要なことは何か。そして内製エンジニアとして果たすべき役割とは――プロジェクトをリードする中澤と佐藤の二人に、取り組みの現在地と思いを聞きました。
ポイントは、内製エンジニアが責任を持って管理できる仕組みづくり！
――まずは、今回dodaリビルドプロジェクトが始動した背景からお聞かせください。どのような技術負債があり、どのような影響を及ぼしていたのでしょうか。
中澤：dodaサイトが抱える非常に多くの技術負債の中でも、それらの根本であり最大の問題となっているのが、データベースのテーブル構成です。
dodaの根幹となるデータベースにはBAKSやARCS、Assistなど複数の基幹システムがつながっており、ここに新たに機能を追加したいとなると、複数サイトへの影響調査を行わなければいけません。このような背景から「既存テーブルの改修に時間と工数がかかってしまうのであれば、新しいテーブルを作ろう」という動きが頻発し、右肩上がりでテーブル数が増加してしまっていたのです。
その結果、システム上の速度が低下する、類似のテーブル・データが複数存在することによってデータの信頼性が落ちる、といった問題が恒常的に発生していました。他のシステムが追加したテーブル・カラムを参照しに行った結果、追加元の仕様変更の影響を受けてしまう、というリスクも孕む状況になってしまっていました。
――それぞれの事情でテーブルを追加するといったことが、許容されてしまっていたのですね。なぜ、解消されずに積み重なってしまったのでしょうか。
中澤：それぞれの事業が、自分たちの事業活動の中でやるべきことやスピードを優先し、個別最適で判断をしてきてしまったのだと思いますが、それでは全体で俯瞰して見た時に当然問題が発生しますよね。そして発生した問題を意識的に解消するという取り組みも、事業成長を追い求めることに劣後してしまっていたのです。
またそういった状況の中で、複数のシステムにつながった、あまりに大きなデータベースであることから、全体を俯瞰する視点と「自分たちの管轄内だ」という意識を持って管理・改善に取り組む人がいなかったことも、技術負債が積もった大きな一因なのだと捉えています。
――この状況を改善して正しく前に進むために、今回プロジェクトを立ち上げられたのですね。対処すべきは大きな課題ですが、どこから着手されたのでしょうか。
中澤：まずは何が問題なのかを見える化するために、3,000〜4,000あるテーブルを一覧化して、分析・ソース解析からスタートしました。その結果、dodaだけが使っているテーブルはわずか200ほどで、残りは複数のシステム間で同じものを参照し合い、同じレコードを更新しあっている状態だということが改めてわかったんです。さらに、組織・サービスの改変などによってそもそも使われていないテーブルも、多数見つかりました。
佐藤：中澤さんから逐一情報をいただいていましたが、私のこれまでの経験とは桁違いなテーブル数や、それらのテーブルを複数のサブシステムが更新し合っている状況に、率直にとても驚いたことを覚えています。データベースを運用することの難しさを痛感しましたし、これまでよくメンテナンスできていたな……とも思いましたね。
――そのような現状が見える化された後、どのようにプロジェクトを進めてこられたのか教えてください。
中澤：まずは今回のリビルドで何を解決するか検討し、「開発の生産性向上」「サイト速度の改善」「内製エンジニアチームが責任を持ってデータベースを管轄していく仕組みづくり」の3本の柱を立てました。
そこから、分析で明確になった課題をもとに、3つのフェーズを設けてリビルドを開始。まずStep1を調査フェーズとし、続いてStep2で技術検証を行い、Step3では技術検証で有効だったものを本番実装する流れになっています。
現在はStep2が佳境に入ったところですね。PoCでは、3本の柱の実現を見据えて①API統合環境の構築、②KVS環境の構築、③コンテナ環境の構築 の3つの対応を行いました。実際に動かしてみる中で新たな課題が見えてきたので、ここから「Step3の本番実装にどれを持っていくか」「本番に入れるにあたってクリアしなければいけない課題は何か」の検討を進めていきます。
API統合環境やコンテナ環境を構築することは、必ずしも短期的に開発生産性を向上させるものではありません。むしろ新しいものを作ることで、両方が稼働する切り替わりのタイミングでは二重管理が求められるなど、マイナスの側面もあります。
でも将来的には生産性が上がることが見込めますし、何より新しく作ることで「自分たち内製チームが主導して作り上げていく環境」ができることに、価値があるのだと思っています。どこのチームの主管でもないから好き勝手やってしまう、という状況をなくし、「自分たちが管理して守っていくんだ」という意識づけを大切にしていきたいですね。
――内製チーム主導であることに、重きを置かれているのですね。
中澤：単に今ある技術負債を解消するという観点では、開発の生産性とサイト速度さえ改善されればそれでいいんです。でも、技術負債は悪意を持って溜まるものではなく、日々の開発の中で自然と蓄積されていくものです。だからこそ「技術負債が存在すること」ではなく、「誰も手綱を握れていないこと」の方を問題として捉えるべきなのではと思っています。
この問題を解決するためには、課題に気付くための見える化と、日常業務の中でその課題を解決していくための仕組みづくりが必要です。そしてそれは、業務やシステムの現状を理解した上で柔軟に動くことができる内製エンジニアが、責任を持って行うべきだと考えています。
抽象的な「技術負債」というテーマを具体化できた価値
――現在Step2の技術検証が進んでいるということですが、実際に構築される中で想定外のことも多々あったのではと推察しています。検証の現在地や苦労されたことを具体的にお聞かせください。
中澤：私からは、担当している①API統合環境の構築と③コンテナ環境の構築 の二つについてお話しします。
①については、影響調査に要する時間を削減するために、既存のweb APIをクラウド上に全て載せ替え、各種テーブルの利用状況を把握できるよう改修を行っています。既存のAPIを全て新しいものにする方法もあるのですが、使っていないテーブルも存在していることを考えると非効率的なので、今回は「見える化」と「不要なものを削れる体制づくり」に絞って実施しています。
実際に構築してみる中で、既存の古い通信仕様がクラウドに対応しておらずスムーズにいかなかったり、またセキュリティ上の観点からAPIを呼ぶのに別途申請・審議が必要だったりと、既存のものをクラウドに載せ替えるだけでも、想定していた以上に作業コストがかかるとわかりました。ここは主に見える化が目的なので、そのためにここまでコストを払うべきなのか、他のやり方で見える化ができるか、を再検討しているところです。
――「③コンテナ環境の構築」についてはいかがですか？
中澤：これは、システム間連携を行う際に技術負債が発生することを防ぐために行っているものです。新たに事業を立ち上げる際の環境構築に、拡張性の高いコンテナ環境を使えるよう整備しています。既存のデータベースを切り分けることが難しいため、別の領域で新たにマイクロサービス化するという発想です。
ここで一つ課題になっているのは、パーソルキャリアのAWSに独自の事情や内部ルールがあるために、AWSを知っているエンジニアも入社してすぐには自走できない環境になってしまっていることですね。AWSの使い方や必要な申請など、根本的な仕組みのキャッチアップに最初は苦戦しましたが、AWS推進チームのサポートを受けてだんだん進みはじめた、というところです。
――佐藤さんが担当されている「②KVS環境の構築」についても、教えてください。
佐藤：KVS環境の構築は、サイト速度の改善に直結するテーマです。サイト速度を落とす原因の大部分は、クエリをデータベースに投げた際、テーブルの中にある100万単位の情報を引っ張ってくる際のスピードなどが占めています。そこで、必要な情報をレイテンシーの低いKVS環境に反映し、素早くデータを提供できる仕組みを作り、他に展開できるような形で仕上げようと取り組んでいます。
ここでは、KVSへいかにデータを転送するか、というところが一つの肝になります。CDC（Change Data Capture）を使って、データベースのあるテーブルにおけるレコードの変更を検知し、その変更を新しい情報としてKVSに適宜流すことで、最新のデータがほぼリアルタイムで見られます。現在はこの仕組みの作り込みをしているところです。
当初想定していたCDC技術の利用がコスト的に難しいとわかり、動き出した後に方向転換があったのは想定外でしたが、現在は別のOSSに切り替えてもその仕組みが実際に動くことを確認できています。
データ量についても、データベースの数件程度の変更を監視しKVSに連携できるところまでは確認できており、手応えもありますが、大量データの場合 / 常時稼働している状況下 でも実用に耐えうるのか、というところをこれからパフォーマンステストしていく必要があります。その結果を踏まえて、Step3の本番実装に向けて動いていけたらと思います。
――Step2全体を振り返ってみて、いかがですか？率直なご感想や、Step3以降への課題として認識されていることがあれば教えてください。
中澤：Step2までで、これまで内製エンジニアの中で抽象的なテーマでしかなかった「技術負債」が、かなり具体化できたと振り返ります。「どのテーブルに課題があるのか」「改善すべきはこの通信方式じゃないか」「優先度的に、ここを先に直さないとやりたいことができない」など、課題を具体的に共有し合えたことが大きいと思っています。
いずれデータベースを新しいものに変えていけたらとは思いますが、古いものはずっと残っていきますよね。そこにどのくらいコストを払い、どうやって付き合っていくのかについては、まだ明確に答えを出せていない状態で、これが今後の課題になります。現場の課題が具体化して見通しが立つようになったので、新たな課題にまた取り組んでいきたいなと思います。
リビルドは一度やって終わりではない。大切なのは、ずっと、何度もやり続けていくこと
――今回のプロジェクトでは特に内製エンジニアが責任を持ってサイトの管理・改善を行うことを大切にされていますが、お二人は内製エンジニアの役割や持つべき視点をどのように認識されていますか？
中澤：私は、事業会社の内製エンジニアになることで、システムに愛着と責任を持って仕事がしたいと思ってパーソルキャリアに転職してきました。ですが、業務や今回のプロジェクトを経て、今では「最後までシステムの面倒を見ることができるのが内製エンジニア」なのではなく、「最後まで面倒を見ることができる仕組みを作っていくことが、内製エンジニアの役割」なのかなと考えるようになりました。
保守まで考えてシステムを作り、保守をする中でFBを受けて改修をする、という「システムのスタートからエンドまで、責任を持って面倒を見られる仕組み」がこれまでdodaにはなかったので、それをきちんと作っていきたいと思っています。
佐藤：内製エンジニアであるからには、やはり「自社のサービスを良くしたい」という気持ちを強く持っていたいんですよね。そのためにも、作って終わりではなく今後の拡張性や保守を真剣に考えて、そこに責任を持って取り組んでいく存在であるべきだと思っています。
また、事業部門からの相談に親身になって応えたり、「ライトなものはすぐにやりましょう」と推進したり。そういった対話ができるのも、事業とシステムの両面を理解した内製エンジニアであるからこそ発揮できる価値かなと思います。
――ただ開発をするだけでなく、サービスの今後や運用のための仕組みづくりまで広い視野を持っていなければいけない、という感覚でしょうか。
佐藤：自分はこの役割だけ、となってしまうのはもったいないですからね。内製エンジニアはある意味フルスタックで、あらゆるところに目を向けてやっていくべきだと思いますし、そういう意識を持っている内製エンジニアが社内に多いと感じています。
中澤：「横に広く」というところは、事業会社の内製エンジニアとしてぜひ伸ばしていきたいところですね。
――そういった役割や発揮できる価値の幅広さが、内製エンジニアという立場の大変さでもあり、魅力でもあるのでしょうね。それでは最後に、dodaリビルドプロジェクトの今後について、意気込みをそれぞれお聞かせください。
佐藤：まずは、担当しているKVS環境構築をPoCで終わらせずに絶対に本番適用して、この先も展開していけるようにやってやるぞ、というのが今の強い気持ちです。
また将来的には、もう一度本当の意味でのリビルドが必要かなと思っています。今回は既存のデータベースをそのままに、できる範囲で今のパーソルキャリアに適した形のリビルドをやっていますが、いずれきちんと作り直すことが必要かなと。その時までにdodaでしっかりと経験を積んで、もう一度活躍したいと思います。
中澤：「リビルドプロジェクト」というと一つの大きなプロジェクトが走っている感覚になりますが、一回やって成功した、失敗した、というものではないと思っています。「こんな課題があるよね」と誰かが手を挙げたら、何回リビルドしても、何回失敗してもいいと思いますし、今回と違うメンバーが入ってやることでまた別の視点からできることがあるかもしれません。
大切なのは、ずっと、何度もやり続けていくこと。日々の開発の中で直面した課題に対して、その時々でみんなでまた新しい仕組みを作り上げていけるような世界観を、dodaの内製開発エンジニアの中に作っていきたいと思います。
――今回課題が見える化されたことで、次のリビルドに一歩踏み出しやすくなる。大切なベースが作られたプロジェクトだと理解しました。素敵なお話をありがとうございました！
（取材＝伊藤秋廣（エーアイプロダクション）／文＝永田遥奈）
中澤 勝 Masaru Nakazawa
プロダクト開発統括部 エンジニアリング部 dodaエンジニアリンググループ リードエンジニア
前職は独立系SIer。携帯キャリアの業務システム開発など幅広い業務システムに携わる。2018年6月にパーソルキャリアに入社し、EFOなどdodaサイト開発に携わる。
佐藤 政美 Masami Sato
プロダクト開発統括部 エンジニアリング部 dodaエンジニアリンググループ シニアエンジニア
SIer、会計パッケージベンダーを経て、2020年7月にパーソルキャリアに入社。入社後は、dodaサイト開発に携わりつつ、AWSを活用した新たな開発に取り組んでいる。
※2021年6月現在の情報です。
