巨人の肩に乗り、SaaSの開発を眺める
はじめに
カミナシのPMをやっています、後藤です。
ノンデスクワーカーの働き方を効率化するSaaSを開発しています。
最近ユーザーへのヒアリングを積み重ねていく中で、自分の実体験の少なさがネックになることが多いです。特にソリューションを機能単位に落とし込む際に、そんなふうに感じます。
大きな顧客のペインを見つけた瞬間はとても嬉しいのですが、どれだけ質の良い課題を見つけても、その解法が悪ければ既存のオペレーションに敗北してしまう。自分たちの場合であれば、デジタルより紙が選ばれてしまうシナリオです。
でも、手持ちの実体験を短期間で増やすことは難しいですよね。
そこで、自分たち以外のSaaSの成功を追体験することで、引き出しを増やそうと考えました。経営者がビジネス本を読むように、PMやエンジニアは他の SaaS を探訪することによって成功へのエッセンスを知る事ができるんじゃないかと。
そこで何故このプロダクトは生まれたのか、そしてこのプロダクトが解決したいことは何か。
実際に、急激に成長した海外 SaaS はどの様な戦略を取ってきたのか、追体験していきたいと思います。
今回は２つのSaaSについて書きました。
Airtable (Series C, 資金調達額: $170.6M)
進化型の Spreadsheet SaaSです。有名ですよね。
Airtable は従来の Spreadsheet と比較すると、テンプレートとセルのフィールドがかなり柔軟に設定できることが特徴です。
テンプレートの設定で、CRM, ユーザーリサーチ, バグトラック, 不動産取引管理, 採用管理等の複数のユースケースに対してテンプレートを管理することができます。
セルのフィールドの設定で、画像つきフォームの作成, カレンダーでの予定の TODO 管理, かんばん形式によるプロジェクト管理等をノーコードで実現できるところが強みです。
今までだとGoogle Formや、Google Calendar などを使って管理をしていた部分を汎用的な設定により、より複雑な要件のアプリを柔軟に作成出来るのがいいところ。
そんなAirtable がどの経緯で生まれ、そしてそのサービスは何故この様な使われ方をされる様になったのか、ルーツを見てみましょう。
Airtableが出来るまで
Airtable の創設者である Howie Liu氏は、2010年当時のCRM業界にとって革新的なサービスの開発を行っていました。そのサービスの名はEtactsです。
このサービスはGmailアカウントと接続し携帯から接続することで、以下のようなことを実現することが出来ます。
■ 連絡先をランク付け出来る！
連絡する頻度、連絡の総数などでランクを付けてくれる
■ 対象に連絡を取るべきタイミングのリマインダーを送信
■ メッセージに優先順位を付与
メール上で行われる情報を追跡し、次への最適なアクションを促してくれるメールのコンシェルジュのようなサービスです。
このEtactsというサービスは1年未満と早い段階でSalesforce によって買収されることになります。
そこでLiu氏はSalesforceでのプロダクトマネージャーとして1年過ごします。
彼はSalesforceで過ごしていく中で、90%以上のユーザーがスプレットシートを適切に使えていないことに違和感を感じていました。
“Spreadsheets are really optimized for numerical analysis and financial calculations. But almost 90% of spreadsheets don’t have formulas. Most are used for organizing purposes.”
スプレッドシートは数値分析や財務計算に最適化されています。しかし、ユーザーが運用しているスプレッドシートの9割は数式が使われていません。ほとんどが整理目的で使われています。
そこで、Liu氏はスプレッドシートの使いやすさとリレーショナルデータベースの力を組み合わせた全く新しいサービスを開発していくことになります。
Airtableの誕生です。
ただ、Airtableがスプレットシートにもリレーショナルデータベースでもなく全く新しい体験を提供しなくてはいけません。じゃないと、それぞれ別のサービスを使ってしまう。
ここがAirtableの肝であると言えるでしょう。
そこでこのスライド内でも紹介されている、カラムが短期間の間に大量に作られているScholarMatchが如何にしてAirtableを活用していったのかを見ていきます。
個人的には、この中にAirtableの成功の鍵が眠っていると考えています。
ScholarMatchの事例
ScholarMatchは、クラウドファンディングの大学奨学金を提供している小さな非営利団体です。
ScholarMatchは、寄付者や寄付を管理するための情報を簡単に相互参照できるシステムを必要としていました。
従来のデータベースシステムでこれを実装すると数万ドルもの費用が掛かってしまいます。
各情報をデータベース化させ、さらに寄付時にデータベースの状態をリアルタイムで管理する必要があり、こうなってくると必然的にシステムに対しての複雑度が増してきます。
この複雑なユースケースに Airtable はどのように解決をしたのか。その解き方は以下の画面にヒントが隠されています。
上のシート内の「Students」,「Student Match」の列に注目です。
このStudentsは、画面内のStudent Matchの欄に入力されている値と紐付きが出来ます。これは、リレーショナルデータベースでの紐付きと全く同じ概念です。
このように、各テーブル間の紐付きをタグのような直感的なUIで表現することが出来ます。
まるでエンジニアがDBの設計をするのと同じような感覚で、データの関連をつけることが出来ます。
このようにAirtableは、複雑なデータベースを必要とするようなアプリケーションに対しても直感的に使えるように設計がされています。
さらに、AirtableはAPIの繋ぎこみやZapierの繋ぎこみも可能な作りです。以下はScholarMatchの寄付金をStripeと連携することにより一覧で見えるようにしたものです。
Airtableにはblocksという機能もあり、最近このblocks内に直接コードを埋め込める機能も紹介されています。これを使うことでまるでGASのようにデータを扱うこともできます。
AirtableはExcelだけではなく、Google SpreadSheetの仮想敵となり得るような存在ですよね。
このようにAirtableは、以前は独自のアプリと独自のデータセンターに閉じ込められていた情報に対して、全く新しい方法を提供することでオープンな状態にしています。
スプレットシートとしての機能を超えるアプリとして側面、テンプレートによる複数のケースへの対応の幅やその表現力の高さが圧巻です。
Front (Series C, 資金調達額: $138.3M)
チーム間でのメールコミュニケーションを効率化する SaaSです。
email にcc をつけて運用をしていた場合に、メールそのものが埋もれてしまったり、そのメールに対してどのくらい重要なメールなのかが分かりづらくなることはないでしょうか？
この痛みを解決するサービスこそがFrontです。
Frontはチーム間で流れやすいコンテキストの共有をemailを超えて複数のサービスを一元で管理し、コミュニケーションできることに特化しているサービスです。
現在はFacebook MessengerやSalesforce、Intercomなどの50種類を超えたサービスとの統合が可能になっています。
Front が解決したいことは何か、またどんなアプローチを取ってきたのか。またそれはなぜか。それは以下の記事にて端的に述べられています。
Frontが解決しているもの
Front がそもそも解決したい課題は Email をなくすことではなく、既存の Email を再定義することです。
Email での体験を一部新しい価値に変換し、Front にしかない体験の提供を行うことで他とは違った価値を提供しています。
Emailは確かに柔軟な作りです。ただ、3人以上の会話となった場合はどうでしょう？
後追いも難しく、チーム間で利用するにはあまりにも機能が乏しいと自分は思います。
Frontはこの体験を以下のような再定義を行います。
◾ CCやBCC => 共有
◾ メールの返信 => コメント
◾ 一括返信 => 購読/フォロー
このように、既存の機能に対して、プロジェクト管理ツールのような機能の側面をEmailに取り入れています。
この機能によって、今まで難しかったチームでの体験を向上させることが出来ます。
この体験向上の例として、Boxtonsの事例を見ていきましょう。
BoxTonsの事例
The Boxton team has 6 shared inboxes in Front to manage requests and shipments, and they regularly receive more than 250 emails a day.
Boxtonチームはフロントに6つの共有受信箱を持ち、リクエストと出荷を管理しており、1日に250通以上のメールを定期的に受信している。
They tag each shipment with the request number to keep all the communication around it in one easy-to-track place. Tags and archiving in Front has been a million times better than our old process, Kucker noted. 「各貨物にリクエスト番号を付けてタグを付け、それに関連するすべてのコミュニケーションを追跡しやすい場所に保管しています」とカッカー氏は言います。「タグとFrontのアーカイブは、以前のプロセスに比べて何百万倍も優れています」とカッカー氏は指摘します。
何百万倍も優れていますって言わせるのやばくないですか？初めて読んだ時、震えました。
このようにFrontのいい点として、メールのフォルダを利用せずに、タグによる管理を行うことにより、より少ないステップでの検索が可能となる点です。
日々の作業のうちの領域の分ける部分、今回でいうと貨物ごとにタグを用意することで、以前だとフォルダ => メール確認への検索経路だったものから、メールへ直接確認することができるようになります。
さらには、割り当ての機能で誰が返信を返すべきなのかにより誰が返すべきなのか、それを全員が確認することにより暗黙知となり得る可能性を潰しています。
Boxtonsは1つのメールに75メールほどのチェインが繋がることがあるそうです。
これだと、もう知っている人で無いと追跡が困難だし、何よりも面倒ですね。
これに対してFrontではコメントで返信することができます。
メール外でのやりとりだったり、この顧客に次どのような行動をするべきかのような、メールでは読み取れない部分も明らかに出来る。
このように、事例を見てもメールでは救いきれなかった体験をFrontが提供することは間違い無いでしょう。
Frontでの意思決定
言うのは簡単ですが、Emailの再発明プロダクトを作ることはそんな簡単ものではありません。分かりやすい点でいえば、MVPを作るのがめちゃくちゃ大変なんです。
Gmailなどが備えている機能を全て代替しなければならない（添付ファイル処理、タグ、ドラフト、アーカイブ、ゴミ箱、会話スレッド、連絡先管理 etc...１つとして不要な機能がない！）
そんなEmailに対して、Frontはどの様な意思決定を行ったのでしょうか？
1. 企業をターゲットとし、フル機能のEmailクライアントを作成したこと
2. 一番初めのプラットフォームとして、デスクトップアプリを選択したこと
1つ目は、Emailの拡張機能としての立ち位置ではなく、Front自体がEmailクライアントとして確立することを意味します。
これによって、EmailでのやりとりはFront内で完結する。GmailやYahoo! Mail等の他のEmailクライアントを見る必要がありません。
2つ目は、webを初めのプラットフォームとして選んでいません。これは何故か。その意味は以下の記事にて語られています。
デスクトップアプリがwebのアプリと違う点は、使用感や使用頻度に差分があります。 エンジニアの使用頻度が高い道具はIDEであり、デザイナーの使用頻度が高い道具はPhotoShopなどがあります。
このどちらも、デスクトップアプリです。
Frontはビジネスマンに取って最高の道具になり得るために、デスクトップという最難関の開発を最初期に選びました。
つまりEmailそのものを作ってしまい、技術的、運用難易度が高いプラットフォームを選択する戦略を取ったのです。
多くのスタートアップが、シンプルで難易度の低いプロダクトから始めて、徐々に複雑なサービスを作っていきます。しかし彼らは、UXの最大化を志向し、最も難易度の高い開発を選択しました。定石からは外れますが、至極合理的な意思決定を取っているとも言えます。
実際にスタートアップでプロダクトを作ってる身としては、Frontのこの意思決定には感嘆の声をあげてしまいます。
頭では合理的だと分かっていても、おいそれと出来ることではありません。
開発チームが、ユーザーの満足度や体験から逆算し、それらを最大化するために意識されています。
終わりに
今回は2つの大型調達を行っている２つのSaaSの成り立ちを見てました。
どちらのサービスも、当たり前とされていた既存の体験に疑問を呈して、新しい価値へ変換させるための意思決定が大胆で、鮮やか、惚れ惚れします。
（みなさんはGoogle spreadsheetとGmailを仮想敵としてサービス作ろうと思いますか！？）
エンジニアとしてキャリアをスタートしているところから、自分でも無意識の部分でバイアスがかかったり、視野が狭まってしまうことがあります。
そんな時に妥協せずにユーザーのニーズを汲み取り、提供価値を見誤らないこと。何より、Frontの例のように、自分を楽な方向へと進めるようなぬるま湯の意思決定はしてはならないと、自戒しました。
巨人の肩の上からSaaSの開発を眺めることで選択の幅を広げ、意思決定をし続けて課題にぶつかり続けていきたいです。
参考文献
- https://techcrunch.com/2015/02/25/airtable/
- https://usefyi.com/airtable-history/
- https://www.quora.com/What-does-Etacts-do
- https://airtable.news/powering-legislative-advocacy-using-airtable-andrew-cates-ae66d5385200
- https://airtable.news/students-meet-your-match-how-scholarmatch-made-airtable-work-for-them-part-1-7a1d77a2bf51
- https://airtable.news/students-meet-your-match-how-scholarmatch-made-airtable-work-for-them-part-2-cf980ea8f691
- https://techcrunch.com/2014/06/18/
- https://medium.com/@collinmathilde/predicting-the-future-of-email-c934bdc1583d
- https://www.slideshare.net/MathildeCollin/front-series-a-deck-64596550
この記事が気に入ったらサポートをしてみませんか？