🎉

初のSaaSが12月で１周年なので振り返ってみた

2022/12/05に公開

個人開発

※これは個人開発 Advent Calendar 2022のカレンダー2/5日目の記事です。

個人開発でいろいろ作ってきたけど、
去年の12月にはじめてSaaSをリリースしました。

ちょうど1年経ったので、少し振り返ってみる。
(12月はいろんな記事が出てくるので、少し触発されました(*´ω｀*))

GoogleスプレッドシートのJSON API化サービス
https://sssapi.app/

どんなサービス？

スプレッドシートのJSON APIをつくれるごくごくシンプルなサービス。

スプレッドシートのURLを登録すると、
中身をJSONで受け取れるAPIを作れます。

検索・絞り込み・ページングなどAPIでよくつかう機能や、
ネストオブジェクトへの変換などいくつか変換機能、
外部API呼び出しやGitHub Actionsとの連携機能などなども用意。

どうして作ったの？

β版リリース時の記事でもいろいろ書いたけど、
スプレッドシートをJSON化する方法はいくつか既存のサービスでは少し使いにくいな。。と思うことがあった。

既存のサービスでの課題

ちょっとしたJSON APIを作る方法はいくつかあるけど、
実際のサービスで利用しようとした場合、すこし気になることが。。

GAS
- レスポンスが遅い/同時実行数などの制限がある
- シートごとに準備が必要/どこで使ってるかわからなくなる
- リッチな検索の実装がめんどくさい
ヘッドレスCMS
- 個人・小規模・開発初期では手を出しにくい価格
- 機能がリッチだけど、初期ではなくていいものも多い
スプレッドシートDB関連サービス
- 必要な権限が多い
- プライベートなAPIは作れない

資金が潤沢であればヘッドレスCMSがよい選択だけど、
試作段階で、いきなり手を出すのはなかなか厳しいお値段。。

GASやスプレッドシートDB関連サービスは、
個人利用なサービスや学習用ではよいけど、
実サービスではなかなか厳しい制約。。

もう少しお手軽で実サービスでも利用できるものがほしいと思い、
このサービスを作りはじめることに。

スプレッドシートをDBにするときの懸念

多くの競合サービスは直接スプレッドシートに接続しているけど、
実際にスプレッドシートをDBにすることを考えたときに、
いくつか気になる点が。。

トランザクションがない -> データ壊れる可能性
編集中のリクエストも受け付ける -> 不正なJSONを返すの可能性
Sheets APIが必要 -> 実サービスだとつらい遅さ

作ったサービスが(万が一でも)大ヒットしたときに、
データが壊れたり、意図しないレスポンスになるのは、
かなりつらい。。

そのため、任意のタイミングのスプレッドシートでAPIを更新でき、
読み込み専用のAPIのみとする、いまの方針になりました。

1年やってみてどうだった？

予想以上に利用されてた!!
エンジニア以外の人の利用が多い!!
企業での利用も多い!!

自分と同じような個人開発者をイメージしていたので、
かなりびっくり。。うれしい悲鳴。。(*´ω｀*)
年プランの購入もあり、黒字で運営できてる。ありがたい。。(*´ω｀*)

(CloudFlareの障害のときは気が気じゃなかった。。)

マッチするユーザ

アンケートやインタビュー、利用データを見ていると、こんな感じに(*´ω｀*)

スプレッドシートを介したコラボレーション
- エンジニア以外がデータを操作しやすい
お知らせなどを極小のコンテンツをあとづけしたい
- 単純なものを素早く作れる
スキーマが決まってない開発初期
- データからスキーマが作成できる

特に、スプレッドシートは多くの人が見慣れているので、
データを作る人に管理画面の操作方法を説明しなくてもよく、
共有も共同編集も簡単にできるというのが強みのよう。

また、スキーマをあらかじめ用意しなくてよく、
列を追加すると自由に変更できるのでプロトも素早くできる。

マッチしないユーザ

逆にマッチしないユーザとしては、
スプレッドシートをDBとして使いたいエンジニア。

