# 会計ERPシステム 要件定義書

## ドキュメント管理情報

| 項目 | 内容 |
|------|------|
| ドキュメント名 | 会計ERPシステム 要件定義書 |
| バージョン | 1.0 |
| 作成日 | 2024年 |
| ステータス | 初版 |

---

## 1. 概要

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

本プロジェクトは、経理部門における管理会計、原価計算、資産管理、税務処理、連結会計の5つの主要業務領域を統合的に管理する会計ERPシステムの構築を目的としている。

現行業務では、予算管理の標準化不足、原価データ収集の遅延、固定資産台帳の分散管理、税務処理の属人化、内部取引照合の非効率性など、多岐にわたる課題が存在する。これらの課題により、手作業による工数増加、計算ミスの発生、リアルタイムな情報把握の困難さが顕在化している。

本システムの導入により、統合会計システムを新規に導入し、既存の会計システムと連携することで、業務の自動化・効率化を実現する。予算管理では約57%、予算実績管理では約80%の工数削減を見込み、年間約153時間の削減効果を期待している。

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

本システムは以下の機能範囲を対象とする:

- **予算管理**: 予算テンプレート管理、部門予算案管理、予算承認ワークフロー、予算シミュレーション
- **実績管理**: 実績データ自動取得、部門別実績データ抽出、内部取引データ処理
- **予算実績比較**: 差異計算、要因分析、アラート管理、レポート自動生成
- **固定資産管理**: 固定資産台帳管理、減価償却計算、減価償却仕訳作成
- **棚卸資産管理**: 棚卸資産データ収集、評価、差異調査、棚卸仕訳作成
- **税務管理**: 税務関連データ収集、消費税・法人税・地方税計算、税務申告書類作成
- **連結会計**: 内部取引データ収集・照合、連結仕訳作成、連結財務諸表作成
- **共通機能**: データインポート/エクスポート、外部システム連携API、マスタ管理、ダッシュボード

### 1.3 用語定義

| 用語 | 定義 |
|------|------|
| AsIs | 現行業務プロセス |
| ToBe | 新業務プロセス（目指すべき姿） |
| 統合会計システム | 本プロジェクトで新規導入するERPシステム |
| 会計システム | 既存の会計データ管理システム |
| 予算実績差異 | 予算と実績の差額および差異率 |
| 内部取引 | グループ会社間の取引 |
| 連結仕訳 | 連結財務諸表作成のための調整仕訳 |
| RTO | 目標復旧時間（Recovery Time Objective） |
| RPO | 目標復旧時点（Recovery Point Objective） |

### 1.4 関連文書一覧

| No. | 文書名 | 説明 |
|-----|--------|------|
| 1 | 業務要件_asis_tobe.md | AsIs/ToBe業務要件の詳細 |
| 2 | erp_accounting_機能要件一覧.csv | 機能要件の詳細一覧（全51機能） |
| 3 | erp_accounting_非機能要件定義書.md | 非機能要件の詳細定義 |
| 4 | erp_accounting_インフラ設計・構成図.md | インフラ設計および構成の詳細 |
| 5 | erp_accounting_セキュリティ設計書.md | セキュリティ設計の詳細 |
| 6 | erp_accounting_テスト方針書.md | テスト方針および計画の詳細 |

---

## 2. 業務要件

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

現行業務では、経理部門が管理会計、原価計算、資産管理、税務処理、連結会計の5つの主要業務領域を担当している。業務システムとしては会計システムと表計算ソフトの2システムで構成され、多くの手作業とデータの二重入力が発生している。

**主要課題**:
- **予算管理**: テンプレート標準化不足、部門間スキルのばらつき、予算実績データ形式の不統一
- **原価計算**: データ収集の遅延、計算ルールの不統一
- **資産管理**: 固定資産台帳の分散管理、手動減価償却計算によるミス、棚卸作業の非効率性
- **税務処理**: 専門知識への依存、書類保管の検索性低下
- **連結会計**: 内部取引照合の工数増大、連結財務諸表作成プロセスの複雑性

※詳細は別紙「業務要件_asis_tobe.md」の第1章を参照

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

統合会計システムの導入により、手作業を削減し、自動化・システム化を推進する。既存の会計システムと統合会計システムの2システム構成とし、システム間のデータ連携を自動化する。

