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

めも帖

「めも帖」代わりにダラダラと書いていったり、めもしたりしているだけです。

nanapi 勉強会 vol.4 #nanapi_study に参加してきました

10月2日に「はてなとnanapi の開発フロー nanapi勉強会 vol4」に参加してきました。 そのときのメモです

f:id:d4-1977:20141002202003j:plain


はてなとnanapi の開発フロー

  • Twitter で話して決めました
    • 福岡でvol3はやった
  • 合同開催なので、来週は京都

IGNITION チーム

  • @vexus2

our service

nanapi

  • 月間 2,500万UU

answer

  • あついサービス

IGNITION

話すこと

  • 開発フロー
  • 開発フローの選定
  • PhpStorm のことは話さない

チーム

  • ディレクター:1人
  • 編集:1人
  • エンジニア:2人
  • デザイナー:1人

開発の流れ

  • 一般的な流れ

スクラム

  • 物理かんばん(ホワイトボード)を使っていた
    • ふせんとissueの二重管理
    • 振り返りのときに看板の移動が面倒
    • ログとして残すのが辛い

代わりに Pivotal Tracker を導入

開発

  • github flowに従う
  • master
  • エンジニア、デザイナ問わずコードレビュー

ありがちな罠

  • 「○○さんがいないのでコードレビューが出来なくてリリースできない」
    • テストがあるならOK
    • ちょっとしたCSS/HTMLの修正はOK
  • 型にはまりすぎない

ツール

Circle CI

  • TravisCIなどと比較
    • Bundle install が早い
  • SSH Access が可能
  • テストが落ちたらSlackに通知

Jenkinsは使わない

デプロイ

  • Pull Request 経由でのデプロイ
  • Slack上からHubot経由で
  • リリースは全てCircleCIで
    • SaSSに載せられるところはSaSSで
    • 問題点もある
    • CircleCI が止まったら?

開発フロー構築

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

  • あまり欲張らない
  • チーム全体の成熟度を客観的に見て選定

グローバルスタンダードを重視

  • 海外向けのメディアサービスなので
  • CI でwerckerを選びたかったがベーターだったので…

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

新規ツール導入後あるある

  • 「明日から○○使うからよろしく」では根付かない
  • 例だと、Slackに乗り換えたら、Slackをとにかく使うようにした
    • 便利系を伝える
    • ドキュメントを用意する
    • チームに根付かせる

常に改善する

モダンな環境を求め続ける

告知


Mackerel(マカレル)

Mackerelについて

Mackerelの歴史

Mackerelチームの歴史

  • エンジニア:5人
  • デザイナ:1人

Perl -> Scala

Why Perl

Mackerel では Scalaを選んだ

  • Perl の次の言語
  • 堅牢なもの
  • リード開発者の趣味

Perlの時代

Scala

  • 静的つけの安心感
    • レビュー
    • リファタリング
  • Slowコンパイル
    • 本当に遅い

Not-So Hotfix

  • Scala Shock
  • のんびりとした開発
    • コンパイルの間にレビュー
    • デプロイ開始は早めに
    • 今では30分程度(前は2時間)

開発フロー

スクラム

  • 決まった期間(スプリント)
    • スプリント開始時にタスクを入荷
    • スプリント終了時に
  • WebDB
  • スクラムブートキャンプ

チーム構成

  • スクラムマスター
  • エンジニア:3人
  • デザイナー:1人
  • インフラ:1人

スプリントの開始

  • 棚卸し会と読んでる
  • バックログを検討
  • 今スプリントでなにやをやるか?
  • GoogleSpreadsheetを利用したバックログ
  • 優先度順
    • 目的、ゴール、理由
    • メモ

タスクの検討

  • タスク = 1PullRequest

スプリントの終了

  • ふりかえり会
  • 金曜日の夕方1時間
  • 個人、チームのKPTを行う

式次第

  • 会の進め方を書いておいた
  • だれでも出来るように

チームとスクラム

  • プロダクトもチームもゼロから
  • やりたいことを着実にすすめていく

スプリント中

  • タスクはGithub
  • 1マイル = 1スプリント

マイルストーン

  • 次のスプリント
    • 今スプリントではできない
  • イデア置き場
    • 優先度未定

季節感のあるスプリント

  • 二十四節気をスプリント名に
  • 「次は立秋スプリントです」
  • メモ:2週間ごとだから、いいかも!と思った

タスク状態ラベル

見積もりラベル

  • Issue のストーリポイントをラベル化
  • 1,2,3,4,6,13
  • Burndown Chart
    • メモ:githubでのBurndown Chartかな?

その他のラベル

  • meta(neta?)
  • ご意見募集
  • 酔っ払い

VS ホワイトボード 付箋

  • 基本的にはgithub
  • 一覧性は、ホワイトボードがいい
  • リモートは無理

はてな東京開発センター

受け入れ予定してた

  • ペアプロとビールを繰り返す
  • 書籍:強いチームはオフィスを捨てる
  • リモート最高!

あの人、最近存在感ないよね

  • みたいにしない

雰囲気をそろえる

  • オフィスリモート
  • ネット越しに会話
  • 朝会の前に雑談
    • 遅刻対策?

ツール

Zoom

Sqwiggle

  • まだ始まったばかり
  • マイク重要
  • メンバー全員がリモートを意識する

