テクノロジーは毎日変わる - あなたのビジネスは追いかけるべきか

本当のところ、追いかけるべきではありません。ビジネス自体がその変化を必要としていない限りは。

これは多くの人 (私自身を含めて) が犯す誤りです。新しい技術が出ると、それを使ってソフトウェアを書き直さなければ、と感じてしまう。しかし、それがビジネスやエンドユーザーにどんな利点をもたらすのでしょうか。多くの場合、何ももたらしません。

新しい技術へ移行したり、依存している 250 個のライブラリのマイナーリリースが出るたびに更新と再テストを繰り返したりするのに時間を使うくらいなら、その時間をエンドユーザーが使う新機能の開発と提供に充てたほうがよい場合がほとんどです。本当のところ、競合にはあるのに自分にはない機能があるなら、最新の Angular を使っているかどうかなんて誰も気にしません。

わかった、と言うかもしれません。でも 3 年後にアップグレードが必要になり、メジャーバージョンが 10 も遅れていて、大量の “レガシー” コードを抱えていたらどうするんだ？

まず、これまで成し遂げたことを誇りに思ってください。リソースを正しく優先付けできていたからこそ、今やビジネス自体が変化を主導し、アップグレードが必要になっているのです。その優先付けがなければ、ビジネスはそもそも立ち上がらず、あなたは誰にも使われていないソフトウェアの Angular のバージョンを上げ続けることに、暗闇の中で時間を費やしていたかもしれません。

次に、すべてのソフトウェアを書き直そうとしないでください。これは特に Web アプリケーションに当てはまります。最初は、アップグレードが必要だったモジュールだけを書き直しましょう。その後に開発する新しいモジュールや機能はそのまま続け、他のモジュールに大きな変更が現れたタイミングで、書き直す価値があるかを判断し、価値があれば書き直してください。

動いているなら触らない

変更には必ずリスクが伴うので、更新のたびにソフトウェアを再テストする必要があります。代わりに、とりあえずリリースして火が出たところで対処する、というやり方もあります。これもある程度は機能しますし、状況によります。自分のプロダクトで、何かが起きてお金を失っても自分の責任、自分のお金、というのなら可能です。しかし、クライアントのためにこの変更を行ったらどうでしょう。良かれと思って行ったが、クライアントは依頼していないし、あなたも知らせなかった。それでバグを混入させ、結果としてクライアントが損失を被ったとしたら？まさにそのとおり。クライアントが評価できないものに対して取ったリスクが、目の前で爆発したのです。

変更を正当化する

変更は正当化できます。ただ、新しいオモチャがほしいだけのために、自分自身 (あるいは、誰かのために働いているならクライアント) に嘘をついていないか確認してください。オモチャは現れては消え、壊れて捨てられ、また新しいオモチャを買う、ということの繰り返しです。ツール、生産性、パフォーマンス、セキュリティの観点で考えてください。「リスクを減らす」では曖昧すぎます。そうした判断を支えるには、現実的な根拠と数字を用意しましょう。