**期待効果**:
- **効率化効果**: 予算策定工数57%削減、予算実績管理工数80%削減、年間約153時間の削減
- **品質向上効果**: データ形式統一、計算ミス削減、リアルタイム情報把握、透明性向上
- **自動化範囲**: テンプレート配布、データ集約、差異計算、レポート生成、減価償却計算

※詳細は別紙「業務要件_asis_tobe.md」の第2章を参照

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

| 項目 | AsIs | ToBe | 変更内容 |
|------|------|------|----------|
| システム構成 | 会計システム + 表計算ソフト | 会計システム + 統合会計システム | 表計算ソフトを統合会計システムに置換 |
| 予算テンプレート作成 | 手動作成（240分） | システム設定（60分） | 75%削減 |
| 予算案集計 | 手動収集・集計（120分） | システム自動集約（0分） | 100%削減 |
| 実績データ収集 | 手動収集（240分） | システム自動取得（30分） | 87.5%削減 |
| レポート作成 | 手動作成（240分） | システム自動生成（24分） | 90%削減 |
| 減価償却計算 | 手動計算（60分） | 自動計算（60分） | 精度向上 |
| 予算案チェック | 人的判断 | ルールベース+例外処理 | 自動チェック導入 |

※詳細は別紙「業務要件_asis_tobe.md」の第3章を参照

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

業務要件は5つの主要領域に分類され、各領域で以下の業務プロセスを対象とする:

1. **予算管理（10業務）**: 予算策定から承認までの一連のプロセス
2. **実績管理（4業務）**: 実績データの収集と処理
3. **予算実績比較（7業務）**: 差異分析とレポーティング
4. **固定資産管理（3業務）**: 固定資産台帳管理と減価償却
5. **棚卸資産管理（5業務）**: 棚卸データ収集から評価まで
6. **税務管理（8業務）**: 税務計算と申告書類作成
7. **連結会計（6業務）**: 内部取引照合と連結決算

※詳細は別紙「業務要件_asis_tobe.md」の第1-2章を参照

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

**人的リソース**:

| ステークホルダー | ToBe役割 | 変更点 |
|------------------|----------|--------|
| 経理担当者 | システム設定・管理、承認・確認作業、例外処理対応、分析業務 | 手作業→システム操作、データ入力→分析業務 |
| 経理部長 | 予算案承認、各種レポート確認 | 変更なし |
| 各部門担当者 | システム上での予算案作成、原価・棚卸データ提出 | 表計算→システム入力 |
| 税理士 | 税務申告書類の確認 | 変更なし |

**システムリソース**:

| システム | ToBe役割 |
|----------|----------|
| 会計システム | 会計データの記録・管理、統合会計システムとの連携（マスターシステム） |
| 統合会計システム（新規） | 予算管理、自動集計・計算、自動レポート生成、データ連携ハブ、ワークフロー管理 |

※詳細は別紙「業務要件_asis_tobe.md」の第4章を参照

---

## 3. 機能要件

### 3.1 機能一覧の概要

本システムは全51機能で構成され、以下の9つの機能分類に整理される:

| 分類 | 機能数 | 主要機能 |
|------|--------|----------|
| 予算管理 | 10 | 予算テンプレート管理、予算承認ワークフロー、予算シミュレーション |
| 実績管理 | 4 | 実績データ自動取得、部門別実績データ抽出 |
| 予算実績比較 | 7 | 予算実績差異計算、レポート自動生成、アラート管理 |
| 固定資産管理 | 3 | 固定資産台帳管理、減価償却計算、減価償却仕訳作成 |
| 棚卸資産管理 | 5 | 棚卸資産データ収集、評価、差異調査 |
| 税務管理 | 8 | 税務関連データ収集、税金計算、申告書類作成 |
| 連結会計 | 6 | 内部取引照合、連結仕訳作成、連結財務諸表作成 |
| データ管理 | 1 | データインポート/エクスポート |
| システム連携 | 2 | 外部システム連携API、データ形式変換 |
| マスタ管理 | 3 | 勘定科目・ユーザー・部門マスタ管理 |
| ダッシュボード | 2 | 予算管理・部門別収支ダッシュボード |

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

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

**予算管理機能**:
予算テンプレートのシステム設定により、部門担当者がシステム上で予算案を作成し、経理担当者が自動集約・チェックを実施する。予算承認ワークフローにより、経理部長の承認を経て予算を確定する。予算シミュレーション機能により、複数シナリオでの予算計画が可能。

