プロダクトのバージョンメンテナンスをサボるメリットは皆無に等しい

サービスをローンチした当時は最新であっても、時間が経てばだんだんと古くなっていくコードやフレームワーク。そのまま運用していても支障をきたすことはないですが、いざ新しい技術を使いたい、もっと便利なフレームワークを使いたいとなったとき、まず古いコードを修正して最新の状態にアップデートしなくてはなりません。

それらにどのくらい工数がかかるか、果たして正確に見積もることができるでしょうか。そもそも過去の古いコードを知っているエンジニアはどのくらい残っているでしょうか。コードのメンテナンスを後回しにすることは、後々になって想定以上の負債をもたらすことになるのは想像に難くないです。

いわゆる 「夏休みの宿題に最終日まで手をつけずに自分の首を締める」 みたいな感覚に近いかもしれません。

最近、弊社のあるプロダクトをRails4から最新の5.2にアップデートすることがあり、その過程でいろいろと教訓を得ることがあったので、自戒と今後の方向性を明確にすることを含めて、このブログにまとめておきたいと思います（※特に技術的な細かい話はしません）。

その上で現時点での考えを先に言うならば、タイトルにある通り、「メンテナンスをサボっていい理由なんてどこにもない」 です。

なお、この記事でいうメンテナンスとは、フレームワークやライブラリのバージョンアップデート、それに伴う既存のコード修正と定義しておきます。

なぜメンテナンスが後回しになるのか

サービスの運営において、メンテナンスより優先すべきことや既存のコードをそのままにしておいた方が良い場合もいくつかあるはずです。毎日バージョンのアップデートを行うことが必ずしも得策とは言えません。例として3つほど挙げてみます。

プロダクトの施策を優先したいから

そのプロダクトが達成すべき指標・ゴールが目の前にあるとき、それを優先するのは至極正しい考え方です。売上を上げること、KPI・KGIを達成することがプロダクトの存続のためには不可欠です。メンテナンスなんて施策が落ち着いたときにいつでもできる、と考えるのも自然かと思います。

既存のコードを変更することで不具合を起こすかもしれないから

メンテナンスを行うことで、既存のコードもそれに合わせて修正しなくてはならない場合もあります。当然それによって、システムのどこかに不具合が生じてしまうこともあるでしょう。新機能を開発する際に起きるバグなら想定内と言えますが、何も機能を開発しない単なるアップデートでバグを起こすのはマイナスとしか思えないです。

それでもメンテナンスをサボってはいけない

今まで述べたことを考えると、「うーん…うかつにメンテナンスをガシガシやるのも考えものだな…」と思うでしょう。誰だって思います。俺だって思います。

しかしそれでも後回しにしてはいけません。 冒頭で少し触れたRails4からRails5.2へのアップデートを自分がメインで進めたことで実感したことが、そのまま理由になっています。

メンテナンスの全体工数が読めなくなる

後回しにすればするほど、次のメンテナンスが大規模なものになり、どのくらい工数を割けばメンテナンスが完了するのか計算できなくなります。具体的に何が起こるかというと、

使っているフレームワークの仕様が大きく変わる。
古いライブラリがサポートを終了して使えなくなる。
ある機能がライブラリから切り出されて、別のライブラリになる。

こうした影響に対応するために既存のコードをどんどん修正していくわけですが、その際に頼りにするのがテストコードです。が、そのテストコードが軒並み通らなくなります。出てくるエラーを一つ解決し、またテスト。一つ解決しまたテスト。この繰り返しです。これ、なかなか終わりません。

ここで問題なのが、一体どのくらいテストコードにエラーが含まれているのか把握できないということです。そのせいで、タスクを割り振って複数人で分担することもできないという副次的な問題も発生します。

過去の古いコードについて誰に聞けば良いか分からなくなる

サービス開始当初のメンバーがずっといるわけではありません。転職して社内にもういないこともありますし、社内にいるとしても、数年前のコードとなると記憶も曖昧になっているかもしれません。ここで心配なのは、もう使ってなさそうだからといって削除して、あとあとバタフライエフェクト的にバグが発生することです。もちろん通常の開発においても発生しうるものですが、その確率はより高くなるように思えます。

新しい技術を使いたくてもすぐには使えなくなる

Web技術のトレンドは常にとてつもないスピードで変わっていきます。レガシー化したシステムを使っていると、その変化についていけず、古い技術だけで新しい機能を開発するしかなくなることもあります。このあたりはあまり目に見えにくいかもしれませんが、たとえば、選択するかはともかく競合が使っている技術を使えないといった状況は避けたいところではないでしょうか。

1ヶ月に1回を目安にメンテナンスしよう

これについてはまだ検証段階なので、どの程度のスパンが望ましいかは数ヶ月ほど様子を見て判断していきたいと思っています。これを実践していく上で今後気をつけていきたい点として、

忙しくても、メンテナンスの工数を少しずつ確保する
バージョンをアップデートするかの議論を設ける

を挙げたいと思います。メンテナンスも細かくやっていけば、その時々の負担も小さいですし、古いバグ修正より有意義な議論に時間を費やすことができると思います。

エンジニアも夏休みの宿題は早めに終わらせなくてはいけません。