GitHub Kaigiに参加してきた #githubkaigi - 初めてのシステムと日記

GitHub Kaigi http://githubkaigi.org/

今日、サイバーエージェントさんで行われたGitHub Kaigiに参加してきました。その発表資料と内容のメモ書きになります。

@naoyaさん「Hello, Github Kaigi」

GitHub Kaigiを開催した経緯
- GitHubが浸透してきたので頃合い
1000人くらいの事前アンケート結果
- GitHubを使い始めたのはいつから
  - 2013年以降がほぼ
- Pubilicリポジトリはどれくらい持っている
  - 5-10個ぐらいがほぼ
- PRを受けた事がある
  - 40%弱
- PRを送った事がある
  - 50%くらい
- Privateリポジトリを持っている
  - 26%
- GHEを使っている
  - 28%
- Atomを使っている
  - 30%

@hirocasterさん「Github実践入門 ─ Pull Request による開発の変革 (仮)」

発表資料:GitHubKaigi Keynote

GitHubを利用した開発の世界を知る
- ここでいう世界とは業務、仕事でGitHubがあるかないかの世界
- GitHubの世界へようこそ
  - PRを利用した開発
    - 対話
    - フィードバッグ
    - コードレビュー
    - テスト
    - マージ
  - よくある世界
    - なんとなく変数名をつける
    - この変素名、適切じゃない気がする
    - とりあえず機能を完成させる
    - あとで適切な名前を思いついたら変更する
    - 「あとで」は一生こない
    - 他の人に目にも触れずに本番環境で稼働
  - GitHubのある世界
    - なんとなく変数名をつける
    - この変素名、適切じゃない気がする
    - とりあえず機能を完成させる
    - このことをGitHubに書いておく
    - 他の開発者がレビュー
    - 良い変数名 + α をフィードバッグ
    - コードに反映
- これが2つの世界の差
  - 習慣(見る、読む、見られる、読まれる)
  - 機会(修正、拡張、学習)
  - 品質(2 eyes < over 4 eyes)
  - 心理(不安、安心、自信)
GitHubを利用|活用する違いを知る
- 世界の中の差もある
  - GitHub
    - コードを管理する道具：使っているだけ
    - コードの価値を高める道具：活用している
  - PR
    - 差分を入れる：使っているだけ
    - 対話、設計、改善：活用している
  - コードレビュー
    - する、してもらう：活用している
- 指摘 = 簡単、提案 = 難しい -コードをより良くすること
- GitHubを導入すると
  - コードをレビューする
  - 行動を起こすキッカケをつくることができる
  - 良い所も悪い所も見れる = 現実
GitHub != 目的
- GitHubの先にある物を獲得しなければいけない
- 開発効率？品質？
- ビジネスの成功？ソフトウェアの向上？

@shibayu36さん「はてなブログチームの開発フローとGitHub」

発表資料:はてなブログチームの開発フローとGitHub

はてなブログチームについて
- はてなブログを開発
- 5エンジニア、2デザイナー
- 月に
  - 170 PR
  - 1281 commits
  - 45 releases
- GHEで運営
  - 開発速度を保てている
  - GitHubでの開発フローの改善
- 開発の流れ
  - Issueを登録
  - branch作成
    - master
    - develop
    - feature branch
  - 開発、レビュー
開発フローの課題とその解決
- タスク管理
  - 以前
    - Redmine(タスク管理)
    - GitHub(コードレビュー)
      - 開発者が両ツールを見る必要がある
      - コードとの連携も上手くいかない
      - 開発者の効率があがらない
  - GitHubをメインにしてみた
    - Issueとコードの連携
      - 開発者の効率はアップ
    - Issuesには優先度、締切などの仕組み少ない
    - 誰が何をやっているかが分からない
      - マネージャがチームの俯瞰を出来ない
  - GitHub + カンバン
    - チームの重要なもの、進行中などの管理はカンバン
    - Issue
      - 全てのタスク管理
    - カンバン
      - Issueの中で重要なものだけ追加
      - 朝会で確認
  - GitHubとタスク管理
    - Issuesをメインで開発者の効率化
    - カンバンで重要なものを管理
    - スクラムまでいかないゆるいタスク管理
- レビュー
  - 以前
    - 個別にPRを送る
    - 気が向いたらPRを探してレビュー
    - PRの状態が分からない(のでレビューをためらう)
      - レビュー依頼中？
      - レビュー後の修正中？
      - レビュー終わってる？
    - レビューが消化されずPRの量がたまる
    - ベテランだけがレビューし続けるはめに
  - 解決案
    - レビュー状態ラベル
      - PRにラベル付け
      - レビュー依頼
      - レビュー中
      - レビュー完了
    - レビュータイム
      - ランチ後14:00
      - レビュー依頼をレビューする
      - IRC botで通知
