コーディングファクトリートピックス
Vol.126 2019年4月号

仕様の決定・実現方法

仕様のご要望→今回の案件規模に収まる範囲での仕様のご提案→ご検討...を繰り返し、両社にて仕様を少しずつ詰めていきました。
細かなルールの組み合わせが多々ある中で、Webアプリケーション側で制御すべき点、考慮すべき点が多くありました。

• ・左端 or 右端 にしか置けない、上に商品を置けない等、特別な値を持った商品が置けない場所に置かれた時にはエラー文言を出力する。
• ・上置きに遷移する際に、すでに配置された下置き商品に対して設置可能な上置き商品しか選択肢に表示しないよう絞り込み機能を実装。
• ・STEP1.5の計算結果の値を、STEP2に遷移した際の上置き商品の初期値に設定

また、商品情報のデータは更新頻度によって以下2つにファイルを分けました。

• ・価格データ...更新頻度高。お客様側のシステムで毎日更新。
• ・商品詳細データ...更新頻度低。商品番号、色、幅・高さ・深さ、オプション商品の番号、等々。

こちらはお客様側で管理しやすいようにバックエンドの操作画面まで制作することも検討しましたが、どうしても工数がかかり費用も増してしまうため、今回はGoogleが提供しているGASを用いて、スプレッドシートにデータを任意の構造でボタン1つでjsonデータ形式出力できるように実装しました。これで、今後シリーズが増えてもお客様側で作業を完結させることが可能になりました。

難しかった点

• ・扱うべき動的データが多いため、当初はデータベースを利用した方がいいのでは、使わないとパフォーマンスが落ちてしまうのでは、という懸念がありましたが、すべてフロントエンドの技術でパフォーマンスを落とさないように実装することができました。基本的な技術は、Reactを使用しています。
• ・上置き商品は、1cm単位で値を変更可能です。本来は別商品として存在する商品を、ユーザビリティを考慮しUI上では一見1商品のように扱い操作できるようにした点が難しかったです。（実際には選択した値によって、3商品のうちいずれかに特定して金額等にデータを反映しなくてはならない）

まとめ

CFではWordPress案件といった、日々のデータ更新に伴いサイトへの表示内容が変化する案件をご対応することも多いですが、そうした案件はご納品後もお客様側で運用が発生するため、一つひとつのご要望に対する認識のすり合わせをより慎重に行う必要があります。
また、双方議論を進める中で必要な機能に気付くこともありましたが、一つひとつの仕様が相互に関連し合っていて、仕様追加や変更が他の仕様の調整にも繋がり、工数の正確な予測が困難でした。そのため、こうした複雑な仕様の案件は特に、スケジュールにはできるだけ余裕を持たせておく必要があります。
そして要件定義の段階で、はじめから最後までの流れを何度も繰り返すことの重要性を再確認した案件でした。それでも実際に実装して動かしてみないと気付けない点もあったので、今回の経験からいかに先回りして多くのパターンを予測し、初期段階から仕様に落とし込めるかが効率化の鍵だと感じました。

(モノサスタイランド 町山)

お問い合わせはこちらからどうぞ