■ 内製化とモダナイズに踏み切った理由
ここ数年、私が所属する会社では「外部委託からの脱却」と「老朽化システムからの脱却」が大きなテーマでした。以前のプロジェクトでは開発の大半を外部ベンダーに任せていたのですが、要件調整のたびに時間とコストがかかり、改善サイクルがどうしても遅れてしまう。
さらに、ノウハウが社内に残らないため、毎回同じ説明を繰り返すような状況になっていました。
同時に、10年以上動かしてきたレガシーシステムは古いフレームワークのまま、テストもほとんどなく変更するのが怖い状態。
「このままではいけない」と判断し、内製化とモダナイズを同時に進めるプロジェクトを立ち上げたのがすべての始まりです。
■ 内製化チームの立ち上げと開発体制の整備
内製化で最初の壁になるのが「チーム作り」です。
私はリーダーとして、以下のような役割構成で小さくスタートしました。
・プロダクトオーナー
・開発チーム（フロントエンド／バックエンド／インフラ）
・QA担当
・DevOps担当
初期は外部コンサルタントを1名だけ残し、知見を吸収しながら社内体制を整えていきました。
開発プロセスはアジャイルを採用し、2週間スプリントで回す形に変更。
CI/CDも構築し、レビュー文化やドキュメント整備も制度として定着させました。
最初の3ヶ月は本当に苦労しました。
社内に開発文化がなかったこともあり、レビューが形骸化しそうになったり、資料が全く揃わなかったり。しかし小さな改善を積み重ねた結果、4ヶ月目には安定して機能が届けられるチームに成長しました。
■ レガシー脱却の難しさと、そこで直面した“壁”
モダナイズでは、まず既存コードの解析から始めました。
ただ、想像以上に苦戦しました。
・仕様書が古く、内容が今と違う
・使われていない機能が大量に残っている
・依存関係が複雑で変更するとすぐ壊れる
結局、現場ヒアリングやTDDを取り入れながら、一つひとつ丁寧に理解していくしかありませんでした。
技術刷新では、次のような構成に刷新しました。
・フロント：旧テンプレート → React / Next.js
・バックエンド：レガシーFW → Node.js / Python / Spring Boot
・インフラ：オンプレ → AWS＋IaC
もちろん、移行は簡単ではありません。
・DB構造の違いでマイグレーションが進まない
・既存APIとの互換性問題
・リリース時のサービス停止リスク
最終的には、段階的移行とサンドボックス検証でリスクを最小化し、ようやく安定稼働に漕ぎつけました。
■ 成功体験と、リーダーとして痛感した学び
振り返ると、とても多くの学びがありました。
■ 成功した点
・CI/CD導入でデプロイが半自動化し、品質が大幅に向上
・レビュー文化とTDD導入で、バグ率が激減
・段階的なリプレースでサービス停止を最小化
・チーム文化が醸成され、改善提案が自然と出てくる状態に
「内製化して本当に良かった」と言える成果が出せました。
■ でも、失敗も多かった・・・
・流行りの技術を選びすぎて、チームがキャッチアップできず開発遅延
→ 技術選定は“習熟度”最優先にすべき
・権限管理が甘く、本番データに誤って変更反映
→ 内製でも統制は外注以上に厳しく
・レガシー解析が地味すぎて、メンバーのモチベが低下
→ 小さな成功体験を共有し、心理的な報酬を意識する
プロジェクトは技術だけでなく 人と文化がすべて ということを、リーダーとして改めて痛感しました。
■ 最後に：内製化とモダナイズは「技術刷新」ではなく「組織改革」
内製化・モダナイズは単なる技術改革ではなく、
チーム体制・文化・運用フローを根本から見直す“組織の変革” でした。
私が強く意識してきたポイントは以下の4つです。
・小さく始め、段階的に内製化・モダナイズを進める
・技術選定は「チーム習熟度」と「運用しやすさ」を最優先
・CI/CDとテストで品質と再現性を担保
・成功体験を共有し、チーム文化を育てる
苦労は多かったですが、得られた知見とチームの成長は大きな財産です。
リーダーとして、この経験は今後のプロダクト運営でも間違いなく活きていくと感じています。