日時: 2009年1月31日（土） 14:10～14
: 55
会場
: アクロス福岡 608会議室
スピーカー
: 橋本 健太 氏
概要
: http://www.pasonatech.co.jp/event/index.jsp?no=1085
レシピサイト、http://cookpad.com/を運営するクックパッド株式会社のCTO 橋本氏がスピーカー。実は俺クックパッド自体は使ったことない。
**まとめ
-ユーザがマニュアルやFAQを必要とするサイトは、どこかに問題がある。
-なにかを開発する際には、開発期間と同じだけの設計期間や品質チェック期間を設ける
**クックパッドについて
-1998年オープン(当初は有料サイト)
-547万人/月
-2.8億pv/月
-登録レシピ数は、47万品目
-アクセスのピークは16時から18時
Ruby on Railsで作られたサイトとしては、世界7位の規模、国内最大規模。レシピサイトとしても、世界最大規模。
**アクセス数を捌くために
DBの構造やサーバ周りについてのチューニングは必須。ページの送信にもキャッシュを有効利用する。
***キャッシュができないコンテンツもある
-ユーザ名の表示などのユーザ個別の表示
-キャッシュすることで取れなくなるアクセスログ等の取得
-掲載する広告
これらのキャッシュできないコンテンツは、Ajaxを使ってページ送出後に動的に埋め込んでいる。Ajaxも個別に呼び出すのではなく、一回のアクセスで統一して呼び出すことで負荷を軽減。
**開発環境
プログラマはMac＋Emacs(rails.el)で環境を統一。個々の導入を容易にするため
**開発手法
「”’Bestに集中する”’」。つまり「Betterなこと」、「やったほうがいいこと」は”’やらない”’。そのためには、ユーザの要求に沿った明確なゴールを設定し、それがぶれないようにするべき
ある機能やサービスに関わる役割を整理し、それぞれの役割について疑う余地のない要求を整理することが第一歩
**スケジュール3分割の法則
スケジュールを引く際には、設計期間、開発期間、品質チェック期間を設けるべき。例えば期間が3週間のプロジェクトを想定した場合、実際に開発に充てるのは1週間。その期間に開発するためには、前述のゴールを明確にする必要がある。
***設計
ユーザに提供するのは、機能やサービスではなく”’価値”’
設計の流れは以下のようになる
+要件定義
+サイトマップ
+ページ遷移
+詳細ページ
+DB設計
最低限必要なドキュメント
-ページ遷移図
-詳細ページ仕様
-DB構造
-サイトマップ(余裕があれば)
***開発
Railに乗る
: 何かを作ろうとすると、どうしてもRuby on Railsの枠からはみ出したくなることがある。そこは敢て枠からはみ出さない道を探るべき
リファクタリングを続けられるような環境を作る
: 失敗談として、初期のクックパッドでは2年を経過した段階でリファクタリングが不可能な状況に陥った
DRY、YAGNI
: 同じことは繰り返さない。今必要なBestに集中する
***品質チェック
ユーザテストは行うべき。
-ユーザに価値を提供できているか
-質問にはその場で回答しない。質問が発生する時点ですでに失敗
ものづくり3原則
*無限実行
事前にリリース予定などの告知はしない。見えないものを伝えるのは困難だし誤解を生じやすくユーザを混乱させる。事前告知の効果もはっきりしないので、しないほうがよい
***無限語化
HelpやFAQなどは準備しない。ユーザがマニュアルやFAQを必要とするサイトはどこかに問題があるので、それを解決するほうが先。ユーザが2秒で理解できないものは問題がある。
***サービスに値段をつける
Webサービスは無料で提供しているものが多いが、無料であることがサービス提供側の言い訳になる恐れがあり、クオリティが低下する。サービスに予め値段をつけることで、そういう状況を回避できる。
