TL;DR（この記事の要約）
- 現状： バージョン管理なし、バニラPHPの「レガシー環境」でチーム開発が限界を迎えていた。
- 戦略： 技術的負債の解消を「エンジニアの都合」ではなく、「若手の市場価値向上（採用・育成）」という経営課題に変換して提案した。
- 転換： あえてPHPを捨て、会社の事業戦略に合わせて「.NET」へ移行することで経営層の合意を得た。
- 結果： 外部の声を活用して危機感を煽り、モダナイゼーションに関する「全権委任」を勝ち取った。
はじめに
この記事は、特定のツールの技術的なHow-to記事ではありません。
（具体的なツールの利用方法等はいつか別記事にしたいと思います。）
10年近く稼働し、つぎはぎで運用されてきた「レガシーなシステム・開発環境」を、いかにしてモダンと呼べる状態まで生まれ変わらせたか。その経緯をまとめた記事になります。
「技術的負債を解消したいが、上層部の理解が得られない」
「古い環境に疲弊しているが、変え方がわからない」
「組織が新しいツールの導入に後ろ向きだ」
そんな悩みを抱えるエンジニアの方々へのヒントになれば幸いです。
※私自身エンジニアとしての歴もスキルも浅いため、記事に誤りがあるかもしれません。
また記事を書くにあたり、Geminiを使用しているので所々にAI臭さがあるかと思います。
何卒ご承知おきください。
簡単な自己紹介
私は、とある中小SIer企業で社内エンジニアをしています。
今年の4月で新卒5年目になります。
社内向けのシステムの開発などを行っており、「コードを書く情シス」のような役割です。
文系からの入社で、学生時代は特段IT経験があったわけではありません。
1. 現場が抱えていた問題点
私がモダナイゼーションを決意した当時（新卒4年目）、勤務先の開発環境はお世辞にも先進的・モダンとは言えない状態でした。
「Gitなし・フレームワークなし」
-
バージョン管理システムが存在しない
- Gitもなければ、SVNもありません。
- バックアップは「ファイルのコピー」や「zip圧縮」。
- サーバー上のファイル名が
index_old.phpのようにリネームされることで、かろうじて痕跡が残っている状態でした。
-
バニラPHPによる開発
- LaravelやSymfonyといったモダンなフレームワークは使われていません。
- 決まった設計手法（MVCなど）もありませんでした。
- 長年にわたり独自拡張された「オレオレ関数」と、1ファイル数千行に及ぶスパゲッティコードの中に、ビジネスロジックとHTMLが複雑に絡み合っていました。
チーム開発が成立しない構造的欠陥
この環境で最も深刻だったのは、複数人での並行開発が事実上不可能だったことです。
-
協働体制が取れない
- サーバー上のファイルを直接編集・アップロードする運用だったため、誰か一人がファイルを更新すれば、その間に他の誰かが書いていたコードは無慈悲に上書きされ、消滅します。
- 「今、このファイル触ってる？」「いや、触ってないよ」という口頭確認が唯一の排他制御でした。
-
破壊されたら、戻れない
- Gitがないため、コードが壊されたり、誤って上書きされたりしても、「コミットを戻す（revert）」ことができません。
- 復旧不能な破壊のリスクが常に存在していました。
「このままでは、新しいメンバーが入っても教育できないし、複数人で大規模なシステムを構築することもできない。」
こうした閉塞感や限界を常々感じていました。
2. エンジニアの「都合」を捨て、経営の「メリット」を語る
現場のエンジニアからすれば「今すぐ作り直すべき」案件です。しかし、経営層や上司にとっては違います。
「動いているシステムをなぜ変えるのか？」
この問いに対し、単に「技術的に古いから」「開発がつらいから」と答えても、稟議は通りません。それはあくまでエンジニアの都合だからです。
そこで、説得の軸を完全に切り替えることにしました。
「技術上のニーズ」を「経営的メリット」に転換する
「便利だからやる」のではなく、**「経営にとって有利（金になる/資産価値が上がる）だからやる」**というロジックへの変換です。
具体的には、**「人材育成と会社の未来」**を交渉材料にしました。
「今の環境（Gitなし・バニラPHP）で若手を働かせても、彼らはこの会社内でしか通用しない独自の作法しか学べません。
モダナイゼーションを通じて、モダンな開発フローや技術を経験させることこそが、若手が現場に出た際の最大の武器（価値）になり、会社の技術資産になります。」
モダナイゼーションを単なる「改修コスト」ではなく、**「新人研修・OJTの一環（教育投資）」**として再定義したのです。
3. なぜ「PHP」を捨て、「.NET8」を選んだのか
モダナイゼーションにあたり、私たちは既存のPHPコードをLaravel等に乗せ換えるのではなく、**「PHPを捨て、.NETへ移行する」**というドラスティックな道を選びました。
Windows Serverを利用していることも大きな理由ではありましたが、ここにも明確な経営的な勝算がありました。
市場の変化と技術スタックの不一致
当時、勤務先の事業ポートフォリオは大きく変化していました。
社内では、ここ数年でPHP案件は減少傾向にあり、代わって.NETやJavaを用いたエンタープライズ寄りの案件が増加していました。会社としては**「PHPエンジニア」よりも「.NETエンジニア（またはJavaエンジニア）」を育成したい状況**だったのです。
経営と現場の利害の一致
この状況下での.NETへの移行は、双方にとってメリットがありました。
-
経営側のメリット：
- 今回のモダナイゼーションが、これから増える.NET案件への実践的なトレーニングにつながる。
- 社内での開発経験によって、若手は「.NETの実務経験者」として、即戦力で別案件に投入できる。
-
エンジニア側のメリット：
- 強力なエコシステムを持つモダンな環境（C#/.NET）で開発ができる。
- 市場価値の高いスキルセットを業務の中で身につけられる。
視点こそ違えど、エンジニアのニーズと経営戦略が一致しました。
4. 「Git導入」という難関
言語を.NET（C#）に変えることは経営判断として合意できましたが、開発プロセスの刷新（GitやCI/CDの導入）については、まだ壁がありました。
経営層から見れば、バージョン管理は「エンジニアが楽をするための道具」に過ぎず、コストをかける理由が見えにくいからです。
経営層に提案した際もGit導入には大きな反対こそないものの、大きな歓迎もされないという印象でした。
突破口は「外部の権威」を借りる
私がいくら「Gitは現代開発の必須教養です」と力説しても、それは「Gitを使いたい社内エンジニアのポジショントーク」として取られてしまいます。
そこで私は、社外（現場）の声を活用することにしました。
ある時、現場のベテランエンジニアの方との雑談で出た話題を、そのまま経営層に伝えてみました。
ベテランエンジニアの言葉：
「最近はどの現場でもGitくらいは使っている。逆に使えないと、現場でのコミュニケーションコストが高すぎて困る。」
社内で信頼が厚いベテランエンジニアの威を借ることで、導入の方向ですんなり話がまとまりました。
この言葉が「Gitがないと不便」ではなく、**「Gitが使えない人材は現場での評価が危うい」**という経営的な危機感をもたらしました。
「わからないから任せる」というありがたい一言
上司からは「Gitのことはよく分からない。だから君に全て任せる。上手いことやってくれ」と一任されました。
こうして私は、今回のモダナイズにおける全権を得ることができました。
この「権限・裁量」を確保できたことこそが、後のモダナイゼーション成功の最大の要因だったと確信しています。
おわりに：モダナイズへの土壌は整った
こうして、私は「バージョン管理なし・バニラPHP」というレガシー環境からの脱出を開始しました。
経営層への説明を行い、裁量権を得たことで、無事スタートラインに立つことが叶いました。
しかし当然ですが、稟議が通っただけではシステムは良くなりません。
本当の戦いはここからです。
- 0からの手探りの中で、どうやって安心安全な開発環境を作るか？
- Gitを知らない若手メンバーに、どうやってモダンな開発フローを定着させるか？
次回、後編にて、私が手に入れた裁量を使って実際に何を行い、チームがどう変わっていったのか。
その過程を書きたいと思います。