「nanapi勉強会 vol4」に参加してきました

nanapiさんとはてなさんが共同で主催された、開発フローや開発手法、継続的インテグレーションや継続的デリバリーなどDeveloper Productivityに関する勉強会、「nanapi勉強会 vol4 - 【nanapi x はてな】はてなとnanapiの開発フロー」に参加してきました。

オープニング

@wadapさんによる発表。

• 開催の経緯
  • 福岡でnanapi勉強会vol3を開催
  • 京都でもやってほしいとはてなの@stanakaさんから要望が
  • せっかくなら東京でもやりたいです
  • vol4開催
• 来週京都でも近い内容でやる（はてなさんのオフィスで）

nanapi IGNITIONチームの開発フローとその構築 / nanapi

@vexus2さんによる発表。

• 自己紹介

  • サーバサイドエンジニア
  • PhpStorm Advent Calendarを24日分くらい書いた
  • nanapiではnanapi、answer、IGNITIONをやっている

• IGNITIONチームにおける開発フロー

  • 社内外の起案でタスク発生
  • スクラムでタスク化
  • 開発
  • リリース

• スクラムについて

  • 以前は物理カンバンに付箋でやっていた
  • 物理カンバンを廃止を禁止した
    • 付箋とIssuesとの二重管理に
    • 物理看板の移動が面倒
    • ログとして残せない
  • PivotalTracker導入
    • 各チケットでの優先度付けが楽
    • チケットのフローがシンプル
    • Slackなど外部コミュニケーションツールとの連携が楽
    • GitHub連携も
    • 朝会は自席のモニタの前で行っている

• 基本はGitHub Flowに則る

  • masterブランチは常にリリース可能に保つ
  • masterへの取り込みはfeatureブランチからPull Request
  • テストを書いてあるならリリースしてもOK
  • CSSの細かい修正などはそのままリリースOK
  • 型にまはりすぎない

• デプロイ

  • Pull Request経由で行う
  • masterへのマージでCircleCIを介してAWSに自動デプロイ
    • HubotでSlackに通知
  • Hubot経由で手動デプロイも

• CircleCIを選んだ理由

  • スペック的にcircle > travis
  • bundle installとかで決定的な速度差
  • SSHでアクセス可能
  • テストが落ちたらSlackで通知

• Jenkinsは使わない

  • カスタマイズ性が高いがメンテコストも高い
  • Jenkins職人が発生する
  • チームでメンテし続けられるなら良いト

• チームに最適なものを選択する

  • "自分が"ではなく"チームが"で考える
  • あまり欲張りすぎない
    • 高機能すぎるとチームに根付かせるのが大変
  • IGNITIONではグローバルスタンダードを重視
    • システム側も全てグローバル化

• 社内のエヴァンジェリストになる

  • ツールを押し付けても絶対に根付かない
  • チャットツールをSlackに乗り換えた事例
    • コミュニケーションツールは反発が起こりがち
    • 全力でドキュメントを読んで、翻訳したり、チップスをまとめた
  • 誰よりもそのツールを使い伝搬していく

• 現状に満足せず、モダンな環境を求め続ける

  • アーリーアダプターである必要はないが、アーリーマジョリティーであるべき

• PR

  • エンジニア募集してます
  • nanapod始めました

はてな Mackerel チームの開発フロー / はてな

Mackerelのチーフディレクターである@motemenさんによる発表。

• Mackerelについて

  • クラウドパフォーマンス管理サービス（はてなの新サービス）
  • 社内ビジネスプランコンテストから発展

• From Perl to Scala

  • はてなのほとんどのサービスはPerl製
  • Why Perl
    • 高速なTrial & Error、高速な開発
    • naoyaさんの僕やはてながPerlを選ぶ理由参照

• なぜScalaを選んだのか

  • Perlの次の言語
  • 中規模開発に耐え、堅牢なもの
  • リード開発者の趣味
    • （本当はHaskellがよかった）
  • 詳しくはScala in Perl Company参照

• Scala

  • 静的型付けの安心感
    • レビュー、リファクタリングが捗る
  • しかしコンパイルが遅い

  • 事例

    • デプロイする
    • ちょっとミスった -> 30秒で治す
    • デプロイ完了まで2時間かかる

  • のんびりとした開発

    • デプロイをちゃんと準備して行う
    • 高速化してデプロイまで30分で終わるようになった

• スクラムの導入

  • スプリント開始時にタスクを入荷
  • スプリント終了時に振り返り
  • WEB+DBの特集でやりたいと思った

