読書日記「仮想世界錬金術 モバイルソーシャルアプリに見る現代ディジタルコンテンツ革命」

今、破竹の勢いでビジネスが拡大しているモバイルソーシャルゲームについて勉強してみたいと思って読んでみました。僕もモバイルソーシャルゲームは「破壊的イノベーション」の典型例だと思っていて、最近はとても注目しています。グリーやDeNAの好調な業績が世間を驚かせていますが、国内のソーシャルゲーム市場は2012年度には3400億円を突破すると予想されているようです。（矢野経済研究所：ソーシャルゲーム市場に関する調査結果2011より）また、同時に海外市場への進出も急速に進めています。本書ではソーシャルゲームビジネスがいかに拡大してきたか、ソーシャルゲームの基本原理、またそのマーケットについてを実例に基づいて説明しています。

僕が一番面白いと感じたのは、モバイルソーシャルゲームはひたすらEnterを押し続けるような単純なゲームに見えながらも、裏側では以下のような技術やノウハウが凝縮された、かなり高度なサービスだということです。

• 限られた機能、コンテンツ、UIでいかにユーザを楽しませるか（ゲームニクス理論、エクスペクトロジー、時間の使わせ方など）
• どうユーザ間のコミュニケーションを楽しませるか
• データマイニングに基づくチューニング
• フレームワークを利用した少人数、短期間での開発
• クラウドサービスや並列処理を利用した負荷分散

個人的には、これからゲームビジネスはどんどんパッケージ型から課金型へビシネスモデルが変換していくと予測しています。据え置き型のゲームも初期の価格設定を低く抑えて、コンテンツやアイテムなどで課金していくのが主流になっていく気がします。正直、僕自身がモバイルソーシャルゲーム（怪盗ロワイヤルとかドリランド）をやった限りでは、システムが単調すぎてのめり込むほど面白いとは思えなかったんだけれども、おそらく今後はスマートフォン向けの新しいゲームがどんどん出てきて、もっとリッチなコンテンツを求めるユーザ層も獲得していくだろうと思っています。メインフレームがオープン系のワークステーションに置き換えていったようにね。海外進出もどんどん進められているようなので、日本のIT企業が海外の市場でどれだけ戦えるのか楽しみですね。

読書日記「企業のファイナンス ベンチャーにとって一番大切なこと」

ちょっと起業して一発当ててやろうと思い（嘘）、友達に薦められた、「企業のファイナンス　ベンチャーにとって一番大切なこと」というベンチャー企業のファイナンスの本を呼んで見ました。磯崎哲也さんというベンチャービジネスやファイナンスについて書かれたisologueというブログで有名な方です。

この本は、実際に自分が起業した時のイメージを持つために書かれており、起業の流れやファイナンスの仕組み、上場やバイアウトのプロセス、実行時にに気をつけたほうが良いことなどを易しく筆者の経験を交えながら説明してあります。

かなり幅広い事を説明しているので詳細まで紹介することはできませんが、事業計画の作り方、ストック・オプションや種類株式や投資家（VCなど）との交渉の仕方の説明まで含めた資本政策の方法、バイアウトや上場によりどうキャピタルゲインが得られるのかなどまで説明してあります。僕は証券会社に5年間ほど勤務しているので基本的なファイナンスの知識はあるのですが、上場時に何が必要になるかや、種類株式を利用して如何にすべてのステークホルダーの利益を損ねないように増資を行うかなどの説明はとても興味深かったです。

また、日本はベンチャーの市場規模が小さく、「ベンチャーに冷たい」と言われがちですが、実際にはそうではなく足りていないのはアニマルスピリッツをもったイケてる創業者や、それをサポートする仕組みだというのが著者の意見です。

シリコンバレーみたいに次から次へと競争力もスピードもあるスタートアップが湧いて出てくる環境と比べればライバルが少ないですし、サポートしてくれる人は資金政策さえ上手く行けば、競争の少ない分だけ上手く行く可能性が高いのかもしれませんね。

読書日記「エンジニアとしての生き方」

著者のLife is Beutifulというブログからの記事と、雑誌などのコラムを編集した、主にエンジニアのキャリアについて述べられた本です。

実は私は学生の頃から中島さんのブログが大好きで、キャリアの意思決定などにかなりの影響を受けてきました。新卒で今の会社に入社したのも、中島さんのブログで英語の重要さや自分でブログラムを書くことの重要さを認識したという点がかなり大きな理由です。外資系の証券会社は外注ではなく殆ど社内で開発を行いますので。

彼のテクノロジーに対する真摯さやモチベーションの高さに感服すると同時に、以下のような彼の主張に強く共感し、影響されてきました。

• どんなに優秀なエンジニアでも、決してプログラムを自分自身で書かずに良い詳細仕様を作ることは出来ない（プログラミングは知的な仕事であり、ITゼネコンの下請け構造では良いソフトウェアは作れない）
• 会社人間ではなく真に価値のある人材になろう（社内だけではなく業界全体または社会全体で価値のある人材を目指すべきである）
• 知的労働者には「組織を移る力がある」（自分のキャリアプランと日々の仕事をシンクロさせる）
• 技術者にも必要な「儲ける決意」（技術者にも儲ける意識やビジネスセンスは重要）
• 英語はグローバル人材市場へのパスポート

でも、僕の心に一番刺さったのはこの文章ですね。（ Software is Beautiful「第1回　一生の仕事を選ぶということ」より引用）

せっかく職に就くのであれば，給料とか社会的地位とかを基準にするのではなくて，自分が好きなことやりたいこととマッチした職を選ぼう，というのが私の人生論である。若いうちにいろいろなものに触れておき，自分が本当に何がしたいのか，何になら夢中になれるのかをできるだけ早いうちに見つけ出すことはその後の人生にとって大きなプラスとなる。そんな「天職」を得るための努力なら惜しむことはないし，けっして無駄にはならない。そうやって「好きなことをして生きていく」ための努力を続けている限り，（ほかの人にとっては）つらいことも苦痛ではなくなるし，楽しい人生がおくれる。一度しかない人生，思いっきり楽しもうぜ。

この本を読んで、自分の好奇心に忠実に、常に全力で情熱を注げるできるような仕事をして生きていきたいと改めて感じました。

読書日記「Web開発者のための 大規模サービス技術入門」

株式会社はてなの伊藤さん（現GREE）と田中さんという、Webに興味のある人なら名前くらいは聞いたことがあるだろう人達の書いた、「Web開発者のための　大規模サービス技術入門」というその名の通り大規模なWebサービスをどう運用していくかを説明している本です。理論的な説明だけではなく、実際にはてなで使われている運用方法などの「泥臭い」部分をかなり詳しく説明してくれているとても実践的な本でした。

この本を読んで、もし自分で大規模サービスを運用が必要になる時には絶対に自分でインフラは持たずにGoogle App Engineのようなクラウドサービスを使おうと思ってしまいました。さすがに自分でここまでする気にはならないですね…。

基本的にはパフォーマンスの問題はCPUかI/Oのどちらかがボトルネックになります。そういう時は単順にtopやsarでどちらの問題か切り分けます。どのプロセスがCPUをどれくらい使ってるかとかI/Oの待ち時間がどれくらいあるのかとかを確認すれば、だいたい目星はつくでしょう。

CPUがボトルネックの場合は以下のような解決方法があります。単純に計算量が足りないだけなので、比較的解決は簡単なようです。

• サーバを増やして処理を分散させる。この場合はDBと違ってデータのレプリケーションなども必要無いので、比較的簡単にスケールする。
• アルゴリズムを改善して計算量を減らす

I/O側はCPUのように、サーバの台数を増やすだけでは簡単にスケーリングできないので対応が難しいようですね。Googleが独自の分散ファイルシステムやデータベースを持っているのもそれが理由でしょう。対応の仕方としては以下の方法があるそうです。

• できる限りキャッシュやメモリのヒット率を高めてディスクアクセスがないようにする。（メモリはディスクアクセスの10万倍以上高速）
• プログラム変更でメモリの利用が減らせるならそうする。
• 足りなければメモリを増やす。できないならデータを複数サーバに分散させる。
• データベース側のスケーリングをする（最終手段）。マスタDB（書き込みを担当するDB）のスケールアウトはACIDが求められるため難しいが、テーブル毎やエントリー毎に別サーバにデータを分散させるようなトリッキーな事をすることもあるようです。TwitterもMySQLの分散とmemcachedで運用しているみたいですね。

RDBの分散やデータの圧縮の話はとても面白いと思いました。RDBのデータを分散するのにテーブル毎に別サーバに分散させたりするので（勿論できるだけ局所性を保つように分散する）、INNER JOINを使わずに複数回クエリを投げるプログラムを書いたりするらしいです。もはや、RDBではないですね。

他にも、データ圧縮をI/Oを減らすためだけとかに使ったりとか、データをページキャッシュにのせるためにアプリケーションで使われる大規模データを一度catしたりとか、面白いノウハウが載っていました。そういえば、僕のサポートしているシステムでもデータをキャッシュに入れるために、再起動するたびにウォームアップさせてるなぁなんて思いながら読みました。

後半のインフラ系の話の部分はまだ読めていないので、また後日にでも。ちらっと見た感じ、SSDを使った高速化とか面白そうだな。明日、Macbook Airが届く僕としては…

読書日記「Webを支える技術-HTTP、URI、HTML、そしてREST 」

ちょっとWeb系の技術の基本的な部分を勉強してみようと思って、「Webを支える技術」という本を読んで見ました。RESTfulな設計の大切さ、URIとHTTPの説明、ハイパーメディアフォーマットなどのWebに使われている基本技術の説明がメインで、最後に少しWebサービスの設計例が載っています。僕のような、コンピュータの基本的な知識はあって、勿論HTMLやJavascriptはある程度書いたことはあるけれども、体系的に勉強した経験がないような人間に丁度よい本でした。

本書ではRoy Fieldingが提唱したREST(Representational State Transfer)というWebのアーキテクチャースタイルを良しとしており、URI（リソース）、HTTP、ハイパーメディアフォーマットについて説明すると同時に、いかにそれらをRESTfulに利用するかについても言及しています。本書では、以下の6つの制約を合わせたアーキテクチャースタイルがRESTであり、実際のアプリケーションは必要に応じていくつかの制約を除外しながら実装すれば良いと述べています。

1. クライアント/サーバ
2. ステートレスサーバ
3. キャッシュ
4. 統一インターフェース
5. 階層化システム
6. コードオンデマンド

個人的には一番印象に残ったのはMethodの説明です。僕が学生時代にWebを少しかじった頃はちょうどSOAPが出てきた頃で、たしかSOAPで実装されたGoogleのWeb検索APIとかで遊んだ記憶があるのですが、今は完全にRESTに基づいてHTTPメソッドを使い分けるのが主流のようですね。5年前の僕がしていたPOSTだけですべての処理をこなすなんていう処理は完全なるアンチパターンのようですね。HTTPには以下の8つのMethodが用意されており、個々の役割は決まっているので用途に応じて使い分けるべきらしいです。

• GET
• POST
• PUT
• DELETE
• HEAD
• OPTIONS
• TRACE
• CONNECT

後はHTTP、URIやデータフォーマット（HTML、JSON、microformats、Atom）の説明や、通信プロトコル、ヘッダー、ステータスなどのリファレンス的な情報などの説明もあり、基本的な技術をおさらいするのにはとても便利でした。

読書日記「その数学が戦略を決める」

イアン・エアーズの「その数学が戦略を決める」という本を飛行機の中で一気に読んで見ました。統計解析やデータマイニングが如何にして応用されているかを述べた本です。実際の統計手法に関しては殆ど説明していないので、数学が苦手な人にでも簡単に理解できるはずです。

本書では統計や、データ分析に基づいて答えを求めることを「絶対計算」と定義しています。そして経験と直感に頼る専門家の意見よりも、「絶対計算」の方が優っているという主張をしています。専門家の意見と統計とでどちらの意見が正しかったかという例をいくつも示し、人間は感情や先入観に左右されるため、ほぼ例外なく絶対計算が勝つと述べています。

まず、過去の大量データを利用し、様々な要因がどのような結果に繋がるかを分析する「回帰分析」により、以下のような分析ができ、それらが専門家の意見に勝ったという例を挙げています。

• ワインの値段を回帰分析で判断
• 野球選手の価値をデータで判断
• カジノでギャンブラーがいくら損してもリピートしてくれるか

また、大量の過去データがない場合でも、母集団から無作為にグループ分けをして、どのような違いが起こるか検査する、「無作為抽出テスト」をすることにより、以下のような判断ができると説明しています。

• AdSenseで複数のタイトルのうち、どのタイトルのクリック率が高いかテスト
• 金利を下げるのと、DMの広告に微笑む女の子の写真を使うのと、どちらが新規融資顧客開拓に有効か

また、この例のように、国民から無作為にサンプルを選んで、政策の有効性を検証することができるとも述べています。

• 失業者に求職支援をするのは有効か？->求職支援をした失業者には、その出費を上回る失業手当削減と税収が得られた

さらに、著者は情報処理の発達により以下の例のように専門家の仕事が絶対計算により置き換えられ、人間の役割は絶対計算のための仮説検証の仕事が主になっていき、専門家の地位が下がっていくと考えています。そのため、当然ですが専門家達は大きな反発をしているそうです。

• 医療データベースによる臨床医師の仕事の単純化
• ダイレクトインストラクションによる教師の仕事のマニュアル化
• 映画のシナリオさえニューラルネットワークによって判断されてしまう。（エパゴギクス社の例）

「絶対計算」という言葉はなんだか曖昧で好きではないのだけれども、統計やデータ処理に基づいた意思決定が専門家の直感より信頼できるという点は私も賛成です。情報処理の発達によって、今後もどんどんと今まで専門家が担っていたような領域に侵食していくようなことも容易に想像できます。

ただ、個人的には、データ分析などをするにしても、分析方法の決定（回帰分析の変数設定など）には専門家の関わる余地は大いにあると思います。ある特定分野への専門知識を持ち、基本的な統計知識をもった人が必要とされていくと考えられます。私が先行していた言語処理や、今の仕事の金融などの分野ではそれが当然のように行われているのですが、今後は政治、法律、医療など様々な分野に幅広く応用されていくのでしょう。

読書日記「集合知プログラミング」

O'Reillyの「集合知プログラミング」という本を買ってみました。この本はWeb APIや簡単なPythonのスクリプトを使って最近流行っているデータマイニングを広く浅く紹介している本です。



本当はもう少し統計的な面から捉えた、Rなどで説明している本を読もうかとも思ったのですが、僕から失われたWebサービス対する「勘」のようなものを取り戻すきっかけにならないかと思い、実際に公開されているAPIなどを多く利用しているこの本を選びました。

今回は、協調フィルタリングとクラスタリングを説明した２章と３章だけ読んで見ました。


第二章「推薦を行う」

協調フィルタリング(Collaborative Filtering)の説明です。これはAmazonの行なっているユーザの購入履歴から商品を推薦する機能や、似たようなアイテムを推薦する機能などに応用されている技術です。基本的なコンセプトは単純で、ユークリッド距離や相関係数でユーザやアイテムの類似度を測った後に、その類似度を重みとした加重平均を行ない、その結果を推薦度とします。主に、アイテムベースとユーザベースの2種類の方法があるそうです。

アイテムベース: まず、アイテム間の類似性を測り、ユーザが評価（購入）したアイテムに対し、その類似度に応じた加重平均をして、推薦度を算出。

ユーザベース: まず、ユーザ間の類似性を測り、その類似度に応じた加重平均をして（勿論、似たユーザの重みが大きい）推薦度を算出。

一般に、アイテムベースだと、アイテム間の関係はユーザ間の関係ほど頻繁に変わらないので、バッチなどで前もってデータを用意しておくことができるため、データのメンテナンスは必要になるがパフォーマンスは良く、疎なデータセットに対しても強いそうです。一方、小規模で変更が頻繁に起こるようなデータに対してはユーザベースが強いそうです。


第三章「グループを見つけ出す」


この章では教師なし学習の一種であるクラスタリングについて説明しています。第二章で測定したようなアイテムやユーザ間の類似度（もしくは距離）を元にして、似たアイテムをクラスタとして集めていくという方法です。本書ではブログをクラスタリング対象とし、ブログ内の単語の出現頻度をベクトル（列）とすることによってブログ間の距離を表現するという例を用いています。階層型クラスタリングとK-mean法によるクラスタリング手法を説明しています。

階層型クラスタリング: 
まず個々のブログをクラスタとし、すべての個々のクラスタ間の距離を測り、一番近い２つのクラスタを結合し新たなクラスタとする、という処理を繰り返す。これにより、すべてのブログを階層的に並べることができます。すべてのクラスタ間の距離を測る必要があるため計算量が膨大（クラスタリング対象の数の二乗 x ベクトル数）になる。（学生の時に悩まされました。疎なベクトルに対して使えるトリッキーなベクトル圧縮や計算方法を利用した記憶があります。）ブログと単語の列、行を入れ替えても動作するが、行（単語）の数が多くなるため計算量が増し、列（ブログ）の数が減るため精度が下がる可能性が高い。

K-mean法:
まず、任意の数の重心ををランダムに配置し、それに近い単語群でクラスタを形成する。さらに、形成されたクラスタの重心から近い単語群で新たなクラスタを作るという処理を、クラスタ内の単語が変化しなくなるまで繰り返す。はじめに選択されてた重心に結果が左右されるが、個々の単語の距離を測る必要がないため高速に動作するという利点がある。

その他、形成されたクラスタの二次元座標へのプロットの方法なども解説してありましたが、今回は読み飛ばしました。


実際のWeb APIなどを利用しており、簡単なスクリプトの例によって説明しているためとても実用性の高い本だと思います。簡単なレコメンデーションシステムなら２章のコードをコピペしてしまうだけで作れてしまうでしょう。

今回は２章と３章を少し時間をかけて読み込みましたが、本書のイメージは掴めましたし、さすがに全部このペースで読んでレビューまでこなすのはヘビーなので、一度簡単に全体をポイントだけ理解しながら読みつつ、興味のある部分は改めて細かく見てみたいと思います。

で、僕から失われたWebサービス対する「勘」が多少なりとも戻ったかというと。「Amazonのこの部分の推薦はアイテムベースでを使っているだろう」とか、「この間話した携帯ゲーム会社の人が話していたHadoopのバッチ処理もこのアイテムベースの類似度データを作ってるんだな」、くらいのイメージは湧きます。でも何か応用できる分野が見つかるかと言われると、、、うーん、例えば広告のWebクリック率履歴を利用してユーザ毎にカスタマイズした広告を出すとか？いやー、そんなものGoogleとかで確実にもう実装されてるよな。もう少し訓練が必要ですね。

読書日記「Googleを支える技術」

ちょっと分散システムの仕組みについて復習してみたかったので、昔読んで面白かった本を引っ張り出してみました。Googleの大規模検索システムが、どのような仕組みで動いていいるのかを、検索エンジンのクローリングやインデクシングから分散システムのハード（データセンターなど）とソフト（データベースやデータ処理）、さらにおまけで開発手法まで説明した本です。Googleのオフィシャルな本ではないですが、Googleの大規模検索システムの概要をとても分かりやすく易しく説明しています。コンピュータサイエンスのバックグラウンドがあれば専門領域が違っても一日で理解できるくらいの内容です。




今回は分散処理の仕組みだけチェックしておきたかったので、3章の「分散ストレージ」と4章の「分散データ処理」の部分を中心に読みました。Googleのシステムはデータやその処理を複数のコンピューターに分散することによって高速化やデータの扱う大規模化を図っています。また、処理を分散させるためのデータのコピーや、ハードウェアが壊れた時のフェイルオーバー機能をもたせており、2章と３章ではそれら仕組みが説明されています。

3章の「分散ストレージ」ではGFS、Big TableとChunkという3つの分散ストレージを紹介し、データの分散方法や、多重化されたデータベースに対するアップデート、エラー時の対応などが説明されています。

GFS
ハードディスク上のデータの大容量化、分散化を可能にする技術です。チャンクと呼ばれる細かい単位に分けられ、マスタによって場所などが保持される。データの読み込みはマスタにデータの場所を問い合わせるのみで簡単に行うことができる。ただ、書き込み時にはロック機能がないため不整合が起こる可能性がある。その代わり、ファイル末尾にレコード追加するような機能を備えており、これだとアトミックな操作はできるが同じデータを重複して書きこむ可能性もある。読み込み、書き込みともにスケールアウトするが、書き込み時にはデータ多重化のためにチャンクのコピーを伴うため読み込みより時間がかかる。

Big Table
ある程度構造化された大規模データを扱うためのテーブル。他のテーブルとのリレーションは持たないが、フィールドにはどんなデータでも格納できるというデータ構造。行キーのカラムキーとタイムスタンプの3つによってデータを特定することができる。ロックは行単位でのみ可能。データはタブレットと呼ばれる単位で分散して格納され、マスタによって管理される。タブレットへの書き込み操作はmemorableというログにジャーナルされ、それがある程度のサイズになったところで新しいタブレットが作られて、タブレットの分割や結合が起こる。

Chunk
ロックとイベント通知の機能を備えた小規模データ向けのストレージ。GSFやBig Tableなどの外部リソースのロック制御や、DNSとして使われている。レプリカと呼ばれるマシンで5重に多重化されており、その一つがマスタとして働く。

4章の「分散データ処理」ではMapReduceによる分散処理の仕組みの説明や、Sanzallという簡単にMapReduceの仕組みを使うためのスクリプト言語について説明しています。ほぼマシン台数に応じて比例してスケールするというかなり優秀な結果がでているそうです(サーバを50台から600台に増やしても1.3倍程度しかトランザクションが増加しないらしい)。

MapReduce
言わずと知れた分散データ処理技術です。データはKeyとValueのセットで扱われ、Map、シャッフル、Reduceという３つのステップにより行われます。Mapが個々のデータに対して分散して処理を行い、シャッフルが処理を終えたデータからKeyに応じてデータの並び替えを行い、ReduceがKeyごとにデータを集約し書きだすという仕組みのようです。

Sanzall
MapReduceの仕組みを使うためのとても簡単なスクリプト言語です。Map処理をスクリプト内に書き、Reduce処理はアグリゲータと呼ばれるパラメータ(Sum, Maxなど)を指定すると自動的に行われるようです。インプットとアウトプットのレコードを実行時に引数で指定すると自動的にGFS(BIG Table)からデータを読み込み、指定したMapReduceの処理を分散して行い、GFSへ結果を書き込みます。本書にいくつかプログラムの例があるのですが、使い方はとても簡単で、分散処理どころかプログラミングの経験すらない人でも簡単にデータ処理ができてしまうと思います。

MapReduceの分散処理のアイデア自体はとても単純なものだけれども、しっかりスケールアウトさせるためにどうデータやトランザクションを効率的に分散させるかであったり、エラー時や機器の故障時にも処理をとめることなくファイルオーバーさせる技術は、（本書ではコンセプトしか説明していませんが）とても複雑であることがよく分かります。その複雑な部分を隠蔽して、単純なスクリプトで扱えるようにしてしまう点には感心しますね。

