お疲れ様です！IT業界で働くアライグマです！
これは2024年、前職のSaaS開発で取り組んだ経験です。バックエンドには、動いてはいるものの処理を追うのが難しいコードがあり、リファクタリングに取り組みました。Laravelの経験を活かして手を動かし、PHPUnitによるテストも併せて書きましたが、振り返ると大きかったのは、開発部の承認で改善に丸一日を使えたことです。
2024年当時は、AIにコードの生成や修正を任せながら開発を進めるAI駆動開発が、今ほど一般的ではない時期でした。ここでは、その当時の取り組みとして、コードを理解して整理する経験、動作を確かめるテスト、改善に使える時間がどう支えになったかを振り返ります。現在のAI活用を前提にした開発手順ではなく、前職での体験談として読んでいただければと思います。
動いているけれど、処理を追うのが難しいコードだった
入社直後、Laravelの経験を活かし、循環的複雑度（CC）が20を超える難解なコードを4件ほどリファクタリングしました。当時はバックエンド開発を海外拠点から国内へ引き継ぐ時期で、動作していてもメソッドが肥大化したコードが残っていました。処理を役割ごとに分けてブラックボックス化を減らし、保守性・可読性を改善しました。メソッドは、まとまった処理を受け持つ単位です。
対象には、分岐の多さからコードの複雑さを見る指標である循環的複雑度（CC）が20を超えるコードもありました。数字の基準を決める話よりも、実際の処理がブラックボックス化していて、変更のために理解する負担が大きいことが問題でした。
コード自体は動いていました。そのため、今回の目的は、目の前の不具合を直して動かすことではありません。処理を適切に分け、今後の仕様変更や機能追加で扱いやすい状態にすることでした。動作を維持しながら内部の構造を改善する、リファクタリングの取り組みです。
私は入社直後でしたが、Laravelを長く使っていた経験を活かして積極的に取り組みました。当時のチームには、私のほかにベテランのエンジニアが2名、若手が1名いました。自分が手を動かせる領域として、複数の難解なコードを段階的に改善していきました。
この経験を振り返ると、「動いている」と「変更しやすい」は別の状態だと感じます。今の動作を維持するだけでは、次にそのコードを読む人の負担は減りません。今回減らしたかったのは、その理解の難しさでした。
たとえば、実際のコードとは別の単純化した例として、会員の状態を確認し、割引を計算し、注文を保存する処理を考えます。全部が1つの長いメソッドに入っていると、割引だけ変更したい人も、会員条件や保存処理まで追うことになります。役割を分ければ、どこが判断を受け持ち、どこが計算を受け持つかを読み取りやすくできます。ただ行数を短くするのではなく、変更したい処理の位置と役割が分かることが、整理の意味だと考えています。
IT女子 アラ美
ITアライグマリファクタリングと一緒にPHPUnitのテストも書いた
リファクタリングにはPHPUnitのテストを併用しました。処理を分割すると、読みやすくなる一方で、条件の評価や実行順序を変えてしまう危険があります。コードを整理する作業と、変更前の動作が維持されるかを確かめる作業を併せて進めたことが、私にとって変更への不安を減らす支えでした。PHPUnitは、入力に対して期待した結果が返るかを自動で確認する、PHPのテスト用ツールです。
なぜ両方が必要なのかを、実際の業務コードとは別の例で考えてみます。入力の確認、金額の計算、保存が1つの処理にまとまっている場合、それぞれを別のメソッドへ分けると役割は読み取りやすくなります。しかし、分けた結果、不正な入力でも保存が進むようになったり、金額の端数処理が変わったりしては困ります。見た目の整理と動作の維持は、別々に確かめる必要があります。
この例なら、少なくとも次の観点を考えます。これは当時のテスト項目の再現ではなく、リファクタリングにテストを併用する意味を説明するための例です。
- 正常な入力に対して、変更前と同じ計算結果になるか
- 不正な入力を渡した場合、保存する前に処理が止まるか
- 金額が0などの境界でも、必要な動作が維持されるか
リファクタリングでは、構造を変えても、必要な動作は維持しなければいけません。読みやすく整理できたつもりでも、条件の扱いや処理の順番が変わって既存機能を壊してしまえば、改善とは言えません。こうした変更による不具合を、リグレッションと呼びます。
今回も、コードの分解とテストを組み合わせて、既存の動作を壊さないように進めました。テストを併用することで、変更の結果を確かめながら取り組める安心感もありました。難解なコードを読む負担に加え、変更して大丈夫かという不安まで抱えると、改善に手を付けにくくなります。
ただし、テストがあれば何を変えても安全になるわけではありません。確かめられるのは、テストに書いた条件と結果です。私がこの経験から持ち帰ったのは、「テストを追加したので安心」という結論より、コードを整理する作業に、動作を確認する作業も含めるという考え方です。
処理を分けることと、その変更を確かめることは、どちらも改善に必要でした。そして両方を進めるには、コードを編集するための時間だけでなく、テストを書く時間も必要になります。
IT女子 アラ美ITアライグマ開発部の承認で、隔週のBE OpsDayに丸一日を使えた
開発部の承認で、隔週・丸一日のBE OpsDayを確保していました。通常のスプリントとは別枠で、難解なバックエンドコードの改善に使う時間です。コードを分解できる経験、動作を確認するPHPUnit、それらに取り組む時間がそろいました。「直せる人がいる」ことだけではなく、その作業を開発部が仕事として認めていたことが、今回の改善を進められた背景でした。
通常のスプリントは、一定の期間で進める開発を計画する単位です。今回の負債対応は、そこに紛れ込ませた個人作業ではなく、別枠として時間が確保されていました。改善のために使う一日を、開発部が把握していたことに意味があったと思います。
この枠で、難解なコードのリファクタリングを進めました。単に私が「直したい」と思っているだけではなく、開発部として、その作業に時間を使うことを認めてもらえていたわけです。
ここが、自分の技術経験だけでは説明できない部分だと感じます。Laravelに慣れていることは、コードを読む・変更するために役立ちました。PHPUnitのテストは、その変更を確かめる助けになりました。しかし、それらを実行する時間は、技術力があるだけで自動的に生まれるものではありません。
改善する力と、改善に時間を使える環境は、両方必要でした。丸一日という枠があったことを振り返ると、成果を「自分が積極的に直したから」で説明するのは足りないと思います。技術的負債の解消に理解のある現場だったことも、取り組みを支えた条件でした。
この経験は、すべてのチームに隔週・丸一日が合うという話ではありません。当時の現場では、その形で時間を確保できたということです。日数や割合よりも、改善を開発の仕事として認めてもらえていた点が、私にとって大きかったです。
IT女子 アラ美ITアライグマBE OpsDayは途中でなくなった。それでも残った学び
BE OpsDayは途中でなくなりました。技術的負債の解消を継続する制度まで完成したわけではありません。仕様変更や機能追加では負債が入り込みやすく、一度コードを改善しても終わりにはならないと感じます。今なら、改善を考える際に「直す対象」「維持したい動作の確認」「時間を使うことへの合意」を分けて整理します。今回の経験でも、この3つがそろって手を動かせたことが、私の中心的な学びです。
当時の記録から、枠がなくなった理由や時期までは特定できませんでした。理由を補って、現場の誰かの判断を評価するつもりもありません。私が振り返れるのは、改善の時間があった時期に、リファクタリングとテストを併用して保守性・可読性の改善を進められたことです。
もう1つ残ったのは、仕様変更や機能追加の際には、技術的負債が入り込みやすいという実感です。複数の難解な処理を改善しても、そこですべてが終わるわけではありません。開発を続ける以上、また読みづらい処理や分けにくい構造が生まれる可能性があります。
だからこそ、改善できた事実と、その取り組みが続く条件は分けて考えたいです。今回、前者にはLaravelの経験とテストが役立ちました。後者については、改善に時間を使うことへの現場の理解が必要だと感じました。枠があったことだけで、継続まで保証されたわけではありません。
今この経験を振り返ると、開発環境を見るときも、「どんな技術を使っているか」に加えて、今あるコードを改善する時間を仕事として扱えるかが大切だと思います。新しい機能を作る力だけでなく、既存の処理を扱いやすくする力を発揮できる環境かどうかも、私には大切です。
もし同じような改善を考えている方がいたら、私は次の3点を分けて整理することを勧めます。今回の体験をもとに、今なら確認したいことです。
- 直す対象：どの処理が理解・変更しにくいのか。新機能の追加ではなく、何を扱いやすくしたいのか
- 動作の確認：構造を変えたあと、維持したい結果を何で確かめるのか
- 時間の合意：コードの変更と確認に使う時間が、開発の仕事として認められているか
今回の私には、複雑なメソッドという対象、PHPUnitによる確認、BE OpsDayという時間がありました。この3点を分けると、「腕の良い人が直せば済む」という説明では、作業を支える条件が抜けてしまうことが分かります。
IT女子 アラ美ITアライグマまとめ
難解なLaravelのコードに対して、処理を分けるリファクタリングとPHPUnitのテストを併せて進めました。その取り組みを支えていたのが、開発部の承認で隔週・丸一日を確保したBE OpsDayでした。
この経験を、自分の技術力だけで説明したくはありません。処理を読む・変更する経験、動作を確かめるテスト、改善に時間を使うことへの理解がそろって、手を動かせたと考えています。
BE OpsDayは途中でなくなったので、継続的な負債返済の仕組みを完成させたわけではありません。それでも、技術的負債の解消を個人の頑張りだけに任せず、開発の仕事として時間を認めることの大切さは、この経験から持ち帰った学びです。
IT女子 アラ美ITアライグマ
