Ruby on Rails セミナー（クックパッド）へ行ってきたメモ

日記 アジャイル開発 ソフトウエア

what

Ruby on Rails セミナー（クックパッド）へ行ってきた。スライドのタイトルは、【５２４万人が利用する食のインフラ「クックパッド」のものづくり】

そこでのメモ。
※スライドの移動が少し早くてメモが追いつかなかった部分があります。



クックパッド概要

  • 1998年オープン
  • 目的：「毎日の料理を楽しみにする事で、心からの笑顔を増やす」
  • ４５万品のレシピ（レシピへのアクセスの仕方はロングテール。けっこうばらばらとアクセスされている。）
  • 月間ユーザ５２４万人
  • Railsの中で世界第８位
  • 月間２.８億View
  • １６時〜１８時がアクセスのピーク
  • 秋からバレンタインに向けてトラフィックが伸びる

サーバネットワーク

  • フロントサーバ（Apache2.2）８台
  • アプリケーションサーバ４４台（？だったかな・・・２２台だったかな・・・？）
  • データベースサーバ４４台
  • Ruby 1.8.6
  • Rails2.0
  • モバイル部分はjpmobile
  • PCとモバイルのコントローラは分けている
  • Mongrel1.1.5
  • Mysql 4 5
  • Caistrano（デプロイ）
  • god(mongrelの再起動)
  • nagios（監視）
  • munin（モニタリング）
  • FiveRuns Manage(モニタリング)
  • Railsの理由（2006年リニューアル時に検討した結果。ほかにあまりアジャイルを意識したフレームワークがなかったから）

パフォーマンス

キャッシュ
  • ページキャッシュをメインに実施（Apacheから返すようにしてアプリケーション以下の負荷を下げる）
    • キャッシュできない部分３つ

Ajaxの１つのリクエストでカバーしている。

クエリチューニング
スロークエリログ
デバックツール
  • FiveRuns TuneUp

DB分割

  • アクセス数よりもデータ量がパフォーマンスを低下させる

環境

DBレプリケーション

  • acts_as_readonlyable
  • データ更新後のセレクトはマスタから行う

全文検索

  • Trittonを利用（mySQLを拡張しているのでテーブルをジョインできる）
    • ２インデックス（絞り込んだ上での全文検索）

専用URL

  • 一部のユーザーは自分専用のURLを持ってる（http://kookpad.com/kem）
    • routes.rb
      • 全てのコントローラ名を検索
      • 一致しない倍に専用コントローラに渡す

全ページプレビュー機能

  • すべてのページで、任意の日付を指定して、プレビューできる。
    • Time.now を上書き

「クックパッドのものづくり」

1. つくるものを決める

重要なことは２つ。

  • Bestなことをみつける３つの輪
  • ユーザの欲求に基づいたゴール設定

Bestなことに集中する。Betterなこと、やったほうがよいことはやらない。


Bestなことをみつける３つの輪
  • やりたい（例：情熱を持って取り組める？）
  • できる（例：世界で一番になれる。得意か？）
  • やるべき（例：儲かること）

３つをすべて実現することをやる。


ユーザの欲求に基づいたゴール設定
  • eogs(emotion oriented goal setting)
    • そのサービスにかかわるキャストを立てる
    • キャスト毎の疑いようのない欲求を理解する
    • シートがクックパッド内にある
    • 欲求はかなり研究してやっている。
      • 欲求
      • なにをやれば
      • How to do
      • 成功イメージ
2. 計画する
  • スケジュールの３分割の法則
    • 設計
    • 開発
    • 質を高める


例：３週間
設計、開発、質を高める（それぞれ１週間ｊ：同じくらい重要）
１週間で開発できるように設計する
不必要なものは削り、Bestに集中する。


  • クックパッドものづくり３分割
    • 無限言実行
      • 例：公開前に、サービスやリニューアル日について説明しない（メリットがない）
      • サービスは言葉で説明できない（ユーザがしなくてよいような不安感がでる場合がある）
    • 無言語化
      • 機能を言葉で説明しない。
      • 一瞬で理解できるインターフェースじゃないと、使われない。
      • 最大２秒。２秒で理解できなかったらユーザは使わない。
      • 言葉で説明するのも無理。
      • ヘルプやFAQを見せるのはユーザに負担
      • そもそも読まれない
    • サービスには値段をつける
      • どんなサービスでもいくらかの価値があるか値段をつけて考える
      • 「無料だから大丈夫」という考えでは負ける
      • これは３０００円だしても使うなどをちゃんと考える。
      • 無料だという理由では使わない
      • お金を払ってでも使いたいサービスが無料だと使われる
      • ウェブ以外のサービスやものは価値に対して値段がついている。
      • クックパッドは当初有料サイト（月５００円）
3. 設計する（２つ）
  • サイトの設計の順番
    • 高域な設計から詳細へ
      • 用件定義、サイトマップ、繊維、ページ詳細、DB構造
      • 詳細から設計すると、機能にとらわれてしまう。
    • 設計に最低限必要なもの

「包括的なドキュメントよりも動くソフトウエアを重視する」
　これは、ドキュメントがないほうがいいという概念とはまったっく違う


  • 設計に最低限必要なもの（３つ）
    • 繊維（ページ繊維がおかしいとユーザがたどり着けない）
    • ページ詳細（紙。最低限のページ詳細）
    • DB構造
    • （大きくなれば、サイトマップも）
4. 開発する
  • 開発の３原則
    • Railに乗る

明日の自分は他人。コードが読みにくくなる。
早いRailsのバージョンアップへの対応が困難。
Railを外れそうになったらRailsの機能でできないか探す、代替がないか探す。
リファクタリングしつづけられる状態を意識する。=> テスト駆動により可能になる。現在クックパッドではここが課題。
リファクタリングを意識しないと２年が限界

    • DRY
      • 同じことを２度しない
      • railsの基本概念
      • YAGN（いずれ必要にならない）に注意
5. 質を高める
  • ユーザテスト
    • バグ発見も重要
    • ユーザにゴールを伝えて行動してもらう（実際にユーザにやってもらう）

質問などには答えない
質問が出るインターフェースは失敗
ユーザに何を考えているのか操作してもらう

    • 「かうき」の法則

ウリを伝える「顔」
ライバルに勝てる「ウリ」
売りが実感できる「効き」


開発人員

６人（デザインが出来るプログラマ・広告担当、元JAVAプログラマ、インフラ担当、UNIXユーザ会幹事、キャッシュ周り担当、スーパーインターン）


感想

ユーザが欲しいものをいかにして提供するかというところを、すごく考えている。ユーザへ提供する機能への質に妥協がない。
使っているツールも参考になる物が多く、試してみたいものがたくさんあった。解説が少し早口でスライドがどんどん進むので、メモが追いつかなかった部分があるのが少し気になった・・・。

「お金を払ってでも使いたいサービスが無料だと使われる」というのは意識していきたい。
「最大２秒。２秒で理解できなかったらユーザは使わない。」こちらも意識したい項目だった。日々の忙しさに謀殺され、どんどん機能は追加するのは良いが、これが本当にユーザが欲しい物なのか、というのをちゃんと検討しないとだめかもと思った。

「設計、開発、質を高める（同じくらい重要）」ここの意識も僕は低いので改めたい。とくに設計と質を高めるの部分。
僕も設計は開発しながらやるもの見たいな意識があったけど、「詳細を作り始めると、それがほんとにユーザが欲しい物なのか」という部分を見失いがちになる。ちゃんと設計段階でユーザの疑いようのない欲求を理解する必要があると思った。

開発体制については、再構築したいなー。