■ 「Web開発者のための大規模サービス技術入門」という本を書きました

自分が作ったWebサービス、将来大きくなってもシステムは大丈夫なんだろうか? そんな不安を抱きながらWebサービス開発に携わっている方も多いでしょう。あるいは、毎日毎日システムが悲鳴を上げる、どうしたらこの状況を看破できるんだろう? 成長したWebサービスを前に、困っている技術者の方もいるかもしれません。

筆者も、まったく同じ経験をしてきました。

月間1,500万人が訪れる、はてなというサイト。その大規模システムの開発と運用に、筆者らは取り組んでいます。1,000台のホストが、その負荷を捌きます。100万人以上のユーザによってブログやソーシャルブックマークに投稿され続けるデータは日々大きくなっていき、サーバリソースを逼迫させます。ギガバイト、テラバイト単位のデータ量が技術者たちを悩ませます。それでもトラフィックの波は収まることを知りません。

(中略)

どうしたらこの怪物、大規模サービスを抑え込むことができるのか。試行錯誤の連続の末、はてなの技術者である我々が手に入れた技術とノウハウ―すなわち大規模サービス技術の地図とコンパス―が本書にはあります。

Web開発者のための大規模サービス技術入門 ― p.iii 「本書について」より

昨年のインターンシップ開催時に、技術評論社の土井さんに取材に来ていただきました。はてなでは、インターンシップで学生と一緒に仕事をするにあたり、大規模サービス開発の勘所を抑えてもらうために10日程度の教育期間を設けるという、少し変わったやり方を採用しています。その講義への取材でした。

このカリキュラムを、書籍にできないか。そう思ったのは、初めてのインターンシップでその成果を実感したときでした。数日後には目の前にいる学生さんたちと一緒にシステム開発を始めなければいけない。限られた期間で結果を出す必要がある。そのためには、現場感から来る必要な知識とノウハウを凝縮して伝えなければいけない。そのモチベーションからまとまった知識はインターンシップに留まらず、Web技術者全般にとって有益なのではないか。これを整理し公開することで、あわよくば、Web開発技術レベルの底上げに少しは貢献できるのではないか。そんなことを考えていました。

こうして、取材記録を整理し、大規模Webサービス開発という視点で書き下ろし、編集したのが本書です。結果として、負荷分散にまつわるOSの動作原理、DBの分散方法、大規模データを処理するための基礎知識、実践的なアルゴリズムをシステムに組み込む実装、検索エンジンの仕組み、システム全体を見渡すためのインフラ設計の知識･･･多方面の解説を盛り込むことができました。

なんやかんやで、企画から出版までに1年が経ってしまいました。しかしその内容は、1年経っても色あせることなく、十分な読後満足感が得られるものになったのではないかと自負しています。

「Web開発者のための大規模サービス技術入門」7月7日、七夕に発売です。ご一読いただければ幸いです。

Permalink | コメント(0) | トラックバック(10) | 12:31

■ はてなブックマーク経由でTwitterに投稿、の新機能

Twitter に URL を投稿するとはてなブックマークにもポストされる Twitter 連携機能。以前からありました。便利だけど･･･

• はてなブックマーク側に「asahi.com: うんたらかんたら」というタイトルだけのコメントが流れるのがやだな
• Twitter 側に [twitter][bookmark] とかタグが流れるのは微妙だなー。設定でオフにできるのは知ってるけど
• 今回の URL ははてなブックマーク側に流したくないんだけど、それを回避する方法が欲しいなあ
• Twitter に投稿してからはてなブックマーク側に同期されるまで結構タイムラグがあるのが気になるんだよなあ。せっかく1getしてるのにー

こんなところが気になる、という方も多かったんではないでしょうか。

まるっと解決

本日リリースしました、Twitter連携機能強化がこの辺のお悩みを、まるっと解決します。これまでは

• Twitter に投稿 → はてなブックマーク側に同期される

という仕組みだったのですが、本日の強化で

• はてなブックマーク側に投稿 → Twitter にも投稿

という機能が追加されました。お悩み解決だけでなく、投稿した URL のクリック数がわかるお楽しみ機能も一緒についてきます。

新機能のあらまし

いつものように Firefox 拡張でブックマークしようとすると「Twitterへ投稿」オプションが (おっ)

ブックマークすると、すぐ Twitter にも投稿されます (おお)

もちろん自分のブックマークにも、投稿されてます。で、投稿したURLがクリックされた回数がわかります (おおー)

クリック数は、ほかの人のも見れたりします (おおおー)

