EC業務の「スキマ」を埋めて、ショップの「ありがとう」を増やしたい〜 テープス株式会社 田渕健悟 #State-Of-Commerce Vol.13

田渕：ありがとうございます。「TēPs（テープス）」構築の背景はいくつかあるんですが、一番大きい動機は、ECの現場の作業にあたるものの「本当の意味での自動化」を実現したいという気持ちでした。

ご存知のとおり、ECって本当にやるべきことが多いです。それらに忙殺されずにマーチャントが本当に力を入れるべき商品開発やマーケティングに時間をさけるように、日々の作業が楽になるお手伝いができたら、と思ったのがきっかけになりますね。

田渕：元々WEB業界でキャリアを築いてきたのですが、2008年に「WEBの匠」という屋号で会社をスタートさせました（現：シッピーノ株式会社）。この命名は、某リフォーム番組で、その道の “匠” が人々の生活をバージョンアップさせるというコンセプトが好きで、あやかりました。「お客さまそれぞれのお悩みにフィッティングする価値をあたえたい」という思いからです。

駆け出しのころは技術的なサポートからコンサルタントまで、何でもやっていました。中小企業と向き合うことが多かったのですが、ビジネスの規模がそれほど大きくなければ、何か一つがヒットすると状況が何倍にも変化します。

田渕：はい、めちゃくちゃ喜んでもらえます（笑）。そこが一番のやりがいだったんです。

でも、少しずつ事業拡大していくほどご予算の確保がネックになってきます。困っている会社ほどご予算がないけれど、こちらも安く請け負ってしまうと品質が担保できない。そのはざまでジレンマに陥りました。

そこで多くの方にご利用いただくために受託開発から SaaS にシフトしたのですが、受託のときのような「大きなありがとう」と出会えなくなって物足りなさを感じるようになってしまいまして……。

田渕：はい、特に困りごとの多い中小企業の場合、それぞれが手作業でやっていることが膨大で、そこを解決したい……となると、どうしても受託開発のほうが向いていることが多いんですよね。

SaaS はたしかに便利なのですが、SaaS に業務をすべて合わせると、どの会社もオペレーションで差別化ができません。EC各社は「他と違うことをする」というインセンティブがあるので、がんばればがんばるほどオリジナルの業務が増えていきますから。

田渕：そうなんです。業務の「スキマ」は必ず生まれるので、SaaS の導入だけでは残念ながら根本解決にはなりません。むしろ複数のチャネルや SaaS があるゆえにスキマが広がっているとも言えます。

そこで行き着いたのが、「ノーコードでスキマを埋めることで業務最適化を実現するツール」の構想でした。受託開発で細かく実現しているようなことを、エンジニアじゃなくてもできるような仕組みがあれば、SaaS の「スキマ」をフォローできるはず、という思いで開発をスタートしました。

田渕：もう少しだけ説明させていただくと、業務改善を目指していることは事実なのですが、実際に取り組んでいることは「業務改善」とは少しニュアンスが違っていて、先ほどから出ているキーワードの「スキマ」を埋める作業だなと感じています。業務一つひとつはツールによって最適化されているので、その一つひとつの業務と業務のスキマを埋めていくというのが表現として近いのかなと思っています。

例えば、商品情報などのデータを移動させるときはプラットフォームに合わせた変換が必要ですよね。CSV のカラムが A と B とで違う、みたいな。「システムとシステムの間でデータを移動させる」といった仕事ってどちらのシステムの公式サポートも得られない領域で、結果的に手作業になりがちな「スキマ」になっているんです。

田渕：まさにそうです。なので、業務全体の改善というよりも「スキマ」だらけの部分をいかに効率化していくかというところにフォーカスしようと思いました。

田渕：そうですね、根本には、たくさんの EC の現場に訪問して朝から晩まで張り付かせてもらって、この目で確認させていただいた経験があると思っています。どういうファイルを使って、どのような入力作業をしているのか、Excel だったらどのセルに何を入れているのか、というところまで。隅々まで見れば見るほど、スクラッチで解決しなくては……という思いが大きくなりました。

田渕：はい、そう考えています。連携先が増えるほどユーザーの利便性が向上する仕組みになっていますね。現在は楽天市場や Amazon 、ネクストエンジンといったサービスとの連携が実現できています。2022年7月からは Shopify とも連携を開始しました。

田渕：基本的にはそのとおりなのですが、連携するサービスの拡大と併せて、それぞれのサービス内での「やれること」を同時に増やしていくことが重要だと考えています。

サービスとサービスの「間」以外にも、サービスの「内側」にもたくさんの手作業による負担があるので、ここにメスを入れないと全体の利便性が上がりません。「TēPs（テープス）」はそれぞれのサービスごとに作業内容を細分化した「ノート」と呼ばれるテンプレートを用意しているのですが、このノートが解決する「内側」のバリエーションを増やすことで、「間」との掛け合わせで指数関数的にできることを拡大したい、と考えています。

田渕：おっしゃるとおりです。たとえば API の仕様どおりにノートを作っていけば、開発のスピード自体は上がります。でも、それだと現場の実作業で発生する「スキマ」を埋めることには必ずしもつながらない。どのサービスでも必ずと言っていいほど仕様外の追加作業が発生してしまっているんです。だから「TēPs（テープス）」は、敢えて連携先の仕様書どおりには作っておらず、一手間加えて実業務に合うようなノートになるように作っています。

