海外サイトの形だけを真似た日本型クラウドソーシングの問題点

クラウドワークスを使っている受注者で、月の収入が20万円を超えたのが、わずか111名しかいなかったという発表が話題になっています。

多くの人が指摘しているように、これはユーザーがクラウドワークスを通さずに直接取引をしてしまうことによって、クラウドワークス上では多額の取引が行われないという構図になっているのだろうと思います。

なぜそういうことになるかというと、ユーザにとってクラウドワークス上で取引するメリットが全くないからなんですよね。サイト上で取引相手を見つけたら、手数料として高額な5～20%を払わずに直接取引に持ち込む方が圧倒的にお得なので、どうしてもそうなってしまいます。

さらに私も一度使ってみようとしましたが、とても概念が複雑でわかりにくく、使い方も難しいので、案件をポストしたけれど、取引には至らずにやめてしまいました。

こうした問題は、クラウドワークス（やたぶんランサーズ）が深く考えずにUpwork (旧称: oDesk)のような既存の海外クラウドソーシングサイトの形だけを真似たことが原因だと思っています。

以前、本ブログの記事でoDeskを利用して発注した体験談を書きましたが、Upworkというのは国際取引を主軸に据えたサイトなのですよ。インドやらウクライナやら、どっかの遠い国にいる、一度も会ったこともないし、永遠に会うこともないような人達と取引をするためのサイトなのです。

国際取引という性質上、Upworkには、業者が金だけ持って逃げてしまったり、発注者が金を払わないなどという事態を防ぐための機能が多数備わっています。

例えば、前払い金をUpworkが預かって、発注者のOKが出れば業者に支払をするエスクロー（第三者信託）機能や、業者がちゃんと働いていることを確認するスクリーンショット機能などがついているのです。さらに紛争が生じた場合には、商事仲裁機関による仲裁判断によって最終的な法的決着が得られるというサービスまであります。*1

なぜこういう機能が必要かと言うと、国際取引においては、もし紛争が生じたとしても裁判に訴えて決着することが容易にはできないからです。

もしウクライナの会社に金を持ち逃げされたとしても、ウクライナに行って現地の裁判所で訴訟を起こすというのは現実的ではないですよね。もし額が数億円ならともかく、数百万円なら泣き寝入りでしょう。そのために信託機能や仲裁機能がとても大事になるのです。

そのためUpworkは、システムの使い方が複雑になり、そのため使いにくく手数料が高くなってもよいので、このような多種の機能やプロジェクト管理機能を実装しているのです。機能として便利だから提供してるわけではなく、法的にどうしても必要だから実装しているのです。仲裁という紛争解決の仕組みまで備えた、法的な国際取引プラットフォームなのですよ。

だからこそ、ユーザーはUpworkを通じて支払を行うメリットがあり、Upworkを飛ばして直接取引に移行するのを躊躇するのです。

しかし日本国内での取引なら、このような機能は一切必要ありません。紛争が生じたら、実際に会って解決するなり、裁判所に訴えたり、ヤクザを雇って殴り込ませたり、すれば良いのです。

そのため日本のクラウドソーシングサイトには、Upworkのような複雑な機能は必要なく、単に受注者と発注者をつなぐマッチング機能だけあれば良かったのです。そして料金も、仲介手数料を取るのは難しいので、広告料などとして徴収すべきでした。

それなのにクラウドワークス等は、Upworkの形だけを見て、その精神を一切理解することがなく、形だけを真似てしまったので、全くおかしなことになってしまったのです。

これは日本のクラウドソーシング業界にとって不幸なことでした。これから改善されていくと良いのですが…。

1. 仲裁 - Wikipedia

ちなみに市場の制度設計の問題に興味ある人はこの本をどうぞ。大変良い本です。こういうサイトを作る人は、単にITシステムを作っているのではなく、経済学的な市場を創っているということを忘れないようにしたいものですね。

発注者側から「なぜ価値創造契約がうまくいかないのか」を考える

