プログラマ以外のノンエンジニア、特にHTMLコーダーさんにとってGitを使うメリットは大きいものの、
設定？用語？げっコマンド…等、実際に使えるようになるにはいくつかハードルがある。
じゃあ順番にやってみますかっということで、3つのステップ（正確には4ステップ）に分けて導入したらうまくなじんだので、その備忘録。
0 Gitで解決できる問題の発見と、Gitそのものの認知のステップ
そもそも、ワタシのいるチームの場合はこんな問題があった
- メールかなんかで修正ファイルをZipして送ってアップ依頼してた（双方ともに面倒くさい）
- いくつかの修正をまとめてHTMLを修正したら、修正中に別の人がさらにHTMLを触ったりしてエライコッタ
- プログラマがバタバタしてたりで忙しいと全然アップしてもらえないんだけど～…
- FTPで直接ファイルをアップするので、間違っちゃったときに微妙にコワイ（※一応やらかしたらバックアップファイルから書き戻せるが…）
このあたりは、だいたいバージョン管理を導入してないチームはどこでも同じような悩みだと思う。
今Svn導入しているところはまた別の問題があると思うが、ウチの場合はゼロベースの導入だったので、
そもそもバージョン管理って？みたいなところからのスタートだったのは幸いだった。
Gitのメリットをアッピールしてみる
- 今メンバーが面倒だと感じていることを汲み取って、Gitで解決できる部分を示す
- それでも腰の重い人はこれ超オシャレでイマドキだよ！みたいな感じでやってみようと思ってもらう
- Git使わざるを得ないプロジェクトに入ってもらう
- Git導入で運用コスト下がりまっせと上の人からも承認もらう
というようなあの手この手でGitをオススメして、まずはGit、
というかバージョン管理そのものを認知してもらうことから初めてみた。
こういう感じになるとつまづくパターン
つまづきがちなのって、
「いや、今できてるし。なんでわざわざめんどくさそうな、ぎっ？ぎっつ？なに？よく分からんけどそれを覚えなきゃなんないの？」
という心理的ハードルが大きく立ちはだかるからだと思う。
その結果、
全体の雰囲気（とくに決定権のある人や、影響力の強い人）が
「じゃあ導入しなくてもいいんじゃないの…？こんなに反対されてるし…？」
って言い出して、その流れになっちゃったりするともう導入はかなりのムリゲーになる。
今出来てるのに何でまた新しいの…面倒くさそう…
を、「おっ？便利そうじゃん？」に変えてあげられれば、
このあとの用語なり概念なりを色々覚えてもらうのもモチベーションが保てて、スムーズに行くと思う。
1 「バージョン管理」のイメージをつかんで、Git特有の用語を覚えるステップ
さて、まずはGitに対して導入のモチベーションをもってもらったところで、
Gitはカタカナ的な用語が多くて、しかもちょっと普段ないような概念だったりするので
（リポジトリ？コミット？ブランチ？チェックアウトってホテル？えっ入るのにチェックアウト？ん？…etc.）
用語でつまづいてしまうと後が続かない。
習得まで時間がかかってイヤになってしまう。
それを防ぐためにも何度もGitに対してプラスの動機づけが出来るようにしつつ、
Gitのイメージ・概念をしっかり掴んでもらうと良いと思う。
用語を覚えるプラスの動機付けと、用語を繰り返し説明する
プラスの動機付けと用語を覚えるため、今見るとヒドいけど、
こんな資料を作って説明してました。
はじめてのGit forデザイナー＆コーダー
（※↑正確にはブランチにコミットを積んでいくんじゃなくてコミットの積み重なりがブランチになるんだけど、とか色々細かいツッコミポイントが。。）
概念をすっとばすとのちのち面倒
まずはこんな感じでていねいに「コミット」「ブランチ」などの用語がどういう概念なのか、
というものを説明し、概念をしっかり腹落ちしてもらうようにする。
ここを駆け足でやってしまうと、次のコマンドでの練習のときに
「えっと～………修正終わったから、ブランチしたらいいの？（※コミットのこと）」
みたいな事態になる。というか、なった。
コマンド（手を動かすために覚える）、概念（イメージを掴む）は別々に
Gitの概念をとらえる捉え方は人それぞれにはなると思うが、その人なりに
「あ～こういう感じね」っというのが納得できてると、
コマンドを叩いていてもなんとなく頭の中で、今なにやってるか描けるはず。
コマンドも、概念も、って同時に色々覚えようとすると中々上達しないので、
切り分けて概念なら概念、コマンドならコマンドを覚えるというようにした。
2 Gitの操作の練習
これは練習用リポジトリを作ってもらって、ひたすら練習、練習。
リモートアップデートして、更新をpullして、ブランチ作って、変更して、コミットして、pushする。
この一連の流れが身に付くまで何度もコマンドなり、ツールなりで練習してもらおう。
複数人で練習するのがおすすめ
このとき、複数人で一斉に始めるとなかなか良い。
というのも、コンフリクト体験をしたり、相手がやった作業をのぞいて、そしてローカルにpullして引き継いだり、といった実践により近い内容での練習が出来るので。
練習で体得する流れは
まずはブランチ作成、チェックアウト、変更をaddしてコミット、これをやる。
これがスムーズになって、混乱しなくなったら、次にpull/push。
次に、マージ。最後に、リベース。
コンフリクトの体験まで出来るとベター。
そして、ブランチを切る起点間違えてぐっちゃりしたり、既にリモートにあるブランチをリベースして無理やりpushしようとしてみたり、別の人とよーいドンで同じ個所さわりまくってしまったり、そんなことがこの練習用リポジトリで発生するととても良い、、、
が、実際には練習用リポジトリでは起こらず、本番で発生するまでがお約束です。
3 いざ、実践編
ある程度スムーズに基本の流れが出来るようになったら、定型の作業など、小規模なものからGitを取り入れてみる。
出来れば開発畑から導入し、その後企画畑、という流れで導入すると、あまりチーム全体がワタワタせずにすむかなと思います。
実践は小規模なものから
そして、小規模なものから取り入れるほど、最初はわけもわからず単純作業…っという感覚になります。
特にはじめての実践では「おっこりゃ便利！」という感覚をすぐ掴む人はいないです。
大抵は、「よくわかんないけど、覚えることもいっぱいだけど、こんな感じか…？」と、手さぐりおそるおそるな感じになります。でも、それで良いのです。
頻度高めにGitに触る機会をもうける
あとは実践なので、忘れない程度に頻度高くGitを触っていくだけでOK。
そうやって繰り返していくうちに自然に身に着けてしまえば、そのうち息をするようにGitのコマンドを叩けるようになっていきます。
（実際導入したメンバーも、最初は「よくわかんないけど、作業」と言いつつ、
少しずつ、自然と使えるようになっていった）
実践の場ではよりトラブルフルな状況に置かれていくので、そういったトラブルのたびに勉強会を開いてみたり、ノウハウをシェアしたりしていくとともに、
新しい世代に教育をする担当になってもらうと、より理解が深まるかと思います。
おわりに
“新しいものを入れてより効率的にしよう”みたいなムーブメントって、現状それが無くても回ってるからこそ、中々賛同してもらいづらいと思う。
なぜなら、よほどヒマな職場じゃない限り（そしてそもそもシステム系はあんまりヒマな職場って無いイメージ）日々業務はあるのだし、
時間があるなら目の前の仕事をなるだけ早く片付けて、早く帰りたい。
そういう新しいことに時間を費やす前に、まずは仕事しろよと。
そういう雰囲気になりやすい。
じゃあトップダウンで、
「明後日からGit使うから、じゃあGitこういうものね！」
みたいにサクッと勉強会を開いてしまうのも一つの手だと思うが、個人的にはその勉強会に参加してもらう前の下地作りも丁寧にやりたいなーと思ってる。
難しいし、とっても面倒だけど。
その反面で、きちんとチームとしてGitを導入していきたいなら、
- 便利だよ～って草の根活動で賛同者を拡げていくこと
- それでも嫌だなという人には、それを使わざるを得ない状況にすること
この甘い面、辛い面の両面の対応をしつつ、チーム、ひいては会社として省力化をはかっていたり、新しいことにチャレンジしたりといった文化を育てていったりっということが出来ればなぁと思ってる。
思ってる！