GitHub実践入門、Pull Requestによる開発の変革。GitHub Kaigi 2014

2014年6月18日

GitHub User Group主催のGitHub Kaigiが6月1日、都内で開催されました。GitHubを利用した開発は、スタートアップやオンラインサービス系の企業などを中心に広まりつつあり、いままさに数多くのノウハウの交換が求められているツールでもあります。

本記事ではGitHub Kaigiの最初のセッションとなった大塚弘記氏の「GitHub実践入門 ─ Pull Requestによる開発の変革」の内容をダイジェストで紹介します。

GitHub実践入門 ─ Pull Requestによる開発の変革

大塚弘記といいます。会社でもリアルでもほとんど@hirocasterと呼ばれています。

今日はメッセージを3つ持ってきました。まず、GitHubを使っている世界と使っていない世界についての話を少し。次に、GitHubを使っているけれど、十分に使っているかどうか、という話をして、最後に本の宣伝をさせてください。

今日はいろんな人が「Pull Request」「PR」「プルリ」「プルリク」なんて言うかもしれませんが、これはみんな同じものを指してる、ということを覚えておいてください。

Pull Requestとは何か、簡単に紹介しようと思います。

ソフトウェア開発でGitHubを使っていて、例えばユーザー関係のブランチを切ってコードを書いているとします。それをコミットして、Pull Requestを出す。つまり差分をマスターに取り込んでくださいね、ということです。

Pull Requestのときに何が起きているかというと、対話を起こしていて、そこでフィードバックが生まれます。Pull Requestとひとことで言っても、コードレビューをしていたり、そこでテストがなければテストの必要性に迫られたり、といったことが起きています。

GitHubを使う前の世界のよくある話ですが、コードを書いていて変数名をつけることがあると思います。ところが適当な変数名が見つからなくて、でもすぐに開発を続けないとリリースに間に合わないとか、すぐにバグを直さなくてはいけないとかで、あとで直そうと思いつつその場で適当な名前をつけておいて開発を進めると思うんです。

でも、あとで直すタイミングってこないんですよ。動いたらそのまま本番環境に出て行ってしまうんです。

一方、GitHubで開発している、Pull Requestで開発していますよ、というところで何が起こっているかというと、変数名に自信がないときに、そのことをGitHubに書いておこうとか、誰かに相談しよう、ということがツールによってしやすくなっているんですね。

そうするとほかの開発者がレビューしてくれる。これはコードを見ることが習慣になっているためで、早ければ数秒で、遅くとも1日くらいでフィードバックが返ってきて、タイポだったり、これ違ってるよ、といったフィードバックがどんどんコードに反映されて、どんどんコードがよくなっていくんです。

これが、GitHubがない世界とある世界の差です。GitHubでやっていこうよ、とよく言われるのはこの差が重要だからです。

GitHubがある世界の4つの要素

GitHubがない世界とある世界の差は、この4つに分類できると思っています。習慣、機会、品質、心理です。

習慣というのは、GitHubを使ってPull Requestをすると、コードを見ざるを得なくなります。コードを見て理解してフィードバックを与えないと、いつまでたってもコードの品質が上がらないし、

それから一緒に働いているプログラマの中には「この人はすごいな」と思える人がきっといますよね。そういう人にコードが見られると思うと、「こんな変な変数名だと何か言われるだろうな」と思ってちゃんと考えようとする、といった心理も働くと思いますし。

そのすごいプログラマに「このコードいいね」って言われたら、自信もってコード書けますよね。コードの分からないマネージャに「おまえがんばってるな」って言われるよりいいじゃないですか。

機会というのは、Pull Requestに対するフィードバック、例えば変数名がおかしくないか、といったことを得られる機会がすごく重要で、機会があるから修正できる。この機会がツールによって創造されているのが大きくて。

そして学習。機会から学べるじゃないですか。GitHubを導入しようと言うときに、こういう価値をプログラマ以外の人に感じてもらうのは難しいのですが、ここは大切だと思っています。

