ecforceでコーディングしていく中でいろいろ思ったことをまとめてみる
前回に引き続きecforceの記事です。今回はecforceのコーディングをしている中でいろいろ思ったことを書いていきます。
なお、ecforceの詳細について触れているものではありませんし、個人的見解で書かせていただいております。
詳細が知りたい場合は公式サイトで情報収集することをおすすめいたします。
運営者側のecforceに対する理解度の重要性
ここでいう運営者は、店舗側ではなく制作者側で考えてください。
例えばですが、ディレクターなどがそのポジションに当たるのかなと思います。
この運営者側がecforceについてどのくらい理解しているのかが本当に重要になってくると個人的に考えています。
というのも、例えば下記のような点で柔軟な対応が必要になってくるからです。
- 店舗側が自分たちでどの範囲まで対応したいのか
- 最低限必要なページの把握
- 実装したい機能がecforceで使えるのか
- デザインの自由度はどのくらいか
- 動作確認時の各情報
店舗側が自分たちでどの範囲まで対応したいのか
例えば、店舗側で商品登録して販売するなどが挙げられると思いますが、商品登録に限らず、どの範囲まで店舗側で対応するのかということは、ecforce全体の操作や仕組みを理解していないと、最善の提案ができないと思います。
また、誤操作によって、想定していない被害を被ることもあるかもしれません。
最低限必要なページの把握
最低限必要なページを把握していないと、あとあとデザインカンプが足りないとなって、スケジュールに遅れが出ることがあります。
ただ把握するだけでなく、同じページでもログイン時・未ログイン時などのいろんな条件によって表示が変わる部分があります。
こういったところも細かく把握しておかないと、意図していない作業が発生してしまうため、結果的にデザイナーやコーダー側の工数が増えてしまうことにつながってしまいます。
条件別の表示対応でよくあるのが、ログイン・未ログイン、LINE連携・未連携、商品がある・ない場合、定期購入のステータスが有効・キャンセル・停止の場合、ポイントがある・ない場合、会員ランクなどです。
こういったところを細かく詰めておくことで柔軟に作業を進めていくことができると思います。
実装したい機能がecforceで使えるのか
よくあるのが、他者の通販サイトを見てこの機能だったら実装できるんじゃないかと勝手に判断して盛り込まれるような事例があります。
何ができて何ができないかということは、事前に確認をとって進めることが重要になってきます。
また、例え実装できる内容であっても、デフォルトテーマには盛り込まれていない特殊な対応をするケースもあります。
その場合は、きちんと実装の対応方法を明確にしてあげないとコーダー側に負担となってしまうので、事前に公式側やコーダーも交えてヒアリングするのがおすすめだと思います。
デザインの自由度はどのくらいか
実際のデフォルトテーマでは、思いのほか制約があるため、自由なレイアウトでコーディングができるわけではありません。
そのことを考慮した上で、デザイナー側に仕様をきちんと説明してデザインを進めていただく必要性が出てきます。
また、先ほどの最低限必要なページの部分とも被りますが、ログイン周りや決済周り、カート周りなどに最低限必要な情報は盛り込む必要が出てきますので、その点も伝えて対応いただかなくてはなりません。
これらのことが曖昧のまま進めてしまうと、実装できない部分がでてきたり、本番公開時に足りないページや情報が出てきて、事故につながってしまう恐れがあります。
動作確認時の各情報
各ページを確認してくときに、メールアドレス、パスワード、クレジットカード、住所、LINEなどの情報を入れていきます。これが作業者にとっては、入れたくないなと思ってしまうのですが、こういった入れるべき情報をきちんと整備しておくことも必要だと感じています。今の現場では、仕方なく自分の情報を入れて対応しなければならない場面が多いです（打診中です）。
まだまだあるとは思いますが、もちろんこれらのことを全体で理解していることに越したことはありません。その方が作業も円滑に進みやすいですし、リカバリーもできますので。
コーダーが気をつけること
アップしたらすぐに本番反映されてしまう
ページにパスワードをかけることはできますが、テスト環境がない現場が多いため、更新すればすぐに本番反映されてしまいます。既存ページの更新時は特に注意をして対応しなければなりません。
またバックアップの取り忘れにも注意しましょう。特にLPページを作るときは、注意です。
LPページは同一ページ上に、複数の枠が設けられており、header、body、footer、css、jsのそれぞれにコードを入れていくからです。間違ってコピペしてしまい、元の情報が消えてしまうことなども起こりえます。
その他、厄介なことにliquidのコードで書かれているため、ローカル環境で確認することができないというデメリットもあります。
テスト確認時のアカウント切り分けが確認時間を要する
テスト用のアカウントが1つだけだと、ログインしている・していない状態、定期購入している・していない状態、LINE連携している・していない状態などの切り分けがめちゃくちゃ大変です。
さきほどの運営者側のコンテンツでも触れましたが、こういったところを複数アカウントを作って確認していくのかなど、コミュニケーションを図っていくことも必要になってくると思われます。
通常のページを確認していくよりも、意外と確認時間がとられる印象です。その分の工数も加味するのがいい気がしました。
成約がある中でのコーディング対応
一旦静的で自由に組みたいと思うところですが、それは残念ながらできません。デフォルトテーマをもとにカスタマイズしていくため、すでに割り当てられたCSSやJS、liquidがあります。
その成約の中で、liquidの中身を改修していくことになります。
liquidは動的に出力している部分になるため、基本的にはそのまま使います。なかには、変えることができる部分もありますが、それが原因で予期せぬエラーに繫がることもあるからです。
ただ、現場ではデザインカンプとデフォルトのテキストやレイアウトが違うことがたくさんあります。これはディレクター側の力量にかかってくる部分かとは思いますが、わからない点が出てきたらその都度確認して進めていくことをおすすめします。
CSSの調整が意外と大変
最初からまっさらな状態で組んでいければよいのですが、デフォルトのCSSに対して、自分で新規で作ったCSSを上書きしていく対応になります。
デフォルトのCSSにはimportantが使われている部分がありますので、詳細度の指定が本当に大変だなと感じています。
また、特に大変なのがフォームです。デフォルトに倣ったデザインカンプで届かないことが多く、liquidも多くの箇所で使われているため、なかなか工数がかかる印象でした。
その他にも、デフォルトにない機能を追加してほしいという依頼もかなり多く、それを実装するのを調べる時間や問い合わせる時間などもあるため、なかなか工数がかかるなという印象でした。
以上、こんな感じですが、他にもなにか思いついたら追記して挙げさせていただきたいと思います。
