toru-murasawaの日記

IoT,Startup,Technology etc

起業して5年がたった。

第5期の決算が終わったので、起業後5年がたったことになる。

途中、1年9ヶ月の休眠時期(会社員をやっていた)を経て復活しやっとPLベースで黒字化した。
この5年間やってきたことを振り返る余裕などなく、とにかく事業を継続するためにフリーランスの仕事などで会社に資金を入れ続け何とか創業期の累積赤字を払拭することができた。

今期(6期)は、ひとまずやるべきことは明らかなので地に足をつけて堅実に経営していきたい。

起業してよかったのか

結論から言うと、トータルで「よかった」と考えている。

  • 時間の使い方を比較的自由にできる
  • 会社員時代より会社や上司の方針にストレスを感じることがない
  • 自分のやりたいテーマをとことん追求できる

相応の自由を得た分、資金繰りや事業の進捗は常に頭の中から離れることはない。

スモールビジネスは向こう3ヶ月のキャッシュフロー管理だけは徹底し、やるべき事をやった後はコントロールできない現象に関しては諦めるのがストレスコントロールとして良いのではないだろうか。商売はマラソンである。いいことも続かないが悪いことも続かない。

なぜ起業したのか

2014年の2月ごろ、当時の勤務先で早期退職募集がありもともと35歳前後で独立したかったのもあり勢いだけで起業した。

起業にあたりテーマを決める必要があるが、当時M2Mと言われる領域に興味があり学生時代にメカトロニクスに触れていたのとネットワーク、クラウドの経験が活かせる農業M2Mプロダクトのリリースを目標に故郷の新潟に戻った。

f:id:toru-murasawa:20190406182214j:plain

早期退職時の退職金で県庁脇に事務所を構えた。


 

f:id:toru-murasawa:20190406182733j:plain

第1回次世代農業EXPOに一人で出展

f:id:toru-murasawa:20190406183737j:plain

当時のミッションステートメント

起業前にしておけばよかったこと

  • PL/BSの読み方を知っておけばよかった
  • 資本政策、資金調達(デット、エクイティ)の仕組み
  • 顧客を作っておけばよかった
  • 会社創立後の税金発生の仕組み
  • 知的財産周りの法律(著作権法など)
  • 顧客集客(マーケティングの基礎、ランディングページのデザインなど)
  • 一緒に事業をやる仲間を作っておけばよかった(営業もマーケティングも一人ってそりゃ無理ですよ)
  • 会社の閉じ方(会社を作るよりたたむ方が大変です。安易な起業ブームに乗ってはいけません)

しなくてよかったこと

  • 展示会(知名度のないベンチャーが展示会に出ても金が出ていくだけだった)
  • 新聞広告(上に同じ)
  • VCから資金調達(2019年現在、やっと市場が立ち上がりつつある現状で当時増資ができていたとしても溶かしてしまった)
  • 農業IoTの継続(ビジネスとしては採算が合わないと判断し、IoTプラットフォームへピボットしたのはよかった)

してよかったこと

  • 節目節目でプレスリリースを打った事(リードにつながった、メディアに掲載された)
  • 一度地元に戻った事(遊びの誘惑がないから、ひたすら開発に没頭できた)

辛かったこと

  • 銀行残高が2万で震えがきた
  • 農業IoTサービス「おんしつくん」がこけ、ピボットを決断した時
  • 休眠の決断をするとき
  • 生活のため東京に戻る時に事務所を一人で片付けぎっくり腰になった
  • 事業をやる上で、利害が絡んだ人間のいろんな姿を見た事

今後の展望

自社サービス展開は今まで一人相撲でやってきたが、OEMパートナーと協業することで、より多くの顧客に使ってもらう機会ができ今後はスケールさせる事に集中したい。

また、当初ラーメン代稼ぎのつもりのフリーランス業も最新の技術を取得できるいい機会であり、当面は続けていくつもりである。

起業当初より、随分こじんまりとまとまってしまったが、焦ってもしょうがないだろうと言う開き直りの心境ではある。

今後、壮大な夢などは無いが自社サービスを使ってくれる方がいる以上はコンパクトな事業形態は変えずにシンプルな経営を続けていきたい。

 

 

 

 

Kubernetesはいいぞ

さて、ここ最近いわゆるラーメン代稼ぎとしてインフラ関連のお仕事をいただいている中、Kubernetes(K8S)をなんとか使えるレベルにまでなってきたのでVMwareや一般的なベアメタルインフラを触ってきたエンジニアの視点でメモを書いてみる。

 

高い学習コスト

K8Sの世界は、極めて高度な抽象化がされているため、まずK8S固有の概念(Pod,service,ingress,persistent volume etc..)を理解した上で手を動かす事が必要になってくる。