**実績管理機能**:
会計システムから実績データを自動取得し、部門別・勘定科目別に抽出・表示する。内部取引データと税務関連データの処理機能により、連結会計と税務処理への連携を実現する。

**予算実績比較機能**:
予算と実績の差異を自動計算し、要因分析を実施する。閾値を超えた場合はアラートを自動生成し、関係者に通知する。標準レポートの自動生成とカスタムレポート作成機能により、多様なレポーティングニーズに対応する。

**資産管理機能**:
固定資産台帳をシステムで一元管理し、減価償却費を自動計算する。棚卸資産データを収集・集計し、複数の評価方法に対応した評価額計算を実施する。差異調査機能により、棚卸差異の原因追跡を支援する。

**税務管理機能**:
税務関連データを自動収集し、消費税・法人税・地方税の計算を実施する。法定様式に準拠した税務申告書類を自動生成し、修正・提出管理機能により申告プロセスを効率化する。

**連結会計機能**:
グループ会社間の内部取引データを収集・照合し、差異調整を実施する。連結仕訳を自動作成し、連結財務諸表を生成する。修正機能により、経理部長のフィードバックに基づく調整が可能。

### 3.3 画面遷移概要

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

1. **予算管理フロー**: 部門予算案一覧 → 予算案自動集約 → 予算案チェック結果 → 全社予算案確認 → 予算確定通知
2. **実績管理フロー**: 実績データ自動取得 → 部門別実績データ一覧
3. **予算実績比較フロー**: 予算実績差異計算 → 予算実績レポート生成 → 予算実績レポート閲覧
4. **ダッシュボード**: 予算管理ダッシュボード、部門別収支ダッシュボード（各種機能へのリンク）

各画面は共通のナビゲーションメニューからアクセス可能で、ロールベースアクセス制御により、ユーザーの権限に応じた画面のみが表示される。

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

**会計システム連携**:
- **連携方式**: REST API（同期/非同期）
- **連携データ**: 実績データ、勘定科目マスタ、部門マスタ
- **連携頻度**: 実績データ（日次自動取得）、マスタデータ（変更時）
- **認証方式**: OAuth 2.0 / 相互TLS認証

**データインポート/エクスポート**:
- **対応形式**: CSV、Excel、PDF
- **対象データ**: 予算データ、実績データ、レポート、マスタデータ
- **処理方式**: 画面からのアップロード/ダウンロード、バッチ処理

**データ形式変換**:
異なるシステム間でのデータ形式の標準化と互換性確保を実施し、データ連携の信頼性を向上させる。

---

## 4. 非機能要件

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

本システムの非機能要件は、可用性、性能・拡張性、運用・保守性、移行性、セキュリティ、環境・エコロジーの6つの観点から定義されている。24時間365日稼働を前提とし、年間稼働率99.9%以上を目標とする高可用性システムとして設計する。

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

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

**性能要件**:
- **レスポンス時間**: 画面表示3秒以内、データ検索5秒以内、レポート生成30秒以内（95%ile）
- **バッチ処理時間**: 実績データ自動取得30分以内、連結決算処理180分以内
- **同時接続**: 通常時100ユーザー、ピーク時300ユーザー
- **データ処理**: トランザクション100件/秒、予算データ100万件/日、実績データ500万件/日

**可用性要件**:
- **年間稼働率**: 99.9%以上（計画停止を除く）
- **目標復旧時間（RTO）**: 4時間以内
- **目標復旧時点（RPO）**: 15分以内
- **冗長構成**: アプリケーションサーバーN+1、データベースActive-Standby、ネットワーク機器冗長化
- **バックアップ**: フルバックアップ（日次）、差分バックアップ（4時間ごと）、トランザクションログ（15分ごと）

**拡張性要件**:
- **データ量**: 初期500GB、年間増加300GB、5年後想定2TB
- **スケーリング**: アプリケーションサーバー・Webサーバーの水平スケーリング対応
- **アーキテクチャ**: マイクロサービスアーキテクチャ、APIファーストアプローチ
- **将来対応**: クラウド移行、会計基準変更、AI予測分析機能追加を想定

※詳細は別紙「erp_accounting_非機能要件定義書.md」の第2-3章を参照

### 4.3 運用・保守要件のサマリ

