# B2B Commerce システム 要件定義書

## 改訂履歴

| 版数 | 改訂日 | 改訂者 | 改訂内容 |
|------|--------|--------|----------|
| 1.0 | YYYY/MM/DD | - | 初版作成 |

---

## 1. 概要

### 1.1 プロジェクトの背景と目的

本プロジェクトは、B2B取引における見積依頼から受注、配送までの一連のプロセスをデジタル化し、業務効率化を図るための統合プラットフォームを構築するものである。

現行の業務では、見積依頼の確認や質問対応、見積回答書の作成、承認プロセス、注文管理などが手作業中心で行われており、以下の課題が顕在化している:

- 見積依頼内容の確認・質問抽出に時間がかかる
- 担当者ごとに管理ファイルがバラバラで非効率
- 見積管理表のデータが手元になく、都度受領が必要
- 顧客からの無理な要求により対応工数が増加
- 知識が属人化し、ブラックボックス化

本システムの導入により、統合プラットフォームによる情報の一元管理、AI機能を活用した見積依頼の自動分析、デジタル承認ワークフローの実現、バッチ処理による自動化などを通じて、リードタイムの短縮、人為的ミスの削減、顧客満足度の向上を実現する。

### 1.2 対象システムの範囲

本システムは、卸売業者（自社）とバイヤー（購入者）、メーカーの三者間での情報連携を対象とし、以下の業務領域をカバーする:

- **営業フェーズ**: 営業担当者による顧客リストからの営業活動
- **見積フェーズ**: 見積依頼の取得、AI分析、質問管理、見積回答書作成、承認、送付
- **注文フェーズ**: 注文受領、商品パターン判別、在庫確認、メーカー注文、注文請書作成・送付
- **配送フェーズ**: 配送スケジュール管理、配送状況追跡、配送完了報告
- **マスタ管理**: ユーザー管理、配送業者管理
- **ダッシュボード**: 見積管理、注文管理の可視化

### 1.3 用語定義

| 用語 | 定義 |
|------|------|
| バイヤー | 商品を購入する企業の担当者 |
| 自社（卸） | 本システムを利用する卸売業者 |
| メーカー | 商品を製造・供給する企業 |
| 統合プラットフォーム | バイヤー・自社・メーカー間の情報連携を行うシステム基盤 |
| 規定商品 | 標準仕様が確定している商品（在庫確認が必要） |
| カスタマイズ商品 | 顧客要望に応じた仕様変更が必要な商品（メーカー見積が必要） |
| 見積管理シート | 見積依頼から回答までの情報を管理する台帳 |
| 注文請書 | 注文を受領したことを証明する文書 |

### 1.4 関連文書一覧

| 文書名 | 参照先 | 概要 |
|--------|--------|------|
| AsIs業務フロー | b2b_commerce_asis.json | 現行業務の詳細フロー図 |
| ToBe業務フロー | b2b_commerce_tobe.json | 新業務の詳細フロー図 |
| 機能要件一覧 | b2b_commerce_機能要件一覧.csv | 全機能の詳細仕様 |
| 非機能要件定義書 | b2b_commerce_非機能要件定義書.md | 性能・可用性等の詳細要件 |
| インフラ設計書 | b2b_commerce_インフラ設計・構成図.md | インフラ構成の詳細 |
| セキュリティ設計書 | b2b_commerce_セキュリティ設計書.md | セキュリティ対策の詳細 |
| テスト方針書 | b2b_commerce_テスト方針書.md | テスト計画の詳細 |

---

## 2. 業務要件

### 2.1 現行業務（AsIs）の概要と課題

※詳細は別紙「AsIs業務フロー」参照

現行業務は、営業フェーズ、見積フェーズ、注文フェーズ、配送フェーズの4つの主要フェーズで構成される。各フェーズにおいて、購入者担当者、自社営業担当者、自社上長、メーカー営業担当者、自社基幹システムの5つのアクターが関与する。

主な業務課題として、以下が挙げられる:

- **見積依頼の確認作業**: 見積依頼書の内容確認と不明点の洗い出しに営業担当者が1件あたり20分を要し、顧客への質問メール作成に3分、電話確認に15分（発生率10%）かかる
- **見積管理の非効率性**: 見積管理表のデータが担当者の手元になく、都度受領が必要。担当者ごとに管理ファイルがバラバラで統一されていない
- **属人化とブラックボックス化**: 担当者しか把握していない内容が多く、都度質問が必要な状態。知識が属人化している
- **承認プロセスの非効率**: 見積回答書のレビュー依頼と承認に時間がかかり、承認結果の待ち時間が発生
- **手作業による処理**: 見積回答書の作成（30分/件）、配送金額の入力（3分/件）、注文情報の登録（15分/件）など、多くの手作業が存在

### 2.2 新業務（ToBe）の概要と期待効果

※詳細は別紙「ToBe業務フロー」参照

