14年目のサービスと今後も歩むためのリファクタリング戦略

2021/02/16に開催された「ラクスMeetup [Day1]／PM・リファクタリング戦略」で発表した資料です。

Transcript

1. #RAKUSMeetup 14年目のサービスと 今後も歩むための リファクタリング戦略 株式会社ラクス 西原 優人
2. #RAKUSMeetup 自己紹介 経歴 • 2015年に新卒でラクスに入社 • 「Mail Dealer」や「Chat Dealer」の開発を経 て現在は「配配メール」の開発担当 良く触る技術 • PHP • JavaScript • Node.js • PostgreSQL 西原　優人 (masato nishihara) Twitter : whiteFox_73 趣味 • アウトドア フットサル／スノーボード／バイク ／ペンギン • インドア 音楽鑑賞／ゲーム／ ペンギン
3. #RAKUSMeetup 配配メールとは • メールマーケティングに必要な機能を備えたメール配信サービス • マーケティングオートメーションツールを備えたプランもある • 現在サービス開始から14年目
4. #RAKUSMeetup 長く続くサービスの課題 • 長年続くサービスならでは負債が多くある ◦ 複雑化したコードや書式が古いコード • 手を出したいが躊躇してしまい放置されて月日が過ぎる ◦ 現在動いているコードに手を入れるリスクや直接利益にならない心理的抵抗感 • 秘伝のタレのように継ぎ足されていく過程で負債も日々増加 ◦ 「イケて」ない箇所が増える事で余計に腰が重くなる …
5. #RAKUSMeetup 課題に向き合うきっかけ チーム状況の変化 • チームメンバーの増加 ◦ 3年間で6名→11名 • 1バージョンでの開発工数増加 ◦ 3年間で約11人月→約23人月 コードに手を入れる人や機会が増えた。 課題を放置するとこれまで以上の速度で負債が増加し手が出せなくなる…
6. #RAKUSMeetup そうだ、リファクタリングしよう。
7. #RAKUSMeetup リファクタリング対象の選定 • 今後の開発で手を入れる可能性が高い ◦ フロントエンド周辺 • 明確に負債になっている ◦ 開発メンバーの多くが負債と感じるコード • 将来的にモダンな開発環境を目指す ◦ 今後モダンな開発に移行する可能性を見据える
8. #RAKUSMeetup リファクタリング対象の決定 PHPコードに組み込まれたJS • PHPとJSが入り乱れて分かりにくい • JSが文字列だからシンタックスハイライトされて いない • 参照先に飛べない • 最終的なJSのイメージが掴めない 見たくない…
9. #RAKUSMeetup リファクタリング対象の決定
10. #RAKUSMeetup リファクタリング対象の決定 見やすくなった
11. #RAKUSMeetup リファクタリング後に得られる効果 • 可読性の悪いコードが要因となる以下のリスクを低減 ◦ 調査の効率低下 ◦ 実装の効率低下 ◦ レビューでの見落とし • IDEの機能を利用可能になることで効率UP ◦ シンタックスハイライト ◦ 参照先ジャンプ ◦ その他様々な機能…
12. #RAKUSMeetup リファクタリング対象の絞込 • 対象が膨大 ◦ 対象となるjsの関数は約2500個以上 ◦ 楽観的に見積もったとしても工数は 50人月以上 • 実施できる量まで絞込 ◦ フロントエンドで最も利用されているファイルの関数に限定 ◦ 220個程度まで絞り込めた
13. #RAKUSMeetup リファクタリングへの3つの懸念点 • 対象数が多いので、開発工程毎にコストがかかりそう • 工数が大きいので、追加のタスクがあった場合に影響が出そう • 工数のかかるリファクタリングを行う事への不安感
14. #RAKUSMeetup リファクタリングの工夫（1/3） 懸念点：対象数が多いので、開発工程毎にコストがかかりそう 　工夫：リファクタリング対象をパターン分け • パターン毎に対応方針と設計を実施 • パターン毎に工数を見積る（工数 × 対象数） • オフショアへ発注もパターン毎の設計書とサンプルを提供し引継ぎ 　　→ パターン分けしたことで設計の一部や準備のコストをカット
15. #RAKUSMeetup リファクタリングの工夫（2/3） 懸念点：工数が大きく追加のタスクがあった場合に影響が出そう 　工夫：柔軟性の高いタスクとして準備 • 複数バージョンで実施する前提で計画 • 3h~4h程度のタスクに分割 ◦ 緊急度の高いタスクが追加された際は最初に削る候補 ◦ オフショアで急な空きリソースが出た際は適時追加発注 　　→　リリースへの影響が少なく、安定する
16. #RAKUSMeetup リファクタリングの工夫（3/3） 懸念点：工数のかかるリファクタリングを行う事への不安感 　工夫：開発チームとビジネスサイドチームに実施イメージを説明 • to開発チーム ◦ 現状のままでは計画通りの開発が困難になる課題感の共有 ◦ リファクタリングのサンプルや複数バージョン先までの計画を用いた実行イメージの共有 • toビジネスサイドチーム ◦ 開発チームの課題を伝え、納得感を持ってもらう ◦ リリースには影響を与えない計画を共有し安心感を持ってもらう 　　→　チーム全体で納得感・安心感を得てリファクタリングを実施
17. #RAKUSMeetup 現在の状態 • リファクタリングを分割した第1弾のリリース直前 ◦ 開発終盤に優先タスクが追加されたがリファクタリングタスクを減らすことで、 無理のない開発が行えた → 工夫2（柔軟性の高いタスク）の効果発揮 • リファクタリングを分割した第2弾の作業中 ◦ オフショアに空きが出た際に追加で発注し対応 → 工夫1（パターン分け）の効果発揮 → 工夫2（柔軟性の高いタスク）の効果発揮
18. #RAKUSMeetup 今後の展望 • 現在進行中のリファクタリングを完遂 • 今回絞込で漏れたものや規模の大きなリファクタリングを順次実施 • オフショアチームのスケジュールに余裕が生まれた時の追加依頼ストック • JSを分離したことで、Type Scriptへのハードルが下がったので導入検討
19. #RAKUSMeetup まとめ • 長年に渡り手を出せなかったリファクタリングの一歩を踏み出せた • リリースサイクル、チーム状態を意識した工夫で順調に進捗 • 今後のリファクタリングのモデルケースに出来た
20. #RAKUSMeetup まとめ • 長年に渡り手を出せなかったリファクタリングの一歩を踏み出せた • リリースサイクル、チーム状態を意識した工夫で順調に進捗 • 今後のリファクタリングのモデルケースに出来た そうだ、みんなでリファクタリングしよう