ソフトウェアの開発・保守をする上でリファクタリングの重要性は語るまでもないですが、そのリファクタリングを継続的に行うというのはなかなか難しいです。個人レベルであれば、各々の意識と行動によってなんとかなりますが、組織全体として継続的なリファクタリングを行う文化を醸成するのはとても難しいです。ここでは継続的なリファクタリングを行う文化を醸成するためにどういったアクションを取り、そういった結果が得られたのかについてと、今後どうしていくかを書きます。ここから分かる通り今現在において継続的なリファクタリングを行う文化の醸成については失敗しています。
課題
「継続的なリファクタリングが行えていない」というのが課題ですが、具体的に私が「継続的なリファクタリング」としてどういったものを期待しているかを挙げておきます。
技術的負債の返済
おそらくリファクタリングと聞いて多くの方が連想するものかと思います。技術的負債を日々少しずつでも返済していく活動は当然期待しています。この活動を行うためにはどういった負債があるのかを把握しておくことが必要であり、そのために日常的な開発において負債を見つけては後で対応できる状態にするためFIXMEコメントを残したりするなどの活動も重要になってきます。
実装前のリファクタリング
仕様変更や追加といった日常の業務において例えば安易に条件分岐を実装することを推奨しません。その場合の多くで複数の責務が混在する状態となっているはずであり、適切に再設計することが重要です。このように小さな仕様変更や追加の実装を行う前に適切に再設計・リファクタリングを行うという活動を期待しています。当然リファクタリングを行うことによって工数は膨らみますが、この活動を避ければ避けるほど後に大きなしっぺ返しとなります。
その他の改善作業
ライブラリのバージョンアップ、typoの修正、TODO対応、ドキュメント整備などの小さな改善作業が日常的に行われることを期待します。
なぜリファクタリングできないかのリサーチ
「リファクタリングをしたほうが良い」というのは皆わかっているはずです。その上でなぜできないのかをリサーチしました。原因はだいたい皆同じで以下の通りです。
リファクタリングを行う時間がない
開発スタイルは様々あると思い思いますが、ここではアジャイル開発を想定してください。スプリント内にやらなければならないタスクがあり、そのタスクを消化することで精一杯であり、リファクタリングに費やす時間がないというものです。こちらに関しては正直プランニングが誤っていると言わざるを得ず、最初からリファクタリング作業を見積もったプランニングをすれば解決するはずです。
負債が溜まりすぎていてリファクタリングを行うには工数がかかりすぎる
すでにしっぺ返しを受けている状態です。明らかになんとかしたほうがよい状態と認識しつつも、それを行うには大規模な再設計が必要で、そんな余裕はないから後回しにするというものです。先ほどの時間がないというものに似ていますが、こちらは「やりたいけどできない」という意味でやや異なる理由となります。これを解消するにはまとまった工数を確保するしかなく、プロダクトオーナーあたりにそのための交渉を行う必要があります。
忘れる
純粋に日々の業務の中でリファクタリングという行為を行うことを忘れているというものです。「リファクタリングは行うべきですか？」と聞かれるともちろんYESだが、普段意識できてないが故にリファクタリングのタイミングのいつも逃しているというものです。継続的なリファクタリングを行う文化を醸成したい目的は主にこの「忘れる」という状態を限りなくゼロにするためと言えます。
改善のための一手
上記全ての原因を同時に解決できる手があります。それはリファクタリングを行う期間を明示的に設けることです。
リファクタリングを行う期間を明示的に設ける
隔週に1日、リファクタリングデーを設けます。会社によってはリファクタリングウィークだったりもするかと思いますが、このようにリファクタリングを行うことを目的とした期間を設定します。
効果はありました。まず、純粋にリファクタリングする時間がないという原因でリファクタリングできていなかった者は、この期間で認識している技術的負債の返済活動を行えています。また工数を確保できず着手できずにいた大規模なリファクタリングについても、隔週で少しずつ改善を進めるという動きができています。リファクタリングという行為を意識できておらず忘れているという者についても、「今日はリファクタリングをする日」となっていれば意識付けされるのでリファクタリングを行えます。
副作用
全ての原因を解消する銀の弾丸のような一手かと思われましたが、期待しない副作用もありました。
リファクタリング期間でしかリファクタリングしない
リファクタリングを行う期間が明示的に設定されていることによって、日常業務の中で「後ほどリファクタリング期間にリファクタリングする」や「この作業はリファクタリング期間に行う」といったコミュニケーションが行われることを観測するようになりました。リファクタリング期間でしかリファクタリングしないという状態は、私の期待する「継続的なリファクタリング」の姿とは異なるものです。原因の解消を目的としたあまり、本来目指したい姿からむしろ離れてしまったような感覚を持ちました。
次の一手を考える
リファクタリング期間の廃止
一旦リファクタリング期間は廃止しようと思います。1年近く継続してきたということもあり、リファクタリングの重要性や恩恵は感じてもらえたと思います。リファクタリングのための期間を失うことにより、日常業務の中でリファクタリングの時間を捻出してくれるような動きを期待しています。
プランニング前に現在の設計と仕様を把握する
これまでプランニングでは各タスクの要件と仕様を把握した上で行なっていました。ここで把握しておくものに「現在の設計・実装」を追加しようと思います。狙いとしては現在の設計や実装の抱える技術的負債や安易な実装によって生まれる技術的負債を認識してもらうことです。ここ認識があれば実装前にリファクタリングを行ったほうがいいかもという会話が行われ、リファクタリングを含めた工数を見積もるべきかどうかの議論に発展してくれることを期待しています。今までこの認識がなかったのかといえばそうではありませんが、詳細に「どのファイルのどのあたりにどういった変更を加えるつもり」という詳細さでタスクを見積もっているわけではなかったので、今後はそのくらいの詳細さを求めるようにしてみようと思います。一方で見積もりをこなうための調査にかかるコストが増えるため、その点は様子を見つつ要調整だと思っています。
PRでリファクタリングの必要性についてコメントする
これまで私が意図的に避けていたものですが、今後は積極的にコメントしていこうと思います。コメント行うことによって現在の設計・実装が抱える技術的負債や課題感を共有するとともに、それを解消するためのネクストアクションについて議論が行えます。この活動を行うことにより今解消すべき技術的負債についてはすぐに対応してもらうようコミュニケーションが取れるようになり、後ほど対応する技術的負債についてはFIXMEコメントとどう直すべきかについてのコメントを残してもらえるようコミュニケーションが取れるようになることを期待します。また、継続的に技術的負債についてコメントすることで実装者にその観点が芽生え、自発的に改善や意思の共有を行ってもらえるようになることを期待しています。
一つ注意すべき点としては、技術的負債についてのコメントはApproveを妨げるものであってはならないという点です。変更をリファクタリングを同時に行うべきではないように、変更を目的としているPRでリファクタリングに関するコメントがApproveを妨害するべきではありません。
最後に
リファクタリングの重要性は全員が理解しているものの、実際の業務の中でその活動を継続的に行うというのはなかなか難しいようです。継続的なリファクタリングの文化の醸成に成功した組織があれば、是非ともその秘訣を伺いたいものです。