永和さんの「価値創造契約」が大苦戦を強いられている件 - GoTheDistance

永和システムマネジメントさんでは、アジャイルらしいシステム受託開発の方式として、ソースコードを納品しないで、利用中も継続課金するという契約方式を試行しておられます。

それが実は苦戦しているそうだということが、永和さんの発表資料から話題になっています。

私もソフトウェア開発を外注することも良くありますが、たしかに発注者の立場からみると、開発中も利用中もずーっと継続課金させるという課金方法で発注するのは、かなりうまくできた仕組みでないと難しいかなと思います。

当たり前ですが、ソフトウェア開発･運用を考えれば、開発フェーズの方がずっと重く、運用フェーズの方がずっと軽いわけです。

ですから、通常の契約では開発フェーズは多くの費用を請求し、運用フェーズでは少ない費用を請求するということになります。それは理にかなったやり方だと思います。

もし納品しない方式であれば、「開発フェーズの金額は受注者が負担し、長期的に回収する方式」なら発注者にはリスク低減メリットがあるでしょう。もしそうではない（稼働時間分を全て請求するor請求金額分しか稼働しない）のなら、単に発注者に対して余計なコストを背負わせているだけということになります。

価値創造契約では、開発フェーズの負担は永和さんが負うように見えますが、その部分をどのような計算で、いくらくらいの開発費や工数を永和さんが負担し、その金額をどのように後日の請求に回していくのか、ということがウェブサイト上では明確ではないように見えます。

経済的に見て、誰がどのように開発費などを負担し、それをどのように償還していくのかということを、きちんと経済学やファイナンスの知見を踏まえて、経営者にとって分かりやすいように説明する必要があるかと思います。

「スモールスタートで」と言うことが書かれていますが、わざわざ支払を繰り延べしてリスク低減する必要があるシステムというのは、スモールスタートよりも社運を賭けた一大プロジェクトのようなものになるのではないでしょうか。

スモールであれば、べつに一括発注でも、普通に人月契約でプログラマを雇って作らせても全く構わんわけですから。失敗すればまたやり直せばよろしなので。

永和さんには、まずファイナンスやミクロ経済学の観点から（リース契約などに習って）契約形態を見直し、ウェブサイトの記述なども見直し、経営者から見てメリットがある形に整理する必要があるかと思います。

もちろん契約書などもかなり入念にレビューして、双方にとって妥当性のあるものにしなければならんでしょうね。

ではでは。

2014/9/19 追記: あと顧客にとって特定の契約形態を押しつけられて売り込まれても何のメリットもないので、プッシュ営業するのは無理だと思いますね。あくまで選択肢の一つという形で提示しておいて、引き合いがあれば提供するという形でないと無理かと思います。

真の人月商売こそが受託開発産業を救う ― 請負契約ではITプロジェクトは失敗する

私は自分では受託開発を原則として請けないことにしていますし、受託開発という産業にはあまり興味がありません。しかし現実問題として日本のソフトウェアビジネスの大半は受託開発産業です。

また自分では受託開発を請けないけれど、他人や他社にプログラミングを外注することはあります。今日は、受託開発のお話です。


受託開発産業でよく言われることに「人月商売からの脱却」などというフレーズがありますが、そうした発言はまさに愚の骨頂と思います。経済やビジネスの原理原則を知らない愚かきわまりない発言です。

受託開発というのは、プログラマーという専門職の時間を使って作業を提供して、その成果物を納品する仕事なのですから、コストは当然プログラマーの作業時間となります。

商品の値段というのは、通常はコストに利益を乗せて売られますから、プログラマーがどれだけ働いたかで算出されるのは、きわめて自然な値付け方式です。

「そうではなく、そのシステムが顧客にどれだけ価値をもたらすかで売りたい」という人がいますが、顧客の注文で作るシステムなのですから、その価値は顧客しか知りませんし、その顧客の価値を開発者が得られる理由がありません。