• スプリントの開始：棚卸し会

  • 月曜の朝2時間
  • プロダクトバックログを見ながらタスクを決定
  • Google Spreadsheetを使っている
    • 優先度順、後ろはごちゃごちゃ
    • どのスプリント、完了したかなど

• タスクの検討

  • 1Pull Requestにできるくらいの粒度にタスクを分割

• スプリントの終了：振り返り会

  • 金曜日の夕方１時間
  • スプリントの達成度を振り返る
  • 個人・チームのKPT
  • 今後のスケジュールを確認

• MackerelチームとScrum

  • プロダクトもチームもゼロから
  • やりたいことを着実に進めていく
  • やりながら変化していった

• タスクはGitHub Issue

  • 1スプリント = 1マイルストーン
  • はてなブログチームの開発フローとGitHubに詳しく書いてある

• リモートワーク

  • はてな東京開発センター
    • 2014年にようやくエンジニアが入社した
    • Mackerelチームに入った
    • もともとリモートの予定があったのでツールは検討してあった
  • 『強いチームはオフィスを捨てる: 37シグナルズが考える「働き方革命」』が良い
  • あの人存在感無いね、にしない
    • 東京の人が存在感なくならないように
    • 雰囲気を揃える
    • オンラインビデオチャットで朝会
    • 雑談の時間を取る

  • Remote Tool

    • zoom
      • 全員の顔が一望できる
      • フリーだと40分限定→長々とミーティングするのを抑えられる
    • Sqwiggle
    • GitHub & Slack
    • polycom

  • to be continue

    • まだまだ始まったばかり
    • 機材が大事そう
    • 全員がリモートワークを意識する

• PR

  • はてな東京オフィスでリモートワークしたい人募集

開発フローパネルディスカッション

@vexus2さん, @wadapさん , @motemenさん, @songmuさんがご登壇。

以下、w:@wadapさん、 v: @vexus2さん、m: @motemenさん、s: @shiba_yu36さん。

w: 皆さん、自己紹介と自分のこだわりポイントを。

v：こだわりは早いものを重視すること。無駄なことを省きたい。私生活では自動化しきれてない。

m: こだわりは一人でつっぱしらない。みんなの様子をみる。意識をそろえる。

s: 1ヶ月前にはてなに入社。前職はソーシャルゲーム会社でリードエンジニア。35人チームでコミュニケーションに苦労したが、その中でスクラムや開発手法を学んだ。チームでの開発は最高に楽しいのでそれをブーストしたい。

w: 前職と違いは？

s: モチベーションが高くて、かっちりやってる。

w: 失敗経験をもとにこうなってるみたいな話をしたい。スクラムについてはどうですか？

m: スクラムでスプリント切ったら作業に集中できる。しかしスプリントを繋げることを考えてなかった。目の前のことをひたすらやっていて、どんなプロダクトにしたいかというマクロな視点が欠けてしまった。

w: 解決策は？

m: エンジニアとして楽しいからだけではなく、全体のプロダクトバックログを気にする。そういうことに対して意識的に時間をとる。

s: 自分の場合は、前職で大きいチームだったのでスクラムをそのまま適用するのが難しいと思った。エンジニアは新しいことをやりたがるが、それ以外がついてこれない。こちらがスクラムとか言ってもディレクター、デザイナーはピンとこない。Subversion、Redmineで満足してるのになぜ？そういうところをケアする。サポートする人を作る。

w: チームに編集長がいたvは？

v: 編集長はスクラム外。ディレクターは中にいた。コードを書かないがGitHubをコミュニケーションツールとして覚えてもらった。特に失敗はなかった。

w: nanapiは文化的にエンジニアがツールを決めて他の人に合わせてもらう。はてなさんは？

s: はてなもエンジニアが主導している。エンジニア以外の人も意外と技術に詳しい。node.js触ってたり。

w: お互いの会社ではいろんなプロダクトをやっている。サービス毎に開発手法を変えてるのかある程度決まったフォーマットがあるのか。

s: 前の会社もいろんなサービスをやっていたがリードエンジニアの裁量に任されていた。IRCでつながっているのでなんとなく把握している。毎週リードエンジニアが集まって共有会をしていた。

m: はてなでもSlackやIRCで流れてくる。リードエンジニアが集まる会もある。エンジニアの異動に伴ってツールが入ってきたりする。ブログチームが平均年齢が若くていろんなことを積極的に導入している。そこから引っ張ってる。

w: 会社共通のものはない？

s: GitHub使いましょう程度

w: vは？

v: nanapiはCakePHPでやってた。しかしIGNITIONではRailsを導入。CakePHPやRailsの知識の共有をどうするか。チャットだと流れてしまう。どうまとめるか。nanapiではナレッジをストックする場所を作っている。

