レポート

GitHubが僕たちを,仕事の現場を変えた!──「GitHub Kaigi」レポート

この記事を読むのに必要な時間:およそ 5 分

OSSとGitHub

続いてのセッションは,Railsコミッタとして有名な松田明氏による発表です。

同氏はまず,⁠Social Coding 3部作」として自らのスライドである以下を紹介し,ソーシャルコーディングは「誰もがコードを平等に読み書きできる自由」を持つ意義深いものであるとまとめました。

続いて松田氏は,本題の「OSSとGitHub」というテーマについてRuby on Rails⁠Ruby⁠⁠,そして同氏の開発するRails用ライブラリKaminariといった同氏のよく知るプロジェクトそれぞれとGitHubとの関係について紹介しました。

RailsとGitHub

そもそもRailsプロジェクトは,GitHubの正式公開後すぐに公式リポジトリをGitHubに移行しています。こういった経緯や,GitHub自体がRailsで作られていること,結果としてRubyコミュニティでのGitブームを牽引したことなどから,RailsとGitHubとはとても相性が良いと述べました。

GitHubを使ったRailsの開発フローは,⁠開発者がPRを送り,それをコミッタがレビューしてマージする」というごく普通のものであるとのこと。このような開発が実現している理由として,PRを積極的に歓迎していること,コミット数ランキングで貢献を視覚化していることなどが挙げられました。

RubyとGitHub

一方のRubyはといえば,また違ったGitHubとの関係を持っています。そもそもRubyには20年という長い歴史があり,少数の主要コミッタによる貢献がかなりの割合を占めているという特徴があります。

Ruby本体についても,メインリポジトリのミラーがGitHub上にあります。そのため,通常のRedmine上でのパッチのやりとりのほかにGitHub上でのPRを使った貢献も可能ではあります。しかしPRはそのままマージされるのではなく,コミッタがpatch化してメインリポジトリのほうに反映するという流れになっています。

このようにGitHubがあくまでサブの扱いである理由として,少数の主要コミッタによる貢献がかなりの割合を占めていることもあり現状それほど困っていないという事情や,Windowsサポートの問題などを挙げていました。

KaminariとRuby

最後に松田氏自身が開発するRails用ライブラリ「Kaminari」についてです。RailsにおけるPagenatorの定番ともいえるKaminariですが,このように人気が出た理由として同氏は「ドキュメントを(英語も含めて)しっかり書いたこと」⁠Asakusa.rbを立ち上げたりカンファレンスに参加するなど,コミュニティに積極的に関わったこと」⁠それによってコミュニティの友人たちが広めてくれたこと」を挙げました。

松田明氏。⁠Kaminari」のGitHubでのStar数が,発表中に4000を超えるという一幕も

松田明氏。「Kaminari」のGitHubでのStar数が,発表中に4000を超えるという一幕も

そして,GitHub自体がコミュニティであることを述べたうえで,そこで関わった開発者たちとリアルで話をすることが楽しく,かつ重要であるとし,OSS開発に積極的に参加し楽しんでほしいと伝えました。

「OSSとGitHub」セッションスライド

GitHubの働き方

前半最後のセッションはGitHubのデザイナ/開発者であるCoby Chapple氏の発表です。サンフランシスコを拠点とするGitHub社ですが,同氏は北アイルランドに在住,つまりリモートワークをしています。発表のなかでは,こうしたリモートワークが全社員の60%を占めるGitHub社での働き方について述べられました。

自身もリモートワークを行うというCoby Chapple氏

自身もリモートワークを行うというCoby Chapple氏

同氏はまず最初に「最も重要なのは幸せである」と述べ,それを実現するためのモチベーションを外発的なものと内発的なものとに分類しました。たとえばお金は外発的なモチベーションのわかりやすい例といえるでしょう。では,内発的なモチベーションとはなんでしょうか? それが意味するところは「柔軟性」⁠自主性」⁠透明性」であるといいます。

