TECH PLAYの古川雄大と申します。よろしくお願いいたします。
「リプレイスと既存サービスの開発を並行するために実施したこと」という内容で発表を始めさせていただきます。

私の自己紹介を簡単にさせてください。
私はパーソルイノベーション株式会社のTECH PLAYでエンジニアを務めています。古川雄大と申します。経歴をお話しすると、2019年4月に独立系SI企業に社内SEとしてジョインしエンジニアとしてのキャリアがスタートしました。そこでは、RubyやPhython、JavaScriptなどを用いて、WEBクローラーの開発や社内向けシステムなどの開発を行いました。
その後、2021年5月にパーソルイノベーションの株式会社の求人検索サービスにバックエンドエンジニアとしてジョインしました。そこではPythonを使用したAPIの開発やバッチ処理の開発、検索エンジンのチューニングなどを行っていました。その後、グループ内移動を経て、2022年4月にTECH PLAYにジョインしました。

TECH PLAYでは、エンジニアとしてフロントエンドからバックエンドまで幅広くサービスの開発に携わっています。余談ではありますが、今回が人生で初の登壇になります。緊張してうまく話せないこともあると思いますが、温かい目で見ていただけると助かります。今回のアジェンダになります。

まず、最初に簡単ですが、TECH PLAYの紹介をさせてください。これが実際のウェブサイトになります。掲載しているコンテンツはイベントだったり、マガジンだったり、ブログだったり様々ありますが、一番メインで行っているのがIT関係のイベントや勉強会の情報掲載です。

最近だと、新しく書籍の追加を行いました。他にはイベント主催者側がイベントを開催して実施したり、それを管理するためのイベント開催グループ向けの管理サービスや私達TECH PLAYのメンバーが使用する社内向けの管理サービスなどがあります。TECH PLAYの紹介はこれくらいにして、次はリプレイスの概要について話していきたいと思います。
まず前提として今回のリプレイスは進行中になりますので、認識をお願いいたします。

ではなぜリプレイスをするのかです。理由としては、大きく分けて事業的な要望と技術負債の解消の2つです。1つ目が新規コンテンツの開発や改修を容易に行えるようにしたい。
また、スマホアプリやAPI公開など情報伝達の手段を多様化したいという事業的な要望です。2つ目がプレゼンテーション層にビジネスロジックが混入していることでバグが発生しやすいこと、言語やミドルウェアなどのバージョンを上げていないために、技術的な情報収集が難しかったり、ライブラリやSDKが対応していないなどの技術負債があり、それを解消したかったからです。

また、なぜリファクタリングではなくリプレイスかというと、サービス開始から今まで9年、コツコツと開発を続けてくる中でリファクタリングも適宜行ってきましたが、アーキテクチャが古くなり、ボトムアップでコードを綺麗にしていくようなリファクタリングでは対応しきれなくなったからです。これらの理由からリプレイスを行うことにしました。

次に、リプレイスの概要です。まずメンバーですが、PDM一人とフルスタックエンジニア4人の計5人です。期間は6ヶ月になります。対象のサービスはTECH PLAYイベント開催グループ向け管理サービス、社内向け管理サービスの全てではありますが、全サービスの中で影響範囲が一番狭いことから、社内向け管理サービスを先に実施することになりました。ゆくゆくは本リプレイスで得た知見や技術を元に他サービスに展開していく予定です。

次に、本題の既存サービスと並行して、リプレイスを行うために実践したことです。まずはリプレイスにおけるルールを策定しました。1つ目が機能の大幅な変更は行わないことです。
あくまでもリプレイスなので、追加工数を発生させないためにも、機能は移行のみで変更は行いませんでした。ただし、工数を削減するために利用されていない機能は、移行の対象外にするようにしました。利用されていない判断はユーザーヒアリングを行い、その結果を基にチームでディスカッションし判断しています。

また、新規機能は新環境のみの実装にしています。リプレース期間中に新たに必要になった機能に関しては、旧環境には適用せずに新環境のみの適用で済ませています。二つ目がCSSフレームワークのデザインを優先することです。工数を減らすために、CSSフレームワークのデザインを優先し、独自のデザインは極力避けるようにしています。

ただ、フレームワークのバージョンアップで発生する1ピクセルの違いなどの変更は許容しています。また、赤色はキャンセルボタンなどのデザインに意味を持たせる要素に関しては変更を許容し、既存の仕様に合わせていくようにしています。以上がルールになります。タグ付けは、既存サービスの開発と開発とリプレイスを並行して実践するために工夫したことです。

まず、1つ目がリリースによる影響範囲を最小限にするために、パス単位での機能の切り替えを可能にしました。これはロードバランサーのパスベースルーティングを使用して行っています。そうすることで、機能単位での細かいリリースができ、バグが発生した際も影響範囲を最小限にすることができました。

また、切り戻しもすぐできます。そのため、他のタスクを行っている際も切り戻しだけ先にしておけば、あとから修正ができるので、頭や環境を切り替える必要がなくなりました。次に、コンフリクト・デグレを回避するために共通するコンポーネントやモデルの先行実装を行いました。チームで必要になるコンポーネントやモデルを洗い出し、実装者を決めて一気に実装します。

