「nanapi勉強会 vol4」に参加してきました
nanapiさんとはてなさんが共同で主催された、開発フローや開発手法、継続的インテグレーションや継続的デリバリーなどDeveloper Productivityに関する勉強会、「nanapi勉強会 vol4 - 【nanapi x はてな】はてなとnanapiの開発フロー」に参加してきました。
オープニング
@wadapさんによる発表。
- 開催の経緯
- 来週京都でも近い内容でやる（はてなさんのオフィスで）
nanapi IGNITIONチームの開発フローとその構築 / nanapi
@vexus2さんによる発表。
自己紹介
- サーバサイドエンジニア
- PhpStorm Advent Calendarを24日分くらい書いた
- nanapiではnanapi、answer、IGNITIONをやっている
IGNITIONチームにおける開発フロー
- 社内外の起案でタスク発生
- スクラムでタスク化
- 開発
- リリース
スクラムについて
- 以前は物理カンバンに付箋でやっていた
- 物理カンバンを廃止を禁止した
- 付箋とIssuesとの二重管理に
- 物理看板の移動が面倒
- ログとして残せない
- PivotalTracker導入
基本はGitHub Flowに則る
- masterブランチは常にリリース可能に保つ
- masterへの取り込みはfeatureブランチからPull Request
- テストを書いてあるならリリースしてもOK
- CSSの細かい修正などはそのままリリースOK
- 型にまはりすぎない
デプロイ
- Pull Request経由で行う
- masterへのマージでCircleCIを介してAWSに自動デプロイ
- HubotでSlackに通知
- Hubot経由で手動デプロイも
CircleCIを選んだ理由
Jenkinsは使わない
- カスタマイズ性が高いがメンテコストも高い
- Jenkins職人が発生する
- チームでメンテし続けられるなら良いト
チームに最適なものを選択する
社内のエヴァンジェリストになる
現状に満足せず、モダンな環境を求め続ける
- アーリーアダプターである必要はないが、アーリーマジョリティーであるべき
PR
- エンジニア募集してます
- nanapod始めました
はてな Mackerel チームの開発フロー / はてな
Mackerelのチーフディレクターである@motemenさんによる発表。
Mackerelについて
なぜScalaを選んだのか
- Perlの次の言語
- 中規模開発に耐え、堅牢なもの
- リード開発者の趣味
- （本当はHaskellがよかった）
- 詳しくはScala in Perl Company参照
スクラムの導入
- スプリント開始時にタスクを入荷
- スプリント終了時に振り返り
- WEB+DBの特集でやりたいと思った
スプリントの開始：棚卸し会
タスクの検討
- 1Pull Requestにできるくらいの粒度にタスクを分割
スプリントの終了：振り返り会
- 金曜日の夕方１時間
- スプリントの達成度を振り返る
- 個人・チームのKPT
- 今後のスケジュールを確認
MackerelチームとScrum
- プロダクトもチームもゼロから
- やりたいことを着実に進めていく
- やりながら変化していった
タスクはGitHub Issue
- 1スプリント = 1マイルストーン
- はてなブログチームの開発フローとGitHubに詳しく書いてある
リモートワーク
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月 2m: 手法はあくまで手法。チームが変われば手法も変わる。
質疑応答
皆さんは情報をどう集めていますか
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サービスでも過去の負債に悩んでいるところはすごく多い。その状態をさらけだせるとこはさらけだして共有すればいいんじゃないか。オープンにしたら同じ悩みを抱えている会社は多いと思う。