新業務では、統合プラットフォームの導入により、情報の一元管理とプロセスの自動化を実現する。主要な改善点は以下の通り:

**期待効果**:

1. **処理時間の大幅削減**
   - 見積依頼の確認・分析: 20分→1分（AI自動分析）
   - 見積回答書作成: 30分→1分（自動生成）
   - 注文情報登録: 15分→0分（自動連携）

2. **業務品質の向上**
   - AI分析による見積依頼の不明点抽出の精度向上
   - 統合プラットフォームによる情報の一元管理
   - デジタル承認ワークフローによる承認プロセスの可視化

3. **リードタイムの短縮**
   - 見積回答までの時間短縮
   - 注文から配送までの時間短縮
   - 配送状況のリアルタイム追跡

4. **人為的ミスの削減**
   - 自動データ取得・登録による入力ミスの削減
   - システムによるデータ整合性チェック

### 2.3 AsIs → ToBe 変更点サマリ

| 業務プロセス | AsIs | ToBe | 改善効果 |
|------------|------|------|----------|
| 見積依頼取得 | 手動でメール確認・登録 | 統合プラットフォームから自動取得 | 作業時間削減、取りこぼし防止 |
| 見積依頼分析 | 営業担当者が手動で確認（20分） | AIによる自動分析（1分） | 95%の時間削減、分析精度向上 |
| 質問管理 | メール・電話で個別対応 | 統合プラットフォーム上で一元管理 | 履歴管理、対応漏れ防止 |
| 商品パターン判別 | 営業担当者が手動判別（1分） | システムによる自動判別（0分） | 判別ミス削減 |
| メーカー見積依頼 | 手動でメール作成・送信（5分） | 自動送信（0分） | 作業時間削減 |
| 見積回答書作成 | 手動で作成（30分） | 自動生成（1分） | 97%の時間削減 |
| 承認ワークフロー | メールベースの承認依頼 | デジタル承認ワークフロー（0分） | プロセス可視化、承認時間短縮 |
| 在庫確認 | 手動で確認（5分） | リアルタイム自動確認（0分） | 即座に在庫状況把握 |
| 注文請書作成 | 手動で作成（10分） | 自動生成・送付（0分） | 作業時間削減 |
| 注文情報登録 | 手動で基幹システムに登録（15分） | 自動連携（0分） | 入力ミス削減、作業時間削減 |
| 配送スケジュール通知 | 手動で連絡（5分） | 自動通知（0分） | 通知漏れ防止 |
| 配送状況追跡 | 手動で確認・記録（30分） | 自動追跡・記録（0分） | リアルタイム可視化 |

### 2.4 業務要件一覧の概要

※詳細は別紙「機能要件一覧」参照

業務要件は、以下の7つの主要カテゴリに分類される（全53機能）:

1. **見積関連** (20機能): 見積依頼の取得・管理、AI分析、質問管理、メーカー見積、見積回答書作成・送付
2. **承認関連** (4機能): デジタル承認ワークフロー、承認タスク管理、承認履歴
3. **注文関連** (12機能): 注文受領・管理、メーカー注文、注文請書作成・送付、注文情報連携
4. **在庫関連** (2機能): 在庫自動確認、在庫確認表示
5. **配送関連** (6機能): 配送スケジュール管理、配送状況追跡、配送完了報告
6. **マスタ管理** (7機能): ユーザー管理、配送業者管理
7. **ダッシュボード** (2機能): 見積管理、注文管理の可視化

### 2.5 ステークホルダーと役割

| ステークホルダー | 役割 | 主要業務 |
|----------------|------|----------|
| 購入者：担当者 | バイヤー側の発注担当者 | 見積依頼作成、質問回答、注文依頼、配送確認 |
| 自社（卸）：営業担当者 | 見積・注文対応の実務担当 | 見積依頼確認、質問送信、見積回答書作成、注文対応、配送管理 |
| 自社：営業担当の上長 | 承認者 | 見積回答書の承認・レビュー |
| メーカー：営業担当者 | 製造元の見積・注文対応担当 | メーカー見積回答、注文請書送付 |
| 自社：基幹システム | 在庫・注文管理システム | 注文情報管理、在庫管理 |
| 統合プラットフォーム | システム基盤 | データ自動取得、AI分析、自動通知、自動連携 |

---

## 3. 機能要件

### 3.1 機能一覧の概要

※詳細は別紙「機能要件一覧」参照

本システムは、全53機能から構成され、以下の機能区分に分類される:

- **画面機能**: 28機能（一覧表示、詳細表示、検索、作成、更新、削除など）
- **バッチ機能**: 15機能（自動取得、自動分析、自動送信、自動連携など）
- **通知機能**: 7機能（メール送信）
- **その他機能**: 3機能（データ受領、外部連携など）

各機能は、CRUD（Create/Read/Update/Delete）操作を明確に定義し、関連業務フローとの紐付けを行っている。

### 3.2 主要機能のサマリ

