要件定義の進め方

はじめに

ここでは一番重要となる要件定義のフェーズについて紹介します。 要件定義以外のフェーズについては、別途重要なポイントを紹介します。

要件定義の進め方

一般的なシステムの要件定義に加えて、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側の運用負荷が増えた場合や、問い合わせ件数が想定より多い場合に発生する可能性があります。