「なんで、エンジニアってそんなにリプレイスやリファクタやりたがるの？」
言われた経験がある人は結構いるはずです。コスト管理してる立場から、一見無意味なリプレイスやリファクタに見えがちなんですよねー。
仕事やりたくない時とか、無理やりリファクタタスク詰んでる人がいるのも問題点の一つですが……
「っち、うるせーな反省してまーす」
リプレイスやリファクタをコストをかけてもやったほうがいいもの等をポエムっていきたいと思います。
毒の溜まるシステム
初期の開発はたいてい、事業という生態系の気まぐれによってぐちゃぐちゃになりがちです。
あれもしたい、これもしたい、やっぱあれがいいよね？などの要望という名の餌をくらいつづけ成長はするけど、それと同時に生体濃縮で毒が溜まっていくように不具合や負債が蓄積していきます。
適切にプロジェクトの運用できてればそうでもないけど……実際に世の中のシステム開発のうち、4分の3は失敗しているという状況なのでそんな状態で自分の会社はまともだ！！と言える企業ってよっぽどキラキラ系で酔っているか、リファクタ等を業務としてしっかり組み込めているかなはずです。
現実は下のような地獄が繰り広げられると信じてます（願望）
アジャイルっぽいけど、失敗してるアジャイルもこの感じで進みますよね（※私の肌感です）
永遠と要望Bが生まれ続けて、その度に実装を緊急で手入れ入るのでぐっちゃぐちゃになっていくという。
こう言う仕事の仕方だと、秘伝のタレや……
// TODO TypeORMのバグのため一時的に要調査
// TODO DRYに即していないが緊急で挿入
// TODO SOLIDに即していないため後で直す
こんな酷いTODOが2年間放置されると言う状況が起きるんですよね。
しかもコード自体も汚く読みにくいため。Aと似た仕様のBを入れたいんだけどと言われた時に、追加の容易性がないため時間がかかるといった状態になります。
イメージとしては、共通フレームワーク使っている会社のシステムで、そのフレームワークが機能不足のためフレームワーク改修をぶっとばしてオリジナルの機能をベタ書きでかいているとかですね？
もちろんマネージャーとかも把握できていないため、見積理由説明しても共通フレームワーク使っているんだからそんなことはないだろと言われ、なぜか先人の書いたコードで怒られると言う理不尽が……やるせないですね。
入れ替わりが激しいチーム
これは内製企業と運用や追加開発などの請負をしているところ限定ですが、エンジニアの入れ替わりが激しい企業なども同様にしたほうがいいです。
秘伝のタレの遺失や仕様自体が共有されておらず、なんでこうなっているかわからないものが多発します。
そのシステムのコアになっている部分で起きると、その時点で整理として冗長的なものを除く目的で行うと良いでしょう。
そもそも、そのエンジニアがいなくて困るなら手放すなよと言いたい気はしますが……職業選択の自由がありますしねー。
個人に依存する会社も悪いんですが、ものを作る仕事ってそれ自体が依存するものというのがついて回ります。
それをリファクタやリプレイスなどを経て、自分がいなくても読めるコードに置き換えることがある種のエンジニアリングなのかなと最近思い始めています。
最初からそれができたらいいんですけどね。出来る開発体制を整えるには、納期や神の気まぐれというエンジニアだけじゃできない部分もあるから難しいところではあります。
経営統合
経営統合は企業のビジョンに向かうために、システムのリプレイスが必要な場面がいくつかあります。
結局のところ、ここに関しては何を捨てて代わりに何を新しくすべきかをしっかり見据えていくべきが現場としてはベストなんだけれども、経営統合した時点でコストがかかり過ぎている可能性もありリプレイスコストなどを捻出できない上、派閥争いや神の力が働くことも稀によくあります。
私はした方がいいとは言いました。するかどうかは💰次第でしょう。
動いているからいいじゃんで突き進む
たまにエンジニアでも行っている人がいますが、その人は前提が自分がスパゲッティを作らない前提なんだと思います。
ただ、動いているからこれもできるよね？あれもできるよねで作られたコードっていつか破綻します。
というのも、エンジニアが入れ替わった時そんなこと知ったことないのです。
Aという機能のコードとそれに似たBという機能のコードに要望を追加しようとします。
コアな記述は一緒なので、新規で入ってきたエンジニアが例えばAのコードを見つけて直したとしてBのコードが直っていないことに気づくでしょうか？
テストコード書かれてたらまじ気づかない……手癖で実際に動かすので最終的に気づきますが割と傲慢で面倒くさがりが多い業界ですやらかす人はやらかします。
やらかさなくても大抵は一発で気づかない上、見積もり範囲から外れるため工数跳ねて誰も幸せにならないですよね。
健全な提案をするためには
そもそも、コストだよね？を理解する
考える前にリファクタ、リプレイスが非エンジニア的に一般的にはどう見えるのかですよね。
言葉を濁さず言ってしまうと、経営者から見ると今動いているシステムのリファクタやリプレイスなぞ、金を生み出さない穀潰しの仕事ということですね。
それにより利益がどれだけ出るか？の見積もりは基本でません、作りやすくなったら開発速度が20％上がってそれだけ利益が出るとしましょう、少し弁のたつ専門外の人間から見ればその20％の速度分の利益はコストがかかっている以上出ても出なくても同じで、コスト分をすぐペイできなきゃ評価されないのでやらないという選択をします。
遅延を許容すれば確実な売り上げがあるかもしれないんですから、そりゃやらんよね。
エンジニアが経営者になったりしたら、ちょっと感覚変わるんですがネット記事だけでテストコードはいらないと断言してしまう経営者や責任者もいるので……難しい。
デメリットを打ち消すほどのデメリットの提示
- バグの発生率
- 追加要件の遅延
- データメンテナンス工数
これらがどれだけ時間的な損害を出しているのか、計測してみましょう。
その上で何が課題になっているのか？課題を解決するためにどうすればいいのか？をまとめてぶつけましょう。
一個一個だと頭の回転だけいい人が、重箱の隅を突き始める可能性があります。
え？一個一個小さいから、小手先の技でなんとかしろというステークホルダーがいる？
適応障害になる前に離れましょう……それで心を壊したエンジニア10人ほどみてきました。
ゴールの設定
とはいえ、リプレイスもリファクタも時間がかかります。
その期間、事業としてその部分に関しては何も進まないため段階的なゴールポストの設定をしないといけません。
要望を出すステークホルダーとしては、自分の評価される項目がまるっと減るため嫌がられ邪魔してくることがありますが……それを極力避けるためには
ステークホルダーを抱き込む
複数人のステークホルダーと口裏を合わせといてください、一人のステークホルダーがたとえ反対しても多数決で乗り切れます。
それで社内政治合戦になるのであれば、普通に会社が悪いから辞めたほうがいいよ。
まともなステークホルダーなら、バグの詳細わからなくてもデメリットの提示とゴールポストの設定さえすれば話は理解してもらえると私個人は信じています。
ステイするっていうのも業務貢献になるはずなんですが……売り上げのみを業務貢献の指標としている企業の場合は無理ですねあきらめましょう。
リファクタやリプレイスの開発時注意したいこと
アーキテクチャ特性を意識する
現状のシステムが提供する範囲を見て、アーキテクチャ特性を整理することが必要だと思います。リアーキテクトまで行かないまでも、選択しているアーキテクチャ特性と一致しているか？を見るだけでいいのかなと。
あと選択したアーキテクチャ特性を否定する時は、時間がかかるからは個人的にはNGですね。
よく言われるのは、アンチDDDのエンジニアがリファクタリングを始めたときに、ドメイン駆動はファイル数が多く可読性が悪いからやめようとかとか
確かにステップ数ファイル数ともに増加する傾向にありますが、凝集度が上がりテストが書きやすい嬉しい特典ていうのもあります。
アーキテクチャじゃなくてアーキテクチャ特性といったのはここが理由ですね？
そのシステムになにがもとめられているのか?を理解してないとリファクタリングしても、きちゃないからぺっしなさいみたいなコードにしかなりません。
んじゃDDDだといってもそんな甘いことはありません、DDDが担保すんのはそのドメインの合目的性と変更性だけなんですよね。
例えばUSERだと何が必要か？
セキュリティ？認証？認可？hogehoge？結局、これらを考えずにコードも書けないしそれを理解しないことには、結局汚いコードになるんですよね。
テストコードを書こう
月並みですね。私はテストコードを書かなくてもいい派ではあるんですが……
たいていリファクタやリプレイス等を急いで進めないといけないコードってテストコードを書かないではなく、書けないんです。
変更容易性がない上、あっちこっちに継承やら呼び出しやらされまくっていて誰も全貌を把握していない一昔前ではスパゲッティ・プログラムとか呼ばれていたものですね。
どっかの記事で見たか知らんが、非エンジニアのステークホルダーが別にテストコードいらないんじゃない？とか、まともなもの作れてないの把握していないリーダーやマネージャーがテストコードいらないんじゃない？とか発言しないようにしましょうね。
「できてないから、リファクタとかリプレイスが必要なんです。できてたら、んなもんはなからいらん」
はい、復唱！！
モチベ管理
でかいコードを分解すればするほど、マンネリ化したりよくわからん呼び出しの分解を長期間続けているといやになってくることがあります。
自分だけではなく、他のメンバーなどのガス抜きの場を展開していくことが重要ですね。
個人に押し付けた仕事を否定するだけではなく、肯定したうえで方針を決めましょう。
また、定期的などなんしたん？話きこか？などの会などを設定してもいいかもしれません。
終わりに
まぁいろいろポエムったけど、実際には毒がたまったシステムの解毒に関して、経営者層や事業管理者層が理解を示さなければ遅かれ早かれ事業自体のストップの未来が来ますね。
だってその事業はシステムありきなんですから、例えば電話とメモ帳で済む仕事であれば問題ないんですが……システムがある以上メインフロントとなるのは、営業や経営者ではなくシステムなんですよね？
そのシステムの成長が止まると、新しいやり方を試そうとしても試せないという結論が見えてきます。それを避けるために、エンジニアはリプレイスやリファクタやりたいというわけなんですよねー
それがわからない企業なほど、そういう層を切り捨ててしまっており気づかず自浄作用が働きませんよねぇ。