もしソフトウェアの価値でお金を取りたいのであれば、受託開発をやめて、自分で製品を作るべきです。もしくは受託開発で作ったものを、他社にパッケージ販売すればいいでしょう。そうしてみればソフトウェアの価値は良く分かります。

マッキンゼーなどの戦略コンサルタントから、建設業界まで、顧客の注文に応じてサービスを提供する企業では、基本的には労賃＋材料費といった計算方法で価格を決めています。

その人月単価をいくらにできるのかは、プログラマーの能力と、企業のブランド力や交渉力/営業力次第でしょう。人月だからといって、プログラマが一律に同じ値段でなければいけない理由がありません。


日本の受託開発産業を悪くしているのは、人月計算ではなく、請負契約などによって受託企業に成果物への責任を負わせる契約慣行です。

あらかじめ完成品の総額を決めて、それから開発にかかるという方式の請負契約は、ソフトウェアのように細かい仕様が全て先に決まらない業界には全く適していない方式です。ソフトウェアの開発は、製造や工事よりも研究開発に近い性質のものであり、見積もりを前もって正確に行うのは極めて困難です。

そうして請負契約でプロジェクトが開始されれば、始まるのはお決まりのパターンです。

発注者は可能な限り多くの仕様を詰め込もうとし、様々な点で修正を求めてきます。それにたいして受注者は、リスク分を見積もりに大幅に上乗せし、仕様をなるべく簡略化しようとし、変更を拒否することを試み、なるべく安いプログラマを使って最小のコストで最低限動くものを仕上げようとします。

これはまさにlose-loseの状況です。

こうした契約形態のせいで、予算超過リスクを負える大企業がシステムを受注し、それを多重下請け形態で、プログラマのスキルとは無関係に、ただ大量の人を集めて、低い品質のシステムをでっちあげるという歪んだ産業構造が生まれました。

請負契約は、あらかじめ仕様を細部まで詰め切れるプロジェクトにしか適用できません。

数十万円の超小規模案件ならそれでも良いでしょうが、大きなプロジェクトになると、仕様策定自体が一大プロジェクトになってしまい、ウォーターフォールで多くの仕様の誤りが生じるので無駄過ぎますね。ルールの厳格な政府調達ならともかく、民間企業がそんな無駄をする理由はありません。


ソフトウェア開発というのは、建設業よりもコンサルティング業に近い産業です。

あらかじめ仕様と設計を細部まで定義して、それにもとづいて見積もりを立てるウォーターフォール方式が良い方法ではない以上、成果を約束させるのではなく、拘束時間に基づいてお金を払うしかありません。準委任契約/派遣契約などに切り替えるということです。

その場合、請負契約のように総額の予算や納期が契約で決まっているわけではありませんし、プロジェクトマネジメントは発注側で行い、発注側が予算や納期について責任を負うことになります。もし発注側にプロマネを出来る人がいなければ、ITコンサルタントなどを雇わなければなりません。

しかし、それにより、発注者と受注者は同じゴールに向かって歩むことが可能になります。「良いソフトウェアを作る」という共同のゴールを持つことができるようになります。

日本でも、いまどきのインターネット企業などでは、請負契約で業者にシステムを作らせているところはないでしょう。そんな方式では、開発速度も遅く、品質も下がってしまうので、競争を勝ち残れません。

一般企業にとってもITの重要性が増す中で、良いソフトウェアを作るためにソフトウェア内製化などに切り替える企業が増えているといった話もあるようです。


発注者側にとって、時間払いの新方式に切り替えるのは、そこまで難しい話ではありません。プロマネをしてくれるITコンサルタント企業さえ見つかれば、実現できるでしょう。

この新方式では総額が決まっていないので発注者にとって余分なリスクがあるようにも思われますが、実際は逆です。

できてもいないシステムの総額にたいして請負契約を結べば、受注者がへぼい仕事をしても途中でキャンセルすることもできず、結局はお金を払ったのにへぼいシステムしかできないというリスクが大きいのです。

