$30 off During Our Annual Pro Sale. View Details »

Service development and Team building

Ryo Katsuma
September 29, 2017

Service development and Team building

Ryo Katsuma

September 29, 2017
Tweet

More Decks by Ryo Katsuma

Other Decks in Technology

Transcript

  1. 巨大アプリにおける
    新規開発とチームビルディング
    Cookpad Tech Kitchen #11 & #12

    クックパッド株式会社
    サービス開発部部長
    勝間 亮

    View Slide

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

    View Slide

  3. 今日の話

    View Slide

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

    View Slide

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

    View Slide

  6. 開発の戦略と計画

    View Slide

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

    View Slide

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

    View Slide

  9. View Slide

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

    View Slide

  11. 新規サービス開発

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

  17. 発生した問題

    View Slide

  18. 3月頃

    View Slide

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

    View Slide

  20. by エンジニア
    “6月公開を目指すなら、

    βの振り返りの期間は無理です。”

    View Slide

  21. by エンジニア
    “そうなると何のためのβか

    目的も不明確です。。”

    View Slide

  22. かなり厳しい

    View Slide

  23. 仕切り直しが必要

    View Slide

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

    View Slide

  25. 課題の整理

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

  31. 状況
    •十分にリッチに発想を膨らませることができる
    •サービス開発に慣れているメンバーも

    「検証すべき最小の仮説は?」を考えられなくなる
    •エンジニアは「とにかく実現しなきゃ」の発想に
    •厳しい

    View Slide

  32. チームのリビルド

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

  37. 検証したい最小の仮説は?

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

  41. 自分たちはどこのフェーズ?

    View Slide

  42. 今ココ

    View Slide

  43. ここを目指す

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

  49. それによって、

    View Slide

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

    View Slide

  51. リリース後

    View Slide

  52. 大振り返り大会

    View Slide

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

    View Slide

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

    View Slide

  55. 現状

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

  59. まとめ

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide