- CODING FACTORY TOPICS
- Vol.126 2019年4月号
Web制作の現場では、フロントエンドの領域が益々広がりを見せており、Web上で実現できる内容がどんどん多様化しています。今回ご紹介する案件は、そんな多様性を垣間見ることのできるWebアプリケーションの制作でした。
案件概要
株式会社ディノス・セシール様が運営する「ディノスオンラインショップ」で販売されている壁面収納シリーズの商品を、ユーザーがWebブラウザ上で並べ、組み合わせて、どんな見た目になるか、合計でいくらになるのかシミュレーションができ、シミュレーション結果のシェアや、そのままカートに遷移ができるWebアプリケーション。
■基本的な流れ
垂直方向に、下段に置ける商品群を「下置き商品」、上段に置ける商品群を「上置き商品」と総称しています。
- STEP1 : まず下置き商品を並べる
- STEP1.5 : 商品設置箇所の天井高さを入力
- STEP2 : 上置きの商品を下置き商品の上に配置する
※シリーズによって上置き設置可能ルールが異なる
シュミレーションの結果を「カートに入れる」「シェアするためにURLを発行する機能」はSTEP1,2のどちらでも動作可能。
■基本仕様
- ・下置きに対する上置きの設置可能なルールは、以下2パターン存在する。
-
ルール1
下置き商品と左端あるいは右端さえ揃っていれば、下置き商品を複数またいで上置き商品を設置できる。 -
ルール2
下置き商品に対して同じ幅の上置き商品しか設置できない。
-
- ・上置き商品は、1cm単位で高さを変更しオーダーすることが可能。
- ・「色」「奥行き」を商品を置いた後でも変更可能。
- ・奥行き...下置き、上置き商品共に同じ深さの商品しか一緒に組み合わせることはできない。上置き商品は、下置き商品の奥行き以下であれば設置可能。
- ・オプション付きの商品も存在する。例えばデスク型の下置き商品に対して、チェアを付けるか選択できる。
- ・「保存する」ボタンで、シュミレーション結果をブラウザに保存することができる。
- ・シュミレーション結果のシェアURLを発行できる。
- ・置いた後に、ドラッグ&ドロップで違う位置に置き直すことができる。
仕様の決定・実現方法
仕様のご要望→今回の案件規模に収まる範囲での仕様のご提案→ご検討...を繰り返し、両社にて仕様を少しずつ詰めていきました。
細かなルールの組み合わせが多々ある中で、Webアプリケーション側で制御すべき点、考慮すべき点が多くありました。
- ・左端 or 右端 にしか置けない、上に商品を置けない等、特別な値を持った商品が置けない場所に置かれた時にはエラー文言を出力する。
- ・上置きに遷移する際に、すでに配置された下置き商品に対して設置可能な上置き商品しか選択肢に表示しないよう絞り込み機能を実装。
- ・STEP1.5の計算結果の値を、STEP2に遷移した際の上置き商品の初期値に設定
また、商品情報のデータは更新頻度によって以下2つにファイルを分けました。
- ・価格データ...更新頻度高。お客様側のシステムで毎日更新。
- ・商品詳細データ...更新頻度低。商品番号、色、幅・高さ・深さ、オプション商品の番号、等々。
こちらはお客様側で管理しやすいようにバックエンドの操作画面まで制作することも検討しましたが、どうしても工数がかかり費用も増してしまうため、今回はGoogleが提供しているGASを用いて、スプレッドシートにデータを任意の構造でボタン1つでjsonデータ形式出力できるように実装しました。これで、今後シリーズが増えてもお客様側で作業を完結させることが可能になりました。
難しかった点
- ・扱うべき動的データが多いため、当初はデータベースを利用した方がいいのでは、使わないとパフォーマンスが落ちてしまうのでは、という懸念がありましたが、すべてフロントエンドの技術でパフォーマンスを落とさないように実装することができました。基本的な技術は、Reactを使用しています。
- ・上置き商品は、1cm単位で値を変更可能です。本来は別商品として存在する商品を、ユーザビリティを考慮しUI上では一見1商品のように扱い操作できるようにした点が難しかったです。(実際には選択した値によって、3商品のうちいずれかに特定して金額等にデータを反映しなくてはならない)
まとめ
CFではWordPress案件といった、日々のデータ更新に伴いサイトへの表示内容が変化する案件をご対応することも多いですが、そうした案件はご納品後もお客様側で運用が発生するため、一つひとつのご要望に対する認識のすり合わせをより慎重に行う必要があります。
また、双方議論を進める中で必要な機能に気付くこともありましたが、一つひとつの仕様が相互に関連し合っていて、仕様追加や変更が他の仕様の調整にも繋がり、工数の正確な予測が困難でした。そのため、こうした複雑な仕様の案件は特に、スケジュールにはできるだけ余裕を持たせておく必要があります。
そして要件定義の段階で、はじめから最後までの流れを何度も繰り返すことの重要性を再確認した案件でした。それでも実際に実装して動かしてみないと気付けない点もあったので、今回の経験からいかに先回りして多くのパターンを予測し、初期段階から仕様に落とし込めるかが効率化の鍵だと感じました。
(モノサスタイランド 町山)