#### 3.2.1 見積機能群（高優先度）

| 機能No. | 機能名 | 機能区分 | 概要 | 頻度 |
|---------|--------|----------|------|------|
| 1 | 見積依頼自動取得 | バッチ | 統合プラットフォームから見積依頼を自動取得・登録 | 70件/日 |
| 5 | AI見積依頼分析 | バッチ | AIによる見積依頼内容の自動分析と不明点抽出 | 70件/日 |
| 14 | 見積回答書自動生成 | バッチ | 見積管理シートから見積回答書を自動生成 | 70件/日 |
| 15 | 承認ワークフロー起動 | バッチ | デジタル承認ワークフローを自動起動 | 70件/日 |

#### 3.2.2 注文機能群（高優先度）

| 機能No. | 機能名 | 機能区分 | 概要 | 頻度 |
|---------|--------|----------|------|------|
| 21 | 注文受領 | バッチ | バイヤーからの注文データを自動受領・登録 | 49件/日 |
| 28 | 在庫自動確認 | バッチ | リアルタイムで在庫を自動確認 | 34件/日 |
| 32 | 注文請書自動生成 | バッチ | 注文情報から注文請書を自動生成 | 44件/日 |
| 36 | 注文情報自動連携 | バッチ | 注文情報を基幹システムに自動連携 | 44件/日 |

#### 3.2.3 配送機能群（高優先度）

| 機能No. | 機能名 | 機能区分 | 概要 | 頻度 |
|---------|--------|----------|------|------|
| 37 | 配送スケジュール自動通知 | バッチ | 配送スケジュールを自動作成・通知 | 44件/日 |
| 40 | 配送状況自動追跡 | バッチ | 配送業者からステータス情報を自動取得・記録 | 44件/日 |

#### 3.2.4 AI・分析機能（中優先度）

| 機能No. | 機能名 | 機能区分 | 概要 | 頻度 |
|---------|--------|----------|------|------|
| 5 | AI見積依頼分析 | バッチ | 機械学習による見積依頼の不明点抽出 | 70件/日 |
| 9 | 商品パターン自動判別 | バッチ | 規定商品/カスタマイズ商品の自動判別 | 70件/日 |

### 3.3 画面遷移概要

主要な画面遷移は以下の通り:

```
[ダッシュボード]
  ├─ [見積管理ダッシュボード]
  │   ├─ [見積依頼一覧] → [見積依頼詳細]
  │   ├─ [見積質問管理]
  │   ├─ [見積回答書作成] → [見積回答送付]
  │   └─ [承認タスク一覧] → [見積回答承認]
  │
  └─ [注文管理ダッシュボード]
      ├─ [注文一覧] → [注文詳細]
      ├─ [メーカー注文作成]
      ├─ [在庫確認]
      ├─ [注文請書作成] → [注文請書送付]
      ├─ [配送スケジュール管理]
      └─ [配送状況追跡]

[マスタ管理]
  ├─ [ユーザー管理]
  └─ [配送業者管理]
```

各画面には、検索、ソート、ページネーション機能が標準装備される。

### 3.4 外部システム連携概要

| 連携先 | 連携方式 | 連携データ | 連携頻度 | 備考 |
|--------|----------|-----------|----------|------|
| 統合プラットフォーム（バイヤー） | REST API | 見積依頼、注文依頼 | リアルタイム | 双方向連携 |
| 統合プラットフォーム（メーカー） | REST API | メーカー見積依頼、注文依頼 | リアルタイム | 双方向連携 |
| 自社基幹システム | REST API / バッチ | 注文情報、在庫情報 | リアルタイム / 日次 | 片方向連携 |
| 配送業者システム | REST API | 配送ステータス情報 | 1時間ごと | 片方向連携（受信） |
| メールサーバー | SMTP | 通知メール | リアルタイム | 片方向連携（送信） |

連携エラー時のリトライ機能、エラーログ記録、アラート通知機能を実装する。

---

## 4. 非機能要件

### 4.1 非機能要件の概要

※詳細は別紙「非機能要件定義書」参照

本システムの非機能要件は、以下の6つの主要カテゴリで定義される:

1. **可用性**: 稼働率99.5%以上、重要業務時間帯は99.9%以上
2. **性能・拡張性**: 同時接続300ユーザー、レスポンス3秒以内
3. **運用・保守性**: 24時間監視、定期メンテナンス
4. **移行性**: 段階的移行、並行稼働期間1ヶ月
5. **セキュリティ**: 多層防御、データ暗号化、アクセス制御
6. **環境・エコロジー**: クラウド最適化、ペーパーレス化

### 4.2 性能・可用性・拡張性・運用要件のサマリ

#### 4.2.1 性能要件

