敢えて技術的負債を残すこともある。EmmaTools™開発責任者が考える技術的負債との向き合い方。

こんにちは、私はエンジニア歴13年、40歳のおっさんエンジニアこと西川です。

30歳のキレキレな CTO と二人三脚で、EXIDEA のエンジニア組織を運営しています。

弊社には新規事業を含め複数のプロダクトがあり、国内メンバーで開発しているものと、オフショアの拠点で開発しているものがありますが、現在は国内メンバーで EmmaTools™ の開発・運用を行なっています。

チームは20代前半の若手正社員と30-50代の業務委託エンジニアで構成されていますが、小さな組織のため、マネジメントだけでなくプログラミングも現役です。

EmmaTools™ は PHP, Node.js（TypeScript）, Python, Java の4つの言語が使われているため、必要に応じて全部書きます！

ちなみに2021年9月現在、UI のリニューアルに取り組んでおり、フロントエンドが得意な方を募集中です。

さて、本題のEmmaTools™ が取り組んでいる技術的な課題というと、昨年に発売された以下の書籍で言及されている内容とかなり類似しています。

Engineers in VOYAGE ― 事業をエンジニアリングする技術者たち

というのも、私が EXIDEA にジョインした 2019年3月の時点で first commit から約4年が経過しており、インフラもアプリケーションもレガシーな状態のまま運用を続けている、という状態でした。

現在も技術的負債と正面から向き合っています。

技術的負債と言うと敬遠したくなる方が多いかもしれませんが、前職を含め、これまでに出会ってきた様々なシステムの中で、技術的負債のないシステムというのは見たことがありません。

以下の内容はまさにそうだと思います。

Seed期スタートアップがITエンジニア採用で強い理由と、新卒採用戦略の反省

開発時点では負債ゼロのつもりで作ったとしても、ビジネスを取り巻く環境が日々変わる以上、いつ技術的負債になってもおかしくないですし、技術的な観点でベストではなかったとしても、当時のビジネス要件と開発組織、システムの現状を踏まえた最適解がそれだった、というケースも多いと思います。

例えば最近だと、EmmaTools™ の前身にあたる旧システムが社内で稼働しており、その中の一部機能を本番の EmmaTools™ に移行する対応を実施しました。

これについては移行後も一部の関係者のみ利用することが分かっていたため、プライベートネットワーク内に Web API を追加した上で、旧システムのコードは API 接続部分のみ改修し、それ以外の部分は触らずに最小工数で移行しました。

技術的には全くイケてない方法ですが、ビジネス要件を踏まえて、敢えて技術的負債を残した例になるかと思います。

ここで大切なのは、返済可能にすること。

そのためには、なぜそのような意思決定をしたのか、という経緯をきちんと残しておくこと。

アーキテクチャ設計を工夫して依存関係を弱める等のテクニックもありますが、最終的な意思決定の拠り所になるのは過去の検討経緯であることが多いです。

議事メモから Issue, Pull Request, 最終的に commit comment まで繋がっていること。

地味かもしれませんが、事業、技術の両側面から意思決定していくためには、これが最も大切と考えています。

教科書通りにはいかない技術課題と向き合いながら、プロダクトのビジネス価値を最大化するための最適解を考え続ける。

技術力と経験が問われる総合格闘技のような、やりがいのある仕事だと思います。

私たちと一緒に課題解決に取り組みたい方のご応募をお待ちしています。

▼弊社では下記ポジションの募集を行っています、まずはカジュアル面談からお話できることを楽しみにしています。