理想のシステム刷新を「諦める」勇気：EM、シニアエンジニアのためのレガシー刷新判断チェックシート
はじめに
エンジニアリングマネージャー（EM）やシニアエンジニアとして現場に立つと、常に理想と現実のギャップに直面します。
技術チームが提案する「モダンな技術スタックへの全面移行」は、技術的には100%正しい選択かもしれません。しかし、現実は非情です。ビジネスの状況、限られた予算、リソースの不足、そして移行そのものの難易度。
これらの制約を無視して理想を強行した結果、プロジェクトが頓挫し、かえって巨大な技術的負債を生んでしまう。そんな光景を、私はいくつもの会社で見聞きしてきました。
理想の移行案はなぜ失敗するのか
全面刷新が失敗する最大の理由は楽観的な見通しにあります。
「最初は簡単な部分から始めて、最終的に全部終わる」という右肩上がりの計画は、レガシーシステムというドロドロの現場では通用しません。途中で必ず想定外の依存関係が見つかり、ビジネスサイドからは優先度の高い機能追加が割り込みます。
EMやシニアエンジニアの本質的な役割は、理想を語ることではありません。制約を冷徹に理解し、組織の状況に応じた「現実的な最適解」を見出すことです。
段階的な「諦め」という戦略
私が著書『Tech Team Management: 不確実な開発現場で成果を出し続けるための原則と技術』の中でも強調しているのは、「戦略的な現状維持」や「部分的な改善」もまた、立派なエンジニアリングの正解であるということです。
完璧なマイクロサービス化を目指すより、モジュラーモノリスにする程度の改修をし、DBをできるだけ改修の手間を抑えたスケーラブルなものに入れ替え、ガードレールとしてのリリースプロセスを徹底的に仕組み化する。これだけで救われるビジネスが山ほどあるのではないでしょうか。
【無料公開】 レガシー刷新・継続のチェックシート
私自身、失敗した苦い経験があります。同じ轍を踏んで欲しくないという想いで、私が実際に使っている体系化した意思決定用のチェックシートを公開します。
このシートでは、以下の3ステップで意思決定をガイドします。
- Reality Check: 現状の負債を「ブラックボックス化」「ドキュメントの化石化」などの観点で直視する。
- ICEスコアリング: 影響度（Impact）、確信度（Confidence）、容易性（Ease）で客観的に他案件との優先順位をつける。
- 3つの問い: 「ボトルネックが想定の2倍だったら？」「割り込みを何割許容しているか？」といった、楽観的バイアスを排除するための自問自答。
完璧でなくても大丈夫
システムが理想の形にたどり着けなかったとしても、それでビジネスが安定し、チームが成果を出せる状況を作れたのであれば、それはEM、シニアエンジニアとしての成功だと思います。
失敗から学び、制約を理解し、その時の最善を選ぶ。このシートが、皆さんの孤独な意思決定を支える一助になれば幸いです。
Discussion