Service development and Team building

A presentation at Cookpad Tech Kitchen #11 and #12
https://cookpad.connpass.com/event/64837/
https://cookpad.connpass.com/event/64844/

Transcript

1. 巨大アプリにおける 新規開発とチームビルディング Cookpad Tech Kitchen #11 & #12 
 クックパッド株式会社 サービス開発部部長 勝間 亮
2. 自己紹介 •勝間 亮（かつま りょう） ‣ ! @ryo_katsuma　 katsuma •2009.05~ Cookpad Inc. ‣ サービス開発エンジニア •2014.05~ レシピ投稿領域 マネージャー •2017.01~ サービス開発部 マネージャー
3. 今日の話
4. 今日の話 •歴史があるユーザー数も多いクックパッドアプリで、 •新規開発がとにかくムズくて課題溢れまくりの中、 •課題を整理してチームをなんとか立ち直した話。
5. 今日の流れ •開発の戦略と計画 •発生した問題 •課題の整理 •チームのリビルド •現状
6. 開発の戦略と計画
7. サービス上の課題 •投稿コミュニティの活性化 ‣ ここ数年ユーザーは順調に増加 ‣ 一方で大半はレシピをさがすユーザー
8. サービス上の課題 •レシピ投稿を活性化させる仕組みを構築できないか? ‣ 当たり前のようにみんなで今日の料理を投稿し合う ‣ 日々の料理の記録からレシピの種が生まれる
10. タイムライン •自分と親しい人、趣味嗜好が近い人の料理の記録 •検索では気にしない料理も関心が湧きやすい(はず) •場が活性化すれば投稿に対する抵抗も下がる(はず)
11. 新規サービス開発
12. 大きめの新規開発 •素直なCRUDのアプリケーションにはならなそう •バックエンドのアーキテクチャもゼロから検討 •それなりの開発規模になりそう。。
13. おおまかなマイルストーン •1月末に構想がほぼ固まった •上期(=6月末)までにはできればリリース •下期(=7月以降)に継続的な改善を実施
14. 開発上のスタンス •「目指す世界」を一通り実現できるもの ‣ フィードの表示, 投稿, リアクション, 通知 ‣ 中途半端な形だと描いてた世界が実現できるか測れない
15. 開発上のスタンス •β版をまず形にしてみる ‣ 今までにCookpadには存在しない形のもの ‣ どんな影響を起こしうるか形を見ないと分からない ‣ 自信を持って進めるためにも、動くもので確認
16. 開発上のスタンス •多めの人員配置 ‣ iOS x2, Android x2, バックエンド x2, デザイナ x3 ‣ デザイナの1人はサービス全体の体験設計のリード ‣ バックエンドの1人は開発全体のリード •立ち上げ時にこの人数は初めての規模
17. 発生した問題
18. 3月頃
19. by エンジニア “6月、今のままだと無理です”
20. by エンジニア “6月公開を目指すなら、
 βの振り返りの期間は無理です。”
21. by エンジニア “そうなると何のためのβか
 目的も不明確です。。”
22. かなり厳しい
23. 仕切り直しが必要
24. •なかなか物事が進みづらい •なのでチームの空気も良くない •ここ数年で最も「厳しい」状況であることが明確 状況を確認
25. 課題の整理
26. ２つの観点の課題 •巨大アプリならではの課題 •チーム構造の課題
27. 巨大アプリならではの課題 •大人数で「Cookpad」1アプリ開発 ‣ 好き勝手にリリースは当然できない •リリースサイクルは1月毎 ‣ キックオフ / PR締切 / コードフリーズ / QAなどが毎回 ‣ リリース後の改善リリースも1月以上後になる ‣ (当然) パフォーマンスも問題ない状態に
28. 状況 •バックエンドは実質1人(もう1人はリーダー) •バックエンドは最初から作り込みが必要 •クライアントはバックエンドに依存 •厳しい
29. チーム構造の課題 •デザイナーは十分な数がいる ‣ 完成形として高品質のプロトタイプが実現 ‣ 当初に狙っていた世界の「触れるプロトタイプ」
30. チーム構造の課題 •デザイナーはタイムラインの中でも分業制 ‣ フィードのUIそのものや仕様 / 投稿周り … etc ‣ プロトタイプは各要素もどんどんリッチに
31. 状況 •十分にリッチに発想を膨らませることができる •サービス開発に慣れているメンバーも
 「検証すべき最小の仮説は？」を考えられなくなる •エンジニアは「とにかく実現しなきゃ」の発想に •厳しい
