読書メモ「その数学が戦略を決める」文庫版


原題は「Super Crunchers」。本書では「絶対計算者たち」と訳されている。こちらにあるように「Number crunching」はコンピュータなどで高度な計算を行うという意味のスラングらしい。邦題の「その数学が」の「数学」は、ここでは統計学のことである。

2008年に出版された本書(邦訳版は2010年?)は「ビッグデータ」ブームの到来前に書かれたものである。内容は古くなく、かえってビッグデータ本にありがちな事例が載っていないために新鮮であったりする。著者はこの分野の専門家で、ジャーナリストが書いたビッグデータ本とはまた異なる良さがある。全体を通じて飽きることなく、一気に読み終えた。

p.61より

絶対計算の一部は企業内で行われているが、本当に巨大なデータ集合は外のデータウェアハウスにおくられて、テラデータのような専門企業が分析している。この会社はまさに何テラバイトものデータを扱っている。世界的な小売業者上位の65%(ウォルマートやJCペニーなど)はテラデータを使っている。また航空会社の七割、銀行の四割も同社の顧客だ。

日本国内でテラデータに位置する企業はどのへんなのか興味がある。

p.98より

偶然にまかせたテストは、銀行や貸金業にかぎられてはいない。Offermatica.comはインターネット上の無作為化をまさに芸術技まで高めた。
(中略)
オファマティカのソフトは、人々がクリックするごとに、その2つのウェブページのどちらかを、無作為に送る。そしてどっちのページが「クリックスルー」が多いか、つまりは購買につながるかを、リアルタイムで教えてくれる。

ウェブページでの無作為化テストは低コストで行うことができるが、ノウハウが必要になる。オファマティカはそのノウハウを誰でも使える形にしたサービスである。その後オムニチュアに買収されたらしい。

p.103より

ユーザビリティ専門家は、実験室で確立されたいくつかの原則に大いに自身を持っている–たとえば、「人々はまず左上の隅を見る」とか「人は青より赤に注目する」とか。ロシュは反論する。「現実の世界では、広告はものすごい数のその他の入力と競合しています。対照実験なんてものは存在しません。ユーザビリティ専門家は、他の情報の津波が押し寄せているのに砂で出来た真実の城にしがみついているんです。」

まさに本書らしい記述の一つ。専門家 vs データ。この例のインターネット上の広告のようにデータが取りやすい場面では、専門家の化けの皮はすぐにはがれてしまう。

p.114より

自分たちの大切な方針をきちんとした試験にかけたくはないのだ。下手をすると、自分がまちがっていることが示されてしまうかもしれない。

企業文化に無作為抽出テストが浸透しない理由について。いかにもありそうな理由だが、長い目でみればそういった立場を取る専門家は駆逐されていくしかないだろう。

p.164より

個々の医師がまともに吸収しきれるのを遙かに上回る、根拠に基づく情報がありすぎるのだ。
(中略)
明らかに、医師たちにそこまでの時間をかけて統計調査の山を漁れというのは、まったく現実的ではない。

「きちんとデータに基づいて仕事をしよう」と考える専門家に立ちはだかる問題。これは、僕のやっているウェブやネットワーク侵入検知の分野でも同じことが言える。興味を引くタイトルの論文や記事はいくらでもあるんだけど、ひとつひとつ吟味している時間を取ることは難しい。本書ではこの後、それぞれの情報の品質に基づいた検索を可能とするデータベースが必要だ、としている。セキュリティとは外れるけれど、僕がよく使う中では、StackOverflowがそのような役目を果たしてくれているかもしれない。

p.169より

ついに教授は、その研修医に診断を尋ねた。そして彼女は、診断を下しましたと述べ、症状に見事にあてはまる珍しいIPEXという症候群を報告した。どうやってその診断に達したのか訪ねられると、彼女はこう答えた。
「主要な特徴をグーグルに入れたら、すぐに出てきましたよ」

本書に登場する数多くの例の中でも、最も印象深いエピソードのひとつ。自分の専門分野でこれ(Googleに自分の知識が負ける)が起こったときにどうするか。あるいは、起こることが当然と考えるか。自分はグーグルに勝てるのか。あるいは勝ち負けではない別の方向を模索するのか。

p.199より

「人間の判断は、最高の回帰分析に劣るというだけではない。ほとんどどんな回帰分析にも劣るのだ」

