リファクタリングは、きれいにするためではありません
先日、ある顧客との打合せで、
ソフトウェアをきれいにして、どれくらい儲かるのですか?
という、少し懐疑的なご意見をいただきました。
確かに、見た目をきれいにするだけであれば、それがどれほど売上や利益につながるのか、疑問に思うのは自然なことです。
しかし、リファクタリングの一番の目的は、ソースコードをきれいにすることではありません。
今後の開発スピードを上げることが、本来の目的です。
「きれいになる」のは目的ではなく結果です
長期間使われてきたソフトウェアでは、仕様変更や機能追加を繰り返すうちに、次のような状態になることがあります。
- 同じような処理が複数の場所にある
- 一つの変更が、思わぬ機能へ影響する
- どこを修正すればよいのか分からない
- 担当者によって実装方法が異なる
- 一部のベテランしか処理内容を理解できない
- 修正よりも、影響範囲の調査に時間がかかる
このようなソフトウェアでは、新しい機能を追加するたびに調査や確認が増え、開発スピードが徐々に低下します。
リファクタリングでは、機能や動作を大きく変えずに、役割の分離、重複処理の整理、インターフェースの明確化、テストしやすい構造への変更などを行います。
その結果としてコードが読みやすく、整理された状態になります。
つまり、きれいになることは目的ではなく、変更しやすい構造にした結果です。
将来の派生開発や機能拡張を速くする
リファクタリングの効果は、その後に行われる開発で表れます。
例えば、今後次のような予定がある場合です。
- 派生機種を開発する
- 次世代機種を開発する
- 新しい機能を追加する
- ハードウェアの変更に対応する
- 複数の製品へソフトウェアを展開する
- 不具合発生時に短期間で対策する
構造が整理されていれば、変更する場所や影響範囲を把握しやすくなります。
また、共通部分と機種固有部分が分離されていれば、既存資産を次の製品へ流用しやすくなります。
一回の変更で削減できる時間は小さく見えるかもしれません。しかし、仕様変更や派生開発が何度も発生する場合、その差は積み重なっていきます。
開発スピードの向上は、事業にも影響します
開発スピードが上がることで、次のような効果が期待できます。
- 開発に必要な人件費を抑えられる
- 新製品を早く市場へ投入できる
- 顧客からの仕様変更に早く対応できる
- 不具合発生時の原因調査と修正を早められる
- 派生機種を少ない工数で開発できる
- エンジニアを新しい機能開発へ振り向けられる
ただし、リファクタリングの効果を、単純に「実施したら何円儲かった」と測定するのは簡単ではありません。
将来発生するはずだった調査工数、手戻り、不具合、教育時間などを減らす取り組みだからです。
それでも、仕様変更にかかる時間、不具合解析の時間、テスト工数、新しい担当者が理解するまでの期間などを比較すれば、効果を確認することはできます。
特に、規模が大きく、構成が複雑で、今後も変更が続くソフトウェアほど、その効果は大きくなります。
新しい担当者が理解できる状態になっていますか?
リファクタリングには、開発スピード以外にも重要な効果があります。
それは、特定の担当者に依存しない状態を作ることです。
新しい人員を追加したときに、
- どこに何が書かれているか分からない
- 変更すると何が起きるか分からない
- 過去の経緯を知っている人に毎回聞かなければならない
- 不具合の原因や修正内容を説明できない
という状態では、人数を増やしても、すぐに開発力は上がりません。
場合によっては、既存担当者が説明やレビューに追われ、かえって開発速度が低下することもあります。
ソフトウェアの役割や構造が整理されていれば、新しい担当者も理解しやすくなり、仕様変更や不具合解析についても説明しやすくなります。
「あの人にしか分からないソフトウェア」は、短期的には動いていても、将来の開発にとって大きなリスクになります。
今後変更しないなら、リファクタリングは必要ありません
もちろん、すべてのソフトウェアをリファクタリングする必要はありません。
今後一切変更せず、機能追加も派生開発もなく、保守対応もほとんど発生しないのであれば、無理に手を加える必要はありません。
リファクタリングには、それ自体に工数と費用がかかります。
重要なのは、現在のコードがきれいかどうかだけで判断するのではなく、これからそのソフトウェアをどのように使い続けるのかを考えることです。
今後も仕様変更、機能拡張、派生開発、人員追加が予定されているのであれば、現在の構造が将来の開発スピードを妨げないかを確認する必要があります。
リファクタリングは、将来の開発に向けた準備です
リファクタリングは、見た目を整えるための美化活動ではありません。
将来の変更を速くし、不具合対応をしやすくし、新しい担当者が参加しやすい状態を作るための取り組みです。
- 仕様変更に早く対応できるようになったか
- 影響範囲を把握しやすくなったか
- 派生開発へ再利用しやすくなったか
- 不具合の原因を調査しやすくなったか
- 新しい担当者が理解しやすくなったか
こうした将来の開発力につながっているかが重要です。
リファクタリングの目的を正しく理解し、今後の製品計画や開発規模を踏まえて、必要な範囲から段階的に取り組むことが大切です。