**運用管理**:
- **システム監視**: 死活監視・リソース監視・アプリケーション監視（5分間隔）
- **ログ管理**: アプリケーション・システム・アクセス・セキュリティログ（オンライン2年、アーカイブ10年）
- **アラート**: 重大度に応じた通知（メール、SMS、チャット、電話）

**保守性**:
- **パッチ適用**: セキュリティパッチ（重要度に応じて最大1週間以内）、機能改善パッチ（月次）
- **バージョンアップ**: マイナー（四半期に1回）、メジャー（年1回）
- **テスト環境**: 開発・テスト・ステージング・本番の4環境

**障害対応**:
- **監視体制**: 24時間365日、オンコール担当者配置
- **障害報告**: 初回報告30分以内、進捗報告2時間ごと、障害報告書3営業日以内
- **ヘルプデスク**: 平日8:00～18:00、電話・メール・チャット対応

※詳細は別紙「erp_accounting_非機能要件定義書.md」の第4章を参照

### 4.4 移行要件のサマリ

**データ移行**:
- **対象データ**: 勘定科目・部門・ユーザーマスタ、過去3年分の予算・実績データ、過去7年分の税務関連データ
- **移行方法**: データ抽出ツール開発、クレンジング・変換処理、段階的移行（マスタ→過去データ→最新データ）
- **スケジュール**: 移行計画策定3か月、ツール開発2か月、テスト移行3か月、本番移行3日間

**システム切替**:
- **切替方式**: カットオーバー方式
- **切替時期**: 年度末締め処理完了後の休日
- **並行運用**: 3か月間、全業務対象、新旧システムの出力結果突合せ

**ユーザートレーニング**:
- **トレーニング計画**: 管理者向け（切替2か月前）、一般ユーザー向け（切替1か月前）、リフレッシュ（切替後1か月）
- **トレーニング方法**: 集合研修、e-ラーニング、ハンズオン研修、マニュアル提供

※詳細は別紙「erp_accounting_非機能要件定義書.md」の第5章を参照

---

## 5. システム構成

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

本システムは、AWSを中心としたクラウドネイティブなアーキテクチャを採用する。マイクロサービスアーキテクチャの原則に基づき、機能ごとに独立したスケーリングが可能な設計とする。3層アーキテクチャ（プレゼンテーション層、アプリケーション層、データ層）を基本とし、各層で適切な技術スタックを採用する。

**アーキテクチャの特徴**:
- **マルチAZ構成**: すべての主要コンポーネントを複数のアベイラビリティゾーンに配置
- **ステートレス設計**: アプリケーション層のステートレス化による水平スケーリング対応
- **非同期処理**: Amazon MQによるメッセージキューイングで大量データ処理を実現
- **キャッシング戦略**: ElastiCache（Redis）によるセッション管理とデータキャッシュ
- **API Gateway**: 外部システム連携のための統一的なAPIエンドポイント提供

※詳細は別紙「erp_accounting_インフラ設計・構成図.md」の第3章を参照

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

**ネットワーク構成**:
- **VPC**: 複数AZにまたがる構成
- **サブネット**: パブリック（ALB、NAT Gateway）、プライベート（EC2、RDS、ElastiCache）、管理用
- **DNS**: Amazon Route 53によるヘルスチェック連動フェイルオーバー

**コンピューティング層**:
- **EC2**: t3.large（初期構成）、Auto Scaling（最小2台、最大10台）、Amazon Linux 2
- **コンテナオプション**: ECS/Fargateによるコンテナ化構成も選択可能

**データ層**:
- **Amazon Aurora PostgreSQL**: マルチAZ構成（マスター/スレーブ）、db.r5.large、初期100GB自動スケーリング
- **ElastiCache (Redis)**: マルチAZ構成、cache.m5.large、セッション管理・キャッシュ用
- **Amazon S3**: 静的アセット、バックアップ、データエクスポート/インポート用

**アプリケーション統合**:
- **Amazon MQ (ActiveMQ)**: 非同期処理、イベント駆動型処理のメッセージキュー
- **Amazon OpenSearch Service**: 高速検索、ログ分析・監視データ収集

**デリバリー層**:
- **ALB**: SSL終端、ヘルスチェック、マルチAZ配置
- **CloudFront**: 静的コンテンツキャッシュ配信、WAF統合

※詳細は別紙「erp_accounting_インフラ設計・構成図.md」の第3章を参照

### 5.3 技術スタック

