「簡単な変更のはずなのに数週間かかる」の正体を、資産形成で説明してみる

筆者はエンジニアとして、表示条件を1つ変えるだけの小さな変更に数週間かかる現場を経験してきた。問題は変更の大きさではなく、差分に関係なく毎回発生する待ち時間にあると整理する。手動の回帰テストを頭から消化する作業、検証環境が足りず順番を待つ時間、リリース列車の出発を待つ時間。どれも変更が数十行でも数百行でも同じだけかかる。筆者はこれを家計の固定費にたとえる。家賃や通信費が収入の増減と無関係に引き落とされるように、プロダクトの固定費も実装の速さとは関係なく毎回かかる。さらに機能が増えれば確認項目も増え、利息だけを払い続ける状態に近づいていく。 AIの鬼が面白いと思うのは、この比喩が「もっと速くコードを書けば解決する」という思い込みを静かに崩している点だ。実装が速くなっても、世に出るまでの時間が変わらなければ手元に残るものはない。そして筆者が正直に書いているのは、テストを増やした効果を数字で測ったわけではないということだ。同じ時期にブランチ戦略もCIもレビュー体制も見直しているので、効いたのが何だったのかは断定できない。それでも、単体テストという先行投資が未完成コードのmain投入とFeature Flagを可能にし、検証環境の順番待ちを消したという構図は読み応えがある。投資が安全網になり、3つの固定費が連動して下がったのである。一方で、テストは捨てれば書く前の状態に戻れる点が投資信託と違う。ただし中身に密着したテストは、リファクタのたびに直す新たな固定費になる。書くなら振る舞いに対して書く、という筆者の結論は、業務で使うどんなルールにも当てはまる。 中小企業の実務に置き換えると、業務システムや社内ツールの改修が遅いなら、まず毎回発生している固定費を洗い出すことだ。確認手順、承認待ち、リリース時期のどれが一番重いのかを見る。外注先に見積もりを頼むときも、「この変更で一番時間がかかっているのはどの確認か」と聞けば、見積もりの中身が見えてくる。全部を自動化する必要はない。毎回必ず払っている部分から一つ手を入れる。家計簿で一番効く支出から削るのと同じ順番である。