スタートアップのアプリ開発の特徴
初めまして、様々なサービスの企画・開発・運用を行うwacarimi株式会社代表の林翼(@_yokurin)と申します。
もともとフリーランスのSwiftエンジニアとしてアプリの受託開発をメインに活動していましたが、自社サービス開発のために wacarimiを立ち上げました。現在はFirebaseを積極的に使って、サービスの開発に組み込んでいます。
今回はFirebaseの利点と懸念点についてスタートアップの視点でお伝えしたいと思います。
▲リクルート時代。この時期にFirebaseに触り始めた
仕様が不安定でサービス自体の変更もしばしば
企業やそれぞれの事業には、次のようなフェーズがあると思います。
- 0→1 ：事業プランニングや立ち上げを行うフェーズ
- 1→10 ：事業のマネタイズ・仕組み化を進めるフェーズ
- 10→100 ：売上PMF後のサービス拡大フェーズ
0→1の時のスタートアップのプロダクト開発では、とにかくスピード感を持って実装し、実際の数字で検証を行う必要があります。
「ヒアリングでいいじゃん」と思う方もいるかもしれませんが、特にtoCサービスの場合はヒアリングだけでは判断が難しいと感じています。
例えば、プロダクトオーナーがイメージしているものと受け手の認識に差があったり、ヒアリングの際にはその場の空気感で使うと言われたものの、実際にプロダクトを出してみたら全然使われないということが日常的にあります。
そのため、実際にリリース後に検証をした結果、いくつか改善点が浮上し、それによって大きく仕様を変更するケースもあります。
開発するサービスの規模にもよりますが、リリースするのに3〜4ヶ月、そこから改善に1ヶ月かかるとなると、検証スピードが遅くお金も時間も無駄にしてしまいます。これが開発ツールや開発体制で、解決できたら嬉しいですよね。
僕は開発スタックとして、スタートアップの初期フェーズにおいてはサービス内容の変更の可能性を考慮してFirebaseを選択しています。最初からサーバーサイドエンジニアが入らなくても良いので、大幅に開発スピードが上げることができました。感覚としては従来のバックエンド実装にエンジニアを割り当てていた体制と比較して1.5倍以上は早くなっていると思います。
Firebaseよりも高速にプロトタイプが作れるNoCodeも検討した方がよい
僕自身、Firebaseの経験の方が豊富なため、今回はFirebaseにフォーカスしていますが、最近は、NoCodeという言葉もよく耳にするようになりました。NoCodeとは、プログラミングをせずに、Webサイトやアプリを開発することを言い、Firebaseよりも高速にプロトタイプを作ることができます。より早く簡単に検証したい場合は、こちらの方法がオススメです。
ただ、僕が観測している範囲では、NoCodeはサービス開発に使うというより、あくまでプロトタイプに使うというイメージです。つまり、実際の運用時には作り直すということです。
特にサービス初期においては、NoCodeの経験もあると予算が厳しい、リーンに開発を始めたいというクライアントへの提案の幅が広がるのではないかと思います。
高速PDCAのために意識したFirebaseのポイント
Firebaseは、Google が提供しているモバイルおよび Web アプリケーションのバックエンドサービスです。ここ数年でFirebaseは認知度がかなりあがったものの、実際のサービスに取り入れている事例はまだ多くはありません。
僕は以下のポイントを意識して開発をすることで、大幅に開発スピードを上げることができました。
意識したポイント①Firebaseにできるだけ依存し、足りない機能はSaaSを利用する (車輪の再発明はしない)
Firebaseの機能は非常に充実しており、実現できないサービスはないと言っても過言ではありません。特に、サービス初期の検証を行うには十分すぎるくらいです。
認証やFCM（※注1）のためだけにFirebaseを利用する方もいますが、全ての機能を最大限に活用して開発をすると、より高速で作れるようになります。Firestoreはクライアントサイドから直接データを見に行きますが、クエリ処理が備わっていて、APIを作らずともデータの作成や更新、検索などができるため、従来のWebAPIの開発なども不要になるのです。
ただ、全ての機能をFirebaseが補えるわけではないので、全文検索やライブ配信などをしたい時は既存のSaaSを使い、できるだけ実装コストを減らすのがおすすめです。
※注1：FCM：Firebase Cloud Messaging
意識したポイント②フロントエンド、バックエンドの役割の廃止
フロントエンドが1人、バックエンドが2人のように職種で分けて開発を進めることはよくあります。
しかし、このように役割を分けると、コミュニケーションコストがかかることに加え、手が空いた人が他のひとを手伝うということがやりづらく、エンジニア工数を柔軟に使うことができません。
フロントエンド・バックエンドというエンジニアの役割をなくし、機能ごとに担当者を割振ることで開発スピードが格段に上がります。
意識したポイント③セキュリティ
FirestoreとCloud Storageはクライアントから直接アクセスするため、セキュリティ対策を十分にしないと、第3者のデータへのアクセスが可能になってしまいます。
特にProjectIDなどは簡単に見ることができるので、データ設計による対策や、セキュリティルールを明確に記載することが大切です。
セキュリティルールによって、データベース内のドキュメントおよびコレクションへのアクセスを細かく制御できるので、下記のように細かく設定します。
- データ閲覧可能な条件の指定
- フィールドごとの文字数制限
- データ更新の条件
- 書き込みに権限設定の追加
詳しくはこちらを参照ください。
https://firebase.google.com/docs/firestore/security/rules-conditions?hl=ja
データ設計によるセキュリティ対策としては、セキュアな情報を入れるためのコレクションを用意して、書き込み権限をadminと本人のみに限定する、などがあります。
開発を進める上で詰まったポイント
ポイント①エンジニア採用が難しい
Firebaseに触れたことある人は増えつつありますが、まだまだ実務経験者が多いとは言えません。そのため、採用時の難易度は比較的高くなってしまいます。
実際にエンジニアを探す際は、SNSや技術共有サイトで Firebaseについて積極的に発信している人に声をかける方が採用自体は早いかもしれませんね。
フリーランスの立場からすると、普段からFirebaseについて発信しアピールすると効果的だと思います。
ポイント②データベース設計が有識者じゃないと難しい
FirestoreはNoSQLなので、RDBを触ってきた人にとっては少し癖があるように感じるかもしれません。基本的にはクライアントサイドJOINなので、正規化しないほうが設計上良くなることも多いです。
癖がある分、最初の設計はFirestoreの経験値がある程度高いエンジニアが担当をしないと、不都合が出てくる恐れがあります。
さらに、データ構造を変えようにも、一般的なWebフレームワークにあるようなマイグレーション機能はありません。そのため、手動でマイグレーションスクリプトを書くことになり、初めての人には少々ハードルが高いかもしれません。
ポイント③バックエンド移行コストが上がる
サービスがグロースした際に、Firebaseの機能だけでは補えなくなるケースがあります。その場合はバックエンドを一新すると思いますが、フロント側もFirebaseへの依存度が高いため、移行時のコストは必然的に上がってしまいます。
ここは初期の開発スピードとのトレードオフなので、どうしようもありません。しかし、資金面や技術負債の観点から見ると、後々サービスが伸びた段階で作り替えるというのは良いタイミングではないでしょうか。
▲現在のwacarimiのオフィス
Firebaseを使えるフリーランスは希少性が高い
サービス初期にFirebaseを使うことはとても有効的だと考えています。
また、Firebaseを採用するスタートアップも徐々に増えており、フロントエンドからバックエンドまで一気通貫してサービスを作れるという方はとても貴重な人材になると思います。
今まで3人月のエンジニアの工数で発注していたのを、2人月分の単価で発注するということも十分にあるでしょう。企業は開発費を抑えることができ、受注側は通常より高い報酬をもらうことができるので、win-winになりますよね。
これからはより一層こういった早く効率よく立ち上げに参画できる人材が求められるようになります。
Firebaseの実務経験を早く積むことが、アプリエンジニアとしての市場価値を高める近道だと思います。