はじめに
最近、社内のバージョン管理ツールを（ようやく）SVNからGitに切り替えたのでその話。
新しいモノに触れようとしない、古い技術にしがみつく層が多く、そんなメンバーに改宗してGitを採用してもらうべくエヴァンジェリストな活動をしました。
やったこと
- 座学による概念理解
- ハンズオンによる体験と、Gitクライアント環境の個人PCへの導入
- アフターフォロー
座学による概念理解
私自身が初めてGitを使い出したときに、SVNとは概念や用語の違いがあって、スッキリ理解するまでに時間がかかったので、メンバーにはそこを一気に飛び越えてもらえるように講義形式でレクチャーしました。 また、今のSVNから移行するにはスイッチングコストがかかるし、Gitは学習コストもそこそこ高いので、慎重派を動かすためには、SVNでのお困りごとがGitなら解決できますよ、という例示が効果的でした。
Gitのメリット
個人単位で任意にローカルコミットできる。
SVNだと、コミットしたコードは全体で共有されるので、ビルドが通らない、開発途中などの中途半端なものをコミットすると、他のメンバーの作業にも影響を与えてしまう。 Gitは個人単位でローカルリポジトリを持っており、そこに対してコミットしていき、ある程度まとめて共有リポジトリ（リモート）に対してプッシュという操作で反映する。 なので、「ライブラリを試してみてダメだったら戻す」とか、「リファクタリング前にいったんコミット」なんかが圧倒的にやりやすい。
（GitLab）コードレビューのための仕組みがある。
マージリクエストという仕組みを使うことで、ソースコードレビューをブラウザ上でできて、指摘コメントなどの記録も残せる。これまではレビュー記録票というExcelシートを使っていました。 マージのコンフリクト時も、ブラウザ上でコンフリクト解消してマージ作業を完結することができる。
並行開発がやりやすい
段階リリースだったり、アジャイルとかイテレーティブな開発スタイルを採用している場合に相性がよい。どのようなブランチモデルで運用するかにも寄りますが、本番稼動しているバージョンのコードには手を付けずに、開発ブランチであれやこれや機能追加して、テストして、ということができる。これの何が便利かというと、開発途中に本番系で緊急対応が必要になったとき、緊急対応部分だけをリリースすることが出来る。ほかにも、並行開発ありきで作られているので、便利なコマンドがたくさんある。
ハンズオン
座学だけでは、いざ使おうというときに、環境構築やらなんやらで結局つまづいたり時間が取られてしまうので、ハンズオン形式で環境構築とGit操作体験まで一気に立ち上げることにしました。 これにより、自分のPCにGitクライアント環境が整うので、いつでも使い始められる状態になり、使い始めるときのハードルを下げることができると思います。
アフターフォロー
困ったときにいつでも気軽に質問してくれていいですよ、というアナウンスと、そのためのチャネル（Slackなど）を用意しました。 さらに、初めて導入するというプロジェクトでは、近くに座るなどして、何か困ったときにすぐフォローしてあげられるようにするのが良いですね。現場コーチっていうんですかね。
最後に
技術のアンテナ張っている人たちは、布教活動はしなくても、ハンズオンだけでも効果ありと思います。しかし、慎重派、現状維持派の人をスイッチさせる（説得する）には、彼らが理解できるレベルで何かしらのメリットを提示する必要があります。 これって、実は普段の仕事でも必要なスキルだと思います。 技術者の興味だけではなかなか新しい技術の採用は難しく、その技術によって何を変えることができるのか、を説明できることって大事だと思います。