| 項目 | 目標値 | 備考 |
|------|--------|------|
| 同時接続ユーザー数（通常時） | 100ユーザー | 営業担当者、上長、管理者 |
| 同時接続ユーザー数（ピーク時） | 300ユーザー | 月初・月末の繁忙期 |
| 画面表示レスポンス | 3秒以内 | 一覧表示、詳細表示 |
| 検索処理レスポンス | 5秒以内 | 複雑な条件検索 |
| 帳票出力レスポンス | 10秒以内 | PDF生成 |
| AI分析処理 | 30秒以内 | 見積依頼分析 |
| バッチ処理時間 | 5-10分以内 | 各種自動処理 |

#### 4.2.2 可用性要件

| 項目 | 目標値 | 備考 |
|------|--------|------|
| 年間稼働率 | 99.5%以上 | 年間ダウンタイム約43時間以内 |
| 重要業務時間帯稼働率 | 99.9%以上 | 平日8:00-18:00、年間約9時間以内 |
| 目標復旧時間（RTO） | 2時間以内 | 障害発生時 |
| 目標復旧時点（RPO） | 1時間前 | 最大データ損失 |
| DR切り替え時間 | 4時間以内 | 災害時 |

#### 4.2.3 拡張性要件

| 項目 | 要件 | 備考 |
|------|------|------|
| ユーザー数増加対応 | 年間20%増加 | スケールアウト可能 |
| トランザクション量増加対応 | 年間30%増加 | クラウドリソース動的拡張 |
| データ保持量 | 最大500GB（5年分） | 初期50GB、年間100GB増加 |
| CPU使用率 | 平均50%以下、ピーク80%以下 | 余裕を持った設計 |
| メモリ使用率 | 平均60%以下、ピーク85%以下 | 適切なリソース配分 |

#### 4.2.4 運用要件

| 項目 | 要件 | 備考 |
|------|------|------|
| システム監視 | 24時間365日 | リソース、アプリケーション、バッチ、ログ |
| 定期メンテナンス | 月1回、業務時間外 | 土日深夜1:00-5:00 |
| バックアップ | 日次・週次・月次 | フル/差分/トランザクションログ |
| サポート体制 | 平日30分、夜間・休日2時間 | 初期対応時間 |
| パッチ適用 | 月1回定期、緊急72時間以内 | セキュリティパッチ |

---

## 5. システム構成

### 5.1 アーキテクチャ概要

※詳細は別紙「インフラ設計書」参照

本システムは、AWSをベースとしたクラウドネイティブなマイクロサービスアーキテクチャを採用する。以下の主要コンポーネントで構成される:

**アーキテクチャの特徴**:
- **フロントエンド**: SPA（Single Page Application）による高速なユーザー体験
- **バックエンド**: RESTful APIによるマイクロサービス構成
- **データ層**: リレーショナルDB（Aurora MySQL）とキャッシュ（ElastiCache Redis）の組み合わせ
- **処理層**: Lambda関数によるサーバーレスバッチ処理
- **AI層**: Amazon SageMakerによる機械学習処理
- **統合層**: API Gateway、SQS/SNSによるイベント駆動アーキテクチャ

### 5.2 インフラ構成概要

※詳細は別紙「インフラ設計書」参照

#### 5.2.1 ネットワーク構成

```
[インターネット]
    ↓
[Route 53 (DNS)]
    ↓
[CloudFront (CDN)] ← [WAF (セキュリティ)]
    ↓
[S3 (静的コンテンツ)]
    ↓
[ALB (ロードバランサー)]
    ↓
[VPC]
  ├─ [パブリックサブネット (Multi-AZ)]
  │   ├─ ALB
  │   └─ NAT Gateway
  │
  └─ [プライベートサブネット (Multi-AZ)]
      ├─ ECS/Fargate (アプリケーション)
      ├─ RDS Aurora MySQL (データベース)
      ├─ ElastiCache Redis (キャッシュ)
      └─ Lambda (バッチ処理)
```

#### 5.2.2 主要コンポーネント

| コンポーネント | 役割 | 構成 |
|--------------|------|------|
| Route 53 | DNS、ヘルスチェック | 自動フェイルオーバー |
| CloudFront | CDN、DDoS保護 | グローバルエッジロケーション |
| WAF | Webアプリケーションファイアウォール | SQLインジェクション、XSS対策 |
| ALB | L7ロードバランサー | HTTPSトラフィック分散 |
| ECS/Fargate | コンテナ実行環境 | Auto Scaling、Blue/Green Deploy |
| Aurora MySQL | リレーショナルDB | Multi-AZ、自動バックアップ、読み取りレプリカ |
| ElastiCache Redis | キャッシュ、セッション管理 | クラスター構成 |
| Lambda | サーバーレスバッチ処理 | イベント駆動実行 |
| SageMaker | AI/ML処理 | 見積依頼分析 |
| S3 | オブジェクトストレージ | ファイル保存、データレイク |
| SQS/SNS | メッセージキュー、通知 | 非同期処理、マイクロサービス間通信 |

### 5.3 技術スタック

#### 5.3.1 開発技術