| 層 | 技術要素 |
|-----|----------|
| フロントエンド | React / Vue.js、TypeScript、Material-UI / Ant Design |
| アプリケーション | Java (Spring Boot) / Node.js (Express)、RESTful API、GraphQL |
| データベース | Amazon Aurora PostgreSQL 13以上 |
| キャッシュ | Redis 6.x |
| メッセージキュー | Amazon MQ (ActiveMQ) |
| 検索エンジン | Amazon OpenSearch Service |
| CI/CD | AWS CodePipeline、CodeBuild、CodeDeploy |
| 監視 | CloudWatch、X-Ray、GuardDuty |
| IaC | Terraform / CloudFormation |

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

| 環境 | 用途 | 構成 | アクセス制限 |
|------|------|------|-------------|
| 開発環境 | 開発・単体テスト | シングルAZ、最小構成 | 開発チームのみ |
| テスト環境 | 結合テスト | シングルAZ、中規模構成 | 開発チーム、テストチーム |
| ステージング環境 | システムテスト、受入テスト | 本番相当のマルチAZ構成 | 開発チーム、テストチーム、ユーザー代表 |
| 本番環境 | 本番運用 | マルチAZ、冗長化構成 | 運用チーム、全ユーザー |

**環境間のデータ連携**:
- 本番データをマスキングしてテスト環境に提供
- ステージング環境は本番環境と同等のデータ量でテスト実施
- 環境間のデータ同期は自動化ツールで管理

※詳細は別紙「erp_accounting_インフラ設計・構成図.md」の第7章を参照

---

## 6. セキュリティ

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

本システムのセキュリティ設計は、高い機密性が求められる会計データを扱うシステムとして、多層的なセキュリティ対策を実装する。認証・認可、インフラセキュリティ、データセキュリティ、アプリケーションセキュリティ、監査・ログ、脆弱性管理、インシデント対応、コンプライアンス対応の8つの観点から包括的なセキュリティ対策を講じる。

**セキュリティの基本方針**:
- **多要素認証**: 管理者および特権ユーザーに対するMFA必須化
- **最小権限の原則**: ロールベースアクセス制御による適切な権限付与
- **データ暗号化**: 保存時・転送時の両方でデータを暗号化
- **多層防御**: ネットワーク層、アプリケーション層、データ層での多重防御
- **監査証跡**: すべての重要操作のログ記録と長期保存（10年）

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

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

**認証設計**:
- **ユーザー認証**: 多要素認証（MFA）、パスワードポリシー（最小12文字、複雑性要件、90日有効期限）、アカウントロック（5回連続失敗で30分）
- **シングルサインオン**: AWS IAM Identity Center統合、社内Active Directory連携
- **API認証**: OAuth 2.0 / OpenID Connect、APIキーローテーション、クライアント証明書による相互TLS認証

**認可設計**:
- **ロールベースアクセス制御（RBAC）**: システム管理者、経理部長、経理担当者、各部門担当者、税理士、監査者の6ロール
- **データアクセス制御**: 部門別アクセス制限、機能別アクセス制限、データ項目レベルの制御
- **権限分離**: 職務分掌に基づく権限分離、特権ID管理

**セッション管理**:
- セキュアなセッションID生成
- セッションタイムアウト30分
- セッション固定化攻撃対策

※詳細は別紙「erp_accounting_セキュリティ設計書.md」の第3章を参照

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

**保存データの暗号化**:
- **データベース暗号化**: Amazon Aurora PostgreSQLの保存時暗号化、AWS KMSによる鍵管理
- **ストレージ暗号化**: S3バケットのサーバーサイド暗号化、EBSボリューム暗号化
- **バックアップ暗号化**: RDSスナップショット、S3バックアップの暗号化

**通信データの暗号化**:
- **TLS 1.2以上の強制**: TLS 1.0/1.1無効化、強力な暗号スイート使用
- **HSTS実装**: HTTP Strict Transport Security
- **VPN接続**: 社内ネットワークとAWS間のサイト間VPN、リモートアクセス用クライアントVPN

**機密データ保護**:
- **データ分類**: 個人情報、財務データ、税務情報の分類と重要度に応じた保護
- **データマスキング**: 非本番環境での個人情報・機密情報マスキング、権限に応じた表示制御
- **データ漏洩防止（DLP）**: S3オブジェクトのパブリックアクセス禁止、異常な大量データアクセス検知

