⭐️ Qiita Advent Calender 2021「datatech-jp」の8日目の記事です。
ずっとGitを使ってみたかった。
非エンジニアのわたしには、Gitが何なのかよくわからない。便利なものらしい、とだけ。 読み方もジットだったかギットだったか迷ってしまう。
ただ、知り合いのエンジニアが使っていてかっこよさげだったので、わたしも「Git使ってます！」とドヤ顔で言ってみたかった。動機はそんなものである。
そんなものなので、いざGitを使ってみようとすると、さっぱりわからなかった。
何がわからないって、何も。
目次
◆ 何がわからないのか、がわからない。
GitやGitHubについて書かれた本を読んでみた。
Git・GitHubは、書いたコードのバージョン管理ができて、共有できて、レビューし合える。そんな素敵なシステムでありツールであるらしい。
わかるようでわからない、Gitについて書かれたWikipediaはこちら↓
https://ja.wikipedia.org/wiki/Git
わたしは何かを開発しているわけではないが、仕事でSQLを書いてデータをあれこれしている。だからそのSQLの記述をGitで管理してみたらいいのでは、と思った。
とはいえ、実務で書いているものを使うのはマズそう。なので、SQLの本に載っているような練習用のクエリを使って、まずは私用のPCで個人でやってみることにした。
…しかし、何をどうすればいいのか、わからない。
いや、手順が本に書いてある。何をインストールして、どう導入を進めればいいのか、書いてある。親切に、最初はこう、次はこう、と教えてくれている。
それでも、わからないのだ。なぜそうするのか。今何をしているのか。この操作は一体何なのか。
手を進めれば進めるほど、わからないが増える。エラーも出る。エラーについて調べれば対処法が見つかる。見つかるので先に進めるが、しかしやっぱり自分が何をしているのかわからない。
わからない…！！！
何のためにGitを使おうとしていたんだっけ？ わたしは何がしたいんだっけ？
疲れたわたしはそっとMacbook Proを閉じて、Gitのことは忘れた。
◆ データ分析チームでGitHubを導入することになった。
※以下では、お仕事の具体的な内容や詳細は出てきません。また、出てくる会話などは、実際のものと少し変えて、ふわっとさせています。
Gitと縁を切って1年ほど経ったあと、なんと会社のデータ分析チームでGitHubを試してみよう、という話が持ち上がった。
いきなり実務で活用しようというわけではなく、まずは練習用として導入されるらしい。「データ分析チームでも、ゆくゆくはGitを使えることも大事になってくるだろうから、みんなで少しずつ慣れてみましょう。有料のアカウントをこちらで取得して、招待メールを送ります」的なお知らせが来てスタートした。
またとないチャンスである。やはりGitの神はわたしを見捨てなかった。
会社でGit活用に取り組むんだ、独学でやろうとした以前とは違う。今度はなんだかやれそうな気がする。所属部署にいるエンジニアでGit・GitHubを使える人から、チュートリアルサイトや初心者におすすめのツール（Sourcetree）も紹介されて、「わからないことあれば質問してくださいね」というありがたいお言葉もいただいた。
がんばってみよう、会社だってその必要性を感じているんだから。
…しかし、やっぱりわたしにはGitがわからなかった。
そして、他のメンバーもまた、使い方がわからないようだった。
GitHubにログインしたら、すでにGit・GitHubを理解しているエンジニアだけが何やら使いこなしていることだけは見ていてわかった。しかし、わたしを含めたわからない勢は、ただそれを見つめるしかなかった。質問も飛ばない。なぜなら、何を質問したらいいのかすらわからないからだ。
もはやGitHubにログインすらしない人もいた。我々にはまだGitは早かったのだ。データ分析チームには、得体の知れないツールが導入されただけで、だれもGitの恩恵にあずかれない。
SQLのクエリの管理？ そんなもん、.sqlファイルに名前をつけて、ファイル名でどれが最新のものかわかるようにすればいい。変更部分がわかるようにしたければ、コメントアウトさせて何か書いておけばいい。Gitはもういい。
（そしてフォルダ内はこうなった…）
yyyymmdd_なんとか用_最新_修正その2.sql
yyyymmdd_なんとか用_これが一番新しいやつ.sql
yyyymmdd_なんとか用_v2.sql
yyyymmdd_なんとか用_追加_修正版1.sql
yyyymmdd_なんとか用_追加.sql
yyyymmdd_なんとか用_最新版.sql
yyyymmdd_なんとか用_いったんこれでいく.sql
yyyymmdd_なんとか用_とりあえず.sql
◆ 突然現れた救世主（メシア）
Gitに再び背を向けて、約半年が経った。わたしはGitをすっかり諦めていた。データ分析チームではもうGitHubの話題すら出ない。
そんなときに、救世主が現れたのだ。突如入社してきた、つよつよエンジニアである。
コロナ禍でリモートワークがメインのため、どんな人なのかはよく知らない。会う機会もない。ただ突然現れて、「最初は担当案件も少ないし、手が空いている今のうちにGitHub勉強会でもやろうかな〜」なんてチャットで言い出した。
またとないチャンスである。やはりGitの神はわたしを見捨てなかった（2回目）。
わたしはつよつよエンジニアに、チャットで正直に現状を伝えて、助けを求めた。「GitHubに興味があります、でも挫折しました、SQLのクエリを.sqlファイルとして名前をつけて管理（？）していますがもうフォルダ内はめちゃくちゃです、どうしたらいいですか」と。
救世主はZoomでも話を聞いてくれて、わたしのつたない説明ですべてを把握された。そして、「勉強会じゃダメかもしれない、マンツーマンでのGitHub導入支援をしよう」と言われた。わたしは、つよつよエンジニアの名前のみが表示されているZoomの画面に手と手を合わせて祈り、顔も知らない救世主に感謝した。これが夜明けであった。
◆ たった2週間でGitHubが使えるようになるなんて。
やると決めたら、つよつよエンジニアの行動は早かった。「めんどくせー」「もう疲れた」とは言いつつも、すぐにGitHub導入支援のための資料を作成し、座学とハンズオンで教えることをまとめてくれている。
わたしと、あともう一人、同じチームのメンバーで「Git？まあ使えたら便利なんでしょうか？」くらいの認識でGitの知識自体はゼロの人間が集められた。さらにチューターとして、「独学ですがGitHubの操作はひと通りできます」というメンバーにも参加してもらい、講師1名・チューター1名・生徒2名の体制でGitHub導入支援がスタートした。
結果から伝えると、GitHub導入支援がはじまって2週間で、わたしともう一人のメンバーはGitHubを使えるようになっている。
つよつよエンジニアのカリキュラムはこうだった。
まずは1時間だけ座学。
ここで、「Gitとは？」「GitHubとは？」「現状どういうことが課題であり、どうしてGit・GitHubを使うのか」「セキュリティについて」など、知識を得たり理解を深めたりする。
そして次の5時間がハンズオン。
GitHubのセキュリティの設定からSSH接続、Sourcetreeのインストールと設定、READMEの編集方法、.gitignoreの指定、リポジトリ・ブランチ・コミット・プッシュ・プル・プルリクエスト・マージといった基本的なGit関連用語の説明をしつつ実践…など、あれもこれもを画面共有しながら手取り足取り教えてもらえる。
これらを週に3日ほど、各回1時間で進めていき、2週間で導入が完了した。
大人数が参加する座学の勉強会ではなく、ごく少人数で取り組む導入支援。それが、本当によかった。その場ですぐに質問できるし、つまずいたときも手を上げれば必ず救ってもらえる。今何をしているのか、何のためにその設定をするのか、聞けば何でも説明してもらえる。
しかも、場の空気はとてもあたたかい。「コミット、できました！」「プッシュ、しました！」「プルリクエスト、しました！ レビューお願いします！」「マージ、しました！」と、ひとつ操作できるたびに褒めてもらえた。
立つだけで、トイレに行くだけで褒めてもらえた、幼い頃を思い出すようだ。
少し前のわたしよ、Gitを諦めていたわたしよ、見ているか。
本を読んだりネットで検索したりしてもわからなくて挫折していたけど、救世主が現れて、ぜんぶ教えてもらえたよ。ここまでつきっきりでやってもらわないとできなかったけど、でも運良く面倒を見てくれる人がいて、なんとかなったよ…！
◆ いいからやれ！
GitHub導入支援が終わり、運用のフェーズに入った。ここからは、自分たちでGitHubを活用していかなければならない。
もう使い方はわかったのだ、あとはSQLのクエリやRのコードなどをGitHubで共有していけばいい。今までは各個人で書いて、特に共有はされず、ほぼ使い捨てだったコードをもっと有効活用できるようになる。知見を共有して、みんなでスキルアップしていける。すべてがより良くなりそうだ。
しかし、GitHub導入支援が終わってしばらくしても、わたしはSQLのクエリをGitHubで共有しなかった。
個人のフォルダにクエリは大量に保管されている。たくさんの.sqlファイルがある。それを整理して、中身の記述も綺麗に整えてから、共有しようと思っていた。やろうとは思っていた。
でも、忙しくて、やれなかった。やらなかった。いつも時間に追われて書いていたクエリなので、お世辞にも美しい記述ではない。正直に言うと、そんなクエリを人に見せるのが恥ずかしかった。
それを察したつよつよエンジニアは、急遽GitHub運用確認会を設定して、わたしともうひとりのメンバーに現状をヒアリングした。
「い、今はクエリを整理しているところで…」と言う、わたし。「忙しくて手が回らなかったです」と言う、もうひとりのメンバー。それを聞いたつよつよエンジニアは、「時間があったらやろう、では進まないよ。いいからやれ！ 毎日時間を決めて、やれ！」と言う。
最初なんだし、気にしなくていいんだよ、と。はじめから完璧じゃなくていい、と。今はGitHubに触れる時間を増やして、共有する習慣を身につけることが大事なのだ、と。GitHubで共有するにあたってSQLの記法を決めたけど、昔のコードを共有する場合は書き方が違ってもそのままでいい、と。
それからわたしは、毎朝15分、必ずSourcetreeを立ち上げて、GitHubにSQLのクエリをアップする時間を確保するようになった。汚いクエリで恥ずかしいとか言っていても仕方ない。それがわたしの実力だ。共有したほうが、もっと良い書き方を教えてもらえる機会も増えるし、良いことじゃないか。
そしてGitHubを毎日活用するようになってから、「あれ、AのブランチにBのブランチのファイルが入ってる？なんで？」「自分しか触ってないやつでコンフリクトが起きた！どういうこと？」などトラブルも増えた。
が、心配ない。つよつよエンジニアやチューターをやってくれた人が、「あー、それはね、…」と怒らず教えてくれるから。
◆ まだまだ課題はあるけれど。
GitHubをデータ分析チームに導入してもらって、数ヶ月が経った。
「今、わたし、どのくらいGitHub使えてますか？」とつよつよエンジニアに聞いてみたところ、「まあ必要最低限はできる、くらいかな」とのこと。おかしいな、自分ではもうGitHubマスターになったつもりだったのに。
相変わらずうまくいかなかったり、トラブルが起きたりもしている。「レビューお願いします！！！！！（ずっと放置されている）」「テンプレ設定してあるんだから、プルリクの際にちゃんと必要な情報を埋めて！」などなど。
いろいろあるけれど、やっぱりGitHubを導入してもらえてよかったな、と心から思っている。
これまでは、誰かが書いたSQLのクエリをUI上で見ることはできていたり、各個人で.sqlファイルとして保管していたりはしたけど、レビューし合う文化は無かったから。
それが、「こういうときは、こんな風に書いたらいいんだね」「この書き方だと処理に時間がかかるから、こうするのがいいよ」とお互い教え合い学べる環境になった。
個人でがんばることが多かったのが、チームで一緒にがんばる方向になってきて、ちょっと雰囲気も良くなってきた気がする。リモートワークが中心だけど、出社しているときよりも連携が強くなったように思う。
GitHubマスターだね、と言ってもらえる日はまだ遠いのかもしれないけど、これからもGit・GitHubをどんどん活用していきたい。
そしてこれは余談だが、転職サイトのプロフィール登録のところでGitやGitHubについて書くと、スカウトが増えた。やっぱり、Git・GitHubを使えるようになってよかった！
