ビジョンと市場に流れる力のバランス、そして起業家兼投資家が集中分野を3つ選ぶべき理由などについてもにょもにょ考える
※非常にハイコンテクストな記事なので、一般に推奨できる読み物ではありません
前提として、私は「スタートアップ」と呼ばれる形態の会社で働く
フロントエンド・バックエンドの開発者である。
開発者ではあるが、起業家でもある。
それ以前に哲学者でもあるが、思索だけして実践しないことは嫌いなので、
現状のような心向きに落ち着いている。
「品質とユーザーの要求を兼ね合いし、最速でサービスの価値の有無を検証すること」
がスタートアップにおいて最も重要であると考え
開発者・起業家としての能力を磨いてきたが、
近頃はそれよりもメタな上位レイヤーで勝負が分かれる
ケースがあると認識できたので、とりとめなく書き記せればと思う。
ビジョンにこだわりすぎて失敗するケースや
市場によりすぎて心がついてこないケースがあるように
ビジョンと市場のバランスには心を悩ませてきた。
一旦の整理のために、
ビジョンと市場を兼ね合いした私なりの優先順位を言語化しておこうと思う。
(以下のリストは向こう30年で達成したいことを時系列マッピングし、今後大きく成長しそうな市場の時系列マップと照らし合わせて、優先して取り組むべきテーマを決定したもの)
1.【価値の再考】
エクイティハックによる「急成長」のデザイン(未公開株式市場・トライアルラウンド)
2.【市場の再考】
この宇宙全体の人口扶養力の向上による「市場の中心」のデザイン(循環型宇宙コロニー・暮らしと労働の在り方)
3.【表象意識の再考】
「体験」の破壊的提案による「不可能だったこと可能に」のデザイン(電脳・明晰夢・仮想現実)
これらを実現するにあたり、市場の流れとの兼ね合いが重要になる。
趣味や芸術活動のようにROIを度外視して取り組むのではなく、
追い風の吹いている分野から着手し、目標達成に有効な仮説検証を重ねていきたい。
また、価値検証をするために必要な開発力の強化や、
業界知識のインプットは非常にコスト高なものなので、
「追い風の吹きそうな注力分野」を3つ程度に制限する事により、
起業家としても投資家としてもバランスのよいものになると考える。
(これがマスクやティールのような起業家兼投資家の強みと考えている)
なぜ注力分野を1つに集中せずに3つにするのかというと、
起業家は往々にして思い込みの激しい生き物なので
「追い風が吹きそうだ」という予想は外れる可能性も多分にあるということ、
アテが外れたときに精神失調に陥らないためのモチベーションマネジメント
的な役割を考慮したことなどが理由に挙げられる。
開発力とドメイン知識を蓄えた、
自分が心から酔える分野を3つ持っておき、
そのどれかに追い風が吹いたときが勝負所だと考える。
また、これらに付随して生活スタイルが決定する。
・最も資金が潤沢で人材に恵まれる土地を拠点に生活する
・配偶者もクリエイティビティに溢れており、日々の生活を心から楽しめる健康的な関係であること
・自らはアイデアを高速で価値検証するだけの高度な開発能力が求められる。
・その先に、資金調達や組織論のような経営者としての力が求められる。
私のなにげない思考の吐露が、
誰かにインスピレーションを与えられれば物書き名誉に尽きる。
「え、まだ自力でボタンのCSS書いてるの?Product Huntで探せば良いじゃん」って思った話
Product Huntがやばい
これがそのサービス
デイリーで英語圏の人気サービスのランキングが出てる
今日紹介したいのは検索機能
こうやって「CSS button」で検索して実装の楽をしようと思った
Transformiconというのが出た
アニメーションつきボタンを作れるサイトだ
僕は自前でこんなものを作るスキルはない。でもある程度用途に合った既製品にアクセスできた。
これはまた使うかもなと思ってお気に入りに保存した
Transformiconの詳細ページがこれなんだけど
「SIMILAR PRODUCT」という欄がある
Anicollectionというアニメーションをお気に入りして溜めて行くサービスだ。
これもProduct Huntデザインリストに入れた。
こんな感じで一定水準のものを作る事がどんどん簡単になっていくんだろうなあと思った。
エンジニアがデザインの設計を学ぶのに良いサイトまとめでまとめたようなデザインが楽になるサービスへのアクセシビリティが上がっている。1年では状況は変わらないかもしれないが、3年経てばあたり前にアクセスできるようになるだろう。
一足先に情報の非対称性を超えていけ。
せいぞーんせんりゃくー
イーロンマスクについてまとめるお
起業家やプロダクトの歴史を知りたいので。
Elon Reeve Musk (43) (1971.6.28 ~ )
- 0歳 ー 南アフリカに生まれる。父は南アフリカ人の電子機器技術者、母はカナダ人のモデル
- 9歳 ー 両親が離婚、父側につく
- 10歳 ー PCを買い、プログラミングを始める
- 12歳 ー 500$(*2)でテレビゲーム用のBlasterというコードを売る
- 17歳 ー 母の親族のつてでカナダに移住し、永住権を得る
- 19歳 ー クイーンズ大学に入学、2年間過ごす
- 21歳 ー 奨学金をもらい、ペンシルバニア州立大学ウォートン校で経済学を専攻。
- 23歳 ー 同校を卒業、インターネット/クリーン・エネルギー/宇宙をテーマとして考える
- 24歳 ー 高エネルギー物理学を学ぶためにスタンフォード大学院に入学するも、2日で退学
- 24歳 ー 弟と共にZip2社を操業
- 28歳 ー Zip2社を売却。307M$の現金と、34M$のストックオプションのうち7%の22M$(*1)を得る。
- 28歳 ー X.com社の共同創業者となる。
- 29歳 ー X.com社がコンフィニティ社(ピーター=ティールとマックス=レヴチンが操業した暗号技術・電子マネースタートアップ)と激しい競争をした後に合併
- 30歳 ー 名称をPaypal社に変更、その後IPO。時価総額1.2B$(*5)。
- 30歳 ー Paypal社をebay社に売却、売却額1.5B$(1)(5)のうち11.7%にあたる165M$を得る
- 31歳 ー 100M$でSpaceX社を操業。テスラモーターズ社に出資。
- 31歳 ー Justine Muskと結婚。その後5人の子をもうける。
- 34歳 ー 総資産328M$(*1)
- 35歳 ー ソーラーシティ社を従兄弟のリンドン=リーブと操業
- 38歳 ー 国際宇宙ステーションへの運搬カーゴの契約をNASAと結ぶ。SpaceX社の価値は1.6~3.1B$(*2)と見積もられる。
- 37歳 ー テスラモーターズ社、CEOに就任。
- 37歳 ー Justine Muskと離婚、親権はイーロン側へ。
- 38歳 ー イギリス人女優Talulah Rileyと婚約
- 39歳 ー テスラモーターズ社をIPO。時価総額1.6B$(*4)。
- 40歳 ー 結婚、5人の子と共に幸せに暮らしているそう。
- 41歳 ー 民間初となるISSへの運搬船のドッキングに成功する
- 42歳 ー ハイパーループ構想を発表。6B$かかるとされる。
- 43歳 ー 総資産11B$(*1)
P.S. btraxさんの記事にもあるように、タルラ・リリーとも離婚しているようですね。
- *1 イーロン・マスク - Wikipedia
- *2 Elon Musk - Wikipedia, the free encyclopedia
- *3 Tesla Motors - Wikipedia, the free encyclopedia
- *4 米テスラがナスダックにIPO、初日は40%高で取引終了 | ビジネスニュース | Reuters
- *5 松山 太河 - ・ペイパル創業から買収まで... | Facebook
何かあれば@_sgtnまでご連絡ください
将軍とスタートアップ
※ 少々ネタバレあり
キングダムという漫画があります。
秦とか魏とかが入り乱れる戦国活劇です。
主人公・信と武将たちが繰り広げる人間ドラマや兵法の数々にはしびれるものがあるんですよね。
作中で王騎というむちゃくちゃ強い天下の大将軍が
※ 画質悪いのしかなかった
「戯言とは心外ですねェ。"知略"対"本能"! これは武将の中の永遠の題目ですよォ」
という示唆深いセリフを吐いていたのが特に印象的です。
(詳しい内容が知りたい人はここで概要を把握すると良いです。) 秦の怪鳥・到着!!! そして暴☆言☆王・信最大の「あの暴言」が……。。(笑)
これ、スタートアップの経営にも通じませんかね。
リーンスタートアップ・グロースハック・UXD(ユーザーエクスペリエンスデザイン)などの「ユーザー中心設計」の理論に基づいてプロダクトの改善や組織作りをする経営者もいれば、自分のセンスを信じて直感でプロダクトを改善して行く経営者もいると思います。
僕はこれ、状況に応じてどちらを採用すべきか変わると思うんですよね。
プロダクトの成長ステージ・チームの状態・マーケットの状態に応じて、最適な改善プロセスがあると思うんです。
本能型の人はそれらの情報を肌感で分かるからものすごいスピードで改善しまくれるんでしょうね。作中では近距離型という比喩がありました。
知略型の人は仮説検証をしまくるので進みは遅く見えますが、理詰めでより良いプロダクトを目指すので大きなミスをすることは少なそうです。中〜遠距離型って言ってました。
どちらも欠点はありますよね。言語化できないから属人性が高いとか、実践するのは難しいので結局は形を崩して使うハメになるだとか、様々な議論はあるんですが、「とにかくユーザーが欲しいものを作って届ける」という基本を外さずに、要求に応じて柔軟に改善フレームワークを使い分けたいですね。
余談ですが、「要求に応じて柔軟にフレームワークを使い分ける」ってプログラミングにも当てはまるなあって思います。プログラミングにおいて厳密さと早さはトレードオフっぽいので、最適な粒度の技術を選べたら最速で十分な品質のプロダクトを開発できますよね。だから、フレームワークや言語を選択できる地力が重要だと言われる訳ですね。
またまた余談ですが、グロースハックって使えるプロダクトが限定されてますよね。準備にすごい工数かかるから既製品のMixpanelとか使いたくなるし、抽出したデータが真にプロダクトの改善点を表現できるかは指標を決定する人間とエンジニアの連携にかかっているし、おまけに変更に弱い。
場合によってはUXDが有効なケースも多そうです。
さらに余談ですが、見方によってはまたマーケットがない(ユーザーが本当に必要としているか言語化できてない)プロダクトでも作らない限り、Googleなんて倒せませんよね。言語化できることは大体真似されますから。
社会的文脈と技術的文脈の両方から予想できる人は強いと思います。当然人類が進歩するであろうという技術的予想を、現実のしがらみを諸々勘案してベストなポイントに網を張っておく感じ。
リーンスタートアップ的なパッチの小さい仮説検証プロセスをベースにしながらも、根本的には学者か宗教家のような狂ったビジョンをベースにした、検証がしにくいプロダクトを作らないと、せっかく上限青天井のギャンブルなのにもったいないでしょうから。
本能と知略を使い分け、理解できないビジョンを掲げるエンジニア集団には、怖くて投資できないかもしれませんね。
認証(対象の正当性を検証すること)の未来について考えてみた
最も身近な認証とは何だろうか。おそらくそれはパスワード認証だ。 操作する人と操作する情報の組み合わせが正当か否かを検証している。
最も堅牢な認証とはなんだろうか。例えば生体認証だとかSSH公開鍵認証が予想されるだろう。 手続きは違えど、どちらも鍵穴の複雑さを安全性の源としている。
安全性の源が複雑さなのは、パスワードも同じだ。 なぜなら、パスワードを総当りにより解析できる時間の平均値 (解析時間 L) は,
L = P・S / R = AM /(2R)
P:パスワードが推定される確率 (= 1/2) R: 単位時間に行えるパスワード探索回数 S: ユニークなパスワード数(パスワード空間) S = AM A: パスワードに使われる文字種類 M: パスワード文字数
で計算でき、大体の認証機構では「回数制限」か「文字種・文字列長制限」が成されているので、現実的な時間ではアクセスが出来ない仕組みになっているからだ。
加えて、パスワードを予想できないなら無理矢理知ってしまおうと言うことで脳から直接情報を取得することを考えたとして、脳に電極を指して複雑な信号の集まりから意味を見いださなくてはならないので、あなたはまずノーベル賞から取得しなければならない。
さて、複雑さによって予想がされない認証情報(生体情報, 公開鍵認証方式に使う秘密鍵, パスワード)だが、人間が全てを管理するには多岐に渡りすぎているのも事実だ。どこでどう管理するかと言う問題が生じてくる。
すごくバカらしい例だけど、もしも認証情報をあなたのブログで公開していたら、どんなことが起こるだろう?たぶん、第三者があなたに成り済まして多額の決済を済ましてしまうと思う。あるいは、イスラム国の国民になる手続きが完了している。
だから、認証情報はなるべく「参照可能性の低い媒体」にまとめたいということになる。ブログのような皆がアクセスできる媒体に認証情報を保存するのはバカらしい例えだった。でも、ローカルのテキストファイルだってパソコンやスマホを奪われれば参照可能だし、evernoteのサーバーがクラックされたり、ベネ○セさんみたいに信頼していたところからパスワードが漏れちゃうかもしれないし、参照可能性は実は至るところにあることが分かっていただけたと思う。
だから、僕は参照可能性が低くて、なおかつ使うためのアクションが少ない、便利な認証情報管理ツールがあれば良いなと思った。だって、あるサービスを使う度にパスワードを聞かれて、いちいちツールを開いて確認するのは嫌だ。出来る限り「認証された証」を元にシームレスに処理を行って欲しい。
そしてそれは例えば1Passwordのようなパスワード一元管理ツールだったり、OAuthのような認可手順簡略化アルゴリズムだったりする。理想の認証情報管理ツールは、認証の手順を簡略化することと、参照可能性が低いことを同時に満たす必要がある。
そこで思いついたのがウェアラブル端末だ。特に、直近では腕時計が良いと思った。なぜなら、常に身につけているし、盗まれないからだ。将来的には、コンタクトレンズ型だとか、皮膚埋め込み型だとか、脳癒着型があってもいい。
ともかく、種々のパスワードとその「認証した証」は一箇所から参照するようにして、それが物理的に奪われにくいことが「参照可能性が低いこと」に繋がると思った。
暗号化された認証情報をBluetoothで操作しているデバイスやサイトに送る。その間にパスワードや生体認証の存在を意識することは無い。そういった「意識されない認証」が認証の目指す姿だと思った。
昨今のWEB界隈を見ていると、皆パスワードを自前で持たない方向に進んでいる。OAuthは登録やログインが簡単だからという以上に、パスワードを持つリスクが必要無いから開発者にとっても喜ばしい。
他にもfirefoxのPersonaはBrowserIDによって(賛否両論あれど)表面的にはemail情報だけで認証を実現する。
Json Web Tokenを用いれば安全に認証した証をサイト間で融通できるし、何なら抜かれたらまずい情報は除いて、初めから登録・ログインを済ませて置いて欲しいと思うケースさえある。(信頼できるサービス運営者のみで相互にログイン情報を融通する形で実現されるイメージ)
そう考えると、twitterやfacebookがパスワードを管理している現状は過渡的なもので、未来では「OAuthのサーバーとなるためだけのサービス」が存在しても良いのかもしれない。パスワードとログインという概念が空気のようになって、腕時計とサービスひとつで全てが実現されている未来はもうすぐそこなのかもしれない。
2014年も終わりに近づいているのでエンドユーザープログラミングがどのように実現されるのかスタートアップ界隈の視点から想像してみた
チラ裏なのでノークレームノー罵倒でお願いします
世の中には課題に気付いた人間と気付かない人間がいて、気付いた人間の中でも、プログラミングで解決する人間と何もしない人間がいる。その差は「プログラミングで解決する絵が想像できるか否か」という「なじみ」の問題が大きく、なじみがあれば今それを解決すべきか思案する段階に移れる。
— ゴミクズ(˘ω˘) (@_sgtn) 2014, 10月 22
一方でプログラミングになじみがなければ、プログラミングを習得するコストはおろか課題を解決するコストも不明瞭なので、課題のコストと報酬が計算できずに「そもそも解決できるとすら思わない」という結果に終わる。これが「道具がアイデアを支配する」という状態の一例だと思う。
— ゴミクズ(˘ω˘) (@_sgtn) 2014, 10月 22
では仮に、よりエンドユーザーのためにデザインされたmilkcocoaが開発されたとして、それが「日常の課題に気付いた全ての人」になじみ深くなりえる良いデザインを備えていたとする。そのとき、「日常の課題に気付いた全ての人」が「この課題は今解決すべきか」という判断の段階まで進む。
— ゴミクズ(˘ω˘) (@_sgtn) 2014, 10月 22
もちろん、「課題に気付いた人の全て」にはいろいろな背景知識が考えられるので、全てのユーザーにとってなじみ深いデザインを実現するためには工夫が必要だけど、多彩な抽象度でプログラミングを行う道具を提供できるように努力することはやり方のひとつに挙がると思う。
— ゴミクズ(˘ω˘) (@_sgtn) 2014, 10月 22
おそらくこれが「エンドユーザープログラミングの世界」と呼ばれるものの姿だと個人的に推測した
— ゴミクズ(˘ω˘) (@_sgtn) 2014, 10月 22
当然、「日常の課題に気付いた人の全て」がmilkcocoaをなじみある道具として使えたとして、専門的知識なくして優れたプロダクトやアーキテクチャが作れるとは全く思えない。なので、milkcocoaで作られたプロダクトがプロトタイプを超えて製品と呼べるようになるためには助力が必要だ
— ゴミクズ(˘ω˘) (@_sgtn) 2014, 10月 22
「日常の課題に気付いた人が作ったプロトタイプがプロダクトになるために必要な助力」がどのようにして提供されるかはmilkcocoaの責任の外側なのかもしれないし、場合によっては内側なのかもしれないけど、これから先、課題を解決するために必要なものを揃えたフレームワークが生まれると思う
— ゴミクズ(˘ω˘) (@_sgtn) 2014, 10月 22
そのフレームワークに含まれるものは、プロトタイプに本当に価値があるか確かめる方法だったり、間違った機能にリソースを割いてないか確認する方法だったり、プロトタイプを洗練するために必要なお金や仲間を集める方法だったり、どうしたらユーザーが喜ぶプロダクトが作れるか知る方法だったりする
— ゴミクズ(˘ω˘) (@_sgtn) 2014, 10月 22
そのどれもが思想のレベルから理解することを求める難しいものだけど、それを助ける補助線のようなプロダクトとしてProttやMixpanelなどの製品が使われ初めているんだと思う。
— ゴミクズ(˘ω˘) (@_sgtn) 2014, 10月 22
田舎者が分不相応にもHikarie.goに行った話
こんにちは
この頃のfrontendの開発環境の複雑さに舌打ちする@_sgtnです
Hikarie.goに行ってきました
原因不明の揺れで倒壊待ったなしらしいヒカリエ上層部、DeNAさんでハンズオン形式の勉強会でした
きっかけ
仕事の関係で東京に越してきたばっかりだったので友達が欲しかった
Docker, Libswarm, Kubernetesなどのコンテナ管理ツールのソースを読んでて気になってきたので来ました。あと@_kai_inuiから教えてもらったHashicorpというVagrantなどを作っている会社がとてもイカしたGolangの会社だったので。
@_sgtn http://t.co/jMq7G4O0SB 倒壊前のヒカリエで開催される模様. 補欠ですけど
— 俺のミームを受けてみろ (@T_Hash) 2014, 8月 11
ミームさんありがとうございました
得られたもの
内容
nodeのすごいひとにしか見えない@yosuke_furukawaさん
のお二人が主催でした。
時間があったので受付から手伝うことに。
ヒカリエ11F綺麗ですね。
ベタですが受付のお姉さんも綺麗です。
そして20F(たしか)のDeNAさんもきれいですね。
隣の部屋でアイドルがキャーキャーいってたようですが、ショールームというサービスの関係らしいですね。
閑話休題。
ハンズオンの内容
@yosuke_furukawaさんのgithubリポジトリ
を見ると分かるのですが、
という流れになっています。
もくもく書きます。
気付いたこと
- やはりerr変数多用するなあということ
- import部分非常に読みやすい
- importで呼んだのに使ってないライブラリや、宣言して使ってない変数はコンパイル時にエラーを吐いてくれるので変なところで苦しまなくて良い
- 自分で定義した型にinterfaceを使って関数を追加する様がオブジェクト指向と似ているがどこか違っていて新鮮だった(型システムを学ぶ必要性を感じる)
- 文字列をbyte型で扱うところやポインタを扱う面はあるけど、アレルギー反応を起こすことなくすんなり使える
よく分からなかったところ
- 2章でnet/httpを呼んでいた際に内部的にgoroutineが使われていたりしたけれど、自分で書けと言われるとムムムとなる
m := user.(map[string]interface{})
という一行の解読の辛さ(structやmapの扱いを知らねば)- 「rubyで言うところのインスタンス変数っぽいことがしたいんだけど・・・」とか思ってもすぐに目的の情報にありつけない。golangの語彙を身につけねばならない。
お開き
なんとsushiが出ました。なんたる財力。ありがとうございます。
PRMLやjuliaやErlangやHaxeや、こないだローンチしたmilkcocoaやSFラノベの話などしながら楽しい時間を過ごせました。
Hikarie.goで得たもの
学習とか成果とか突きつけられるプログラマーという仕事ですけど、プログラマーとしてリアルを充実させるやり方はいくらでもあるんだなあって感想を抱きました。
福岡から東京にきて4日程度ですが、なんとか生きていけそうです。
宣伝
milkcocoaの便利さをもっとたくさんの人に分かってもらいたい、のですが、とてもじゃないけど今の状況からコードを書き始めるのはハードルが高いので、技術ブログ的なことも始めます。よろしくお願いします。