| レイヤー | 技術 | 備考 |
|----------|------|------|
| フロントエンド | React/Vue.js/Angular | SPAフレームワーク |
| バックエンド | Node.js / Java Spring Boot / Python | マイクロサービス |
| データベース | PostgreSQL / MySQL / Oracle | Aurora MySQL採用予定 |
| キャッシュ | Redis / Memcached | ElastiCache採用 |
| メッセージキュー | RabbitMQ / Kafka | SQS/SNS採用予定 |
| AI/ML | TensorFlow / PyTorch / scikit-learn | SageMaker上で実行 |
| コンテナ | Docker / Kubernetes | ECS/Fargate採用 |

#### 5.3.2 運用技術

| カテゴリ | 技術 | 備考 |
|----------|------|------|
| CI/CD | Jenkins / GitLab CI / GitHub Actions | 自動ビルド・デプロイ |
| 監視 | CloudWatch / Prometheus / Grafana / Datadog | メトリクス、ログ、アラート |
| ログ管理 | ELK Stack / Splunk | CloudWatch Logs採用予定 |
| APM | New Relic / AppDynamics / X-Ray | パフォーマンス監視 |
| テスト自動化 | Selenium / JUnit / Jest | 単体・結合・E2Eテスト |

### 5.4 環境構成（開発・本番）

#### 5.4.1 環境一覧

| 環境 | 用途 | リージョン | AZ | 構成規模 |
|------|------|-----------|-----|----------|
| 開発環境 | 開発・単体テスト | ap-northeast-1 | 単一AZ | 最小構成 |
| テスト環境 | 結合テスト・システムテスト | ap-northeast-1 | 2 AZ | 縮小版 |
| ステージング環境 | 受入テスト | ap-northeast-1 | 2 AZ | 本番縮小版 |
| 本番環境 | 本番運用 | ap-northeast-1 | 3 AZ | フルスケール |

#### 5.4.2 リソース構成

| 環境 | Webサーバー | APサーバー | DBサーバー | ストレージ |
|------|------------|-----------|-----------|-----------|
| 開発 | 2 vCPU, 8GB x1 | 4 vCPU, 16GB x1 | 4 vCPU, 16GB x1 | 100GB |
| テスト | 2 vCPU, 8GB x1 | 4 vCPU, 16GB x1 | 8 vCPU, 32GB x1 | 200GB |
| ステージング | 4 vCPU, 16GB x2 | 6 vCPU, 24GB x2 | 12 vCPU, 48GB x2 | 500GB |
| 本番 | 4 vCPU, 16GB x2 | 8 vCPU, 32GB x2 | 16 vCPU, 64GB x2 | 1TB |

---

## 6. セキュリティ

### 6.1 セキュリティ方針概要

※詳細は別紙「セキュリティ設計書」参照

本システムのセキュリティは、多層防御（Defense in Depth）の原則に基づき、以下の6つの主要領域で包括的な対策を実施する:

1. **ネットワークセキュリティ**: VPC分離、WAF、セキュリティグループ
2. **アプリケーションセキュリティ**: 認証・認可、入力検証、API保護
3. **データセキュリティ**: 保存時・転送時暗号化、機密データ管理
4. **バッチ処理・AI機能のセキュリティ**: Lambda実行権限、AIモデル保護
5. **監視・監査**: ログ管理、リアルタイム監視、異常検知
6. **インシデント対応**: 検知・分析・封じ込め・復旧体制

### 6.2 認証・認可方式のサマリ

#### 6.2.1 認証方式

| 項目 | 方式 | 詳細 |
|------|------|------|
| 基本認証 | AWS Cognito | ID/パスワード認証 |
| 多要素認証（MFA） | 必須 | SMS、認証アプリ |
| パスワードポリシー | 強制 | 最低12文字、複雑性要件、定期変更（90日） |
| セッション管理 | JWT | アイドルタイムアウト15分、最大セッション8時間 |
| シングルサインオン | SAML/OAuth 2.0 | 企業アカウント連携 |

#### 6.2.2 認可方式

| 項目 | 方式 | 詳細 |
|------|------|------|
| アクセス制御 | RBAC | ロールベースアクセス制御 |
| 権限設計 | 最小権限の原則 | 必要最小限の権限付与 |
| ロール定義 | 4種類 | 営業担当者、上長、管理者、閲覧者 |
| 権限レビュー | 四半期ごと | アクセス権の定期見直し |

#### 6.2.3 主要ロールと権限

| ロール | 権限 | 対象ユーザー |
|--------|------|------------|
| 管理者 | 全機能アクセス、マスタ管理、ユーザー管理 | システム管理者 |
| 上長 | 見積承認、注文承認、レポート閲覧 | 営業部門上長 |
| 営業担当者 | 見積作成、注文対応、配送管理 | 自社営業担当者 |
| 閲覧者 | 見積・注文情報の参照のみ | 関連部門担当者 |

### 6.3 データ保護方針のサマリ

#### 6.3.1 データ分類とセキュリティレベル

| データ分類 | 保護レベル | 暗号化要件 | 対象データ |
|-----------|----------|-----------|-----------|
| 極秘 | 最高 | フィールドレベル暗号化 + 転送暗号化 + 保存暗号化 | 価格情報、取引条件、契約情報 |
| 機密 | 高 | 転送暗号化 + 保存暗号化 | 顧客情報、注文内容、見積内容 |
| 社内 | 中 | 保存暗号化 | 商品情報、在庫情報、配送情報 |
| 公開 | 低 | 改ざん防止 | 公開カタログ情報 |

#### 6.3.2 暗号化方式

| 対象 | 暗号化方式 | 鍵管理 |
|------|-----------|--------|
| 保存データ（DB） | AES-256 | AWS KMS |
| 保存データ（S3） | SSE-KMS | AWS KMS |
| 保存データ（Redis） | at-rest encryption | AWS KMS |
| 転送データ（外部） | TLS 1.3以上 | AWS Certificate Manager |
| 転送データ（内部） | TLS 1.2以上 | AWS Certificate Manager |
| 機密フィールド | AES-256 | アプリケーション管理 |

#### 6.3.3 セキュリティ監視

| 監視項目 | 監視レベル | アラート条件 | 対応 |
|---------|----------|------------|------|
| 認証失敗 | 高 | 5回連続失敗 | アカウントロック、管理者通知 |
| 特権操作 | 高 | すべて記録 | リアルタイム通知、日次レビュー |
| データアクセス | 中 | 通常パターン外 | 異常検知アラート |
| 設定変更 | 高 | すべて記録 | 承認済み変更との照合 |
| APIコール | 中 | レート超過、異常パターン | 自動スロットリング、調査 |

#### 6.3.4 コンプライアンス

本システムは、以下の法規制・基準に準拠する:

- 個人情報保護法
- 不正アクセス禁止法
- PCI DSS（支払いカード業界のセキュリティ基準）
- ISO 27001（情報セキュリティマネジメント）
- GDPR（EU一般データ保護規則）対応

定期評価として、四半期ごとの脆弱性スキャン、年次ペネトレーションテスト、セキュリティ設定の定期監査を実施する。

---

## 7. テスト計画

### 7.1 テスト方針概要

※詳細は別紙「テスト方針書」参照

本プロジェクトのテスト活動は、システムの品質保証を目的とし、以下の4つのテスト工程で段階的に実施する:

1. **単体テスト**: 開発者による個々のコンポーネントの検証
2. **結合テスト**: 開発チームによる機能間連携の検証
3. **システムテスト**: テストチームによるシステム全体の検証
4. **受入テスト**: ユーザー代表による業務適合性の検証

各テスト工程では、機能テスト、業務フロー検証、非機能テスト（パフォーマンス、セキュリティ、可用性）を実施する。

### 7.2 テスト種別と範囲のサマリ

#### 7.2.1 テスト種別

| テスト種別 | 目的 | 対象 | 実施者 | 実施時期 |
|----------|------|------|--------|----------|
| 単体テスト | 個々のコンポーネントの動作確認 | 各機能単位（画面、バッチ、API） | 開発者 | 各機能開発完了後 |
| 結合テスト | 複数コンポーネントの連携確認 | 機能間連携（見積〜注文〜配送） | 開発チーム | 単体テスト完了後 |
| システムテスト | システム全体の要件適合性確認 | システム全体 | テストチーム | 結合テスト完了後 |
| 受入テスト | ユーザー視点での適合性確認 | システム全体 | ユーザー代表 | システムテスト完了後 |

#### 7.2.2 テスト範囲と優先度

**高優先度テスト対象**（クリティカルパス）:
- 見積依頼自動取得（No.1）
- AI見積依頼分析（No.5）
- 見積回答書自動生成（No.14）
- 承認ワークフロー起動（No.15）
- 注文受領（No.21）
- 在庫自動確認（No.28）
- 注文請書自動生成（No.32）
- 注文情報自動連携（No.36）
- 配送スケジュール自動通知（No.37）
- 配送状況自動追跡（No.40）

**中優先度テスト対象**:
- メーカー見積依頼送信（No.11）
- 商品パターン自動判別（No.9）
- 各種一覧表示・詳細表示機能

**標準優先度テスト対象**:
- マスタ管理機能
- ダッシュボード機能

#### 7.2.3 テスト観点

| テスト観点 | 確認項目 | 対象機能 |
|----------|---------|---------|
| バッチ処理 | 正常系、異常系、スケジュール、ログ出力 | 全バッチ機能（15機能） |
| 画面機能 | 表示、操作、バリデーション、ページネーション | 全画面機能（28機能） |
| 通知機能 | メール送信、テンプレート、添付ファイル | 全通知機能（7機能） |
| AI機能 | 分析精度、処理速度、学習機能 | AI見積依頼分析（No.5） |
| 業務フロー | 見積〜注文〜配送の一連の流れ | 全業務フロー |
| 非機能 | パフォーマンス、セキュリティ、可用性 | システム全体 |

