技術スタックをまとめた記事をたまに見かけますが、気になるサービスの裏側を知れるのは「隣のクラスの気になるあの子」のFacebookを初めて覗くようなドキドキ感があります(笑)

しかし残念ながら、このようなブログが紹介している技術スタックは**成熟したサービスのもの**に限られており、**立ち上がったばかりのSaaS**に関するブログ記事はほぼ見かけません。そのため、現在の[Ekaki](https://ekaki.ai)の技術スタックの選定に役立つ情報をなかなか見つけられず、多くの失敗を繰り返してきました。

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

ちなみに、私達の創業ストーリーに関しては[別のブログ記事](https://ekaki.ai/blog/hello-world)で紹介しているので、ぜひご覧下さい！

## 背景

以下が、今回の技術スタックの選定に大きく影響している重要なバックグラウンドになります。

- ***開発経験***. 大学2年の秋からコンピューターサイエンスを独学し、その過程でプログラミングに触れている。そして今回の開発が初めての開発経験であり、ゼロから学びながら進めてきた。Ekaki以外の組織での開発経験がないため、成長中/成熟したサービスに関する知見は少ない。
- ***カバレッジ***. 共同創業者の前澤が参画するまでは、開発に関することを全て一人で担当していた。Ekakiの開発においては、特にフロントエンドに多くの時間を費やしている。
- ***深層学習の研究***. 2021年の「未踏アドバンスト」に応募しており、2021年1月から2021年3月の期間はアプリケーション開発から身を引き、深層学習ベースの音声認識の研究を行っていた。「未踏アドバンスト」は二次面接でアウト。
- ***主な情報源***. 技術スタックの選定における情報源の多くは英語のサイト。そのため、利用しているサービスの中には日本語対応の弱いものも含まれている。

## 言語

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

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

MERN(MongoDB, Express, React, Nginx)スタックを採用しています。当時はUdemyのMERNスタックのコースを受講しながら開発を始めたため、それ以外の選択肢が存在しなかったのが本音です。エンジニア脳になると全てを自前で開発したくなりますが、プロダクトのコア部分に多くの時間を割くためにも、できる限りオープンソースに頼ることにしています。

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

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

### 全体

- [***Lerna***](https://github.com/lerna/lerna). フロントエンドやバックエンドのような複数のパッケージを一つのレポジトリで管理する(=モノレポ)ためのツール。全てのパッケージのスクリプトを同じ階層から実行できるのはとても便利。ローカルのNPMパッケージ的なものも簡単に作れる。
- [***I18next***](https://www.i18next.com/). Ekakiは現在日本語のみの対応だが、近い将来には複数言語に対応させる予定のため、現時点から多言語化(i18n: Internationalizationの略)を意識している。少しでも多言語化の可能性があるのであれば、開発の初期段階から入れた方が良いツール。

### フロント系

- [***React***](https://reactjs.org/). 一番人気のフロントエンドフレームワーク。Reactを知る前と知った後では、作れるアプリケーションの幅が劇的に広がった。自由度が高い一方で、Reduxなどを用いたステート管理は非常に複雑であり、システム的な思考スキルが求められる。
- [***Electron***](https://www.electronjs.org/). デスクトップアプリを作成するためのフレームワーク。デスクトップアプリは配布までのフローを自分で設計しなくてはいけない上、実際に配布可能な形にしないと確認できない機能(eg. 自動アップデート機能)が多く存在する。開発リソースが十分な場合を除き、絶対必要でない限りは開発すべきではない。
- [***Styled Components***](https://styled-components.com/). JavaScriptファイルに直接CSSを書き込めるライブラリ。JavaScriptファイルとCSSファイルを行き来する必要がなくなる。Reactのようにコンポーネント単位でスタイルを再利用することも可能。
- [***NextJS***](https://nextjs.org/). Reactをベースにしたフロントエンドフレームワーク。Ekakiのランディングページで利用している。アプリのビルド時に静的なHTMLファイルを作ってくれるため、高速なサイトとSEO最適化の二つを達成できることが個人的なオススメポイント。
- [***Tailwind CSS***](https://tailwindcss.com/). HTMLのClass上から要素のスタイリングができるフレームワーク。Ekakiのランディングページで利用している技術。レスポンシブなサイトを高速で作れることに加え、[Bootstrap](https://getbootstrap.jp/)などと比べてUIのカスタマイズ性も高い。

### バックエンド系

- [***Express***](https://expressjs.com). APIサーバーを簡単に構築できるフレームワーク。他のフレームワークを検討したことはないが、今のところ特に困ったこともない。
- [***Socket.io***](https://socket.io/). WebSocketサーバーを簡単に構築できるライブラリ。クライアントからのイベントを受信しつつ、任意のタイミングでサーバー側からクライアントにイベントを送信できる。ソケットの管理・ステートの管理・コンフリクトの対処などは非常に難しいため、本番環境で利用できるようになるまでは時間がかかる。
- [***Mongoose***](https://mongoosejs.com/). スキーマレスであるMongoDBにスキーマ的な要素を加えたライブラリ。スキーマを定義することで、スキーマに沿わないドキュメントの作成などを事前に阻止してくれる。TypeScriptとの相性が悪いのがデメリット。

### 深層学習系

前述した2021年の「未踏アドバンスト」では、**オンデバイスのE2Eの音声認識モデル**の開発を予定していました。現在は深層学習系の開発は行っていません。

- [***PyTorch***](https://pytorch.org/)/[***Tensorflow***](https://www.tensorflow.org/). 元々は[Emformer](https://arxiv.org/pdf/2010.10759.pdf)というモデルを論文実装した上で改良していたが、GitHub上に挙げられているその他の音声認識モデルも勉強目的で実装していた。最初はPyTorchを利用していたが、オンデバイスに最適化するためにも、TFLiteという形式へ変換可能なTensorFlowに途中から変更した。

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

### インフラ

- [***Docker***](https://www.docker.com/). Dockerコンテナを作成することで、Dockerをサポートする全ての環境で同じようにアプリケーションを動かすことができる。チーム開発に役立つことはもちろん、ほとんどのクラウドサービスがDockerコンテナによるホスティングをサポートしている。
- [***Amazon ECS***](https://aws.amazon.com/ecs/). AWS上で簡単にDockerコンテナを利用できるフルマネージド型のサービス。データベース以外のEkakiの全サービスはECS上で稼働している。
- [***AWS Copilot***](https://aws.github.io/copilot-cli/). Amazon ECS上にアプリケーションを簡単にデプロイできる、[公式からのお墨付き](https://github.com/aws/amazon-ecs-cli/issues/1129#issuecomment-814507410)のCLIツール。[Docker Compose](https://docs.docker.com/cloud/ecs-integration/)や[ECS CLI](https://github.com/aws/amazon-ecs-cli)なども検討したが、デプロイまでの工程数の少なさと複雑なアプリケーションにも対応可能な点が特徴。クラウド周りの経験が浅くても使いやすい。
- [***Mongo Atlas***](https://www.mongodb.com/atlas/database). MongoDB社が提供するクラウド型のデータベースサービス。データのバックアップ設定やMongoDBが得意とするスケーリングを簡単に行うことができる。

### CI/CD

- [***Github Actions***](https://github.co.jp/features/actions). GitHubが提供するCI/CD(継続的インテグレーション/継続的デリバリー)のサービス。最初は[Travis](https://www.travis-ci.com/)を利用していたが、ソースコードにアクセス可能なサービスを減らしたかったことに加え、GitHub上でCIの状況を簡単に確認したかったことから乗り換えた。
- [***CodeCov***](https://about.codecov.io/). プログラムのソースコードがテストされた割合(=カバレッジ)を可視化してくれるサービス。GitHubのREADMEにバッチを載せていること以外の用途はない。本来は入れなくても良いサービス。

### モニタリング

- [***Sentry***](https://sentry.io/welcome/). フロントエンドで発生したエラーログを収集してくれるサービス。現在はウェブアプリ・デスクトップアプリ・ランディングページのエラーログを収集している。
- [***Uptime Robot***](https://uptimerobot.com/). ウェブサイトの死活監視サービス。指定したウェブサイトが落ちていないかを定期的にチェックしてくれる。現在はウェブアプリとランディングページを監視している。

### メール

- [***SendGrid***](https://sendgrid.com/). APIベースのメール配信サービス。新規登録時の認証メールやパスワードの再設定メールの送信などに用いている。[Mailchimp](https://mailchimp.com/)も検討したが、SendGridと比較してドキュメンテーションが読みづらく、APIの機能も限られていた。

### 分析

- [***Google Analytics***](https://analytics.google.com/analytics/web/). ユーザーの行動をページビュー毎に解析するツール。「何人がサイトに訪れたのか」「どのページをどれくらい閲覧したのか」などを確認できる。現在はランディングページの訪問者数を調べるためだけに使っている。
- [***Mixpanel***](https://mixpanel.com). ユーザーの行動をイベント毎に解析するAPIベースのツール。ボタンクリックのような細かなイベントを収集できるため、プロダクトを詳細に解析したい場合に役立つ。[Y Combinatorの講義](https://www.youtube.com/watch?v=C27RVio2rOs&t=1680s)でもオススメされている。ドキュメントを読むことに慣れていないと、[公式ライブラリ](https://github.com/mixpanel/mixpanel-js)の使い方に苦戦するかもしれない。

### 決済

- [***Stripe***](https://stripe.com). APIベースの決済サービス。Ekakiのサブスクリプション決済のバックエンドに用いている。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/)はチケット管理機能が弱かった。
- [***Typeform***](https://www.typeform.com/). 一問一答型のフォームを作成できるツール。主にランディングページからの問い合わせを管理している。以前はフォームを自作し、送信リクエストを[Formrun](https://form.run/home)に投げていたが、多言語化やモバイルに対応したフォームを作成するのが面倒だった。TypeformのUI/UXは非常に洗練されており、[公式のライブラリ](https://github.com/Typeform/embed)を使うことで表示方法もカスタマイズできる。

### デザイン

- [***Figma***](https://www.figma.com). 無料から使えるデザインツール。アプリケーションやランディングページのデザインを管理している。Figma以外のツールは検討したことがないが、これまで一度も困ったことはない。
- [***Flaticon***](https://www.flaticon.com/). 様々なアイコンをダウンロードできるサービス。Flaticonよりもアイコン数の多いサービスは、今のところ発見していない。ついこの前まではSVGが無料でダウンロードできたが、今は課金をしなければSVGをダウンロードできない。

### ドキュメント

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

## まとめ

以上が、Ekakiの技術スタックの紹介となります。技術スタックの選定は一人で行ってきましたが、実際の開発内容に関しては共同創業者の前澤が参画してから大きく変わりました！サービスとしてもまだまだ駆け出しのため、**これから新しく追加したり変更したりすることは頻繁に起きる**と思います！このブログに関する質問などありましたら、ツイッターで気軽に連絡して下さい！

 私がこれまでにどのような技術スタックを採用してきたのかをまとめました。SaaSの開発を始めたばかりの方やSaaSを新しく開発する予定のある方には、ぜひ読んで欲しい記事です。

one-man-saas

1人でのSaaS開発を支えた技術スタック

[前回の勉強記事](https://ekaki.ai/blog/loom)では、画面録画ツール「Loom」を取り上げました。今回選んだのは、Loomと同じくProduct-Led Growth (PLG) を実現している日程調整ツール「Calendly」です。2021年1月時点では$70M (約70億円) のARRを達成し、1,000万人のユーザーを抱えています。

## CEOの壮絶な経歴

### 幼少期の悲劇

CalendlyのCEO、Tope Awotona (トープ・アオタナ) はナイジェリアのラゴス出身です。母親は薬剤師、父親が微生物学者という比較的裕福な家庭に育ちました。しかし、12才の時に悲劇が訪れます。ある日、父親が家の前の道路に車を止めた際に、複数人の強盗に襲われてしまいます。父親は車の鍵を強盗に渡したものの、問答無用で銃で撃たれてしまいました。Topeはこの出来事の一部始終を目の前で見ており、大きなトラウマとなって、今でも不眠症に悩まされているそうです。

### アメリカへ移住

ナイジェリアでは大学の教育が遅れていたため、Topeが16才の時に、母親の勧めでアメリカのアトランタに移住します (ちなみにナイジェリアの公用語は英語です)。多くの面でTopeを支えてきた母親ですが、その母親もTopeがCalendlyを創業した年に亡くなっています。

### 起業家になるまで

アメリカ南部の慣れない英語のアクセントに悩みながらも、無事にジョージア大学に入学し、経営情報システムを専攻します。元々セールスに興味があったTopeは、大学在学中にコールセンターのオペレーターや警報装置の訪問販売などの仕事を経験しました。

そして大学卒業後もIBM・Dell EMCなどの企業でセールスとしてのキャリアを歩み続けます。特に[Perceptive Software](https://en.wikipedia.org/wiki/Perceptive_Software)という成長中のスタートアップで働いた経験は、Tope自身が起業家として独立する自信を与えてくれたそうです。

### 3度の起業失敗

TopeはCalendlyを創業するまでに合計3回起業し、いずれも失敗に終わっています。

1. マッチングサイト (Single To Taken)
2. プロジェクターのECサイト (ProjectorSpot)
3. グリルのECサイト (YardSteals)

一回目のマッチングサイトに関しては自身の開発スキルが足りなかったことから、ローンチにも至りませんでした。二回目と三回目のECサイトに関しては、利益率が低かったことや自身の興味がない分野であったことから撤退を決断しました。3度の失敗で自信を喪失したTopeは、しばらくの間は起業から身を引くことにします。

## 4度目の挑戦「Calendly」

### 日程調整に全てを賭ける

TopeがDell EMCでセールスをしていた頃、商談の日程調整のためのメールのやり取りが非常に面倒であることに気が付きます。20から30の日程調整ツールを一通り試しますが、誰もが簡単に使えるようなツールは存在しませんでした。

> ***The more I researched the opportunity the more I became obsessed with the problem -*** [Episode 81: Scheduling as a Service: Calendly’s CEO Tope Awotona on Revolutionizing the Meeting Lifecycle](https://open.spotify.com/episode/2BbrQLelNCKRZSup3Gurgv)
> 

3度の失敗で自信を喪失していたTopeは、何とかしてこの新しいアイデアを諦める理由を探しました。しかし調べれば調べるほど、同じような課題感を持つ人が数多く存在することがわかりました。そして6ヶ月のリサーチ期間を経て、これまでの失敗したアイデアとは何かが違うことを確信したTopeは、起業資金として200,000ドル (約2,000万円) を準備し、3度目の失敗から数年後の2013年に「Calendly」を創業しました。**起業資金を準備するためにも、クレジットカードを限度額まで使い切り、高金利の個人ローンなども借りたそうです**。

### ウクライナの開発組織

セールス出身の彼一人で起業したため、エンジニアを探す必要がありました。しかし、興味を持ってくれるようなエンジニアはTopeの周りにはいません。そこで「Railsware」というウクライナの企業に開発をアウトソースすることに決めます。アウトソースするに至って国内外の多くの企業を検討しましたが、最終的にはCalendlyのアイデアに最も興味を持ってくれた企業を選びました。ちなみに、**今でもCalendlyの開発の多くがウクライナで行われている**そうです。

そして契約から半年間の開発期間を経て、MVP (Minimum Viable Product) をリリースしました。

[https://cards.producthunt.com/cards/posts/2413?v=1](https://cards.producthunt.com/cards/posts/2413?v=1)

## Calendlyの成功要因

Tope自身が考えるCalendlyの成功要因は4つあります。

1. フリーミアムモデル
2. 日程調整の工数の削減　　　
3. 優れたUI/UX
4. 顧客管理システムとの連携

これらの全ては、**他の日程調整ツールには欠けていたが、実際にユーザーが必要としていた要素**になります。フリーミアムモデルを選択したのには、戦略的な理由はなく、当時決済システムを導入するだけの金銭的余裕がなかったからだそうです。

もう一つのCalendlyの凄さが、その高いバイラル性です。2019年1月まで一度も広告を打っていない上、アウトバウンドのセールスも行っていません (現在は不明)。数千人のユーザーに広がるまでには数ヶ月かかりましたが、それからはユーザー数が急速に伸び続けています。今では約1,000万人のユーザーがCalendlyを利用しています。

## 個人的に学んだこと

**誰よりもその課題について詳しいことはもちろん、なぜ既存のツールではその課題が解決できていないのかを徹底的に分析する必要性**を学びました。もしProduct Market Fit (PMF)を達成しているツールが市場に存在せず、課題と解決策の間に明らかなギャップが存在するのであれば、そこに大きなチャンスが潜んでいる可能性は高いでしょう。

## 参考文献
- [21: Calendly Founder Tope Awotona | Going All In](https://open.spotify.com/episode/6BcVQt388vWLmlXgytGEzp)
- [213: Calendly's Founder: Building A $30M SaaS After 3 Failed Startups - With Tope Awotona](https://open.spotify.com/episode/0Qb02QZGsoO22BoYemfTFH)
- [Demystifying the Unicorn Buzz with the CEOs of Calendly, Algolia, and Contentful](https://www.youtube.com/watch?v=ZvSzLrHocR8)
- [Episode 81: Scheduling as a Service: Calendly’s CEO Tope Awotona on Revolutionizing the Meeting Lifecycle](https://open.spotify.com/episode/2BbrQLelNCKRZSup3Gurgv)
- [Full Case Study: Calendly’s Journey to a $3B Valuation](https://blog.getlatka.com/calendly-tope/)
- [How Atlanta’s Calendly turned a scheduling nightmare into a $3B startup](https://techcrunch.com/2021/01/26/how-atlantas-calendly-turned-a-scheduling-nightmare-into-a-3b-startup/)
- [How Calendly is building a platform by turning scheduling into a center-stage event](https://techcrunch.com/2021/09/22/how-calendly-is-building-a-platform-by-turning-scheduling-into-a-center-stage-event/)
- [How Calendly Serves 5,000,000 People on a Monthly Basis](https://podcasts.apple.com/us/podcast/how-calendly-serves-5-000-000-people-on-a-monthly-basis/id1356321172?i=1000459273951)
- [Meet the unicorn founder that braved war zones and missed meetings to make his mark on the startup world](https://fortune.com/2020/11/19/calendly-founder-tope-awotona-startup-unicorn/)
- [Tope Awotona – A Founder Story](https://atlantatechvillage.com/buzz/2018/04/26/tope-awotona-a-founder-story/)

数々の苦難を乗り越えてきたナイジェリア出身のCEOが率いるユニコーン企業「Calendly」についてまとめました。世界の1,000万人以上が使う日程調整ツールを提供しています。

calendly_logo

日程調整ツール「Calendly」のまとめ

僕はたまに、今後の事業の模範となりそうなスタートアップのストーリーを読んでは、事業の将来を考えたり、純粋に元気をもらったりしています。普段は、Notion上にまとめたものをメンバーにだけ公開しているのですが、これからはブログにて公開することにしました。

今回選んだのは、画面録画ツールを提供するユニコーン企業「[Loom](https://loom.com)」です。「Video Messaging for Work」をキャッチコピーとし、2021年10月の時点では1,400万人のユーザーを抱えています（参考までに、Notionは同時期に2,000万人のユーザーを抱えています）。

## Loom CEOの経歴

LoomのCEO、Joe Thomasはインディアナ大学の出身です。大学では経済学を専攻していましたが、当時はリーマンショックと時期が被っていたこともあり、魅力的なインターン先を見つけられませんでした。そこで、ウェブデザインやロゴデザインを専門とする広告制作会社を在学時に立ち上げます。何の経験もなしに起業するには相当な自信が必要だと思いますが、Joeの家族が起業家一家（印刷会社・ゴルフコースの運営など）であることが大きく関係していると思われます。

> *I want to be a large owner of my own destiny* **-** [Joe Thomas, Co-Founder and CEO at Loom - "Creating Moments”](https://open.spotify.com/episode/3vcOVj5jglM1LHjQ6M2JDh?si=e971d16ac8fd49fd)

大学卒業後も自身の会社で働き続けますが、自身の興味やスキルアップを目的に、卒業から約3年の間に2回転職します。この時に、プロダクトマネージャー（PdM）としての経験を積みました。そして自身が十分に成長したと感じたタイミングで、次の起業のための共同創業者探しを始めます。Joeはこの時「何をやるか」よりも「誰とやるか」を最重視しており、特に

1. 働くリズム (Work Ethic)
2. 価値観 (Values)

の2つが一致する方を探していたそうです。そして9ヶ月後の2015年に、友人のエンジニアとデザイナーと共に、3人のチームで始動しました。

## Loomの前身「Opentest」

約8ヶ月で開発した最初のプロダクトは「[Opentest](https://www.producthunt.com/posts/opentest)」という、アプリを投稿するとデザイナーやマーケターなどの専門家からフィードバックを貰えるというサービスでした。サービス自体は悪くなかったものの、多くの企業は自社で専門家を抱えていたため、数万円も払って外部の専門家からフィードバックを貰う仕組みはヒットしませんでした。

[https://cards.producthunt.com/cards/posts/47996?v=1](https://cards.producthunt.com/cards/posts/47996?v=1)

しかしその中でも唯一、画面録画を通したフィードバック機能はユーザーから高く評価されていました。シンプルな画面録画ツールが求められていることを知ったメンバーは、画面録画に特化したプロダクトへとピボットすることを決意します。そして、2016年7月に今のLoomの原型となる「Openvid」をProductHuntにて公開しました。

> *The simplest solution is usually the right one* - [Joe Thomas, Co-Founder and CEO at Loom - "Creating Moments”](https://open.spotify.com/episode/3vcOVj5jglM1LHjQ6M2JDh?si=e971d16ac8fd49fd) 

ProductHuntの公開日には2,500人が登録し、100日後に「[Openvid 2.0](https://www.producthunt.com/posts/openvid-2-0)」を再度ProductHuntに公開した時点ではユーザー数は12,800人にも上っていました。

[https://cards.producthunt.com/cards/posts/77615?v=1](https://cards.producthunt.com/cards/posts/77615?v=1)

## PLG達成までの道のり

Loomが早期に直面したのが、「画面録画を撮って誰かに送る」という新しい習慣をどのようにユーザーに定着させるかという問題です。この問題を解決するためにチームが行ったのが、

1. 理想のカスタマージャーニーを明確にすること
2. 各ジャーニーのKPIを最大化すること

の二つです。ちなみにこの考え方は、Jim Collinsの「[Good To Great](https://www.amazon.co.jp/Good-Great-Some-Companies-Others/dp/0066620996)」という有名な本に書かれているFlywheelという成功の循環サイクルのモデルを参考にしています。

下の図は、ある時期にLoomが実際に理想としていたカスタマージャーニーになります。オレンジ色のボックスが各ジャーニーとそのKPI、白色のボックスが割くリソースの割合を示しています。

![「How a Focus on Speed & Simplicity Can Fuel Your Flywheel with Loom's CEO Joe Thomas」より](//images.ctfassets.net/nikr86yg7x45/637ROAjp3jKkU2kdCgO2gK/4c6ace722b44a95a32c671fbee93e75e/____________________________2022-01-22_22.23.48.png)

この時期は録画機能の強化（一番右のボックス）に70%のリソースを割いており、当時3人居たエンジニアの内、2人のエンジニアが4ヶ月もの時間をかけて取り組んでいたそうです。Loomは、録画してからビデオがアップロードされるまでの時間が短いことで有名ですが、この機能はCTOのHiremathによって同時期に作られました（[特許](https://patents.google.com/patent/US10484737B2/en?inventor=vinay+hiremath&assignee=Loom%2c+Inc.)も取得しています）。

## 個人的に学んだこと

### バーティカル**に展開しないこと**

> *We did not want to verticalize for any one persona, we wanted to build a video messaging for everybody at work* - [Joe Thomas, Co-Founder and CEO at Loom - "Creating Moments”](https://open.spotify.com/episode/3vcOVj5jglM1LHjQ6M2JDh?si=e971d16ac8fd49fd)

Loomは、Notion・Evernote・Slackなどの成功したフリーミアム系のサービスと同じように、多くの人に刺さるような汎用的なプロダクトを最初から目指してきました。Joe自身も、この意思決定を早期に行ったことはLoomの成功要因の一つと語っています。

汎用的なプロダクトを作るというのは、**ユーザー全員の最大公約数を取ったプロダクトを作る**という意味ではなく、コアユーザー・コアユースケースを常に明確にした上で、**どのような機能を作らないのかを言語化する**という意味でしょう。

### プロダクト作りにおける**忍耐力の重要性**

> ***Providing a best-in-class product is hard in any case, and much harder over the course of a decade because it takes so much discipline*. -** [Seven Questions with Joe Thomas](https://articles.sequoiacap.com/2020-10-14-joe-thomas)

SalesやPaid Marketingに依存せず、**プロダクトの力だけでユーザーに新しい習慣を定着させるには時間がかかります**。そしてそれを**何千万人のユーザーに定着させることにも途方のない時間がかかります**。

長期的なプロダクトの価値を犠牲に、短期的な開発スピードを追求しないことは重要です。プロダクトチームがスケールして良い時期なのかを常に問い、採用のタイミングを適切に見極める必要があります。Loomに関しても、上に挙げた理想のカスタマージャーニーを達成するまでは、3人のエンジニアだけで開発していました。

コアな機能だけに絞れば、小さなプロダクトチームでも達成できることはたくさんあります。同様に、小さなプロダクトチームにしか達成できないこともたくさんあります。もしLoomが初期に何十人ものエンジニアを抱えていたら、理想のカスタマージャーニーを追求することへの理解を全員から得られず、バイラル性の弱いサービスに終わっていた可能性もあったでしょう。

## 参考文献

- [Joe Thomas, Co-Founder and CEO at Loom - "Creating Moments”](https://open.spotify.com/episode/3vcOVj5jglM1LHjQ6M2JDh?si=e971d16ac8fd49fd)
- [SaaStr Podcast 445: Loom CEO Joe Thomas On How Speed & Simplicity Can Fuel Your Flywheel](https://www.saastr.com/loom-ceo-joe-thomas-on-how-speed-simplicity-can-fuel-your-flywheel/)
- [E1113 The Next Unicorns E19: Loom CEO Joe Thomas is building video for work, shares insights on creating new behaviors, support as a competitive advantage & more](https://thisweekinstartups.com/e1113-the-next-unicorns-e19-loom-ceo-joe-thomas-is-building-video-for-work-shares-insights-on-creating-new-behaviors-support-as-a-competitive-advantage-more/)
- [How Loom created an industry — and maybe figured out the future of work](https://www.protocol.com/loom)
- [Slack off — send videos instead with $11M-funded Loom](https://techcrunch.com/2019/02/19/loom-video/)
- [About Us | Loom](https://www.loom.com/about-us)
- [Seven Questions with Joe Thomas](https://articles.sequoiacap.com/2020-10-14-joe-thomas)
- [Loom Workplace Video Message Platform Valued at $1.53 Billion](https://www.bloomberg.com/news/articles/2021-05-20/loom-workplace-video-message-platform-valued-at-1-53-billion)

世界の1,400万人以上が使う画面録画ツールを提供するユニコーン企業「Loom」についてまとめました。勉強ノートです。

loom-logo

画面録画ツール「Loom」のまとめ

今回のブログは、私達が外に向けて発信する最初のブログになります。起業してからこれまで３年近く、会議を行う誰もが必要とする「[Ekaki](https://ekaki.ai)」を目指し、朝から晩まで職人のようにひたすらプロダクトを作り続けてきました。そして去年の１１月にクローズドβ版の事前登録の受付を開始し、その１ヶ月後にはSkyland Venturesからの資金調達を完了しました。

そして今回、資金調達という大きなマイルストーンを達成したことで、起業から今に至るまでのストーリーを初めて公開することにしました。Ekakiを作るチームとCEOである飯塚啓介（私）の紹介になればと思います！

## 自由なオーストラリア時代

私は、父親の仕事の関係でオーストラリアのシドニーに合計約８年間住んでいました。オーストラリア時代は、趣味のスポーツから学校の選択科目まで興味のあることには飽きるまで没頭するタイプでした。ボールのようにコロコロと興味が変わるということで、Bally（ボールみたいな子）というニックネームを付けられていた時期もあります笑

## 大学在学時に起業

![大学２年の時に旅行したタイで撮った写真](//images.ctfassets.net/nikr86yg7x45/5SIAqsUjCWaW2l262SlzuV/1b2ad0b50f0c2689a7ab463cf10e3719/IMG_0466_1_.jpg)

大学は、早稲田大学国際教養学部に進学。入学当初は、唯一の心の拠り所であった彼女とも別れ、大学のサークルにも加入しておらず、平日も休日も常に一人。退屈を紛らわすために一人で国内外を頻繁に旅行していました。しかし、何をしても孤独感が増すだけで、自分の人生に価値を見い出せなかったのを覚えています。

大学の授業期間は、家の近くのカフェで朝から晩まで本を読んでいました。特に好きなジャンルは、有名な起業家からコンピューターサイエンティストまで、様々な分野の偉人の伝記です。

> **人間が一生をかけても辿り着けるか分からない目標のために、自分の人生を捧げる**

そんな彼ら/彼女らのストーリーを純粋に楽しむと同時に、ある時、そのような生き方に嫉妬している自分が居ることに気づきました。「これが自分がずっと求めてきた生き方だったのか！」と、生きる意味を見つけたような感覚がありました。そして「**日本一の時価総額の会社を作る**」という目標を立て、大学２年の時に起業しました。

大学在学中に起業することは、就活という逃げ道を断ち、事業とは関係のない楽しい事を全て捨てるキッカケを作ってくれました。「起業する前に事業を作れ」みたいなことは頻繁に聞きますが、私のように繊細なくらい環境に影響を受けやすい方は、誘惑や環境の変化に流されないために、先に起業するのもアリかもしれません。それからは趣味の読書やスポーツに加え、自分の身だしなみとも完全に縁を切りました笑 

## スキルも経験もゼロからスタート

![ニューヨーク大学に留学していた時の寮の写真](//images.ctfassets.net/nikr86yg7x45/7KD8Vx0cvBPh7UvfZX2Kzr/6f03fb25b642a8b3ebc97e10de9c7cff/IMG_0755.jpg)

起業したは良いものの、当時は何のスキルもなく、事業アイデアをプロダクトに落とし込めるようなエンジニアやデザイナーの友達も周りに居ません。「だったら自分で勉強した方が早い」ということで、大学２年の秋からコンピューターサイエンスの参考書を読み漁りながら、プログラミングを独学し始めました。この時期にはニューヨーク大学に留学しており、寮の近くにある図書館に毎日通いながら参考書を１日２冊のペースで読んでいたのを覚えています。勉強熱心というよりかは、他にやることが無かったというのが本音です笑

## Ekakiの由来

![ロゴのアイコンは絵の具のパレットをイメージしています](//images.ctfassets.net/nikr86yg7x45/3LPlHPji48JX02h5GNewbX/36c5af3e24d044cbfa142c1862159cfb/ekaki_logo_inline.png)

当時はスキルと同じように事業アイデアも無かったので、市場レポートや深層学習系の論文も読み漁りながら、自分で定めた事業選びの基準を満たす事業も探していました。

1. ***市場***. 巨大な市場で高いシェアを継続的に獲得できるか
2. ***ニーズ.*** 絶望的な問題が存在し巨大なニーズが生じているか
3. ***ソリューション.*** 既存の解決策よりも何十倍も優れた解決策か
4. ***モチベーション***. 私自身がその事業に何十年も関わりたいと思えるか

まずは音声の領域に絞ることから初め、LinkedInで知り合った方にヒアリングをし、小さなピボットを繰り返していくことで、最終的に現在のウェブ会議のドメインに辿り着きました。

> 偉大な芸術作品は、人間の寿命よりも遥かに長い。プロダクトも一つの芸術作品であり、私達は**絵描き**として、そのような歴史に残り続ける作品を創り上げたい。

このような想いが「Ekaki」という名前に込められています。

## 採用の失敗の連続

そしてEkakiの事業が定まると同時に、プロダクトスキルのある共同創業者を探すことにしました。なぜ共同創業者が必要なのかは、[このスライド](https://www.slideshare.net/takaumada/how-to-find-your-best-cofounder)が非常に参考になります。

結論としては、エンジニアとして非常に優秀な方をSNS上で見つけることはできましたが、３ヶ月も経たずに辞めてしまいました。そして、この失敗を２回連続で続けてしまいました。失敗の原因は２つありました。

1. ***モチベーションの相違.*** プロダクトドリブンな事業において、共同創業者のプロダクト作りへのモチベーションが低い場合は、高い確率で修復不可能な問題が発生すること
2. ***弱い信頼関係***. 自分と個人的に繋がりのない人を共同創業者に迎えるに至って、コロナの状況下で対面で会える機会も少ない中、信頼関係を構築するのは現実的に難しいこと

この時期は、チームは一人/コネクションはゼロ/売上はゼロ/銀行口座には１０万円/プロダクトはプロトタイプ、というあらゆる面で課題が山積みの状況でした。到底一人で解決できるような問題ではないけれど、そもそも頼れるような共同創業者はいない。寝ても覚めても「この先どうすれば良いのか。。。」と悩んでいました。精神的に一番辛い時期でした。

## 共同創業者との出会い

採用の失敗から得た学びを元に、今度は、

1. **将来的に誰よりもEkakiにフィットするか**
2. **個人的な繋がりがあり、お互いに信頼できるか**

という２つの条件だけで共同創業者を探すことにしました。参画する時点でプロダクトスキルがあるかどうかは、完全に無視です。

そこで真っ先に思い浮かんだのが、大学時代に１学年下だった前澤です。私が大学２年の時に友人から[Hult Prize](https://www.hultprize.org/)という社会起業家向けのビジコンに招待され、そのチームの代表をやっていたのが前澤でした。早稲田大学近くのカフェで数年ぶりに会った時は、私自身冗談も言えないくらい感情を喪失していましたが、素直に興味を持ってくれて本当に嬉しかったです笑

前澤を一言で例えるならば、クリエイティビティーの神様です笑 神様は、息を吸うように新しいアイデアを発想したり、アイデアをデザインに落とし込むことができます笑 私と同じように幼少期を英語圏（イギリス）で過ごした経験もあるからか、お互いに大切にしている価値観が一致しているのも、信頼・尊敬し合える理由でもあります。

声を掛けた当初は起業時の私のように何のスキルもありませんでしたが、今では前澤がデザインとPRを兼任し、私がコアなエンジニアリングやその他の経営に関することを担当しています。改めて振り返ると、**私が起業してから今に至るまでに取った選択の中で、前澤に声を掛けたことが最高の選択**でした。最近はチームとしての地盤も固まり、前へ進むスピードが加速しているのが実感でき、今後が楽しみで仕方ありません！

## 準備せずに挑んだ資金調達

次に解決すべき課題は、資金調達です。実は前澤が参画する頃に、とあるVCのキャピタリストの方と投資委員会に向けて準備していた時期がありました。しかし、**当時は何となく資金調達を進めていた**こともあり、「このまま進めるのは事業のためになるのか」と色々悩んだ結果、自分勝手ながら投資委員会をキャンセルさせて頂きました。

## Skyland Venturesからの資金調達

![木下さんと３年ぶりに対面した時の写真](//images.ctfassets.net/nikr86yg7x45/3eOICYB6ZvULJJG9VMbqDN/8b60e4f7a3135ea5d62da7259e619dc7/265206774_293145092745541_3221410989836293944_n.jpg)

前回のような失敗を経験したことから、今回は事業計画の解像度を上げることから始め、どのような投資家がEkakiに必要なのかを言語化した後に投資家を探し始めました。

Skyland Venturesの木下さんと３年前にお会いしたことはありましたが、今回改めて「一番に投資して欲しい！」と思ったキッカケは、「スタートアップ投資TV」の[Skyland Venturesの回](https://www.youtube.com/watch?v=B7-vRYCxRFQ&t=656s)を見たことです。そこでは木下さんがプロダクト投資に対する考え方を話されていて、プロダクトを作っている起業家としてあらゆる面で共感できました。プロダクトで勝負をしているチームには、是非一度見て欲しいです！

木下さんは、C向けサービスの拡散方法からPLG（Product-Led Growth）を目指すSaaS企業の組織設計まで、私達が今までお会いした誰よりも広く深く、プロダクトが中核にあるビジネスを理解されています。まだ投資から１ヶ月も経っていませんが、木下さんのような投資家が隣にいてくださることで、**長期的なプロダクト作りの観点から今のEkakiに何が必要かを見極められる**ようになりました。改めて、最高の選択でした！

## 音声メモツール「Ekaki」とは？

[https://www.youtube.com/embed/6fG7b_g08SY](https://www.youtube.com/embed/6fG7b_g08SY)

「[Ekaki](https://ekaki.ai)」は、会議中は素早く快適にメモし、会議後は録音を聞き返しながら簡単に議事録を作成できる音声メモツールです。メモに夢中で会議の重要な場面を逃してしまう問題も、誰がどの時点で何を話していたのかわからない問題も解決します！現在、クローズドβ版の事前登録受付中なので、是非[こちらより](https://form.typeform.com/to/kVzmc3Vh)登録お願いします！

## これからのEkaki

これまで誰も解決できなかった問題を新しい方法で解決している以上、EkakiのPMF（Product Market Fit）には時間がかかると思います。一人一人のユーザーと向き合いながら、職人のようにコツコツ開発していくことは今まで通り何も変わりません。

このような職人魂を持ったエンジニアの方を募集しています！興味がありましたら、[気軽にMeetyで話しましょう](https://meety.net/matches/hTWLTbXRyJkX)！

私達が外に向けて発信する最初のブログです。資金調達という大きなマイルストーンを達成し、起業から今に至るまでの私達のストーリーを公開します。

1人でのSaaS開発を支えた技術スタック

日程調整ツール「Calendly」のまとめ

画面録画ツール「Loom」のまとめ

初めまして、Ekakiです