あなたの新規事業プロダクト開発はこうして失敗する🦆

釣りタイトル容赦。なんてことありません、僕の失敗談です。
失敗談は好きですか？僕は大好きです。
他人の不幸はなんとやら。さぁ行ってみよう！

1. 早すぎる最適化をしてしまう

ドナルド・クヌース先生の、「早すぎる最適化は諸悪の根源」という言葉は、ソフトウェア開発に携わっている皆様であればそれなりに日々実感することであり、なんとなくでも直感的に共感できることと思います。

この言葉自体は、ソフトウェア開発の性能チューニングの文脈で語られるものだとは思いますが、僕はこの言葉、結構いろんな場面で使えると思いますし、使っています。

もちろん原義通り、パフォーマンスのための最適化という文脈でも当たり前のように意識したほうが良い言葉ではありますが、例えば抽象概念のモデリングや、コード品質の向上、ライブラリやアーキテクチャの選定といった場面でも使える概念ではないでしょうか。

「ここ」と「そこ」のロジックはなんとなく共通化できそうとか、この流行りのフレームワークやアーキテクチャはこのプロダクトにピッタリなはず、このデータは抽象化した方が良さそうなので別テーブルで表現しよう、なんてのはよくあるシーンですが、案外そうでもないわけです。

こと新規事業というのは大体において不確実性の塊なわけで、全容が見えていない状態でそういうことをやり過ぎると、無用な考慮事項と手数が増えるだけで開発速度や品質の向上には何ら寄与しないなんてことはザラにありますし、なんなら誰もが恐怖する「手戻り」を誘発します。
（いやいや、あんたの設計力がないんでしょ。と言われればそうでしょう。そんな方は是非、弊社ココナラで僕と握手！）

さらに風呂敷を広げて言うと、この "Premature optimization" というその言葉自体は直訳すると「時期尚早な最適化」であり、「最適化」という抽象概念は「最も適した状態にする」という意味なので、プログラミング分野に限らない汎用的な言葉として使えそうです。

例えば先行者が居る分野に参入する場合、機能やUIをそれなりに参考（あくまでも参考…ですよ！）にするわけですが、彼らがなぜその機能群のその組み合わせに至って今の状態になっているのか、ということは外部から触っているだけの僕らからは完全に理解することはできません。

歴史的に仕方なくそうなっているだけのこともあるでしょう。
声の大きなユーザーの少数意見を思わず参考にしてしまったかもしれません。
現場の雑談ノリで「それウィーネ！」的に実装してしまった無根拠お便利機能の可能性もあります。

この先輩達の現状を、「最適」と思いこんでしまうと、それほど効果的でない作り込みを、それなりに手前で、わりかし頑張ってやってしまいます。
そしてそんなこんなをやっているうちにサービスが成長するタイミングを逸するのです。

こうしてあなたの新規事業プロダクト開発はモリモリの過剰最適と共に失敗します。

失敗からの学び

「最適」という状態は究極的には観測時の結果論でしかなく、なんならそれが「最」なのかなんてわかるわけないので、あんまり手前で頑張り過ぎないということが意外と大事です。

イケてるアレより泥臭いコレの方が実はそのフェーズに合っていた、なんてことはよくありました。
肩の力を抜いてそのプロダクトのコアを見つけることに集中しましょう。

2. 時間をかけすぎる

そのまんま、「鉄は熱いうちに打て」ということです。熱しやすく冷めやすいこの世の中。Webサービスだって同じです。

スタートアップにおいて必要最低限の機能をなるべく早く顧客にぶつけるようなやり方は当然選択され得ると思います。MVPを見極め、粗く作り込んで、一秒でも早くユーザーにぶつけてフィードバックを得る。言うは易し。

なんてったってこれ、なまじ経験を積んでいるおっさんエンジニアだと案外難しいのです。あと若くても賢くて気が利く君みたいな人。

僕らおっさんエンジニアは人生経験としてそれなりの数のまぁまぁ良質な地雷を踏み抜いているので、「負債化」という言葉に敏感です。

アプリケーションをどういう風に設計し、どんな💩ードを書いたらどういった技術的負債を残すことになるかということをそれなりに知っているつもりです。
だから、それを回避する術というのも勿論それなりに知っているつもりです。
そういう本も世界中の偉いおじさんや賢いエリートたちによっていっぱい出版されております。

