dots.カンファレンス　チーム開発を支える技術に参加したよー 午後の部

![dots.png](https://qiita-image-store.s3.amazonaws.com/0/93976/debaeeca-522f-494e-8c35-96d175348ccd.png)

dots.カンファレンス、チーム開発を支える技術に参加してきました！

午前の部、午後の部、と別れており今回は午後の部の紹介をしていきます。

※私の範囲内で聞いて咀嚼したものですので、内容に相違がある可能性があります。

**講演 #午後の部**

## Qiita/Qiita:Teamの開発を通して見つけた、Incrementsの文化を作る方法

**Increments株式会社 東峰 裕之氏**

![increment.jpg](https://qiita-image-store.s3.amazonaws.com/0/93976/5ee3ad51-3f2d-65bc-feaa-abfde80ca3cd.jpeg)


自己紹介：

- Twitter: @htomine
- デザイナー
- 前職サイボウズ

Incrementsってどんな会社？
書き方は「++」で言語のインクリメントを表している

ビジョン：ソフトウァア開発を良くすることで、世界の進化を加速させる

立ち上げ３名、メンバーは14名！？

- **Running Leanを実践**
 - 何を作るかより、何を作らないか
 - MVPで検証し、すぐ捨てる
 - 無駄な作り込みは悪！

- **価値仮設シートの実行**
 - (ユーザー)＿＿＿は、
 - (欲求)＿＿＿＿たいが、
 - (課題)＿＿＿なので、
 - (製品の特徴)＿＿＿に価値がある。
※cookpadさんのものを踏襲し実行

- **属人性の排除について**
 - 情報共有をTeamlでシェア
 - Teamlで書いてあれば誰でも実行可能

1. **ChatOps**
 - Qiitan(BOT) rubotyを利用し、掃除当番、Issue登録、Deploy/Mearge
 - 面倒なルーチンワークは常に疑う
 - 例：勤怠管理は打刻漏れとかめんどくさいよね！？=> Qiitan(Bot)に移行

- **初期メンバーは3人から14人になってからどう変わった?**
 - 多様化への対応が求められた
 
```
尖った人が多いが文化はあっている。趣向は少々違う
多様であり、同じ文化に共鳴する集団であることが今の強み
```

- 働きやすさをどう担保するか

```
フレックス＆リモートワークの導入
他人に強要しない
```

- **社長<=>各社員での月一1on1**

```
これを実現していくことで以下のことが芽生えてくる（はず！）
会社：社員を知ることをあきらめない
メンバー：会社が「よくしてくれるはず」をあきらめない
```

- **2014-2015はTeamに注力**


```
実行したこと
Teaming 輪読会
1.学習する組織作り
2.意見の相違の乗り越えられ
3.解決策が生まれるまで議論できる関係性があり
4.安心して率直に意見を述べられる環境である
```

**これができる組織でなら困難を乗り越えていけそうに感じられる。**

オススメの本：(http://www.amazon.co.jp/dp/4862761828/)[チームが機能するとはどういうことか]

****

## クラウドソーシングでチームを作る方法

**株式会社StartupTechnology 菊本 久寿氏**

**自己紹介：エンジニア**

```
もともとはフリーランスで一人でタスクをたくさん受けていた。
ただ案件を取りすぎて、、、炎上・・・
その中からクラウドソーシングサービスを設立して、
外注するようになったのが設立経緯
```

**クラウドソーシングを利用する理由：エンジニアを採用できない**

- **メリット**
    - 取りやすい
    - （自粛）
    - 必要な時に必要な分使える（変動費化）
    - フリーランスなど個人でも使える
    - 個人でも払える額で発注できる

- **向かないプロジェクト**
 - 大規模プロジェクト
 - PMがいない
 - ISMSなどが絡んでいる場合

- **受注側の気持ち：受けたくない地雷案件**
 - ボリュームが見えない
 - ボリュームがでかい
 - やすい
 - 夢がいっぱい

- **正しい募集方法**
 - やることが明確
 - 時給制
 - 時間コミットさせない(1500円〜2000円）

- **スクリーニングについて**
 - 先に仕事をやってもらってからスクリーニングに（通常の採用と異なる）

- **開発の進め方**
 - PMがタスク登録（レビュー）
 - 開発者が好きなgit pull request / git flowを使ってオープンソースのような形式で開発
 
- **コミュニケーション**
 - 同一のチャット空間で進めることで技術ヒエラルキーが生まれる（複数人アウトソースする場合）

- **ルールの定義**
 - セットアップ方法のドキュメンテーション(README)
 - コード規約を定める
 - その他チームのルールを定義する
 - プロジェクトの背景などもドキュメンテーション

- **運用しながらスクリーニング**
 - 運用しながら個々のスキルを把握しスクリーニングを行う

- **クラウドソーシングエンジニアの状況把握**
 - スキルが把握できない -> 技術選定を簡単なものに寄せる
 - 時間が合わない -> コミュニケーション量を減らす
 - 稼働が読めない責任も持てない -> 大きいタスクを振らない
 - 仕様を把握していない -> やることはコードを書くように細かく書く

**※言語選定はRubyOnRailsがオススメ！ PHPだと複数のフレームワークがありパイが獲得できなくなってしまう**

**※最新の技術ではなく一般的なソリューションで伝える**

- **難易度は以下（右が難しい）**

```
右が難しい
Scaffold / View => Logic => Design
```

- **大きくタスクを振らないことに関して**
 - タスクを細かくして、なるべく複数人に作業を依頼する

![crowd.jpg](https://qiita-image-store.s3.amazonaws.com/0/93976/5031aeee-042f-7ff8-a951-12dd2f6ed4d7.jpeg)


- **慣れてきたら**
 - タスクサイズを大きくしてみる
 - 上級技術を与えてみる

***

## 強いチームをつくる技術

**楽天株式会社 及部 敬雄氏**

自己紹介：
Twitter: @takaking22

- 開発現場でよく見る問題
 - レガシーシステム
 - メンバーのスキルが低いなどなど




- **一見技術的な問題かと思いきや、コミュニケーションの問題では？**



- **チームがビジネスとの開発基盤になる　以下が3セット**
 - チーム
 - 開発
 - ビジネス


- *強いチームとは！？*
 - 変化に強い
 - チームの文化が存在する
 - 改善サイクルが回っている

- **強いチームは意識的に作る**
 - Q.誰が作る！？　　A.チームで!!
 - 誰かがやっているうちは継続しない。自転車を押すくらいのイメージ
 - 自分たちで自分たちを強くする

## [及部さんスライド](http://www.slideshare.net/TakaoOyobe/team-refactoring-dotsconf)

及部さんオススメスライド

1. [エンジニアコミュニティで組織は動き出す](http://www.slideshare.net/ssuserafaef6/ss-58412612)

***

## 組織の壁とその壊し方

**株式会社シーエー・モバイル 大八木 晋平氏**

- 自己紹介
 - 2003年サイバーエージェントで入社
 - ゲーム事業でのマネージャー兼プログラマ経験
 - サイバーエージェントのメディア事業、人事責任者
 - 現在はシーエーモバイルにて現任

- **はじめに**

**特定の個人を非難するものではなく、気づきを与えるもの**

- **会社紹介**
 - シーエー・モバイル：2000年創業
 - ガラケーからSPへ転換し、直近で過去最高業績に復活
 - エンジニア：50名強
 - プロダクト：大小多数
 - 技術環境は決してよくなかった
 - パートナーのコンテンツに守られ、技術的な変化の必要性に迫られなかった
 - 課題感があり、なんとかしたいと考えてくれている社員がたくさんいた

- **組織は生き物**

**お話しするケースについて**

サイバーエージェントのメディア組織

![cyberagent.jpg](https://qiita-image-store.s3.amazonaws.com/0/93976/95e354e4-6bea-77cb-6878-0994e4c02205.jpeg)


- **組織の壁(1)**


```
企画、開発の壁　（よくある内容で）
企画：「こんな感じでよろしく」
開発：「企画、技術理解なさすぎ」
企画：「開発、事業理解なさすぎ」
・・・
```

- **壊し方！(1)**

```
どっちが悪い、というわけではない
とにかく互いに歩み寄るための取り組みを行う
企画メンバーがDBのテーブル構造理解、SQLを書く
開発メンバーが市場の競合サービスをめちゃ知っている
技術リテラシーの高い企画者
事業リテラシーの高い技術者
技術者の評価は技術者がする
```

- **プレイヤー、マネジャーの壁(2)**

```
1.優秀なプレイヤーがリーダー兼マネージャーをやらざるをえなくなる問題
2.その結果、優秀なプレイヤーを失い、MTGエンジニアが誕生！問題
3.そんなあの人(2)を見て、ああはなりたくないと人が辞めていく問題
```

- **壊し方！(2)**

```
1.優秀なプレイヤーは優秀な組織マネージャーとは限らない
2.マネジメントは偉いわけではなく、役割の一つ
3.開発マネジメントの機能、組織マネジメントの機能
4.優秀なプレイヤーがその部署のマネージャーより給料をもらっている世界を当たり前に
5.グレード制度の改定
```

- **まとめ**

```
1.全ての壁は、ドアである
2.問題は、組織・人の数だけ存在しますが、引き出しを増やしてどんなチーム・組織もよくしている人材になっていく
```

## 懇親会！！

料理めちゃくちゃうまい＞＜
ハンバーガー、タコライス！？、ケーキ、寿司！！
そしてビールまで。。。
至れり尽くせりです

![20160228081717.jpg](https://qiita-image-store.s3.amazonaws.com/0/93976/6dcaf9cf-2b3b-3239-b25e-540a1e5f696a.jpeg)

![20160228081756.jpg](https://qiita-image-store.s3.amazonaws.com/0/93976/82e49bc2-8360-7b3b-a409-107cc9e03e89.jpeg)

![20160228081808.jpg](https://qiita-image-store.s3.amazonaws.com/0/93976/262d124a-e1af-2820-7e61-a893b42268cd.jpeg)


登壇者の方ともいろんなお話が出来、すごく満足度の高い勉強会でした


**詳しい内容は是非是非、[dots.カンファレンスに参加してください](http://eventdots.jp/contents/dots_conf_201602)！！**