ネットショップの要件定義ってどうすればいいですか。 その２

前回記事では、ECサイトを作るにあたってどのように要件定義をすればよいのかというお話をさせていただきましたが、要件定義をするうえで大切なことは「網羅性」です。

ECサイトを構築する際、ECサイトのうち、お客様に見える部分に注意が向きがちです。フロント側についてはかなり具体的なイメージをお持ちの場合が多いですが、バックエンド側は「普通にやればよい」と考えて、それほど整理されていないケースがあります。

バックエンドは業種や商材やサイトオーナーのビジネスの仕方によって、いろいろなバリエーションがあります。
限りある時間の中でどのように漏れなく要件定義できるでしょうか。

---

要件定義と同じく、工数見積も網羅性という点が重要視されます。
ソフトウェアの見積手法ではファンクションポイント法というものがよく知られています。
データフローダイアグラム（DFD)を作成して、データの入出力を洗い出してファンクションポイントとしてカウントしていくというものです。

これはかなり設計が進んだ段階でなければ算出できませんが、もっと初期の段階で簡易に測定する簡易測定法が用いられることもあります。

それはテーブルを項目数の多さによって分類し、それに対して特定のポイントを乗じて計算するような方法です。
本来のファンクションポイント法のやり方でデータフローダイアグラムを作成していくと、システムの中のほとんどすべてのテーブルに対してCRUD（Create（生成）、Read（読み取り）、Update（更新）、Delete（削除））が発生することになります。
それでテーブル数そのものとDFDから算出したファンクションポイントは相関することが分かっています。

---

少し横道にそれましたが、ソフトウェアの規模見積の際に漏れなく検討するには、テーブルとテーブルに対するCRUDに注目する方法が有効なのですが、ECサイトの要件を漏れなく検討する際にもその考えは応用できます。
データの項目とデータのライフサイクルに注目してヒアリングをすることによって、最低限の網羅性は確保できます。

EC-CUBEのデータベースを見てみますと、それなりにたくさんのテーブルがあり、テーブル単位に全てCRUDを考えるのは大変です。
少し乱暴ですが、ライフサイクルを俯瞰するという場面では、商品と受注と会員の3つのデータとシステム管理用のデータに集約して考えることができます。

例えば、カテゴリというデータがありますが、これは商品に関連するデータです。商品規格もそうです。商品データの登録のライフサイクルとは切り離して考えることはできないデータです。ECサイトで管理しているほとんどのデータは商品か受注か会員のデータのいずれかと関連があります。

---

そこで、以下のような手順で進めてみるとよいでしょう。

（1）EC-CUBEの管理画面から、商品、受注、会員のページを見ながら関連データについてヒアリングする

例えば、管理画面の商品マスタを見ます。商品の説明文や写真があります。価格や在庫数があります。規格があります。カテゴリもあります。それぞれについて、取り扱いの有無や、具体的にどのようなデータを扱うのか確認します。例えばデジタルコンテンツであれば在庫数はないですし、一品モノの場合は規格使わないでしょう。カテゴリや規格についてかなり複雑な管理が求められているかもしれませんし、デフォルトのEC-CUBEにはないデータを扱いたいケースもあるでしょう。管理画面を見ながら、EC-CUBEのデフォルトの項目をベンチマークとして検討することにより、具体的な検討ができます。

受注詳細ページにも、送料やポイント、複数配送先の対応、決済方法など、確認ポイントがあります。会員も同様です。付随する情報としては配送先やポイントなどがあります。それらのデータをそのECサイトの運用に利用するかどうか、またもデフォルトの機能では扱いきれないデータがないか確認します。

「システムに業務を合わせる」妥協は終わりにしませんか。複雑な要件も100%叶える、ベンダー依存のない自社専用EC基盤を。
自社要件を相談する

（2）商品、受注、会員とその関連情報のライフサイクルについてヒアリングする

次に、それぞれのデータをどのようなタイミングで管理するのかを確認します。
例えば、EC-CUBEには商品データをメンテナンスする機能はあります。その機能で十分でしょうか。CRUDそれぞれ、どのようなケースがあるかを書き出してみるとよいでしょう。

Createはどのようなケースでしょうか。通常は商品の追加はなく、年度やシーズンの切り替えにまとめてモデルチェンジしているケースは多いです。例えば1000点くらいの商品が追加され、逆に1000点くらいが廃盤になり、それは3月31日の夜に一斉に切り替えたいという要件があるかもしれません。この場合、管理画面で1件ずつ更新するのでは対応できない可能性があります。また夜間に更新作業するのではなく、あらかじめ登録しておいて設定された日に公開・非公開が切り替わる仕組みが必要かもしれません。廃盤品はDeleteというテーマですが、非公開にせずにしばらく表示して、後継商品を案内したいという要望があるかもしれません。廃盤品を単純に削除すればよいという話ではない可能性があります。

このようにCRUDそれぞれにヒアリングしてみますと、様々な要求事項があることが分かります。

以下のようなマトリックスを作って、ヒアリングをするとよいでしょう。
ショップオーナーにとっても考えを整理して伝えやすくなります。

最後に、ヒアリングした内容は「要求」や「要望」かもしれませんが、「要件」と呼ぶことができないものもあります。
「要求」や「要望」に対して、システムとしてどのようなシステムが求められるかが「要件」です。
それはEC-CUBEのデフォルトの機能で対応できる要件もありますし、運用で工夫して要求を満たすのでシステムはこの程度でもよいという要件が定義されることもあります。

その前提として漏れなく検討することが大切です。