dots.カンファレンス チーム開発を支える技術に参加したよー 午後の部
dots.カンファレンス チーム開発を支える技術に参加したよー 午後の部
dots.カンファレンス、チーム開発を支える技術に参加してきました！
午前の部、午後の部、と別れており今回は午後の部の紹介をしていきます。
※私の範囲内で聞いて咀嚼したものですので、内容に相違がある可能性があります。
講演 #午後の部
Qiita/Qiita:Teamの開発を通して見つけた、Incrementsの文化を作る方法
Increments株式会社 東峰 裕之氏
自己紹介：
Incrementsってどんな会社？ 書き方は「++」で言語のインクリメントを表している
ビジョン：ソフトウァア開発を良くすることで、世界の進化を加速させる
立ち上げ３名、メンバーは14名！？
- Running Leanを実践
- 何を作るかより、何を作らないか
- MVPで検証し、すぐ捨てる
無駄な作り込みは悪！
価値仮設シートの実行
- (ユーザー)＿＿＿は、
- (欲求)＿＿＿＿たいが、
- (課題)＿＿＿なので、
(製品の特徴)＿＿＿に価値がある。 ※cookpadさんのものを踏襲し実行
属人性の排除について
- 情報共有をTeamlでシェア
Teamlで書いてあれば誰でも実行可能
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.チームで!!
- 誰かがやっているうちは継続しない。自転車を押すくらいのイメージ
- 自分たちで自分たちを強くする
及部さんスライド
及部さんオススメスライド
組織の壁とその壊し方
- 自己紹介
- 2003年サイバーエージェントで入社
- ゲーム事業でのマネージャー兼プログラマ経験
- サイバーエージェントのメディア事業、人事責任者
現在はシーエーモバイルにて現任
はじめに
特定の個人を非難するものではなく、気づきを与えるもの
- 会社紹介
- シーエー・モバイル：2000年創業
- ガラケーからSPへ転換し、直近で過去最高業績に復活
- エンジニア：50名強
- プロダクト：大小多数
- 技術環境は決してよくなかった
- パートナーのコンテンツに守られ、技術的な変化の必要性に迫られなかった
課題感があり、なんとかしたいと考えてくれている社員がたくさんいた
組織は生き物
お話しするケースについて
サイバーエージェントのメディア組織
- 組織の壁(1)
企画、開発の壁 （よくある内容で） 企画：「こんな感じでよろしく」 開発：「企画、技術理解なさすぎ」 企画：「開発、事業理解なさすぎ」 ・・・
- 壊し方！(1)
どっちが悪い、というわけではない とにかく互いに歩み寄るための取り組みを行う 企画メンバーがDBのテーブル構造理解、SQLを書く 開発メンバーが市場の競合サービスをめちゃ知っている 技術リテラシーの高い企画者 事業リテラシーの高い技術者 技術者の評価は技術者がする
- プレイヤー、マネジャーの壁(2)
1.優秀なプレイヤーがリーダー兼マネージャーをやらざるをえなくなる問題 2.その結果、優秀なプレイヤーを失い、MTGエンジニアが誕生！問題 3.そんなあの人(2)を見て、ああはなりたくないと人が辞めていく問題
- 壊し方！(2)
1.優秀なプレイヤーは優秀な組織マネージャーとは限らない 2.マネジメントは偉いわけではなく、役割の一つ 3.開発マネジメントの機能、組織マネジメントの機能 4.優秀なプレイヤーがその部署のマネージャーより給料をもらっている世界を当たり前に 5.グレード制度の改定
- まとめ
1.全ての壁は、ドアである 2.問題は、組織・人の数だけ存在しますが、引き出しを増やしてどんなチーム・組織もよくしている人材になっていく
懇親会！！
料理めちゃくちゃうまい＞＜ ハンバーガー、タコライス！？、ケーキ、寿司！！ そしてビールまで。。。 至れり尽くせりです
登壇者の方ともいろんなお話が出来、すごく満足度の高い勉強会でした
詳しい内容は是非是非、dots.カンファレンスに参加してください！！
