パーソルキャリアのプロダクト開発統括部では、dodaのシステムリフォームを進めるプロジェクトが今年スタートしました。規模も大きく歴史あるシステムの抜本的改修は、関係者や調整ごとも多く、道のりは簡単ではありません。
今回はdodaのシステムリフォームのPMであり、システムアーキテクトを担当するプロダクト開発部 アーキテクトグループの石川篤から、プロダクト開発統括部で働くことのやりがいや、大規模プロジェクトを動かすことの醍醐味を訊きました。
より本格的な開発に携わりたい dodaの開発者ポジションに転職した理由
――かつては病院にて社内SEをしていたとのことですが、石川さんはなぜパーソルキャリアに転職を？
石川：前職では、病院内の閉じたWebシステムを扱っていたので、開発や保守に取り組む中で、より多くの人に使われるオープンなWebシステムを作りたいと思うようになりました。
前職で扱うシステムは、デザインも古いものでしたし、技術的にもそこまで高いものではないと自分自身感じていたので、世の中にオープンになっているサービスに携わり、技術的にもいろいろなことができるようになりたいと思い、当時のインテリジェンス（現パーソルキャリア）に応募しました。
――前職ではどうやって技術を身につけたのでしょうか？
石川：前職では手取り足取り教えてもらえるわけではなかったので、「ここを作って」と指示されたら、自分で調べて作ってみるというスタイルでした。「言われたことをどのようにして実現するか」を考える力が身についたかなと思いますね。パーソルキャリアに入社して、正しいフローや正しい設計思想などはこれまでの自分にはない部分だったと感じました。
――パーソルキャリアに入社した後は、どのような仕事に携わっているのでしょうか。現在のポジションに至るまでの経緯を教えてください。
石川：最初は、dodaサイトの機能改修や管理の方針決めなど、PMと呼ばれるポジションについていました。大きめのインフラ周りの機能改修も手がけていて、アルバイト求人情報のan（現在は終了）にも一部携わっていました。
今期からはシステムアーキテクトとして、機能改修よりもシステム全体の改善でPMを担当したり、システム自体をどう新しくするか、セキュリティをどう見直すかを中心とした改修をしています。また、dodaのサービス維持、継続にかかわるような保守作業の管理も行っています。
――機能改修とシステム全体改修では、考えかたやアプローチが異なるのでしょうか？
石川：異なると思います。機能改修は、たとえば「こういうボタンをつけましょう」「こういった検索機能をつけましょう」といったように、やることが決まっていますし、実際に改修した結果の良し悪しが純粋に売上の数字に出るため、結果をシンプルにとらえられます。
逆に、システムの改修は正解があまりないイメージです。「今こういう状態だが、何をどうしたら良くなるのか」から考えなくてはならないので、企画部分もシステム側で考え、決めていかなければならないという違いがあります。機能改修は規模によっては大変ですが、ゴール地点がはっきりしていると思います。
ゴールは見えなくともミドルウェアを見るのは楽しい――dodaシステムリフォームの醍醐味とは
――石川さんは、現在dodaのシステムリフォームに携わっていますが、この案件が始まった背景を教えてください。
石川：課題のスタート地点としては、システムの土台となるフレームワークが非常に古いものを使っていて、さまざまな要素が合わさって成立しているような状態だったため、とても不明瞭だった、という点です。これにより、開発作業の難易度が無駄に高くなってしまったり、障害が起きやすくなってしまったりしている、ということが問題になっている状況です。
こうなってしまった原因は、dodaサービス開始時からずっとシステムが継ぎ足しで作られ続けていた点にあります。今はその体制から抜け出そうとしていますが、これまでは社内に開発メンバーがいなかったため、SIerに外注してシステムを作る構造がこれまでずっと続いていて、受注したベンダーは発注された部分だけを要件通りに開発をしていた状態でした。場当たり的な対応が積み重なり、今の状況になってしまったと感じています。
――なぜ今、このプロジェクトに取り組むことになったのでしょうか？
石川：今までは、やりたいことだけを決め、細かい部分はSIerにおまかせというスタイルで開発が行われていました。開発するものの中身についての課題意識が、パーソルキャリアとしては弱かったのでしょう。今は少しずつ変化していますが、投資対効果で評価する文化だったこともあり、古いものを適切に直すことが売上にどう影響するかを話したところで、あまり社内的には響かない・・・。少なからず課題意識を持っていた人はいたかもしれませんが、実際に行動というアクションにはつながっていませんでした。
今のプロダクト開発統括部は、プロダクトの開発力を高めていく、スピードアップしていくということが課題でもあるので、そこにフィットしたのがこのプロジェクトだったということもあると思います。プロダクトの開発力を高めていくためには、dodaのシステムを全体的にもっときれいにする必要があります。それを実現するには時間もパワーもかかるので、重要な部分からまず着手するイメージです。
――どういった基準でリフォームする箇所を選んでいるのでしょうか？
石川：重要度と着手しやすさから選んでいます。現在取り組んでいるところは、インターネットに面した画面を作る機能の部分で、サイトを変える際には必ず触れる部分なので、改善できれば確実に開発効率も上がると考えています。古いものをそのまま使っていると、セキュリティリスクも高まってしまうので、そうしたものはなるべく早く排除していきたいです。
――具体的にはどのような方針で進める予定でしょうか。またその進め方を決めた判断基準があれば教えてください。
石川：まずはインターネットに面した画面を作る機能のサーバーをきれいにしようと考えています。
この領域については、MVCの分離ができていないことや、サーバー単位のセッションに色々な情報を持ちすぎていること、機能単位でプログラムが分割できていないなど、プログラムの設計自体の見直しが必要な課題がいくつかあります。
一方で複数の古いフレームワーク（seasar2やSAStrutsなどのサポート切れのものや、dodaを以前改修したベンダーオリジナルのOSSでないものも含む）を複雑に利用している状態でもあります。
プログラムを直してからフレームワークを綺麗にするよりも、フレームワークを綺麗にしてからプログラムを直すほうが効率的と判断して、まずはフレームワークリフォームのPJTを進めています。セッション周りなどは特に利用するフレームワークに依存して設計を考える必要があるため、フレームワークを先に乗り換えないとプログラムの設計見直しが二度手間になる可能性が高いと考えました。
フレームワークリフォームの方法は、少しずつ機能別に置き換えて進めようと最初は考えていましたが、新旧のフレームワークでセッションを共有できない技術的な問題や、1つ1つを手作業で実施することへの費用面の問題があり、置換パターンを分析して全ソースに対して一括で置換をかけてフレームワークを乗り換える方法を選択しています。一括作業でリスクは大きいですが、1機能ずつやっていくとかなりの時間、新旧フレームワークが混在した状態がしばらく続いてしまい、開発効率がより悪くなることも判断の一因になっています。
このフレームワークリフォームは2021年4月以降までかかる予定ですが、その次の作業としてはサーバー単位で保持しているセッションをKVSに保持する形に変更することや、機能単位でサーバーの分割（マイクロサービス化）、バック側のデータベースの一部の領域をRDSからの脱却することなどを進めていく予定です。
――効率性や費用面も含めて検討していたんですね。このプロジェクトはいつ頃からスタートしたのでしょうか？
石川：プロジェクト自体はつい先日始まったばかりですが、正式に着手する前にどうしたら良いか検討するための細かい調査や依頼先のベンダー選びなど、少人数での取り組みは昨年から行っていました。正式なプロジェクトのスタートは今期からという形になります。
プロジェクトは、「プロトタイプを構築する」ということを目的に進めています。リフォーム対象箇所は膨大な分量あるので、ひとつひとつやっていくと大変なことになります。そこで、古いものを新しいものに一気に書き換えることができるツールを作成し、パターンを作成して一括で書き換える方法を現在は取っています。9月までにこの作業を終える計画で今は動いていて、このやりかたでうまくいくようであれば、残りも同様に書き換えを進めていきます。
――いつまでにシステムをきれいにする、など目標はあるのでしょうか？
石川：正直、ゴールはまだ見えていません。漠然と「ここも良くないから、今やっている場所をきれいにしてから考えよう」と思って箇所はたくさんありますが、「こうなったら完璧！」と思える図はまだできていません。また、バックエンド部分も抜本的に見直そうとすると、現在のプロジェクト以上に莫大な工数や期間が発生しますから、なおさら見通しは立てづらいですね。バックエンド部分も本格的に着手しようとすると、よりコアな部分を見ていく必要があります。ドキュメントなども存在せず、他のシステムと共通利用している部分は、ソースを再確認したりテストを行ったりしなければわからないこともたくさんあります。
――1から作り直すという選択肢はなかったのでしょうか？
石川：その可能性も現状0とは言い切れません。データベースや基幹システムとつながっている部分をどう直すのか考えるより、抜本的に作り直してしまったほうが安上がりという考え方もあるかもしれません。
しかし、そうすると事業をどう継続していくかといった課題にぶつかると思うのです。やはり転職活動中のお客様を考えると、当社の都合でシステムが使えないということはあってはなりません。理想論では作り直したほうが良いですが、現実を考えるとできるところからやっていくしかないと考えてます。
――今回のシステムリフォームを進めるにあたって、大変なことを教えてください。
石川：今回のプロジェクトは、これまでdodaの開発経験がないベンダーさんに新規でお願いしているので、dodaについての説明や、テスト環境の作りかたを1から共有するのは大変ですね。
――大変さがありながらも、なぜ新しいベンダーに依頼することにしたのでしょうか？
石川：既存のベンダーさんは機能改修がメインなので、抜本的改修になると彼らの得意領域ではありません。それだと期間的にも工数的にも大変です。
今回は、システムリフォームを手がけるベンダーさんに依頼をしたのですが、やはり手慣れているなという印象を受けました。渡されたシステムを1から分析していくノウハウに強みを持っていて、こちらからの説明以上に自ら調査をして調べてくれているところも多くあるので新規のベンダーさんにお願いする判断になりました。
――ドキュメントもない中、新たなベンダーと進めていくのは大変な部分もあったのではないでしょうか？
石川：ベンダーさんと議論しながら手さぐりでやっています。私はフロント側の改修よりも深いレイヤーのミドルウェアとかインフラのほうが興味があるんですよね。そういう人は少ないみたいですね（笑）
――なぜ深いレイヤー部分のほうに興味があるのでしょうか？
石川：JavaやHTMLなどプログラムは、個人でも請け負うこともできるし、比較的に対応できるエンジニアは増えている印象です。しかしミドルウェアやインフラなど大規模なものは、大きなサービスでないと導入できない金額のものも多く、普段は触れられないものに対して、いろいろと考えて取り組める点が面白いと感じています。
これは、前職からパーソルキャリアに入った動機にもつながっていますね。トライアルをしてみて「こういう仕組みで動いていた」と発見したり、深い部分がどう動いているのかを理屈で理解できたりするとしっくりきます。共通機能は最初に作った状態でも便利なので、使い回しすることがほとんどですが、なんで動いているのか理由がわかると面白いですね。大変ですが、やりがいも感じています。
Webサービスとしてプロでありたいーー内製の技術力アップにも貢献を
――大規模な案件だと、スケジュールやスコープをきるのも大変ではないでしょうか？
石川：これはもう決めの問題かなと考えています。関係者にヒアリングしたり、発注しているベンダーさんにスケジュールを出したりしてもらってはいますが、テスト段階で何が起きるのかわからないのは仕方がないことなので、実際にやってみて柔軟に対応していく形になります。
――柔軟な対応力が求められますね…。そのために確度の高い仮説を立てることも重要だと思うんですが、その辺りはいかがですか？
石川：これまでの仕事で培ってきた感覚ですね。インターネット上にあるドキュメントなどから関連した事象を自分で調べたり、それをもとに関係者と会話したりして落とし込んでいく感じです。これは、前職で「とりあえず自分でやってみて」と言われてやっていたのが役に立っていると思います。
――この先は、どのようなことを実現したいですか？チャレンジしてみたいことを教えてください。
石川：今は、前職で得た知識や現場で仮説を立てながら取り組んで得られた知識をベースとして働いているので、もう少し広い範囲で知るべきことがあるなという課題意識があります。
たとえばアーキテクチャーのような案件は、今までもクラウド移設やセキュリティ導入などで携わってきたこともあり、全体的な知識はついてきていると思うのですが、作るだけで終わるのも良くないと感じているので、Webを管理する立場としてより専門性を持ってやっていきたいと考えています。
作る知識だけでなく、今動いているサービスをどう守るのか、どのような体制でやればより良くなるのか、今動いているサービスの維持継続をどう管理していくか、といった力を身につけていきたいですね。開発の体制はどのようなチーム分けが良いのか、サイトが落ちた際にどう検知してどのように直していくべきか、そういったことが起こらないようにどのように事前対応していくかなどは、プロジェクトを作るだけだと介入しない部分だと思うのですが、作った以上、どのように維持していくのかについても、専門性を持ってやっていきたいです。
――保守とはまだ別の考えかたなのでしょうか。
石川：保守という考えかたに入るものだと思います。
保守がいなければ基本的にサービスは立ち行かないと思っていますが、dodaでは追加機能に対する熱意が強い人は多くても、システムそのものをきれいにしたり適切な保守を行ったりする意識を持つ人はそこまで多くありません。
今回、リフォームのプロジェクトと並行して保守の見直しも少しずつ行っているので、これをより推進していきたいと考えています。個人的には、Webサービスに関するプロフェッショナルになりたいので、作る部分だけではなく、キープするための視点も必要だと思うのですが、まだそこが弱いとは思っています。
――内製で対応する範囲も変化していきそうですね。
石川：そうですね。これまで内製チームは開発が中心でしたが、作るだけではなく、自分の領域で出たエラーは自分たちで責任を持って直していくやりかたで今後は進めていきたいです。
これまでのように保守を依頼しているベンダーさんの職人芸に頼るのではなく、誰が見ても何が起きているかがわかるように変えていきたいと思っています。担当者がいないときに障害が起きても対応ができるように可視化し、誰がやっても同じように直せるようにしたいです。可視化しなければ自動化もできません。可視化さえしておけば、システムが自動的に直すような仕組みも作れると思うので、見える化を進め、自動化にも取り組んでいきたいですね。
――ありがとうございました！
（インタビュー・編集＝伊藤秋廣（エーアイプロダクション）／執筆＝The Text Factory（エーアイプロダクション）／撮影＝古宮こうき）
石川 篤 Atsushi Ishikawa
P＆M本部 プロダクト開発統括部 プロダクト開発部 アーキテクトグループ リードコンサルタント
2016年12月にパーソルキャリアに入社。前職は病院の社内SEとして病院独自のソフト開発や営業、導入支援に取り組む。現職では、システムアーキテクトとしてdodaのシステムリフォームを行っている。
※2020年7月現在の情報です。