ここで共通処理の実装待ちが発生して、開発全体が止まるのを避けるために知見があり、技術力の高いエンジニアが実装するようにしました。次に、リリースサイクルの高速化を行うために2つのことを実施しました。1つ目が自動テストを導入して確認工数を最小限にすることです。

私たちのチームには、いわゆるQAエンジニアのような専任で品質を担保する人がいません。そのため、チーム全員で確認を行い、品質を担保していました。ただ、その結果、リリース時にはかなりの確認工数がかかっている状態でした。なので自動テストを導入して機械的に品質を担保して工数を下げるようにしました。
しかし確認作業のためにリリースを週1にしていましたが、その必要がなくなったため、最小限の実装で好きなタイミングでリリースができるようになりました。

2つ目がCI/CDの自動化です。
GIitHub Actionsを用いて設定してあるブランチにマージされたら自動でテストとデプロイが走るように設定しました。最後に相談しやすい環境を作るために、隔週での振り返りを実施しました。学習の振り返りでは、個々のタスクの進捗だけではなく、課題や懸念点を共有し、メンバー全員で解決に当たり結果一人で悩みすぎて時間がかかることがなくなり、プロジェクト全体の遅れも発生しづらくなりました。

また、チーム力も向上したと感じています。これらのルールや工夫のもとにリプレイスを行なってみてどうなったかです。まず良かったことです。1つ目がルールを決めたことで、余剰な開発の発生を防げたことです。これにより、追加の工数の発生を防ぐことができたと感じています。

2つ目がリリースにより、問題が発生した際も着手中の作業を止めずに行うことができたことです。パス毎の切り替えができるので、新環境に機能移行した際に問題が発生してもすぐに対応する必要はなく、切り戻しを行い着手していました。
既存サービスの開発だったり、移行作業だったり、着手中の作業に専念することができました。

3つ目がテストやCI/CDの自動化を行うことでリリース時にかかる工数を減らせたことです。自動テストの導入やCI/CDの自動化を行うことで、毎週確定でかかっていた工数を減らすことができます。

4つ目がコミュニケーションがスムーズになり、意思決定の速度を向上できたことです。学習の振り返りで、事前に課題や懸念点を共有しておくことで、納品時に何かあった時にかかるコミケーションが削減でき、意思決定がスムーズになりました。

5つ目が開発のフォローに入れたことです。これも各週の振り返りがあることで、メンバー間の状況を把握することができ、フォローが入りやすい状態が作れます。

次は課題に感じたことです。1つ目が開発とレビューが同時に走っていたが、開発を優先したためにプルリクが塩漬け状態になり、その結果実装内容を忘れてしまったり、コンフリクトが発生したりしたことです。

コンフリクトに関しては、発生しないように、共通処理を先んじて実装する対応はしていましたが、それでもプルリクが長期間放置されることにより、コンフリクトが発生する状態になっていました。それに対する対応策として、レビュー期間を別途設けて、プルリクが長期間放置されない状態を作ろうと考えています。

2つ目がコーディングルールや設計思想をあまり明確にしなかったため、メンバーが思い思いに実装した結果、統一性がなくなったことです。リンカーを入れていたので、コードはある程度統一されていましたが、ディレクトリやファイル構成だったり、コンポーネントの粒度等、統一性がない状態になってしまいました。

それに対する対応策としてルールを決めた上で、リファクタリング期間を別途設けて統一していこうと考えています。最後にまとめです。既存サービスの開発と並行してリプレイスを行うのはなかなかに大変でした。でも、ルール化したことで予定通りに進められたのと同じ程度に進められています。

そのため、やっぱりルール化って大事だなと感じました。皆さんも既存サービスの開発と並行してリプレイスを行う際は参考にしてみてください。以上で、私の発表を終わりたいと思います。
ありがとうございました。

– - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 

古川 雄大 / TECH PLAY

2019年に独立系Sier企業に社内SEとしてジョインし開発の経験をし、2021年4月にパーソルイノベーションに入社。現在はソフトウェアエンジニアとしてTECH PLAYに関わるシステム全般の開発を行なっている。
TECH PLAY（パーソルイノベーション株式会社）
IT勉強会やセミナーなどイベント情報のプラットフォームである「TECH PLAY」を運営しています。「TECH PLAYERを増やす。TECH COMPANYを増やす。」というミッションを掲げイベント運営サポート、社内IT人材を育成する「TECH PLAY Academy」、DX推進における課題解決のためにプロフェッショナル人材をご紹介する「TECH PLAY PRO」も運営しています。

– - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 

ミイダス Techについて

ミイダスでは、様々な技術イベントを開催しています。connpassやYouTubeチャンネルでミイダスグループのメンバーになった方には、最新の開催情報やアーカイブの公開情報が届きますのでぜひご登録をお願いいたします。

イベントページ：https://miidas-tech.connpass.com/
Twitter：https://twitter.com/miidas_tech