ITエンジニアと意思疎通できない経営感覚のズレ 貴重な戦力の離職を招く間違いのポイント

スタートアップ企業界隈ではITエンジニアが技術選定を自身でできる、0から設計から始められるということで、「前任者のソースコードや設計を引き継がなくていい」というメリットを挙げて転職の意思決定をするケースが多く見られます。言い換えると「技術的負債」がないことが魅力だそうです。

ITエンジニアは技術的負債という言葉をよく使います。非効率な処理や読みにくいソースコードを指しているケースもあれば、非効率なデータベース構造を指す場合、メンテナンスがしにくいインフラの場合もあります。

原因としては、前任者の設計や実装の習熟度が低いケースもありますが、度重なる仕様変更に追従できなかった結果、複雑怪奇なシステムになったケースもあります。

あるゲーム会社では「車輪の再開発は絶対に許さない」という方針を貫いた結果、毎年リリースされるゲームタイトルで必ず利用される共通APIを10年近く使い続けていると聞きます。ここまで来るとソースコード変更に伴う影響範囲の把握などは難解です。

しかし見方を変えると、それだけ施策やタイトルを打ち続けるほどユーザーがついたことの裏返しであり、技術的負債は「名誉の負傷」であるとも言えます。

当該サービスがマネタイズできるようになったのは、紛れもなく過去のITエンジニアによる試行錯誤のおかげであり、「技術的負債」はその試行錯誤に伴って出てきたものです。

この試行錯誤のフェーズがないと当該求人票ポジションもなかったわけです。私の見解としては、技術的負債に感謝しながらリファクタリング（メンテナンス性や処理効率の向上を目的としたソースコードの書き直し）のプロジェクトを計画し、弔うべきだと考えています。