ITエンジニアと意思疎通できない経営感覚のズレ

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

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

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

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

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

反対にリリース前フェーズにITエンジニアがリファクタリングに夢中になるケースがあります。その結果、リリース前に時間切れとなって資金ショートしたサービスを見たことがあります。開発費用だけが消えていきました。

開発の話になってしまいますが、「0-1」フェーズを作り込んでいったら途中で「ここはああすべきだった」「ここはもっとよくできそうだ」というのはいったんメモをしておき、重大なセキュリティリスク以外はリリースして落ち着いてから別途対応すべきです。自分自身のソースコードもインフラも、よかれと思った技術選定も、多くの場合は半年もすれば誰かの技術的負債になるのです。

経営層としては、技術的負債があることを認識したうえで、技術的負債の解消をITエンジニアに意味付けし、建設的な解消を求める姿勢が重要です。

売り上げを上げることを最優先した結果、技術的負債の解消が後回しになり、セキュリティインシデントに繫がったり、実装に時間がかかり続けたりすることは多くあります。技術的負債の解消を、新規施策と同様に「投資」と位置付ける意思決定もまた必要です。

『ITエンジニア採用とマネジメントのすべて 「採用・定着・活躍」のポイントと内製化への道筋が1冊でわかる』（かんき出版）。書影をクリックするとAmazonのサイトにジャンプします

往年の個人業務委託は自社の評価制度・給与制度に見合わないほどの高度人材を対象として契約されていました。しかしフリーランスという働き方が一般化するとともに、2012年のソーシャルバブル以降、メンバークラスの個人業務委託がフリーランスとして増えています。

現在の都内フリーランス市場では、80万円／月くらいで実装が任せられる人材、100万円／月で設計もできる人、リーダー・マネージャークラスで120万円／月くらいが相場観です。

ITエンジニアは採用コストや年収レンジが上がっているだけでなく、未経験などであれば一人前の戦力にするために教育コストを支払わなければなりません。採用しても、すぐに辞めてしまいフリーランスになってしまう人が増えているため、コスト回収ができない企業が出てきています。

経営層としてはこうした状況を踏まえ、ITエンジニアを雇用することに対する意味付けや、正社員と業務委託を適切に配置した開発組織設計をしなければなりません。