新規事業はなぜ失敗するのかの3つの理由
最近よく新規事業に携わっていると、新規事業はよく失敗すると言われるが何故失敗するのだろうかと自分の経験則から3つ書いてみたいと思う。
１：アイディアに対する過剰な自信
全くアイディアがでないときに、ふと思いついたもしくは考え出したものは 大抵イケテナイものだ。
よくあるパターンとして、せっかく出したアイディアであるがために、 それをどうやって正当化しようかという思考回路に陥ることだ。
そういった思考回路になると、情報収集したりヒアリングしたときも 正当化するためのリソースしか拾ってこずにプロダクトを作り上げてしまう。
そして、リリースしてみたものの誰も使わないプロダクトになる。
スタートアップにとって一番難しいのは、人々の欲しいと思うものを作れるかどうかである。
一つのアイディアに固執せず、時には俯瞰してみて粘り強くかつ素早くMVPプロダクトを 繰り返し作り、諦めないことだ。
また、営業資料自体をMVPプロダクトにしたっていいではないか。 それでクライアントの反応を見て何社中何社利用しそうかというファクトを見て プロダクトを作り上げるのも一つ手ではある。
２：責任者の確固たる自身を持ち続けられるか？
新規事業が世の中に出るのは、製品・サービスを作り上げてからである。
そこから、マーケットフィットさせるために長い時間をかけて、 プロダクトの認知をさせる必要がある。
「今までやってきたことは無駄だったのかな？」
こういった葛藤に戦い続ける必要がある。
日が経つにつれてお金が減っていく恐怖に対して、 これで行くんだ！という自身を持ち続けることが重要だ。
これがブレると、プロダクトではなく、 見せ方や売り方など利害関係者にどう良く見てもらえるのか？という 本質的なことは考えなくなり破滅への道を辿っていく。
３：リーンスタートアップ的な考え方
事業を行う上で、もう一つプロセスを適宜修正できる柔軟性を持ち続けることが重要だ。
リーンスタートアップと多くの企業でも言われているが、 なかなか実行しようとしても実行している人は少ないと思う。
考えられる理由としては、普段忙しいなかで振り返る時間が少ないということが言える。
特にリーンで重要なことは正しい目的に着くためにはどういった正しい やり方を踏んでいくかが重要だ。
行っている施策は効果あったのか？失敗したのか、成功したのか、 その原因はなんだったのか？これがわからない時点では、 いいプロセスは回せない。
読んでいる方からしたら、 当たり前のように聞こえるが日々忙殺されてる日々を過ごしていると 振り返って次のアクションを回せず、今どんな検証をしてるんだっけ？ という状態に陥ることは多々ある。
最後に、もちろんプロセスも大事だが、最終的なものを目指す形を イメージすることも重要だ。
このサービスで絶対いける！と盲信することほど危険なことはない。 時にはマクロ的な視点をもってピボットする勇気も必要だ。
以上3つが、事業を推進するものにとっての主な失敗要因だと最近感じている。
インプットの仕組化
最近、どのように日々インプットしてるのかと聞かれる事が多いので下記に個人的にインプットしてる仕組みを書こうと思う。
私がよく言ってるのはインプットの仕組化において重要なのは
「いかに不要な情報を追わないか」ということ。
人間の能には限界もあるし、せいぜい一日でインプット出来る量もたかがしれてる。
【Tech系】
・javascript weekly
・githubのトレンド（メルマガを利用）
・facebookのテック系記事
【キャリア】
・個人的にとても好きなブログで毎回読んでる
http://tomomatsukawa.blogspot.jp/
上記に加えて随時更新していきます。
エンジニアとして経営サイドと現場サイドの両方を経験して思った事
去年は会社の経営サイドに関わっていて、エンジニアとして現場にがっつり開発のコミットしてなかった。
どちらかというと、組織内に技術をどう浸透させるか？非エンジニアでも技術的な要素を理解してもらい、技術で何ができるのか？を全員理解して、エンジニアの評価制度も構築していた。
そして、訳あってここ5ヶ月間は打って変わって現場にがっつり入って開発に従事している。
そこで感じたことをつらつら書きたいと思う。
１：80対20の必要性
どうしてもプロジェクト中は、同じ技術に触れていて、直近の技術トレンドを追いかけていくのにも遅れが生じるものだ。
そして、プロジェクト人数が少なく、個々のタスクがパツパツだと尚更だ。
そして、よくディレクターはエンジニアがヒマを持て余さないようにプロジェクト間も隙間無くタスク入れてくる事もある。
そうなってくると、次のプロジェクトも何かちょっとしたことを技術的に試したいといっても上手く行けば良いがリスクもあるため、結局今までの既存のやり方で行う。
上記のような悪循環から既存のやり方で行うために、個々のモチベーションが保てにくい。。
だからこそ、エンジニアのインプットというのは重要であって、80対20の法則
（仕事の80％は業務で20％は技術トレンドを追う制度のことを指している）というものが出たのだろう。
まあ、必ずしも80対20の必要性はないが、勉強会やら社内の共有などやっていれば必然的に80対20になっていくのだろうとも感じる。
２：現場サイドから見たリーダー
上記の話しの続きになるが、上記の悪循環にいかに起こらないようにするかはリーダーの仕事の一貫でもある。
個人的な見解だが、エンジニアが会社を退職する理由は大きく二つだ。
①：技術的な倦怠
②：事業の倦怠
だからこそ、いかにエンジニアが技術的に貪欲になって次のステップにチャレンジしけるかが重要。
今のITはエンジニアが育っていく風土を形成しないと会社自体が成長しないとい記事もあったが正にそう感じる。
現場サイドからしたら、そう言う点で割とシビアにリーダーを評価してくる。
あのリーダーは評価してくれない。技術を軽視している。なんでこのプロジェクトやるのか？などなど
そして、リーダーからすれば全てよかれと思ってやっていたりして全て裏目にでてしまう。。
でも、こう言った現場目線の率直な意見は聞くと辛くて若干、何を分かってるんだ！おれは必死にやってるんだ！という感じで怒りたくなる気持ちも分かりたくなるが、落ち着いて聞いてみるとごもっともである。
逆にこういう率直なフィードバックをもらえてる環境に感謝すべきだと思う。
３：エンジニアの今後のキャリア
この点は割と評価制度の点でも重要になってくると思うが、
必ずしも技術力が高いエンジニアが成果でやすい仕組みにしにくいということだ。
どういう事かというと、ある一定レベルに技術力が達してしまうと作るプロダクトによってもそうだが、自分の技術力の100％がアウトプットしにくくなる。
一個人の評価の一つにもちろん、報酬もある。
その報酬はもちろん会社の業績によって比例してくる。だからこそ、エンジニアはある一定の技術力保有してくると、いかに自分の技術が市場に受け入れられる状態になるか？
もしくは自分以外の人でも高い技術力を保有する状態にしていくにはどうするか？
ということを実践していかなくてはならない。
こういって、エンジニアは個から対へと貢献する対象が変わっていくんだなと改めて感じた。
「資本の強い会社 = ユーザーファーストのプロフダクトを制作できる」という考え方について
表題の通り、最近私の周りでユーザーファーストでやりたいから資金が潤沢のところに行きました的な話しをよく聞く。
そこで私は以下のような仮説をたてて、その仮説に対して考察していきたい。
仮説：資本の強い会社 = ユーザーファーストのプロフダクトを制作できる
つまり、この仮説に対しては、資本とユーザーファーストでプロダクト制作ができるということに
相関関係があるということなのだろうか？と私は思う。
ベンチャーでの宿命でもあると思うが、限られたキャッシュの中でいかに
プロダクトをリリースして爆速でPDCAを回せるかがカギになってきて
割と体力勝負になってくる
最近、具体的なサービス名は出さないものの、
VCが入ったことで個人的に悪化したなーと思うサービスもあり、
資本の強い会社とユーザーファーストのプロダクトを作れるという要素の
相関関係がどこまであるのかをふとした瞬間によく考える
ただ、とても個人的ではあるが、
スタンス的に、ベンチャーでやっているとキャッシュを気にして何もできず事業失敗も責任者のせいだ！という人をとても好まない。。
割とサービスを創るというと、BtoCに限った視野を持った人がいるがBtoBのサービスもあることを忘れないで欲しい。
つまりBtoBで換金化できなかったサービスとかは極論言うと、ユーザーにとって価値のないものだったということだと思っている。
何かふと資金が少ないからこそユーザーファーストでサービスを創り上げて行かないと
マズい！という風潮もあったりするし、資金が潤沢になってくると利害関係社が多くなってきて雑音が多くなるという
話しを聞くしなーとも思う。
と色々考えてみたものの、私が思うには
いかに共感しあえる仲間と本気で一緒にプロダクトを作っていけるかが
本当に重要だと思う。
ここで言う「本気で」というのは結構重要だと思っていて、どんな環境でもそこの壁を突き破れる人材or組織になれるかが
結局は重要
何か上に仮説をたてたが、要は人材次第だと思うなーとやはり思う。
日本のIT業界に対して思った事
最近、個人的にわりかし大きい企業と仕事をしたり、やり取りする機会が多くなってきて世の中のエンジニアの見方に対して、思ったことがあった。
マネージャーや役員勢がエンジニアの方が本当に少ない
これはしみじみ感じたことだが、役員の方とかにエンジニアが本当にすくないように思える
もちろん、技術的な会社はそんなことは無いが、今やITという分野はどんな事業領域でも必要になってきてる事は自明になっていると思う。
だからこそ、技術観点での側面で考える機会が本当に必要になってきててる中、思考的に少ない
あとは、エンジニアはたかだか、制作のみの仕事にするという印象が強い
まあ、日本のエンジニアの価値が小さいというのが言われてる理由も分かった。
もちろん、コードが書けたりものづくり出来たりとする必要は無いと思うが、個々がエンジニア目線でもビジネスを考えられる必要があるべきではというときが、多くある
だからこそ、私は最近そういう思考性の方が多いので海外からしたら今や日本のIT分野は衰退領域なんて言われる機会も多くなってるのではと思う。
個人的にこういう根本的なところから考えて、見直して行きたい。
ベンチャーにおける組織というのを考えてみる
私は現在、大手からスタートアップまでいろんな事業の手伝いをさせて頂いている中で、割と人材を適材適所に配置して効率よく事業を回してるケースが多くないと感じた。
特に急成長中のスタートアップやベンチャーは如実に現れてる。
「この人がこの仕事をやるべきではないよなー」とか自分が苦手な仕事を頑張って「おれ頑張ってるし、成果はこれからだ！」というよく分からないポジティブ頑張りとか色々ケースはあるかなと。
そろそろ日本のベンチャーで意識していかないといけないのは、頑張れば成果でるという考え方は通用しないと思う。むしろ古い。。
ここで言う「頑張る」の定義だが、
私は自分がやっていてわくわくしなくて、得意分野でないことを頑張っていることを指している。
もちろん、そういう頑張りも必要なときはあるが、自分にしかできないポイントを組織内で見いだし、そこにフォーカスしていくという考えがまだ薄いかなと。
あともう一つ情報共有の点。
これはスタートアップではあるあるだが、開発体制やプロダクトのリリース体制がしっかりしてない分、お互いのタスクの認識や問題点に関してがブラックボックス化されてしまっている。
そうなってくると、急にクリティカルな問題が浮上してバタバタする。。
とにかく、私もこれは経験済ではあるが、社員が少数のときでも日ごとベースでもいいので、タスクの共有をしたり、当たり前のことを継続して行って行く事が本当に重要かと。
【プロダクト開発において重要なこと】
グロースハックというワードが多く出てきて、割とサービスを成長するにあたってこのワードを使うのが一般的になってきたなと最近思います。
そこで、今回グロースハックの本質的な部分を書きたいと思います。
１：how toに注力しすぎない
割と今はいろんなサービスがあり、グロースハックにおいての記事が多く出ています。しかも、データサイエンティストブームもありデータドリブン的に物事を捉えることが増えています。
しかし、忘れてはいけないのはサービス自体がどんな価値提供をしたいのか？どんな世界観を提供したいのかを明確に描く事を忘れてはならないということです。
正直、グロースハックの事例が多くあってそれに乗っ取ってサービスをグロースしているケースが見受けられます。
それはそれで本当に素晴らしい事だと思います。
ただ、言える事はCV率などをあげるなどのグロースがサービスの本質的な部分でないことは忘れないで欲しいと思います。
よく失敗するケースは部分的に最適化はできたけど、サービスビジョンレベルでの全体の最適化が上手くいっていないケースです。
これが本当に多いような気はします。
なので、本当にどんな価値を提供するのかどんな世界観を作るのかを明確にして、さらにチーム全体の共通認識をもつことがグロースへの第一歩だと思います。
２：多くのデータを取得したがらない
取れるデータは取っておいて全然いいでしょ！的な感じでよく聞きますが、
とても危険な兆候だと思います。
データを取得しやすくなった今、それを基にPDCAを回して行こうと思ってるところは
確実に判断を迷わせます。
絶対にデータドリブン的に動きたいのであれば、仮説をたてて1機能にフォーカスすることが重要です。
1機能だけでも自分たちの描く100％を追求することはとても難しいです。
以上が私がグロースハックブームの中で感じたことです。
こう見るととても当たり前のことを書いてはいますが（笑）