### 7.3 合格基準・品質指標のサマリ

#### 7.3.1 テスト完了基準

| 項目 | 基準 | 備考 |
|------|------|------|
| テストケース実施率 | 100% | 全テストケースの実施完了 |
| 重要度「高」の不具合 | 0件 | クリティカルな不具合なし |
| 重要度「中」の不具合 | 5件以下 | 軽微な不具合のみ |
| テストカバレッジ | 80%以上 | コードカバレッジ |
| 性能要件達成率 | 100% | レスポンス時間、処理時間 |
| セキュリティテスト | 合格 | 脆弱性診断クリア |

#### 7.3.2 品質指標

| 指標 | 目標値 | 測定方法 |
|------|--------|----------|
| 不具合密度 | 0.5件/KLOC以下 | 総不具合数 ÷ 総コード行数 |
| 不具合収束率 | 90%以上 | 修正完了不具合数 ÷ 総不具合数 |
| テスト効率 | 5時間/ケース以下 | 総テスト時間 ÷ テストケース数 |
| 自動化率 | 60%以上 | 自動テストケース数 ÷ 全テストケース数 |

#### 7.3.3 不具合管理

| 重要度 | 定義 | 対応期限 |
|--------|------|----------|
| 高（Critical） | システム停止、データ損失、セキュリティ問題 | 24時間以内 |
| 中（Major） | 主要機能の動作不良、回避策あり | 3営業日以内 |
| 低（Minor） | 軽微な表示不良、使い勝手の問題 | 次回リリース |

#### 7.3.4 テスト環境

| 環境 | 用途 | データ | 備考 |
|------|------|--------|------|
| 開発環境 | 単体テスト、結合テスト | 開発データ | 開発者が自由に利用 |
| テスト環境 | システムテスト | テストデータ | 本番同等構成 |
| 受入テスト環境 | ユーザー受入テスト | 本番同等データ | 本番データのマスキング版 |
| 本番環境 | 最終確認 | 本番データ | リリース直前の確認のみ |

---

## 8. スケジュール

### 8.1 マイルストーン一覧

| マイルストーン | 予定日 | 成果物 | 備考 |
|--------------|--------|--------|------|
| 要件定義完了 | YYYY/MM/DD | 要件定義書、業務フロー | ユーザー承認 |
| 基本設計完了 | YYYY/MM/DD | 基本設計書、画面設計書 | レビュー完了 |
| 詳細設計完了 | YYYY/MM/DD | 詳細設計書、DB設計書 | レビュー完了 |
| 開発完了 | YYYY/MM/DD | ソースコード、単体テスト結果 | コードレビュー完了 |
| 結合テスト完了 | YYYY/MM/DD | 結合テスト結果報告書 | 不具合修正完了 |
| システムテスト完了 | YYYY/MM/DD | システムテスト結果報告書 | 品質基準達成 |
| 受入テスト完了 | YYYY/MM/DD | 受入テスト結果報告書 | ユーザー承認 |
| データ移行完了 | YYYY/MM/DD | 移行結果報告書 | データ検証完了 |
| 本番リリース | YYYY/MM/DD | リリース報告書 | 並行稼働開始 |
| 並行稼働終了 | YYYY/MM/DD | 稼働報告書 | 旧システム停止 |

### 8.2 主要フェーズの概要

#### 8.2.1 要件定義フェーズ（2ヶ月）

**主要活動**:
- AsIs業務フロー分析
- ToBe業務フロー設計
- 機能要件定義
- 非機能要件定義
- ユーザーインタビュー、ワークショップ

**成果物**:
- 要件定義書
- 業務フロー図（AsIs/ToBe）
- 機能要件一覧
- 非機能要件定義書
- 画面遷移図

#### 8.2.2 設計フェーズ（3ヶ月）

**主要活動**:
- 基本設計（アーキテクチャ、画面、帳票、バッチ、外部連携）
- 詳細設計（DB、API、処理フロー）
- インフラ設計
- セキュリティ設計
- テスト計画策定

**成果物**:
- 基本設計書
- 詳細設計書
- DB設計書（ER図、テーブル定義）
- API仕様書
- インフラ設計書
- セキュリティ設計書
- テスト計画書

#### 8.2.3 開発フェーズ（4ヶ月）

**主要活動**:
- フロントエンド開発
- バックエンド開発
- バッチ処理開発
- AI機能開発
- 外部連携開発
- 単体テスト実施

**成果物**:
- ソースコード
- 単体テスト結果報告書
- コードレビュー記録

#### 8.2.4 テストフェーズ（3ヶ月）

**主要活動**:
- 結合テスト（機能間連携）
- システムテスト（全体動作確認）
- 非機能テスト（性能、セキュリティ）
- 受入テスト（ユーザー検証）
- 不具合修正

