コンテンツにスキップ

blog リプレイスの誘惑に負けるな#

created: 2023-08-24
updated: 2023-08-24

担当プロダクトの技術的負債が大きく、いくらリファクタリングをしてもキリがないと感じるとリプレイスしたほうが早い！という気持ちになってくる。だがこれは悪魔の誘惑だ。プロダクトの規模がよほど小さくない限り、リプレイスは考えているよりとても大変で、リファクタリングをするよりも多大な苦労が発生する。自分もリプレイスの悪魔が囁いてくることが多いので、自戒のためにリプレイスの注意点をまとめておく。
（この文章の中で言及する「リプレイス」とは、ユーザから見える動作は変えずに内部品質を高めた全く別のソースコードに移行することを指す。ユーザから見える動作が変わってもいい場合は事情は異なってくる。）

追加の開発メンバーを確保できるか#

現行プロダクトの開発メンバーがリプレイス開発にジョインする場合、当然現行プロダクトの開発が止まる、もしくは現行プロダクトの開発ができる人数が少なくなる。
リプレイスを実施するということは当然現行プロダクトもユーザに利用されて価値を生み出し続けているはずだ。（使われてないプロダクトならばリプレイスの必要はない。）利用されているということは現行プロダクトに対しても絶えずユーザの要望がやってくる。
「フルリプレイス開発をしている間は現行プロダクトの開発は全くできません」がOKされることは殆ど無いだろう。なので現行プロダクトの開発とフルリプレイス開発を両立するためにはメンバーを確保することが前提だ。（まちがっても今のメンバーで二倍頑張るから大丈夫です！と言ってはいけないし、言われた方も鵜呑みにしてはいけない）

適切な技術選定と設計ができるスキルを持っているか#

リプレイスするということは、現行プロダクトの利用技術や設計になんらかの問題点があるはずだ。ではそれらの適切な技術選定、適切な設計はどのようなものかを自信を持って答えられるだろうか。
現行プロダクトを開発していく中で部分部分で設計に不満を感じることは多いだろう。だがソースコード全体を俯瞰してこうすべきだというのを考えるのは高度な設計スキルが必要とされる。個人的には似たような技術構成で新規プロダクトを開発した経験が無いと難しいと思う。具体的な理想像を描かないままリプレイスを実施すると完成できたプロダクトも現行プロダクトと同じような物になってしまう。そしてあとからチームに入ってきた人に「こんなわかりにくいコードはフルリプレイスしたほうがいい」と言われてしまう。

チームメンバーに覚悟はあるか#

ほとんどの場合、フルリプレイスの道のりは長く険しい。設計スキルがあるメンバーを運良く確保しリプレイスが始まったとしても、最初に考えてたとおりうまくいくことは殆ど無い。
現行プロダクトには絶えず新たな要望が来て、当然リプレイス版にも機能追加が必要になる。裏仕様が判明し開発機能が増える。思っていた設計では実現できない部分が見つかり当初考えていたよりきれいに書けなくなる。いざリリースしたら以前と動作が違うというユーザの声の嵐にあい、長い修正の旅が始まる。しかもリプレイスである以上、ユーザから見た動作は変わらず世の中には新しい価値を提供できておらず評価もされにくい。
これらに耐えるという「覚悟」がチームメンバーに無いと（また、当初はあったとしても）、壁にぶつかるたびに疲弊していく。その結果、あるものはモチベーション低下により開発効率が下がり、あるものは異動願を出し、あるものは転職していく。そうすると当然リリーススケジュールも遅れていき、最悪の場合はリプレイス計画は頓挫する

かなりネガティブな書き方になってしまったが、これらは実際に考慮すべきことだ。個人的には上層部の意向でリプレイスチームが別に作られたり、現行プロダクトの開発を止めても良いと言われない限りは、こつこつリファクタリングをしていくのが結局は開発者の精神的負担も工数も少なくやっていけると考える。

参考#