「State of Commerce」は、Eコマース運営の影の主役である、EC制作やアプリ開発、物流や在庫管理、集客などの現場を通じて、顧客や市場へ価値をつくりだしているスペシャリストの方々に焦点を当てるインタビューシリーズです。現場の最前線が肌で感じていることを自らの言葉で語って頂くことで、Eコマースの現在の輪郭を少しでも捉えることができればと考えています。 (インタビュー一覧はこちらから)
第13回目は、ECに特化したノーコードツール「TēPs(テープス)」を提供する、テープス株式会社代表の田渕健悟さんにお話をうかがいました。この夏、新たな接続先として Shopify を追加した「TēPs(テープス)」にとってEC運営の未来はどう映っているのか、存分に語っていただきました。
※インタビューは2022年8月に行われました
「大きなありがとう」と「小さなありがとう」
ーー 本日はお時間いただきありがとうございます。「TēPs(テープス)」はネットショップ内に起こるさまざまな業務を効率化するツールを自分で作れるサービスですよね。紆余曲折を経てこのサービスにたどり着いたと思うのですが、まずはこのアイデアを具現化するに至った経緯からお伺いできればと思います!
田渕:ありがとうございます。「TēPs(テープス)」構築の背景はいくつかあるんですが、一番大きい動機は、ECの現場の作業にあたるものの「本当の意味での自動化」を実現したいという気持ちでした。
ご存知のとおり、ECって本当にやるべきことが多いです。それらに忙殺されずにマーチャントが本当に力を入れるべき商品開発やマーケティングに時間をさけるように、日々の作業が楽になるお手伝いができたら、と思ったのがきっかけになりますね。
個人事業主を経て、2010 年に株式会社 WEB の匠(現シッピーノ株式会社)を代表取締役として起業。2022 年 4 月にシッピーノ株式会社内の TēPs(テープス) 事業を分社化し、新たにテープス株式会社を設立。シッピーノ株式会社 取締役 / テープス株式会社 代表取締役に就任。
田渕:元々WEB業界でキャリアを築いてきたのですが、2008年に「WEBの匠」という屋号で会社をスタートさせました(現:シッピーノ株式会社)。この命名は、某リフォーム番組で、その道の “匠” が人々の生活をバージョンアップさせるというコンセプトが好きで、あやかりました。「お客さまそれぞれのお悩みにフィッティングする価値をあたえたい」という思いからです。
駆け出しのころは技術的なサポートからコンサルタントまで、何でもやっていました。中小企業と向き合うことが多かったのですが、ビジネスの規模がそれほど大きくなければ、何か一つがヒットすると状況が何倍にも変化します。
ーー “匠” のリフォームで施主であるネットショップのみなさんが感動している光景が浮かびます(笑)
田渕:はい、めちゃくちゃ喜んでもらえます(笑)。そこが一番のやりがいだったんです。
でも、少しずつ事業拡大していくほどご予算の確保がネックになってきます。困っている会社ほどご予算がないけれど、こちらも安く請け負ってしまうと品質が担保できない。そのはざまでジレンマに陥りました。
そこで多くの方にご利用いただくために受託開発から SaaS にシフトしたのですが、受託のときのような「大きなありがとう」と出会えなくなって物足りなさを感じるようになってしまいまして……。
ーー むずかしいですよね。SaaS で「小さいありがとう」はたくさん得られるかもしれないけれど、その代わり先方のビジネスを変えるような「大きなありがとう」には出会いにくくなってしまうという、新たなジレンマが待っていたと。
田渕:はい、特に困りごとの多い中小企業の場合、それぞれが手作業でやっていることが膨大で、そこを解決したい……となると、どうしても受託開発のほうが向いていることが多いんですよね。
SaaS はたしかに便利なのですが、SaaS に業務をすべて合わせると、どの会社もオペレーションで差別化ができません。EC各社は「他と違うことをする」というインセンティブがあるので、がんばればがんばるほどオリジナルの業務が増えていきますから。
ーー マーチャントは「他と違うことをしよう」、SaaS は「みんな同じ仕組みで運用しよう」だと、重ならない部分で利害の不一致が起きてしまいますよね。そのスキマをブリッジするための仕組みが必要になって受託開発に立ち戻ると、今度は予算のジレンマが待っている……。うーん、ムズいです。
田渕:そうなんです。業務の「スキマ」は必ず生まれるので、SaaS の導入だけでは残念ながら根本解決にはなりません。むしろ複数のチャネルや SaaS があるゆえにスキマが広がっているとも言えます。
そこで行き着いたのが、「ノーコードでスキマを埋めることで業務最適化を実現するツール」の構想でした。受託開発で細かく実現しているようなことを、エンジニアじゃなくてもできるような仕組みがあれば、SaaS の「スキマ」をフォローできるはず、という思いで開発をスタートしました。
ーー なるほど、業務のスキマを埋めることで、マーチャントごとに違う業務を包括的に改善することを目指して「TēPs(テープス)」が生まれたということですね。
実際に目で見て感じた、「スキマ」業務の実態
田渕:もう少しだけ説明させていただくと、業務改善を目指していることは事実なのですが、実際に取り組んでいることは「業務改善」とは少しニュアンスが違っていて、先ほどから出ているキーワードの「スキマ」を埋める作業だなと感じています。業務一つひとつはツールによって最適化されているので、その一つひとつの業務と業務のスキマを埋めていくというのが表現として近いのかなと思っています。
例えば、商品情報などのデータを移動させるときはプラットフォームに合わせた変換が必要ですよね。CSV のカラムが A と B とで違う、みたいな。「システムとシステムの間でデータを移動させる」といった仕事ってどちらのシステムの公式サポートも得られない領域で、結果的に手作業になりがちな「スキマ」になっているんです。
ーー ああ、確かに、マーチャントが導入しているシステムが1つだけということは稀で、複数を組み合わせていることがほとんどですよね。それぞれをつないだり集計したりするためにダウンロードして Excel にまとめて……と手作業が増えていく。重大なミスの温床にもなりそうです。
田渕:まさにそうです。なので、業務全体の改善というよりも「スキマ」だらけの部分をいかに効率化していくかというところにフォーカスしようと思いました。
ーー なるほど! ようやく「TēPs(テープス)」がどこにフォーカスしているのか理解できた気がします。 ちなみに田渕さんはものすごく現場でのヒアリングを重視されている印象ですが、この「スキマ」問題は、アイデアというよりもEC現場のヒアリングを繰り返す中で気づかれたのでしょうか。
田渕:そうですね、根本には、たくさんの EC の現場に訪問して朝から晩まで張り付かせてもらって、この目で確認させていただいた経験があると思っています。どういうファイルを使って、どのような入力作業をしているのか、Excel だったらどのセルに何を入れているのか、というところまで。隅々まで見れば見るほど、スクラッチで解決しなくては……という思いが大きくなりました。
ーー 使用ツールも技術的な習熟度もバラバラなマーチャントごとのスキマを埋めていく…… EC 業務が複雑化して、接続するサービスや組み合わせが増えれば増えるほど「TēPs(テープス)」の価値もあがっていきそうです。
田渕:はい、そう考えています。連携先が増えるほどユーザーの利便性が向上する仕組みになっていますね。現在は楽天市場や Amazon 、ネクストエンジンといったサービスとの連携が実現できています。2022年7月からは Shopify とも連携を開始しました。
ーー 今後もどんどん連携先を増やしていくという戦略なのでしょうか。
田渕:基本的にはそのとおりなのですが、連携するサービスの拡大と併せて、それぞれのサービス内での「やれること」を同時に増やしていくことが重要だと考えています。
サービスとサービスの「間」以外にも、サービスの「内側」にもたくさんの手作業による負担があるので、ここにメスを入れないと全体の利便性が上がりません。「TēPs(テープス)」はそれぞれのサービスごとに作業内容を細分化した「ノート」と呼ばれるテンプレートを用意しているのですが、このノートが解決する「内側」のバリエーションを増やすことで、「間」との掛け合わせで指数関数的にできることを拡大したい、と考えています。
ーー なるほど、ここで現場を直接見てきた経験が生きてくるのですね。EC の担当者が実際に行っている業務内容と「TēPs(テープス)」でできることが合ってないと、需要に対してちぐはぐな機能を提供してしまいかねない。接続先ごとに典型的に発生する業務を洗い出す必要があったということですね。
田渕:おっしゃるとおりです。たとえば API の仕様どおりにノートを作っていけば、開発のスピード自体は上がります。でも、それだと現場の実作業で発生する「スキマ」を埋めることには必ずしもつながらない。どのサービスでも必ずと言っていいほど仕様外の追加作業が発生してしまっているんです。だから「TēPs(テープス)」は、敢えて連携先の仕様書どおりには作っておらず、一手間加えて実業務に合うようなノートになるように作っています。
ーー すばらしい。仕様書プラスアルファで開発するということは、一つひとつのノートの中にさまざまなユースケースが詰まっているということなんですね。ちなみに、実際に発生しうる典型的な業務にはどのようなものがあるんでしょうか。
田渕:たとえば、楽天市場はセールに合わせて一気に商品情報を変更する必要があります。しかも、セールは日付が変わるとともに始まるので、作業が求められる時間は深夜帯。これを手作業で全部……となると、なかなか大変ですよね。スプレッドシートを活用して変更する時間をセットし作業を自動化するだけで、大幅に負担が軽減できます。
ーー こういうユースケースごとにノートができていると便利ですね。ブログでもこまめに発信されていらっしゃいますが、まさにこういうケースのための説明書としても機能しているように思えました。
田渕:はい、EC だけではなく実店舗でも展開しているお店も多いので、みなさん結構な頻度でダウンロードとアップロードを繰り返されています。なので、こういったユースケースの発信を通じて、Excel やスプレッドシートも含めた現場が管理しやすいデータ運用を提案していければな、と思っています。
さらなる広がりを求めて、Shopifyへ
ーー 連携するサービスを増やすこと、ユースケースをノートで解決していくこと、2つの要素の組み合わせによる展開を伺いましたが、今後さらに目指しているところがあれば教えてください。
田渕:実は、ノート自体を外部のベンダーが開発できる仕組みを作ることができれば、と考えているところなんです。
我々以外のアプローチが入ることで活用にさらなる広がりが期待できますし、その開発者がサービス提供者ならば、一つノートを追加するだけで「TēPs(テープス)」へ新たなサービス連携ができるようにもなるはずです。
API を提供するのかどうかも含め、実現の方法についてはまだ検討中ではありますが。
ーー 「TēPs(テープス)」のオープン化ですね! ある種のプラットフォーム化していく感じ、大好きです。ベンダーが新たなノートを開発して取引中のマーチャントに連携してもらったりもできそう……おもしろそうです。
田渕:Amazonのベンダーセントラルや、「卸の情報を基幹システムに連携したい」といったご要望は頻繁にいただいてまして。こういう表に出てきにくい連携も「TēPs(テープス)」で担保していきたいと考えています。
ーー この文脈でいくと、API が豊富な Shopify への連携拡大もうなずけます。
田渕:カートシステムに連携したのは、実は Shopify が初めてなんです。これまではモールが中心だったので。
Shopify でストアを持とうとするユーザーさん、どんどん増えていますね。既存のカートシステムともまったく違う思想でできていて「今後間違いなく伸びる」という感触があったので、Shopify はカート連携の第一候補でした。
外部のベンダーがアプリ開発をして機能拡張できるのも、必要なものをつなぎ合わせてかたちを作る考え方も、「TēPs(テープス)」にぴったりはまると考えています。
ーーShopify は API のカタマリみたいなものですし、連携はやりやすそうですね。
田渕:そうですね。ただ、物流側では Shopify の注文を取り込めても、逆の機構が Shopify 側にない、といったケースはあるので、だからこそ「TēPs(テープス)」でスキマを埋める仕事があるなと考えています。ほかにも細かく発生するイレギュラーはたくさんあると思うので、Shopify で使えるノートを増やして利便性を向上するのがミッションです。
「ニッチすぎて泣き寝入り業務」を救済
ーー 困りごとのほとんどは、イレギュラーですよね。困りごとの大きさや頻度と、システム化のコストが見合わないという。
田渕:そうなんです。だからニッチな業務はサービス化されないんですよね。
改善してほしいという要望に対して、その母数が少ないとベンダーやプラットフォームから手を差しのべてもらえないことが大半です。開発されないから、事業者は泣き寝入りして手作業でやらなくてはならない。しつこいですが、ここを「TēPs(テープス)」でカバーしていきたいんです。
ーー ニッチな業務って、ニッチであるがゆえに自社固有の業務と思いこまれていることも多い気がしますね。
田渕: 「注文のキャンセル」のような一言で表現できる作業でも、実際はそれがどのプラットフォームなのか、クレジットカードなのか代引きなのか、複数の商品のうち一部のキャンセルなのか、その場合のポイントやクーポンはどうするのか、といった付帯業務の幅はショップによって違いますね。だから名前がついていない自社固有の業務はとても多いです。
ーー それらは言語化されないままその会社の中にずっとあって、言語化されていないから助けを求められないし、そもそもそこに手を差し伸べるサービスが存在しているということを認識できないということですね。おそらく「TēPs(テープス)」だったら救えるのに。
田渕:ありがとうございます(笑)。そういう細かなところも救えるように、ユースケースのブログを頻度を高く更新するようにしています。色々なパターンがあるので、ここで言葉を尽くすことで誰かに発見してもらって、問題の解決につながるとよいなという願いを込めて書いています。
一つひとつの記事のトラフィックはそれほど多くはないですが、確実に困っている人につながっている感触はつかんでいます。最近はベンダーさんやコンサルティング会社さんから「TēPs(テープス)」を紹介してくれることも増えました。ユーザーがそういったサービス会社に問い合わせることが多々あるのですが、その時に「その作業はTēPs(テープス)で解決できるよ」と言っていただける。この流れもとてもありがたいですね。
参考リンク
ーー 基本はエンドユーザーに気付いてほしいけれど、ニッチな業務だと課題化するところから難しく、助けてくれるはずの「TēPs(テープス)」になかなかたどり着かない。そこを、サービス事業者からの紹介で補えるわけですね。サービス事業者側からしても、個々の細かな問い合わせを「TēPs(テープス)」に委ねられるから、三方良しですね。
常に新しい価値と遭遇できる
ーー ここまでいい話ばかり聞いている気がするので(笑)、今後に向けての課題などもお聞きできるとありがたいです。
田渕:課題はもちろんたくさんあります(笑)。大きく分けると2つありまして、まずは先ほど触れていただいところと近いですが、「TēPs(テープス)」の解決する問題がニッチすぎて、知っていただくための活動がむずかしいことです。要するに集客の難易度が高い。地道にユースケースのブログを増やすことでじわじわと広がりを見せてはいますが、大きく階段を駆け上がれないのが悩ましいところです。
もう一つは、ノーコードツールではあるのですが、ユーザーが一人で使いこなせる段階までまだ至っていないことです。世の中にノーコードツールがまだ普及しきっておらず、利用イメージを抱きにくいことも影響していると思います。解決したい課題がマーチャントごとの個別業務なので、利用イメージが湧くまでは都度ご相談をいただいてサポートをすることも多いです。結果としてサポート業務にリソースを多く割いているのが現状です。どう活用すれば良いのか、ユーザーが迷わないように見せる設計が必要だと思うので、試行錯誤を重ねています。
ーー SaaS だとプロダクトが自走して成長するモデルを思い描きがちですが、課題が個別化されている以上、泥臭くやっていく根気が必要という感じでしょうか。
田渕:そうですね。とはいえ、どう活用すればいいのか、ユーザーが迷わないように見せる設計はまだまだ改善の余地がたくさんあると思うので、試行錯誤を重ねています。
ーー 先ほどおっしゃっていた「他のベンダーがノートを作れる仕組み」、たくさんのステークホルダーを「TēPs(テープス)」を中心としたサイクルに巻き込めるところがすごく良いですよね。どの企業も自社で全部やろうとすると無理が出てくるから、外部をどうやって巻き込んでいくかが大事になってくる。その前提でのオープン化なのかなと思いました。
田渕:自分の本質的なところに立ち返ると、とにかく新しいものが好きなんです。新しい仕組みであったり、新しい価値であったり、そのあたりを構築していくところがとても好きで。
おそらく、普通の SaaS を作っていたらすぐ飽きてしまっていたと思います。「TēPs(テープス)」だから新しい連携先が増えるだけでそれまでとまったく違う価値と遭遇できる。常に新しい価値が作り出せるところが、自分にすごく合っているんですよね。構築が本当に楽しい。
だからこそ、現状の課題解決も、外部を巻き込んだ新しい一歩も、大変だけれども楽しんで突き進んでいきたいという気持ちが大きいです。
ーー 「作るのは楽しい」、何にも勝る回答ですね。今後の「TēPs(テープス)」の進化が楽しみで仕方ありません。本日は貴重なお話をありがとうございました!
編集後記
以前からのご縁もあり、「TēPs(テープス)」のことはある程度知っているつもりで臨みましたが、改めてコンセプトやフォーカスしている部分を詳しくお聞きでき、単なる「ノーコードツール」という言葉から連想される以上の価値の連鎖が「TēPs(テープス)」の中で起こっているのだなと理解が深まったインタビューでした!
ECはますます複雑化していて、日々のフルフィルメント業務は多様化し、チャネルは増え、油断すると業務のスキマはどんどん広がっていってしまいます。そのスキマを埋めることでオペレーションがスムーズになり、結果としてマーチャントの成長やエンドユーザーの購買体験も向上していくに違いない。。。 そんな未来が「TēPs(テープス)」を通じて拓けていくようなイメージが少しでも伝わる記事になっていればうれしいです。
参考リンク