『エンジニアのためのShopify開発バイブル』出版記念オンラインイベントの書き起こし

加藤：Shopifyのアプリの開発、普段は公式の英語のドキュメントを頼らざるを得なくて、日本語ではあまり情報がないのが現状です。少し開発にまつわる本など出てきてはいますが、アプリや開発のところについて、ステップバイステップで最初のところからサポートできる入門書があったらいいよね、というところから企画がスタートしています。なので、初めてShopifyのストアを構築する方とか、これからアプリを作りたい方、カスタムストアフロントをReactで書くことを勉強しようと思っている方などにも読んでもらえることを想定しています。公式のドキュメントももちろん大事なんですが、それに加えてShopify導入の最初の一冊として手に取っていただければと。

加藤：そうですね、ストアフロントですとか、実際に開発してみた部分もありますし、API や環境構築といった部分も丁寧に書きました。Shopify の開発に興味のあるデザイナーさんにも読んでいただけるとうれしいですね。

大道：担当したのは、2章の「開発を始める前の環境構築」です。具体的に言うと、API をたたくときに有用な GraphiQL（グラフィクル）という Shopify の開発用アプリがあるんですが、その説明を丁寧に書いています。操作方法を知らないと分からないままになってしまいそうなツールだったので、Shopify で初めて GraphQL（グラフキューエル）を触る方に向けて詳しく説明しました。

大道：あとは、日本語の情報でアクセスすることについても記述しています。Shopify はドキュメントが充実しているんですが、公式のものは英語で提供されているんですね。Shopify のブログも英語版が先にあって、そのあと翻訳されて日本語版が出てきたりします。こういう事情を知らないと意外と知らないままで過ぎてしまうことがあるので、追加で書きました。

小飼：私は 6章、7章のカスタムストアフロントに関連する部分を担当しました。先ほど大道さんが言ったとおり、Shopify はドキュメントがすごく豊富で、かつ英語ですので、開発するにあたり避けて通ることはできないんですね。この本ではそのための下準備といいますか、用語の技術的な意味もそうですし、Shopify の文脈で用語をとらえて理解しやすくすることを意識して書いたつもりです。

小飼：あとカスタムストアフロントは国内だとまだ事例がそこまで多くないので、Slack で海外のコミュニティの方に「良い例ないですか」と取材したものも載せているので、よかったら読んでみてください。

長岡：私は 3章の Shopify のデータ構造についてと、10章の一部を担当しました。3章については、Shopify の公式のドキュメントにもデータ構造の記載はあるものの、すべて完璧に読み解くのは正直難しいので、概要を噛み砕いて説明しています。

Shopifyのデータを扱う方法として REST API、GraphQL があるんですけれど、この本では GraphQL での扱い方について重点的に説明しています。GraphQL は自分も最初は慣れなくて苦労した記憶があるので、同じ環境の方のサポートになれば幸いです。ここがマスターできれば、あとは Shopify のドキュメントとにらめっこしながらで、ある程度開発を進められるようになるんじゃないかなと思っています。

長岡：もう一点、10章の方は、ストアフロントで使われる App Proxy を利用して、ログイン中のカスタマーからのリクエストを判断する、という内容について書きました。（※こちらの記事も参照）ソーシャルPLUSでリリースしているアプリ「CRM PLUS on LINE」の核となる機能で、弊社の佐藤も頭を抱えながら苦労して実装した部分になります。

ただ、もうすぐ Shopify の公式が、App Proxy を使ってログインしているカスタマーを判別できる機能をリリースするらしい(※)ので、おそらくこの記事で書いたことはもう少ししたら使えなくなってしまうようなので……ちょっと残念ではあるのですが、「昔はこんなことがあったんだな～」とあった事実を読み物として楽しんでいただけたらと思います。

佐藤：どうも、頭を抱えていた佐藤です。私は 8章と 9章、あと巻末で 2つほど記事を書いています。8章、9章は Shopifyアプリの開発に関する話が中心になっていて、8章はその前提となる知識を埋めていく内容で、9章は実際にハンズオン形式でサンプルアプリを作ってみましょう、という内容になっています。

