- 2016/9/27 スタートアップRails勉強会発表資料
About
- @takashi
- Increments アプリケーションエンジニア
- 主にQiita:Team担当
- 最近入社した
最近
Incrementsの開発チームが大事にしていること 
- HRTを大切にしたコミュニケーション
- 作業は意識的に自動化する
- 属人性を極限まで排除する
- 重要な価値に集中する
Qiitaにおけるリモートワーク開発プロセス
HRTを大切にしたコミュニケーション
Humility(謙遜), Respect(尊敬), Trust(信頼)
リモートワークにおいてHRTとは？
オンラインコミュニケーションは誤解を招きやすい
- (本当に)意図せず冷たく接しているように伝わる
- そこで
- なにげないレビューに
を添えるだけで雰囲気が良くなる - (けど普段喋れないこともあるので)月１回はオフラインで集まるようにしている
作業は意識的に自動化する & 属人性を極限まで排除する 
- リモートワークは同期的なコミュニケーションを取るコストが高い
- 入社したその日には誰にも聞かずに働ける(環境構築も終わった)みたいな環境がとても便利
たとえば
- 入社した際のフローをまとめておく
- docker-composeを使った開発環境の配布
- イケてないUIの勤怠管理システムをラップして、slack上から勤怠管理を行えるように
- re:dashを使った各種KPIの計測、それをslackから参照できるように
- (そしてそれらを)Qiita:Teamに残しておく
重要な価値に集中する
- スタートアップに無駄なことをしている時間はない
- 「本当に必要な機能なのか」をしっかりと確認するためのフローが必要
- 口頭で話した、は無くしていきたい
PRD, RFC
PRD
Product Requirements Document
つまり 「製品への要求が書かれた文書」
- IncrementsだとQiita, Qiita:Teamぐらいの単位で存在する
- 製品の目指すゴール、ユースケース、UXや技術的な要求について詳しく書いていく
- 新しい機能の実装時などに、逐一確認、必要に応じて編集しながらゴールを明確にしていく
- 実装方法については書かない
- 迷ったらここを見る
なにを書くか
# 概要 / Summary
# 背景 / Background (Optional)
# 製品原則 / Product Principles
# スコープ
製品のゴールおよびゴールとしないものについて記述する。
# KPI
# 対象ユーザー / Target Users
# ユースケース / Use Cases
# 市場分析 / Market Analysis
# 競合分析 / Competitive Analysis (Optional)
# 機能要求 / Functional Requirements
# UX要求 / UX Requirements
## UIモックアップ / UI Mockups (Optional)
# その他の技術的要求
## システム要求
## セキュリティ要件
## プライバシー要件
## パフォーマンス要件
# リリーススケジュールおよびマイルストーン / Release Schedule & Milestones
## テスト計画
# マーケティング計画 / Go-to-Market plan (Optional)
RFC
Request for Comments
「新機能や機能改善のための提案書」 として使っている
- 軽い気持ちでつくって共有する。いけそうだったら実装に入る
- 実装に入るまでの段階で議論を重ねられる
- 「本当に必要なものなのか」をPRDよりもミクロなスコープで見ることができる
- GoogleのDesign Docにも近い
何を書くのか
# 概要
# 動機
# 詳細
# 欠点
# 代替案
# 未解決の問い
まとめ
- HRTを大切にしたコミュニケーション
- 作業は意識的に自動化する
- 属人性を極限まで排除する
- 重要な価値に集中する
QiitaやKobitoを作る開発チームの文化
http://blog.qiita.com/post/74997115585/increments-dev-team-culture
We're hiring!
@takashi に気軽に話しかけてください