という感じになってます。こちらの機能ではてなブックマーク経由でTwitter に投稿すると、同期はすぐに行われますし、タイトルままがはてなブックマーク側に投稿されることもありません。タグも同様。Twitter に投げたくないときは、チェックをオフにすれば ok です。

Twitter に投げる/投げないのチェックボックスはブックマークレットやはてなブックマーク本体のブックマーク追加画面はもちろん、Firefox 拡張や Google Chrome 拡張にも対応してます。

はてなブックマークと Twitter を両方お使いの方は、これからははてなブックマーク経由で Twitter に投稿していただくと、拡張その他と操作がすべて統合されて便利、また楽しいと思います。どうぞご利用ください。

Firefox 拡張で利用したい場合 ― アドオンを 2.1.0 にアップデートお願いします

Firefox 拡張をお使いの方は、アドオンをこちら https://addons.mozilla.org/ja/firefox/addon/11285/versions/ から最新版にしていただくと、Twitter のチェックボックスがでます。もう少し後になると Firefox 拡張が自動更新されるようになると思いますが、すぐに試したい場合はマニュアルで更新をお願いします。すみません。設定画面からTwitter 連携を有効にするのもお忘れなく!

Permalink | コメント(0) | トラックバック(4) | 12:13

■ エンジニアの不安と壁

このところ、KLab×はてな エンジニア応援ブログコンテストというのを開催していまして、エンジニア人生に関するちょっとした小話をブログに書いていただくと、内容によっては、シリコンバレーに行けたり、iPad が貰えるかもしれない。という企画です。「え、ブログ書くだけでシリコンバレー? 」 なかなか太っ腹な企画です。

よい機会なので、宣伝がてら、自分もちょっと、昔話をしてみたいと思います。

振り返ってみると、自分がエンジニアとして経験を積むなかで、「ここが壁だったな」と思うところがぼちぼちありました。それが何で壁に感じたのかといま改めて考えると、いずれも体系的な知識がなかったために、それを乗り越えるための指針がなかったというのが大きかったように思います。

• きれいなコードを書くにはどうしたらいいんだろう?
• 負荷分散って、どうやるんだろう?
• 溜め込んだデータをうまく活用するには、どうしたらいいんだろう?

などなど。

「きれいなコードを書くにはどうしたらいいんだろう」。プログラマになって誰もが一度は経験する壁なのかな、と思います。社会人一年目くらいに「そもそも綺麗なコードってどんなコードなんだ」というところに始まり、四苦八苦したのでした。覚えたてのオブジェクト指向で「おれおれオブジェクト指向」を遺憾なく発揮し、周囲に迷惑をかけた、なんて黒歴史もきっちりと刻んできました。

自分がまあまあ綺麗にコードを書けるようになったな、と思えるようになったのは、結構時間が経ってからでした。そうですね、はてなに入ってしばらく経った頃だから、社会人プログラマ経験的には4年くらいが過ぎた頃だったと思います。何が設計のセオリーか、どういうコードが見本なのかというのは、断片的にあちこちから得た知識/コードからなんとなくは分かっていたのですが。それらの点と点が繋がって線になった、と感じたのは、結城浩さんのデザインパターンの本を久しぶりに読んだときでした。

あの本を読んで、同じような感想を持った人がどれくらいいらっしゃるかは正直なところわからないのですが、自分は繰り返し繰り返し読むうちに、パターンの根底に通じるプログラミング設計の概念がおぼろげながら分かるようになったと感じました。ひとことで言うなら「インタフェースでプログラミングする」ということなんですが、その概念が中心軸になって、それまでに持っていた自分の知識が徐々に体系化されていったのを良く覚えています。

負荷分散。これはなかなか大きな壁でした。自社のシステムがサービス規模の拡大に追いつかず、また日々の対応がどうしても対症療法の繰り替えしに留まってしまう。正直、途方に暮れていた時期もありました。そんなとき、息抜きだったかどうか、もう忘れてしまったのですがたまたま手にとったのが、オライリーの Linux カーネルの本でした。その本には、今考えると当然なんですが、OS が動作する仕組みが解説されていました。プロセスとは何で、スレッドとはどう違っていて、仮想メモリはどういう働きをしていて、OS はどのようにデータをキャッシュするか。そんなことが書かれていました。

サービスの負荷分散を実行するのに OS の動作原理を知る必要がある。その紐付けに気付いたのは、それからすぐでした。OS は有限なリソースを効率的に利用するためにこれこれこういう動きをしている。逆に、こういう動きはしていない。それがわかれば、システム全体の系を、その OS の効率性を阻害しないように組み立ててやればよい。これが答えでした。一時期、このブログに Linux カーネルの話しをたくさん書いていたこともありましたね。

