BASE開発チームブログ

フリーミアムなネットショップ構築サービス BASE( https://thebase.in )の開発チームによるブログです。開発メンバ積極募集中! https://www.wantedly.com/companies/base/projects

DroidKaigi2018にスタッフとして参加したらいろいろとすごかった

Androidアプリエンジニアの鈴木 (G_devi) です。 今まで何回かDroidKaigiに参加はしていたのですが、今回のDroidKaigi2018は初めてスタッフとして参加させていただきました。 その中で、運営・進め方・情報管理・当日の動き・臨機応変な対応など、いろいろとすごいなーとか、このやり方いいなーとか思ったことがあったのでお伝えしたいと思います。(書ける範囲で)

すごかったこと・いいなと思ったやり方etc...

どれが一番とか選べないので順番は特に関係ないです

globalチームがある

簡単に言うと、英訳してもらいたい文をここにお願いすると分かる人が翻訳してくれる感じです。

DroidKaigiは海外からも参加者や登壇者が来ますし、グローバルな対応が必要になってくるので何にでも英語が必要となります。 登壇者とのメールのやりとり、アンケートなど全体に投げるもの、海外サービス(Sessionizeなど)への質問など英語を用いるところはたくさんあるのですが、担当している人が必ずしも英語ができるわけではありません。(自分もできません)

slackの専用のchannelで英訳できる人のグループ(@english)宛に、こんな用途でいつまでにお願いしたいという感じで投げると、誰かがシュッと英訳してくれるという初めて見たときは感動するような流れ! 何よりみんなslackを使い慣れているので引用など諸々見やすく投げるし、感謝と謝罪もキッチリしているし、緊急度と重要度をみんながある程度把握しているため流れがいい。

こんなに素晴らしい流れができてる企業とかないんじゃないか?と思ったくらいです。

こういうのほしいなーという話が出たら誰かが作り始める

多分、いろいろ作られてたとは思うけどとりあえずパッと思い出したのは一つ。 github issueのMilestoneからもうすぐ期限が来そうなものをまとめてslackに投げて教えてくれるというもの。 全体で見ると結構な数のissueが作成されてるうえ、期限遵守しなくてはいけないものもあるため非常に見やすく気づきやすく素晴らしかった。

恐らくスタッフの大半が簡単なスクリプトを書いてシュッと投げるくらいのものはそれほど手間なくできると思うので、誰かに作業が集中してしまわないのが素晴らしい。まあ、忙しい人ほど自分で作ってちゃっちゃと済ませちゃうものな気がするけども。

用語集がある

まぁ、当然ですよね? ただこれがちゃんと存在してないと認識のズレや時間のムダにつながるのであることはとても重要だと思います。 用語が増えてきてメンテできずに人によって呼び方が違うものとか増えてくる現場にいた経験をするともう。。。

リアルタイムKPT

KPTを雑に書き込めるchannelがある。

確かに、思ったことはその場ですぐに記載したほうがいいですね。 DroidKaigi本番中もちょくちょく書き込まれていて、みんな結構slackのチェック頻度が高かったりもあるので、それを見て参考にもできるしとても良かったと思いました。 今更ながら、何でよくあるKPTの集まりでは時間区切って思い出しつつ書き出すことをするのだろうと。。 あのやり方だと後でこれもあったなと思うことが結構あるんですよね。

当然ながらslackに書き込んで終わりではなく、後で別途まとめると思いますが。 担当ごとに書き込むためのissueもありますし。

当日のインカム運用

当日はスタッフ全員がインカムをつけて緊急時の案内や共有などを行っていた。 slackでいいじゃんと思っていたが、結構動き回ってるうえ一般の人よりチェック頻度が高いと言ってもやはりリアルタイム音声連絡の便利さには敵わないものがありますね。 特に参加者から質問などを受けて自分が分からないときなどは急ぐ必要があるので非常に良かったです。

正直、撤収の途中からインカムを外したら不安になるし聞きたいことあるときに不便だなと思いました。 去年は全員がつけていたわけではなかったようなので、うまく改善がされていってるんだなという印象も受けました。 ただ、どうしても聞き取りづらいというのはよくあるので、いずれgoogle glassをつけて追加でも文字でも見れるようになるといいな〜。

2段階認証

当然だがキッチリしている。 当然ながら外に出せない情報もあるので重要なところですね。 何よりまだ設定していない人に対するリマインドがしっかりしていてよかったと思います。

最新情報の重要性の理解度

みんながみんな、情報が最新であることの重要性を強く認識しているため古い情報を見てズレたことをしてしまうという状況がほぼなかったと思う。 特に、セッションの司会や補助の割り当ては当日中にもちょくちょく更新されたので全員が最新情報をきちんと確認する必要があったが、通知もしっかりしていましたが問題なくみんなチェックしていたようでスムーズでした。 あとは、マニュアル類も都度更新されたりするのでそのチェックも重要でしたがデジタル主体の人が多いとなんと楽なことかと。(やはり便利なので印刷したものもありましたが) とりあえず手軽にgoogle docsは便利ですよね。

スタッフ用アプリ

なんと、スタッフが利用するアプリも作られていたのです!

マニュアル類へのリンク、Slack起動、Twitterで#DroidKaigi検索、各自の行動予定表、各ルームの進行中・休憩中表示の切り替え、そして何よりプッシュ通知でみんなへの連絡事項が文字で送られてくるというのは便利でした。(ちなみに最後の通知は打ち上げ会場についてでしたw)

半分くらい(?)はスタッフ初参加なようなので、このようにこれを開けばなんとかなるというものがあると迷わずに便利に動けて素晴らしかったです。

各種マニュアルの完成度

各種マニュアルの完成度がハンパないです!

上にも書いたように初めての人が多いというのもありますが、とりあえずこれを見れば大体のことは迷わずできるというレベルで作成されていました。 当日のことだけでなく、準備や撤収に関してもマニュアル化されているので非常に動きやすかったです。 しかも、こういうことも必要ではないかという話が出るとすぐに更新されて通知がくるのがまた素晴らしかったです。 いろいろな面で見習いたいところ。

責任の所在が明らか

全体、そして各担当の責任者が明確で(状況によって変わったりもありますが)その人に質問すれば大体何とかなるという状況。 もちろん質問だらけにならないようにいろいろ記載されているものがあるのですが。 何か発生した際の線引(これはやる。やらないなど)がすぐに分かるというのは素晴らしかったです。 まぁ、これもエンジニアらしく反応速度が早いからうまく回ってるというのもありますが。

やばい問題が起こらないように、そして確実に間に合わせるためにきっちりと内容を把握している責任者がハンドリングしているのは素晴らしかったです。 責任者が自分の担当範囲をキッチリ把握している。できない場合でも周りがフォローできるという体制は普通なようでなかなかできてなかったりしますからね。

受付アプリまで作られている

ついに1000人規模になったDroidKaigiですが、その人数の受付を回すとなるとものすごく大変なのは目に見えている。 参加者が提示したQRコードをスタッフの受付アプリで読み取ることによってスムーズな受付が可能だった模様。 "模様"というのも、自分は受付時に別の作業をしていたので現場は見ていないもので。。。 ただ、この辺も前回の反省を踏まえて作るという流れがいいですね。 何より特別な機器を用いなくてもスマホのカメラで可能であり、そのアプリをシュッと作れる人たちというのが強い。

ミーティングはハングアウトでも参加可能

スタッフもほとんどの人が普段の仕事をしているうえで夜に集まるので、どうしても参加できない人もいる。 また遠方の人もいるので、行くことはできないけどハングアウトで参加できるというのはすごく便利。 あと、議案・議事録もしっかりしているため参加できなかったとしてもある程度はきちんと把握できるようになっていました。 (自分もいろいろあってあんまりミーティングの場に行けなかったので非常によかった)

直接会って話すというのも重要なのですが、普段テキストベースでのやり取りに慣れている人が多いのもあり、議事録のチェックでも情報格差がそれほど発生しないようになっているのは非常によかったです。 経緯はともかく結果はしっかりとどこかに明記されているので。

そして、それほど回数も時間も確保できるわけではないのでミーティングのための準備もしっかり行われており、極力無駄な時間を使わないようにしていたのが素晴らしかったです。 これも非常に見習っていきたいところです。

急遽対応すべきことが発生したときの流れが良い

1000人もの人を動かすと、予期できなかったことなどが発生し急遽対応を入れたりします。 うまく人を流すために誘導を配置する必要がでてきたなど。 その作業タイミングで手が空いていそうな人をみつけ簡単に流れを説明するだけで動けるのは非常に良かったです。 何か分からないことがあればインカムで聞けますし。 エンジニアだからとは必ずしも言えないですが、ある程度自分で考えて行動できる人が多かったように思えます。

オープニング動画がかっこいい!!!

これはしびれた (まぁ、自分は準備でウェルカムトーク出てないし終わってから見たんですが)

www.youtube.com

その他感想

ひたすらに物理作業がツライ!!!

普段座ってばかりいる自分なので、、前日の電源を机に配置してテープで足をひっかけないように留めていく作業で疲労困憊。 セッションの司会補助で立ち続けてるだけでも脚がプルプル。 撤収作業で疲労困憊。 最初のほうは緊張もあり相当疲れました。 やはり体力は必要だなーと。

朝が早い!

と言っても、8:50厳守なので一般的に見たらそんなに早くはないのですが。 自分は朝に弱すぎるうえ、疲労困憊なので本当に心配でした。。 現地が西新宿で家が池袋なので結構近いのに本気で現地近くに泊まろうかと考えていました。 けど、参加者も泊まる人多いでしょうし、そんな近くに宿泊施設が多そうに見えなかったので断念。 少し歩けばいくらでもあるだろうけどそれなら帰っても変わらないかなーと。 最終的に知り合いに電話で起こしてもらうというリスクヘッジをして何とか乗り切りました。

スタッフの顔と名前が分からない。一致しない。

自分がミーティングにあまり参加できなかったというのもありますが、当日結構みんな初めましてという感じが多かったです。 slackやtwitterのアイコンや表示名は分かるけども実際の人と結びつかないというのはよくありますよねー。 人が増えてくると会社でもそうだったりしますよねー。 とはいえ、それでもうまく回るような感じではあったのですが、やはり顔と名前が一致するとだいぶやりやすくはなると思います。 (覚えるの苦手なんですが。。。) あと、みんなほとんどslackの表示名で呼んでいるのですが、どう読むのか分からなかったりw

スタッフ打ち上げ会場に人権(ネット接続環境)がなかった…

ほぼネット前提であるAndroidのイベントスタッフの打ち上げにこの状況は驚きましたねw 地下だったのもあり電波がほぼ届かず、現地WiFiもなかったです。(あったとしてもこれだけアクティブな人が80人?くらい集まってたらパンクするでしょうが…) まだ外部と連絡とる必要のある人もいたでしょうしせめて繋がる環境だったほうがよかったのでは?とは思いました。 何より自分が欲しかった。。。w

最後に

個人的に非常に為になり、参考になり、楽しかったです。 他にも良かったと思うところはたくさんあるのですが、とりあえずパッと思いつくところを書きました。

やってみたい人や組織運営に悩んでる人なども一度スタッフとして参加してみると為になるかと思います。 元の仕事や準備など諸々で時間がなくアプリ開発のほうには関われなかったのが残念だったので、来年は多少手を付けられるといいなと思いました。

スタッフのみなさん、登壇者のみなさん、そして参加者のみなさん、ありがとうございました!!

(文字だけで寂しいのでスタッフ名札写真でも載せようと思ったら無くしてしまったようだ…泣)

PHPerKaigi 2018にプラチナスポンサーとして協賛いたします!

こんにちは、BASE株式会社 エンジニアの東口です。主にサービスの決済部分を担当しています。

この度、BASE株式会社は、PHPerKaigi 2018にプラチナスポンサーとして協賛いたします。

phperkaigi.jp

PHPerKaigi(ペチパーカイギ)は、現在PHPを使用している、過去にPHPを使用していた、これからPHPを使いたいと思っているエンジニアが、技術的なノウハウを共有するためのカンファレンス(イベント)です。 BASEは、サーバーサイドの大部分をPHPを使って構築しているため、この機会を通してPHPのコミュニティ発展に貢献できればという想いから協賛を決めました。

私自身もレビューをもらいやすい細かいプルリクの切り分け方 | PHPerKaigi 2018というタイトルで発表いたします。

カンファレンス当日は、皆様にノベルティを配布させていただいたり、弊社エンジニアも参加いたしますので、ぜひお気軽にお声掛け下さい。

イベント概要

  • 日時 2018年3月9日(金)〜3月10日(土)

  • 場所 練馬区立区民・産業プラザ Coconeriホール

  • 主催 PHPerKaigi 2018実行委員会 (実行委員長: 長谷川智希 / @tomzoh)

  • 公式HP:https://phperkaigi.jp/2018/

CakePHP Cookbook を直す方法(表示確認してからプルリクエストを出すまで)

はじめまして、2017年9月に入社したBack-End Engineer の田中です。アプリケーションが使うPHP/CakePHPのバージョンアップを担当しています。

BASE ではサーバーサイドアプリケーションの大部分がCakePHP2を使って構築されています。 日常的にCookbookやCakePHPコアのコードを読んでいて、時々typoや不具合を見つけてはプルリクエストを送っています。 PHP 7.2 でテストスイートをパスさせる修正もしたので、PHP7.2 でも動くはずです。

CakePHPユーザーの方で、ドキュメントにtypoを見つけたことはありませんか?ドキュメントへの貢献についてのページを読むと、まずはメールを送る必要があるようなことが書いてあり面倒そうに思えますが、実際のところプロジェクトがGitHubに移行してからはいきなりプルリクエストを送っても問題ないようになっています。この記事ではドキュメントをPCで修正してプルリクエストを送る方法を説明します。

この記事の内容は2018/02/08にランサーズ株式会社で開催されたCakePHPクックブックを直してみよう勉強会 - connpassで解説した内容に多少の修正を加えたものです。

CakePHP のドキュメントを直す

CakePHP Cookbook 日本語ドキュメントはボランティアベースで翻訳されています。 翻訳率はかなり高いですが、typoや読み取りづらい部分が見つかることがあります。 CookbookはGitHubでホストされているので、GitHubアカウントさえあれば、修正してプルリクエストすることができます。以下の記事をご覧ください。

こちらの方法だと、PCにリポジトリをコピーしなくてもよいので、簡単に修正依頼できますが、表示確認ができません。 マークアップやサンプルコードを含めて修正するときは、表示確認したくなります。 その場合はローカルPCで作業する必要がありますのでその方法を説明します。

目次

  • リポジトリをコピーして作業を始めるまで
  • テキストを修正してローカルビルドする
  • プルリクエストを作成する
  • 補足

リポジトリをコピーして作業を始めるまで

事前の準備としてgitインストールとSSH鍵の設定が必要です。以下の記事が参考になります。

monsat.hatenablog.com

準備が終わったら、Cookbook用のリポジトリにアクセスします。

github.com

ページ右上にあるForkボタンを押しましょう。

f:id:tenkoma:20180204033301p:plain

そうすると、自分専用のリポジトリが作成されます。

github.com

次にリポジトリをローカルPCにクローンします。 [your-name] はあなたのGitHubアカウント名に置き換えてください。

$ mkdir -p ~/src/github.com/cakephp
$ git clone git@github.com:[your-name]/docs.git ~/src/github.com/cakephp/docs

常に最新のソースファイルから作業に着手するために、オリジナルのリポジトリを upstream として登録しておきます。

$ git remote add upstream git@github.com:cakephp/docs.git

最後にDocker をインストールします。ドキュメントをビルドするために必要な環境を簡単に構築できるようになっていますので、手元のPCにインストールしてください。 Docker Storeから、お使いのPCのプラットフォーム向けインストーラをダウンロードして、インストールしてください。

https://store.docker.com/search?type=edition&offering=community

テキストを修正してローカルビルドする

まずは、手元でドキュメントをビルドして、ブラウザで確認してみましょう。以下のコマンドを実行します。

$ cd ~/src/github.com/cakephp/docs
$ docker build -t cakephp/docs .
$ docker run -it --rm -v $(pwd):/data cakephp/docs make html-ja

2行目の docker build ... でビルドに必要なツールをインストールして、3行目の docker run ... でビルドします。

生成されたWebページは build/html/ja ディレクトリ以下にあります。 build/html/ja/index.html をブラウザで開くと生成されたドキュメントを確認できます。

f:id:tenkoma:20180204044217p:plain

次にドキュメントのソースを修正します。今回はCakePHP3 Cookbook で見つけたtypoを修正してみましょう。 *1 upstream/3.0 *2 からブランチを作成します。

# オリジナルのリポジトリの状態をローカルに取得します
$ git checkout 3.0
$ git fetch upstream
$ git merge upstream/3.0
$ git checkout -b fix-ja-console
Switched to a new branch 'fix-ja-console'

ソースを開いて修正します。ドキュメントソースのreStructuredText形式に対応しているエディタを使うのがよいでしょう。以下はPhpStormでの例です。

f:id:tenkoma:20180204050908p:plain

直したらビルドします。

$ docker run -it --rm -v $(pwd):/data cakephp/docs make html-ja

2回目以降は docker build 不要です。

表示が確認できたらコミットします。英語である必要がありますが、typoなら 「Fix typo」でOKです。

$ git commit -am '[ja]Fix typo'

プルリクエストを作成する

あとは、ブランチをプッシュして、プルリクエストをつくるだけです。

$ git push origin fix-ja-console

cakephp/docs: CakePHP CookBookを開くとプッシュしたブランチが表示されるので「Compare & pull request」を押し、「Create pull request」を押すとプルリクエストが作られます。 *3

f:id:tenkoma:20180204054530p:plain

github.com

あとはマージしてもらえるのを待ちましょう。

補足

日本語以外の版もビルドしたい場合は以下のコマンドを実行します。

# 英語
$ docker run -it --rm -v $(pwd):/data cakephp/docs make html-en

# すべての言語
$ docker run -it --rm -v $(pwd):/data cakephp/docs make html

エンジニア募集

BASEではECプラットフォームを一緒に作ったりCakePHPにコントリビュートしたいエンジニアを募集しています!

*1:typo程度ならローカル作業不要ですが、修正箇所を見つけてないので…

*2:3系の最新版のドキュメントでも 3.0 ブランチを更新していきます

*3:2コミット以上のプルリクエストだと、プルリクエストのデフォルトタイトルがブランチ名になってしまうので、「[ja]Fix typo」などに変更しておきます

デブサミ2018において「BASE社におけるフィンテックへの取り組み」というタイトルでお話させていただきます

CTOの藤川です。今回、デブサミにお誘いいただいて登壇させていただくことなりました。

初日 2/15の13:05~13:50の回でE会場とのことです。

BASE社におけるフィンテックへの取り組み

今回お話しようと思ってるプレゼンテーションに類するお話に、以前、情報処理学会の学会誌にフィンテックについての寄稿をさせていただいたことがあります。

フィンテック:3.フィンテックスタートアップのビジネスモデルFintech:3. Business Model of Fintech

こちらではさすがに自社の自慢話をするのは難しかったので、freeeさん、マネーフォワードさんのアカウントアグリゲーションのビジネスから始まり、何が重要か?という部分でメルカリさんの事例を挙げさせていただきました。

まだ、当時はメルカリとフィンテックの繋がりというのはあまり着目されていなかったタイミングでの寄稿だったと思っています。

メルカリさんの例で書いていたのは、要はポイント経済圏のことなわけですが、フィンテックと呼ばれるサービスは、Webサービスを通じなんらかしらの経済合理性や集客力を金融事業に結びつけていく試みですので、その部分を抽象化して、沢山の方々のビジネスに対する共感をいただくことは可能だと思います。

なので、そこについては聴講者の方々には、絶対に損をさせないようにしますってのがまず大前提として。

(我ながらタイトルがいまいちでしたね。BASEのPRみたいなタイトルにしてしまったし、何か特別なことをやってるようなタイトルにしてしまった。それでもお申込みが満員のようで感謝です。)

もう一つは、確かにBASEのPR面の野望はありまして、採用面接をしている時に、無料ECのプラットフォーム事業者という認識はあっても、フィンテック企業だという認知はほとんど得ておらず、しっかり面接でお話することで、我々の狙いを理解いただくことで会社に興味を持っていただくということが多いです。

逆を言えば、1時間、話をしなければ、我々の魅力を知っていただけてないということになり、それでは転職市場に対しても強烈な機会損失をしていると考えられます。

その部分の認知を変えたいというのもあります。

無料EC自体は、これまで沢山の会社がやってきていますし、ショッピングカートのUIのパラダイムもずっと変わっていないし、敵と思わしき企業はビジネスが完成された会社ばかりで、ある意味、ECプラットフォーム市場はコモディティ化していいると言っても過言でないでしょう。

なのに何故、今更ECなの?となるわけですよね。

わかります。

SNSやゲームなどのネットワーク性が前面に出ているサービスと比べても、ただのツールという感覚が強いのかなと思います。そもそも決済やEC業界が好きだという人でなければ、あまり魅力的なサービスのように見えない部分もあります。

一方でEC業界の玄人のおじさん達に言わせると「こんなビジネススキームで儲かるわけがない」となるわけです。

BASEのサービスデザインにおいて、無料ECという仕組みは情報発信プラットフォームの一つであり、BASEという名前からもなんとなく感じ取れるかもしれないですが、インターネット的な世界を作りたいという社会変革を目指したグランドデザインの方にビジネスとしての主眼があります。

会社としての理念が、「価値の交換をシンプルに。世界中の人々が最適な経済活動を行える社会へ」という抽象概念で語られているのは、そこにポイントがあります。

何故、BASEは無料でいいのか?という部分にこそ、他社の有料サービスが考えているビジネスモデルとは違う思想が存在しており、それこそがフィンテック企業として注目いただいている肝になっております。

僕が面接で使うメタファは、銀行で通帳を作る時の「口座維持手数料」って無料ですよね?それ単体だと銀行だって赤字ですよね?BASEも同じなんですよ、というところなんですが、当然我々は銀行ではないのですから、Webサービス企業としての「BASE」がビジネスとして成立するための世界観を、どううまく伝えられるか、そんなあたりにチャレンジしていきたいと思います。(書いててプレッシャーが...)

要は、フィンテックベンチャーの肝は「ただの家計簿アプリ」「ただのフリマアプリ」「ただのネットショップ構築サービス」「ただの決済サービス」ではないんですよ!、、、、ってところなんで、その辺の整理をしていけたらいいし、そのプレゼンテーションを通じて、フィンテックへの魅力を伝えられて、聴講者の方のビジネスにメリットを提供できれば幸いです。

あ、HRの方で採用ページを作ったそうなので、是非見てみてください! jobs.binc.jp

BASEを利用し、皆様のWebサービスに商品販売機能を追加する方法

BASEと連携し、皆様が運営されているWebサービスに商品を販売する機能を追加したい!であるとか、Webサービスのユーザーに簡単に商品を販売する提供し、購入連携を実現したい!というご相談をいただくことがあります。

そのような連携をするメリットとしましては、

  1. 商品販売に関するあれこれを実装、維持、管理しなくてもよい。特にセキュリティ管理周りを外注したい!
  2. 販売機能がコア機能ではないからプラスアルファの価値を提供したい
  3. お金の支払い周りや購入トラブルに関する問い合わせ等が煩雑すぎるから、そこをBASEに外注したい
  4. クレジットカード決済やキャリア決済などを提供したい

などなど、BASEを活用するメリットがそのまま、皆様のWebサービスに組み込めることが考えられます。

このような取り組みに対する一つのご提案をさせていただけたらと思います。

BASEには、ネットショップに慣れてきたオーナー様が、あれをやりたい、これをやりたいというニーズにお応えするための機能拡張「BASE APPS」というものがあります。

その中に「広告効果測定」という機能があります。このAPPSを使うと、購入者様が商品を購入する際の購入完了画面で、任意のタグ、JavaScriptを実行する機能を提供することができます。

いささか裏技的ではありますが、この機能を流用し、Webサービスとの購入連携を実現しようというのがこの記事の趣旨となります。

購入フローは、こちらになります。

f:id:f-shin:20180119152616p:plain

  1. Webサービスは登録済み商品のページURLを通じてBASEショップにリダイレクトする(別窓が良い気がします)
  2. 商品の購入完了ページで、Webサービスに購入完了通知を送る。
  3. Webサービスは通知を元に、BASE APIに購入情報を問い合わせて、サービスを提供する

というフローです。

材料としては、

  1. 皆様のWebサービス
  2. BASEのショップ管理画面内にある「広告効果測定」APPS
  3. BASE API

の組み合わせになります。

■広告効果測定APPS

広告効果測定APPSは、BASEのショップ管理画面からご利用いただけます。

f:id:f-shin:20180119143544p:plain

f:id:f-shin:20180119144623p:plain BASEの商品購入の完了画面に、ここに書いた任意のHTML / JavaScriptが出力されます。iframe内に出力されるのでWebページ経由のWebhookとして皆様のサービスに通知を送ることができます。

購入完了画面のページのURLには、ショップのIDが入っているのでリファラーもしくはJavaScriptでパースすることで、どのお店からのリクエストかも判別可能です。

(なお、購入画面のURLはどこかのタイミングで変わる可能性がありますので、その際は、下記のdevelopers登録のアドレス宛に一ヶ月前ぐらいには、連絡いたします)

■BASE APIを使うためには

プラットフォーム様がBASE Developersからアカウント申請をお願いします。

f:id:f-shin:20180119145027p:plain

developers.thebase.in

BASE APIの利用申請が承認された後、BASEが提供するOAuthログインのコードを書くと、皆様の管理画面から商品を売りたいユーザさんに対して、BASEショップとの連携機能を追加することができます。

ユーザさんからOAuthを通じてBASEショップのアクセス権が移譲されることで、

  • 商品登録 / 削除 / 在庫数の変更
  • 購入者情報の取得

などができるようになります。これらの処理を自動化することで、商品購入と連携して購入者様にサービスを提供することができるようになります。

(そのため、商品を売りたいユーザさんには予めBASEショップを開設いただくことが必要です)

■本機能実現についての検討事項

以上のようにシステム連携自体は簡単にできますが、いくつか検討すべき事項があります。

f:id:f-shin:20180119150546p:plain

エンジニアをかかえるWebサービス様が販売責任を負う形で商品を販売されるのであれば簡単です。

それに対して、皆様のユーザーにこの機能を提供しようとすると、誰が何をするか?という部分が少し煩雑になります。

検討部分として、整理すべきポイントは以下のようになります。

BASEアカウント保有者 = ショップオーナーさんの責任
- 特商法の記載(販売主体 / 返品責任は誰が追うか?)
- お金の流れ(BASEから振り込むので済むなら簡単だけど...)
- 購入者情報の管理(個人情報管理)

システム連携に必要な作業
- 広告測定appsの設定
- 連携タグの設置

API連携して、サービス提供に必要な機能
- 商品の登録、削除、更新
- 購入者情報の取得

その他 APIのドキュメント

本文章の内容としては以上になります。 今後、より高いニーズに応じて機能追加も検討していこうと思っておりますが、ひとまずこちらをご検討くださいませ。