**監査・ログ**:
- **監査ログ取得**: ユーザーアクティビティ、システム変更、データ変更の全記録
- **ログ保存**: オンライン3か月、アーカイブ7年（税務要件対応）
- **セキュリティ監視**: GuardDutyによる脅威検知、CloudTrailによるAPI操作監視、CloudWatch Alarmsによる異常検知

※詳細は別紙「erp_accounting_セキュリティ設計書.md」の第4-5章を参照

---

## 7. テスト計画

### 7.1 テスト方針概要

本システムのテストは、システム要件に沿った機能が正しく実装されていること、ユーザビリティ・性能・セキュリティの各要件を満たしていること、データの整合性が確保されていることを検証する。テストは単体テスト、結合テスト、システムテスト、受入テストの4段階で実施し、優先度に基づいた効率的なテスト実施を行う。

**テストの目的**:
1. システム要件に沿った機能の正しい実装を検証
2. ユーザビリティが要件を満たしていることを確認
3. 性能要件の充足を確認
4. セキュリティ要件の充足を確認
5. データの整合性を確保

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

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

**単体テスト**:
- **実施範囲**: 各機能単位
- **テスト内容**: 入力値妥当性検証、出力結果妥当性検証、エラーハンドリング、境界値テスト
- **実施期間**: 4週間
- **担当**: 開発チーム

**結合テスト**:
- **実施範囲**: 複数機能の連携部分
- **テスト内容**: 機能間データ連携、処理フロー、エラー時挙動
- **実施期間**: 3週間
- **担当**: 開発チーム、テストチーム

**システムテスト**:
- **実施範囲**: システム全体
- **テスト内容**: 機能要件充足確認、非機能要件（性能・セキュリティ）充足確認、エンドツーエンドシナリオテスト
- **実施期間**: 4週間
- **担当**: テストチーム

**受入テスト**:
- **実施範囲**: ユーザー視点での全業務シナリオ
- **テスト内容**: 業務シナリオテスト、ユーザビリティテスト、運用手順確認
- **実施期間**: 2週間
- **担当**: ユーザー代表、テストチーム

**テスト環境**:
- **ハードウェア**: クラウド環境（AWS/Azure）、Windows PC、Mac、タブレット端末
- **ソフトウェア**: Windows、macOS、iOS、Android、主要ブラウザ（Chrome、Edge、Safari、Firefox）
- **テストデータ**: 模擬予算・実績・固定資産・棚卸資産・内部取引・税務関連データ

※詳細は別紙「erp_accounting_テスト方針書.md」の第4-6章を参照

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

**テスト開始基準**:
- 開発フェーズの完了
- テスト環境の構築完了
- テストデータの準備完了
- テスト仕様書の完成

**テスト完了基準**:
- すべての高優先度テスト項目が実施され、重大な障害が解消されていること
- 中優先度テスト項目の90%以上が実施され、重要な障害が解消されていること
- 低優先度テスト項目の70%以上が実施されていること
- 残存障害の影響度と対応計画が明確になっていること

**テスト優先度**:
- **高優先度**: 予算テンプレート管理、予算承認ワークフロー、実績データ自動取得、予算実績差異計算、減価償却計算、税金計算、内部取引照合、アクセス権設定など（20項目）
- **中優先度**: レポート自動生成、アラート管理、棚卸差異調査、税務申告書類作成、外部システム連携APIなど（15項目）
- **低優先度**: 予算シミュレーション、レポート配信設定、税務関連書類保管など（5項目）

**品質指標**:
- **機能カバレッジ**: 高優先度100%、中優先度90%以上、低優先度70%以上
- **バグ密度**: 重大バグ0件、高優先度バグ5件以下/1,000行
- **テスト実施率**: 計画テストケースの95%以上実施
- **自動化率**: 回帰テストの70%以上を自動化

※詳細は別紙「erp_accounting_テスト方針書.md」の第5-9章を参照

---

## 8. スケジュール

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

