何故クックパッドのサービス開発は日々進化しているのか@デブサミ2014（DevelopersSummit2014）

2/13(木)、14(火) に目黒の雅叙園で開催された「Developers Summit 2014」の参加レポート#6です。

何故クックパッドのサービス開発は日々進化しているのか（庄司 嘉織 〔クックパッド〕）

クックパッドのサービス開発部、Happy Author部の部長である庄司さんによる、クックパッドのサービス開発における

• 体制やマインド
• デプロイ時のルール
• エンジニア以外との絡み方（コミュニケーション・コラボレーション）

などについての非常に、非常にためになるセッション。

cookpad.com の技術基盤と規模

• 技術基盤

  • Ruby 2.0
  • Rails 3.2 （現在4.0？へ移行作業中とのこと）

• 規模（2014/02/13 時点）

日時	model	controller	view	route	asset	example
2013/10/31	1,082	318	3,304	2,127	3,946	-
2014/02/13	1,136	358	3,530	2,718	4,135	16,108

4ヶ月弱でかなり増えてますね。というお話。 この規模のアプリケーションを運用しながら、「1日約10回のデプロイ」を続けている。

cookpadのエンジニア体制

• インフラストラクチャ部：5名
  • DevOpsの"Ops"側
  • 詳しくは 迷ったら健全な方
• サービス開発部（サービスを開発するエンジニア）：40名超
  • DevOpsの"Dev"側
  • 庄司さんの部署
  • ものづくりの考え方については ユーザを向いたものづくり
• 技術部：10名超
  • テスト基盤やデプロイ基盤、開発基盤などを整備するエンジニア
  • 技術的な目標（CIã‚’10分以内に終わらせるとか）がある

本題から外れますが、@mirakuiこと成田さんの「迷ったら健全な方」は去年のDevOpsDays Tokyoで聞いていたのですが、本当に良い発表で、個人的には去年1年間でベストな発表だったのでは無いかと思います。まだ見ていない方はぜひ御覧ください。

サービス開発（今回の本題）

• chanko

  • 新機能のプロトタイプを安全に行うためのRailsプラグイン
  • ユーザを限定して公開してプロトタイプのテストを行う
  • 限定公開側がエラーでコケたら、一般バージョンを表示する仕様になっている（よく考えられていますね）

• masterへのマージ

  • マージはコードレビューが通った上で、本人が実施
  • レビューは有識者やチームに向けて適宜行う

• デプロイ

  • CIを通ったリビジョンのみ、デプロイ可能
  • 全開発者が手元でデプロイ可能
  • 時間帯は9:30-17:00 休前日は無し（ルールがあった方が良い）
  • ロールバック、デプロイロックも開発者が手元から行う
    • デプロイロックはインフラから「お願いベース」で来る（権威的にならずにDevOps的に）

• DevOps？

  • 社内ではDevOpsという言葉はほぼ意識していない
  • もともとやっていたことに後から名前がついたような感覚

• DB関連もNW設定変更もGithub

  • 開発環境で出来たテーブルからスクリプトを自動生成してPull Request
  • 後の定義変更やインデックス追加もPull Requestで実施

• 設計もGithub

  • 設計中の議論・経緯が一目瞭然
  • Pull Request内容とのヒモ付もラク
  • 残タスクもGithub記法でわかりやすい

• デザイナーもGithub

  • 開発中画面のデザインを依頼すると、「ブランチ教えて」→「Pull Request送っておいたよ」（デザイナが開発者のブランチをCloneして、デザインを入れてPull Requestしてくれる）

• ユーザサポートもGithub

  • GithubにIssueチケットが切られるとhipchatに通知されるので、エンジニアが見逃さない
  • ユーザサポートメンバーが画像を添付してくれたり、Markdownを書いてくれる（スゴい）
  • もともとは違うチケット管理システムを使用していたが、Githubに移行した
  • ユーザサポートメンバー分のアカウントを確保→ユーザサポートチームに説明（1時間程度）だけで運用が変えられる
  • 「この人達に使いこなせるかな」と考えるのは逆に失礼

• 社員ひとりひとりにユーザがいるという意識

  • バックオフィス（管理部とか）は社員がユーザ
  • 技術部社員は社内のエンジニアがユーザ
  • サービス開発、インフラはエンドユーザがユーザ
  • ユーザを幸せにするために常に正しいと思うことを積極的に行う

• エンジニアに求められていること

  • クックパッドのエンジニアは社外の開発者に貢献することが求められている
  • 発表資料、OSS活動など
  • 会社がしてほしいと推奨している
  • 業務時間にOSSで作ったプロダクトは個人名で公開する

• Cookpadの文化

  • 情報共有（wikiとblogが統合されたツール）←いつかのWEB+DBに書いてあった「Groupad」のことですね
  • なるべくルールを作らずに運用する（ルールにしない）
  • 正しいと思ったら行動する

• まとめ

  • 安定したサービスを
  • 速度を維持しながら
  • 文化を育てる
  • "文化を共有し信頼し実行"

• 所感

庄司さんのお話がうまいこともあるのですが、やはり内容が素晴らしいと思いました。クックパッドのエンジニアの発表は、もう何度も聞いていますが毎回どこかに驚かされる部分があります。今回は「エンジニアもGithub」「ユーザサポートもGithub」の件ですね。デザイナがPull Requestしてくれるとか、ユーザサポートメンバーがMarkdownとか、異世界すぎます。

また、勝間さんの「ユーザを向いたものづくり」は今回はじめて知ったのですが、これも素晴らしい資料ですね。「リーン・スタートアップ」を理解していないと会話にならない。最近の成長企業もリーン・スタートアップのMVPをベースにした考えをよく聞きますが、「全員が理解している」という現場は今回はじめて聞きました。ユーザに対する姿勢が素晴らし過ぎます。

一休では非エンジニアに対してPull Requestなどを求めるという文化が無いのですが、「文化を作る」という意識を持って改善に取り組めば、だんだんとクックパッドのようなスタイルに近づけることができるのでは無いかと考えています。「やり方変えてみない」とカジュアルに取り組んでいくことが大切ではないかと思います。

今回もクックパッドの見習う点を積極的に取り入れていこうと思ったデブサミ1日目最後のセッションでした。