2018-12-20 エンジニアリング組織論LT大会

1. 大規模データプロダクトでの
0->1から1->100開発に向けた
チームビルディング
株式会社リクルート 鹿島 隆雄
2018/12/20 エンジニアリング組織論 LT大会

2. 自己紹介
•名前：鹿島 隆雄 @kashitaka1118
•出身：埼玉県
•趣味：キャンプ⛺
•アドベントカレンダー
• リクルートライフスタイルのがあります
• https://qiita.com/advent-calendar/2018/recru
itlifestyle

3. プロダクトについて

4. 大規模データプロダクト
•「Airメイト」
• 飲食店向け経営サジェスト
会計・商品
予約・顧客
従業員人件費

5. 今日話すこと

6. チーム拡大期の混乱にどう向き合ったか
•0->1から1->100開発へ移行する時に起きたチーム課題
•スケールするチームを作るための仕組み・ルール作り

7. ここ半年の開発実績
54
案件
34
リリース
※完了したJiraエピックベース ※APIのtag数ベース
苦労したけど結構上手くいってる。このLTを機に言語化したい

8. 0->1フェーズから1->100フェーズへ
• 0 -> 1
• プロトタイプ開発
• チーム：小規模(~5人)
• フェーズ：製品コンセプトの検証
• 1 -> 100
• プロダクト開発
• チーム：いっぱい(いま18人)
• フェーズ：事業として成り立つことがわかった後

9. 移行期に起きたこと

10. もっと人数を増やそう！
•理想：速度UP = 人数に比例して生産量UP
•現実：カオス化
• 慢性的なスケジュール遅れ
• リリース直前にマージ不能なPR
• ドキュメントや仕様の分散。何が正解？

11. 人数が増えると「よしなに…」じゃ回らない
• 0->1期：少数精鋭で「よしなに」開発
• 実装ルール
• 品質要件
• 要件の伝え方
• etc…
• 1->100期：人員が増えてスキル・認識の差が拡大

12. 新規参画者の障壁
• スキルの差
• 大規模データ集計基盤
• 新しい・難しい技術要件
• 認識の差
• 言語化されていない暗黙のルール
• 何もルールがない状態

13. 仕組み化、ルール化
と
コミュニケーション

14. 仕組み化・ルール化
• 仕組み化
• 再利用・汎化のための技術基盤(仕組み)を作る
• 目的：スキルの差を埋めて拡大再生産
• 「時を告げるのではなく、時計を作るのだ」
• ルール化
• チーム作業が円滑になるための取り決め(ルール)を作る
• 目的：コミュニケーションの齟齬防止

15. 仕組み・ルール化はシンプルに設計
•❌ 複雑な仕組み・ルール
• 認識齟齬は減るが、速度UPにならない
• 運用負荷高：覚えてられない
• 学習コスト高：メンバーに装着が難しい
•⭕ シンプルな仕組み・ルール
• すぐに説明できる
• 1回やればわかる
• 人数増に比例して速度もあげる上で大事

16. 施策：大規模データ集計基盤の汎用化
• 複雑な基盤を意識しなくてよい作り
• 開発者はYAMLとSQLだけ書いて機能を追加
• 基本的なSQLの知識で開発に参加できる仕組み

17. 施策：案件開発の共通認識作り
• 案件には1人のPMと1つのslack部屋・仕様ページ
• 全員で同じところを見るようにすると齟齬が生まれない
• 小さな単位で意思決定・合意形成できる疎結合さも大事
案件A
PM
BE
FE
iOS
Android
・・・
案件B
PM

18. 施策：リリース手順
• ボツ案
• 開発者は5営業日前にQAチームにリリース予定を連絡
• QAチームはスルーテスト可能な日を開発者に伝える
• 開発者はその日の前日までにmasterマージすること
• 採用案
• 開発者は火曜・木曜午前にmasterマージ
• QAチームは火曜・木曜午後にスルーテスト
• シンプルかつチーム間が疎結合なルール

19. 他にも色々...

20. ルール化をあきらめるケースも
• 全員が理解するイメージがわかない
• 「APIの設計ルールを決めよう！」
• →売上APIと、人件費APIがあった場合に「人件費率(人件費/売上)」はどっち？
• 30分話しても解決策が出ない・開発者全員が理解して進めるイメージがないものは
諦める
→諦めたものはどうするか

21. コミュニケーションに頼る
• ルール化しないものは人間の柔軟性に頼る
• 5〜10分話せば解決する問題が実は多い
• 振り返り「〇〇で問題が起きたのでそのルールを検討する」ではなく、コミュニケー
ションで解決できたから良しとする
• コミニュケーションの負荷が高いが速度は出る
• 会話が起こりやすい雰囲気を作る
• 朝会(月曜の朝はみんな無口なので
• チーム内LT会
• slackの#gohanチャネル
• 案件前案件の開発チームの参加

22. まとめ

23. 人数に比例して速度が上がるチームを目指す
• 仕組み化：技術の差を埋める
• ルール化：認識の差を埋める
• 運用のために仕組み・ルールはシンプルに設計
• 複雑になるくらいならコミュニケーションに頼る

24. 最後に

25. チーム設計のおもしろさ
自分の生産性を1.2倍UPするより
みんなの生産性を1.2倍UPした方が
何倍も生産量が上がる

26. ご清聴ありがとうございました
組織論でもプロダクトの話でも
交流会で知見交換しましょ〜 👋