Sansan tech meetup #4 アジャイルなチームづくり in Osaka 編

# はじめに

日時：2017/03/21(火) 19:30 〜 22:00
場所：Sansan株式会社 関西支店
詳細：https://sansan.connpass.com/event/52316/

# ① プロダクトマネージャーとエンジニアで行う改善の仕組み
@ErikoObe

## 改善サイクル3つのP

### Product

MVP…最小の機能にしながらユーザーに価値を提供するのがPMの役割

### Process

- 3つの見積もりタイミング
    - ロードマップ時
    - リリース計画時
    - 開発前

- 2回のPJ振り返りタイミング
    - 開発前
    - 開発後

- バリューストリームマッピング

### Person

- 組織の取組み
   - 捨てる
     例）振り返り毎週2時間
       - 聞くだけのメンバーを減らす
       - 空いた時間で全員で改善について話をする
   - Realtime board
      - 大阪、東京間でボードを共有
   - 目線をあわせる
      - 目的・方針・背景を説明する…迷わせない
        例）エンジニアはHOWが豊富
           ⇒WHYとWHATが迷わないようにする
   - 知識を改善する
      - ランチ勉強会
        - エッセンシャルスクラム
        - 改善マインドを持ち続ける

### Q&A

Qランチ勉強会の参加ルール
⇒任意


# ②働き方を革新する?!リモートで結果を出すチームビルディング術
[@mmmmao0530](https://twitter.com/mmmmao0530)

## 変化の激しいビジネス環境

- 既存の知識やスキルだけでは時代に取り残される
- プロセスを少しずつ進化させていく

## 個人ではなくチーム

- メンバーの強み・経験・知識を融合させることが重要
- 気兼ねなく安心して発現行動できるチーム
- **心理的安全性** はチームの生産性を高める (by Google)

## 複数の役割でチーム構成

- お互いの価値観を知る（役割が変わると価値観が変わる）
- 本音で意見を言える関係性
- 信頼関係が重要（役割を超えるとブラックボックスなので）

ギャップがある
⇒ギャップを埋めるためのチームビルディング

## 成果と成長

チームの成果と個人・チームの成長

## モダンアジャイル

4つの原則

- 人々を最高に輝かせる
- 高速に実験＆学習する
- 安全を必須条件にする
- 価値を継続的に届ける

⇒チームビルディング前提の原則

※参考：[モダンアジャイル](https://www.slideshare.net/imagire/ss-64457130)

## 実践

### ワークショップ・打ち合わせの重要ポイント

- メンバーひとりひとりの積極的な参加
- 自由に意見を出し合える環境や雰囲気

### ツール

- [どこでもシート](http://sailorshop.jp/SHOP/81047/81077/list.html)
- 付箋
- ペン

⇒意見が出しやすい
（あんまり考えていないメンバーにはつらいがつらいなりにも意見が出る）

**リモート環境で使うツール**
 [Realtime Boad](https://realtimeboard.com/)

### タックマンモデル

- 形成期
- 混乱期
- 統一期
- 機能期

#### 形成期

- ドラッカー風エクササイズ
- バリューストリームマッピング
    - 役割を超えたプロセスの見える化
    - 課題の共有
    - プロセス改善

#### 混乱期

- 理想的なチーム像（プロダクトのミッションなどは自分たちでは手が届きにくい）
    - 共通のゴールを持つ
    - 本気で意見をぶつけ合う
    - 自律的に考え動き成果を出すチーム
    - 多様性を認め意見をまじ合わせるチーム
    - 学びを共有できるチーム

- 西洋文化インストール
    - Wa-gailからの脱却（MS牛尾さん）

- 働き方を変えて生産性を高めるための8つの習慣
    - 世界基準の働き方を理解
    - 気づきのディスカッション
    - 新たな働き方の実験

- 朝会の司会から関心事を共有
    - 学習する習慣づくり
    - 継続的な価値観共有

※何かを喋るためのインプット情報がないとできない

- ニコニコカレンダー
  - 夕方アイコンを共有
  - 夕会で共有
  - 意外と悩み・困りごとの共有が多い

#### 統一期・機能機

ここまでくればチームとしては大丈夫

## Q&A

### Qチームビルディングにどれくらい時間を割いているか

- チームで時間…週1時間〜2時間
- コンテンツ（取り組むための内容）を考える時間は30分〜1時間

### Qアジャイルを取り組むうえで一番大変なこと

- Be Lazy
   - 何かやりたいことの2割を実践すると8割分の価値が出る
   - 日本人はそうならない
  
  例）カンファレンスに出て報告
  - アメリカは30分ぐらいで報告完了
  - 日本はプレゼンなどで共有⇒時間かかる

### Qリモートでの開発ツール

- Slack（音声共有）
- [Zoom](https://zoom.us/)
- タスク管理…trello⇒変えようとしている

### Q社内の他のチームもアジャイルしている？

- 組織的にはスクラム
- 各チームで判断⇒発表者のチームはアジャイル


# ③早く帰るとMVP(MLP)になる
@distkloc

## MVP

- 最小限のプロダクトを実現する
- 最小限を考えるMVPが遠回りになることもある

## MLP

- 感情に訴えるプロダクトを最小限の労力で実現する

## どうやって実践するか

- 目的を明確にするとやらなくていいことが明確になる
- やらないと決める⇒Be Lazy

## 時間的な制約をつくる

- 強制的に定時で帰る
    - 日々やっている中で不要なことを真剣に考えるようになる
- 仕事以外の予定を平日の夜に作る
    - やらなくてもいいことを捨てられる


## Q&A

### Q.定時で帰ることで得られたこと

朝起きたらその日やることを真剣に考える

### Q.NLPの成果

- 仕様を削ることができた
- プロダクトオーナーが決めたものの中から話し合って不要な仕様を削る


# ④ LT枠
@okeicalm

## 「モノキュン！」の開発の話

- **アジャイル開発** ＆ **オフショア** で実施
- SES契約で実施（発注側が責任を持つ）
- Scrumを選択

## 体制

- プロダクトオーナー⇒発表者
- スクラムマスター⇒ベンダー
- 開発チーム⇒ベンダー、オフショア

## ツール

- Redmine(backlog)
- slack
- zoom⇒テレビ会議…帯域狭くてもいける


## Sprint実行

### Sprint1

1カ月でベロシティ０
⇒２週間に変更

### Sprint2

- 中国人がドキュメントを見ない
- テストしない

### Sprint3

- 開発範囲を絞って全ストーリー完了

### Sprint4

- 不具合積み重なる

### Sprint5
 
- やっとなれてきた

### Sprint6
 
不具合改修⇒βテストへ

## メトリクス

- ベロシティ…50〜60
- 不具合…残バグ100

## 振り返り

- ユニットテストを書くことを先延ばし⇒結局やらなかった
- 短いサイクルで振り返りできるのでプロセス改善が容易
- TDDで品質を作り込む必要性


# その他

飛び入りで @atsukanrock さんの『C++のtemplate特殊化的なことをC#でやった話』も面白かったけど勉強会のテーマとは違う話だったので割愛（すみません）