これって一見良いことのように思いますよね？
いや、実際良いことです。今まで培ってきた経験が活かせるのですから。
よーしパパ頑張っちゃってください。

将来抱えるであろう負債を回避すべく、たくさんの考慮をし、クールなアーキテクチャを採用します。
俺たち熟練技術者はその職人としての矜持を胸に誰もまだ見ぬ完璧な我が子に全身全霊をかけて魂を注ぎ込むのです。

そんないぶし銀な俺たちの行く先にはさぞや堅実な成長と「さすがはオジサマ、素敵、抱いて！」なんていうバラ色の未来が待っていると思いますよね？僕は思います。

でも待って下さい。
もしかしたらその滑らかで真っ直ぐな舗装道路の先には、除去したはずの地雷が埋まっているどころか、無条件降伏への片道切符がぽつねんと落ちているだけ、なんてオチが待っているだけかもしれません。

あなたが立ち上げたそのWebサービスにはたぶん先行者や後続者がいます。
もちろん「差別化」みたいなこともするので、ドン被りはしないかもですが「狙う市場に俺一人」なんてことは絶対にない。

そんな青い海、資本主義の神が絶対に許しません。

Webアプリケーションなんてのは失恋をこじらせたザッカーバーグ×１でも立ち上げられるくらいには参入障壁が低いのです。
そしてどんな要素がユーザーに刺さるかも予想がつかない。
ピボットなんて当たり前の世界です。

そんな強力な柔軟性が求められる荒野を、技術的負債を返済するという過去のトラウマに怯えながら頑張って頑張って丁寧に道を舗装し進む私達イケオジ組と、どんな悪路でも手製のバギーでヒャッハーしながら爆進する若人達との間で、事業成長の進捗に差が付いていくのは火を見るよりも明らかでしょう。

確かに投下できるリソースは紳士的な僕らのほうがよっぽどあるかもしれません。
でもやっぱりおカネで若さは買えないのです。

こうしてあなたの新規事業プロダクト開発はピカピカのランボルギーニと共に失敗します。

失敗からの学び

細くて凸凹でグネグネ曲がっていても、道が続く限りは人は通れるのです。
いろんなことに頭を使いすぎてスピード感を失ってしまうと、「技術的負債」なんて言葉すら知らない学生起業家さん達に簡単に追い抜かされてしまいます。

そして、我々のその丁寧な作り込みが効いてくる規模に達する前に、そのサービスを閉じることになるのです。

それは今本当に必要か？
別のもっと簡易な手段はないか？
品質と速度のバランスはとれているか？
手戻りが許容できる程度の作りになっているか？

経験値に胡座をかかず、一日でも早く、一人でも多くのユーザーにぶつけ、少しでも有用なフィードバックを得て、小さくても着実な改善に活かすという、起業の基本に立ち返ることが我々エンジニアにも必要な心構えだと僕は思います。

ちなみに、めっちゃキレイな舗装道路を同時に何方向にも敷けるなんて環境だったら話は別だとは思いますたぶん。

3. 「凄い人」を見出してしまう

技術力はグラデーションです。「技術力」という言葉はこの界隈だと良く聞くワードですが、その概念、あなたは端的に説明できますか？

日々進歩するこのIT業界において、半年前に流行っていたものが今日誰かに擦られているなんてことはあるあるです。
そんな業界にアラフォー（もはやフォー）の僕は辟易していますが、残念ながらそれが現実です。

そんな現代の超特急インターネッツ世界において、エンジニアのあなたの技術力って偏差値的にどのくらいでしょうか？50？80？46？

ぶっちゃけこれ、幻想だと思うんです。
巷にはどうにかしてこのITエンジニアの「技術力」を数値化しようとする勢力が存在しますが、それ結構難しくない？って思います。

そういう試みを否定しているわけではないですし、もちろんそういうサービスで出力された数字はある側面では参考にできると思います。

でもやっぱり日々変わるトレンドだったり、そのサービスやフェーズに適する人材ってワリとマジで適材適所を考えないといけない。当たり前のことなのかもしれませんが、この適材適所って結構難しいです。

