Youtubeチャンネル開設してみた。
コロナ禍で、何か新しいことを始めたいと思いYoutubeチャンネル開設した。
とりあえず10本アップするまでは頑張りたいと思う。。
https://www.youtube.com/channel/UCjKHIE_U7Z0eVPNY2zkqVmg/featured
起業して5年がたった。
第5期の決算が終わったので、起業後5年がたったことになる。
途中、1年9ヶ月の休眠時期（会社員をやっていた）を経て復活しやっとPLベースで黒字化した。
この5年間やってきたことを振り返る余裕などなく、とにかく事業を継続するためにフリーランスの仕事などで会社に資金を入れ続け何とか創業期の累積赤字を払拭することができた。
今期（6期）は、ひとまずやるべきことは明らかなので地に足をつけて堅実に経営していきたい。
起業してよかったのか
結論から言うと、トータルで「よかった」と考えている。
- 時間の使い方を比較的自由にできる
- 会社員時代より会社や上司の方針にストレスを感じることがない
- 自分のやりたいテーマをとことん追求できる
相応の自由を得た分、資金繰りや事業の進捗は常に頭の中から離れることはない。
スモールビジネスは向こう3ヶ月のキャッシュフロー管理だけは徹底し、やるべき事をやった後はコントロールできない現象に関しては諦めるのがストレスコントロールとして良いのではないだろうか。商売はマラソンである。いいことも続かないが悪いことも続かない。
なぜ起業したのか
2014年の2月ごろ、当時の勤務先で早期退職募集がありもともと35歳前後で独立したかったのもあり勢いだけで起業した。
起業にあたりテーマを決める必要があるが、当時M2Mと言われる領域に興味があり学生時代にメカトロニクスに触れていたのとネットワーク、クラウドの経験が活かせる農業M2Mプロダクトのリリースを目標に故郷の新潟に戻った。
起業前にしておけばよかったこと
- 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がコンテナオーケストレーションの主流になることはもはや疑いもなく、クラウドに関わるエンジニアであれば是非とも触ってみてほしい。
ひとりスタートアップのサービス開発
久しぶりのブログ記事である。
新年ということもあり、初心に返る意味で今回はエンジニアひとりでサービス開発する際に意識しておくといいことがあるかもしれないポイントについて書いてみる。
サービスデリバリを重視する
大抵のスタートアップは、クラウドサービスの形態（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年目は自社サービスにフルコミットし、サービスの立ち上がりの状況によっては受託もやるといった感じでまずは自社サービスを優先させた方が後悔も少ないだろうし得るものも多いのではと思う。
作るの２割・売るの８割
典型的なエンジニア出身創業者（私自身も含め）の場合、自分のアイデアで自分の技術で作った自社サービスが売れない訳がないと思っている。私の場合は、最初に作った自社サービスが日経新聞にも掲載され展示会でも活況だったのに関わらず大コケしてしまい、メディアの反応と市場の反応は全く比例しないという現実を学ぶ事となった。
農家向け製品だったので九州地方で新聞広告も試してみたりしたが問い合わせのハガキ1枚が来ただけだった。
新聞広告など一定期間継続して効果があるようなものに手を出した時点でスタートアップが取る作戦ではないのはマーケティング経験者であれば判ると思うがそのレベルの判断さえ当時は出来なかった。
相応の金と時間を投じて学んだのは以下：
- 買ってもらうのは消費者が取る最終行為であって、知ってもらわないとその入り口にも立てない
- 一過性か、その後につながるかのメディア特性とマーケティング投資を見極める
自社サービスは作ってからが本当のスタートだ。
受託というビジネス構造の限界
受託はoutputが決められているので、要件通りの案件をいかに回すかが売り上げの多寡に直結する。
合理的に売り上げを突き詰めようとすれば経営者はいかにエンジニアの頭数を揃え、案件に突っ込んでいくかという人月的な発想をせざるを得ない。
outputとしての対価はキャッシュで得られる代わりに会社に残すべき知的財産は残らず中長期的にみれば先が無い商売というのは明らかだ。
（ここでは受託自体を否定している訳ではなく、受託したノウハウを自社ビジネスに活かせない受託はやるべきで無いという考えだ）
せっかくスタートアップなのだから、リスクを取った分自社サービスに賭けてみてほしい。
まとめ
やりたい事を突き詰めるには自社サービスという選択肢は最高だ。
その代わり、作ってからが大変だ！という話でしたw