基本的に、インフラレイヤとして意識するのはdockerより上位の層が中心となってくるためlow-levelでの理解はむしろ足枷にしかならず、K8Sの美味しい部分をいかに普段のインフラ構築運用上の課題解決に取り込めるかの観点で学習するのがモチベーションを維持する意味でも良いのではないかと思う。

Yamlを乗りこなせ

 K8Sでは、構成に関する全てをyamlマニフェストに定義(宣言)し、オブジェクトの作成やスケールアウトの定義までファイルとして宣言しなければならない。

このyamlをkubectlコマンドに渡して、作成、更新を繰り返していく事になる。 

例えば、ingressコントローラをインストールしたい場合、最低でもingress本体、設定(configmap)、Role、default backendのpod作成などに必要な複数のyamlファイルが必要になる。

ただ、yamlに関してはyumのような依存性を解決してくれるパッケージマネージャーのようなhelmというものがあり、これを活用する事でyaml地獄から幾らかの負担低減にはなるだろう。

Scale out/Rollingupdateが素晴らしい

宣言的インフラの意味するところ、yamlマニフェストに最小Pod(コンテナの単位)や最大Podを記述しておけば、クラスタの総リソース内で自動的にPodのScale out/inが行われる。

そして、Deploymentとして作成したPod定義のコンテナイメージのtagを書き換えれば、全Podのイメージが自動的にRollingupdateして最終的に指定通りのコンテナイメージがdeployされる。

頻繁にdeployが繰り返されるCI/CDのトレンドと最高の組み合わせではないだろうか。

まとめ

私は、Google Cloud Platformが用意するマネージドK8SであるGKEで概念を学んだが、さすがにGKE自体が純度の高いK8S環境なので、オンプレK8S環境でもGKEとほとんど変わらない感覚で操作することができた。ただ、LoadBalancer周りはクラウドプロバイダごとに固有の違いがあるので、この点だけは留意しておきたい。
総じて、K8S自体の学習コスト自体は高いものの、これからはK8Sがコンテナオーケストレーションの主流になることはもはや疑いもなく、クラウドに関わるエンジニアであれば是非とも触ってみてほしい。

 

4K最高。

開発環境として長らくMac mini 2012Lateを使ってきたのだが、昨年末にやっと新型が出たので6年ぶりに買い換えてみた。

モニタも手持ちのFull HD23インチから4K対応の27インチにしてみた。

これが想像以上に良かったので、感想を書いておく。

  • ターミナルがバカスカ開ける
  • スケーリングでなんちゃってretina化で目に優しい
  • Youtubeがきれい

買って、最初にYoutubeで見たDAPUMPのU.S.Aの臨場感がFHDで見るより全然違ったw

私が買ったのはLGの27UK600-Wという機種。Amazonで4万ちょっとで買えたが6年使ったEIZOのEV2336Wとの違いは歴然である。

まあ、4Kでスケーリング表示でも4K最高って話でしたw

 

 

ひとりスタートアップのサービス開発

久しぶりのブログ記事である。

新年ということもあり、初心に返る意味で今回はエンジニアひとりでサービス開発する際に意識しておくといいことがあるかもしれないポイントについて書いてみる。 

サービスデリバリを重視する

大抵のスタートアップは、クラウドサービスの形態(PaaS or SaaS)でサービスを世に出すことを前提とした場合、まず重視すべきは「動くものを、世に出す」ということである。

何を当たり前のことを、と言うべきところだが実際に動いて、それなりのUIを提供しそれなりのドキュメントを伴う形でローンチできるところまでは相当のエネルギーを要する。

まずは、最低限のクオリティ(MVP:Minimal Viable Product)を保ったプロダクトをスピーディに市場に出すことが何よりも最優先される。ここを意識することで、今やるべき事・やらない事の選択がシンプルになる。

Gitを使わない

チームで開発する場合はレポジトリが必須になるのは言うまでもないが、ひとりスタートアップには基本的にレポジトリ管理が必要ないと感じる。

私が採った方法は、ステージングサーバとプロダクションサーバを明確に分けプロダクション環境のコードは直接いじらずステージングサーバ上で改修を繰り返して、一定の動作確認が終わったらrsyncでコードごとプロダクションにコピーする方法だったが、シンプルかつプロダクションへの影響を最小限に抑える意味で有用なアプローチだと思う。

もちろん、Gitを使っても良いがシンプルな方法論としてrsync管理もありではないだろうか。

スケール前提の構成を組む

例えばSNSサービスを作るとして、最初からCDNやリッチなキャッシュサービス(redis or memcache)を使う必要はないとしても、マイクロサービス化できるところはないかを常に意識して構成を考えてほしい。

