反省文。

tl;dr

・「後から改善すれば良い」のスタンスは、返済コストを甘く見積もっている結果
・負債の返済にはコーディング以外の工数が大きくかかってくる
・技術的負債を"徐々に"返済することは様々な面で良い

出社即リファクタリング

最近出社した直後に、こっそりリファクタリングの時間を一定程度取るようにしている。朝のウォーミングアップがてら改善作業をしていると、瞑想みたいな効果があって大変気分がよくなるし、その後のコーディングも生産性が上がる。大体こういう気分。

具体的な作業は、アーキテクチャの方針が固まってなかった時代のコードの１つのエンドポイントだけ、適切なレイヤ化を施したり、単体テストが可能なメソッドとして切り出しつつ実際にテストを書いたり、テストに必要な共通処理を定義したり、だ。

初期から機能追加を重点的に行ってきたプロダクトでは、スピード優先の名目で多くの負債が生まれる。こうした負債を生んだのが他人なら、改善作業をした後その人のコーヒーに塩を混ぜたりする嫌がらせをできようものなのだが、如何せん手元の負債を生んだのは大体自分なので、自分に腹を殴られ続けている気分。これがブーメランならすでに返ってきて自分に刺さってる。

「後から改善すればいいから今は多少の雑実装で」

負債が積み上がった当初、たとえスピード優先方針について開発当事者の間で合意が取れていても、そうでない部外者からすれば「なんでこんなのができてしまったのか」という考えを抱くほかない。なので、「こっちはお前らよりビジネス志向でやってんだ」という初期フェーズ開発当事者と、「安定した開発力のない奴らめ」という外から見た人たちとの対立構造が生まれたりする。

個人的にも特にコードを書いてない部外者から「なんでこんな負債あるの？」と言われたりすると、「うるせー！」と言いたくなる。実際、開発初期は工数に比して期限が非常に短い。それは、開発中期に入ってきた人ではあまり想像つかないレベルだったりする。

ただ、冷静に考えれば「一流なら質とスピードは両立できるし、まあ自分の実力不足だよな」という考えに落ち着き、もやっとしつつ「うーん、そっすねぇ」と濁すことが多い。

そもそも技術的負債が生まれた（僕が生んだ）要因なんて、

・工数をあまり増減させないままテストや適切なアーキテクチャを適用するだけの知見がなかったこと
・"スピード優先"を盾に、技術的負債を貯めることを良しとしたこと

の２つに尽きる。「後から改善すればいいから今は多少の雑実装で行きましょう」は、"ビジネス上最適な選択"などではない。個人的な経験則や周囲を観測した結果でいうと、"この決断をしたからビジネスがうまくいく"ことはない。技術的に凝りすぎて失敗することはあっても、手薄にしたことで成功することはない。

大体そういう議論をしている人で、負債を作った当初から完済まで開発に関与し続けた人、つまり自分の作った負債によるDXの低下の被害を自分で被った人というのは少ないと思う。両方経験した上でいうと、TDDしろとは全く思わないが、負債は最初から150%くらいの努力で抑制するべき、という結論になった。

返済コストの理想と現実

技術的負債のあるコードを書き続けることは、バランス悪く積まれたジェンガを抜くようなものだし、後からやろうとするとコストが高くなる。初期フェーズならせいぜい加算されても１週間程度の工数だ。後々改善しようとすれば、アーキテクチャの再考を含めると多分１つのエンドポイントを綺麗に修正仕切るまでに３週間くらいかかる。（私見）

そして、こうした議論が繰り返された上で積み重なった負債をいざ返済しようとすると、チーム全体の工数として後々組み込むのは大変難しい。手元のコーディング以外にも、「改善はタイミング / 方針が適切か」「チームの関係者の誰を巻き込んで行うか」というコミュニケーションが発生し、負債集中対策期間を設けて２ヶ月くらい"みんなで"山籠もりする必要がある。

これは大変しんどいし、組織的にもそりゃ予算確保だったり戦略優先度の都合でできない。よくもジェンガを適当に抜いてくれたな俺という感じがする。

0→1を作るエンジニアの役割

0→1を作るエンジニアの役割は、決してスピード感を持って作ることだけではない。むしろこうした甘い見積もりを冷静に見つめ続け、「今現在と同じくらい、将来のDX（Developer Experience）を楽しいものにするにはどういった手堅い環境づくりができるのか」を考えることに力点をおくべきだったなと思う。

また、「自分は0→1を作るエンジニアで、スピード優先で作ります」という発言は、非常に良くない。その人が別のプロダクトに関わるようになったり、もっとマネジメントに時間を使うようになって手を動かせなくなってしまうと、意図していなくても、「自分は負債を作ったけど、返済義務は他人に肩代わりしてもらっている」という結果になってしまう。

これは暴力にも近い無責任だが、プロダクトが継続しているとなぜか正当化されてしまい、当の負債生産者は"スピード優先"を誇りとしてしまう。発言と実行に乖離が生まれないよう自ら改善をするか、そんな主旨の発言をしないのが良い。

継続的リファクタリングの効用

積み上がった負債を一気に山籠りして返済するのはまあ無理なので、徐々に改善していきましょう、となる。ということでこっそりリファクタリングしているが、肌つやがよくなりいい夢を見るようになった。リファクタはまだガンには効かないがそのうち効くようになる、というレベル。

継続的かつ小規模な負債の返済は、

・多くの人が避けることで手に入らない、マイナスがプラスに転ずる際のノウハウを手にできる
・日々善行を積み重ねているという自覚が得られる
・リファクタリングの方針確認を小さいサイクルで回せる

という効用がある。こう書くと精神的な効用が多そうで、宗教染みているが、実益を生む瞑想みたいなものだと思ってやってる。

そして、これを始めて少し悟ったのは、「後から改善すればいいから」の「後から」は、期待してても決して来ないということだった。隙をみて、少しずつにでも"今すぐに"始めるべきだった。

そんなことがあったので、技術的な負債の返済には多少前向きになったのだが、この習慣が付くまで大変DXが悪く、罪悪感に見舞われ続けてたので、できることなら最初の、0→1のフェーズで最良の環境を作っておくべきだったと思う。