読者です 読者をやめる 読者になる 読者になる

初めてのシステムと日記

システムも日記も初めてです。

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さんOSSGitHub (仮)」

発表資料:OSS と GitHub

 

@cobyismさん 「How Github Works」

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

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

 

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

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

  • 何を作っているか
  • どんな人と作っているか
    • 一流のエンジニアの人達
  • どのように作っているか
    • GitHubで原稿管理とやりとり
    • md2inaoで原稿テキストの変換
      • Markdownで書かれたテキストをinDesign形式に変換
    • Adobe 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はどうしてもエンジニア、最近はデザイナーのツールというイメージでしたが、雑誌や書籍というソフトウェアでも通用し既存の問題を解決出来る仕組みは素晴らしいですね。こういう形で非エンジニアな方々にも浸透していくと面白いかなと思いました。