それに対して、時間払い方式であれば、品質に満足できなければ合理的な予告期間のあとでいつでも契約を終了することができるでしょう。これはリスクを減らす方向に働きます。

とくに最近はシステムが完成しなくても、どんどん出来たところから動かしてみて、品質を顧客がチェックしていくことができるので、よりこうした方法は実現しやすくなりました。


受注側がこの方式に切り替えるためには、顧客側にも変化を要求することになるので、もっとハードルが高いです。

しかし株式会社ソニックガーデンのように、顧客にこうした方式を要求して、実践している会社もあります。

報われない、疲弊するといった悩みを抱えている受託開発企業は、契約形態を見直して、本当に顧客のためになる仕事をできるように変えていくしかないのではないでしょうか。

人月からの脱却ではなく、真の人月として、働いた時間に応じてお金をもらう、それがプロフェッショナルの働き方だと思います。ワインバーグは「コンサルタントの秘密」で何十年も前にそれを述べています。

では。

oDeskで本格的な開発プロジェクトをやってみたよ

oDeskをつかって本格的なソフトウェア開発プロジェクト(1人月)をやってみたので、そのご報告です。oDeskをつかってみようと思う方には、かなり参考になるのではないかと思います。

oDeskとは、世界中にいるフリーランサーやアウトソース企業にさまざまな仕事を頼むことができるアウトソースサイトです。他のサイトと比べた特徴としては、作業内容の記録ツールを使った時給払いに対応していることです。クレジットカードで支払いできて送金も楽ちんです。

今回なぜoDeskを使ってみたかというと、純粋に海外アウトソーシングに興味があった点が一つ、もうひとつは少しでも開発コストを減らせないかという考えがありました。

開発コストの観点から言うと、oDeskで雇える人のうち、しっかりした実績があるような人の時給は$25くらいに設定されているので、人月40万円くらいの計算になります。

日本でもジュニアプログラマなら人月40～60万円くらいで雇うこともできるのではないかと思いますし、相当優秀なシニアプログラマでも人月80～120万円くらいなことを考えると、コスト削減効果としては、ちょっと微妙です。クラウドワークスを見れば、時給2500円くらいで働いてくれそうな人がごろごろいますし・・・

そういうわけなので、今回oDeskでの発注に踏み切ったのは、海外アウトソースの実情を知りたいという好奇心の点が大きいかもしれません。


使ってみて最初に思ったことは、プロジェクトマネジメントがしんどいということです。

英文でやりとりしたり、英文仕様書を書いたりする手間を考えると、プロジェクトマネージャーである私の作業時間が取られてしまいます。

そしてお互い外国に住んでいるわけなので、もしトラブルになったとしても訴訟などを通じて解決することは現実的ではなく、すべてを慎重に交渉して進めていく必要があります。また赤の他人に依頼するとなると、やりとりにもかなり気を遣います。

通常の開発案件であれば、国内の安いフリーランサーを見つけて、そういう人に頼むほうが楽なのかなー、と思いますね。そういう人が、うまく見つかればですけど。

もともと英語で開発してるとか、全世界向けに開発してるような会社であれば、oDeskはお勧めですけども、日本語でやってる普通の会社にとっては言葉の壁が厚いです。


今回の案件に関して言うと、かなりうまくいったと思います。

まず依頼した時点で、時給が高くても、きちんとした返事を返してきたウクライナの業者を選定しました。oDeskでは、雇う対象をフリーランサーに絞るよりも、業者に任せた方が安心感があると思いました。

彼らは、25ドルの時給の中で、プログラマーだけでなく、英語が上手な連絡担当者も担当者としてつけてくれました。なにか問題や不明点があれば、すぐに聞いてきますし、きちんと着実に仕事を進めていきます。こっちからいちいち突っつかなくても、向こうから主導的に仕事をしてくれます。

結果的に、日本で外注したときの予想価格に比べて、半額くらいの値段で、きちんとした品質の製品を完成させることができました。