**成果物**:
- 結合テスト結果報告書
- システムテスト結果報告書
- 非機能テスト結果報告書
- 受入テスト結果報告書
- 不具合管理表

#### 8.2.5 移行・リリースフェーズ（2ヶ月）

**主要活動**:
- データ移行リハーサル
- 本番データ移行
- ユーザートレーニング
- 本番リリース
- 並行稼働
- 本番稼働開始

**成果物**:
- データ移行報告書
- トレーニング資料
- 運用マニュアル
- リリース報告書
- 稼働報告書

### 8.3 クリティカルパス

以下の活動は、プロジェクト全体のスケジュールに直接影響するクリティカルパスとして管理する:

#### 8.3.1 要件定義フェーズ

- **業務フロー確定**（2週間）: AsIs/ToBeの合意形成
- **機能要件確定**（4週間）: 全53機能の仕様確定
- **非機能要件確定**（2週間）: 性能・セキュリティ要件の合意

#### 8.3.2 設計フェーズ

- **アーキテクチャ設計**（2週間）: システム全体構成の決定
- **DB設計**（3週間）: ER図、テーブル定義の確定
- **外部連携設計**（2週間）: 統合プラットフォーム、基幹システム連携仕様の確定

#### 8.3.3 開発フェーズ

- **AI機能開発**（6週間）: 見積依頼分析機能の実装と学習
- **統合プラットフォーム連携開発**（4週間）: バイヤー・メーカーとの連携実装
- **基幹システム連携開発**（3週間）: 注文情報連携の実装

#### 8.3.4 テストフェーズ

- **AI機能テスト**（3週間）: 分析精度の検証と調整
- **外部連携テスト**（2週間）: 統合プラットフォーム、基幹システムとの連携確認
- **性能テスト**（2週間）: 負荷テスト、レスポンス時間測定

#### 8.3.5 移行・リリースフェーズ

- **データ移行リハーサル**（1週間）: 移行手順の検証
- **本番データ移行**（2日間）: 週末を利用した移行実施
- **並行稼働**（4週間）: 旧システムとの並行運用

#### 8.3.6 リスク管理

クリティカルパス上の活動については、以下のリスク管理を実施する:

- 週次進捗確認と遅延の早期検知
- バッファ期間の確保（各フェーズに1週間）
- 代替案の事前準備（特にAI機能、外部連携）
- ステークホルダーへの早期エスカレーション

---

## 9. 付録

### 9.1 略語一覧

| 略語 | 正式名称 | 説明 |
|------|---------|------|
| AI | Artificial Intelligence | 人工知能 |
| API | Application Programming Interface | アプリケーション間のインターフェース |
| AWS | Amazon Web Services | Amazonのクラウドサービス |
| B2B | Business to Business | 企業間取引 |
| CDN | Content Delivery Network | コンテンツ配信ネットワーク |
| CRUD | Create, Read, Update, Delete | データ操作の基本4機能 |
| DNS | Domain Name System | ドメイン名システム |
| DR | Disaster Recovery | 災害復旧 |
| ECS | Elastic Container Service | AWSのコンテナサービス |
| KMS | Key Management Service | AWSの鍵管理サービス |
| MFA | Multi-Factor Authentication | 多要素認証 |
| RBAC | Role-Based Access Control | ロールベースアクセス制御 |
| REST | Representational State Transfer | Webサービスのアーキテクチャスタイル |
| RPO | Recovery Point Objective | 目標復旧時点 |
| RTO | Recovery Time Objective | 目標復旧時間 |
| SLA | Service Level Agreement | サービスレベル契約 |
| SPA | Single Page Application | シングルページアプリケーション |
| TLS | Transport Layer Security | 通信暗号化プロトコル |
| VPC | Virtual Private Cloud | 仮想プライベートクラウド |
| WAF | Web Application Firewall | Webアプリケーションファイアウォール |

### 9.2 参考資料

| 資料名 | 発行元 | 参照URL |
|--------|--------|---------|
| AWS Well-Architected Framework | AWS | https://aws.amazon.com/architecture/well-architected/ |
| OWASP Top 10 | OWASP | https://owasp.org/www-project-top-ten/ |
| ISO/IEC 27001 | ISO | https://www.iso.org/isoiec-27001-information-security.html |
| PCI DSS | PCI Security Standards Council | https://www.pcisecuritystandards.org/ |

---

## 承認

| 役割 | 氏名 | 署名 | 日付 |
|------|------|------|------|
| プロジェクトマネージャー |  |  | YYYY/MM/DD |
| 技術責任者 |  |  | YYYY/MM/DD |
| 品質保証責任者 |  |  | YYYY/MM/DD |
| お客様代表 |  |  | YYYY/MM/DD |

---

**文書管理情報**

- 文書ID: REQ-B2B-COMMERCE-001
- 分類: 要件定義書
- 機密区分: 社外秘
- 保管期間: プロジェクト完了後5年間

---

**以上**