コロナ禍になって考えた自社の競争優位性　Public APIで競合相手を出し抜く、スタートアップのプロダクト戦略

飲食店におけるオペレーションの課題を解決する「Camel」

司会者：tacoms CTO、井上将斗さまです。制限時間は6分間です。準備はよろしいでしょうか？

井上将斗氏（以下、井上）：はい、大丈夫です。

司会者：それでは、お願いします！

井上：はじめまして。tacomsの井上です。「API連携が牽引する事業成長」というタイトルで発表いたします。

はじめに会社の紹介をさせてください。tacomsは学生起業から始まった会社で、創業当初は大学生向けフードデリバリーをやっていました。

（スライドを示して）当時はこのような状況でしたが、非常に楽しく開発していた記憶があります。

このサービスはうまくいかず撤退することになるのですが、飲食店のオペレーションに課題があることに気づきました。

まず、イートインと店外注文のオペレーションの両立は難しいということです。（スライドを示して）写真のように、デリバリーサービスのタブレットが乱立し、運用に負担がかかってしまいます。

また、飲食企業の売上管理はPOSで行っているのですが、デリバリーの売上が連動していないことがほとんどです。そのため、1注文ずつ手入力で打ち直す作業が発生してしまいます。

このような課題を解決するため、私たちは「Camel」というサービスを提供しています。1台のタブレットで複数サービスのオペレーションを統合した上で、さまざまなシステムと連携し、シームレスなオペレーションを実現しています。現在では約8,000店舗に導入いただくサービスに成長しました。

迅速に連携を拡大するためにPublic APIをリリース

本日は、どのようなプロダクト戦略が事業を牽引してきたかを紹介します。

我々がサービスを開始したのは2020年です。コロナ禍で競合も多数存在。優位性について考える必要がありました。

その中で私たちは、API連携のネットワークを優位性にしようと考えました。連携パートナーが増えて導入飲食店が増えると、パートナーにとっての魅力も高まり、事業成長を加速できると考えたからです。

連携ネットワーク構築にあたって「迅速」「柔軟」「高品質」の3つを大事にしてきました。それぞれどのような課題があったかを紹介します。

まず迅速さについてです。国内の飲食店は50万店舗存在し、飲食企業を取り巻くサービスも非常に増えています。そんな中で複数の企業から連携の依頼をいただきますが、すべてに対応することはできませんでした。

では、この課題にどう対処したかを紹介します。

迅速に連携を拡大するため、Public APIをリリースしました。リリース以降、連携企業は1年で7倍に成長。開発工数は0です。また、3ヶ月で3社との連携が完了するなど、通常開発と比較して大幅に期間の短縮ができました。

連携先が開発できない場合は、Public APIを通した外注開発を提案することもあります。事例として100店舗のアップセルも実現しました。

このように迅速な連携が可能となりました。

イベントドリブンアーキテクチャの導入で柔軟な連携を可能に

次は柔軟さについてです。冒頭でPublic APIの話をしましたが、連携先にAPIがある場合は、tacomsが開発することもあります。当然ですが、連携先の仕様はさまざまです。また、個別開発とPublic API双方の連携が必要になることもありました。

では、この課題にどう対処したかを紹介します。イベントドリブンアーキテクチャを導入し、コアサーバーと連携サーバーを疎結合にしました。Public APIと個別開発、双方の連携も実現できています。

このように柔軟な連携が可能となりました。

「問い合わせ対応全員参加」のアプローチで高品質なサポートを実現

最後は高品質についてです。連携開発の不確実性は大きく、仕様理解の難易度も高いです。以前は店舗からの問い合わせに対して気がついたエンジニアが対応する運用でしたが、仕様理解の難易度が高く、一部メンバーに負担が偏ってしまうという課題がありました。一部のメンバーへの偏りは、緊急の問い合わせに対応できず、サービス品質が低下するというリスクをはらんでいます。

では、この課題にどう対処したかを紹介します。「問い合わせ対応全員参加」というアプローチを取りました。一人ひとりが問い合わせ対応を行い、対応記録をドキュメントに残します。そして、個人の対応記録は週次のミーティングで全体共有し、チームのナレッジへと広げていきます。結果として、高品質なサポートを実現できました。

このように、迅速、柔軟、高品質を意識した開発が事業を牽引してきました。