パネルディスカッション

  • @vexus2
    • nanapi
    • いき急いでいる
    • 私生活
  • id:motemen
    • おおつぼさん
    • 一人で突っ走らない
    • みんなの意識を揃える
    • id:wadapさん「このIDは?」「このIDは、他の人が決めた」
  • id:Songmu
    • はてな
    • Mackerelチーム
    • 前職で35人ぐらいのチームで、スクラムを学んだりした
    • チームでものづくりをするのが最高に楽しい

開発手法

id:motemen

  • 以前の開発手法の失敗
  • スプリントをきったので、目の前のタスクは気持ちよくできる
    • スプリントを繋げて考えてなかったので、何が作られるのかわかっていなかった
    • 解決方法。バックログを見たりした

id:Songmu

  • エンジニアは開発手法が好き。でも、それ以外の人は、そうでもない
    • SVN + Redmine で満足しているところに、githubを持ってきてもうまくいかない
    • ツールや手法を率先して使う
  • エンジニア以外をスクラムに巻き込むか?
    • nanapiの場合は、エンジニア主導
    • エンジニアを巻き込んでいく
  • はてなの場合も同じ
    • GHEのアカウントをディレクターや、サポートの人もアカウントを用意する

複数のサービスを持っている場合の横のつながり

id:Songmu

  • 前職の鎌倉では、IRCで横のつながり
  • 毎週、リードエンジニア同士で話していたりした

id:motemen

  • IRCや、Slackで話したりしている
  • 各チームのエンジニアで話していたりした
  • エンジニアの異動で手法を取り入れる
    • はてなブログチームは若くて勢いがあるので
    • お互いに取り込みをしてる

@vexus2

  • nanapi本体は、CakePHP
  • IGNITION はRails
  • チャット情報は、フロー情報。これをストックに
    • Qiita::Teamに入れている
    • エンジニア以外にも使っている

はてな

注目しているツールは?

id:Songmu

  • とにかくいいマイクが欲しい
  • リモートではマイクが重要。音声が悪いと長時間の会話がストレスになる
  • リモートをやることで強いチームを作る事になる
  • answerで聞いてほしい?人力検索で聞いてほしい

id:motemen

  • 外部のツールを使おうとならない
  • CircleCIを使ってみたい。Jenkinsに頼ってしまう
    • 若者なんだけれど、Jenkinsおじさんになっている

@vexus2

  • たいがどっとio
  • プロジェクトマネジメントツール
  • かっこいい!と思ったから

開発手法に正解はあるか?

@vexus2

  • 正解はないけれど、王道はある
  • ツールは発展途上
  • 王道や正解にはまりすぎないで、サービスを開発する

id:Songmu

  • 開発手法は手段
  • チームで開発するための手段
  • リモートで、自発的に自分でルールを決めなくてはいけない。自立して動ける。自立した人が共同で開発する

id:motemen

  • 正解はない
  • 正しい手法はある
  • チームに合わせて変わっていく。手法に合わせてチームは成長していく

業務連絡

  • ピザ来てます?
  • 来てないです

質疑応答

情報はどうやってあつめてますか?

@vexus2

id:motemen

id:Songmu

ネイティブアプリとウェブのチーム開発の違い

  • ペーパープロダクトをすごくやっている
  • リリースサイクルが違う

  • リリースが慎重

  • サーバーサイドと、アプリのリポジトリをわけなくてはいけない
  • 手法が確率されていない
  • ロジックのテストはできてきたが、UI部分はどうするか

リモート開発はどこまでいったら無理?

  • 時差があると大変そう
  • 通信速度はあまり気にしていない
  • モニターの向こうでどんな顔をしているのか?を考える

チーム開発のとっかかり

id:Songmu

  • 鎌倉(の会社)で、スクラムでやろう!となっときにワークショップをうけた
    • すごくよかった
  • テストのやり方や、書き方を決めた

id:motemen

  • チームリーダーとかが枠組みを決めるとやりやすい
  • そこから改善する
  • 最初の場所が大切

@vexus2

  • リードする人がぶれない
  • 決めた事にはコミットする

id:wadap

  • エンジニア以外にも周知した

既存のプロジェクトにツールを入れる

@vexus2

  • チームに合わせて、いま不便だと感じていることからツールを入れる
  • 上司に言ってやるほうが健全

id:motemen

  • 仕事さぼってやったほうがいいかなあ...
  • 自分の時間を削ってやる
  • CIはまわすほうが幸せ

id:Songmu

  • 個人的なプロジェクトからやってみて、会社のプロジェクトに
  • 過去の負債に悩む会社が多いので、さらけだして知見をためる

まとめ

  • 来週、京都で!

  • 手法に大きな差がないように感じました
  • ツールは少し違うけれど、自動化、ChatOpsの実践は、あまり変わらない
    • はてなも、Slackを入れるようになってるのかな?
  • リモートについても、検討してたり、始まったりで、知見をためようとしているのが面白い
    • リモートをしていなくても、リモートを意識する事でチームでの仕事が楽しくなるように感じる
  • id:wadapさんの司会ぶりが板についていてすごい
  • id:Songmuさんの「過去の負債に悩む会社が多いので、さらけだして知見をためる」というのに同感。

テストから見えてくる グーグルのソフトウェア開発

テストから見えてくる グーグルのソフトウェア開発

強いチームはオフィスを捨てる: 37シグナルズが考える「働き方革命」

強いチームはオフィスを捨てる: 37シグナルズが考える「働き方革命」