そして品質。1人の目より2人やそれ以上の目で見た方が品質が良くなるはず。

この4つの要素が、GitHubのPull Requestのスタイルで開発しているとあたりまえになっていくんだよ、ということです。

GitHubをただ使うのと十分活用することの違い

GitHubを使っている世界にも、ただ使っている人と、十分に活用している人のあいだにも、これだけの差があります。

使っているだけの人は、GitHubはコードを管理する道具だと思っていますが、活用している人は、コードの価値を高めるための行為をサポートしてくれるツールだというとらえ方をしていて、習慣を作ってくれるとか、機会を生んでくれるといったことをしてくれるツールだと認識しています。

Pull Requestに対しては、GitHubを使っているだけの人は「コードをマージしてください」という要求ですが、活用している人は「こういう風に設計しているけどどう思うか」とか、「これしっくりこないんだけどどう思う？」とか、Pull Requestをレビューしてくださいとか対話に使っていて。

「マージしてください」だとコードレビューしてくださいという意識は薄いですが、活用している人はコードレビューが当たり前になっています。

ぜひ意識してほしいのは、コードを見るときに「この変数名はこのほうが具体的でいいのでは？」といったコメントを残せるようにと。そうすることでいろんな対話をしてほしいんです。そして「いいね」ということになって、ほかの人からも「いいね」ということになって、じゃあリリースしましょう、というコミュニケーション。

コードの問題を指摘するのは簡単で、コード見なくても「この名前はおかしくない？」とか簡単に言えるんです。でも、コードをよくする、という行動や提案をしましょう。そうすることがGitHubを使う価値だと思います。

Githubを活用すると、コードをレビューすることになるはずです。それが行動を起こすきっかけや習慣を作ってくれます。これがGitHubが開発者に受け入れれ、人気がある理由です。

すると、本当の現実をコードに対して見ることになって、その現実の悪いところをどうやって回避するか、解決するか、といったノウハウは「GitHub実践入門」の本の中で書いています。

「GitHub実践入門」で活用するレベルまでいけるはず

書籍「GitHub実践入門」は、説明書じゃなくてガイドブックですとずっと言っています。

この本を書く前、去年のYAPCで「GitHubでつくる、たのしい開発現場」というセッションをやったのですが、GitHubを組織に導入すると、成長の段階というものがあるよ、という話をしました。

導入期、成長期、成熟期に分かれていて、それぞれの時期に適切な情報を提供していかないとうまく活用していけないんです。それが大変だったのでこの本を書きました。

とりあえずGitHubを使う、そして活用するレベルまで、この本でいけるはずです。

GitHubって、Pull Requestをマージしなさいといういうところまでは提示してくれるのですが、じゃあマージするときにコードのレビューをしなさいとか、マージされたくないけどとりあえず見てほしいときには「Work in Progress」って付けるとか、そういうのってなかなかマニュアルとしてGitHubからは提示されていなくて、この本ではそういうことを説明しています。

そして、本の通りにやっていくと、パブリックのGitHubにPull Requestを送ることになっていて、実際に送ることができて、それがマージされます。練習と思ってやってもらうのにちょうどいい機会を作りました。

まとめたいと思います。

GitHubを使うのが目的ではなくて、その先にあるものを獲得していかないといけない。大きい組織では導入のコストとかワークフローを変えるとかという話になりますが、コードの品質や開発効率の向上、ビジネスの成功といったことを考えるのが必要で、そうした価値をいち早く得るために、この本とGitHubが十分活用できると思うのでぜひ使ってください。

GitHub実践入門 ~Pull Requestによる開発の変革
GitHubの実践的な使い方を、実際に手を動かす形で解説する書籍です。初学者の方にもわかりやすいよう、基本的なGitやGitHubの使い方から、「ソーシャルコーディング」の目玉機能であるPull Requestの送り方・受け方まで解説します。

（GitHub Kaigiの2つ目のセッション「はてなブログチームの開発フローとGitHub」の記事は来週公開予定です。お楽しみに！）