プロダクトをリニューアルするのか現状維持かの判断

こんばんは、某製品のリニューアルを担当しているIwaoです。

今回は（今回も）持論を残そうかなと思っていますが、たまにはテック寄りの話をします。もし自分たちの製品があって、リニューアルするか現状維持で突き進むのか、迷った時の判断軸を書こうと思います。

現状維持のリスク

ご存知の通りトレンドの変化は激しく、ウェブにしろアプリにしろこのまま放置していいのか悩んだ経験は一度はあるかと思います。

そんなときもまずは何事も現状の理解が必要ですね。まずは現状維持していく場合のリスクを理解していきます。

1. 古い言語・環境での若手の採用リスク
2. フレームワークやライブラリの老朽化によるセキュリティリスク
3. 改善や機能追加したときのデグレードによる障害リスク

大きくこんな感じかと思います。会社に若い血を入れて組織を活性化したいとか、セキュリティを担保することが重視されるサービスだったり、まだまだ機能追加していくロードマップを描いているなら、これらのリスクヘッジをしたほうがいいんじゃないかと思えてきます。

また、大抵このようなリスクがある製品の場合、ドキュメントがなかったり、メンテナンスされていなかったり、当時の担当者が辞めてしまい放置プレイを強いられるなど属人化が排除できていないことが多いので、古いソースコードを見ながら正解を定義しつつ進めることになります。

つまり現状維持をするにしても忍耐が必要であり、これらのリスクを許容する覚悟は必要ですね。

家に例える

僕はいつもこの手の話は家に例えるんですが、お金がないとか離婚しそうで家族構成が変わりそうとかであれば新築なんてやりませんよね？

老朽化による強度への不安、泥棒から身を守る安全性、家族構成の変化に対応するリフォームなど、もし家の価値が長く安心して住みたいのであれば、新築したいなと思うのではないでしょうか。

そしてその決断のトリガーとなる事象が起きたら、それがスイッチだと思っています。手遅れになる前に先回りして価値を出すことが昨今のマネージメントには求められているためです。

リニューアルのリスク

次はリニューアルをする場合のリスクを理解していきます。

1. リニューアル期間に機能追加やバグフィックスをした場合は古いバージョンと新しいバージョン両方を更新する工数が必要
2. リニューアル前と後でメジャーバージョンが変わるので互換性を意識する必要がある
3. お金（工数）がかかる

ざっくりこの辺りかなと。2ライン走らせる体力があって、互換性を担保できることを最初にリサーチする必要があります。

もしあなたがマネージャーならリニューアルを検討することは当然ながら、PLを引いてみてこれらのリスクヘッジできるのかを判断してみることになります。

他社事例

他社事例というのはあくまでも参考でしかなりませんが、不安であれば調べてみると良いかと思います。

僕の知っている範囲だと、5年以上続いていてメジャーなサービスというのは概ねリニューアルしていると思ってて、テック寄り（技術的負債を理解している事業）であればなおさらです。

決断

スマホが世に出て10年、AndroidもiOSも開発言語が変わって64ビッド化もされて、当初からサービスを提供しているパブリッシャーであれば10年も運営しているわけです。であればそれなりの収益を上げているので、一度は製品をリニューアルしているのではないでしょうか？

旧INSPIREDを読むとリニューアルについて明記されています。

（リニューアルは）あらゆる手を尽くしてでも絶対にそうするべきだ。たとえ、コードの書き直しが完全に終わるまでに、 9ヶ月ではなく 2年かかることになったとしても、である。

実際には前後の文脈があってステップワークで評価しているんですが、許可が降りてリスクヘッジができるのであればリニューアルはすべきだということです。

ただここで重要なのは大規模なリニューアルをしなくてもいいように、日頃から工数の20％程度をメンテナンスコストとしてかけて、リファクタリングしていく体制を作ることが熱く語られていましたw

eBayも何度かリニューアルにチャレンジして苦労したうえで、成功を得られているわけですね。

雑感

見て見ぬふりをするのも必要な時もあるかもしれないですが、自分の家だと思ってプロダクトと向き合いながら判断することが必要だな、と改めて思った次第でした。