はじめに
前回の記事では、Laravel移植後のテストコード戦略について記録しました。
今回はシリーズ最終回として、リファクタリング・業務フロー改善、そしてプロジェクトを完走して思うことを記録します。
①負債の把握 →
②Laravel/インフラ移行 →
③テストコードで保証 →
④リファクタリング＆業務改善（今ここ！）
リファクタリングの進め方
優先順位の基準：影響の小さい箇所から本丸へ
テストコードが完成し業務も通常通り回っている状態（バグを潰しながらではありますが）からリファクタリングを開始しました。
方針は業務影響が大きくクリティカルなロジックは一旦後回しにして、画面表示だけのシンプルな箇所から手をつけるです。予約・決済などの核心ロジックはあまりにも複雑で、いきなり手をつけると影響が大きすぎるため、まず影響の軽い箇所でリファクタリング後のディレクトリ構成を整えながら本丸に備えました。
「シンプルな箇所」でもひと仕事あった
ただし「影響のない箇所から」と言っても、一筋縄ではいきませんでした。
例えば料金を表示するだけのページでも、料金マスタがテーブルではなくロジック内の配列にベタ書きされている状態でした。これを正すだけでも以下の作業が発生します。
- マスタテーブルを新規作成する
- 既存データとの紐づけを確認する
- ページ表示と決済時の料金参照先を新テーブルに切り替える
「影響のない箇所から始めざるをえなかった」というのが実態で、それほど全体に負債が染み込んでいました。
レイヤーを整えながら進める
リファクタリングと並行して、コードの構造を以下のレイヤーへ整理していきました。
- Repository層：データアクセスを集約
- Service層：何度も呼び出される機能単位のロジックを切り出す
これにより、複雑に絡み合っていたロジックが徐々に見通せるようになっていきました。
業務フロー改善：ビジネスとの対話で進める
リファクタリングと並行して双方向で
業務フロー改善はリファクタリングと並行して進めました。進め方は双方向です。
- エンジニア側から：「このロジックは使われていないようだけど必要ですか？」
- ビジネス側から：「今これが不便なので改善したい」
根が深いものは後回しにしましたが、画面の表示や文言改善などすぐに対応できるものはその場で反映しました。小さな改善を積み重ねることで、ビジネス側との信頼関係を少しずつ深める。これはかなり重要です。
経理の締め作業がワンクリックになった
ハイライトの一つが、講師報酬の計算・締め処理のリファクタリングです。
リファクタリングも進みロジックや構造がシンプルになるとこれまで複雑すぎて手がつけられなかったロジックも影響を抑えながら変更可能になります。そこで今まで複雑すぎて手がつけられず、かつ業務上の手間がかかっていた講師報酬計算・締め処理のリファクタリング及び業務改善を実施しました。実施にあたっては、経理の方が実際にシステム上で行っている作業とその後にExcelで行っている手作業を一緒に見せてもらい、その一連の流れをワンクリックに集約しました。
担当者が1人なのでリアクションはシンプルに「便利になった」でしたが、1日かかっていた締め作業がワンクリックになったという事実は十分な成果です。
定例会議・定期リリースで信頼関係を作る
リファクタリングと並行して、開発タスクの管理運用も整えました。
もともとこのサービスでは、創業者が「やらない」「技術的に難しい」などの理由を説明せずに放置していたタスクが多数ありました。ビジネス側は要望を出すことを半ば諦めている状態です。
そこで以下の運用を始めました。
- 週1回の定例ミーティングで開発タスクを一覧化し優先度をつける
- 今着手できないものはその理由を明確に説明する（「このリファクタリングが終わらないと手がつけられない」など）
- 週1回のリリース時に「今週はこのタスクが反映されます」とアナウンスする
この運用をしばらく続けると、ビジネス側がやりたいことや修正してほしいことを週次ミーティングで積極的に出してくれるようになりました。システムが複雑だから諦めていた企画やキャンペーンの相談も来るようになり、「今はできない」「すぐできる」を一緒に判断できる関係になりました。これはこのプロジェクトの中で最もうまくいったことの一つだと思っています。
完走して思うこと
途中で終わったが、やりきった
正直に言うと、完全な完走ではありませんでした。テーブルの整理やフロント側のリファクタリングを終える前に会社が吸収合併され、プロジェクトは途中で幕を閉じました。
ただそれまでに達成できたことを振り返ると、自負できるものが揃っています。
- 決済ロジックのリファクタリング完了
- 全ユーザーの復号可能なパスワードを復号不可能な形式へ移行
- MySQLを5系から8系へアップグレード
- LTV・チャーンレート・講師のコンバージョンレートなど、これまで正確に取れなかった指標を正確に計測できるように
- GitHub Actionsによる自動リリース（ECS Fargate）への切り替え
ヤバかったシステムを、一通り普通のシステムにできました。自分で言うのもなんですが、いい仕事だったと思っています。
そして吸収合併後の運命
余談ですが、吸収合併後にこのシステムがどうなったかをお伝えします。
さくらインターネットのVPS上でPerlで動く別システムに統合されたそうです。
今ちゃんと動いているかなあ……。
このプロジェクトで学んだこと
技術的な負債はコードの問題ではなく、ビジネスの歴史の堆積です。創業期の苦労、成長の痛み、属人的な運用の積み重ねがコードに刻まれています。それを「敵」として倒すのではなく、ビジネス側と対話しながら一つひとつ解きほぐしていく作業でした。
1人エンジニアとして動く中で最も大切にしたのは、ビジネス側との信頼関係を壊さないことでした。エラーが出ても「改善の証拠」として受け取ってもらえる関係、やりたいことを素直に相談してもらえる関係。それを作れたことが、技術的な成果と同じくらい重要だったと思っています。
シリーズを通じたまとめ
4回にわたるシリーズを振り返り、このプロジェクトのポイントを改めて整理します。
経営・ビジネス視点で
- セキュリティと事業継続性のリスクは、エンジニアから経営に提言すべきです。今回は私から言い出しました
- システム刷新と業務改善は同時にやらない。現場体制を尊重した順序が信頼を生みます
- テストコードは追加コストではなく、事業継続性への投資です
- **「完璧なシステム」より「すぐ直せるシステム」**のほうが、小規模体制では現実解です
- 開発タスクの透明な管理と説明が、ビジネス側がシステムを信頼する土台になります
技術視点で - インフラを先行させALBで新旧を並走させることで切り替えリスクを最小化できます
- 意図不明なロジックは一旦そのまま移植し、リファクタリングは後フェーズに積み残す
- ファイルアップロードロジックを1箇所に集約してからS3切り替えをすることで修正漏れを防げます
- リファクタリングは影響の小さい箇所から始め、構造を整えながら本丸に備える
このシリーズ
- その1：負債の可視化と刷新の方針
- その2：Laravel移植とインフラ移行の実録
- その3：テストコードで挙動を保証する
- その4（本記事）：たった1人で挑むリファクタリング・業務フロー改善・そして完走