日本のシステム開発業者と比べても、かなりそつのない真面目な仕事をしていると思います。この値段で、この品質でやってくれる会社があるのだから、アメリカなど英語圏のプログラマーは大変だろうなあ、と思いますね。


僕はあまり自分の仕事能力に自信を持っていないのですが、英語で一つプロジェクトを完遂させることができて、すこし自分の能力に自信が持てた気がします。

なぜAmazon Web Servicesを使うべきなのか

弊社では、ぼちぼちとAmazon Web Services (AWS)を試用してきておりますが、色々使ってきてみて思うのは、AWSは素晴らしいシステムであり、特別な用途を除けば原則としてこれからのシステムはAWSで構築するのが良いのかなと思いますね。

AWSが優れている理由は、とにかく運用やソフトウェア開発を楽にする機能が豊富に揃っており、運用までをフルサポートしてくれる垂直統合環境であり、APIやソフトウェア、ドキュメントの品質や使いやすさが極めて優れていることです。そのため、システム開発運用のコストが大幅に下がり、システム運用の品質を上げることができます。


まずAmazon EC2 (仮想マシンホスティング)から説明すると、一つにはAmazon LinuxというEC2専用のLinuxがあることは大きなメリットです。

Amazon EC2のインスタンスに最適化されていますので、簡単に安定利用できるだけでなく、OSアップデートもyum updateするだけで安心して行うことができます。そのため、サーバーが陳腐化してシステム移行が必要になることがありません。これにより、システム移行工数(数人日～数人月)が削減できるのは大変なメリットです。より大きいサーバーに変えることも一瞬でできます。

EC2の有用性はEBSという外部ストレージのサービスを使うと、さらに強化されます。インスタンスのスナップショットによるフルバックアップを１クリックで取ることができますし、スナップショットをひな形にして新しいサーバーを立ち上げることも簡単にできます。(自動で定期的にフルバックアップを取得する機能がないのは不可解ですが....)

Amazon Route53は、DNSのホスティングというニッチな領域ですが、非常に便利なサービスです。AWSの持つ信頼性や、グローバルな拠点を活かして、世界中の顧客に高速なDNS解決を提供できます。もう、わざわざ脆弱性だらけのBINDなどをDNS権威サーバとして使う必要はゼロでしょう。

Amazon S3は、システム開発を圧倒的に簡単にするという点で大きな価値があります。これまでは一つのサーバーの容量を超える多数のファイルを格納するためには、極めて高額なストレージ製品を使うか、独自で分散ファイルシステムを構築しなければ行けませんでした。それがS3では、圧倒的に簡単に運用を行うことができます。

Amazon S3とGlacierを利用すれば、ログやバックアップなども簡単かつ安価に保存していくことができます。

DynamoDBのような分散データベース環境は、素人が運用するのは極めて困難ですので、それが管理まで任せられるというのも大きなメリットだと思います。ただし現時点では、１クリックでバックアップを取るような機能がついていませんので、その点では運用性がまだいまいちかなと思います。

Amazon Cloudfrontは、コンテンツ配信システム(CDN)であり、ファイルや画像などを世界中に高速配信することができます。弊社では、一部サービスで海外からの表示を高速にするために使っています。Akamaiのような高額なCDNに比べて、無料みたいな値段で使えるので、ちょーおすすめです。


AWSを使う上で気をつけるべき点としては、EC2は他社レンタルサーバーより割高なことと、メール送信に許可が必要なので非常に面倒くさいことですね。

まずEC2から外部へメールを送るためには、基本的に許可を得ないと送れません。その時点でかなり面倒です。さらに不着率が高かったりすると許可を剥奪されます。

Amazon SES(バルクメール送信サービス)を使ってメールを送信すると30%程度の不着率で数千件メールを送っただけで、許可を剥奪されてしまい、英文で釈明するはめになりましたので、非常に使いにくいかなあという印象です。

メールサーバーは別のサーバーを利用するなり、他社のサービスを利用するなりしたほうが良いかもしれませんね。このあたり改善を期待したいところです・・・

