今回はairteamを作った際にやったことを解説していきます。開発だけではなく、法人登記やデザイン、ロゴ、弁護士への法律確認などさまざまなことを解説していきます。
これからwebサービスを作りたい人の参考になる内容です。
会社の辞めるタイミング
元々、僕は元々IT企業に勤めていました。airteamは当時の副業で月1時間でもいいから開発のこと教えてとか、広告のこと教えてと言われたのがきっかけだったりします。会社を辞める前からやれることはあるのでできるだけ辞める前に色々やった方がいいと思っている派です。
まあ、中にはすごい忙しい人ややめて背水の陣にしてやった方がいいという人もいますが、貧すれば鈍するなので余裕ある期間を長めにとった方がいいです。
また、タイミングもあります。市場のタイミングもあるので自分のテンションで起業してしまうとその市場のタイミングをなんとかして生き抜かないといけません。airteamはコロナで副業やリモートワークが盛んになったタイミングで起業してやりました。
それは市場環境のタイミングが来るまでは多少遅くなっても会社員をやりながら準備してそのタイミングが来たら辞めるという計画だったからです。
やりたいタイミングでテンションで勝負をかけるのではなく、やるべきタイミングで勝負をかけるべきでそのためにはできるだけ会社を辞めないで準備してそのタイミングまで待てるようにするというのも一つの戦略です。
情報収集
webサービス運営の情報は意外と落ちていません。正確にいうとあるんですが、すでに成功した大きい会社のものだけだったりしますし、大きくなっている会社の創業時期と少し間があるので参考にならなかったりします。
現在進行形の情報を得るためにはコミュニティに入るなどして同じフェーズの人と交流しないとなかなか手に入りません。
投資などを受けているとスタートアップコミュニティに入れたりすると思うんですが、僕は投資を受けていないのとコミュ障なのでそう言ったコミュニティには入っておらず、個人での知り合いと個人開発者のコミュニティに入っていました。
開発者ギルドというコミュニティがあり、ここは個人でwebサービスを開発している方の集まりになります。エンジニアが多く、自分でwebサービスを作っている人たちですね。ものづくりにおいてはかなりいろんな情報が集まってきます。
経験者にヒアリング
経験者にヒアリングも重要ですが、正直事業内容については経営者やスタートアップ経験者に聞くよりユーザーにヒアリングすべきです。よくある間違えがビジネスモデルの相談をするだと思うのですが、正直そのプロダクトがいいかは対象ユーザーじゃないとよくわからないです。
もちろんビジネスモデルだったり汎用的なノウハウを聞くのはアリですが、最初はそのプロダクトが使われるかが一番肝なのでそこを経営者の先輩に聞いても微妙だったりします。僕も昔そこを聞いてめちゃいいねって言われたけどユーザーに使われなくて悲しいという事がよくありました。
今思うとそりゃそうだよなと思いつつも聞いてしまいがちです。
逆に資金調達やビジネスモデルなどある程度汎用的なノウハウはどんどん聞くべきだと思います。
事業検討
どんな事業にするか、これが一番の肝ですが、検討するにあたって経営者の先輩などに相談するよりもひたすら対象ユーザーにヒアリングしていました。あと、単純にこういうサービスどうですか？と聞いても大抵いいですねってみんな言ってくれるので参考になりません。
広告を使って知り合いじゃない人に簡単なLPを見てもらって申込みしてもらい、提案も兼ねてヒアリングしていました。そこで実際に購入してくれたかどうかのみを信じました。
webサービスの概要
airteamは月1時間からマーケターやエンジニアに相談できるサービスです。
機能的には下記で
- ユーザー登録
- 月額でのプランをユーザーが設定し、販売できる
それを下記の構成で実装しています。
- rails
- heroku
- AWSのs3で画像保存
法人の準備
まず法人設立ですが、そもそも法人を立てる必要があるのかというのがあります。まあ、正直webサービスによっては個人事業主でも問題ないと思います。私の場合、決済を行うのでより信用が欲しいなと思ったので、最初から法人を立てました。
また法人の中でも合同会社や株式会社がありますが、webサービスの売却や株による資金調達を考えているなら最初から株式会社で立てちゃった方が後々面倒じゃないです。大きくなったら変更しようというのも手ですが、変更する場合、利用規約はじめ会社名が入っているところなどを変更、ユーザーへの告知などあるのでかなり面倒です。
法人の登記の仕方
法人登記自体は今は任せっぱなしで大して金額のかからないサービスが多くあるので、ちょっと検索して頼んじゃうのが一番かなと思います。私は依頼してほとんど手間をかけませんでした。
デザイン
デザインはざっくり分けると下記に分かれます。
- 機能要件
- デザインデータ作成
- マークアップ
機能要件、どんな構成にするかから考えてもらうのが理想ではありますが、ここからやるには相当デザイナーに事業を理解してもらわないといけません。しょっぱなから月20-30万ぐらいデザインに使えるならいいかなと思うんですが、合計10万以下とかだとデザイナーさんもちゃんとしたアウトプット出しにくいと思うのでワイヤーはある程度、こちらで引いていい感じのデザインにするところだけお願いするなどがいいかもしれません。
また、デザインにオリジナリティを出す必要がなければbootstrapなどテンプレートを使うのをお勧めします。
僕はマークアップ、デザインともに自分でできるのでfigmaでデザインを起こして、マークアップしました。
ロゴ発注
開発はできるのでマークアップは自分でできるのですが、ロゴなどはデザイナーに依頼した方がいいです。素材はやはり素人では難しいですね。差がすごいでます。また、クラウドソーシングなどでコンペ形式で5万ぐらいから依頼することも可能です。
ロゴは顔になる部分ですし、ここを後から変更するとなるとかなり手間かかるので5-10万ぐらいは少なくともかけた方がいいかなと思います。後で後悔します。
逆に昔、いきなり100万かけてた知り合いがいたんですが、そこまでかけるのはうまくいってからでいい気もします。まあ、ここは経営者のセンスですね。
開発
さて、ついに開発。ここも私は自分でやってしまったのですが、多くの人は発注すると思います。この際に開発会社に依頼するよりも業務委託でエンジニア二人にお願いするのがお勧めです。もちろん二人以内にすまない量だと開発会社さんに依頼しないと無理な場合もありますが、そもそも初期は機能を削ぎ落として最小限で出すべきで今どき二人で2ヶ月以上かかる、つまり4人月以上かかる場合、やりすぎなのではと疑った方がいいです。
どれくらいの期間かかったのか？
airteamは僕一人で2ヶ月ほどかかりました。発注する場合は発注先を探すのにもまあまあ時間かかるのでそこも短縮できてよかったです。
二人に依頼した方がいい理由
先ほど二人に依頼する方がいいと述べましたが、これは理由がありまして一人だとその人への依存度が増してしまうからです。プログラミングというのはブラックボックスになりやすく、一度ブラックボックスになると他の人が開発しにくくなります。しかし、逆にエンジニアからするとそうなった方が自分が優位になるので悪い人だと意図的にそうします。
最初から二人で開発すればオープンにしないと開発を進められないので強制的にブラックボックスになるのを避けれるのです。
技術選定
技術選定ですが、今回はrailsを選択しました。これはジョインしてくれるエンジニアのスキルに大きく依拠すると思うのですが、できれば最初は少人数ですみ、将来的には拡張できる技術選定をした方がいいです。
そう考えた時に僕はSPAは避けました。SPAはシングルページアプリケーションの略で簡単にいうとwebページ上でアプリのようにサクサク動く技術です。こちらの方が体験としてはいいですが、airteamはツールではないのでそこまで恩恵を受けれないと考えました。
もしSPAにした場合、バックエンドをfirebaseとかに投げれるならrailsのみとそこまで変わらないかもですが、バックエンドでも色々処理できた方がなんだかんだ楽な場面も多いので完全にfirebaseに頼り切るのが難しいなと考えました。そうなるとrails（API）+SPA（nuxtなど）になるのでそうなると連携部分が少し面倒なのでrailsオンリーにしました。
技術選定時に採用も考えよう
また技術選定時にはその技術のエンジニアを採用しやすいかも考えた方がいいです。言語やフレームワークには実は人気不人気があります。人気じゃないものを選ぶと採用が非常にやりにくいです。
しかも言語やフレームワークは移行させるのが非常に大変です。正直、ほぼコードを丸々置き換えるみたいになるので一度捨てるぐらいの感覚になります。
webサービスは一度作って終わりではなく、継続的にメンテナンスしないといけないのでその技術を持ったエンジニアを継続的に確保しないといけません。採用しやすいある程度人気のある技術を選ぶようにしましょう。
私はrailsを選びましたが、railsはそこそこエンジニアがいる技術になります。最近は少し人気が落ちてきて、枯れてきてはいますが、railsメインの大規模サービスがいくつかあるので途絶えることはありませんし、枯れてきているので逆に安定しているとも言えます。
ここが難しいところなんですが、最先端で人気の言語はまだ新しいので安定していなかったり、まだドキュメントや記事が充実していなかったりしており、枯れているものの方がドキュメントなど充実していたりします。ただ、枯れすぎると途絶えるのでいいフェーズの技術を選ぶのが重要なのです。
スクラムでの開発
エンジニアも見つかり、開発を始めよう！となったらまずスクラムの勉強をするのをお勧めします。スクラムはアジャイル開発という思想をもとに作られた開発手法で簡単にいうと仕様書やドキュメントを最小限にし、実際に作ったものでコミュニケーションをし、その分、細かい期間に区切って仕様決めやふりかえりをして細かい修正ができるようにする手法になります。
webサービスの開発においては基本はこのスクラムの手法をもとに行った方がいいです。というのもwebサービスは新しいものを作るので作りながら出ないとわからないこと多いからです。
作った後って開発するの？
時々聞かれるのがwebサービスって作った後って放置なんでしょ？なんですが、リリースしてからが勝負ですwというのもバグが出たりはもちろん、やっぱりこの機能こうした方がいいなとか出てきます。なんでtwitterなどの巨大サービスがリリースから何年も経っているのにあんなにエンジニアがいてずっと開発し続けているのか？webサービスはサクラダファミリアのように永久に終わらないのです。
DMをする場合は電気通信事業法の申請を
web上でクローズドなやりとりをユーザー同士がやる場合は電気通信事業の届出をしないといけません。運営とユーザーとのやり取りだと必要ないです。今回はairteam上でユーザー同士のクローズドなやりとりがあったのでこの申請をしました。
この申請自体はサクッと終わりました。自分で出して全然大丈夫だと思います。
法律の確認
意外と初期に抜けがちになるのがビジネスモデルの適法性の調査。今回は決済が絡むので弁護士さんに確認しました。意外なところで落とし穴があったりするので相談した方がいいかなと思います。
また、ビジネスモデル自体には問題なくても必ず利用規約やプライバシーポリシーは作ると思うのでこの辺は弁護士に確認した方がいいです。
利用規約、プライバシーポリシー
利用規約やプライバシーポリシーはほとんどのwebサービスに必要だと思います。
利用規約とは
利用規約とは、事業者が提供するサービスのルールになります。ユーザーに対して同じルールでサービスを提供するためのもので登録時などに提示し、同意を得るのが一般的です。同意を得ると利用者を法的に拘束します。
プライバシポリシーとは
プライバシーポリシーは簡単にいうと個人情報をサービスとしてどう扱っているかを示しているもの。これがちゃんとしていないとユーザーによってはこのサービス大丈夫かなと不安になるので重要です。例えば自分の個人情報をどっかに売っているんじゃないかとか思われちゃうわけです。
また、最近は広告周りにも色々と世論が厳しいのでどう広告に利用しているかなどもメディアだと細かく指摘されたりします。
弁護士への依頼の仕方
利用規約やプライバシーポリシーをもうセットにして受け付けてくれる弁護士事務所さんもあります。また、IT業界に強い弁護士さんもいるのでそういった弁護士さんに頼むといいです。また、弁護士さんに0から作ってもらうと結構な費用かかりますが、自分である程度まとめ、レビューしてもらう形だと多少費用を抑えられます。僕は今回、事業内容とたたき台を作り、レビューしてもらいました。
一度自分で考えることで盛り込みたい条項を自分で洗うことができるので0から依頼する場合でもお勧めです。にたビジネスモデルのwebサービスのを参考にするのもいいです。もちろん丸写しはダメです！
時々、丸写しして、サービス名をそのままにしてしまっている人がいてあちゃーという感じで見ています。間違えると再度ユーザーに訂正した利用規約を同意してもらわないといけないので結構大変です。
ドメイン、サーバー
webサービスならおそらくドメインとサーバーを取得すると思います。ドメインは言ってみれば住所のようなものです。サーバーはコードを置いて置く場所になります。
ドメインとは
ドメインはサイトの住所でwebサイトはIPアドレスというもので住所を割り当てられているんですが、このIPアドレスは数字の羅列で覚えにくいのでドメインという文字列に紐づけています。hogehoge.comみたいな形ですね。
どこで取得してもいいですが、お名前ドットコムは登録するととんでもない量のメールが来ることで有名なので違うところにした方がいいかもしれません。
サーバーとは
サーバーはコードを置いておく場所になります。今回はrailsだったのでrailsが動くサーバーを探したのですが、色々考えherokuにしました。
herokuはwebサービスを運営する上でのインフラを簡単に設定できるサービスです。月々数千円でrailsの設定をかなり手助けしてくれます。将来大きくなった際に割高にはなるのですが、そうなったら移行すればいいので最初はお勧めです。
herokuのようなサービスをpaas（Platform as a Service）といい、最近は自分達でサーバーを色々設定するよりもこう言ったサービスを使う方が多いです。
heroku
https://jp.heroku.com/platform
問い合わせ対応の準備
次が問い合わせ対応の準備です。webサービスをリリースすると問い合わせがきます。例えばバグの報告や提携の提案です。問い合わせフォームを用意したいですが、最初問い合わせフォームやらFAQなどを作るのは億劫ですし、自分で作る必要はありません。
tayoriで十分
tayoriというサービスがおすすめで無料で問い合わせフォームとFAQを作ることができます。
tayori
チャットボットなどで対応したい場合はチャネルトークなどもお勧めです。ただチャットボットだとユーザーがすぐに対応してもらえるものだと思うのでサポートのリソースをそこまで避けない場合問い合わせフォームの方が無難です。
FAQもtayoriで
よくある質問などFAQもtayoriで作成できます。この辺を自社で作るのは大変なので丸投げしちゃいましょう。事前にユーザーに直接営業しているといくつか質問もらえるのでどういう項目を書くべきか参考になります。
PR
よしできたぞ！リリースだ！となったらそのリリースを知ってもらうためにPRを打つ人もいると思います。airteamでもPRを打つためにまず、メディアに問い合わせをしました。でもあまり反応が芳しくなったので切り替えてリリース前にRTしてくれたらテスト利用できますよとtweetして広めました。
これは結構RTしてもらえたのでやってよかったなと思います。
PRもPRTIMESに打つなどしました。PRTIMESにはスタートアッププランがあり、一定期間無料でプレスリリースを打てるのでおすすめです。リリースから結構なんどもうち、打っているうちに少しづつ取り上げてくれるメディアも増えました。