佐藤：こだわりポイントは、8章に Shopify のアプリをインストールするときの OAuth のフローの部分です。弊社のソーシャルPLUS がその OAuth を扱っていることもあり、認証フローにはもともと興味があったので、書いてて楽しかったですね。認証・認可周りは仕様が複雑なので、英語のドキュメントに慣れない中で進めている時期に自分が引っかかった箇所などはしっかり補足したつもりです。解説は丁寧にしたつもりですので、Shopify の仕様についてしっかり知りたい方には良い情報が書けているんじゃないかなと思います。

9章では実際にアプリを作るんですけど、アプリの開発環境を作るところから、コードを書いて、Shopify にアップロードするところまで、一通り入っています。この章で Shopify アプリ開発の一から十までを通して体験できるように意識して書いてますので、初めてアプリ開発する方にも読んでいただけたら嬉しいかな。Shopify のアプリはバージョンアップが非常に早いので、もしかしたら読んでいただいているときにはサンプルコードそのままだとバージョンによっては動かないかもしれませんが、一応動いた状態のものは GitHub でソースコードを公開しているので、確認してもらえればと思います。

最後に、巻末に執筆した Shopifyアプリの公開のための審査のフローについてを、自分の体験を交えて書かせていただきました。案外、生の声ってネット上に落ちていないので、既にアプリ作ったけど審査が通らないって方にも、参考にしていただけるんじゃないかなと思っています。

加藤：私は 4章と 5章、テーマのところについてお話をしています。Shopify の機能の強みのひとつに、オンラインストアを構築する「テーマ」という仕組みがあります。テーマは Lliquid というプログラミングのコードで書かれていますが、テーマエディタというノーコードで編集できる画面があり、そこと連携できる仕組みがついているんですね。以前執筆した『いちばんやさしいShopifyの教本』という本では「どういう風にECサイトを作るか」という部分について焦点を定めて説明したんですが、本書はサイトを作るためのテーマ自体をどうやって作るか、というところにフォーカスを置きました。

冒頭で「デザイナーさんにも読んでほしい」という話をしましたが、Shopify でサイトを構築して、例えばアプリと連動させたりとか、元々あるテーマからカスタマイズを加えていくという過程で、どうしてもコードを触ることが避けられない場面があります。そういう時に参考にしていただけるよう、どこから始めていけばいいのか、どういうオブジェクトが動いていて、それを表示させるものをどうやって連動させていくのか、という説明しています。文量としては少ないですが、サイトのデザインや機能を、実際に運用する人が触る部分をどう実装するか、について書かせてもらっていますので、テーマを触ったことがない方にも読んでいただけたらうれしいです。

書いている途中でバージョンアップがかかって、「この検証いつ終わるんだろう」みたいなことが続いて、大変ではありました。。。ですが、開発バイブルとして、Shopifyのコアな部分をきちんと解説できたかなと思っています。

佐藤：過去の経験と比べると、作りやすいなと感じています。インターフェイスであったり、制約などを見ていくと「おそらくこうなるだろうな」という予想のとおりに進むことが多く、期待通りになるというか、理にかなっていると言いますか。変な引っ掛かりが基本的なところにはほとんどないので、作りやすいと思いますね。

佐藤：どういう意図で読むかで変わると思うのですが、多少は触ったことがあった方が良いかもしれません。開発することに比重を置いているので、エンジニア向けではあるかもしれないですね。

小飼：Shopifyアプリって、実態としては普通のWebアプリなんです。Webアプリの上に Shopify のAPI を使ったりとか、インストールといった挙動が被さってくる感じなので、もし読んでみて「手も足も出ないぞ」と感じるときは、「これはWebアプリである」というところに立ち返って分解して考えてもらえると、スムーズに理解が進むのではないかと思います。

加藤：API そのものというよりは、Shopify をまったく触ったことがない状態のほうが大変かもしれないですね。オブジェクトの概念が分からなかったり、「フルフィルメントって何？」みたいな感じだと、なかなか理解が難しいとは思います。

大道：保守的なリソースボリューム……どれくらいの日数がかかるか、というイメージですかね。

大道：なるほど。私もつい最近、開発に携わっている Omni Hub のバージョンアップを担当しました。レビューは別の人にやってもらいましたが、基本は1人で、調査を含めて1週間と少しくらいかかった気がします。バージョンアップに関して言うと、Shopify はチェンジログというか、差分をドキュメントでかなり丁寧に書いてくれています。あと、GraphQL の変更に関してはそのスキーマ自体が変わるので、どこが変更になったかは分かりやすく、アップデートはしやすいかなと思います。

