Ruby on Rails セミナーに参加してきました

クックパッドさん主催のRuby on Railsセミナーに参加してきました。Railsは仕事では利用していないのですが、CakePHPなんかはRailsと似たところがあるし、スケーリングの話なんかは参考になるところもあるかな、と思い参加。CTOの橋本健太さんのトークのみ、という内容だったのですがRailsに留まらない「クックパッドとしてのものづくりに対する考え方」は非常に興味深い内容がふんだんでした。以下、そのメモです。（誤字とかRails系の用語は間違っているものもあるかも、、）

クックパッド

• 毎日の料理を楽しみにすることで心からの笑顔を増やす
• これだけやる！
• 世界で一番！生活に役立つサイト作り
• 月刊ユーザ524万人
• 四国の人口よりおおい！
• 20,30代女性中心
• 20代は４人に１人が見てる！
•  Railsサイト中世界８位（ユーザ数）
• 月刊PV2.8億
• PV的にはRailsサイトで世界３位
• 16-18 時がアクセスがピーク
• 秋からバレンタインにかけてトラフィックがのびる

構成

• apache x8
• app x44
• db x13

• apache 2.2.3
• rails 2.0
• mongrel 1.1.5/mongrel_1.0.5
• mysql 5.0.45
• tritton(未来検索ブラジルの全文検索エンジン)
• capistrano(デプロイ)
• god（mongrelの再起動）
• nagios(リアルタイム監視)
• Fiveruns Manage(モニタリング)

パフォーマンス

• キャッシュ
• mongrelをとおすだけで10ms
• ページキャッシュをメインに実装中
• ページキャッシュできない
• ユーザごとにことなる表示
• アクセスログ
• 広告
• これらはAjaxの１リクエストでうめこんでる
• クエリチューニング
• FiveRuns Tuneup
• どんなクエリを発行したのか、が１クリックでわかる
• DB分割
• 最初
• app 2GB
• app 2GB
• slave 8GB
• 検索 4GB
• 検索DBをslave dbに統合
• app 2GB
• app 2GB
• slave 12GB
• OSのキャッシュにテーブルファイルがのりきるかが重要   
• アクセス数よりもデータ量がパフォーマンスを低下させる

ノウハウ

• 開発者は全員Mac
• Emacs
• rails.el
• Subversion, trac
• Shinjiko
• Mondorianのクローンのコードレビューシステム
• DBのレプリケーション
• マスター、スレーブの切り替え
• acts_as_readonlyable を使用
• データ更新後のselectはマスターから
• 全文検索
• Trittonを使用（未来検索ブラジル）
• MySQLを拡張
• テーブルをJoin できる
• 2 index
• index を貼ったテーブルのファイルをそのまま
• 専用URL
• 一部のユーザは専用のURLをもつ
• （例）cookpad.com/kem
• routes.db
• すべてのコントローラ名を検索
• 一致しない場合に専用のコントローラに渡している
• 普通にファイル探索してコードかいてる
• 全ページのプレビュー機能
• x 月x比x時からx時のみ公開　などの場合
• すべてのページで任意の日付を指定してプレビュー
• Time.nowを上書き
• /?current_time=2008-10-11
• アクセス制限はかけてる

ものづくり

