Mixed In

リードエンジニアが執行役員にNode.jsのEOL対応を力説していた。

サポートが切れる。セキュリティパッチが止まる。脆弱性が放置される。技術的には正論だ。だが執行役員の反応は薄かった。「で、それやってユーザーに何のメリットがあるの？」。リードは言葉に詰まっていた。

横で聞いていて、その言い方じゃダメだよな、と思った。

受託開発にいた頃、Railsのバージョンアップで何度も痛い目に遭った。メジャーバージョンが上がるたびに互換性が崩れ、EOLの号令のもとに追い立てられるように修正した。顧客にとって、この手のマイグレーションはビジネス的な価値を生まない。画面は変わらない。機能は増えない。レスポンスが速くなるわけでもない。なのに工数はかかる。見積もりを出すたびに渋い顔をされた。

一方で、同じ会社にPerlで書かれたシステムがあった。ほとんど改修が入らない。枯れきったコードが静かに動いている。ステークホルダーの目には、こちらが正常に映る。触らなければ壊れない。なぜRailsだけ金がかかるのか。その疑問に技術者が答えるのは思ったより難しい。

Kubernetesも同じ構図だ。サポートウィンドウに追われて走り続けるチームをいくつも見てきた。

ただ、どのプロジェクトでも変わらない現実がひとつある。ビジネス価値を生まない修正に、ステークホルダーは金を出したがらない。

正解はわからない。だがわたしなら、EOL対応を単体で提案しない。リスクは素直に伝える。その上で、新しい機能の追加や既存の課題を解決する提案を一緒に持っていく。基盤を更新するついでに、こういう価値も出せますと。

技術的な正しさだけでは組織は動かない。正しさに、相手が欲しいものを添える必要がある。

あのリードエンジニアにそう伝えたかったが、黙って見ていた。勝てない戦いはしない。一度「価値がない」と思わせたら、その場で何を言っても同じ色に染まる。仕切り直さないと無理だ。