ただ、コード変更よりそのあとの動作確認周りに時間が必要です。総合して、個人的にはリソースがかかるという印象はそこまでなかったです。

大道：前回はそうですね。

大道：そこまでないですかね。普通に開発していると、それこそフレームワークのバージョンアップとか、プログラミング言語自体のバージョンアップとかがあると思うので、それと同じような感じです。

大道：そうですね。でもやっぱりドキュメントが読みやすく書かれているので、内容の把握という意味では、かなりしやすいと思います。

加藤：これは良い質問ですね。

佐藤：アプリがサポートする範囲がどの程度なのかによっても違いますが、一番はやはり、申請する相手も人間なので、コミュニケーションをいかに上手くやるか、円滑にやるか、というところでしょうか。

おそらくですが、レビュー担当の方ってたくさんのアプリを同時に見ていて、一個一個のメールを読み飛ばしている可能性もあるのかな、と思うんですよね。メールには書いてあるはずだけど、読み飛ばされているから話がちぐはぐになっている……ということもあるはず。なので、どこまで伝わっているのか、きっちり確認しながら、箇条書きでくる質問を一個一個つぶしていくのが大事かなと思います。

佐藤：そうなんですよ。あと一番困ったのは、添付ファイルのリンクが開けなかったこと。

加藤：そんなことあるんですね！

佐藤：あるんですよ。Google Drive とかに公開していても「開かない」と言われたりして。結局、原因が分からなくて同じことを毎回説明するしかないんですが。。。

あと、勘違いというか、知らずに Shopify の規約に違反している状態、こちらが間違って解釈した状態で実装しちゃうと、審査はすぐ戻されるので、そういうやらかしをしないというのも大事ですね。

小飼：僕、多分フィードフォースグループで一番最初に Shopifyアプリの申請をしたんです。その時は実験的に LINE と Shopify をつなぐアプリを作ったんですが、ご存知のとおり LINE は日本をはじめ東アジアでのシェアがとても大きいです。審査担当の方っておそらくカナダ本社なんだと思いますが、そもそも LINE をご存知ない、もちろん使ったこともない、アカウントも作れない、そういうところからのスタートなんです。その辺りをぼんやりしたまま進めたら、はまりこんで何往復もすることになってしまいました。

そういうローカルに起因する問題、日本とカナダの事情の違いとかであれば、イメージしやすい動画をおいて「アプリは今回用意できないけれど、これを見て確認してね」とか、「確認用にアカウントを用意したから、これを使って」とか、そういう配慮をして渡してあげた方が良かったなと思いましたね。

加藤：審査側に同じ環境を作れないって、はまりポイントだったりしますよね。リワイアもアプリを申請するときに、もちろん手順は全部英語で書くんですけど、結局、管理画面が日本語なので。審査側がその日本語を読めなくて、それで「テストができない」というパターンはありました。手順書とは別に対応表があった方が良かったかもしれません。

また、向こうの通貨はカナダドルなので、日本円の設定のものをそのまま動かすと上手く表示ができない、ということもあって。そういう環境の違いが、はまりやすいと思います。

佐藤：加藤さんがおっしゃった状況は、本当にそうなんです。私の場合は、動作確認に関係するページのスクリーンショットをすべて撮って、日本語の UI メニューは英訳をつけて送ったので、効果があったと思います。手間はかかりますが、下準備をしっかりしておくとスムーズだと思いますね。

加藤：これ、(Theme) App Extensions のことですかね。

佐藤：一応書いてはありますが、たくさんはないです。最低限は書いてありますが……。

加藤：弊社では「どこポイ」というポイントアプリを出しているのですが、アプリのブロックを作って実装できているところではあります。ベストプラクティスっていうほどではないですが……そもそもドキュメントにあるように作っていけばできるのかな、と思います。

実装していくなかで、例えば色を変えたりとか、設定に変更を加えるところは Liquid の箇所を読んでいただいて。Schema タグを使うと、App block として、テーマ側でその設定をノーコードで変更できたりするので、合わせて進めてもらえれば実装できるんじゃないかなと思います。