ちなみに本書の著者は回帰分析とランダム化を(統計が専門家に勝つ理由である)大きな武器として紹介していて、機械学習系にはあまり積極的ではない。基本的には統計学に惚れ込んでおり、回帰分析の肩を持つきらいがある。上記は、単にある心理学者が言った言葉というだけであり、さすがに真実ではないと思いたい。

p.216より

だがどこかの時点で、絶対計算の優位性というのは他人事ではない、ということを受け入れるべきだ。野球のスカウトだのワイン批評家だの放射線医学だの等々、一覧は果てしなく続き、やがては自分のところにもくる。

これは、まさに今の僕を突き動かしていることである。ウェブやネットワーク侵入検知の現場には膨大なデータが存在していて、それらを活かせば、より高品質な侵入検知サービスを構築することができるだろう。データサイエンスの知識を持たないままでいれば、いつかは砂の城にしがみつく権威的な存在になってしまうことは確実だ。

p.331より

最高のデータマイニング屋は、統計分析がもっともらしいかどうかについて直感や経験的な技法を使う。直感から大きくはずれた統計結果は、慎重に調べ直す必要がある。
(中略)
それぞれの意志決定は、お互いの最大の弱点を実用的に補い合ってくれるわけだ。

理想的な形は「絶対計算 vs 専門家」という構図ではなく、絶対計算を使う専門家という形だろう、という話。当然だろう。

本書は基本的に「絶対計算が最強である」という意見を強く持つ著者によって書かれていて、他の中立的なジャーナリストが書いていることが多いビッグデータ本よりも、やや偏った内容となっている。しかしそこが魅力でもあり、ITエンジニアであれば、自分も絶対計算ができるようになりたい、と思うに違いない。

さて、本書を読んで、あらためて自分の立ち位置について振り返ってみた。

最初は、自分は完全に、本書で書かれている「野球のスカウト」だと考えた。つまり絶対計算を使わず、経験、直感、勘といった要素で仕事をする専門家だ。そのためこのままではビッグデータ、データサイエンス、絶対計算の波に完全に飲み込まれるだろうと恐怖を感じていた。

しかし、実際にデータサイエンスの勉強を始め、あらためて自分が行ってきた仕事を振り返ってみると、そこまでひどいことにはなっていないことに気付いた。僕は自分の直感を(ネットワーク侵入検知の)コードに落とし込むわけだが、そこで終わらず、きちんと実際に集められたデータを使ってそのコードの質を検証する、というサイクルを繰り返していたのだ。その過程に機械学習や回帰分析などのデータサイエンスの技術は(知らなかったので当然だが)まったく存在していないが、それなりに自分の直感に依存しない、客観的なテストデータを取り込んでいたので、これは方向としては非常に正しいものであると思う。

野球のスカウトも、自分がスカウトしてきた選手がその後本当に期待通りの成果を上げたかきちんと評価し、間違っていれば自分の勘を修正する、というサイクルを回せば、それほどひどいことにはならなかったろう。しかし、そこまで自分を追い込まなくても、仕事が舞い込んでくるという環境だったのかもしれない。

僕は最近本格的に統計解析やデータマイニング、機械学習の勉強を始めたが、こんなに面白いものがあったのか、という新鮮な驚きで満ちている。これらの技術を自分の専門分野にフィードバックする段階に到達するのが楽しみだ。


Hadoop/Dunkhead用にデータを漁った際のPublic Data Setsメモ

Dunkheadでいろんな種類のデータの可視化を試すために、パブリックになっている面白そうなデータを漁った際のメモ。

Dunkheadは『タイムスタンプ付きの』データのみが対象になるのだが、意外とこれが見あたらない。特に、Apacheのログみたいなのはたくさんあるかと思ったのだが、殆ど手に入れることができなかった。

CAIDA Data – Overview of Datasets, Monitors, and Reports

CodeRedワームのデータが手に入るのがここ。誰でも自由にダウンロード可能なデータと、そうでないもの(アメリカの学生とか向け?)があるみたい。

Publicly available PCAP files

パブリックなPCAP(パケットダンプ)のデータへのリンク集。ここには猛烈に助けられた。
CTF系のパケットはDefcon以外についても色々と公開されている。

Web Traces and Logs

HadoopとDunkheadでNASAのウェブサーバのアクセスログを解析・可視化するで使ったアクセスログを見つけたリンク集。少し古いデータが中心。

Quora

public data setsを探す質問にいろいろ回答が寄せられている。

まだまだ探せばあるとは思うのだが、今回は予想外にデータにたどり着けなかった感じ。