また、論理的に分割できる単位(ネットワーク/APP/DBなど)は可能な限りVM、コンテナなどで切り出しTCPベースのロードバランサでスケールできる構成にしておく事をオススメする。

サービスがスケールした場合にあなたを助けてくれると同時に顧客にとってもサクサク動くサービスはそれ自体が価値を生むだろう。

(あえて)マネージドサービスを使わない

ここは語弊がある点だが、マネージドサービス(RDS/CloudSQL)などは開発にリソース投下できる点でメリットが大きいが、当たるかわからない段階ではあえて使わない選択もありではないだろうか。

EC2/GCEインスタンスミドルウェアを直接入れて、サービス成長の過程でマネージドサービスに移行すれば自らがconfファイルをいじりながらトラフィックの負荷に応じたチューニングや今後のアーキテクチャの方向性にも目を向ける事ができる。

また、今後AWS/GCP/Azureという選択がより難しくなる中でもプラットフォーマーに依存しないポータルブルなミドルウェア運用スキルというのは今後高まるのではないかと感じている。

まとめ

ここは私自身が場数を踏んでいるわけではないので(無い無い尽くしの状態での結果論)、今後も試行錯誤しながらやっていくんだろうと思う。

本年もよろしくお願いいたします。

 

 

 

 

 

 

 

 

「メールdelay常習犯」の傾向と対策

自営して色々な利害関係者とコミュニケーションするようになると、特に一定規模以上の企業はメール連絡が遅い傾向がみられる。

ひどい担当者はそもそもメールに気づいていない、あるいはこちらから連絡するまで平気で1週間〜2週間返信を放置する人もいる。

ベンチャー企業の時間は有限であり、1営業日あたりの重みを考えながらやるべき事をスケジュールしないと成功はおぼつかない。

上記のような「メールdelay常習犯」に対しての対策を考える。

  • 回答期限を設ける。

「本件、〜までに意志表示をいただけますか」という感じでデッドリミットを設ける。相手は喫緊の課題でなくても回答期限があるのですっぽかしできないという認識をするだろう。稀に、平気で回答期限を忘れている人もいるのでリマインドも効果的だ。

  • 回答項目を箇条書きでリストする

1.〜についての意志 2.〜のスケジュールの設定 といった感じで相手が決定権を持っている事項について箇条書きしメール返信しやすい形にする。

あまりyes,noで答えろ的な文調は失礼になるのであくまで「決定いただけますと幸甚です」といった文調で相手の時間を割いていただいている事に敬意を表したい。

  • メール後に電話する

相手がすっぽかし常習であれば、メール後に電話して念押しするのも原始的だが効果的だ。

その場で回答をもらえるような用件であればメールは言った言わないを回避する意味であえて使い、関係者へのCCのために使うのもありだろう。

 

上記は自分自身が相手のメールにすぐ返す習慣がついているのが前提となる。重要な用件は30分以内に、緊急でない用件でも1営業日以内に返す習慣をつけたい。

私は再度の催促でも連絡が遅れる相手はこちらを必要としない取引先だと思っており、経験上も仕事の品質が低い相手が多いと思っている。3営業日以内にメール返信しない相手とは取引しないくらいの社内ルールがあっても決しておかしいとは思わない。

スタートアップは時には付き合う相手を選ぶ勇気が必要だ。

 

 

 

スタートアップにとっての自社サービスと受託

「IoTはなぜ儲からないのか」という記事で数年ぶりに連絡をしてくれた元同僚がやっているスタートアップに遊びに行った。

彼も自社サービスから受託を経験し、また自社サービスにチャレンジするという。やはり挑戦する起業家は目が輝いているしこちらもエネルギーをお裾分けしてもらった気分に成る。

私も起業して最初に作った自社サービス(農業用IoTサービス)が大コケしてしまい、その後現在に至るIoTクラウドへピボットするきっかけとなるのだが依然、成功とは言えない状況で自社サービスの難しさを日々痛感している。

ここではスタートアップ期(創業5年以内)のベンチャーが自社サービスと受託をどうバランスさせながら乗り越えていくべきかを試行錯誤の身として考えてみたい。

 

ラーメン代稼ぎの重要性

シードマネーが潤沢に準備または調達できている場合を除き、最初の売り上げが立つまでに基本的に資本金を燃やしながら、必要に応じて創業者自身からの役員借入金も加えて事業を運営していく。

この過程で、運転資金としてのキャッシュ稼ぎは重要で当座の入金予測が立ちやすい受託は魅力的である。