小飼：アプリ開発者として見た App block 対応法について少しご紹介しますと、新しい Theme App Extensions の仕組みだと、UI パーツに「こういうパラメータを受け取ります」というのを設定しておくと、マーチャントが Shopify の管理画面で GUI を使って設定を入れられる、というかたちで活きるので、そこは使えるところは使っていった方が良いですね。

アプリのベンダーからすると Online store 2.0 ってすごく良い仕組みだと思うので、基本的にはそっちを使っていただきたいと思いつつ、マーチャントやテーマの状況を考えるとまだまだ旧式(1.0)から切り替わるのは先かなと想定しているので、実態としては同じものを提供するんだけど、パラメータの受け取り方とかだけ 1.0 と 2.0 を分離しておいて、同じような開発コストでできる仕組みを作っておくと良いかな、というのは感じています。

佐藤：App block とか、Shopify App CLI を使って開発するのが一般的ですが、この CLI の機能で、APP Extensions を呼び起こしてくれる機能があって、その使い方も紹介しているんですよね。サンプルに書いた雛形のコードを、そのまま Shopify のアプリの方にアップロードすると実際に動かせますし、どういうコードでどんな風に動くのかっていうのが一通り見られるので、ぜひご参考ください。この辺りは公式ドキュメントでもサラッとしか触れてなかったりするのですが、本書ではしっかり取り上げています。

小飼：これはもう、ご質問のコメントが正解ですね。Liquid でカスタマイズ対応できるなら基本的にその方が良いですが、Liquid だけでいい感じにやろうとするとそれはそれで大変なので、であればアプリに任せた方が良いこともありますし。

加藤：ケースバイケースかなと思います。ほとんどのアプリが Liquid だけではできないデータを持っていたりとか、何かと連動させたいということになるので、そうなると Liquid だけでっていうのは難しい部分も多いとは思います。正直、その判断も難しい。Liquid でできないのであれば、アプリでも良いかなと思っていて。

僕自身はテーマとアプリはある程度分けたいなと思っています。色んな意見はありますし、本書でテーマについて書いている自分が言うのもどうかと思いますが、テーマはあまりカスタマイズしすぎてしまうとアップデートについていけなくなったり、干渉してしまったりと、リニューアルのタイミングなどで大変さが顕在化してしまうリスクはやっぱりあります。極論を言うと、アプリも Liquid のカスタマイズもしないで使うのがベスト。どうしても必要であれば、アプリ側でやるのか、Liquid のカスタマイズでできるのか、その判断が必要ですね。

仮に Liquid のカスタマイズができるとしても、テーマのアップデートや切り替えの可能性がある場合は、アプリとかでやった方がシンプルかもしれないな、とも思います。それでもどうしようもない部分は Liquid のカスタマイズにするべきで、というのが個人的な見解ではあります。本に書いているのに変更しない方が良いですとか言っちゃいましたが（笑）

佐藤：あとは App Unity は、そういうアプリ同士の相性の問題を解消できるように活動しているので、App Unity に加盟しているアプリで揃えちゃうというのも一つの選択肢として挙げさせてもらいます。別のアプリがメインのアプリの動きを阻害してるという不具合もたまに聞きますので、確かにアプリを入れすぎないのは大事だと思います。

小飼：これは JS(JavaScript) 用の構成のことですかね。

加藤：あと CLI で立ち上げたときの構成が若干変わったという話は、このあいだ聞きましたね。Shopify app のコマンドの話かもしれない。

大道：本書だと佐藤さんが書いてくれたところになりますね。Shopify App を Ruby on Rails でサンプルアプリを作るというところなので、Node のところには触れていないという回答になりますでしょうか。

佐藤：そうですね、ごめんなさい。Node.js では書いてないんです。

佐藤：改めまして、書籍に関心を寄せてくださった皆さん、本当にありがとうございます。

著者一同、基本的に楽しんで開発をしています。なので、皆さんも一緒に楽しんでいただけたらと思って書きました。ぜひお楽しみいただければ幸いです。

いただいたご質問の中に審査の話もありましたが、Shopify には開発以外の大変な箇所もあります。本書ではそういう、道なき道を歩んできた経験を解説しました。大変だった、辛い部分を本書で解決して、Shopify の開発を楽しんでください。よろしくお願いします。