柔軟性,つまり,好きな場所・好きな時間に働くことを実現するためには,さまざまな工夫が必要です。そこで,リモートワークという選択肢をデフォルトで用意するために,GitHubがなにを実践しているのかが次々に紹介されました。

たとえば社内チャットでのHubotの利用です。チャット用botにちょっとしたおもしろ機能を付けたり,チャットかラデプロイ作業ができるような自動化のしくみを持たせるなど,会話の中心にツールを置くことにより,開発者同士の距離を縮めることに成功しているといいます。

もちろん,開発対象であるGitHubそのものも活用しています。まじめなプロダクトのリポジトリをGitHubで管理するのはもちろんですが,趣味に関するリポジトリを作りそこに写真をアップロードするなどして交流していたりもするのです。

リモートワークが主体とはいえ,実際に会う機会を設けることももちろん重要です。GitHubでは,⁠Summit」と呼ばれる全社員が一堂に会する機会を設けたり,プロダクトごとの会議,チームごとの会議を都度行っているようです。このようにして信頼関係を築いていくことで,柔軟な働き方を担保しているようでした。

また,透明性の確保の秘訣として紹介された「Everything should have an URL(すべてがURLを持つべき⁠⁠」という考え方も参加者の印象に残るものだったといえるでしょう。

最後に同氏は,ベストな方法は変化していくため,常にこうした考え方・実践をの改善を続けていくべきだとして発表を締めくくりました。

「How GitHub Works」セッションスライド

GitHubで雑誌・書籍を作る

休憩を挟んで,後半最初のセッションは,弊誌『WEB+DB PRESS』編集長の稲尾による「GitHubで雑誌・書籍を作る」でした。

MarkdownからInDesignタグ付きテキストへ

現在WEB+DB PRESS編集部では,多くの記事が以下のワークフローで制作されています。

  1. GitHubで原稿のやりとり
  2. 原稿テキストをmd2inaoでInDesign用のテキストに変換
  3. 変換したテキストを使って,InDesignで紙面レイアウト

そもそもWEB+DB PRESS編集部では,2010年ごろまで独自の記法(いわゆる「inao記法⁠⁠)での原稿執筆をお願いしており,それをInDesing用のテキスト(文字まわりのスタイルを一通り設定できるタグ付きテキスト。これを使うことで組版作業を省力化できる)に変換していたという経緯がありました。

とはいえ,独自の記法は使いづらい点も多く,あるとき@typestar(村瀬大輔)氏がMarkdownで書いた原稿をからinao記法に変換するスクリプトを作ってくださいました。そしてさまざまな著者のみなさまに改良を加えていただき,今ではMarkdownの原稿を直接InDesign用のテキストに直接変換するプログラムとして成長しています。

WEB+DB PRESS編集部でもGitHubを利用しています

WEB+DB PRESS編集部でもGitHubを利用しています

GitHubの活用によって変わったもの

こういった原稿の多くは,GitHubやBitBucketでやりとりされています。Git/GitHubの利用による変化としては,以下のようなものが挙げられるでしょう。

  • 著者さんの原稿執筆の進捗状況を把握しやすくなった
  • IssueやPRのしくみを活用することによりメールを使う必要がなくなった
  • コミットメッセージを使って変更の意図を伝えやすくなった
  • PRの破棄やrevertが容易なため思い切った変更の提案が行いやすくなった

Git/GitHubの実戦投入からまだそれほど経っていませんが,著者のみなさまの助けもあり,現在ではWEB+DB PRESS編集部の多くがこれを活用している状況です。

雑誌・書籍作りをソフトウェア開発に近づける

こうした実践を通して,ソフトウェア開発の利点を取り入れることで雑誌や書籍作りがうまくいくことがわかってきました。編集部ではこれからも,MarkdownやGit/GitHubの利用にとどまらない,ソフトウェア開発の知見を取り入れていきたいと考えています。

「GitHubで雑誌・書籍を作る」セッションスライド