2〜3年目
他の記事は以下のリンクから
2020年2月〜8月：新規案件の獲得に注力
行動
新規案件を獲得するために、まずはシェアオフィスで知り合った方たちの御用聞きに徹する。
相談されたり会話の中で悩み事を聞き出せたら「私がやります」と即答して、実際のやり方はその後考えていた。
記憶にある限り、実際にやったことの抜粋
・人,スタートアップの紹介
・新規サービスのテストで最低限必要な機能の洗い出し
・他社の開発見積もりで不要な項目ないかチェック
・カスタマージャーニーなどを一緒に作成
・資本政策表,想定キャッシュフローの作成
・VC MTG同席
・営業同行
・ピッチ代行
*全て無料
この間のイベント
3月：初めての受託案件炎上開始
4月：政策金融公庫のコロナ融資制度を活用して5M追加融資
6月：炎上受託案件が鎮火
8月：お手伝いしていた企業から10M弱のシステム受託開発を受注
感想
案件獲得に繋がった結果を踏まえても、最初無料で御用聞きに徹した選択は良かった。
実績がない中で他者から仕事をもらうには、まず信頼を積み重ねる必要があったし、お金を支払ってでも何かやらせてもらう気概でいても良かったレベル。
ただこの間、初めての受託案件が燃えている。
原因は書類不備による[言った言わない]問題。
発注者が知り合い&初めてのクライアントだから[よしなに]で色々注文に対応していたら大変なことになった。
どんなに知った仲でもビジネスであれば抑えるべきところは抑える必要がある。最終的にはシェアオフィスで知り合った方々に助けてもらいながら鎮火させることに成功した。
ただこの時の経験からもスタートアップは徹底的に人的ネットワークの構築,頼れる人の数を増やすことに注力するのが良いと言える。生存確率が格段に高まるし、何かと役立つからだ。
炎上案件の鎮火、新規受注案件双方とも、頼れる人の数を増やしたお陰でどうにかなった。
私の経験を基に[自分が頼れる人になる方法]をまとめたので、無い無い尽くし起業家は是非参考にしてほしい。
まず積極的に様々なイベント,コミュニティに参加
最初は汗かいてスタートアップ界隈の知り合いを作る
*コミュニティ,イベント例：STARTUP HUB TOKYO , STARTUP STUDIO, 01START,
**ピッチはほぼ毎週どこかでやってる少しでも気になったり意気投合した人と連絡先を交換して継続的に連絡を取り合う。
知り合いが増えたら自分から相手の役に立ちそうな人をどんどん紹介する。
[1]〜[3]を繰り返して少しずつ何か依頼してもらえるようになったら秒で対応
基本お金がかからないことに対応した方が良いが、数千円程度であれば持ち出しても良いと思う。
例えばテストプロダクト販売開始連絡が来たら購入してあげたりとか。
クオリティよりもスピード重視
これを繰り返していると「あの人はお願いしたら対応してくれる頼れる人だ。」と認識してもらえるようになる。
最初は自分の利益なんて度外視して徹底的に尽くす。
ちなみにこの一連の流れは起業前からでも出来る。起業を決意したら在職中からやっておくのがbetter。
少しでも人的ネットワークを構築できていたら起業時に大きなアドバンテージとなる。
2020年11月〜2021年2月：受託開発の新規受注ストップ
行動
8月に受注した案件が泥沼化&関係悪化
途中で契約解消も視野に入れたが何とか年明けに終了
コンスタントに売上を立てていた甲斐あって、港区制度活用して10Mの融資獲得
1年程度は何とかなるキャッシュが貯まったので、新規事業への挑戦を再開するために受託開発の新規受注を止めた
感想
受発注者両者が大型案件に慣れていないのに無理して受注するべきではなかった。特に発注者がITに疎いとわかっていたなら尚更慎重にいくべきだった。
開発工期は想定を超え、利益も結局トントンくらい、ただ疲弊しただけになってしまった。
この時に学んだことは以下の通り。私の反省を踏まえて他の無い無い尽くし起業家には上手くやってもらいたい。
大型案件はコミュニケーションコストが小型案件の数倍かかる
協力会社(開発,デザイン,フリーランス含)との調整
発注者との調整
[発注者-自社]の契約と[自社-協力会社]の契約を同じにする
発注者-自社が請負なのに、コストを優先して自社-協力会社間を準委任にするのはNG
当初の期間内で開発を終わらせる義務が自分たちにはあるが、協力会社にはない。
従って生殺与奪の権を協力会社に握られている状況に陥る。協力会社との契約は準委任なので、想定より圧倒的に低クオリティでも追加でお金を支払って修正してもらうしかない。
オフショア開発はBEのみにした方が良い
FEの細かい部分はオフショアだと粗い
ブリッジエンジニアがいても結局は自分たちで細かくチェックする必要あるので時間,費用ともにかかる
他の案件に手が回らなくなる
新規事業開発はほぼストップ。モチベーション維持困難
ちなみに案件毎の金額が大きいので惑わされがちだがシステム新規開発は基本的に薄利多売なので要注意。受託開発は開発後の保守管理で儲けるビジネス
パッと作成した受託開発の損益推移表がこちら。
請負の大型案件の場合、支払は基本的に複数回に分かれるため、途中で支出先行して赤字になる。
ちなみに利益率8%はけっこー高め。もっと利益率が低くなることはザラにある。
*当社の関わった案件の数字とは異なります。サンプル値です。
この時、当社は保守管理契約を他社に譲っている。しかし保守管理をやってくれる他社を探すのも一苦労だったので、契約時に保守管理についても事前に決めておくことを徹底するように注意。
2020年11月：One Minutes構想開始
行動
zoomMTGが増加したことや、自分だけでなく他社も言った言わない問題で揉めているとわかったので議事録効率化ツールの開発に着手
11月中に無料サービスなどを組み合わせて最低限のパイロット版を開発して12月からユーザーテスト開始
感想
One Minutesの開発に伴い、新規の案件獲得をストップした。
今思えばハイリスクだし避けた方が良い。
撤退ライン(キャッシュアウト予想の3ヶ月前までに資金調達)を設けていたが、撤退しても死に物狂いで生き残りに専念する必要があっただろう。
いまからToB事業始めるなら、比較的低リスク,高角度のアイディアを出せる以下の方法でやると思う。
共通の流れはお金を貰って特定の企業の課題解決→他社展開。
【Horizontal 事業タイプ】
業界・業種に関係なく幅広く展開できる事業の創出方法。freee , SmartHR , Sansan などがHorizontal事業に該当。
パターン1
複数業界の複数企業からシステム受託開発受注
受託開発したシステムを他社,他業界に横展開
*受託開発時に他業界への横展開を見越した契約を締結する必要有り
パターン2
複数業界の複数企業から案件受注,情報収集
共通の課題を洗い出す
課題解決ツールを提供
【Vertical 事業タイプ】
特定の業界に絞って深く展開する事業の創出方法。
スマレジ , MEDLEY , ANDPAD などがVertical事業に該当。
特定の業界内で複数企業から案件受注,情報収集
業界特有の課題を学ぶ
課題解決ツールを提供
【自社ペイン解決事業 タイプ】
自社のペインを解決する事業。
自社がターゲットユーザーになるためMVP(Minimum Viable Product)が最も作りやすいかもしれない。
ジョブカン , Slackはこの事業創出タイプ。
案件まわす過程で出てきた自社業務内のペイン洗い出し
システム化出来そうな課題を選択
ツール開発
クライアントへ提案
事業アイディアは自社課題からだが、それを他社に試して少しずつ拡める。複数業界に転用できるならHorizontal事業だし、特定業界のみならVertical事業に分類される。
2021年1月〜8月：ユーザーテスト・フィードバック注力
行動
ユーザーテストに協力してくれる人,企業探しに注力
・起業してから知り合った方々に片っ端から連絡
・ピッチイベント登壇
・PRtimes出稿
感触良さげだった人にはその後も連絡して繰り返しテスト協力してもらっていた。
そしてこの間に共同創業者が辞めることになり、エンジニア探しに奔走
この時も元々構築していた人的ネットワークのお陰でお陰で首の皮一枚つながった。
共同創業者の保有株は創業時に締結した創業株主間契約書に則って、出資時の金額で全て買い取った。
感想
プロダクト改善は延々とできてしまうので、先にフィードバックのアポを取ることをオススメ。
先にアポを取らないと「◯◯の機能実装と××のエラー修正ができたら,,,」みたいになって、開発が延々と続いてフィードバックをもらわなくなってしまう。
そうなると悪い意味でプロダクトに愛着を持ちすぎるので、フィードバックをもらうのが怖くなる。
さらに開発の区切りが見えないのでエンジニアのモチベーション維持が困難で、非開発メンバーもヤキモキするしかないので皆メンタルがヤラれる。
コスト,メンタル両面でフィードバックアポを細かく取って、ユーザーに触ってもらった方が健全。
事業アイディアが固まってから形にしていくまでの流れはざっと以下の通り。
低コスト&高速で「MVP開発→ユーザーテスト&インタビュー→改善」をまわすことがポイント。
【1.初期想定ターゲットの明確化,仮説立て】
アイディアが固まったらターゲットを具体的にイメージできるようにする。
面倒くさそうだし本当に意味あるのか半信半疑で全然気乗りしないのは分かるが、丁寧にやると本当に効果があるのでやって損は無い。
Product Concept Key Questions
共有ファイルの一番下にOne Minutes着想時のサンプル掲載
今振り返ると粗々だけど、とりあえず最初に書きまくって思考を整理することが大事
カスタマージャーニーマップ
テンプレはどれでもOK。作り切る
【2.MVP作成】
ターゲット像,サービスコンセプトがなんとなく固まってきたらMVPを作成
コツはとにかくお金をかけないこと
大抵のアイディアはGoogleの無料ツール組み合わせればなんとか形になる
まだユーザーに触ってもらってもいないのに、このタイミングから詳細設計,開発に時間とお金をかけるのは無駄。
ユーザーがサービスコンセプトを体験できる最低限のプロダクトをサクッと作って、サクッと次のインタビューに進むべき。
【3.インタビュー】
MVPができたら直ぐターゲット像に近しいユーザーへインタビュー
インタビューはできる限り直接会った方が良い思う。
ターゲットユーザーがプロダクトを触ってる姿を後ろから見学しつつ、彼らには思ったことをブツブツ呟いてもらう。そうすると予想外のところで操作に手こずっていたり、意外なところを気にしていたりすることがわかる。
この時のユーザーインタビューで得られる「なんとなくイヤ/好き」的な非言語情報が今後のプロダクト開発にとても役立つ。
ただ、ほぼダメ出しを喰らう。インタビューが怖くなってくるけど、ダメ出しにこそ価値があることを常に意識。ユーザーが答えを持っている。
それに少しでも早くフィードバック→機能改善のサイクルをまわせばその分手戻りが少なくて済むので、コスト的にもこまめにダメ出しをもらった方が良い。
インタビューのコツはこの記事がよくまとまっている。探せばたくさん出てくるのインタビュー前に学んでおく。
【4.ユーザー解像度を上げる】
インタビューを繰り返すと比較的相性の良いユーザーが使用しているツール,業務手順,業界の慣習などがわかってくる。
こうなるとターゲット外のユーザーからダメ出しを喰らっても刺さらないとわかっているからあまり落ち込まなくなる。
例えばOne MinutesだとNotion大好きなスタートアップ,ベンチャー企業はターゲット外。
彼らは様々な便利ツールを使いこなすことが出来るし、それが誰でも出来ると思っていた。
でも元々日系大企業で働いていた経験から、一般企業のサラリーマンたちはそんなことできないと理解していたので彼らを早々にターゲットから外すことができた。
誰かをターゲットから外すと機能の取捨選択をしやすくなるので、プロダクト開発速度,クオリティが上がる。
【フィードバックもらう時の注意事項】
フィードバックする側も気を遣っている
プロダクトのテストに協力してくれる人たちも気を遣っている。なので親切心から安易に「いいかも」と言ってくれがち。
関係性が深ければ深いほどそうなってしまう傾向にある。
なのでフィードバックを貰う前に「辛辣な意見ほどありがたい」と伝えて、実際に辛辣な意見を貰ったら笑顔で「勉強になるなぁ。なるほどねぇ！」的なリアクションをすると、どんどん素のリアクションをくれるようになる。一番"使ってくれている"ユーザーがターゲット
なんとなく一番”良いフィードバックをくれる”ユーザーが自分のターゲットだと思ってしまいがちだけど、それは間違っているかも。
[1.フィードバックする側も気を遣っている]の通り、それが本当の意見ではない可能性がある。
実際にリリースしたら好意的なフィードバックくれた人が全然使ってないと発覚してびっくりなんてことは往々にして発生する。
文句は言うけど使ってくれている人がいたら、その人があなたのターゲット◯◯で出来るじゃんと言われても落ち込まない
そんなこと言ったらほぼ全てのことはGoogleのツールを使いこなせばできる。でもそれで解決できていない課題があるんだからシカト。
zoomだってGoogle meetがあるし、ちょっと前にCM打ちまくってたTime treeだってGoogle calendar使いこなせばいいし、例を挙げ出したらキリがない。
ここで大事なのはユーザーの声に耳を傾けながら、こだわりを持ち続けることだと思う。
この記事が気に入ったらサポートをしてみませんか？