CyberZ 2016年6月8日のスキルウェンズデーでの発表

1. 成功したチームと
成功しなかったチーム
2016/06/08
CyberZ スキルウェンズデー
遠藤圭一

2. 自己紹介
独立系SIerにて携帯電話やWebサービスの開発に従
事後、2012年サイバーエージェント中途入社。
iOS/Androidエンジニアとしてコミュニティサービスの新
規立ち上げを経験。
その後、コミュニティサービスのアナリストとしてサービ
ス改善に従事。
2014年CyberZ入社。現在は、F.O.Xデータ分析及びデー
タを活用した新規機能の企画/ディレクションを担当

3. 成功？
• ここでの「成功」は開発チームが炎上や空中分解せ
ず、比較的スムーズに最後まで開発とリリースがで
きたことです（主観的）
• 本来のPJのゴールである、売上やDAUについては
また別の評価になるのでここでは触れません

4. 過去の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 失敗？ ？

5. 何でそうなった？

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

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

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

9. 1.人数？

10. 人数の多さだけではない？
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 失敗？ ？

11. 人数のメリデメ
メリット デメリット おすすめのスタイル
8 小回りがきく 休めない 困ったらすぐ集合
4〜6人 チーム分割可能 「あれそんなことしてた
の？」
誰かがチーム全体意
識しよう
７人以上
さらに
チーム分割可能
夏休み取りやすい
PM必須 PMは開発しない

12. 人数が増えても一般的
には３〜４名のチームに
わかれる

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

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

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

16. 関係ありそう
No 種別
難易度
成功？
失敗？
理由
種類
課金/決
済
大量デー
タ？
要求稼働
率
他システム連
携
1 SNS開発 BtoC ◯ ☓ 高 あり 成功
メンバ変更も少な
く安定開発
2 解析基盤 BtoB ☓ ◯ 低 あり 失敗
業務が増え人手
不足で回らない
3 ツール開発 BtoB ☓ ◯ 高 なし 成功
少人数で安定開
発
4 ツール開発 BtoB ☓ ☓ 中 あり 成功
少人数で安定開
発
5 ツール開発 BtoB ☓ ☓ 中 あり 失敗 炎上＆空中分解
6 ツール開発 BtoB ☓ ◯ 高 あり 失敗？ ？
・チーム外調整工数
・仕様コントロールできない

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

18. (ex)外部システム連携

19. データ転送の頻度、タイミング
データ・フォーマット
レスポンス内容

20. 連携先の仕様に引きづられ
る
テストや問題の切り分け困難

21. 「すぐ使えますよ」

22. 絶対に問題でます

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

24. 3.チーム内の共有?

25. 飲み会神話崩壊
No 種別
コミュニケーション
成功？
失敗？
理由
ランチ 飲み会 朝会/夕会
技術相談/
提案
要件相談
/提案
1 SNS開発 ◎ △ ◎ ◎ ◎ 成功
メンバ変更も少な
く安定開発
2 解析基盤 ◎ ☓ ☓ ◯ △ 失敗
業務が増え人手
不足で回らない
3 ツール開発 ☓ ☓ △ ◎ ◎ 成功
少人数で安定開
発
4 ツール開発 ☓ ☓ ◎ ◯ ◎ 成功
少人数で安定開
発
5 ツール開発 ☓ ☓ ◯ ◯ △ 失敗 炎上＆空中分解
6 ツール開発 ◯ ◯ ◯ ? ? 失敗？ ？

26. 技術相談？

27. アーキどうしよう

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

29. API設計

30. 要件相談？

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

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

33. 「それ絶対使わないです
よ」ってプロデューサに
言う勇気

34. (注)作るのが面倒だから言うのはNG。
ダメ絶対。
“自分が使うイメージがあるか？”
で話しましょう。
たとえ、それが難しい開発になるとしても・・・

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

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

37. うまくいったPJは

38. 何が良かったか？

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

40. 作る人が理解している
コントロールできている
精神的な余裕

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

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

43. (3)柔軟な役割分担

44. PM
・メンバを守る
・プロジェクトを守る

45. 設計/リード
・基本設計
・アーキテクチャ設計
・レビュー

46. 暇な人
・環境整備
・チーム内マスコット
・その他タスクを拾ってあげる

47. まとめ

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

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

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

51. 1.役割分担/バランス

52. 柔軟にタスクを
拾いあう

53. 「あ、それボクやっとくよ」
「カレー行こう」
「午前休、スケジュールにいれ
といたよ」

54. 2.やさしさ

55. 仕事はやさしさ

56. つエナジードリンク

57. 「一緒に考えよか」

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

59. 3.作るものへの理解

60. それ何？
用語
それ楽しいの？

61. 成功したツール開発PJでは・・・
UI、指標、仕様は３人で議論
理想を出し合って
みんな納得したら作る