🌮

レガシーコードとどう付き合うかの備忘録

2023/07/01に公開

はじめに

スタートアップにおける例として

そもそもエンジニアを確保できる資金力がないため、組織上レガシーコードを生みやすい構造になっている
- エンジェル・シードやアーリーステージ(数百万〜数千万)は資金が潤沢ではない
  - 1人600万だとしても3人雇用しただけで1800万/年になる
  - 低賃金で働いてくれて、コミュニケーション力が高く、開発速度は速く、設計力も優れているというエンジニアを雇用できるのは至難の業
レガシーコードをリファクタリングするモチベーションが湧かない
- 新しい技術や知見を学習してエンジニアとしての価値を高めたい
- レガシーコードの改善が顧客価値から遠くやる気が続かない
組織がサイロ化してシステム全体を把握できるエンジニアがいない
時間と共に仕様把握は断片化していくのは避けられない(人の異動や退職は避けられない)
レガシーコードを嫌う人でもシード期の会社に参画したら、技術的負債を生んでしまう張本人になりうる可能性は高い
- フルスクラッチで裁量が高く、キャッシュの心配がなくアプリケーション開発できる職場はあるのだろうか？

ラウンド	概要	例
シリーズA〜B	ビジネスを維持するための重要な実装部分	課金周りの実装
シリーズB〜C	サービス全体	アクティブユーザー数やLTV、ARPUなど事業の重要なKPIに依存する部分の実装
シリーズD以降	次のサービス実装が容易に行えるような実装やコード分割	IPOを見据えてITガバナンス強化せざるを得ない。セキュリティパッチや証明書の組み込みなど

これらの記載からもレイターステージになるに連れて、開発のアジリティは下がり、負債返済に対する人的コストが増えていくことが予見される

技術的負債は人件費が嵩むという基本認識を経営層側と共有した上で、CTOとテックリードの責任範囲を明確化して強く実行していく

Four Keysを使ってアプリケーションの品質を定量化し、ビジネス上のKPIと組み合わせて顧客への価値提供を測定する

理想は、部分的な改修を重ねながらドメイン知識を吸収し、フルリプレース計画を立てるのがリスクが低い
また、メリット・デメリットを比較し、今本当に取るべき選択肢を経営層に説明できる必要がある
考慮すべき要素としては

現在の事業戦略や引いてはエクイティストーリーなどを加味する
フルリプレイス後にはいつか陳腐化するので賞味期限の確認
業務ドメインへの理解度の高さ
- コードを見てリプレイスしていくだけの単純な作業ではない。業務ドメインへの理解度も必要
- 場合によっては業務ドメインのヒアリングやコミュニケーションも多岐に渡るためそこが担保できるか

古参エンジニアが経営層に優遇されやすいのは心理的バイアスによるもの
- エンジェル・シード期の辛い経験を共に乗り越えてきた
  - レイターステージに近づくに連れ、経営層は現場の細かい業務を把握できない
- 古参エンジニアが書いたレガシーコードよりも良いコードを書く新規参入エンジニアは何で古参が評価されているんだ？と軋轢を生む
ボーイスカウトルール
- 来たときよりも美しくするというルール
- 現状の動作は同じだが、コーディングルールを守るように改善したり、コードを分割して可読性を良くしたりすること
自己破産
- 技術的負債が解消不能になった時に使われる言葉
優秀なエンジニアとは何か？は状況により変わる
- 0→1、1→10、10→100など事業フェーズによって発揮できるパフォーマンスにそもそも差がある
- バックエンド、フロントエンド、DevOps、QAなど強みが異なる
- 会社にとって最適化された人なのか、ポータブルなハードスキルを持っている人なのか