TL;DR（この記事の要約）
- 選定： ツール選定の軸は「市場シェア（若手の価値が上がるか）」と「無料（失敗できるか）」の2点。
- 構築： 廃材のデスクトップPCに「GitLab EE (Free)」を構築し、閉域網で運用することでコスト0円とセキュリティを両立。
- 定着： 若手メンバーの「モダンなスキルへの渇望」が推進力となり、大きな抵抗なくモダンなフローが定着した。
- 品質： 無料のSonarQubeも導入し、レビューの自動化と技術的負債の可視化を実現した。
はじめに
「Gitのことはよく分からないから、君に全て任せる」
前編の記事で書いた通り、私はレガシー環境からの脱却にあたり、経営層から「全権委任」を得ました。
しかし、当然ながらできるだけ人的・時間的・金銭的コストをかけずに実行することが理想です。
後編では、私が若手テックリードとして、「超低予算」「ゼロベースから」「失敗前提」の中で具体的にどのようなツールを選定し、チームに定着させたのか。その実行記録を書きたいと思います。
1. ツール選定の基準：失敗できるかどうか
世の中には便利なDevOpsツールやSaaSが溢れていますが、私は以下の2つの軸を持って選定を行いました。
① 「メジャーであること」が正義
今回のモダナイゼーションの目的（大義名分）はあくまで若手エンジニアの市場価値向上です。
そのため、機能の優劣よりも市場シェア(利用率)を優先しました。「このツールが使えます」と履歴書に書いたとき、他の現場でも通じるものを選ぶことが、若手の市場価値を高めると判断したからです。
② 「無料」にこだわった真の理由
次に重視したのがコストです。もちろん、安いに越したことはありません。
ですが無料にこだわった最大の理由は、「失敗しても痛くない環境」を確保するためです。
私自身にとっても手探りでゼロベースからの構築です。
不便なツールを導入してしまったり、設定ミスで使えないなんてこともあるかもしれません。
有料ツールの場合、「稟議を通した手前、簡単には解約できない」というプレッシャーがかかります。
しかし無料なら、導入してダメならすぐに捨てて別のツールを試せます。
「失敗ややり直しが前提だからこそ、財布を痛めない選択をする」
この戦略により、私は「だめなら作り直せばいい」という身軽さを保ち、高速でPDCAを回すことができました。
2. 低コストGit環境の味方：GitLab EE (Free Tier)
上記の条件を満たすツールとして選定したのは、GitLab Enterprise Edition (Free Tier) でした。
- 無料
- GitHubに次いで、非常にメジャーな製品である
- セルフホスティング可能
- リポジトリ・CI/CDなどがAll in One
これらの理由からGitLabの導入を決めました。
3. インフラは「拾ったPC」で構築
ソフトウェアは決まりましたが、ハードウェアはどうするか。
ここでも「ゼロコスト」と「心理的安全性」を徹底しました。
サーバーは「余っていた古いデスクトップPC」
AWSでもラックマウントサーバーでもなく、社内で余っていた廃棄寸前の古いデスクトップPCに構築しました。
OSにはUbuntuを採用しました。
- コスト0: 「そこらへんにある古いPC」なら許可さえあれば0秒で使える。
- 気楽さ: 万一壊しても「ゴミ」に戻るだけ。プレッシャーがない。
- 移行: もし今後専用のサーバーを立てるとなっても、Ubuntuであればクローンも容易です。
今回はUbuntu上に構築しましたが、Dockerで構築するのも良いかと思います。
「閉域網（LAN）」という安心感
また、ネットワーク構成は社内LAN内のみとし、外部からのアクセスにはVPN接続を必須にしました。（VPNはテレワークのために構築済みでした。）
クラウド版（SaaS）を使わなかった最大の理由は、若手が設定ミスをしても、情報漏洩などがない環境を作るためです。
Git初心者が誤って git push で機密情報を上げたり、リポジトリをPublic設定にしてしまったりしても、LAN内に閉じていれば社外には漏れません。
なにかあっても、せいぜい全社員向け公開になるくらいです。全世界公開よりは遥かにマシです。
この物理的な安全担保があったからこそ、若手メンバーは恐れずにGitを触ることができました。
やはり、恐れずに好き勝手できるというのは、成長において大切です。
4. 教育の壁？意外とメンバーのほうが・・・
インフラとツールが整い、いよいよチームへの導入です。
「勉強したくない」「面倒だ」「古くからのやり方を変えたくない」といった反発を覚悟していましたが、結果は良い意味で裏切られました。
若さゆえの「市場価値」への危機感
私のチームは新卒4年目の私がリーダーを務めるほど若いチームでした。
彼らは「今の環境（No Git）は異常」「このままではエンジニアとして成長できない」という危機感を強く持っていたのです。
そのため、今回のモダナイズは「面倒な作業」ではなく、「やっと人並みの環境で開発ができる」「自分の市場価値が上がる」という喜びとして受け入れられました。
前編で経営層に説いた「若手の価値向上」というロジックは、現場の若手たちも求めていたことでした。
ここはうれしい誤算でした。
5. CI/CDの導入がもたらした「自動化」の恩恵
GitLab CI/CDの導入の恩恵は、単に「デプロイが楽になった」だけではありません。
パイプラインという基盤ができたことで、これまで手動では到底回らなかった①品質管理と②保守の自動化が可能になりました。
今回のモダナイズではそこに、2つの無料ツールを組み込みました。
① レビュアーを救う「SonarQube」
Gitの導入で開発スピードは上がりましたが、今度は私のコードレビューがボトルネックになりました。
なにぶん、複数人のコードを私一人でレビューしますので、手が足りません。
そこで、CI/CDパイプラインに静的解析ツールの SonarQube（Community Edition）を導入しました。
機械的な指摘を自動化することで、工数削減以上のメリットがありました。
- 人間（私）の指摘: 「ここ直して」と言うと、どうしても「怒られた」という感情が混ざる。
- ツールの指摘: 「認知的不協和が高い」と数値で言われると、「スコアを良くしよう」とゲーム感覚で直せる。
また、長年の技術的負債（スパゲッティコード）も数値で可視化され、リファクタリングの優先順位をデータに基づいて決められるようになりました。
「最低限の品質はシステムが担保し、人間は設計レビューに集中する」体制が完成したのです。
② ライブラリの塩漬けを防ぐ「Renovate」
もう一つ導入したのが、依存関係更新の自動化ツール Renovate です。
最近では国内でも導入事例が増えているようですね。
以前の環境では、ライブラリのバージョンアップは数か月～数年に一度行うかどうかといった状態であり、何年も放置される「塩漬け」状態が常態化していました。
しかし、RenovateとGitLab CIを組み合わせることで、各種ライブラリのアップデートを自動化しました。
Renovateがライブラリの新しいバージョンを検知して自動でMerge Requestを作成し、CIが自動テストを行います。私たちはテスト結果を見て「マージボタンを押すだけ」。
設定によっては、メジャーバージョンアップの場合は無視するなど細かい動作も可能です。
これにより、「脆弱性対応」や「最新機能の追従」が、特別なイベントではなく日常業務の一部になりました。
こうしてCI/CDの導入により、現在では
- 自動ライブラリアップデート
- 自動コードレビュー
- 自動ビルド
- 自動デプロイ（テストサーバー）
が実現しました。
今後は自動単体テストなども導入したいと考えています。
おわりに
今回のモダナイズで必要だったものは、
- 廃材のデスクトップPC（0円）
- 無料のGitLabとSonarQubeとRenovate（プランにもよるが今回は0円）
だけでした。
それよりも成功の要因は、若手の学ぶ意欲や経営層の理解を得られたことが何よりも大きいと思います。
経営層にもチームメンバーにも、当事者意識（自分にもメリットが有る意識）を持ってもらえたことが、大きな助けになりました。
予算がなくても、高価なSaaSが使えなくても、「各自の意識」と「熱意」があれば、レガシー環境は変えられるのではないでしょうか。
今回のモダナイズでは、「そこそこモダンな環境を、そこそこ安く」作れたのではないか？と自己評価しております。
各種ツールの細かい導入手順やCI/CDの設定手順などは、需要があれば、後日別に記事を作成したいと思います。
加えて、現在ではきたるAI時代に向けナレッジ共有の方法のモダナイズも行いましたが、それもまたの機会に書きたいと思います。
この記事が、同じように古い環境で悩み戦う誰かの背中を押すことができれば幸いです。
最後までお読みいただき、ありがとうございました。