読書メモ「ビッグデータの正体」

p.28より

今、挙げた二つの変化は、さらに重要な第三の大きな変化をもたらす。因果関係、すなわち「原因と結果」を求める古い体質からの脱却だ。
(中略)
相関関係は、正確な「理由」を教えてくれないが、ある現象が見られるという「事実」に気付かせてくれる。基本的にはそれで十分なのだ。

安く手に入るようになったコンピュータリソースによってゴリゴリ計算を行い、相関関係をガシガシ見つけていくことがまず役に立つ、ということか。とりあえずは実際に手を動かして、データから相関関係を見つけるスキルを身につけねば。

p.29より

映画『マネーボール』では野球のスカウトマンが統計データの活用で注目を浴びたが、あれはまさに高度なデータ分析に、職人的な直感が敗北を喫した例だ。

自分は現在、まさに「職人的な直感」で喰っているので、まったくもって寒気がするとしか言いようがない状況。この後マネーボール観ました(;´Д`)

p.40より

意外かもしれないが、ある母集団が、「はい・いいえ」のような二者択一問題にどのように回答するかを調べたい場合、無作為抽出した1100人の標本があれば、なんと97%以上の精度で全体の動向を言い当てることができる。

最近ちょうど統計学の勉強を始めた。目的としては上記のようなことを理解すること。とりあえず1100という数字と97という数字を結びつけるために頑張ってみたが、よくわからなかったw まだまだ修行が足りないらしい。「全体の動向を言い当てることができる」っていうのが何を指しているのかよくわからない。「はい・いいえ」をそれぞれ1と0とした場合の平均値(例えば、偏りがなく0.5なのか、「はい」が非常に多く0.9なのか)に左右される気もする。

統計に詳しい人、是非上記を解説していただきたく…m(_ _)m

p.130より

原作者不明とされた書物も、文章の書き方を比較することで原作者を突き止めるヒントが得られるかもしれない。

文章の「指紋」のようなものについての話。すごい発想だと感じた。データあるところにパターンあり、か?

p.166より

結果としては、携帯電話利用に伴う癌リスクの増加は見られなかった。

デンマークでの携帯電話と癌の関係に関する大規模な調査の話。携帯電話は関係なさそう、という結果だったからか、あまり話題にならなかったらしい。個人的に電磁波の健康への影響の有無に非常に興味がある。

p.180より

その結果、連邦政府の公開情報を集めた「data.gov」と呼ばれるウェブサイトが開設された。
(中略)
欧州連合(EU)もデータ公開構想を発表した。

恥ずかしながら上記のような動きがあったとは、ちっとも知らなかった。ちょっと系統は異なるけど、個人的に政府(?)に期待したいのは、例えばIPAなどが税金で作らせているアプリケーション(iLogScannerのようなもの)をオープンソース化すること。そうすれば報酬を求めない開発者も参加して、よりよい形に改善できると思う。

p.186より

現在、データの値付け実験の場として、数々の取引市場が立ち上がっている。
(中略)
外部企業はこうした場に参加して、自社のデータを他社に有償あるいは無償で提供する。オークションサイトで不要品を売るのと同様に、社内のデータベースにしまい込んであるデータを販売できるのだ。

純粋にデータをインターネット上で売買するという動きができているとのこと。これも知らなかったので、驚いた。Scutumのようなサービスも、しばらくやっていると「素性の悪いIPアドレス」のデータなどが溜まるが、そういうものを売るというアプローチも考えられるのだろう。

p.205より

現在、データベース管理、データサイエンス、分析、機械学習アルゴリズムなどの専門知識やノウハウは引っ張りだこだ。しかし、今後、ビッグデータが日常生活に深く入り込み、ツールは使いやすく性能も向上し、さらに多くの人々がノウハウを持つようになると、スキルの価値は相対的に低下する。コンピュータプログラミング能力もそうだった。1960年代から1980年代にかけて普及し、今では海外のアウトソーシング先の存在もあって、プログラミングの価値はさらに下がった。かつては技術力の代表格のように言われたものが、今では貧困国の発展の原動力になっている。とはいえ、ビッグデータのスキルが重要でないといっているわけではない。こうしたノウハウや専門知識は、価値を生み出す厳選としてみると、最重要ではないのだ。その気になれば外部から調達できるからである。

ビッグデータのスキルが将来的にはありふれたものになるだろうという予想。現時点でそこまで考えられる視点は見習いたい。スタートアップ的な動きをするエンジニアにとってはプログラミングもビッグデータのスキルも外注してどうにかなるものではないので、しっかりと身につけるという選択肢以外はあり得ないと思う。「プログラミングできること」自体も大事だが、それより「プログラミングできること」によって得ることができる「より高い視点の位置」「発想の柔軟さ」が大事だ。エンジニア出身の社長が優秀なのは、まさにこの点であると思う。

p.215より

これからは数学や統計学、それにプログラミングとネットワークのちょっとした知識が、”現代の読み書きそろばん”になる。

さっき「外注できる」って言ってたくせに…というのはいいとして、まさにその通りだと思う。

p.232より

やはり個人特定可能なデータは丁寧に削除されていたのだが、それでもユーザが特定されてしまったのだ

ネットフリックスの話。インターネット上の他のデータと組み合わせることで、ちょっとした手がかりから個人が特定されてしまうケースは多数ある。日本でもかつてのWinnyでの個人情報漏洩や、2ちゃんねるによる「特定」など、個人情報がさまざまな情報の断片から特定される例はよく見られる。

p.275より

まず手をつけたのが、市内に90万軒ある住宅リストの作成だ。次に、19の機関から入手したデータを住宅リストに加えていく。具体的には、建物オーナーの固定資産税滞納、抵当権執行手続きの有無、電力使用量の異常や料金滞納による電力供給停止といったデータだ。また、建物のタイプ、竣工時期、救急車出動回数、犯罪率、ネズミの苦情などのデータも入力された。

不正改造住宅を見つけるためのアプローチの第一歩として、上記のようなデータが使用されたとのこと。相関関係を調べる具体的な例として興味深い。

p.289

ところが発明のひらめきは、データには語れない。まだ存在していないのだから、いくらデータ量を増やしたからといって、裏付けや確証が得られるものではないのだ。

ジョブズが市場調査をしなかった(「消費者は欲しいものを知らない」)のに似ている。当たり前だが、ビッグデータがすべてを解決するわけではない。ただ、遺伝的アルゴリズムのように「突然変異」という現象をコンピュータでの計算に取り入れることだって可能なのだから、一概に「コンピュータはひらめかない」と決めつけることもできないだろう。

この本を読めば「ビッグデータ」が単なるバズワードではないことはすぐにわかる。文句なく、「買い」の本。ビッグデータの具体例はもちろん、上記で紹介したようなやや抽象化した見方もできるのが、この著者の凄いところだ。

インターネットの台頭に続き、このような大きな動きが現れる時代を生きることができる幸運に感謝したい。


Hadoopのセカンダリソートを避け、より高速に値をソートする方法

Scaling out H2 on Hadoop

HadoopのReduceに渡されるのはキーと値のリストだが、このとき値のリストに含まれる各アイテム(値そのもの)はソートされていない。ソートされていて欲しい場合にはセカンダリソートと呼ばれるテクニックを使うのが定石とされているが、これは実装の面でも概念的な面でもバッドノウハウ的な側面がある。Hadoopには「キーをソートする」機能は実装されている。そこで、値をキーに入れてしまい、このHadoopに備わっている「キーをソートする」機能によって、実質的に値をソートしようというわけだ。

Map/Reduceというのはキーごとにデータを分割して処理する方法なので、「キーに値が入ったら分割がおかしくなるんじゃ?」と思うのは当然である。キーに値が入っていても、分割に影響しないよう、Partitioningクラスを自分で拡張し、分割の基準となる値(本来のキー)には、値の影響が出ないようにするのだ。それでいて、ソートの際に使われる比較(つまりComparator)については、「キーに含まれる値」を使うということである。

上記を読んで少しでも意味がわかっただろうか?分からないのが当然で、つまりセカンダリソートはウ○コだということなのである(w

そこで、Java組み込み型のRDBMSであるH2を利用して、値のソートを行うというテクニックを使う。Reduceの処理において、単純にすべての値をH2データベースに格納する。そして、「select … order by …」で取り出すだけで、ソートは終わる。単純明快、コードも短く、そして驚いたことにパフォーマンスはHadoopのセカンダリソートより速くなる。唯一、H2がまるごとデータを扱うことになるため、そのぶんのディスク領域が追加で必要となる点はデメリットだ。

H2にデータをすべて格納することによって、セカンダリソートを避けることが可能になるだけでなく、ロジックは明快になり、またデータに対して複数回の問い合わせを高速に(これはインデックスが使えるためだ)行うことができるようになる。

下記リンクではHadoop上でH2を使うテクニックについて詳細にまとめたので、ぜひご一読を。

http://www.scutum.jp/information/waf_tech_blog/2013/08/waf-blog-025.html


和訳された技術書の邦題がひどく入門な件について

注:下記、ただのディスり記事なので、よっぽど暇な人だけ読んで頂きたく。

僕は基本的に技術書については英語の原書を中心に読んでいて、Kindleを愛用している。といっても英語のレベルはそれほど高くないので、内容は大体見当が付くジャンルの本しか、英語では読めない。具体的には、Androidプログラミングとか、Eclipseプラグイン開発とか、Java・MongoDB・Webセキュリティあたり。この辺は英語でも結構なスピードで読める。(最近はデータサイエンス系の勉強もしているのだけれど、そっちはまったくの素人であるため、英語だと、まず単語の意味がわからない。専門用語なので、辞書を引いてもわからず、結果として読むスピードが極端に遅くなる。そのため実質原書だと読めないという状態になり、結果、データサイエンス系の本については殆ど和書を買っている。統計の本とかも同じ。)

そんなわけで結構頻繁にAmazon.comのKindle Storeをチェックしているため、新しい技術書など、どんな本がどんなタイトルで出ているのかをなんとなく把握しているのだけれど、その原書のタイトルと、邦訳された本の(日本語の)タイトルの乖離がすごい。
(ロックの曲名に邦題を付けるときに「白夜のトラジディ」とか「撃墜王の孤独」みたいにセンスがいいやつで乖離するならまだしも、技術書でタイトルが乖離するのはちょっと…)

ということで、個人的にかなり引っかかったやつを紹介。

入門 PHP セキュリティ

Essential PHP Security

原書のタイトルは「Essential PHP Security」、つまり「PHPセキュリティの主要点」あるいは「PHPセキュリティのエッセンス」という感じ。この本はすごく薄くて内容が濃い、密度の高い良書で、原書のタイトルはそのものズバリを表している。それが「入門」かよ〜という感じ。やはり初心者向けみたいに見せると売れるんでしょうか。

次はこれ。

入門 機械学習

Machine Learning for Hackers

原書のタイトルは「Machine Learning for Hackers」。ずばり「ハッカーのための機械学習」ですよ。それが「入門」かよ〜という感じ。やはり初心者向けみたいに見せると売れるんでしょうか。

そして次はこれです。

RとRubyによるデータ解析入門

Exploring Everyday Things with R and Ruby: Learning About Everyday Things

原書のタイトルは「Exploring Everyday Things with R and Ruby: Learning About Everyday Things」。つまり、RとRubyを使って、身近な日常の物事に対して(データ解析で)切り込んでいく、という部分に、この本のやや珍しい立ち位置が集約されているわけです。「Everyday Things」が2回も出てくるんですね。それが「入門」かよ〜という感じ。Amazon.co.jpのページには「日本語版ではさまざまな統計手法についての入門となる章を追加。この本で使っている統計の基礎も学べる構成になっています。」って書いてあるけど、タイトルに「入門」って書いてある本に「入門となる章を追加」って意味わかんねぇよ!w やはり初心者向けみたいに見せると売れるんでしょうか。

技術書の洋書を翻訳してくれる数少ない出版社のうちのひとつとしてオライリージャパンのことは常に応援していますが(実際にたくさん買ってますよ!)、難しい本も「入門」にしちゃうのはいかがなものか!


読書メモ 「Yコンビネーター」

最近、かなり読書量が増えたので、基本的には自分のメモとして、ブログに読書感想文的なものを書いていこうと思う。僕は読書の際に、気になる箇所についてはページの端を折っている。このブログではその折ったページのうち、数カ所ずつ引用していく。

第一回は「ハッカーと画家」で有名なポール・グレアムが中心となる「Yコンビネーター」である。

p.50より

1996年の末になってもヴァイアウェブには70人くらいのユーザしかいなかった。これはグレアムの「成長はゆっくりでいい」という考えから来ていた。ユーザがわずかならグレアムと創業者たちはソフトウェアの改良が簡単にできる。

この考えは賛同できる。成長のペースが速すぎると、インフラのスケールアウトやら障害対応やら、目の前の作業のコストが高くなりすぎる。急激に成長して利益がついてくる場合、株主は喜ぶかもしれないが、現場のソフトウェアエンジニアの余裕がなくなると、サービスの中長期的な成長にマイナスの影響があると思う。

p.86より

ソフトウェア・スタートアップの世界では創業者は「エンジニア」と「それ以外」に二分される。エンジニアとはコードを書く人間で、コードを書かない人間は「それ以外」だ。

コードを書かない人間は「それ以外」だと思う。
コードを書かない人間は「エンジニア」ではない、ということだ。
僕は生涯エンジニアで有り続けることがひとつの目標なので、つまりそれは死ぬまでコードを書くということだ。

p.177より

スタートアップの創業者がハッカーであるかぎり、ビジネス面に時間を割くことに問題はない。ハッカーは時間さえあればプログラミングしていたいはずだからだ。ビジネス面の仕事をやっているならそれは必要に迫られてのことだ。ハッカーの創業者の問題はむしろビジネス面に注意を向けさせるのが難しい点だ。

…なるほど…という感じ。僕自身はスタートアップの創業メンバーであり、かつハッカー(スタートアップの中心になるソースコードを書く人間)であると考えているので、上記引用部分については常に頭にいれておきたい。

p.250より

カンが大学で身につけた知識とスキルのうち、現在IT系起業家として役立っているのは、ごくわずかだ。

日本の大学はクソ(主に、入るのが難しく、出るのは簡単という意味で)だが、アメリカの大学はかなり実用的な教育をしてくれるのでは、という漠然とした根拠のないイメージを何となく持っていた。しかし上記を読む限り同じようなものなのだろうか。どちらにせよこの時代、大学に物理的に通っている時間があったらネットで情報を収集して勉強しても同じかそれ以上のレベルに到達できる気はする。ただ、友人を見つけるという意味では大学の存在には意味があると思う。

全体を通してこの本から感じた点は以下の通り。

Yコンビネーターは優秀なハッカーによって構成されるスタートアップがビジネス面での成功を達成するためのひとつのパターンを作り上げていて、それは日本(東京)でも同じことが達成できると思う。なので、誰かそういうのが好きでお金を集める力がある人が、Yコンビネーターをまるパクリで東京でやれば面白いと思う。ハッカー2〜3名のチームを数十チーム(物理的に東京に)集めて全チームに初期に200〜300万円投資し、数ヶ月の間に具体的にウェブサービスを軌道に乗せさせる(実は上記で引用した「成長はゆっくりでいい」という考えとは逆行している!)。そしてどこかにバイアウトしてもらえれば、成功。イグジット。

でも、その後は?イグジットが目的でいいのかな?と思う。「Yコンビネーター」を読み終えて僕には猛烈な違和感が残った。もう少し僕自身に近いものなのかと考えていたけど、それはまるで違った。

ポール・グレアムは各ウェブサービスに対し、週単位、日単位でサービスの「ユニークユーザ数的な指標となる数値」が上がることを要求する。これは繰り返しになるが「成長はゆっくりでいい」という考えとは相反するものだ。また、基本的には鬼コーチ的なムードのようで、「まぁ気軽にリラックスしながらスタートアップしようよ」という感じではない。僕は苫米地英人氏の著書が好きで良く読むのだが、彼から教わった大事なことは、どんなときでも適度なリラックスが必要だ、ということだ。自身の経験からも、普段から常にリラックスしている方が、よいアイデアが浮かぶと思う。Yコンビネーターではリラックスはあまり歓迎されないように読めた。

個人的な考えとして、サービスはユーザと、サービス運営チーム自身を幸せにするものであるべきだ、というものがある。ユーザ目線で考えれば、サービスが「猛烈に成長すること」「ユーザが爆発的に増えること」よりも、「安定して長期間運営されるサービスであること」が大事だ、というケースは多いと思う。ウェブサービス主体の時代になってイヤになるのは、気に入ったサービスがあっても、人気がないと数年でたたまれてしまうことだ。自分のPCにインストールするタイプのソフトウェアであれば、開発元が倒産したって、手元でいつまでも使い続けられる。僕の手元では、今日も、昔のThinkpadについてきた、「王様の翻訳バイリンガル」というソフトが動いている。もう10年以上前に買った物だと思う。果たして僕たちは進化しているのか?Yコンビネーターでは「サービスがユーザに対して継続的に価値を提供する」ことについてどのように考えられているのだろうか。

このように読後感は悪かったけれど、知識として持っておきたい内容だったので、この本は読んで正解だったと思う。