OSの動作原理を知るためには、カーネルの本を読むだけでなく、CPU の本や、時にはアセンブラの本を読む必要もありました。目的がはっきりしていましたから、その「負荷分散のためのOSの動作原理」という考え方が軸になって、それぞれの知識が自分の中で体系化されていきました。知識と知識を紐づけて構造化する。それが結果として、力になるんですね。すなわち、知識の体系化とは自分の脳内を編集することと思います。

データの活用。これはコンピュータサイエンスの分野にそのヒントがありました。情報検索やデータ圧縮、パターン認識や機械学習。それらの基礎を学ぶことで徐々に現実的な応用の道筋を立てられるようになりました。ここで苦手だった数学をいちからやり直す必要があって、腰をあげるのが大変だったのですが、数学は数学で面白いもので、高校・大学の授業はあんなに退屈だったのに、「あのアルゴリズムを理解するため」という目標がはっきりしてくると、その学習が面白く感じられるのでした。

数式を解くのが目的ではなく、なぜなに、を知るのが目的になったので、そもそも数学ってどういう学問なの? というところまで遡った入門書なんかも読んで、あー、学生の頃にこんな風に数学を教えてくれる人がいたらよかったのに、なんて感じたりもしたのでした。未だ現役の学生さんには全く叶わない程度の知識で留まっていますが、根本的なところからやりなおして徐々に積み上げていった結果、その分野を壁と感じることは、もうなくなりました。

こうして、一つ一つ壁を乗り越えるたび、自分の中で体系化された知識が構築されていったように思うのですが、こういう知識は時間が経っても陳腐化しないし幅広い場面で応用が効くんですね。それはエンジニアとしての大きな自信につながりました。

ずっと抱いていたエンジニアとしての不安 ― 自分はプログラマとして自分の技術を誇れる日が来るだろうか? という気持ち。 Web API を操作してああしてこうやればこんなアプリケーションが作れる。このデータとこのデータをあのライブラリに放り込めばこんな風に綺麗なグラフが描ける。そういう知識を次々と溜め込んでいけば、いつか不安は解消されるんじゃないか。そう思っていた時期もありました。でもそれを続けても、不安は解消されないばかりかなぜか益々大きくなっていくばかりでした。そんな不安を払拭するのに必要だったのが、ここまで述べたような道のりだったように感じます。

長く自分語りしすぎました。昔話はこの辺にしておきましょう。

さてさて、未だによくわかっていない大きな壁が

「ヒットサービスを作るにはどうしたらいいんだろう?」

ということですか。うーん、これはさすがに体系化していくのにはだいぶ苦労しそうですが･･･これからもいちサービス開発者として、その追求を忘れないよう気持ちを新たにがんばっていくとしましょう。

Permalink | コメント(2) | トラックバック(8) | 12:42

■ モノリスでジャガビーをスキャンしたらじゃがポックルが届いた

あ…ありのまま今起こった事を話すぜ！な…何を言ってるのかわからねーと思うが以下略、京都オフィスにじゃがポックルが届きました。

ことの経緯

先日モノリスに

と、ジャガビーのあまりのおいしさへの共感を求めて切羽詰まった投稿をしたところ

というようなやりとりがありました。で、ここまでは良くある話なんですが

えっ、という展開に･･･!

じゃがポックル届いた

そして本日、じゃがポックルがほんとに届いてしまいました。id:takehiko さん (@itayan さん) ありがとうございます!!!

スタッフ一同歓喜です。早速じゃがポックル食してみましたが、こ、これはほんとうに美味しい。味皇だったら口から黄金色のジャガイモの類が吹き出るレベル。いや、冗談抜きでおいしいですねー。社内あちこちから、美味しいという声が聞えます。

じゃがポックルは、Wikipedia によるとカルビー千歳工場だけで生産される北海道限定商品で、人気ですぐ売り切れるらしく入手がなかなか難しいそうです。で、確かに、同じカルビーのジャガビーと似てるんですが、食感や塩味の濃さ等々が違います。じゃがポックルは、限定と言われてメンタルに作用していることもあってか、こっちの方が美味しいような気もします。ほんとうに美味しいので、調子にのって3袋も食べてしまいました･･･。

喜びすぎる id:onishi さん。ちなみにぼくはカルビーの回し者ではありません。

以上、モノリスに投稿するとモノが届くという話でした。いやいや。こんな感じで、日々モノをスキャンしては投稿していますが、モノを中心にしたコミュケーションというのもなかなか面白いですね。フォローを増やしていくと、タイムラインを見ているだけで、自分じゃあ探さなかっただろうなという面白そうなアイテムが見つかったり、新体験です。おかげで最近、本を買いすぎています。

