成功したチームと成功しなかったチーム 20160608

成功したチームと 成功しなかったチーム

2016/06/08 CyberZ　スキルウェンズデー

遠藤圭一

自己紹介

独立系SIerにて携帯電話やWebサービスの開発に従事後、2012年サイバーエージェント中途入社。

iOS/Androidエンジニアとしてコミュニティサービスの新規立ち上げを経験。

その後、コミュニティサービスのアナリストとしてサービス改善に従事。

2014年CyberZ入社。現在は、F.O.Xデータ分析及びデータを活用した新規機能の企画/ディレクションを担当

成功？

• ここでの「成功」は開発チームが炎上や空中分解せず、比較的スムーズに最後まで開発とリリースができたことです（主観的）

• 本来のPJのゴールである、売上やDAUについてはまた別の評価になるのでここでは触れません

過去のPJを評価してみた

No 種別

メンバ構成成功？ 失敗？

理由プロデューサー

フロント サーバ ネイティブ 合計

1 SNS開発 1 3 4 2 10 成功メンバ変更も少な

く安定開発

2 解析基盤 0 0 3 - 3 失敗業務が増え人手不足で回らない

3 ツール開発 0 1 2 - 3 成功少人数で安定開

発

4 ツール開発 1 1 1 - 3 成功少人数で安定開

発

5 ツール開発 1 2 3 - 6 失敗 炎上＆空中分解

6 ツール開発 ？ 3 5 2 10 失敗？ ？

何でそうなった？

ロジスティック回帰分析で分析

被説明変数　1:成功 0:失敗 説明変数　　メンバ数 　　　　　　難易度 　　　　　　開発期間 　　　　　　言語 　　　　　　フレームワーク

時間無かったので 無理でした

1.人数？

人数の多さだけではない？

No 種別

メンバ構成成功？ 失敗？

理由プロデューサー

フロント サーバ ネイティブ 合計

1 SNS開発 1 3 4 2 10 成功メンバ変更も少な

く安定開発

2 解析基盤 0 0 3 - 3 失敗業務が増え人手不足で回らない

3 ツール開発 0 1 2 - 3 成功少人数で安定開

発

4 ツール開発 1 1 1 - 3 成功少人数で安定開

発

5 ツール開発 1 2 3 - 6 失敗 炎上＆空中分解

6 ツール開発 ？ 3 5 2 10 失敗？ ？

人数のメリデメ

メリット デメリット おすすめのスタイル

8 小回りがきく 休めない 困ったらすぐ集合

4〜6人 チーム分割可能 「あれそんなことしてたの？」

誰かがチーム全体意識しよう

７人以上

さらに チーム分割可能

夏休み取りやすい PM必須 PMは開発しない

人数が増えても一般的には３〜４名のチームに

わかれる

要件に対してキャパシティがあるかどうか

キャパシティ超えた開発はできない

2.システム要件や開発要件の難しさ?

関係ありそう

No 種別

難易度成功？ 失敗？

理由

種類課金/決

済大量デー

タ？要求稼働

率他システム連

携

1 SNS開発 BtoC ◯ ☓ 高 あり 成功メンバ変更も少な

く安定開発

2 解析基盤 BtoB ☓ ◯ 低 あり 失敗業務が増え人手不足で回らない

3 ツール開発 BtoB ☓ ◯ 高 なし 成功少人数で安定開

発

4 ツール開発 BtoB ☓ ☓ 中 あり 成功少人数で安定開

発

5 ツール開発 BtoB ☓ ☓ 中 あり 失敗 炎上＆空中分解

6 ツール開発 BtoB ☓ ◯ 高 あり 失敗？ ？

・チーム外調整工数 ・仕様コントロールできない

コントロールできない領域

(ex)外部システム連携

データ転送の頻度、タイミング データ・フォーマット

レスポンス内容

連携先の仕様に引きづられる

テストや問題の切り分け困難

「すぐ使えますよ」

絶対に問題でます

検証期間をちゃんととりましょう

3.チーム内の共有?

飲み会神話崩壊

No 種別

コミュニケーション成功？ 失敗？

理由

ランチ 飲み会 朝会/夕会技術相談/

提案要件相談

/提案

1 SNS開発 ◎ △ ◎ ◎ ◎ 成功メンバ変更も少な

く安定開発

2 解析基盤 ◎ ☓ ☓ ◯ △ 失敗業務が増え人手不足で回らない

3 ツール開発 ☓ ☓ △ ◎ ◎ 成功少人数で安定開

発

4 ツール開発 ☓ ☓ ◎ ◯ ◎ 成功少人数で安定開

発

5 ツール開発 ☓ ☓ ◯ ◯ △ 失敗 炎上＆空中分解

6 ツール開発 ◯ ◯ ◯ ? ? 失敗？ ？

技術相談？

アーキどうしよう

フレームワークどうしよう

API設計

要件相談？

これってユーザはどんな目的で使うの？

これを作ることはどんな価値があるの？

「それ絶対使わないですよ」ってプロデューサに

言う勇気

(注)作るのが面倒だから言うのはNG。 ダメ絶対。

“自分が使うイメージがあるか？” で話しましょう。

たとえ、それが難しい開発になるとしても・・・

作るものを理解しないといいものはできない

イメージできないものは作れない

うまくいったPJは

何が良かったか？

(1)エンジニア主体で 機能提案や開発

作る人が理解している コントロールできている

精神的な余裕

(2)リリース前の おさわりタイム

自分が作ったものがちゃんと動いているか面白

いかの確認

(3)柔軟な役割分担

PM ・メンバを守る

・プロジェクトを守る

設計/リード ・基本設計

・アーキテクチャ設計 ・レビュー

暇な人 ・環境整備

・チーム内マスコット ・その他タスクを拾ってあげる

まとめ

よいチームがビジネス的に成功するわけでは

ない

優秀なエンジニアがいるから成功するわけでもな

い

でもいいチームで仕事したいよね？

1.役割分担/バランス

柔軟にタスクを 拾いあう

「あ、それボクやっとくよ」 「カレー行こう」

「午前休、スケジュールにいれといたよ」

2.やさしさ

仕事はやさしさ

つエナジードリンク

「一緒に考えよか」

「１５分考えてわかんないから、話し相手になっ

て」

3.作るものへの理解

それ何？ 用語

それ楽しいの？

成功したツール開発PJでは・・・ UI、指標、仕様は３人で議論

理想を出し合って みんな納得したら作る