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 に気軽に話しかけてください