「Shopify Functionsでできること」について、リワイアのエンジニア3名でざっくばらんに話し合いました。
後編となる今回は、Shopify Functionsの今後と課題感を中心に、意見を交わしています。
株式会社リワイア代表取締役、今回のインタビュアー
株式会社リワイア エンジニア（主にチェックアウト拡張アプリ「あとプラ」担当）
株式会社リワイア エンジニア（主にポイントアプリ「どこポイ」担当）
今、気になっているFunctions API
Hide：定期的にAPIが増えてる印象なんですが、今後もどんどん増えていくのでしょうか？
Kaneda：ここ半年くらいの間だと、Cart Transform APIは結構耳にしますね。
Hide：Cart Transform APIはカートの中身を変えるAPIですね。カートに商品を追加したり、削除したり、数量を変えたり、といったことを実現します。「特定の商品を入れたらギフト商品が追加される」など、チェックアウト側での追加購入と違って、よりルールベースでの調整ができそうですね。
Shinya：僕の方はDiscounts Allocator Function APIが気になっていますね（※本記事編集時点ではDeveloper Preview）。これはShopifyが適用するディスカウントの優先順位を変更できる機能なんです。例えば、通常ディスカウントは一番割引率が高いものからの使用が強制されるのですが、「（ポイントアプリ導入済みのストアで）必ずポイント利用の割引を優先する」といったロジックに変更することも可能となります。
Hide：なるほど、確かに。「必ずポイントで割引してから他のクーポンを適用させたい」や、「ポイント適用時に無料配送ラインを下回った場合でも無料配送にする」などのニーズはありそうですね！
Functionsに感じる課題感
Hide：かなりShopifyのコアのロジックをいじれるということもあって、個人的にはものすごく興味を抱いているものの、世間的にはFunctionsの広がり自体はまだまだそこまでじゃないなと思ってるんです。これって何が課題なのでしょう？そもそもの話、情報が少ないから……？
Shinya：基本的にFunctionsは「設計」が難しいですよね。例えば今後リリース予定の「Order Routing Location Rule Function API（※編集時点ではDeveloper Preview）」は注文のロケーションのルールを変更できるAPIで、とても使い勝手の良い印象ですが、具体的な運用方法が理解できていないと先に進めません。「このAPIを使って何をすればいいのかすら分からない」状態になっている人が多いのではないでしょうか。
まずは簡単なAPIから慣れていくしかないのかな、と。
Hide：Functionsは画面などがある訳ではないので、実装自体はシンプルなはずですよね。「○○を△▼する」みたいな。だからこそ設計が重要になってくるのかな。
これってもしかして、今後たくさんのFunctionsが入るようになったら、「処理Aと処理Bがバッティングする」みたいなことが起きたりしませんか？例えば、とあるアプリが決済情報を書き換えて、また別のアプリが書き換えて、みたいなことが発生したらどうなるんでしょう……？
Kaneda：非表示にしたものはバッティングしても消えるだけなので問題ないですが、Updateをかけるような処理は、確かに設計次第で予期せぬ結果を招きそうですね。
Hide：マーチャント側の視点では、どのFunction APIがどの順番で動いているかは理解しにくいはず。一応管理画面には表示されますが、最終的にどのような処理の組み合わせになっているのかは分かりませんよね。
Hide：アプリを複数入れた場合と同様に、マーチャントの担当者や制作パートナーが、どこまでちゃんと手綱を握れているかが大事になってくるのではないでしょうか。例えばアプリでタグを管理する際に、複数のアプリがタグをコントロールしたり、Shopify Flowが干渉してきたりするなど、「タイミングや組み合わせによって動かなくなるケースがある」みたいな話をよく聞きますが、Functionsも同じようなことが起きる可能性があるような……。
Shinya：その通りだと思います。我々はアプリベンダーではありますが、アプリと同様にFunctionsも必要最低限の導入に留める、「可能な限り入れない方がベター」ということが鉄則になる気がしています。そして改めて、制作パートナー側は「設計」の力がないとサポートが難しい状況ですね。管理画面もアプリもFlowもFunctionsも、全部見て対応する必要が出てきているので。
Hide：確かに。あとは「過去に構築したもののメンテナンスをどうするか」問題でしょうか。Script Editorの場合は、過去に制作した担当者がいなくなっても、最悪コードさえ読み解けさえすれば、何とか対応ができました。一方でFunctionsの場合は、情報はアプリでまとめられているので……。
Shinya：まさしくその状態になると、制作した本人しかその中身が分からなくなってしまい、後に修正が必要となっても「対応ができない」という事態に陥る可能性が出てきます。機能ごとに別々のパートナーが入っている場合は、かなり危険でしょうね。コードも実行結果も、それぞれ提供するパートナーしか理解できないことで、更新時に「新しく作り直すしかない……」といった最悪のケースを選ばざるを得なくなります。
まとめ
Hide：ここまで結構たくさん話してきましたが、話し損ねていることはありますか？
Shinya：どうしてもAPIとしてはバージョンが存在するので、定期的なAPIのメンテナンスやアップデートは必要、というところですね。「急にバージョンが古くて動かなくなる」みたいなことが発生しそうなので。
Kaneda：Cart Transform APIでカートの中身を変更することができるので、その辺はより活用法を考えていきたいな、と感じています。Checkout UI Extensionと同じような実装になる部分はあるのですが、Shopify Plusじゃなくても利用できるところはメリットが大きそうです。
Hide：これまでのカートでのアプリ実装による購入制限など、「カートの中身を変更する」ことは外部アプリの影響を結構受けたりしていたので、Functions利用で「正規ルート」で顧客のUXを損なわずに対応できるのは魅力ですよね。B2B、B2Cどちらでも利用は広がりそうだと思っています。
まだまだ話し足りない部分もありますが、今後は実際に実装してみた時の話なども含めて、もっと検証していきたいですね。今回はありがとうございました。