ほかの人の投稿みていると、食べ物をスキャンしてるひとも結構多いですね。どうも いろはすが人気 みたいですね。

ということで、嘘のような本当の話でした。じゃがポックル、堪能させていただきます。

Permalink | コメント(0) | トラックバック(0) | 12:05

■ 「ほんとうのプロダクトアウト開発」 ― マツダはなぜ、よみがえったのか?

"プロダクトアウト"。技術や思い入れなどを優先して製品を作るやり方です。

技術から発想しなければなし得ない製品というのは当然ありますし、そういうものこそ革新的であるとずっと思っていました。ですが、僕はこの「プロダクトアウト開発」というのを、いつからか都合の良いように解釈していた。自分達がやりたいことを優先するための正当化、技術的に困難な課題を解くことからはじめるのではなく、そこに扱いやすい技術があるからそれで作るという、リスクを取らない開発のための言い訳。

「プロダクトアウトじゃないと、真に新しいものは作れないんです。」

先日、『マツダはなぜ、よみがえったのか?』という本を読みました。不振に陥った自動車メーカーのマツダが、苦境の中から RX-8 を開発し、その状況から脱出するまでをつづったノンフィクションです。この本には「ほんとうのプロダクトアウトとはなにか」ということが記されていました。

RX-8 という車

MAZDA RX-8 はマツダの4ドア4シーター、ロータリーエンジンのスポーツカーです。

(写真: RX-8 のカタログより)

見ての通り、非常にスポーティで、いかにもよく走りそうな出で立ち。素人の自分から見ても、これは車好きにはたまらない車だということが良く分かります。ドアが観音開き状に開閉するところなども、非常に特徴的です。

RX-8 は 2003 年に市場にお目見えするわけですが、それまでの常識では、通常スポーツカーと言えば2ドア2シーター。つまり2人乗りが前提でした。見た目的にというよりも、技術的に、車体が軽量であることを優先するスポーツカーにとって、重量が増す 4ドア4シーターのスポーツカーというのはあり得なかったわけです。RX-8 はそんな常識を打ち破り、4人で乗れるスポーツカーとして、驚きをもって迎えられた車です。

RX-8 はロータリーエンジンを搭載した唯一のスポーツカーでありながらも「4人で乗れる走って楽しい」車として、売れに売れました。しかし、この売れるスポーツカーである RX-8 の開発には非常に高い技術的ハードルがありました。それを乗り越えるためにマツダの開発陣が、経営陣が何をしてきたかが、この本には記されています。

マツダは、はじめから「儲かるロータリーエンジンスポーツカー」を作ろうとした

前述の通り RX-8 はスポーツカーとしては異例の販売台数を誇る車であり、また、世界各国での賞を総舐めした、専門家からの評価も高い車でもあります。

しかし、この RX-8 の開発の裏側では、経営陣と技術陣の真剣なぶつかり合いがありました。

詳しくはぜひとも書籍を読んでいただきたいのですが、RX-8 の前身であるショーモデルの RX-01 は2ドア2シーターのいわゆるスポーツカーでした。マツダは自社の強みである、ロータリーエンジンや高性能の足回りを実現する技術力を活かして、当初は 2ドア2シーターのスポーツカーを開発しようとします。ところが、当時経営不振に陥いっていたマツダがフォードへ経営支援をあおいだことで送り込まれて来た外国人経営者から、このスポーツカー開発に注文が入ります。

フォードの経営陣が示した難題こそが RX-8 のコンセプトである「4ドア4シーターのスポーツカー」を作れ、という指示でした。なぜ、フォードの経営陣は4ドア4シーターを命題としたのか。

いちばん大きな理由は、2ドア2シーターのスポーツカーは「売れないから」です。2人しか乗れないマニアックなスポーツカーでは、ターゲットになる市場が小さすぎる。芳しくない経営状況の中、市場規模の小さな車を作ることは許されない。そこで売れる車を…となるわけですが、ここで単純にマーケットイン的に、売れるだけの車を作るとはせず「4ドア4シーターのロータリーエンジンスポーツカー」というあくまでロータリーエンジン + スポーツカーというマツダ独自のテーマにはこだわります。

当時マツダは、経営再建にはモノ作り企業としての技術力の他に、市場に訴えるためのブランド戦略が必要だと考えていたようです。そのブランドを確立するためには、ブランドを体現するフラグシップモデルとなる車が必要。そしてその車はコンセプト重視でありながらも儲かる車でなければいけない。自社の持つスポーツカー開発をも可能にする技術力を活かしながら、市場を拡げる車 … その回答が RX-8 でした。

