僕の個人開発を成功に導いてくれた本たち
成功者から学び、それを直ちに実践しろ
English version is available here
こんにちは、TAKUYAです。あなたが安全で健康であることを願います。さて、読書はプロダクト制作を成功に導くための重要な習慣です。インターネットには沢山の無料で読める記事があり、それらを読むのは面白いし役に立ちます。でも特定のトピックについて深く詳細に学びたい場合は、本を読むのが非常に有効です。本稿では、僕が読んで実際に拙作プロダクトで実践して、とても役に立った本をご紹介したいと思います。
まとめ
- プロジェクトが行き詰まっていた時、読書を始めたら上手くいくようになった
- 周りにアイデアを話しただけで満足するな
- 事業立ち上げ: Getting Real by Basecamp
- マーケティング: Marketing Lessons from the Grateful Dead by David Meerman Scott & Brian Halligan
- 生産性: The Goal: A Process of Ongoing Improvement by Eliyahu M. Goldratt
- その他のおすすめ
- 今すぐ実践しろ
プロジェクトが行き詰まっていた時、読書を始めたら上手くいくようになった
僕は2016年末頃から一人でInkdropというMarkdownノートアプリを開発しています。この拙作アプリがなぜ収益化に成功(MMR = 80万円)したかというと、その大きな理由は本を読んで実直に実践してきたからです。2012年ごろまで、僕は読書の習慣がありませんでした。当時、沢山の人を惹き付けるようなアプリを作ることは出来るものの、そこから収益を生むことがなかなか出来ませんでした。例えば、音楽推薦アプリ「walknote」を作って13万人超の登録ユーザを獲得しました。そのモーメンタムはとても熱いものでしたが、マネタイズして運営を継続することが出来ず、あえなくクローズすることになりました。このアプリは、自分が便利で人気が出るようなアプリを作れる能力の裏付けとなり、フリーランス活動をする上では大きな実績となりました。しかしながら、僕はこの結果に満足していませんでした。僕はフリーランスではなく独立したアプリ開発者としてどうしても成功したかったのです。その後、完全に燃え尽きてやっと気づきました — — 自分はマーケティングやマネタイズについて、世の中の成功した人たちから学ぶ必要があるという事を。でもどの本を読んでいいか全くわからなかったので、良さそうな本を片っ端から読み始めました。
周りにアイデアを話しただけで満足するな
Inkdropを作る前のかつての自分には悪い癖がありました。それは、思いついたアイデアを自分と同じような（まだ）それほど成功していない友人などによく話していた事です。なぜそれが悪い癖かというと、彼らは自身の経験からどうやってプロダクトを収益化するのか知らないからです。つまり僕と同じ問題を抱えていたのです。そんな彼らと、どうやったらビジネスを成功させられるかという議論で勝利して満足していました。一度も成功させた事もないくせにです。アイデアを誰かに話して同意を得るのは楽しいです。しかしそれだけです。もちろん、口に出すことで思考が整理される事は多少ありますが、だからといってその考えや計画が上手くいく保証にはなりません。自分の場合、まったく上手く行きませんでした。なので、話すのをやめて成功した人たちから本を通じて学ぶことにしました。
僕は活字が嫌いでした。退屈だからです。どちらかと言えば漫画とか映画を好みました。しかも、成功者はその秘密をあまり人に公開しないと思い込んでいました。いいえ、全員ではありませんが、世の中には彼らが本当の知見を教えてくれるような本があります。そして、本がとてもインスピレーションを与えてくれるものだと気づいてから、僕は昼夜問わず読み耽るようになりました。
洋書は原著を読もう
これからご紹介する書籍にはすべて日本語版があります(注: Getting Realは今確認すると日本語版が無くなっていた)。しかし出来れば原著を読んでほしいと思います。特にあなたが英語圏をターゲットにしたサービスを考えているのなら。ソフトウェアやインターネットの素晴らしいところは、地理的制約に縛られない点です。なぜ日本語圏に自分を制限する必要があるのでしょうか。あなたは優秀です。ちょっと海外の人たちと交流すればわかります。自分の腕が意外なほどに通用するという事を。日本はこれから人口が減り、経済も下降する事が確定しています。だから外貨を稼ぎましょう。外貨を稼ぐにはまず英語に普段から慣れ親しむ事が重要です。言語の違いだけで大きな機会を逃すのは非常にもったいないことだと思うのです。1日1ページだけでも構いません。「出来るようになってからやる」では永遠に時間の無駄で、世の中の出来る人は「やってたら出来るようになった」と口を揃えて言っています。
Getting Real by Basecamp
この本は僕が個人開発者として進むべき方向を照らしてくれました。今でも繰り返しメモを読み返しています。かつての僕はアントレプレナーシップやスタートアップ文化に強く影響されていて、「スティーブ・ジョブズみたいにビッグになるぞ！」とか「facebookみたいな世界を席巻するサービスを作らなきゃ！」と息巻いていました。イタイ。同書は世界を獲ってビッグになることだけが成功の道ではなく、他にもソフトウェア開発で人生を謳歌できる方法がある事を教えてくれました。これはSaaSビジネスの立ち上げを、より少なく、本当に重要な事にだけ取り組む事で成功に導く方法について解説した本です。同書の中で好きな節を紹介します。
What’s your problem? — The key here is understanding that you’re not alone.
If you’re having this problem, it’s likely hundreds of thousands of others are in the same boat. There’s your market. Wasn’t that easy?あなたの問題は？ — 重要な点はあなたが独りではないという事だ。もしあなたが何か問題を抱えているなら、同じ人が何百、何千人といる可能性が高い。そこにマーケットがある。簡単だろ？
自分が斬新と思えるようなアイデアを思いついても、だいたい他の人が同じか似たようなアイデアを既に実行しているものです。でもそこで諦めるのはまだ早い。ポイントは、他より自分のほうが３倍上手にその問題を解決できるぞ、と思える部分を見つけられるかどうかです。
It’s a Problem When It’s a Problem — Heck, we launched Basecamp without the ability to bill customers!
その問題は、実際に問題になってから考えろ — くっそ、俺たちはBasecampを課金システム無しで公開したんだ！
Inkdropも課金システム無しで立ち上げました。
Make Opinionated Software — They say software should always be as flexible as possible. We think that’s bullshit. The best software has a vision.
And remember, if they don’t like your vision there are plenty of other visions out there for people. Don’t go chasing people you’ll never make happy.信念のあるソフトウェアを作れ — みんなソフトウェアは可能な限り柔軟であるべきだと言う。そんなのはデタラメだ。最良のソフトウェアはビジョンがある。そして覚えておくんだ、彼らが君のビジョンを気に入らなくたって、人々には他にも山程のビジョンがある。君が喜ばせられないと分かりきった人たちを追いかけるな。
僕はInkdropをもっぱら個人用のMarkdownノートアプリとして作りました。そのために、沢山の機能要望に毅然として「No」と言ってきました。チーム対応、ファイルシステムベースの同期や、オープンソース化などなど。もしこれらにYesと応えていたら、今頃アプリは膨れ上がって重くなり、メンテに手が負えなくなっているでしょう。そのお陰で、アプリのコードベースは今もシンプルでクリーンに保てています。
Don’t be a yes-man — You should only consider features if they’re willing to stand on the porch for three days waiting to be let in. We listen but don’t act. The initial response is “not now”. If a request for a feature keeps coming back, that’s when we know it’s time to take a deeper look.
イエスマンになるな — もし彼らが玄関で３日間待ち続けるほど欲しがるような機能で無い限り、その機能を検討すべきではない。一応意見は聞くが、最初の答えは「今じゃない」だ。もしその機能要望が何度も来るようであれば、初めて深く検討する。
現状の機能性に満足している人たちは基本的に何も言いません。誰かが変更を持ちかけた時、この事実を思い出してください。
「なんでブラウザ対応してないんだ？」という質問に対する答え：「なぜなら俺がタブを好きじゃないから。俺は俺が使わないモノは作らない。」
みんなより沢山の機能対応を望みますし、それに対してYesと応えるのは簡単です。なぜなら深く考えなくていいからです。でもあなたに強く関係する事だけに集中することはとても重要です。自分の場合、それは自分が使いたいものです。それが僕自身のモチベーションを保ってくれます。
Less Software — Each time you increase the amount of code, your software grows exponentially more complicated.
より少ないソフトウェア — コードの量を増やす度に、君のソフトウェアは加速度的に複雑になる
これは非常に大切な事です。特にあなたが独りの開発者なら。僕はコードの行を削除する行為が大好きです。行数は少ないほど良い。ユーザは「私が個人的に必要なので、この機能をオプションとして追加して欲しい」と言う傾向がありますが、僕は滅多にYesと答えません。なぜならプリファレンス(設定項目)の追加はコードベースを酷く複雑にするからです。バグはいつも自分が使っていない機能から出てくるという事を嫌ほど経験してきました。プリファレンスはバグの温床です。
Ride the Blog Wave — Start off by creating a blog that not only touts your product but offers helpful advice, tips, tricks, links, etc.
Our Signal vs. Noise blog gets thousands of unique readers a week thanks to the helpful, informative, and interesting bits and anecdotes we post on a daily basis.ブログの波に乗れ — 自分のプロダクトについてだけでなく、役に立つアドバイスや小ネタやリンクなどについても書くブログを始めるんだ。僕ら「Signal vs. Noise」ブログは毎週数千のユニークビジターがある。毎日のように面白い話や役に立つストーリーを投稿しているおかげだ。
沢山の開発者が自分のプロダクトについてしか書きません。あなたは自分の痒い所を解決するアプリを作りました。ならば、あなたはアプリが解決する事柄について沢山の事を書けるはずです。僕はモノづくりが好きで、その制作を助けるツールを作りました。なので僕はより良いソフトウェアを作る方法について詳しく知っていました。そこで、その事についてブログに書き始めました。その結果、広告を使わずともブログ記事が人を集めてくれました。
同書にはこの他にも沢山の金言があります。ぜひチェックしてみてください。
Marketing Lessons from the Grateful Dead by David Meerman Scott & Brian Halligan (HubSpot CEO)
日本語版: グレイトフル・デッドにマーケティングを学ぶ
僕ら個人開発者はアーティストのようなものです。なぜならユニークなモノを作り、ユニークな方法で届けるからです。なので、僕らはアーティストから沢山学べることがあります。
この本は伝説的ロックバンド「The Grateful Dead」について書かれたものです。たぶんあなたはこの古いバンドを聞いたことが無いかもしれません。僕も知りませんでした。なぜなら彼らはメジャーの音楽業界でのヒットがありません。テレビにも出ず、それでもバンドは1900年代後半において著しい成功を成し遂げました。彼らの熱心なファンはデッドヘッド(Deadheads)と自分自身を呼ぶことで知られています。個人開発者にとってこのバンドが人々を魅了してきた方法は、ファンベースのバイラルマーケティングとして非常に参考になります。なぜなら、彼らのアプローチは大きな予算を必要とせず、マス広告に頼らず、強力なファンの口コミによるもので、とてもシンプルで実行可能だからです。それらを実践することで、僕は14,000のサインアップを獲得しました。従来のPRファームを雇って話題を作ったり、PPC(pay-per-click)広告キャンペーンを打ったりなどは一度もしませんでした。僕がした事は、ただ自分のプロダクト制作の秘話をソーシャルメディアやブログでシェアしただけです。ここで重要なのは、なぜ自分のストーリーを語るのが有効か理解する事です。なぜならほとんどの人は何をシェアしたらいいか、どう表現したらいいか、なぜうまく行くのか分からず、そして書くのをやめてしまうからです。同書はその方法について詳しく教えてくれます。
The Grateful Dead’s concerts were completely unscripted, which meant that band members often made mistakes. (…) Their fans understood and accepted this as part of the Grateful Dead experience. After all, they were human, too.
Grateful Deadのコンサートは完全に即興で、それはつまりメンバーが頻繁にミスを犯すという事だった。(中略) ファンはその事を理解していたし、体験の一部として受け入れていた。要するに、彼らも人間だという事だ。
つまり、あなたはあなたのままで良い。完璧じゃなくてもいい、という事です。完璧主義を投げ捨てましょう。プロダクトの構築はまるで何ヶ月も何年も続く即興ライブ演奏のようなものです。あなたも、あなたのファンも、次に何が起こるのかなんて知りません。
The marketplace is incredibly forgiving of mistakes — especially if a company owns up to a mistake immediately, explains how or why the mistake happened, and how the company is fixing it.
市場はもの凄く失敗に寛容だ — 特に企業が失敗をすぐに認めて、そのミスがどのように起きて、どのように取り組んでいるのか説明する場合に。
あなたがミスを犯した時、ユーザはあなたも人間であることを理解するでしょう。僕も頻繁にミスを犯しますし、ユーザがそれを報告してくれます。僕は「おっと、それはバグですね。こちらにパッチを当てましたので、ちょっと試してもらえますか？」という感じで応答します。ありがたいことに、彼らは基本的に協力的です。ちゃんとリリースノートに個別に感謝を伝えるのを忘れてはいけません。
Stop hiding your personality behind carefully scripted announcements, press releases, and events. Be yourself, and encourage your CEO and employees to be themselves.
あなたの個性を、入念に考えて書いたアナウンスやプレスリリースやイベントの後ろに隠すのはやめよう。自分らしくあれ。そしてあなたのCEOや従業員にも“らしく”ある事を奨励しよう。
個人開発者はプロダクトを作ったら、だいたい新しくTwitterアカウントを開設してその後ろに個性を隠します。人々はあなたが何を考えているのか、なぜそれを作ったのか、何を成し遂げたのか、何に取り組んでいるのか、あるいは何に苦戦しているのか、などが見えません。僕も同じ失敗を英語のTwitterアカウントで犯しました。当初そのプロフィール画像はアプリのアイコンで、プレスリリースしかツイートしませんでした。こんな平凡なアカウントを誰がフォローしたいと思うのでしょうか？誰があなたのプロダクトのファンになりたいと思うでしょうか？僕は自分のプロダクトについてばかりピッチするのを控えて、プロフィール画像を変更し、人間味を隠さず、意味のあるツイートをすることに努めました。
The grateful dead announced tours to fans first and treated supporters to the best seats, driving passionate loyalty.
Give your best deals to existing customers. Tell your fans first. Show the people who invest their time and money in your company that you care.
Grateful Deadはツアーを計画したら最初にファンにそれを教え、サポーターに良い席を案内した。それがファンの忠誠心をよりかき立てた。
既存の顧客に最も良い待遇を提供しよう。最初にファンに伝えよう。時間とお金を投資してくれた人たちに対して、あなたが気にかけている姿を見せよう。
バンドがしたように、顧客のロイヤルティを育むには彼らを特別な存在として扱いましょう。僕はまず課金ユーザにベータ版を提供し、彼らに新機能をいち早く試せるようにして、一緒に議論しています。
The way to reach your marketplace is to create tons of remarkable, free content like blogs, videos, white papers, and e-books.
市場にリーチする方法は、ブログやビデオや白書、電子書籍のような、大量の素晴らしい無料コンテンツを作ることだ
僕はたまにYouTubeに動画を投稿します。そもそもYouTubeはブログがリーチできないオーディエンスを開拓するために始めました。しかし最近、既存のオーディエンスも動画をとても楽しんでいることに気づきました。無料のコンテンツは人々を惹き付けるだけでなく、彼らをファンにします。例えば彼のように：
Yoshidaさん、良い気付きをありがとうございます。
この他にも同書には沢山の叡智が詰まっています。ぜひチェックしてください。
The Goal: A Process of Ongoing Improvement by Eliyahu M. Goldratt
日本語版: ザ・ゴール ― 企業の究極の目的とは何か
この本は生産性について書かれています。独りきりでプロダクトを走らせるには、高い生産性が求められます。コーディングを始め、マーケティングやユーザサポート、デザインなどやることは山積みです。尚かつ健康を損なわずにそれらをやり遂げなくてはなりません。うっ、時間が足りない！生産性についての本は沢山ありますが、そのほとんどはタスク特化系です。例えばToDo管理やスケジューリング、コミュニケーション最適化などです。ちょっと待ってください。それらは料理のレシピのようなものです。自分自身で継続的に生産性を高めるための基礎的なスキルとは何でしょうか？その答えは — 「Do less (より少なく行う)」です。より少ないコーディング、より少ないマーケティング、より少ないユーザサポート。それが結果的に「より多く行う」余地を与えてくれます。それを何年と続けて積み重ねれば、人との違いを作れます。しかしどうやって？「Do less」とは具体的にどういう意味か？同書はこれらの疑問に、ソクラテス的形式(質疑応答式)で答えてくれます。
When you are productive you are accomplishing something in terms of your goal.
あなたが生産的である時、あなたはゴールに向けて物事を成し遂げている
あなたのゴールは何か、考えてみて下さい。成功とは何か、定義してください。僕のゴールは、自分の好きなことを好きなだけやる事です。多くの人や企業は、ゴールはお金を稼ぐことだと言います。僕はかつて働いていた会社での研修で、会社の目的はお金を稼ぐことだと教えられました。でもお金は僕にとってあくまで手段です。なぜなら僕のプロジェクトは自分自身のためにあって、投資家や株主のためにあるわけでは無いからです。僕は自分の問題を解決するモノを作るのが大好きです。もし他の人が同じ問題を抱えていたなら、僕はそれをサービスとして提供します。僕は美しいモノを作るのが大好きです。人が自分の作品を楽しんでくれる様子を眺めるのが好きでたまりません。そしてそれを死ぬまで続けたいと心の底から思っています。なので、僕が生産的な時とは、この活動をより良く、より早く達成している時です。僕のゴールは豪邸に住むことでも、いかに金持ちか見せびらかす事でもありません。あなたはどうですか？
この本は、とある工場で働くマネージャーが、ボトルネック(生産の妨げ)を最小限にしつつスループット(処理量)を高める事で生産性の問題を解決するという話です。幸運なことに、僕らソフトウェア開発者は基本的に「在庫」について気にかける必要がありません。なぜなら成果物はデジタルで物理的な場所を取らないからです。また、オフィスや倉庫の契約料もかからないしサーバ費用も最近はとても安いので、僕らは運用コストもほとんど無視できます。つまり、スループットを最大化するために必要なことは、自分のボトルネックを回避したり最小化する事です。なぜなら：
Whatever the bottlenecks produce in an hour is the equivalent of what the plant produces in an hour. So … an hour lost at a bottleneck is an hour lost for the entire system.
ボトルネックが一時間で生産できるものが何であれ、それが工場において一時間で生産できるものと等価である。つまり、ボトルネックでの一時間のロスは、システム全体での一時間のロスに等しい。
これは個人開発でも大いに当てはまります。あなたが何かに１時間つまずいた時、文字通りあなたは１時間を失ったことになります。同書はどうやったらボトルネックを解決できるか解説します：
STEP 1. Identify the system’s bottlenecks.
STEP 2. Decide how to exploit the bottlenecks.
STEP 3. Subordinate everything else to the above decision.
STEP 4. Elevate the system’s bottlenecks.
STEP 5. If, in a previous step, a bottleneck has been broken go back to step 1.ステップ 1. システムのボトルネックを特定する
ステップ 2. ボトルネックをどのように有効活用するか決める
ステップ 3. その決定に伴って全行程を調整する
ステップ 4. ボトルネックの生産性能を向上させる
ステップ 5. 前ステップでボトルネックが解決したら、またステップ1に戻る
要するに、「Do less」とはボトルネックがより少ない・より小さい状態を指します。ポイントは、どんなものでもボトルネックになりうるという事です。例えば：
- ソフトウェア設計
- 肉体的・精神的健康
- 家族・友人・同僚・顧客との関係性
- 家や職場の環境
- 機材・仕事道具
- など
あなたのボトルネックについて何か改善できることはないか、日頃からチェックする習慣を持つことが重要です。なぜなら、ボトルネックは人によってそれぞれ異なるからです。現時点で最も大きなボトルネックは何か、常に知っておくべきです。以前、僕の生産性向上の取り組みについて詳しく書いたのでご参考下さい：
先にご紹介した「Getting Real」では、この「Do less」をソフトウェア設計において実践するための手法を非常に明快に説明しています。ちなみに最近僕が取り組んだのは作業部屋の環境改善です。部屋の空気の状態を可視化するモニタを構築しました：
低酸素の状態は想像するよりも遥かに生産性に影響します。CO2レベルをモニタするようにしてから、換気の頻度が増えて、自分の生産性に明確な効果を感じています。
その他のおすすめ
もし既に上記の本を読んだことのある人は、以下も読んでみて下さい：
- MAKE: Bootstrapper’s Handbook — Pieter Levels
- Drive: The Surprising Truth About What Motivates Us — Daniel H. Pink
- Company of One: Why Staying Small Is the Next Big Thing for Business — Paul Jarvis
今すぐ実践しろ
本稿ではおすすめの本を引用しながら、自分の実践してきた事も併せてご紹介しました。ここで強調したいのは、本を読み終わったら直ちに、今すぐに実践するべし、という事です。もう一点付け加えると、勝手に自分なりにアレンジして実行しないで下さい。出来るだけ本に書いてある通りに実行するのです。なぜならあなたは自分のプロジェクトでそれが実際どのように働くのか知らないからです。それを試したあとにやり方を変えたって遅くありません。改めて言います。今すぐやれ。本を読了しただけで満足するな！
