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

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

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

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

講演 #午後の部

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

Increments株式会社 東峰 裕之氏

自己紹介：

• 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

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

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

---

強いチームをつくる技術

楽天株式会社 及部 敬雄氏

自己紹介：
Twitter: @takaking22

• 開発現場でよく見る問題

• レガシーシステム

• メンバーのスキルが低いなどなど

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

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

• チーム

• 開発

• ビジネス

• 強いチームとは！？

• 変化に強い

• チームの文化が存在する

• 改善サイクルが回っている

• 強いチームは意識的に作る

• Q.誰が作る！？　　A.チームで!!

• 誰かがやっているうちは継続しない。自転車を押すくらいのイメージ

• 自分たちで自分たちを強くする

及部さんスライド

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

1. エンジニアコミュニティで組織は動き出す

---

組織の壁とその壊し方

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

• 自己紹介

• 2003年サイバーエージェントで入社

• ゲーム事業でのマネージャー兼プログラマ経験

• サイバーエージェントのメディア事業、人事責任者

• 現在はシーエーモバイルにて現任

• はじめに

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

• 会社紹介

• シーエー・モバイル：2000年創業

• ガラケーからSPへ転換し、直近で過去最高業績に復活

• エンジニア：50名強

• プロダクト：大小多数

• 技術環境は決してよくなかった

• パートナーのコンテンツに守られ、技術的な変化の必要性に迫られなかった

• 課題感があり、なんとかしたいと考えてくれている社員がたくさんいた

• 組織は生き物

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

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

• 組織の壁(1)

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

• 壊し方！(1)

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

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

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

• 壊し方！(2)

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

• まとめ

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

懇親会！！

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

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

詳しい内容は是非是非、dots.カンファレンスに参加してください！！