How we cook cookpad.com 2016

Transcript

1. 何故 クックパッドの サービス開発の進化は 止まらないのか 庄司 嘉織 ∠

2. 庄司嘉織 yoshiori 2001 組み込み系 プログラマ 2002 Borland Conference Tokyo で発表

   2003 SI へ転職

3. 2007 Java-ja コミュニティ立ち上げ 2009 ドワンゴへ転職 Web+DB PRESS で特集1 執筆 2011

   ニコニコ静画 （電子書籍） リリース 2012 クックパッド へ転職

4. 2014 Developers Summit で発表（ベストスピーカー） Developers Summit 関西 で基調講演 2016 CEDECで発表

   イマココ ∠

5. クックパッドについて 2,450,000 cooking recipes 61,090,000 monthly unique visitors 1,850,000 PS

   user

6. 世界のクックパッド

7. 13 languages 55 countries

8. None

9. 世界一

10. 世界一巨大な モノリシック Rails サイトでもある （かも知れない） https://speakerdeck.com/a_matsuda/the-recipe-for-the-worlds-largest-rails-monolith

11. rake stats >

12. なぜ Ǹ Ruby なのか スクリプト言語としては早い方 Ȑ 多分 Java や ASP

    にすると サーバ台数半分くらいに出来る

13. コンピュータ資源を使い切りたい Ȑ 素早く価値を届けたい サーバコストを安くしたい 何を優先するか

14. 素早く価値を届けたい コレは資源の有効活用や サーバコスト削減の努力を 怠っているわけではありません。 素早く価値を届けることを最優先事項とし、 それを最大限活かせる形で コスト削減などを 日々努力しています。

15. 開発 テスト デプロイ

16. 開発の基本的な流れ 開発用ブランチを切る 追加修正をしコミット ∠ ∠

17.  開発環境には 本番のデータが 常にレプリ されている http://techlife.cookpad.com/entry/2014/10/03/110806

18. ダミーデータやテストデータでは サービスの価値はわからない データが 大量なときに 遅くなるなども 発見

19. 開発の基本的な流れ 開発用ブランチを切る 追加修正をしコミット ∠ ∠

20. Pull Request を作成し レビューしてもらう リリースブランチに マージ CI でチェック ∠

21. レビュー対象 リリース対象となるブランチにマージされる コードはすべてコードレビューされる必要が ある。ただし、簡単な文言修正や緊急度の 高いものはテストが通ればマージして良い。 レビュー時 必ず返信がほしい、もしくは修正してもらい たいものは [MUST] をつける。逆に今は修

    正しなくていいが次に弄るときは気にして おいてほしいことのような気軽なものには [nits][IMO]などをつける レビュー相手 他のチームとの連携や、専門分野外なの で識者にレビューしてもらいたいときはその 人達にも mention すること。 ȑ マージ LGTM を貰ったら自身でマージする。 また [MUST] が付いていない修正箇所は レビュー相手に再度確認を求める義務は なく自身の裁量で修正、マージして良い。

22. 機械的にチェックできるのもは 機械にチェックさせる

23. iOS, Android は dokumi 使って チェック cookpad/dokumi

24. DeployGate などへの 自動アップロードにも対応 cookpad/dokumi 実機ですぐ チェックできる デザイナや ディレクタも

25. もちろん Pull Request 毎に CI も通す

26. Pull Request を作成し レビューしてもらう リリースブランチに マージ CI でチェック ∠ ∠

27. 2,000+ 20,000+ FILES EXAMPLES ̓ MINITS cookpad/rrrspec 分散テスト実行システム

28. Pull Request を作成し レビューしてもらう リリースブランチに マージ CI でチェック ∠ ∠

29. 本番デプロイ CI が通ると Staging に 自動的にデプロイされる ので動作確認 ∠ ∠

30. sorah/mamiya 150+ hosts 13 sec 高速デプロイシステム Ȑ Ȑ Ȑ Ȑ

    Ȑ Ȑ Ȑ Ȑ

31. デプロイは開発者自身で行う 業務時間中のみデプロイ出来る デプロイはチャットでボットに言うだけ ロールバックもボットに言うだけ

32. 本番デプロイ CI が通ると Staging に 自動的にデプロイされる ので動作確認 ∠ ∠

33. 90+ 毎週約 90 個の Pull Request が 取り込まれている *クックパッド本体のみの数字です

34. 30+ 課金や認証、 ユーザーサービスなど 30 以上の アプリケーションが 動いている

35. 10+ 毎日 10 回以上 デプロイされている *クックパッド本体のみの数字です

36. 「デプロイしたら終わり」ではない

37. スタッフだけ、 特定のユーザーにだけ 開発中の機能を 簡単に 公開できる cookpad/chanko 安全に簡単に

38. ユーザーさんが ご意見、ご感想を書くためのフォームを サービスの奥に隠すのではなく すぐに書ける場所に置く フォームへの投稿は 専用のチャンネルなどに流すのではなく、 常に眼に入るように サービス担当者が 普段から使っているチャンネルに流す

39. 素早く価値を届けたい

40. 2 年半前、発表した時は dokumi も rrrspec も mamiya も無かったし チャットでデプロイも 出来なかった

41. 進化する 文化

42. 情報共有 Blog と Wiki の機能を持った社内ツールがある。 Wiki だけでなく Blog があるのでストックスべき情 報とフロー情報を分けて書ける。それが別のサービ

    スとしてあるのではなく、同じ所にあるため全員そ れを見れば良いし誰でも自分の意見を発信できる

43. 全社的に 1Password が 導入された

44. 意見交換 提案は最近は github/issues で行われる。議論と して追いやすく、後から経緯を見ることもできる。 チャットで話し始めたあとに issue に移行する場合 もある

45. 社長も創業 者もアカウント 持ってるし 使っている

46. 雑 ɔ http://techlife.cookpad.com/entry/2015/03/25/202709 決して低品質な仕事をしたり、誰かに迷惑をかけた りすることを指しているわけではありません。日頃か ら発言のハードルが低く、気軽に意見できることが 重要なのです。

47. zatsu リポジトリに 雑に issue を立て ていく

48. 昼飯や 飲みに行った時の 貸し借りも

49. 行動する ユーザーのため、会社のために正しいと思ったら 自分の意志で行動出来る。 怒る人は居ないし、助言してくれたり助けてくれる。 賛同したら一緒に動いてくれる。 Ŏ

50. Tech ブログ英語版 作ったぜ！と言ったら いろいろな人が 書き出している

51. 社外のエンジニアにも貢献すること OSS 活動、執筆や講演などの社外への貢献も評価 の軸の1つです。 そういったことが許されているとかのレベルではなく 会社がそれを望んでいます。

52. 今日ご紹介した 以外にも 多数

53. オープンである

54. 平等である Ŏ ɔ

55. 素早く価値を届けたい

56. –Grace Hopper
 http://en.wikiquote.org/wiki/Grace_Hopper “It's easier to ask forgiveness than it

    is to get permission.”
57. None
58. None