Service development and Team building

by Ryo Katsuma

Slide 1

Slide 1 text

巨大アプリにおける新規開発とチームビルディング Cookpad Tech Kitchen #11 & #12   クックパッド株式会社サービス開発部部長勝間亮

Slide 2

Slide 2 text

自己紹介 •勝間亮（かつまりょう） ‣ ! @ryo_katsuma　 katsuma •2009.05~ Cookpad Inc. ‣ サービス開発エンジニア •2014.05~ レシピ投稿領域マネージャー •2017.01~ サービス開発部マネージャー

Slide 3

Slide 3 text

今日の話

Slide 4

Slide 4 text

今日の話 •歴史があるユーザー数も多いクックパッドアプリで、 •新規開発がとにかくムズくて課題溢れまくりの中、 •課題を整理してチームをなんとか立ち直した話。

Slide 5

Slide 5 text

今日の流れ •開発の戦略と計画 •発生した問題 •課題の整理 •チームのリビルド •現状

Slide 6

Slide 6 text

開発の戦略と計画

Slide 7

Slide 7 text

サービス上の課題 •投稿コミュニティの活性化 ‣ ここ数年ユーザーは順調に増加 ‣ 一方で大半はレシピをさがすユーザー

Slide 8

Slide 8 text

サービス上の課題 •レシピ投稿を活性化させる仕組みを構築できないか? ‣ 当たり前のようにみんなで今日の料理を投稿し合う ‣ 日々の料理の記録からレシピの種が生まれる

Slide 9

Slide 9 text

No content

Slide 10

Slide 10 text

タイムライン •自分と親しい人、趣味嗜好が近い人の料理の記録 •検索では気にしない料理も関心が湧きやすい(はず) •場が活性化すれば投稿に対する抵抗も下がる(はず)

Slide 11

Slide 11 text

新規サービス開発

Slide 12

Slide 12 text

大きめの新規開発 •素直なCRUDのアプリケーションにはならなそう •バックエンドのアーキテクチャもゼロから検討 •それなりの開発規模になりそう。。

Slide 13

Slide 13 text

おおまかなマイルストーン •1月末に構想がほぼ固まった •上期(=6月末)までにはできればリリース •下期(=7月以降)に継続的な改善を実施

Slide 14

Slide 14 text

開発上のスタンス •「目指す世界」を一通り実現できるもの ‣ フィードの表示, 投稿, リアクション, 通知 ‣ 中途半端な形だと描いてた世界が実現できるか測れない

Slide 15

Slide 15 text

開発上のスタンス •β版をまず形にしてみる ‣ 今までにCookpadには存在しない形のもの ‣ どんな影響を起こしうるか形を見ないと分からない ‣ 自信を持って進めるためにも、動くもので確認

Slide 16

Slide 16 text

開発上のスタンス •多めの人員配置 ‣ iOS x2, Android x2, バックエンド x2, デザイナ x3 ‣ デザイナの1人はサービス全体の体験設計のリード ‣ バックエンドの1人は開発全体のリード •立ち上げ時にこの人数は初めての規模

Slide 17

Slide 17 text

発生した問題

Slide 18

Slide 18 text

3月頃

Slide 19

Slide 19 text

by エンジニア “6月、今のままだと無理です”

Slide 20

Slide 20 text

by エンジニア “6月公開を目指すなら、  βの振り返りの期間は無理です。”

Slide 21

Slide 21 text

by エンジニア “そうなると何のためのβか  目的も不明確です。。”

Slide 22

Slide 22 text

かなり厳しい

Slide 23

Slide 23 text

仕切り直しが必要

Slide 24

Slide 24 text

•なかなか物事が進みづらい •なのでチームの空気も良くない •ここ数年で最も「厳しい」状況であることが明確状況を確認

Slide 25

Slide 25 text

課題の整理

Slide 26

Slide 26 text

２つの観点の課題 •巨大アプリならではの課題 •チーム構造の課題

Slide 27

Slide 27 text

巨大アプリならではの課題 •大人数で「Cookpad」1アプリ開発 ‣ 好き勝手にリリースは当然できない •リリースサイクルは1月毎 ‣ キックオフ / PR締切 / コードフリーズ / QAなどが毎回 ‣ リリース後の改善リリースも1月以上後になる ‣ (当然) パフォーマンスも問題ない状態に

Slide 28

Slide 28 text

状況 •バックエンドは実質1人(もう1人はリーダー) •バックエンドは最初から作り込みが必要 •クライアントはバックエンドに依存 •厳しい

Slide 29

Slide 29 text

チーム構造の課題 •デザイナーは十分な数がいる ‣ 完成形として高品質のプロトタイプが実現 ‣ 当初に狙っていた世界の「触れるプロトタイプ」

Slide 30

Slide 30 text

チーム構造の課題 •デザイナーはタイムラインの中でも分業制 ‣ フィードのUIそのものや仕様 / 投稿周り … etc ‣ プロトタイプは各要素もどんどんリッチに

Slide 31

Slide 31 text

状況 •十分にリッチに発想を膨らませることができる •サービス開発に慣れているメンバーも  「検証すべき最小の仮説は？」を考えられなくなる •エンジニアは「とにかく実現しなきゃ」の発想に •厳しい

Slide 32

Slide 32 text

チームのリビルド

Slide 33

Slide 33 text

やることを見直し •開発フェーズの再定義 •アーキテクチャ決定を早くできる体制に

Slide 34

Slide 34 text

やることを見直し •開発フェーズの再定義 •アーキテクチャ決定を早くできる体制に

Slide 35

Slide 35 text

開発フェーズの再定義 •「いつ、どの状態を目指すの？」を完璧に合わせる •この感覚が少しでもズレるとやることが無限に膨らむ

Slide 36

Slide 36 text

http://lean-trenches.com/how-spotify-builds-products/

Slide 37

Slide 37 text

検証したい最小の仮説は？

Slide 38

Slide 38 text

検証したい最小の仮説 •自分と親しい人の料理の情報が流れることの影響は？ ‣ 良い影響まで出るとよいけど、そこは望まない ‣ 少なくともサービスに悪い影響が出ていない？

Slide 39

Slide 39 text

検証に必要な最小のものは？ •表示 / 投稿 / リアクション / 通知　？

Slide 40

Slide 40 text

検証に必要な最小のものは？ •表示だけで良い ‣ Readだけ ‣ Write系のものは最小の仮説検証には全部不要

Slide 41

Slide 41 text

自分たちはどこのフェーズ？

Slide 42

Slide 42 text

今ココ

Slide 43

Slide 43 text

ここを目指す

Slide 44

Slide 44 text

開発フェーズの再定義の結果 •「フォローされてる人の情報を表示する」だけを形に ‣ レシピやつくれぽを流すだけ ‣ 仮説検証できる最小サイズをShip itすることに集中 ‣ 投稿や通知はその後のTweak itのフェーズで実施

Slide 45

Slide 45 text

開発フェーズの再定義の結果 •βフェーズの廃止 ‣ 表示のみのテストはWebで実施済 ‣ アプリでβテストすることの実質的な意味は無いので廃止

Slide 46

Slide 46 text

やることを見直し •開発フェーズの再定義 •アーキテクチャ決定を早くできる体制に

Slide 47

Slide 47 text

開発の根幹 •クライアント, APIエンドポイントなど開発の根幹 ‣ インフラチームも協力 ‣ エンドポイントを開発できる人も増やす •パフォーマンステストのために必要な開発に集中 ‣ 開発項目をRead Onlyにしたのでテストのポイントも絞れた

Slide 48

Slide 48 text

アーキテクチャ決定を早めた結果 •キャパシティの見極め ‣ フォローは1000人が当面の限度 ➜ 仕様上は上限100人 •開発すべきものにより集中できる体制に ‣ テストを充実

Slide 49

Slide 49 text

それによって、

Slide 50

Slide 50 text

•全体として進み始めた ‣ やるべきことを絞ってコミュニケーションも活発化 •スケジュールがようやく現実的なものに ‣ 7月から段階的リリース体制

Slide 51

Slide 51 text

リリース後

Slide 52

Slide 52 text

大振り返り大会

Slide 53

Slide 53 text

大振り返り大会 •チームの中＋他の部とも合同 •開発プロセス / レビュープロセス / テスト … etc ‣ とにかく関係者全員の思いを全部棚卸し •すぐ動けるものからどんどん導入

Slide 54

Slide 54 text

体制変更 •1チーム ➜ 2チーム + 統括的なリーダーに分割 ‣ スモールチームの中で意志決定 • 1月に1度のリリース ➜ 2週間に1度のリリース ‣ 小回りが効く改善体制に

Slide 55

Slide 55 text

現状

Slide 56

Slide 56 text

リリース状況 •Tweak it中 ‣ 8月: ゲストユーザー含めて全体リリース完了 ‣ 9月: リアクション, フォロー促進, 投稿のリリース ‣ 10月頭: 通知のリリース（予定） •やっと仮説が形に ‣ 今後は、継続的にどんどん改善

Slide 57

Slide 57 text

チーム状況 •自分たちで意志決定して進められる体制に ‣ 課題の定義、解決策の立案、リリース… etc •「雰囲気」も良いものに

Slide 58

Slide 58 text

サービスとしての影響 •まだまだこれから… ‣ 利用者は更なる拡大が必要 ‣ 期待する1/10ほど

Slide 59

Slide 59 text

まとめ

Slide 60

Slide 60 text

新規開発のポイント •仮説を絞ることで検証するものをとにかく絞る •大きい構想を立てたときこそ小さく進める ‣ 油断すると、慣れていてもやることは膨らむ •自分たちの立ち位置と方向性を常に意識合わせ ‣ 最終的に狙いたいこと、今やるべきこと ‣ 少しの意識のズレが大きな問題に

Slide 61

Slide 61 text

依存関係を考える •何より最初に解決すべきものは何か ‣ 開発上の観点 ‣ 開発サイクルの観点

Slide 62

Slide 62 text

問題発生時は •状況を落ち着いて見極め ‣ 問題の根底になっているところは何？ •「止める」ことも躊躇しない ‣ 「ここまで進めていたから」は考えない •目線を揃えてやるべきことを集中させるのがとにかく重要

Slide 63

Slide 63 text

ご清聴ありがとうございました