こと新規事業におけるプロダクト開発というのは、特化型の尖った人材よりは守備範囲広めの何でもやる（やりたい）よ系人材が向いているのではと個人的には思います。

もちろんサービス内容や事業内容によっては尖りまくったスーパーサイヤ人が求められるのは理解していますが、そういう内容のスタートアップって案外稀だと思うので、大体の新規事業ではどちらかと言えばとりあえず一通りはなんとなくこなせる程度の人が向いていたりする印象です。

特化型の人材を領域ごとに集めたアベンジャーズ的チームもありかもですが、多分誰かはどこかのタイミングで暇になります。

そういったチームにおける「技術力」の定量化って本当に難しい。

特化型のスキルが求められている場合はこの辺結構やりやすいです。
その分野で必要とされるスキルのパワーというのは、割と相対化しやすいので「凄い人」が見えやすいです。

でもその範囲を広く取れば取るほどその「凄さ」という指標はモヤモヤと雰囲気寄りのバズワードになっていきます。

それでも人々はそういうよくわからん曖昧さを嫌うので、あの人が言えば間違いないはずだ的なヒーローを担ぎ上げます。
何でもできるスーパーヒーロー。

こうなるともう大変。

その英雄伝説はその自らの責任感に則ってチームをリードするし、カリスマを見出した大衆はそれに盲目的に付き従う。
これはある側面では必要なことかもしれませんが、前述した通り0->1における最適解なんてのは生存バイアスでしかないので、組織的な思考停止をまねくのみです。

「凄い人」が下した「凄い決断」はその事業、そのサービス、そのフェーズ、そのプロダクト、そのチーム、そのターゲットユーザーに本当に合っていますか？

不確実性の塊である事業の立ち上げには最適解がないように、技術という側面においても何がちょうど良いかは本当にわかりません。
0->1フェーズにおいては、結果としての「凄い人」は居たとしてもその過程には決して「凄い人」など存在しないのです。

だって1にならなかったら0なんですから。
何もしなかったと同じです。

こうしてあなたの新規事業プロダクト開発はムキムキのMr.インクレディブルと共に失敗します。

失敗からの学び

技術という側面に限らず新規事業開発における組織的な思考停止は、即ちその事業の「死」を意味します。

基本的にはまだ何も価値を生み出していないのだから、それなりにユーザーが付いているサービスのように半自動的な成長という慣性が働きません。

トップダウン・ボトムアップとかそういう二元論ではなく、チームのメンバー全員が自分ごととしていっぱいちゃんとあたまを使う。
そんな組織でないと事業の立ち上げは結構難しいと思います。

ただ、「凄い人」が「めっっっちゃ凄い人」なら別です多分。

4. 自分の役割を限定する

なにも、ITエンジニアの貴方に焼きそばを焼けと言っているわけではありません。

社内新規事業の立ち上げ方は、その会社や扱う分野によってやり方が異なると思います。
一気に資本を投下して垂直立ち上げを目指す場合もあると思いますし、フットワーク重視の少人数チームで最小限のコストで事業を始めるパターンもあると思います。

弊社の新規事業は今までどちらかと言うと後者のパターンの方が多かったです。
そして、普通のスタートアップもほぼ全てが後者のパターンでしょう。

こういった少人数構成のメリットは何と言ってもコミュニケーションコストの低さと柔軟性の高さにあると思います。

同質性の強い人を起業仲間とせよという先人たちの助言は高い機動性が求められる0->1フェーズにおいて説得力があります。
いくら当方ボーカルでドラマーを募集したとて、志向する音楽性が全く異なれば即刻解散するものでしょう。

役割の違いと方向性の違いというのは全く別次元の話です。

一方、スモール組織の最大の弱点はその字面の通り圧倒的な火力不足。
小回りが効く分、それぞれに与えられた役割をこなしているだけなわけにはいきません。

やれる人がやれる事をやれる時にやる。
そんなスタンスが求められます。

もちろん、専門家でない人が専門外のことをやるのは非効率です。
しかし、創造期における効率というのは必ずしも一般論としてのそれとは性質が異なるのではないかと僕は考えています。