経営陣はプロダクトアウトのビジョン、技術陣は困難な目標を技術で解決する

当時は4ドア4シーターのスポーツカーは常識外れでしたから、この無理難題に対して当然、技術者達ははじめは反発するのですが、双方でコミュニケーションを取り、議論を重ねながら、ひとひとつ課題を解決していきます。軽量であるロータリーエンジンでなければ成し遂げられなかったエンジンのレイアウト、4ドア4シーターでありながらもスポーツカーとしての高いボディ剛性、見た目を損なわないための観音開きドアも、すべてその課題を解決するために生まれたアイデアだったそうです。

技術陣が自分達が作りたいものを自分達の目線で作るのではなく、当初は困難だとさえ思われる目標設定があって、そこにチャレンジしたからこそ、革新的な製品を作ることができた。一方の課題設定は、「売れる車を作れ」ではなく「強みである技術力を活かしながら、4ドア4シーターの車を作れ」という、あくまで自社の強みやブランドに拘った「プロダクトアウトな目標設定」でした。ここが RX-8 開発成功の最大のポイントではないかと思いました。

RX-8 は、童心を取り戻した大人に売れた

ブログで書くとあっさりなのですが、実際にはその問題解決の過程にはさまざまなドラマがあり、それが詳細に語られています。そしてモノ作りや経営だけでなく、当然マーケティングや販売戦略なども高度に行われる必要があったようです。

結果として RX-8 は、どのように売れたか。RX-8 の主要購買層は、RX-7 の頃の典型的なスポーツカー購入層…20代の独身男性や40代50代の高額所得者…ではなく、30代の、家族がいる子育て世代でした。

スポーツカーがファミリー層に売れる。あり得ないですね。「子供の頃に憧れたあのスポーツカー、でも、家族も子供もいるし、もう諦めなければいけないと思っていた。この車なら、RX-8 なら、家族と一緒にスポーツカーに乗れる。」そんな客が試乗会に行列を成したそうです。…4ドア4シーターのスポーツカーというコンセプトの勝利です。技術革新の末に、ライフスタイルの変革がありました。このくだり、涙なしには読めませんでした。

こうして RX-8 は、スポーティでありながらも使い勝手が良く「走って楽しい車」というマツダのイメージを体現するフラグシップモデルとなり、アテンザ、アクセラなどその後のマツダのカーラインナップの牽引役となります。

ほんとうのプロダクトアウト開発

書籍から引用しましょう。

ほんとうのプロダクトアウトとは、RX-8のような製品の開発過程を指すのだ。すなわち、無理難題とも言える目標を経営陣が掲げ、現場はその目標を超えようと知恵を絞り、試行錯誤を重ね、そして目標以上のものを創り出す―。これが、ほんとうの「モノづくり」であり「プロダクトアウト」である。

プロダクトアウト、という言葉を言い訳にしていた自分にとっては、ぐさりと刺さる一文でした。

一方で、モノづくりだけにこだわり過ぎるのが良いとも思えません。あくまで市場を見据えることが前提で、そこに自社の強み、ブランドを活かしつつのプロダクトアウトの視点を注入することが大切なのではないかと考えます。

知人のことば

「大きなビジョンというか目標のようなものを決める。そこを柱に、すべての物事がそこに吸い寄せられるように進むようなものを。それができれば、事業はうまくいくよ」と、かつて社会人になりたての自分に、先輩である知人がアドバイスをくれました。当時は、そのビジョンや目標に何を示すのが良いのか、良く分かりませんでした。

徐々に経験を積んでいく中、おぼろげながらその姿形が分かってきたつもりになっていましたが、この RX-8 開発秘話は、それをはっきりと教えてくれました。示さなければいけないのは具体性を伴った高い目標であり、また必要以上には現場に踏み込み過ぎずない、現場を信頼するビジョンなのでしょう。自社の得意な問題解決力を見極め、その現場力を更に引き上げたところにありつつ、売上げやブランドなどを総合的に確立する目標設定。困難ではありますが、確かに全てをその目標設定に吸い寄せることができれば、物事はうまくでしょう。

そしてそのビジョンこそが、プロダクトアウト開発において必要不可欠なものである。それを教えてくれた本でした。

マツダはなぜ、よみがえったのか? ― もちろん、読み物として仕上げるために、美談にされているくだりなどはあることでしょう。それをさっ引いてでも、今の自分にとっては糧になる様々な物語が詰まった一冊です。著者の宮本さんに感謝したいと思います。

P.S. 遅ればせながら Twitter はじめました。

Permalink | コメント(7) | トラックバック(5) | 10:48