- リリース
  - 流れ
    - PRがどんどんマージされてどこかでリリース
  - デプロイ自体はコマンド一発(capstrano)
  - リリースに必要なもの
    - リリースして良いかの確認
    - 検証環境で最終確認
    - デプロイコマンドでデプロイ
  - 自動化が出来てない
    - マネージャ確認せずにリリース
      - 何がリリースされるか抜けかあった
    - 新人がリリースできない
  - デプロイ以外のサポートが出来ないか
    - リリース用のPR手順書を作成
      - developからmasterへのマージをリリースPR
      - リリース内容
      - リリース後のチェック内容
      - コマンド一発で作業出来る仕組みを作った
      - https://github.com/motemen/git-pr-release

@amatsudaさん「OSS と GitHub (仮)」

発表資料:OSS と GitHub

@cobyismさん「How Github Works」

発表資料:How GitHub Works (GitHub Kaigi, Tokyo, 2014)

GitHubの中の人の仕事の仕方
60%がリモートで仕事している
一番重要なのは幸せを感じる事
- 働きたいと思う企業を自分たちで構築する事
- その他で起きる事は全て副作用
- 幸せを持続するにはモチベーション
モチベーションの要素
- 外発的意欲
  - お金
  - 食事
  - 家など
- 内発的意欲
  - 柔軟性
  - 自主性
  - 透明性
- 内発的意欲が幸せに重要
信頼が必要
- 信頼出来る人を雇う必要
- 才能が全てではない
自分にあった場所で自分の時間で働く
- 必要な時に休暇を取る
- リモート作業にも価値はある
- リモートがデフォルトの働き方
柔軟性は家族を持つ人には最高
リモートで作業する事も最高の経験である必要がある
- 発想の転換が必要 = 行動の変化を必要
- 全ての企業でリモートが上手くいくわけではない
- リモート作業は未来である
使用しているツール
- チャット
  - HUBOT
  - ソーシャルである
  - デプロイ通知
  - 継続的インテグレーション
  - HUBOTを用いた社内ワークフローChatOpsと呼ばれている
- ビデオチャット
  - Blue Jeans
- 重要なのはツールではなくその使用方法
- 会話でショートカットを使用しない
- 皆がリモートを得意にする必要がある
- 絵文字は素晴らしい
直接会う機会
- 全社会議
- 製品グループ会議
- チーム会議
- 新入社員研修
必要とする信頼関係を築く
働き方が非同期でも休み時間はとってもいい
反復が成功への鍵
上手く行くものは時間で変化する
Everything should have an URL

@inaoさん「GitHubで雑誌・書籍を作る」

発表資料:GitHubで 雑誌・書籍を作る

何を作っているか
- WEB+DB PRESS
- WEB+DB PRESS plus
どんな人と作っているか
- 一流のエンジニアの人達
どのように作っているか
- GitHubで原稿管理とやりとり
- md2inaoで原稿テキストの変換
  - Markdownで書かれたテキストをinDesign形式に変換
- Adobe inDesignで紙面レイアウト
  - inDesignタグ付きテキスト
GitHubをどう使っているか
- ブランチモデル
  - 作業者がWIPなPRを送る
- コミット
  - 特集1個で500くらい
  - 見出し単位でコミット
  - 意図を伝えたい変更はピンポイントでコミット
- FB方法ーPRの確認時にはGitHub上でコメント
  - テキスト上での校正はテキスト中にkakikomi
GitHubで何が変わったか
- 進捗状況が見える化された
- Issue/PRによりメールを使わなくなった
- コミットメッセージで変更意図を伝え易くなった
- 思い切った変更の提案が行い易くなった
背景にある考え
- 雑誌・書籍作りはソフトウェア開発に近づけた方がうまくいく
  - 著者さんのワークフローに近いから
  - 雑誌や書籍もソフトウェアだから
- GitHubによる常時共有、バージョン課題管理
- Markdownという書き慣れた記法

@nathansoboさん「Atom, the Programmable Text Editor」

発表資料:Atom – GitHub Kaigi_jp

@yuku-tさん「入門書には載ってない Git & GitHub Tips」

発表資料:入門書には載ってない Git & GitHub Tips

GitHubの働き方は本当に素晴らしいと思いました。リモート作業による柔軟性を持続しつつ、直接会う機会も作る、人にフォーカスしたモチベーションは羨ましい限りです。

あと、@inaoさんのGitHubで雑誌・書籍を作るも興味深い内容でした。GitHubはどうしてもエンジニア、最近はデザイナーのツールというイメージでしたが、雑誌や書籍というソフトウェアでも通用し既存の問題を解決出来る仕組みは素晴らしいですね。こういう形で非エンジニアな方々にも浸透していくと面白いかなと思いました。

@naoyaさん 「Hello, Github Kaigi」

@hirocasterさん 「Github実践入門 ─ Pull Request による開発の変革 (仮)」

@shibayu36さん 「はてなブログチームの開発フローとGitHub」

@amatsudaさん 「OSS と GitHub (仮)」

@cobyismさん 「How Github Works」

@inaoさん 「GitHubで雑誌・書籍を作る」

@nathansoboさん 「Atom, the Programmable Text Editor」

@yuku-tさん 「入門書には載ってない Git & GitHub Tips」