もしかしたら、顧客からの問い合わせメールに返信する中で、便利そうな追加機能を思いつくかもしれません。
もしかしたら、運用業務を手伝う中で、無駄な反復作業を発見し、自動化への提案が行えるかもしれません。
もしかしたら、焼きそばを焼いているうちに、あのスパゲッティコードの解法が閃くかもしれません。

0->1フェーズにおける自組織のビジネス環境というのは基本的に「こなれていない」状態だと思うので、どんな行動がどんなことに効くのかが読めないのです。

そんな時に「そんなの（俺に）関係ねぃ」と自分の役割を限定してしまうと、機能として穴だらけの組織に普通になります。

重なり合わないベン図。つまりノーベン図。
僕はこれをちゃんとした美しいベン図にするべきと思います。

仮に3つの円があった場合、３人の◯が重なり合う「パンツ部分」が程よく大きいと、きっとそのチームは良いチームです。

大きすぎても駄目です。同質性が高すぎます。
同じ業務ばかり、思考ばかりをしていては流石に非効率というかそもそもなんか色々ダメです。
デカパン注意。

重なりが小さすぎるとなんのコラボレーションも起きません。一緒にやる必要がない。
そういう仕事はしっかりとした枠組みがあれば成り立つやつです。
そんなホワイトな状況、このフェーズにはありません。

そんなスタンスのメンバー同士だと、「なんで俺がこんなこと」となって、ただでさえ穴だらけの小さな組織の墓穴が余計に広がります。

僕も実装に集中しすぎてビジネスへの興味を疎かにしてしまい、なぜそれが要求仕様として上がってきているのかを上手く解釈できず、言われたまま開発してしまったことが何度かあります。

後から考えるとエンジニアとしてもっと良いソリューションを提案できたはずなのに、事業への解像度が低すぎて、結果的に未来の自分の首を締める設計をしたりしていました。
そんなことをやっていると、後から入ってきたメンバーに、なんでこうなっているの？と不思議がられる（withオブラート）という不名誉なオチをつけられます。

こうしてあなたの新規事業プロダクト開発はビチビチのタイニーパンツと共に失敗します。

失敗からの学び

与えられた役割を全うする以前に、自分たちの最終目的は何なのかというところから逆算して考えるということが大事だと思います。
そうすると自ずと自分のやるべきことが限定的でないことに気付けます。

弊社には掲げているバリューの一つに "Beyond Borders" というものが存在します。
自分の境界を超えてコトを成すことでより良い価値を生み出すことができるかもしれません。

あ、でもちゃんと自分の領域では最低限、期待値以上のことはやりましょう。
浮気ばかりしていると人から信用されません。

最後に

この他にもたくさんの失敗（だったなと思うこと）を経験してきました。

もちろん失敗だけでなく、無事0->1のフェーズを脱し成長軌道に乗せることができたプロダクトもありますし、あのとき丁寧に設計したアレが結構いい感じで生きていて自己満足しているところもあったりします。

成功体験と失敗体験の両方を経験することで「どんな行いが良いor悪い結果を生みがちなのか」という相対評価を事業のフェーズを意識しながら（ある程度は）できる身体になった気がしています。

だからと言って、次の新規事業をエンジニアとして器用に立ち上げることができるかと言えばそうではないと思いますし、多分また苦戦するんじゃないでしょうか。
それでもまたその時は七転八倒四苦八苦しながら生みの苦しみを楽しむのだと思います。

最後にこんなダラダラと説教臭いポエムを書き散らして元も子もないことを言いますが、立ち上げフェーズの各種判断基準は徹頭徹尾「バランス」が重要だなと思います。

そのバランスの支点がどこにあるかがわからないから難しいのです。

その惑星直列みたいな奇跡的な調和の構成要素には、当然ながら「運」も含まれるわけで、正の再現性なんて決して高くはないのです。

悲しいかな。

筆者について

首藤宏朗。株式会社ココナラで自称ハイパーメディアクリエイター見習いとして約9年、ココナラ初期の開発と（全部ではないけど）ほとんどの新規事業サービス（ココナラ法律相談、ココナラエージェント、他…）の立ち上げに従事。現在もココナラエージェントと別の新規事業プロダクトの開発をやっている。社歴マウントなら大体負けない。