やはり、書き込みができない、すぐに反映されないのは、
かなりネックなため、刺さらない感じだった。。

とはいえ、DBとして使う懸念があるので、
妙案が出るまで少し難しいことを思っている。。

振り返り(というなの後悔＆反省)

うれしかったことも多かったけど、
「こうしとけばよかった。。」の日々(´・ω・｀)

ユーザとのコミュニケーション

機能の開発はずっとやってきたけど、
マーケティングは考えていなかった。。

リリースしたはいいものの、フィードバックを受けたり、
何かを個別に伝えたりというのが難しい状態に。。

以下のようなものが必要だと感じた。
さらにサイト上とメールなどのサイト外でやり取りできるとよい。

運営 -> 全体
- サイト内: お知らせ・更新履歴のページ
- サイト外: メーリングリスト
運営 <- 個別
- サイド内: フィードバックフォーム
- サイト外: お問い合わせフォーム/メール
運営 -> 個別
- サイト内: (現状なし。例:個別のお知らせ)
- サイト外: メール
運営 <-> 個別
- サイト内: (現状なし。例:チャット)
- サイト外: メール

当たり前のことだけど、機能の開発が優先になってしまっていた。。
機能は最低限でもいいけど、
ユーザとやり取りできる部分はあらかじめ用意できていると良かった。。

統計データの収集

これもマーケティング関連。

リリースして終わりではなく、なにを改善すべきかを把握する必要があるが、
こんなに利用される想定ではなかったので、かなり後回しに。。

最低限でも仕込んでおけば、かなり改善を早く回せた気がする。

特に、Twitterでのコメントと、実際の利用データとはかなりの乖離があるので、
もっとはやく実データを見て判断できる基盤を用意しておけばよかった。。

個人利用の想定

想定ユーザが自分自身であったので、
複数人でがっつり利用されるのを想定しなかった。。

フタを開けてみると、企業での利用や、
エンジニア/非エンジニアとのコラボレーションが多い。

そういった場合、プロジェクトやワークスペースみたいな、
複数人で共同編集できる構成が必要。

そうしておくことで、メンバーを招待したりもできるので、
バイラル効果も期待できる。

特にSaaSの場合はマルチテナントな構成で組んでおけばよかった。。
(新機能として実装中...)

料金プラン設計

個人利用の想定も絡んでいるけど、
アカウント単位のシンプルな3プランだけにしていた。
(しかもかなり手を出しやすい価格...)

この設計の場合、なかなか収益を増やすのが難しい。。
ランニングコストがかかるリッチな機能も開発しにくい。

また、APIがたくさん作りたい人と行数をたくさん増やしたい人がいて、
ニーズにあうプランがないことも多い。

今回のサービスの場合は、ある程度、好きなプランにできるよう、
ユーザがカスタマイズできる構成で組んでおけばよかったと思う。

とはいえ、ユーザが無駄に費用をかけなくていいように、
無料で試せて、小さくはじめて、大きく伸ばせる、
みたいな仕組みにしておくと個人的にはとっつきやすい。

その他もろもろ

書きはじめるときりがないけど、ほかにもいろいろと。。

より積極的なインタビュー/事例収集
大きな更新よりも小さくても定期的な更新＆お知らせ
UIフレームワークは利用を控える/移行つらい
広告は少額だと微妙かも/ある程度の金額なら効果的
記事募集やクーポン配布は効果薄いかも

はやく小さくリリースするのも大事だけど、
こういったサービスの場合には、
マーケティング関連や共同利用の想定ももっと想定しておけばよかった。。

今後は？

まずは後悔している部分の対応と使い勝手を向上していく。

あとはNuxt3がリリースされたので、Buetfyを剥がしつつ、
すこしずつ移行している感じ。

シンプルさを保ちつつ、よりサクッと便利なサービスになるよう、
少しずつでも長く運営できるようがんばります(*´ω｀*)!!

ご興味がある方も無い方も一度はぜひぜひ〜(*´ω｀*)