一般論としては、受託と自社サービスの両立は「中途半端」で終わると考えている。受託をやっているうちに受託一本になってしまうスタートアップの話を聞くからだ。

創業1年目は自社サービスにフルコミットし、サービスの立ち上がりの状況によっては受託もやるといった感じでまずは自社サービスを優先させた方が後悔も少ないだろうし得るものも多いのではと思う。

 

作るの2割・売るの8割

典型的なエンジニア出身創業者(私自身も含め)の場合、自分のアイデアで自分の技術で作った自社サービスが売れない訳がないと思っている。私の場合は、最初に作った自社サービスが日経新聞にも掲載され展示会でも活況だったのに関わらず大コケしてしまい、メディアの反応と市場の反応は全く比例しないという現実を学ぶ事となった。

農家向け製品だったので九州地方で新聞広告も試してみたりしたが問い合わせのハガキ1枚が来ただけだった。

新聞広告など一定期間継続して効果があるようなものに手を出した時点でスタートアップが取る作戦ではないのはマーケティング経験者であれば判ると思うがそのレベルの判断さえ当時は出来なかった。

相応の金と時間を投じて学んだのは以下:

  • 買ってもらうのは消費者が取る最終行為であって、知ってもらわないとその入り口にも立てない
  • 一過性か、その後につながるかのメディア特性とマーケティング投資を見極める

自社サービスは作ってからが本当のスタートだ。

 

受託というビジネス構造の限界

受託はoutputが決められているので、要件通りの案件をいかに回すかが売り上げの多寡に直結する。

合理的に売り上げを突き詰めようとすれば経営者はいかにエンジニアの頭数を揃え、案件に突っ込んでいくかという人月的な発想をせざるを得ない。

outputとしての対価はキャッシュで得られる代わりに会社に残すべき知的財産は残らず中長期的にみれば先が無い商売というのは明らかだ。

(ここでは受託自体を否定している訳ではなく、受託したノウハウを自社ビジネスに活かせない受託はやるべきで無いという考えだ)

せっかくスタートアップなのだから、リスクを取った分自社サービスに賭けてみてほしい。

 

まとめ

やりたい事を突き詰めるには自社サービスという選択肢は最高だ。

その代わり、作ってからが大変だ!という話でしたw

 

40歳からのスタートアップはありか

私は40歳のおっさんである。

37歳で起業し、一度解散を経験し2度目のチャレンジをさせていただいている。

40歳というと、社会の酸いも甘いも一通り経験し職業人生の折り返しを迎え色々な思いに突き動かされる年齢だろう。自分も不惑どころか日々葛藤の真ん中である。

そんな、腫れものセンチメンタルなアラフォーが40歳から起業するとした場合に直面するであろう事をリストしてみる。

 

体力こそ資本という現実を知る

自社でプロダクトをこしらえて世に問うのだ!という熱い、いや第三者からするとどうでもいい思いを具現化するために1日16時間労働も厭わない覚悟が必要になってくる。

1日24時間という地球上の生命体全てに与えられた物理リソースの限界を超えられない以上、1時間でも多くの生産的作業をしoutputを出さなければならない。 

税金が辛い

アラフォーともなるとサラリーマン時代の所得もそれなりのものになっているだろう。退職後の税金(市民税等)は全てサラリーマン時代の所得をベースに計算されるので前もって備えが必要だ。そして、会社が厚生年金を払ってくれているありがたみを実感するだろう。

サラリーマン時代の人脈は期待するな

会社員時代に誰でも知っている大企業に勤めていた人ほどこの現実に直面するだろう。

名刺にある会社のロゴ、肩書きは全て与えられたものであってそれがなくなった時、単なるおじさんになってしまう。

その代わり、軽薄な付き合いだった人は蜘蛛を散らすように去っていく代わりあなたと仕事したいと言ってくれる人が必ずいるはずだ。そんな人こそ、大切にすべきである。

Give and Takeが基本である

独立すると取引先の社長と交流する機会も増えるだろう。先方の時給を考えた場合、あなたと会ってくれた30分でまず相手になにを提供できるか考えるべきだろう。

常に相手の求めている事を先回りして提供できるネタ作りや準備をしておきたい。

媚びるな

アラフォーで組織を飛び出すのはリスクでもあるが20年社会人をやってきたという事実に自信を持ってほしい。

リスクを負ってまでやりたい事があるのだから、苦手な人に無理くり付き合うだけの時間は無いはずだ。本当に一緒に仕事をしたい人というのは、限られてくるはずだ。

せっかく大海に漕ぎだすのだから自分の意思を持ってやりたい事をやり通そう。

 

日本も副業許可の流れに動いているらしいが、これをチャンスと思うか単なる制度設計の1つと思うかは自由である。