ほかにAWSが不向きなシステムとしては、大量の計算資源を継続的に使い続けるものですね。やはりその場合は、自前で構築する方がずっと安くなります。但し、大企業や官公庁が大手システムインテグレーターに依頼して構築・運用するよりはAWSの方が安いと思いますが。

例えば、動画配信など、継続して大量のストレージや回線を使う場合があるでしょうか。またHPC(スーパーコンピューター)なども継続してずーっと使い続ける場合も同様ですね。この場合は、色々とハードウェアやデータセンターの調達を工夫することで、自社調達すれば、AWSよりもコストを下げることができると思います。

弊社でも動画のストレージは自社で運用してますが、S3よりもストレージコストは大幅に割安です。そのあたりは工夫次第かと思います。

うまくAWSを使いこなしていくことが今後のシステムでは基本となることは間違いないと思います。AWSは他社に比べると機能や技術力で圧倒的に上をいっていますので、しばらくはAWSの圧倒的優位は揺らがないでしょう。

クラウド以外ですと、市販ソフトウェアやオープンソースソフトウェアで、AWSと同じような機能を謳う物はいろいろありますが、あまり信用しないほうが良いかと思います。実際はうまく動かなかったり、操作性や運用性が著しく悪かったりと、品質問題が多発しますので。

レンタルCTOはじめます

注: 写真はイメージです。

こんにちは、新井です。

個人の取り組みとして、新たにレンタルCTOという活動を始めてみようかと思います。すなわち非常勤の技術コンサルタントとしてベンチャー企業などにアドバイスを行う試みです。

昨今の経営環境では、IT技術の活用が必要不可欠となっていますが、一般企業が優れた技術者を見つけることは容易ではありません。しかし、経営陣にIT専門家がいなければ、ITを高度に活用してビジネスを行うのは難しいのが現実です。

そうした企業の技術参謀役として、ビデオミーティングなどによりアドバイスを行う「レンタルCTO」業をはじめます。


私は、日本を代表する著名技術者ではありませんし、最優秀の経営者でもないでしょう。しかし技術と経営の両方を分かっていて実践している人材という点では、日本では極めて稀少な部類かと思います。いわゆるコンサルタントなどと違い、いまもプログラミングや経営を自分で行っていますので、実用的な知見を提供できます。

これまで、有料動画配信モール、名刺管理ITサービスなどの企画・開発・運用までに携わってきました。動画配信モールは、現在では100TB以上のストレージ容量を運用する巨大なサービスとなっています。

この動画配信モールは、私に開発依頼があったときには、P2P技術を使って安価に動画を配信するという企画でした。しかし私がP2P技術のメリット・デメリットをお話しして、P2Pは今回の案件には適切ではないことをご理解頂き、最終的には通常のサーバーから配信する形式で開発することになりました。

日本でP2P技術で動画配信を行う事業は一つもうまく行かなかったことを考えると、この選択によってビジネスを失敗から救うことができました。

このように、適切な判断のできる高度な技術者を経営判断に活用することは、テクノロジービジネスにおいては必須であると考えます。「プログラムが書けます」というレベルの技術者と、経営判断をゆだねる技術者に求められる知識は全く別のレベルです。


私にとっても、レンタルCTO役をやることで、これから新規事業を手がけるにあたり、様々なビジネスから知見を得たり、新しく優秀な経営者の方々とお知り合いになれるのではないかと期待しています。

私自身の新規事業開発の時間もあり、コンサルティングに使える時間は限られていますので、先着３社までの限定でお受けさせて頂きます。

お互い相性が大切かと思いますので、まずは気軽にお問い合わせ頂き、チャットなどでお話しできればと思います。

お問い合わせは arai [at] mellowtone.co.jp まで。

レンタルCTO基本プラン
* 毎月10万円 (年商1億円以下の企業や個人事業主は毎月5万円に割引します)
* 4時間のビデオミーティングを2回/月
* メールとチャットは無制限 (回答までの時間は無保証)

