私はエンジニアとして、技術スタックをまとめた記事を読むのに非常にワクワクします。しかしながら、このような記事が紹介している技術スタックは成熟したサービスのものに限られており、立ち上がり初期のSaaSに関する記事はほぼ見かけません。そのため、現在の[Flip](https://www.flip.inc)の技術スタックの選定に役立つ情報をなかなか見つけられず、多くの失敗を繰り返してきました。

ということで、今回のブログではFlipがこれまでに採用した技術スタックを紹介します。SaaSの開発を始めたばかりの方や、SaaSを新しく開発する予定のある方の参考になれば嬉しいです。

## 言語

- [***TypeScript***](https://www.typescriptlang.org/). 開発当初はJavaScriptで統一していましたが、サービスの規模が大きくなるにつれて、昔書いたコードを見返した時に「このコードは何をしているのか」と忘れることが多くなりました。TypeScriptを採用したことで変数や引数の型が可視化され、コードの可読性が大幅に向上しました。共通の型をフロントエンドとバックエンドの両方で利用することで、データモデルを変更した際のコード修正もしやすくなりました。

## フレームワーク/ライブラリ

フレームワーク/ライブラリを選択するときに重視していることは二つあります。

1. ***開発者コミュニティ***. 技術のシェアが高ければ高いほど利用者側の開発者も多いので、何か行き詰まった時のサポート(ドキュメント/StackOverflow/ブログなど)が充実しています。ニッチなライブラリに関しては、直近のコミット数や未解決のイシュー数を調べることで、今後致命的なバグが生じた場合の作成者側の対応の早さを調べています。
2. ***少ない技術で多くを達成***. 頭の切り替えコストを抑えるために、利用するフレームワークの数はできるだけ少なくしています。一方でライブラリに関しては、コードレベルで自分好みに抽象化できるので、良いライブラリがあれば積極的に採用しています。

### 全体

- [***Lerna***](https://github.com/lerna/lerna). フロントエンドやバックエンドのような複数のパッケージを一つのレポジトリで管理する(=モノレポ)ためのツールです。全てのパッケージのスクリプトを同じ階層から実行できるのはとても便利な上、ローカルのNPMパッケージ的なモノも簡単に作れます。

### フロント系

- [***React***](https://reactjs.org/). 一番人気のフロントエンドフレームワークです。Reactを知る前と知った後では、作れるアプリケーションの幅が劇的に広がりました。自由度が高い一方で、Reduxなどを用いたステート管理は非常に複雑であり、システム的な思考が求められます。
- [***Styled Components***](https://styled-components.com/). JavaScriptファイルに直接CSSを書き込めるライブラリです。JavaScriptファイルとCSSファイルを行き来する必要がなくなります。Reactのようにコンポーネント単位でスタイルを再利用することも可能です。
- [***NextJS***](https://nextjs.org/). Reactをベースにしたフロントエンドフレームワークです。[Flipのランディングページ](https://www.flip.inc)で採用しています。アプリのビルド時に静的なHTMLファイルを作ってくれるため、高速なサイトとSEO最適化の二つを達成できることが個人的なオススメポイントです。

### バックエンド系

- [***Express***](https://expressjs.com). APIサーバーを簡単に構築できるフレームワークです。[Nest](https://nestjs.com/)も検討しましたが、JavaScript以外の言語に触れたことがない方にとっては、学習コストが高いと感じました。

## 利用中の外部サービス

### インフラ

- [***Docker***](https://www.docker.com/). Dockerコンテナを作成することで、Dockerをサポートする全ての環境で同じようにアプリケーションを動かすことができます。チーム開発に役立つことはもちろん、ほとんどのクラウドサービスがDockerコンテナによるホスティングをサポートしています。
- [***Amazon ECS***](https://aws.amazon.com/ecs/). AWS上で簡単にDockerコンテナを利用できるフルマネージド型のサービスです。[Heroku](https://www.heroku.com/)や[Render](https://render.com/)などのPaaSと比較すると覚えることが多いですが、一度セットアップさえしてしまえば、運用は簡単に行えます。
- [***Terraform***](https://www.terraform.io/). インフラをコードで管理できるツールです。AWSはもちろん、出来るだけ多くのリソースをTerraformで管理するように心がけています。コマンド一つでリソースの作成や削除ができるので、インフラコストをかけることなく、テスト環境を立ち上げられます。その他のリソースも一元管理することで、無駄なリソースが増殖することを防げます。

### CI/CD

- [***Github Actions***](https://github.co.jp/features/actions). GitHubが提供するCI/CD(継続的インテグレーション/継続的デリバリー)のサービスです。最初は[Travis](https://www.travis-ci.com/)を利用していましたが、ソースコードにアクセス可能なサービスを減らしたかったことに加え、GitHub上でCIの状況を簡単に確認したかったことから乗り換えました。

### モニタリング

- [***Sentry***](https://sentry.io/welcome/). サービスで発生したエラーログを収集してくれるサービスです。エラーが発生した背景を詳細に把握できます。現在はウェブアプリとバックエンドのエラーログを収集しています。
- [***DataDog***](https://www.datadoghq.com/). 多機能なモニタリングツールです。主に、インフラのリソース監視とログの管理をしています。グローバルのモニタリング市場でのマーケットリーダーであることから採用しました。[スタートアップ向けのプログラム](https://www.datadoghq.com/partner/datadog-for-startups/)に登録すれば、無料で使えます。

### メール

- [***SendGrid***](https://sendgrid.com/). APIベースのメール配信サービスです。新規登録時の認証メールやパスワードの再設定メールなど、全てのメールの配信基盤として利用しています。[Mailchimp](https://mailchimp.com/)も検討しましたが、SendGridと比較してドキュメンテーションが読みづらく、APIの機能も限られていました。管理画面上でメールのデザインも行えますが、非常に使いづらいので、[React Email](https://react.email/)を採用しています。

### 分析

- [***Flip***](https://www.flip.inc). プロダクト内のユーザーの行動を定量的に可視化するツールです。Google Analyticsのようなアクセス解析ツールと似ていますが、より解像度の高い分析が直感的に行える上、AIに質問するだけで何でも可視化してくれます。弊社が提供しているツールです。

### 決済

- [***Stripe***](https://stripe.com). APIベースの決済サービスです。サブスクリプション決済のバックエンドに用いています。Stripe以外のサービスには、税関係の計算などもまとめて管理してくれる[Paddle](https://paddle.com/)や、BASEから分社化した[PAY.JP](https://pay.jp/)なども存在しますが、Stripeの認知度と「世界一読みやすいドキュメンテーション」と呼ばれるサービスを超えるサービスは存在しませんでした。

### サポート

- [***Zendesk***](https://www.zendesk.co.jp/). 電話/メール/SNSからの問い合わせを一元管理できるサービスです。ウェブアプリのウィジェット(右下の丸いボタン)からの問い合わせを管理しています。[非公式のライブラリ](https://github.com/B3nnyL/react-zendesk)を使うことでウィジェットの表示方法をカスタマイズできます。[Drift](https://www.drift.com/)は表示方法のカスタマイズ性が低く、[Intercom](https://www.intercom.com/)は料金が高いです。
- [***Airtable***](https://airtable.com/). ノーコードのデータベースツールです。主にランディングページからの問い合わせを管理しています。APIでAirtable側に問い合わせを送ると、問い合わせがデータベースに追加され、Slackに自動で通知が飛ぶように設定しています。[Notion](https://www.notion.so/product)も検討しましたが、[ブラウザ環境からAPIを直接叩けない](https://github.com/makenotion/notion-sdk-js/issues/96)ため、断念しました。

### デザイン

- [***Figma***](https://www.figma.com). 無料から使えるデザインツールです。アプリケーションやランディングページのデザインを管理しています。Figma以外のツールは検討したことはありませんが、これまで一度も困ったことはありません。

### ドキュメント

- [***Notion***](https://www.notion.so/). 社内のドキュメント&タスク管理ツールです。ファイル形式ではなくページ形式で管理できるのが一番のオススメポイントです。興味本位で[ClickUp](https://clickup.com/)や[Coda](https://coda.io)も利用してみましたが、全てをブロックという単位で管理できるNotionの方が使いやすいです。すぐに必要な情報にアクセスできることから、タスク管理も[Trello](https://trello.com/)からNotionに乗り換えました。
- [***Contentful***](https://www.contentful.com/). APIベースのコンテンツ管理サービスです。[Flipのブログ記事](https://www.flip.inc/blog)を管理しています。Headless CMSとも呼ばれており、ブログのUIを自由にカスタマイズできるのが特徴です。最低限のコーディングスキルがあり、サイトのデザインを統一したい場合はオススメです。しかし、Notionでブログの原稿を書いていることもあり、毎回NotionからContentfulに原稿を移すのは面倒なので、NotionをCMSとして採用する予定です。

## 最後に

以上が、Flipの技術スタックの紹介となります。サービスとしてはまだまだ駆け出しのため、これから新しく追加したり変更したりすることは頻繁に起きると思います。このブログに関する質問などありましたら、[ツイッター](https://twitter.com/iiKeisuke)でお気軽に連絡して下さい。

また、現在は2名のメンバーでこの技術スタックを支えられている(いない)状況です。全職種で採用していますので、力を貸していただける方をお待ちしています！[こちらのページ](https://www.flip.inc/company)から、ぜひお話しましょう！

シード期のスタートアップの技術スタックを公開します。SaaSの開発を始めたばかりの方やSaaSを新しく開発する予定のある方には、ぜひ読んで欲しい記事です。

one-man-saas

シード期のSaaS開発を支える技術スタック

シード期のスタートアップは大抵が失敗します。Y Combinatorを卒業したスタートアップでさえ、シリーズAの資金調達ができるのは[全体の45%](https://www.linkedin.com/posts/garrytan_45-of-yc-companies-get-to-series-a-and-median-activity-7099481078825959424-QL6P/?trk=public_profile_post_view)に過ぎません。そして、シード期のスタートアップが失敗する理由は様々です。共同創業者と別れた、従業員を雇い過ぎて資金が尽きた、プロダクトが作れなかったなど、色々あると思います。

その中でも今回は、シード期のエンジニアCEOとしての私自身の失敗談を共有したいと思います。日本においてエンジニアが起業するケースはまだまだ少ないですが、数少ない事例の1つとして参考になれば嬉しいです。

## リリースから1ヶ月でクローズ
今回の失敗談の主役となるツールは、Ekakiという会議の文字起こしツールです。ざっくりとした使い方は、デスクトップアプリがウェブ会議の音声の録音と文字起こしを行い、ユーザーは会議後にツール上でそれらを確認できます。

![文字起こしツール「Ekaki」](//images.ctfassets.net/y8i9aadd4hm0/1Q6Z59TQTZtJU6tJADOj5S/41f792c8a8d009124f8665f1d3500424/ekaki_.png)

1年以上の歳月をかけて開発し、2022年1月にβ版をリリースしました。Skyland Venturesの木下さんにPRを後押しいただいたこともあり、1ヶ月で80社ほどの事前登録がありました。この数字を見ると「悪くはないのでは？」と思う方もいるかもしれませんが、95%以上の事前登録は想定ターゲットからではなく、純粋にEkakiのUI/UXを見たいという方からでした。

しかし想定ターゲットからの事前登録数が少ないことは、もう一つの巨大な問題と比べれば些細な問題に過ぎませんでした。その巨大な問題とは、Ekakiが絶望的な問題を解決できていなかったということです。そしてリリースから1ヶ月もしない内に、Ekakiをクローズすることを決断しました。

## 絶望的な問題を解決していない
絶望的な問題を解決できていないことに気づいたのは、ALL STAR SAAS FUNDの佐伯さんとのミーティングがきっかけでした。私のEkakiについてのピッチが終わり、佐伯さんから「どのような絶望的な問題をこのツールは解決しているのか？」と質問された時、初めて「答えられない、やばい…」と、自らに絶望しました。そしてその後に、人生で初めてのユーザーインタビューを行い、最終的にピボットしなければならないという確信へと変わりました。

> どのような絶望的な問題をこのツールは解決しているのか？

ユーザーインタビュー中に「絶望的な問題を解決していないな」と感じる瞬間は多々ありましたが、その中でも特に次の2つはこのことを示している重要な証拠だと思います。

- *__既存の解決策よりも10倍優れていない__*. 文字起こしのコストが高い上、フォーマット通りの議事録を作成するのは難しいです（当時はWhisperもChatGPTもまだ存在していません）。ツールの費用と自動作成された議事録を修正する作業が発生すると考えると、録音を聞き返して人力で議事録を書くという既存の方法よりもEkakiの方が非常に優れているということはありませんでした。
- *__熱狂的なファンがいない__*. 議事録業務を日常的に行う潜在的なユーザーにEkakiを紹介した時に、Ekakiが存在しない世界では議事録業務が出来ないというくらい、熱狂的なファンは現れませんでした。新しいツールがユーザーに強く求められないのは、一点目が理由として大きいと思います。

絶望的な問題を解決していないという失敗自体は、CEOが誰であろうが陥る可能性のある失敗の一つだと思います。しかし、1年以上の開発期間の中で、失敗を事前に防げる機会は十分にあったのに出来なかったのは、過度なエンジニアドリブンな文化が原因でした。

## プロダクトマネジメントの崩壊
プロダクトの企画当初は、[MVP（Minimum Viable Product）](https://www.ycombinator.com/library/Io-how-to-build-an-mvp)の定義を文書化していました。しかし実際に開発が始まると、徐々に開発の規律が失われ、ユーザーではなくエンジニアの自己満足のために開発するように変化していきました。今振り返ると、色々散々なことをしていたなと思います。

### ユーザー中心ではなく、思い付きで新機能を追加する
[ProductHunt](https://www.producthunt.com/)で見た競合ツールの機能をその場で実装したり、技術に惹かれて興味本位でデスクトップアプリケーションを作成してみたり、個人的に好きなツールと連携したりもしていました。

どの機能も技術的にはそこまで難しくなく、頑張れば一人で開発できてしまうという点が、開発の意思決定をチェックする基準を下げていたのだと思います。もちろん、規律が崩壊した中で追加された機能は、本来のMVPでは予定されていない機能なので、プロダクトの本質的な価値とも関係はありません。

### ツールの本質ではない、デザインに必要以上に時間を割く
Figmaでピクセル単位の修正を繰り返したり、大規模なデザインの改修を何回もしたり、独自のデザインシステムを作るノリで各コンポーネントのUIを調整したりもしていました。

当時は「NotionがUI/UXを極めて成功しているから、自分達もUI/UXを極めるべき」という考えでしたが、そのデザインの修正は本当にユーザーに価値があるのかは、深く考えるべきでした。特にEkakiの場合は、デザインを極めるよりも、文字起こしの価格と精度を極めた方が、ツールとしてのUXは圧倒的に良くなったはずです。

## ピボットするには共同創業者が必要
開発する中で「これは誰のために作ってるんだっけ」という議論は度々起こりました。しかし、開発の手を止めるスイッチングコストは大きいので、深い議論を避けて開発を続けていました。

プロダクトマネジメントが崩壊した原因は、私自身の未熟さも大きいですが、共同創業者がいなかった点も大きいです。共同創業者がいないということは、CEOの次にモチベーションに溢れる人が社内にいないということです。

![Y Combinatorの2022年夏のバッチに参加した企業の創業者の数](//images.ctfassets.net/y8i9aadd4hm0/1sNhdhTN9PL2B4AB222ZHQ/5e34f084deb7a3346def5ac9140d577b/__________2023-09-26_15.15.48.png)

特にシード期の場合、どれだけ初期の事業アイデアを固めたところで、競争環境の変化や新技術の登場などによって、ピボットを迫られる瞬間があります。創業者が一人の場合は、従業員がゼロの状態からやり直す必要があるかもしれませんし、その選択肢を考えるだけで頭が痛くなるくらい気が遠くなります。そういう時に共同創業者が居てくれたら、やり直しにかかる時間も短くなると思いますし、自分達なら出来るという自信も与えてくれます。もちろん、共同創業者と上手くやれていて、株式も十分に分配されていることが前提ではありますが。

## 決して悪いことだけではない
Ekakiの失敗を経て、得たものも多くあります。開発という打席に多く立てたことで、私自身の技術やエンジニアリングの理解が深まったこと。技術ドリブンではなくユーザードリブンに開発を進めること。Ekakiの開発力を評価してくれた、Skyland Venturesの木下さんから投資いただいたこと。そして、次のプロジェクトを共にする共同創業者に出会えたことです。

## 今は何をしているのか
現在は「UXの新たなスタンダードを創る」というミッションの元、[Flipというプロダクトの分析をAIを用いて自動化するツール](https://www.flip.inc)を開発しています。AIに質問するだけで、5秒で分析からデータの可視化までしてくれます。基本的な集計からファネル分析やリテンション分析のような高度な分析まで、幅広いプロダクト分析を自動化します。無料から試せるので、ぜひこの機会に試してみてください！

![プロダクト分析ツール「Flip」](//images.ctfassets.net/y8i9aadd4hm0/7DSK7KgTUDqXx0N31Aq4VV/ef122d11336acd1347ddb28eec7e5031/flip_.png)

また、現在は2名のメンバーしかいないため、常に人手が足りていない状況です。全職種で採用していますので、ぜひ力を貸していただける方をお待ちしています！[こちらのページ](https://www.flip.inc/company)から、カジュアルにお話しましょう！

シード期のエンジニアCEOとしての私自身の失敗談を共有します。エンジニアが起業するケースはまだまだ少ないですが、数少ない事例の1つとして参考になれば嬉しいです。

シード期のSaaS開発を支える技術スタック

シード期のエンジニアCEOが事業を失敗して得た教訓