■それはハッカソンから始まった

当社では、開発のイベント ハッカソンのコードを管理するため、GitHubを使っています。
（ハッカソンについては、こちらを参照 ↓）

ハッカソンは当初、参加者が開発環境を手軽に用意できることを重視し、ブラウザ上でコードの記述から実行まで完結するWebサービスを使って実施していました。
ただし、参加者のレベルが上がるにつれ、コード量も多くなり複数人の開発したコードをマージするのが大変．．．という状況が頻発するようになってきました。

そこで、ハッカソンの開発環境としてGitHubを導入することになり、これが私自身GitHub管理者としてのスタートとなりました。

ちなみに、業務ではもともとGitを長年使ってきました。
これに替わりGitHubの導入が決まった際には、既にハッカソンである程度の期間、管理者としてGitHubの運用経験のある自分に、白羽の矢が立ちました。
その後、契約するプラン選定から、契約処理、当初の運用方法の検討などを私が担当するという既定路線で進むことになりました。

■プラン契約の罠

さて、GitHubでどのプランに申し込むかが決まり、申込画面で会社情報など色々な情報をエントリー、最後にクレジットカードによる支払い画面まで到達しました。
あとは、支払いが完了すればめでたく契約完了＆使用開始．．．となるはずですが、最後のボタンを「ポチッ」と押すと．．．

どういうわけかエラーが発生します。リトライしても状況は変わらず．．．(;_;)。
この後、GitHub（米国本社）に慣れない英語で問い合わせを行い、その後カード会社への問い合わせを経て、ようやく無事に使用可能な状態にたどり着くことができました。

私自身、開発については詳しいものの、事務手続き的な知識は乏しいため相当焦りましたが、今となっては記憶に残る、苦い思い出、となっています。

■最初の一歩は．．．やはり自分から

さて、GitHubが使えるようになったものの、やはり”初もの”を導入すると問題となるのが

「どのプロジェクト（＝誰）が最初に、導入するか？」

です。
人には「新しいものはキケンなので手を出さず、誰かが人柱となり安全が確認できてから進みたい」という気持ちが少なからずあるはずです。
社内ではGitHubを自分用として使った人はいるものの、組織的に管理＆運営したことのある人は、ほとんどおらず、皆が手を出しにくい状況のため、最終的には自身の参画プロジェクトで、最初に導入することになりました。

■素晴らしきプルリクの世界

ということで、自身のプロジェクトでGitHubを導入し、使い始めたわけですが ”そこには素晴らしい景色” が広がっていました。（普通のGitと比べ、色々と気が利く機能が満載です！）

色々話すと長くなるので割愛しますが、実プロジェクトへのGitHub導入で、一番便利で素晴らしいと感じたのは、Pull Request（以降 ”プルリク” と称します）機能です。

プルリクは、一言で言えば
「コードレビューをスマートにオンラインで完結させるための仕組み」
です。

１つプルリクを作成すれば、それに紐づいて以下のようなことが可能です。

・コミットの記録が時系列で一覧表示される。
　＞ 開発中にこまめにコミットしてもややこしくなりません。

・コードの変更点も、ブラウザ（gitub.com）で簡単に確認できる。
　＞ コードを手元に持つ必要すらありません。

・開発者とレビュアー（または上司）とのやりとりのメッセージが全記録残り、後日参照可能。
　＞ スペルミスの指摘など、全記録が赤裸々に残るので注意が必要です。

・メッセージには画像が貼り付け可能で、UIの議論にもってこい！
　＞ 添付画像はブラウザでそのまま表示され「ここをもう少し目立たせて」なんて指示も簡単です。

・「任意のコードの任意の行」を簡単に指定して、「ここに問題がある」と指摘できる。

とくに最後の項目の威力は抜群で、これまで問題のあるコードを指摘して修正を依頼する場面では．．．

GitHub導入前

• 　議論するための場所（チケット等）を確保
• コードを含む対象ファイル名を記載
• 議論する箇所付近のコードをコピペ
• ↑のコードの付近に、「ここをこう直して」と指示を記載
• 複数箇所の指摘がある場合は上記を繰り返し

という手間が必要だったのが．．．

GitHub導入後

• 該当コードの横の「＋」ボタンを押してコメントを記載

で済んでしまいます。

これでコードレビューに対し費やす精神的＆肉体的負担も、かなり軽減され、コードレビューがかなり楽になりました。

コードレビューはソフトウェアの品質向上を主目的とするのはもちろんですが、
・コードをレビューされる側は、開発者としてのレベルアップを。
・コードレビューする側は、自身のノウハウの後進への伝達を。
と、エンジニア間それぞれのスキルアップに繋がるという効果が期待できます。

ぜひ、チーム内にGitHubの「プルリク文化」を根付かせて、いい循環ができるようにしていきたいと思います。