| No. | マイルストーン | 期間 | 主要成果物 |
|-----|----------------|------|------------|
| M1 | 要件定義完了 | 3か月 | 要件定義書、機能要件一覧、非機能要件定義書 |
| M2 | 基本設計完了 | 2か月 | 基本設計書、画面設計書、データベース設計書 |
| M3 | 詳細設計完了 | 2か月 | 詳細設計書、インターフェース設計書 |
| M4 | 開発・単体テスト完了 | 5か月 | プログラム、単体テスト結果 |
| M5 | 結合テスト完了 | 3か月 | 結合テスト結果、障害管理表 |
| M6 | システムテスト完了 | 4か月 | システムテスト結果、性能テスト結果 |
| M7 | 受入テスト完了 | 2か月 | 受入テスト結果、ユーザートレーニング完了 |
| M8 | データ移行完了 | 1か月 | 移行データ、移行結果報告書 |
| M9 | 本番稼働 | - | 本番稼働報告書 |

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

**要件定義フェーズ（3か月）**:
現行業務の詳細分析、ユーザーヒアリング、業務要件の整理、機能要件・非機能要件の定義を実施する。ステークホルダーとの合意形成を重視し、要件定義書の承認を得る。

**設計フェーズ（4か月）**:
基本設計では、システム全体のアーキテクチャ、画面設計、データベース設計を実施する。詳細設計では、各機能の詳細仕様、インターフェース仕様、バッチ処理仕様を定義する。設計レビューを複数回実施し、品質を確保する。

**開発・テストフェーズ（12か月）**:
開発と単体テスト（5か月）、結合テスト（3か月）、システムテスト（4か月）を段階的に実施する。アジャイル開発手法を部分的に取り入れ、優先度の高い機能から順次開発・テストを進める。CI/CDパイプラインを構築し、継続的なテストとデプロイを実現する。

**移行・受入フェーズ（3か月）**:
受入テスト（2か月）と並行してデータ移行準備を進め、最終的にデータ移行（1か月）を実施する。ユーザートレーニングを段階的に実施し、本番稼働に向けた準備を整える。並行運用期間（3か月）を設け、システムの安定性を確認する。

**本番稼働・安定化フェーズ（3か月）**:
本番稼働後3か月間を安定化期間とし、障害対応、問い合わせ対応、軽微な改善を実施する。運用体制を確立し、定常運用への移行を完了する。

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

本プロジェクトのクリティカルパスは以下の通り:

1. **要件定義 → 基本設計 → 詳細設計**: 設計フェーズの遅延は全体スケジュールに直接影響
2. **データベース設計 → データ移行ツール開発**: データ移行の前提となる設計完了が必須
3. **外部システム連携設計 → 連携開発 → 連携テスト**: 外部システムとの調整が必要で遅延リスクが高い
4. **コア機能開発 → 結合テスト → システムテスト**: 予算管理、実績管理、予算実績比較の3機能は相互依存性が高い
5. **データ移行テスト → 本番データ移行**: 移行の成否がカットオーバーに直結

**リスク対策**:
- 外部システム連携は早期に仕様確定し、モックを活用して並行開発を進める
- データ移行は3回のテスト移行を実施し、手順とツールの完成度を高める
- コア機能は優先的にリソースを配分し、早期にプロトタイプを作成してユーザーフィードバックを得る
- 定期的なマイルストーンレビューを実施し、遅延の早期検知と対策を講じる

**スケジュール短縮オプション**:
- アジャイル開発手法の全面適用によるフェーズの並行化
- クラウドサービス（SaaS）の活用による開発範囲の削減
- オフショア開発の活用によるリソース増強

---

## 9. リスク管理

### 9.1 プロジェクトリスク

| リスク項目 | 影響度 | 発生確率 | 対策 |
|-----------|--------|----------|------|
| 要件変更の多発 | 高 | 中 | 要件凍結期限の設定、変更管理プロセスの厳格化 |
| 外部システム連携の遅延 | 高 | 中 | 早期の仕様確定、モックの活用、定期的な進捗確認 |
| データ移行の失敗 | 高 | 低 | 複数回のテスト移行、切戻し手順の準備、専門家の支援 |
| 性能要件未達 | 中 | 中 | 早期の性能テスト実施、アーキテクチャレビュー、チューニング期間の確保 |
| セキュリティ脆弱性 | 高 | 低 | セキュアコーディング、定期的な脆弱性診断、ペネトレーションテスト |
| キーパーソンの離脱 | 中 | 低 | ナレッジの文書化、複数担当制、定期的な引継ぎ |
| ユーザー受入の遅延 | 中 | 中 | 早期のプロトタイプ提示、定期的なデモ、段階的なトレーニング |

### 9.2 技術リスク