w: はてなさんは？

m: はてなグループを使っている。ブログエントリーとして残している。それで情報が貯まっている。

w: 開発手法やツールは新しいのを導入して、固定化しすぎないのが重要。今気になってるものはありますか？

s: いいマイクが欲しい。リモートワークではそこが一番重要。長時間の会話だとノイズがストレスになってくる。リモートが強いチームを作ると思っている。

w: リモートワークには興味がある。マイクはアンサーで聞いてみたらいいのでは？

m: 自分はCircleCIを使ってみたい。今はJenkins。社内にあるからいいやとなっている。外部のものを使ってみたい。

w: Jenkinsおじさんがいる？

s: おじさん化する若者もいる

v: 自分はTaiga.io。プロジェクトマネージメントツール。バンダムチャートがかっこいい。

w: かっこいい？

v: かっこよさ重要。グラフィカルなツールだとテンション上がる。

w: さて、最後の質問。開発手法に正解はあると思いますか？

v: 王道はある。しかし王道に基づいているツールが最適解ではない。効率性を求めすぎてサービスが疎かになることは防ぎたい。

s: 開発手法はあくまで手段。最高のチームで最高の開発をしたい。 強いチームはオフィスを捨てる: 37シグナルズが考える「働き方革命」』には自律的に働くことが書かれている。各々が自律的に働かなければいけない。それはOSSと似ていると思う。そういう開発をしたい。

今日のパネル、お互いが依存するのではなく自律的に動いて協調するチームのあり方が、(UNIX的な)ソフトウェアのきれいな設計にも近しい、みたいなことを言ったつもりだったけど、後から思うとちょっと違う受け取られ方をしそうだなとか思った #nanapi_study

— songmu (@songmu) 2014, 10月 2

m: 手法はあくまで手法。チームが変われば手法も変わる。

質疑応答

皆さんは情報をどう集めていますか

v: はてぶ、RSSで情報を見ている。海外系のツールが多いので一次情報に触れられるように心がける。

m: はてぶを使ってます。お気に入りにいれておいて、その人がブックマークしたものをウォッチする。GitHubでもウォッチする。

s: はてぶ使ってます。RSSに出力してRSSリーダーで見るとか。naoyaさんなどホットな人を追いかける。OSS開発をやっているとツールに触れる機会が増える。

スマホアプリ開発とWebアプリの開発で違いについて

m: 隣のチームを見てると、プロトタイピング開発を行っている。画面作りがシビア。そこに注力している。

s: 前の会社でやっていた。慎重さがもとめられる。リリースサイクルが違う。サーバサイドのコードとクライアントサイドでリポジトリを分ける。そこでバージョンを合わせる必要がある。基本は変わらない。手法が確立されていない。テストが難しい。ロジックのテストはCIを回す。UIはわかっていない。

v: リリースに対する感覚が慎重になる。サーバサイドもクライアントも慎重になる。

海外でもリモートワークは可能か？通信速度や時差の問題は？

s: まだわからないが時差があるのは大変そう。レビューする時間を決めるなどを行っているらしい。まだ無理だとは思っていない。これから大変なことが起こるかも。

m:時差は大変。通信速度はあまり問題ではない。文字ベースなので。相手の顔が想像つかないと難しいかも。

v:リモートでやってる人。3人くらい。

今、5,6人のチームで開発を始めるところ。手法のとっかかりをどうするべきか。

s: 前の会社でスクラムでやろうというときにワークショップを受けた。みんながスクラムに対して前向きになる。まずは基本を抑える。テストの書き方を準備しておく。

m: 出来上がった場所がないと落ち着かない。リーダーが枠組みを先に決める。それから改善していく。

v: 最初にオーナー、リーダーが基盤を作る。方向性をメンバーに周知し、ブレないようにする。そこからブレークダウンしていく。

w: 自分はnanapiにスクラムを導入した。会社に周知しまくった。

どういうツールを入れたらいいか、時間も取りづらい

v: チームが不便に思っていることを考える。そこを自動化するツールを考える。時間をとるのは上司にコミットする。効果を明示する。

m: 仕事さぼってやればいい。それでみんなが良くなれば成功。CI回すくらいはやっておくといい。

s: Productivityはやってると楽しくなる。しかしすごく難しい。成長したWebサービスでも過去の負債に悩んでいるところはすごく多い。その状態をさらけだせるとこはさらけだして共有すればいいんじゃないか。オープンにしたら同じ悩みを抱えている会社は多いと思う。