要件定義の進め方
はじめに
ここでは一番重要となる要件定義のフェーズについて紹介します。 要件定義以外のフェーズについては、別途重要なポイントを紹介します。
要件定義の進め方
一般的なシステムの要件定義に加えて、EC特有の要件定義を検討していく形になります。 その他のポイントとしては、非機能要件の大半についてはクラウドPaaS ECであるCommerble側で担保しますので、検討項目は減ります。
基本情報の確認
まず、現状の基本情報を確認します。 下記の項目に限らず、事業を成功させるにあたり必要な事項を話し合います。
- EC事業者様の企業情報
- (既にECを行なっている場合)売上高、注文数、商品数、顧客数(移行対象)などの現状値
- 顧客像の確認
- 何に特化しているのか
- 何を苦手としているのか
- 競合
- 利益構造
- 業界情報
構築(リニューアル)の目的
RFPの再読み合わせなど、目的を確認するのに必要なものは以下の通りです。
- RFPや、RFP相当の情報で要求事項のおさらい
- 構築に当たり目標値の確認
- コンセプト
- やりたいことのリストアップ(大小問わず)
- 既存ECがある場合、既存ECから改善したい事項のリストアップ
- この場合、ワークショップを行い、より要求を掘り下げる事も可能です。
全体像
- 全体像の確認
- システム化部分の確認
- 注文管理システム(OMS)の確認
- 基幹連携内容の確認
- 倉庫物流の連携内容の確認
- 外部モール
- ポイントシステム
- 会員証、アプリ
- CRM
- メルマガ
- DWH
デザインの進め方
デザインの進め方については、EC事業者様が主導するケースと、Commerble側で主導するケースがありますが、どちらの場合も以下のような議題を検討します。
- コンセプト
- トンマナ
- テンプレートを確認し、改修したいポイント検討から始めるやり方
- ワイヤーからゼロベースで検討するやり方
- 作業分担
ワイヤーまでEC事業者様で対応、もしくはHTML実装までEC事業者様で対応可能です。 ただし、HTMLの品質はその後の改善しやすさに直結しますので、弊社側での指示に従って頂くか、弊社側で実装する事を推奨します。 経験の少ない方がHTMLを作るより、弊社側で実装する事を推奨します。
業務フロー
- 受注ステータスに伴う業務
- 受注ステータス表に伴いどのような業務があるか検討します
- 注文変更時の業務
- 明細の変更可否を決めます。変更可にすると、決済やポイントやその他連携先との整合性を調整します
- 注文キャンセル時業務
- 決済のキャンセル、ポイントの戻し、在庫の戻しを検討します
- 返品時業務
- 返品時に必要な業務を検討します
- 在庫管理
- どこから在庫情報が連携されるか、在庫の種類にどのようなものがあるか等を検討します
- 商品登録
- コンテンツ作成
- バナーなどメンテナンス
- ビジネス都合のサイト停止
- ユーザーヒアリング
既存と同じという部分には多くの問題が内在しています。1つは問題があっても気付かずそのままにしてしまうこと、1つは仕様の詳細が適切に伝わらない事があります。この注意点を良く考慮して進めましょう。
現状及び方向性の確認
- 決済代行業者
- 対応する決済方法
- 商品情報レイアウト、サンプルデータ(CSVやRDB)
- 注文情報(現状)レイアウト、サンプルデータ
- セット商品やバスケット売りの情報
- 会員情報(現状)レイアウト、サンプルデータ
- カテゴリ情報レイアウト、サンプルデータ
- メールテンプレート※注文時や会員登録時のメール
- キャンペーン(定率定額値引き、プレゼント、誕生月、購入2回目)
- 送料の計算方法
特殊機能
どこまでがEC業務なのかは各社異なる部分があります。ここでは、通常のECから離れた業務や機能を洗い出し、検討します。
- ECの範囲内に収まるか不明な機能の確認
- 例)請求書、納品書(物流の場合が多い)
スコープおよびスケジュール
全ての要件を叶えるスケジュールにするのか、リリーススケジュールを遵守して、リリース後に段階的に機能を追加していくなど、ロードマップを検討します。
非機能要件
- 月間の受注数、閲覧数
- ピーク時の受注数、閲覧数
- 連携システムの可用性
- 連携システムのタイムラグ
- メンテナンスの有無
- セキュリティテストの実施
外部機関によってセキュリティテストを行うか検討します。Commerble部分だけではなく連携先も含めてのセキュリティなので、実施を推奨します。
意思決定
- 会議体
- 役割分担
- オーナー、参加者
- 検討方法(Backlog)
- コミュニケーション(Slack、Teams)
試験
- 結合試験
- 試験環境(主に連携先)、インフラ制約
- 受入試験(ユーザー主導)
その他
- 気をつけるべき法令の確認
- 用語集の作成
稼働後の費用
- 月額保守費用
- カスタム部分の保守費
*コマーブルでは機能追加で保守費が増えることはありません。*というのも、コマーブルではカスタム部分の保守費を構築費から見積もっていません。問い合わせ件数やシステム間連携の複雑性で見積もります。カスタマイズすると保守費用が増えてしまっては、リリース後の柔軟な対応、良くしていきたいという思いが奪われるため、そのような費用追加は行っていません。
保守費用の増額は、連携先のシステムが不安定でCommerble側の運用負荷が増えた場合や、問い合わせ件数が想定より多い場合に発生する可能性があります。