| リスク項目 | 影響度 | 発生確率 | 対策 |
|-----------|--------|----------|------|
| AWSサービスの制限 | 中 | 低 | 事前の制限値確認、必要に応じた上限緩和申請 |
| データベースパフォーマンス | 中 | 中 | 適切なインデックス設計、クエリ最適化、読み取りレプリカの活用 |
| バッチ処理の時間超過 | 中 | 中 | 処理の並列化、段階的な処理実行、リソースの増強 |
| 障害復旧の失敗 | 高 | 低 | 定期的なDRテスト、手順書の整備、自動化ツールの活用 |

### 9.3 運用リスク

| リスク項目 | 影響度 | 発生確率 | 対策 |
|-----------|--------|----------|------|
| 運用体制の未整備 | 高 | 中 | 早期の運用設計、運用マニュアル整備、運用トレーニング実施 |
| 障害対応の遅延 | 中 | 中 | 24時間365日監視体制、エスカレーションルート明確化、定期訓練 |
| バックアップの失敗 | 高 | 低 | 自動バックアップ、定期的なリストアテスト、監視アラート設定 |

---

## 10. 前提条件と制約事項

### 10.1 前提条件

1. **既存システム**: 会計システムは稼働中であり、API連携が可能である
2. **ネットワーク**: 社内ネットワークとAWS間のVPN接続が確立されている
3. **認証基盤**: 社内Active Directoryが稼働しており、SSO連携が可能である
4. **データ**: 過去3年分の予算・実績データが電子データとして存在する
5. **ユーザー**: 経理担当者はExcel、会計システムの基本操作が可能である
6. **プロジェクト体制**: プロジェクトマネージャー、システムアーキテクト、開発チーム、テストチームが確保されている
7. **予算**: プロジェクト予算が承認されており、必要なリソースの調達が可能である

### 10.2 制約事項

1. **法令遵守**: 会社法、金融商品取引法、個人情報保護法、電子帳簿保存法への準拠が必須
2. **会計基準**: 日本の会計基準（企業会計原則）に準拠すること
3. **税制**: 現行の税制（消費税、法人税、地方税）に対応すること
4. **データ保持期間**: 税務要件に基づき、最低7年間のデータ保持が必要
5. **稼働時間**: 月末・四半期末・年度末の業務繁忙期には停止不可
6. **予算制約**: プロジェクト予算の範囲内でシステムを構築すること
7. **スケジュール**: 次年度予算策定開始前（10月）までに本番稼働すること
8. **既存システム**: 会計システムの大幅な改修は不可、API連携のみ可能
9. **セキュリティ**: 社内セキュリティポリシーへの準拠が必須
10. **ブラウザ対応**: Internet Explorerのサポートは不要（モダンブラウザのみ対応）

---

## 11. 承認

本要件定義書は、以下の承認者による承認をもって確定とする。

| 役割 | 氏名 | 承認日 | 署名 |
|------|------|--------|------|
| プロジェクトスポンサー |  |  |  |
| 経理部長 |  |  |  |
| システム部長 |  |  |  |
| プロジェクトマネージャー |  |  |  |

---

## 付録

### A. 略語一覧

| 略語 | 正式名称 |
|------|----------|
| ERP | Enterprise Resource Planning（統合基幹業務システム） |
| API | Application Programming Interface |
| AWS | Amazon Web Services |
| VPC | Virtual Private Cloud |
| EC2 | Elastic Compute Cloud |
| RDS | Relational Database Service |
| ALB | Application Load Balancer |
| MFA | Multi-Factor Authentication（多要素認証） |
| SSO | Single Sign-On（シングルサインオン） |
| RBAC | Role-Based Access Control（ロールベースアクセス制御） |
| TLS | Transport Layer Security |
| RTO | Recovery Time Objective（目標復旧時間） |
| RPO | Recovery Point Objective（目標復旧時点） |
| CI/CD | Continuous Integration / Continuous Delivery |
| DLP | Data Loss Prevention（データ漏洩防止） |

### B. 参照資料

1. 業務要件_asis_tobe.md
2. erp_accounting_機能要件一覧.csv
3. erp_accounting_非機能要件定義書.md
4. erp_accounting_インフラ設計・構成図.md
5. erp_accounting_セキュリティ設計書.md
6. erp_accounting_テスト方針書.md

### C. 改訂履歴

| 版数 | 改訂日 | 改訂内容 | 改訂者 |
|------|--------|----------|--------|
| 1.0 | 2024年 | 初版作成 |  |