Don't politic, use data. by Marissa Mayer

梅田望夫さんの本で紹介されていた言葉。
色々とjavascriptについての知識を拡大させつつ、こりゃいいかもと思える新しいポータル画面を作っても、結局はお客さんの偉い人やらの意見で、ころっと方針転換を余儀なくされることがある。特に画面というのは、目に見えやすいのでそのような機会にさらされることが多いように思う。(バックエンドのDBの構造に関して、お客さんの意見が反映されることは無い気がする。)
大きく分けて

1. 本当にその画面がダメ
2. 人の作ったものを否定することで、自分を高みに登らせる

という２パターンがあると思うけど、いずれの場合にしてもちゃんとしたデータ(ex.新しい画面にすることで、見たい番組を探すための時間がどれくらい減るか?、とか)を自分がとっていないため、1.の場合も自分が納得できる変更理由も示してもらうことができないし、2.の場合もなかなか建設的な反論もできない。そもそも、こちらから相手に対して画面の魅力をちゃんとした言葉で伝えることができていないため、否定が先にでてきてしまうのも仕方ない。
今回の仕事の大きな反省点。

ハイパフォーマンスWebサイト ―高速サイトを実現する14のルール

弾さんのブログで紹介されていたこの本にかなり興味を持って買ってみようかなーと思っていたら、概要を訳してくれていた。
http://www.inter-office.co.jp/contents/177
ほんと細かいこともあるんだけど、そこを徹底してきたからこそ、今のYahooがあるのかな。
毎回のレスポンスを0.1秒早く返すことができれば、一日１０万リクエストとしても、
0.1 * 100000 * 365 / 24 = 42.245..... 日
世界中の人がパソコンに向かう時間を42日間減らすことに成功。まあ、実際のYahooやGoogleのアクセス数は桁がまったく違うんで、その効果は恐るべしです。

Googleを支える技術 ?巨大システムの内側の世界 (WEB+DB PRESSプラスシリーズ)

を今読んでいるけど、GoogleもYahooもとにかく速さを追求するために何でもやっているんだな。（後者の本は自分の知識ではなかなか理解しきれないところもありますが。。）個人的には、両者ともにDNSの名前解決に焦点をあてているというのが印象的だった。自分の今の環境からは想像がつかない規模のでかい話ではあるけど、将来のスケールの拡大を漠然とでも意識しながらシステムを作れれば、少人数で使うシステムであっても、よりよいものができるに違いないので、ちょくちょく復習しないと。

• -

近藤社長のブログにもこんなエントリーが。
http://d.hatena.ne.jp/jkondo/20080409/1207690030