お手伝いすること:
* IT活用ビジネスに関する企画のアドバイス
* 技術者の採用および、ITアウトソーシングに関するアドバイス
* 基本的な開発プロセスマネジメントに関するアドバイス
* 基本的なITセキュリティに関するアドバイス
* 技術基盤(アーキテクチュア)に関するアドバイス
* システム設計、開発、運用に関するアドバイス

得意な領域:
* ビジネスと技術にまたがる領域 (テクノロジービジネスの企画等)
* ウェブビジネス
* ITベンチャー企業 (受託開発業を除く)
* システム設計
* データベースアプリケーション
* システムの高速化

得意でない領域:
* 大規模エンタープライズシステム
* 大規模プロジェクト
* 市販業務パッケージの活用ノウハウ
* ゲーム開発
* ソフトウェア受託開発業
* 先進的な開発プロセスマネジメント (アジャイル、テスト駆動開発、継続的インテグレーション等)

週四時間だけ働く

連休中は海外旅行に行っていました。そこで読んだ二冊の本が、福翁自伝と、「週４時間」だけ働くです。この二冊はたまたま意外と似通った主張を持った本であったことが面白い点です。どちらも「独立」がテーマである点で共通しているのです。

本稿では、まず「週四時間だけ働く」をご紹介します。


「週四時間だけ働く」は翻訳された当時は結構な話題となったようです。いかにして自分の働く時間を減らしていくかという本です。そのためにアウトソースを活用したり、雑用などを減らしたりしていくことが載っています。

私は、現在推進中のメイシーという事業では、小林というパートナーと一緒に仕事をしています。が、新規事業をやるにあたり、小林が既存事業の運営で手一杯のため、次は久しぶりに自分一人で推進することになりました。

一人で事業を推進するためには、とにかく雑用や人との面会などを極限まで減らす必要があります。もし雑用をしていたら、事業戦略や研究開発に十分集中できなくなって、私の強みを活かすことができません。

そのために本書を読んで、週四時間の考え方や実践法を学ぶことにしました。本書は、自己啓発本的な要素と、事業の構築法、事業の自動化方法などの実践的な要素が、半々くらいの割合で混ざっています。いかにもADHDの人が書いたような飛び飛びの本で、すこしごちゃごちゃしてるのですが、読みにくい本ではありません。

本書の主張は、以下のようなものです。

１．とにかく雑用や不要なタスクを減らせ、断れ。そして自由を勝ち取って旅行しまくれ！
２．自分の事業や副業を立ち上げて、それをITやアウトソースを活用して完全自動化しろ！ そうすれば一切働かなくても金が入ってくる。

いかにも怪しい主張です。普通の人がこれを読んで真似をしてもうまくいくかどうか定かではありません。しかし事業家にとっては非常に役立つ考え方が多いと思います。しばしば雑用に埋もれてしまい、本来、社長がやるべき重要な仕事ができてない人が多いですから。

本書の著者の事業では、秘書、サポートセンター、物流(フルフィルメント)などを全てアウトソースすることで、自分はマーケティングだけに注力すれば良いという仕組みになっています。アメリカはアウトソース先進国なので、容易にここまでのことができるようですが、日本でもこうした仕事のアウトソース先は色々あるだろうと思います。

ITの世界で普及してきたelanceやodeskのようなクラウドソーシングも紹介されています。

とくに面白いと思ったのは、秘書をインドにアウトソースする方法です。個人的な秘書から、ビジネス上の秘書まで、オンラインで完結する仕事はすべてインドにアウトソースできるとのことです。これは英語圏ならではの強みですね。

マーケティングについては、ダイレクトレスポンスマーケティングの初歩が説明されています。ダイレクトマーケティングについては、稿を改めて良い本を紹介したいと思います。

こうした工夫を活かすことで、著者の事業では一人も従業員を雇うことなく成功を収めています。

経営者には一読の価値のある本です。経営者でない人も、独立心を養うために読んでみても良いかもしれません。