kur.jp

バイオリンと自転車をこよなく愛するkurのチラシの裏。たまには技術的なことを書いたりするかも知れません。

起業するとき気をつけたい3つのこと

私が関わった会社がそこまで大きくなったって言う話は聞かないものの、そこそこうまく回ってる会社と、そもそも離陸すらできてない会社があったりする。これらで何が違うんだろう?って考えて、そこそこうまく行ってる会社について共通する特徴を考えてみた。もしかしたら業界によっても違うのかもしれないし、世の中のアントレプレナーな人達が見たら、鼻で笑われるかも知れないけど。

というわけで、私が次に起業するとき気をつけたい3つの事はこんな感じ。

  1. 何のために起業するかを考える
  2. とにかく顔を合わせる
  3. 温度差の存在を理解する

それぞれについて説明します。

1. 何のために起業するかを考える

創業者が複数人居て、起業の目的がそれぞれ違う場合は厄介です。話の流れで「起業しようぜ」ってなったとしても、起業の目的がそれぞれ違う場合ってのは良くある話です。良くある起業の目的ってのはこんな感じ。

  • お小遣い稼ぎ
  • 上場して一攫千金
  • 自分達の製品のリリース
  • 自分達が世界を変える
  • 社長って名乗りたい

もちろん、目的がひとつである必要はなくて、複合的な目的でも良いんですけど、少なくとも優先順位は決めておいたほうがいいと思います。ここの部分がもやもやしてると、会社の方向性を決める時にもめてしまうことがあります。メンバー間で目的が共有できていれば、その目的を達成するためにはどうすればよいか?を考えて判断することが出来ます。

例えば、ソフトウェアエンジニアが集まっていざ起業しようってなったとき、他の会社から開発案件を受注して開発するような受託ビジネスをするか、独自製品を開発してビジネスをするかで意見がわかれる場合があります。

受託開発であれば、仕事さえ請けることが出来れば、確実に売り上げが得られるので、そこまでリスクが大きくありません。ただし、リターンもそこまで大きくはない。いくら天才プログラマだろうと、1人があげられる売り上げってのは限度があります。そういった面で、ローリスクローリターンと言えます。

自社製品を開発する場合であれば、実際にどの程度売れるかどうかは、製品が完成して販売を開始するまでわかりません。場合によっては開発に多くの時間がかかったのに、まったく売れないというリスクもある。ただし、もしかしたら3人ぐらいでつくったソフトウェアがとんでもない価値になるかも知れません。Dropboxなんかはエンジニアが20人にも満たないのに、数千億円の企業価値があるとも言われています。リスクはありますが、あたればリターンも大きいです。

受託開発と自社製品開発ではリスクやリターンが異なってくるため議論になりやすいのですが、あらかじめメンバーの中で起業の目的を話し合っておけば、こういった議論をせずに済みます。他にも、会社を運営する上で決めなければいけないことは多くありますが、あらかじめ目的をすり合わせておけば、目的を達成するためにはどうすればよいか?という観点から決めることが出来るので会社としての意思決定が楽になります。

いくら気が合う仲の良いメンバーだったとしても、「何のために起業するのか?」がバラバラだと、意見の調整が難しくなってしまいます。一緒に起業するメンバーを考えるとき、仲が良いかはもちろん大切な要件だと思いますが、「何のために起業するのか?」に対する考え方が一致するかを重視すべきです。

2. とにかく顔を合わせる

非効率だと思われるかも知れませんが、特に用事がなくても顔を合わせるのは結構大事だと思います。

効率性だけを求めるのであれば、事前に打ち合わせのアジェンダを用意してアジェンダに関係があれば打ち合わせを行う、自分にあまり関係なければスルーする、などといった運用が出来ると思います。用事がないのに自分の時間を取られたくないという気持ちは私自身もよくわかるのですが、特に用事がなくたって実際に顔を合わせることって結構大事だと思います。

今は、メールやSkypeなどもあるのでちょっとしたやり取りには困りませんし、ちょっと複雑な話でも電話をすれば事足りることが多いです。でも、文字や声だけで伝わらない情報って結構あるんです。たとえば自分が会社の方針に対して何らかの提案をしたとして、他のメンバーからYesを引き出せたとします。だけどこのYesが積極的なYesなのか、消極的なYesなのか、文字や音声だといまいちわからないこともあります。

また、雑談から生まれるアイディアって結構多いです。だから特に用事が無くても顔をあわせてみる。なんだったら定期的にご飯を食べに行くとかでも良いと思うので、とにかく実際に顔を合わせることが大事だと思います。

3. メンバー間の温度差の存在を理解する

理想を言えばキリがありませんが現実問題として、複数人で作業する以上、メンバー間で多少の温度差が出来てしまうことは仕方がないことだと思います。だけど仕方ないのなら仕方ないなりに、温度差の存在を認め、いかにプロジェクトをまわしていくは、非常に重要な問題です。

例えばメンバーが複数人居て、無職と社会人の人が居たとします。無職の人の場合、収入がないとどうやった食べていくかを考えなければなりませんから、どうしても焦りが生じてしまいますが、社会人の場合、昼間働いていればとりあえず食べていくことはできるわけですから、そこまで焦ることも少なくなってしまいます。

他の例を挙げます。起業するにあたっては様々なタスクが発生するわけですが、この負荷をどのように分散させるかということも考えなければなりません。特定の人だけに負荷が偏ってしまうと、不満の温床になってしまう場合があります。貢献度に応じて何らかのリターンがあるとかであればよいのですが、売り上げのない段階ではこういったことを考えるのも難しいです。多少無理をしてでも資本金の中から給与を出せばよいのかも知れませんが、これも実際には、なかなか難しいと思います。

温度差ではないかも知れませんが貢献度の話のついでに書いておくと、エンジニアとビジネス屋さんはお互いに相手の仕事を軽く見る傾向があるように思います。エンジニア同士でご飯を食べに行って、ビジネス屋さんの悪口を言うようになったら危険信号かも知れません。

ただ、私は、これらに関して良い解決策は持っていません。ひとつあげるとするなら、最初の段階で人を増やしすぎず、お互いに十分なコミュニケーションをとれる人数で基礎を作るということが挙げられるかもしれませんが、何人ぐらいが適切かと言うことも難しい話だと思います。やはりとにかく顔を合わせて、お互いの考えを理解し、不満の芽を早い段階で摘んでおくのが良いかも知れません。

さいごに

私がこれまでに様々なプロジェクトを通して学んだことを書いてみたものの、私自身、そこまで大きなプロジェクトを大成功させた経験がないので説得力に欠けるところは否めないし、経験豊富な人から見れば、それはあんまり重要じゃないって言われるかも知れない。5年後ぐらいにこのエントリを自分で読み返したら考えが変わってる可能性は大いにあると思う。

ただ、少なくとも、今取り組んでいるプロジェクトであったり、今後取り組むプロジェクトにおいては、上記のことについて気をつけたいなぁと思う次第。