15
13

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

More than 3 years have passed since last update.

エンジニアが起業に失敗する4つの理由

Last updated at Posted at 2020-04-13

この記事は、INDIE HACKERSに投稿されたIvan Mirさんの記事「What Makes Developers Bad at Business」の意訳・要約です。

翻訳と投稿の許可はいただいています。

なぜエンジニアはビジネスに失敗するのか

20339.jpg

1.エンジニアリングの魔力に負ける

エンジニアはビジネスタスクよりもエンジニアリングを優先しがちです。

非技術者の起業家は開発をコストとして認識しています。

主な目標は収益性の高いビジネスであり、エンジニアリングはそこに至るための高額なコストにすぎません。

一方で、エンジニアにとってエンジニアリングは比較的簡単なので、ついつい余分な機能を追加したりしがちです。

最悪なケースは、機能からビジネスを考えてしまうことです。

たまにはうまくいくかもしれませんが、既存/潜在顧客と話すなどの市場調査に基づいてビジネスを考え、そこに機能を当てはめるのが基本です。

ビジネスの過程とその結果の90%はコーディングにあらず。
例えば、プレセールスの問い合わせへの対応、マーケティング、SEO、マーケティング、カスタマーサポート、マーケティング、WEBサイトのコピーライティング、それとマーケティングなどだ。
ー Patrick McKenzie


次に、ツールの構築と保守のブラックホールがあります。

作業に1週間以上かかる場合は注意してください!これによりプロジェクトが完全に崩壊する可能性があります。

作業の代替に高価なPaaSなどのサブスクリプションが必要な場合でも、長期的に見れば多くのお金を節約できるかもしれません。


「マーケティングを行う」「ランディングページを改善する」などの漠然としたタスクに直面してしまうと、難しいはずのエンジニアリングタスクすらとても簡単に見えてしまうものです。

こういう時は、アイゼンハワーマトリクスなどを活用して、優先順位を決めるのが良いでしょう。

意識すること

  • 市場調査なしにコードを記述しない。
  • すでに習熟している「退屈な」技術スタックを使用する。トレンディな技術選定はバグを増やし、ドキュメントやライブラリ、そして開発者を探すことを難しくする。
  • 可能な限りシンプルな実装を選択する。サードパーティ製品の活用を厭わない。
  • 優先度の高いビジネスタスクがあるなら、エンジニアリングを後回しにする。

2.熟考・完璧主義に陥る

プロジェクトを立ち上げたぞ!
よーし、まずは使う技術と機能を検討するぜ!

・・・

1ヶ月経過

・・・

疲れた、、僕には無理だ、、諦めよ
(この間、書いたコード0行!!!)

みたいなことを避けるためには、いくつかの制約を設定することが有効な場合があります。

例えば、

  • 1週間の調査の後、その中から一番良さそうなものを選ぶ
  • リリースの期限を設定して、それに間に合うように最善を尽くす

などです。

リリースが完璧出ないことを心配するのはやめましょう。販売開始の前に100%のプロダクトにする必要がないからです。競合他社より機能が少なくても、それが優れていれば良いのです。


機能は友達ではありません。
機能が1個増えるごとにUIが複雑になり、バグが増え、コードのメンテナンスが複雑になり、ユーザーサポートが必要になります。

これが、MVP(Minimum Viable Product)が効率的と言われる所以です。

コアアイディアを検証し、顧客のフィードバックを収集して、市場の実際のニーズに応じた正しい機能を開発しましょう。


コードがイケてるだとか、エモいアルゴリズムを使ってるだとか、そんなことを顧客は気にしません。

彼らは、課題を解決するためにプロダクトを雇うのです。

成功しているプロダクトの多くは、最初の顧客を獲得した後に少しずつ改良されています。

一方で、作者が「正しく作ろう」と完璧主義に敗れたが故に、リリースに至れなかったプロダクトは無限にあります。

意識すること

  • 完璧主義に打ち克つために制約を設定し、それに従う。
  • 機能ではなく、メリットに焦点を当てる。
  • できるだけ早くリリースして、アイディアを検証し、市場にさらなる改善を求めてもらう。
  • あなたにとっての初めてのプロジェクトなら、特に小さく始めるべき

3.内向的になる

目立ちたくない、矢面に晒されたくない、必死に発信するのとかダサい、そう思う気持ちはわかります。ただ、悲しいことにそれは成功の確率を大幅に減少させます。

あなたがインターネットで大声でプロダクトについて発信しない限り、誰にも気付いてもらえません。

これは、バイラルでない(口コミを発生させにくい)プロダクトに特に当てはまります。また、バイラルであっても、ノイズを突破して強い牽引力を得るために初期のプロモーションは重要です。

定期的な宣伝なしでは、将来の顧客、味方になりうる他の起業家、あるいはあなたのプロダクトに近いドメインで活動しているライターでさえ、あなたがしていることに気付きません。

開発者は、ダサいと思われることを恐れて発信できない場合が多いです。

プロダクトにはセールスが不可欠です。
ビジネスパーソンは常にセールスを行い、あなたへの批判に腹を立てるべきではありません。

