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.カンファレンスに参加してください！！