田渕：たとえば、楽天市場はセールに合わせて一気に商品情報を変更する必要があります。しかも、セールは日付が変わるとともに始まるので、作業が求められる時間は深夜帯。これを手作業で全部……となると、なかなか大変ですよね。スプレッドシートを活用して変更する時間をセットし作業を自動化するだけで、大幅に負担が軽減できます。

田渕：はい、EC だけではなく実店舗でも展開しているお店も多いので、みなさん結構な頻度でダウンロードとアップロードを繰り返されています。なので、こういったユースケースの発信を通じて、Excel やスプレッドシートも含めた現場が管理しやすいデータ運用を提案していければな、と思っています。

田渕：実は、ノート自体を外部のベンダーが開発できる仕組みを作ることができれば、と考えているところなんです。

我々以外のアプローチが入ることで活用にさらなる広がりが期待できますし、その開発者がサービス提供者ならば、一つノートを追加するだけで「TēPs（テープス）」へ新たなサービス連携ができるようにもなるはずです。

API を提供するのかどうかも含め、実現の方法についてはまだ検討中ではありますが。

田渕：Amazonのベンダーセントラルや、「卸の情報を基幹システムに連携したい」といったご要望は頻繁にいただいてまして。こういう表に出てきにくい連携も「TēPs（テープス）」で担保していきたいと考えています。

田渕：カートシステムに連携したのは、実は Shopify が初めてなんです。これまではモールが中心だったので。

Shopify でストアを持とうとするユーザーさん、どんどん増えていますね。既存のカートシステムともまったく違う思想でできていて「今後間違いなく伸びる」という感触があったので、Shopify はカート連携の第一候補でした。

外部のベンダーがアプリ開発をして機能拡張できるのも、必要なものをつなぎ合わせてかたちを作る考え方も、「TēPs（テープス）」にぴったりはまると考えています。

田渕：そうですね。ただ、物流側では Shopify の注文を取り込めても、逆の機構が Shopify 側にない、といったケースはあるので、だからこそ「TēPs（テープス）」でスキマを埋める仕事があるなと考えています。ほかにも細かく発生するイレギュラーはたくさんあると思うので、Shopify で使えるノートを増やして利便性を向上するのがミッションです。

田渕：そうなんです。だからニッチな業務はサービス化されないんですよね。

改善してほしいという要望に対して、その母数が少ないとベンダーやプラットフォームから手を差しのべてもらえないことが大半です。開発されないから、事業者は泣き寝入りして手作業でやらなくてはならない。しつこいですが、ここを「TēPs（テープス）」でカバーしていきたいんです。

田渕：　「注文のキャンセル」のような一言で表現できる作業でも、実際はそれがどのプラットフォームなのか、クレジットカードなのか代引きなのか、複数の商品のうち一部のキャンセルなのか、その場合のポイントやクーポンはどうするのか、といった付帯業務の幅はショップによって違いますね。だから名前がついていない自社固有の業務はとても多いです。

田渕：ありがとうございます（笑）。そういう細かなところも救えるように、ユースケースのブログを頻度を高く更新するようにしています。色々なパターンがあるので、ここで言葉を尽くすことで誰かに発見してもらって、問題の解決につながるとよいなという願いを込めて書いています。

一つひとつの記事のトラフィックはそれほど多くはないですが、確実に困っている人につながっている感触はつかんでいます。最近はベンダーさんやコンサルティング会社さんから「TēPs（テープス）」を紹介してくれることも増えました。ユーザーがそういったサービス会社に問い合わせることが多々あるのですが、その時に「その作業はTēPs（テープス）で解決できるよ」と言っていただける。この流れもとてもありがたいですね。

田渕：課題はもちろんたくさんあります（笑）。大きく分けると2つありまして、まずは先ほど触れていただいところと近いですが、「TēPs（テープス）」の解決する問題がニッチすぎて、知っていただくための活動がむずかしいことです。要するに集客の難易度が高い。地道にユースケースのブログを増やすことでじわじわと広がりを見せてはいますが、大きく階段を駆け上がれないのが悩ましいところです。

もう一つは、ノーコードツールではあるのですが、ユーザーが一人で使いこなせる段階までまだ至っていないことです。世の中にノーコードツールがまだ普及しきっておらず、利用イメージを抱きにくいことも影響していると思います。解決したい課題がマーチャントごとの個別業務なので、利用イメージが湧くまでは都度ご相談をいただいてサポートをすることも多いです。結果としてサポート業務にリソースを多く割いているのが現状です。どう活用すれば良いのか、ユーザーが迷わないように見せる設計が必要だと思うので、試行錯誤を重ねています。

田渕：そうですね。とはいえ、どう活用すればいいのか、ユーザーが迷わないように見せる設計はまだまだ改善の余地がたくさんあると思うので、試行錯誤を重ねています。

田渕：自分の本質的なところに立ち返ると、とにかく新しいものが好きなんです。新しい仕組みであったり、新しい価値であったり、そのあたりを構築していくところがとても好きで。

おそらく、普通の SaaS を作っていたらすぐ飽きてしまっていたと思います。「TēPs（テープス）」だから新しい連携先が増えるだけでそれまでとまったく違う価値と遭遇できる。常に新しい価値が作り出せるところが、自分にすごく合っているんですよね。構築が本当に楽しい。

だからこそ、現状の課題解決も、外部を巻き込んだ新しい一歩も、大変だけれども楽しんで突き進んでいきたいという気持ちが大きいです。