スタートアップを始めたハッカーは、イケてるソフトウェアを開発し、サーバーに配置し、売り上げを監視していれば、ユーザーと話したり、他の企業と交渉したり、取引せずとも成功できると思っています。
もしかしたらそれは可能かもしれません。でも、そんな例を私は見たことがない。
ー Paul Graham


内向的にプロダクト開発に取り組み続けていると、視野が狭くなります。

これに対処するためには、様々な人から頻繁にフィードバックをもらうと良いでしょう。

彼らは、初心者な目線でプロダクトに向き合ってくれるので、あなたの気づけない視点から意見をくれるでしょう。


コーディングばかりしていると、共感力が低下します。

以前私が1週間コーディングマラソンした後は、社会性が麻痺してるのを感じました。皆さんはそんなことはないかもしれませんが...

共感力が低下すると、私生活がうまくいかないだけでなく、他の人が製品をどう認識するかを理解できなくなり、マーケティングなどにマイナスな影響を与えるでしょう。

意識すること

  • 少なくとも、週に1回はマーケティングとプロモーションに取り組む。何も見せるものがなくても、プロダクト活用のアイディアや使い方について話すべき。
  • 知らない人に連絡するのをためらわない。それがビジネスを行う上で重要となる。
  • 定期的に他の人からのフィードバックを求めることで、自身の認識を調整する。

4.技術に傾倒した生活を送る

現代のソフトウェア開発は、非常に要求が激しく、言語、フレームワーク、ツール、プラットフォーム、API、などの知識を常に学習して知識や経験をアップデートしていく必要があります。

それ故に、多くのソフトウェアエンジニアは技術に関連した趣味を好む傾向にあります。

しかし、技術に傾倒した生活を送っていると、成功を損なう場合があります。

エンジニアは、技術に明るい人々との交流が多くなり、そうでない人々の感覚が欠如しやすいです。

なんでみんなSlack使わずにLINE使うんだろ...
Androidの方がiPhoneよりコスパ良いだろ!
こういった怠惰な思考は危険です。
一般に流行している製品から、UXや非技術者にとっての重要性など、学ぶべきことはたくさんあります。


もちろん、一般向けではなく、技術者むけにプロダクトを作ることはできます。しかし、このニッチな市場は既にレッドオーシャンです。

優れたアイディアを見つけるには、技術に傾倒した生活とオサラバして、他の業界や珍しいライフスタイルの曖昧なニーズを探っていく必要があります。

あなたの人生において、ユニークなことがあるならば、あなたはその領域の痒いところに手が届きます。あなたがヨガと青汁が好きなサンフランシスコのフリーランスのグラフィックデザイナーならば、あなたは新しいことを始めた方が良いでしょう。
ー Tyler Tringas


技術的なバックグラウンドを持つ企業家にとってのもう一つの課題は、自然科学と工学以外の分野に慣れることです。

全てのビジネスは心理学とソーシャルインテリジェンスに大きく依存しています。

プロダクトのデザイン、マーケティング、セールスなどは全て、他者のニーズと行動を理解することから始まります。

合理的なエンジニアであれば、これらの分野の全ての答えを簡単に推測できるように思えるかもしれませんが、私自身の経験からするとそれはダニングクルーガー効果の作用です。

これらの分野は何世紀にも渡って研究開発されてきた複雑なものです。

これを学ぶことで思考力を大幅に向上させることができます。

意識すること

  • 非技術者がソフトウェアとどのようにやり取りし、どのような前提を持っているか観察する。
  • あなたが気に入らずとも、人気のある製品は分析すべき。
  • 様々なニッチな業界と繋がり、それらを理解する。
  • 毎週時間をかけてデザインやマーケティングなど専門でないテーマに飛び込んでみる。

まとめ

この記事の目的は、開発者がブートストラップを行わないようにすることではありません。実際、それはまったく逆です。

スタートアッププロジェクトの全範囲を担当する時は、以上の「意識すること」を念頭に置いてください。

幸運をお祈りしています。

訳者感想

機能からビジネスを考えてしまう

これは耳が痛いです...w
まさに自分のことだなぁと思いました。

僕がポストイットに書いて貼ったメモには機能のことばかり書いてあります。

課題仮説→市場調査→ビジネス考案→機能当てはめ→開発→検証→アップデート
の流れを、意識するだけでなく、実践していく必要がありますね。

開発者は、ダサいと思われることを恐れて発信できない場合が多いです。

自身のプロダクトについて、自信を持って、大々的に発信するのって、僕にとってすごく勇気がいることです。

今改めて、(僕が勝手に)リスペクトしているIndieHackerのTwitterをみてみると、自身のプロダクトに関連することを頻繁に発信していことに気づきました。

成功するためには、勇気を持たなきゃなと考えを改めます。


僕が勝手にリスペクトしているIndieHackers


技術に傾倒した生活を送っていると、成功を損なう場合があります

僕はこれ、TimeTreeの流行で感じました。

自分にとって、スケジュールはGoogleカレンダーに登録し、他者と共有することが当たり前で、特別なことではなかった。

しかし、エンジニアでない多くの人々にはそれが特別だったようです。

非エンジニアの当たり前を知って、そこをDXするようなプロダクトを開発していきたいですね。

15
13
1

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
15
13

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?