• つくるものをきめる
• Bestなことに集中する
• Betterなこと、やったほうがいいこと、はやらない
• Bestなことを見つけるまでのの３つの輪
• やりたい（情熱を持ってとりくめること）
• できる（世界で１番になれること）
• やるべきこと（儲かること）
• ユーザの欲求に基づいたゴール設計
• EOGS(Emotion Oriented Goal Setting)
• そのサービスに関わるキャストを立てる
• キャストごとの疑いようのない欲求を理解する
• 解決方法を探す
• 疑いようのない欲求
• 何をすれば？
• How to do? / action
• 指標
• 計画する
• スケジュールの３分割の法則
• サービス完成までの時間にやるべきこと
• 設計
• 開発
• 質をたかめる
• これらに同じだけの時間をかける
• ３週間後にサービスインするならば
• 設計１
• 開発１
• 質をたかめる　１
• １週間の開発でできるように設計する
• 不必要な機能は削りBestに集中する
• 設計にも１週間かける
• 調査も入る
• クックパッドものづくり３原則
• 無限実行無言実行（2008/11/21 11:00修正）
• 公開前にサービスについての説明をしない
• リューアルします！　なんかも言わない
• サービスを言葉で説明することはできない
• ユーザさんにしなくていい不安感を抱かしてしまう
• 公開前に告知するメリットはない
• 無言語化
• 機能を言葉で説明しない
• 一瞬で理解できるインターフェースじゃないと使われない
• 最大２秒
• ヘルプやFAQを読ませるのはユーザに負担
• そもそも読まれない
• サービスに値段をつける
• どんなサービスでもいくらの価値があるか値段をつけて考える
• 無料だから大丈夫、という考えでは負ける
• 無料だというだけの理由では使われない
• お金を払ってでも使いたいサービスは無料だと使われる
• ウェブ以外のサービスやものは価値に大して値段がついている
• クックパッドは当初は有料サイト
• 設計する
• サイトの設計の順番
• 広域な設計から詳細へ
• 詳細から設計すると機能にとらわれる
• ユーザに届けるべきものは機能ではなく価値
• 設計に最低限必要なもの
• アジャイル宣言の一節
• 包括的なドキュメントよりも動くソフトウェアを重視する
• これはドキュメンドがないほうがいい、という概念とは全く違う
• 最低限必要なドキュメントとは？
• 遷移
• どんなによくできたページでも遷移がおかしいとユーザは目的の行動をできない
•  ページ詳細
• 紙でかいたものでOK
• 構造をメモ
• 紙の真ん中のデザインをかいて左右に空白をあけておくと書き込みしやすくてオススメ！
• DB構造
• サイトマップ
• 規模の大きな開発の場合
• 開発する
•     開発の３原則
• Railに乗る
• Railを外れると
• 明日の自分は他人。コードが読みにくくなる。
• 早いRailsのバージョンアップへの対応が困難
• Railを外れそうになったら
• Railの機能でできないかさがしてみる
• Railをはずれない代替案がないかさがしてみる
• リファクタリングしつづけられる状態をたもつ
• テスト駆動により可能になる
• 現在のクックパッドはここが課題
• 2006年にリニューアルしたコードは２年で拡張が不可能に
• DRY
• 同じことを２度しない
• YAGNI You Are not Going Need Itに注意
• いずれ必要にならない
• 質をたかめる
• ユーザテスト
• ユーザテストにおいてはバグの発見よりも、ユーざにねらった価値を提供できているかをテスト
• ユーザにゴールを伝えて行動してもらう
• 質問などには答えない
• 質問がでる遷移、インターフェースは失敗
• ユーザが自分が何をかんがえているか話しながら操作してみる
• 顔マーケティング
• 「かうき」の法則
• ウリをつたえる　顔
• ライバルにかてる　ウリ
• ウリが実感できる　効き

まとめ

Railsの細かな話は分かりませんでしたが、クックパッドさんのものづくりに対する姿勢は他社と比べてもかなり特徴的だと思います。実装内容の検討について「設計、実装、QAに費やす時間が自動的に決定されるので（そういうルールなので）そこから逆算される実装可能なボリュームだけ実装を行い、そのボリュームを設計する」という時間配分ドリブン？な考え方は結構ユニークだけど合理的。ユーザ試験の方法やBestなことに集中する姿勢などを見ても、合理的に行うにはどうすればいいか？に拘っているように感じ取れました。これを機に、自分たちの開発スタイルにもクックパッドスタイルで取り入れられそうなものが無いか、じっくり考えてみたいと思います。