本書はGoogleを支えているシステムの基本的な技術を知るにはとても良い本だと思います。完全に読み物的な本で、著者もGoogleのシステムに触れるわけではなく、コードの例が豊富にはなかったのでコードレベルでのイメージがしにくかったのがちょっと残念ですが、その辺りはHadoopをちょっと勉強してカバーしたほうがいいかもしれないですね。少なくともGFSやMapReduceに対応する仕組みがどのようなもので、どうやって使うかくらいは簡単に把握しておこうかな。

読書日記「はじめの一歩を踏み出そう―成功する人たちの起業術（マイケル・E. ガーバー）」

起業の勉強をすべく、本を呼んでみました。読んだ本はマイケル・E. ガーバーの「はじめの一歩を踏み出そう―成功する人たちの起業術」です。スモールビジネスの経営コンサルタントの方が書いた本で、売上は100万部を超えてアメリカでは起業家のバイブル的な本になってる（と帯に書いてある）そうです。「職人系」の起業家が「起業家」としての視点を持つことの重要さと、自分が現場にいなくても収益が上がる事業モデルの作り方を三部構成で説明しています。

Part1では失敗例を元に起業に対してあるべき姿勢や、美化された起業家像に乗せられて無計画に事業を始めると痛い目をみるよ、という事を説明しています。起業には「起業家」と「管理者」と「職人」がバランスよく協力し合うことが必要であると述べています。そして、僕のような職人タイプが専門知識があるだけで事業経営ができると勘違いして、従業員を雇い出した頃に経営的な視点や従業員のマネジメントを疎かにしたがために（例えば嫌いな経理を従業員任せにしてほったらかし）崩壊するパターンが多いと指摘しています。自分の創造力に任せて自由にプログラミングができるから起業するぞ、なんてだけ考えていると大ゴケする可能性大かもしれないですね。

Part2では事業モデルの重要性について述べています。起業とは、職人としての自分自身に依存することではなく収益を上げる事業モデルを確立することです。個々の専門家の能力に依存するのではなく、普通の専門家が最大限の結果を出せるようにシステム化された事業モデルを作ることができれば、その事業モデル自体が価値を持つことになります。組織の役割とその運営をマニュアル化し収益をあげられる事業モデルができあがれば、それにより自分の役割も他の従業員で交換可能になり、事業モデル自体が価値を持つので売却も可能になります。

Part3ではその事業モデルをどう作り上げるかを、「事業発展プログラム」として説明しています。

まず、事業モデルはイノベーション -> 数値化 -> マニュアル化というサイクルで作られます。例えば、紺色のスーツの営業員が茶色のスーツより売上が高いことを発見したので（イノベーション）、何パーセント高いのかを図り（数値化）、紺色のスーツ着用を従業員に義務付ける（マニュアル化）といった具合です。

著者の「事業発展プログラム」は以下の7ステップから構成されます。

1. 事業の究極の目標 - 自分の人生で何を成し遂げたいのか
2. 戦略的目標 - 収益目標や会社の規模、スケジュールなど
3. 組織戦略 - 組織図を作り役割を明確にする。それにより、従業員が増えた場合にも責任が明確になる。
4. マネジメント戦略 - 業務マニュアルなど、従業員に如何に働いてもらうかなどの管理システム
5. 人材戦略 - 従業員を動機づけ、思い通りに働いてもらうためのルール
6. マーケティング戦略 - 顧客がなにを求めているか、顧客にどう印象づけるかなど
7. システム戦略 - 上記の戦略のシステム的な統合

この数時間で読み終わってしまう本を読んだだけで起業の仕方が理解できてしまうわけはないです。ただ、起業とは「職人」としての自分の能力に依存せずに収益が上がる事業モデル（システム）を作るとこだというコンセプトと、そのモデルを作るための大まかなステップはよく理解できました。

自分が職人として会社で働く立場から、起業家として自分でその仕組を作る立場になりたいかと言われると、うーん、まだ具体的なイメージがないのでなんとも言えないですね。業務モデルを試行錯誤しながら作り上げていくプロセスはすごく面白そう。そのプロセスが身近に感じられ、自分もそれに貢献できるような小規模な起業で働くのも向いているのかもしれませんね。