CTOとして大事にしてきたこと

最後に、自分がCTOとして大事にしてきたことを紹介します。1つは、全領域を横断した課題解決です。CTOは経営者なので、開発以外も含めた課題解決が必要だと考えています。

2つ目は覚悟です。学生だった自分がここまでCTOをやってこれたのは、多くの人の人生を背負う覚悟を持って経営してこれたからだと思っています。

ご清聴ありがとうございました。

（会場拍手）

かなり初期からAPIを開ける交渉に注力している

司会者：ありがとうございました。それでは質疑応答に移ります。審査員のみなさま、挙手をお願いします。さぁ、いかがでしょうか。竹内さま、お願いします。

竹内真氏（以下、竹内）：ありがとうございます。Public APIで競合戦線に勝ち抜いたというお話だったと思うのですが、いろいろな機能開発をされている中で、ほかの競合サービスにはない、または競合サービスを出し抜いた技術的なアプローチによるユニークネスがあれば教えてもらっていいですか？

井上：そうですね……連携先でAPIがないことって当然あると思うんですよ。APIを開ける交渉にはかなり昔から注力していました。

交渉をどうやってやったかというと、基本的にはまず大手の飲食店さんに、Uberさんや出前館さんなどの連携先を当たってもらって、そこからAPIを開けてもらうという交渉をかなり初期から注力していました。

竹内：それはテックのチームもやっているということですか？

井上：ごめんなさい。これは会社全体の話です。

竹内：そうですか。なるほど（笑）。

井上：テックの話については、ちょっとここではあまり言えませんが、やはり泥臭いこともやってました。

竹内：なるほど、ありがとうございます。

セキュリティリスクにはどう対応しているか？

竹内：もう1個、質問してもいいですか？

井上：はい。

竹内：Public APIを使って連携を増やしていくと、APIもどんどん増えていく可能性が高いと思っていて、やはりものによってはセキュリティリスクがはらむAPIもあると思いますが、そこのバランスはなにか考えられていますか？

井上：うち経由のAPIのセキュリティですか？

竹内：そうですね。公開して、最初よりだんだん増えていくと思うんですよね。その時にリスキーなAPI、「これはちょっとやめよう」みたいなものもあるのかなと思っていて。

井上：そうですね、例えば、開示しちゃいけないデータとか、どこまでは開示していいという概念はあると思っていて。いわゆる公開API、Web APIにもスコープという概念があると思いますが、そこは初期から設計しています。

例えばうちの場合、注文の中にお客さまの住所が入っているんですね。全Public APIの事業者がお客さまの住所を必要とするわけはないんですよ。一部はいらないので、そこはしっかりスコープで出し分けられるようにしています。

竹内：ありがとうございます。

司会者：ありがとうございます。

APIを使ってもらうためにやっていること

司会者：ほかに質問はありますか？　馬田さま、お願いします。

馬田隆明氏（以下、馬田）：ご説明ありがとうございました。APIを公開してもらったあとの話をぜひお伺いしたいです。公開したからといって、使ってもらえるとは限らないとも思っています。

そういう意味でデベロッパーリレーションズをやったり、先ほどお話にあったパートナー企業をつかまえたり、周りでAPIをうまく使ってもらえるような環境をどう作ってきたのかというところをお伺いしたいなと思っています。

もしくはビジネスサイドでのトラクションがすごく多いので、別にそんなことやらなくてもみんなは使ってくれたみたいな。そのあたりをぜひお聞かせください。

井上：ありがとうございます。現状、うちのAPIを連携先にそのまま提案するということはやっていなくて。現状は2つのパターンがあると思っています。

1つ目は、連携企業が、導入したい飲食店においてtacomsと連携したいというパターン。もう1つは、tacomsが導入したい飲食店の方が連携を希望しているPOSレジやシステム会社へPublicAPIで連携してくれませんか？　と提案するパターンですね。この2軸が多いです。

現状は基本的にこれだけでやっています。ただ、これからどんどん連携先のターゲットは広がってくると思うので、そうなったら直接うちが連携先に行くこともあると思います。

司会者：ありがとうございます。以上で質問を締め切らせていただきます。審査員のみなさま、ありがとうございました。そして、井上さまにも大きな拍手をお送りください。

（会場拍手）