32. チームのリビルド
33. やることを見直し •開発フェーズの再定義 •アーキテクチャ決定を早くできる体制に
34. やることを見直し •開発フェーズの再定義 •アーキテクチャ決定を早くできる体制に
35. 開発フェーズの再定義 •「いつ、どの状態を目指すの？」を完璧に合わせる •この感覚が少しでもズレるとやることが無限に膨らむ
36. http://lean-trenches.com/how-spotify-builds-products/
37. 検証したい最小の仮説は？
38. 検証したい最小の仮説 •自分と親しい人の料理の情報が流れることの影響は？ ‣ 良い影響まで出るとよいけど、そこは望まない ‣ 少なくともサービスに悪い影響が出ていない？
39. 検証に必要な最小のものは？ •表示 / 投稿 / リアクション / 通知　？
40. 検証に必要な最小のものは？ •表示 だけで良い ‣ Readだけ ‣ Write系のものは最小の仮説検証には全部不要
41. 自分たちはどこのフェーズ？
42. 今ココ
43. ここを目指す
44. 開発フェーズの再定義の結果 •「フォローされてる人の情報を表示する」だけを形に ‣ レシピやつくれぽを流すだけ ‣ 仮説検証できる最小サイズをShip itすることに集中 ‣ 投稿や通知はその後のTweak itのフェーズで実施
45. 開発フェーズの再定義の結果 •βフェーズの廃止 ‣ 表示のみのテストはWebで実施済 ‣ アプリでβテストすることの実質的な意味は無いので廃止
46. やることを見直し •開発フェーズの再定義 •アーキテクチャ決定を早くできる体制に
47. 開発の根幹 •クライアント, APIエンドポイントなど開発の根幹 ‣ インフラチームも協力 ‣ エンドポイントを開発できる人も増やす •パフォーマンステストのために必要な開発に集中 ‣ 開発項目をRead Onlyにしたのでテストのポイントも絞れた
48. アーキテクチャ決定を早めた結果 •キャパシティの見極め ‣ フォローは1000人が当面の限度 ➜ 仕様上は上限100人 •開発すべきものにより集中できる体制に ‣ テストを充実
49. それによって、
50. •全体として進み始めた ‣ やるべきことを絞ってコミュニケーションも活発化 •スケジュールがようやく現実的なものに ‣ 7月から段階的リリース 体制
51. リリース後
52. 大振り返り大会
53. 大振り返り大会 •チームの中＋他の部とも合同 •開発プロセス / レビュープロセス / テスト … etc ‣ とにかく関係者全員の思いを全部棚卸し •すぐ動けるものからどんどん導入
54. 体制変更 •1チーム ➜ 2チーム + 統括的なリーダーに分割 ‣ スモールチームの中で意志決定 • 1月に1度のリリース ➜ 2週間に1度のリリース ‣ 小回りが効く改善体制に
55. 現状
56. リリース状況 •Tweak it中 ‣ 8月: ゲストユーザー含めて全体リリース完了 ‣ 9月: リアクション, フォロー促進, 投稿のリリース ‣ 10月頭: 通知のリリース（予定） •やっと仮説が形に ‣ 今後は、継続的にどんどん改善
57. チーム状況 •自分たちで意志決定して進められる体制に ‣ 課題の定義、解決策の立案、リリース… etc •「雰囲気」も良いものに
58. サービスとしての影響 •まだまだこれから… ‣ 利用者は更なる拡大が必要 ‣ 期待する1/10ほど
59. まとめ
60. 新規開発のポイント •仮説を絞ることで検証するものをとにかく絞る •大きい構想を立てたときこそ小さく進める ‣ 油断すると、慣れていてもやることは膨らむ •自分たちの立ち位置と方向性を常に意識合わせ ‣ 最終的に狙いたいこと、今やるべきこと ‣ 少しの意識のズレが大きな問題に
61. 依存関係を考える •何より最初に解決すべきものは何か ‣ 開発上の観点 ‣ 開発サイクルの観点
62. 問題発生時は •状況を落ち着いて見極め ‣ 問題の根底になっているところは何？ •「止める」ことも躊躇しない ‣ 「ここまで進めていたから」は考えない •目線を揃えてやるべきことを集中させるのがとにかく重要
63. ご清聴ありがとうございました