· 5分で読了

4. 2つのモデル:ピラミッドの頂点と平均

この記事は中国語から自動翻訳されたものです。翻訳によりニュアンスが失われている場合があります。

世の中には2つの収益モデルが存在する。1つは「80対20の法則」で、上位20%の人が80%の利益を得る、あるいはさらに極端な場合では上位1%が80%の利益を手にするモデル。もう1つは平均的な収益が高く、必ずしも突出した存在である必要はないモデルだ。

ソフトウェア開発はここ数十年間、この2つ目のモデルに属してきた。極めてトップクラスでなくても悪くない給与をもらえるし、医師や弁護士などの職業も同様の性質を備えている。

これらの特徴は、長年の学習と高度なスキルや専門知識が必要とされる点、そして何よりその供給を支えられる市場が存在する点にある。LLMの登場によってプログラミングをしたりモノを作ったりするハードルは大幅に下がったものの、ソフトウェア開発への需要は依然として存在する。この点については後で詳しく語ることにしよう。

多くの業界にこのようなピラミッド構造が存在するが、ソフトウェア開発において利益が出るかどうかは、ソフトウェア開発そのものというより、会社のビジネスモデルが成功しているかどうかにかかっている。ここで言いたいのは、プロダクトの成功は必ずしも優れたソフトウェアがあることだけから生まれるわけではなく、他の要因も含まれている可能性があるということだ。

収益モデルが頂点にある会社を見つけて参加できれば、参入できる分野は特定の業界に限られず、ソフトウェア開発というパイの許容量は非常に大きなものになる。同時に、ソフトウェアには他の業界では再現が難しい強みがいくつかある:

  • 計算力(コンピューティングパワー)の向上がソフトウェア開発のハードルを下げる
  • 開発コストが低い:ソフトウェアの複雑さにもよるが、PCさえあれば誰でも書ける
  • 初期コストがほぼゼロ:初期トラフィックの段階なら、大半のサービスは無料で済むし、かかってもドメイン代(年間10ドル前後)くらいだ
  • 複製が容易:1つのソフトウェアを無限のユーザーに販売できる

もう1つは「勝者総取り(ウィナー・テイク・オール)」の収益モデルだ。例えばインフルエンサー、作家、画家、スポーツ選手などである。業界のトップに君臨する一握りの人を除けば、大半の人は副業をしなければ食べていけない。案件を受注すれば何とか食いつなげる程度の収入は得られるかもしれないが、複利効果を積み上げるのは難しい。(これはあくまで収益の観点からの話であり、自己実現や信念を追求するなら、自分のやりたいことをやればいい)

僕は幸運なことに、キャリアの最初の10年間をこの2つ目のモデルのピラミッドの中で過ごすことができた。


個人開発となると話は違ってくる。開発プロセスへの一定の理解に加え、プロダクト、市場、ビジネスモデルなど、すべてのことを自分自身で背負わなければならない。これらには膨大な蓄積、研究、そして市場への嗅覚が必要であり、一朝一夕にはいかない。

僕は以前、ネットである事例を目にした。マッサージ店にとって、最善の予約方法は電話と紙とペンなのだ。自動化やオンライン予約、認知度向上なんて彼らにとっては知ったことではない。自分では「自動化やオンライン予約を作ってあげれば課題を解決できる」と思っていても、実際に作ってみてそれが単なる自分の思い込みだったと気づく。

業界のルールは一見シンプルに見えて、「自分でも飛び込めばできるんじゃないか」と思いがちだが、リソースが追いついていないことが多い。キーパーソンが見つかっていないのかもしれないし、法規制をクリアできないのかもしれない。あるいはその業界自体が極めて閉鎖的で、開発の腕があったところで何の役にも立たないのかもしれない。

かつて人脈やリソースの統合による恩恵を受けてきた僕にとって、この重要性は身に染みている。僕たちがサーバー費用を節約しようと頭を悩ませている間に、電話1本で無料枠を手に入れる人がいる。法務が必要なときも、電話1本で提携している法律事務所が動いてくれる。そうした人たちが物事を成し遂げるスピードや効率は、僕のような素人とは比べものにならない。

自分ですべてをなんとか解決しなければならず、立ち向かうことになるのは1つ目のモデルのピラミッドだ。だが、それでも問題ない。ピラミッドを小さくするための方法はいくつかある:

  • 領域(ドメイン)を絞り込む:ターゲット層を、自分がトップになれるところまで絞り込む。例:新米ママ向けの健康ドリンク、ミュージシャン向けのNetflix、推し活のためのSNS
  • 低コストでアイデアを素早く検証する:いきなりコードを書かないこと。共同購入や募集、Googleフォーム、ランディングページ、MVP、プロトタイプなどの方法で需要を確かめる
  • キーパーソンを見つけ、リソースの輪に入る

もう1つ注意すべきなのは、この道を進む中で、多くの人が自分のアイデアを疑い、否定してくるということだ。中には的を射た意見もあるが、単に彼らがターゲットユーザー(TA)ではないだけということも多い。

「手っ取り早く成功すること」と「アイデアを素早く検証すること」は別物だ。前者は何の労力もかけずに成果だけを得ようとすることであり、後者はまず最小限のコストで需要を確かめ、確信を得てから本格的にリソースを注ぎ込むことだ。

僕自身、次のスティーブ・ジョブズではないと自覚している。需要が顕在化していない状態でユーザーが何を求めているかを正確に予測し、魅力的なプロダクトを生み出すことなどできない。だが、作り上げていくプロセスの中で鍛えられるものもあると信じている。

こうしたやり方に対して、「開発者としての職人気質がない。Appleのようにプロダクトの細部まで徹底的に磨き上げるべきだ」と反論する人もいるかもしれない。しかし、コンテクストを無視してそれを語るのはあまりに理想主義すぎると僕は思う。

もし僕にほぼ無限の資金があるなら、自分が納得いくまでじっくりとプロダクトを磨き上げることもできるだろう。だが僕はそんな人間ではない。職人気質で物事に取り組む姿勢は確かに称賛に値するが、餓死するリスクもある。

まずは飯を食えるようになることだ。

関連記事

他のトピックを探索