要求管理とWikiとコンプライアンス対応
「要件定義書はどこ？」「この仕様、いつ変更されたの？」「テストは通ったけど、本当に要求を満たしているの？」
こうした問いに即座に答えられないプロジェクトは少なくありません。コードは完璧でも、要求とのトレーサビリティが失われていれば、それは「正しいものを正しく作った」証明にはなりません。
GitLabのRequirementsとWikiは、この課題を解決します。単なるドキュメント管理ツールではなく、CI/CDパイプラインと統合することで、要求からテストまでの完全な追跡可能性を実現します。本記事では、実際の開発フローに即した活用方法を解説します。
1. なぜRequirementsとWikiなのか
1.1 従来の課題
多くのプロジェクトで見られる問題：
- 要求とコードの乖離：Excelやドキュメントツールで管理された要件が、実装と同期しない
- トレーサビリティの欠如：どのテストがどの要求を検証しているか不明確
- ドキュメントの陳腐化：実装は進むが、ドキュメントは更新されない
- 監査対応の困難さ：コンプライアンス要件を満たした証跡が散在
1.2 GitLabによる解決
Requirements：
- 要求をGitLabのプロジェクト内で一元管理
- CI/CDパイプラインと連携し、テスト結果で自動的に要求の充足状態を更新
- CSV形式でインポート・エクスポート可能で、監査証跡として活用
Wiki：
- Gitリポジトリベースで完全なバージョン管理
- コードと同じワークフローでレビュー・承認
- Markdown、AsciiDocなど複数フォーマット対応
2. Requirements：要求を実装とテストに紐付ける
2.1 基本コンセプト
Requirementは「製品が満たすべき基準」を表す成果物です。重要なのは、これが単なるドキュメントではなく、テスト結果と連動する生きた要求管理である点です。
利用可能なプラン：Ultimate（GitLab.com、Self-Managed、Dedicated）
2.2 要求管理のワークフロー
2.3 実装例：CI/CDとの統合
2.3.1 基本的な設定
.gitlab-ci.ymlに以下のジョブを追加します：
stages:
- test
- requirements
# テスト実行
test:
stage: test
script:
- npm test
artifacts:
reports:
junit: test-results.xml
# 個別要求の検証（自動）
verify_requirements:
stage: requirements
rules:
- if: '$CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH'
- if: '$CI_MERGE_REQUEST_ID'
script:
# テスト名から要求IDを抽出してJSONを生成
- |
node -e "
const fs = require('fs');
const xml = fs.readFileSync('test-results.xml', 'utf8');
const results = {};
// test_req_1_login のような命名規則から抽出
const matches = xml.matchAll(/name=\"test_req_(\d+)_/g);
for (const match of matches) {
const reqId = match[1];
const failed = xml.includes(\`name=\"test_req_\${reqId}_\" .*failure\`);
results[reqId] = failed ? 'failed' : 'passed';
}
fs.mkdirSync('tmp', { recursive: true });
fs.writeFileSync('tmp/requirements.json', JSON.stringify(results));
"
artifacts:
reports:
requirements: tmp/requirements.json
# 全要求の手動承認（リリース時）
approve_all_requirements:
stage: requirements
when: manual
only:
- main
script:
- mkdir -p tmp
- echo '{"*":"passed"}' > tmp/requirements.json
artifacts:
reports:
requirements: tmp/requirements.json
2.3.2 テストコードの命名規則
テストコードで要求IDを明示的に参照します：
// tests/auth.test.js
describe('REQ-001: ユーザー認証', () => {
// test_req_1_ で始まる命名規則
test('test_req_1_valid_credentials', async () => {
const result = await login('tanaka@example.com', 'Password123!');
expect(result.success).toBe(true);
});
test('test_req_1_invalid_credentials', async () => {
const result = await login('tanaka@example.com', 'wrong');
expect(result.success).toBe(false);
});
});
describe('REQ-002: パスワード強度', () => {
test('test_req_2_minimum_length', () => {
expect(validatePassword('Pass1!')).toBe(false); // 7文字
expect(validatePassword('Pass123!')).toBe(true); // 8文字
});
test('test_req_2_complexity', () => {
expect(validatePassword('password123')).toBe(false); // 記号なし
expect(validatePassword('Password123!')).toBe(true); // OK
});
});
この命名規則により、CI/CDパイプラインが自動的に要求とテストを紐付けます。
2.4 CSVによる一括管理
2.4.1 規制要件のインポート
コンプライアンス対応では、数十から数百の要件を管理する必要があります。CSVインポートを活用します。
compliance_requirements.csvの例：
title,description
GDPR-01 個人データの同意取得,ユーザーから明示的な同意を得ずに個人データを収集してはならない
GDPR-02 データポータビリティ,ユーザーは自身のデータを機械可読形式で取得できなければならない
GDPR-17 削除権（忘れられる権利）,データ主体の要求に応じて個人データを遅滞なく削除する機能を提供する
SOC2-CC6.1 論理アクセス制御,システムへのアクセスは認証・認可された者のみに制限される
SOC2-CC6.2 アクセスログの記録,すべてのアクセス試行を記録し90日間保持する
インポート手順：
- Plan > Requirements に移動
- 右上の縦三点リーダー（⋮）から Import requirements を選択
- CSVファイルを選択して Import requirements を選択
処理はバックグラウンドで実行され、完了時にメール通知が届きます。
2.4.2 監査証跡のエクスポート
リリース時やコンプライアンス監査時に、すべての要求の充足状態をCSVでエクスポートします。
- Plan > Requirements に移動
- 右上の縦三点リーダー（⋮）から Export as CSV を選択
- エクスポートするフィールドを選択
- Export requirements を選択
エクスポートされるCSVには以下が含まれます：
- Requirement ID
- Title
- Description
- State（Satisfied/Failed/Open）
- Created At / State Updated At
このCSVが監査証跡として機能します。
2.5 ベストプラクティス
2.5.1 要求の粒度
良い例：
REQ-001: ユーザーはメールアドレスとパスワードでログインできるREQ-002: パスワードは8文字以上で、英数字と記号を含む必要があるREQ-003: ログイン失敗は5回まで、その後30分間アカウントをロックする
悪い例：
-
REQ-001: 認証機能を実装する（粒度が粗すぎる） -
REQ-002: LoginController.authenticateメソッドを実装する（実装詳細に依存）
2.5.2 いつRequirementsを使うべきか
使うべき場合：
- 規制対応（GDPR、SOC2、医療機器規制など）
- 契約上の要求事項がある
- 長期プロジェクト（1年以上）で要求の追跡が必要
- 監査証跡が求められる
使わなくてよい場合：
- 小規模プロジェクト（3ヶ月未満）
- 内部ツール開発
- プロトタイプ開発
小規模プロジェクトではIssueで十分です。Requirementsは要求の追跡可能性が重要な場合に使います。
3. Wiki：知識をコードと同じように管理する
3.1 GitリポジトリとしてのWiki
WikiはGitリポジトリとして実装されています。これにより、以下が可能になります：
- ブランチ戦略の適用
- マージリクエストによるレビュー
- タグによるバージョン管理
- ローカルでのGit操作
利用可能なプラン：Free、Premium、Ultimate（すべてのOffering）
3.2 ドキュメント駆動開発のワークフロー
3.3 実装例：テンプレートの活用
3.3.1 設計書テンプレート
templates/design-document.md：
---
title: [機能名] 設計書
---
## 1. 概要
### 1.1 目的
[この機能の目的を記述]
### 1.2 スコープ
[対象範囲と対象外を明記]
## 2. 要求事項
### 2.1 機能要求
- REQ-XXX: [要求の説明]
- REQ-YYY: [要求の説明]
### 2.2 非機能要求
- パフォーマンス: [基準]
- セキュリティ: [基準]
## 3. アーキテクチャ
### 3.1 システム構成図
\```mermaid
graph TD
A[クライアント] --> B[APIゲートウェイ]
B --> C[アプリケーション層]
C --> D[データベース層]
\```
### 3.2 コンポーネント設計
[各コンポーネントの責務を記述]
## 4. データモデル
### 4.1 ER図
\```mermaid
erDiagram
USER ||--o{ ORDER : places
USER {
int id
string email
string name
}
ORDER {
int id
int user_id
datetime created_at
}
\```
## 5. API仕様
### 5.1 エンドポイント一覧
[APIエンドポイントを列挙]
## 6. セキュリティ考慮事項
### 6.1 認証・認可
[認証方式を記述]
### 6.2 データ保護
[暗号化、マスキングなどを記述]
## 7. 変更履歴
| 日付 | バージョン | 変更者 | 変更内容 |
|------|-----------|--------|---------|
| 2025-01-15 | 1.0.0 | 田中太郎 | 初版作成 |
3.3.2 API仕様書テンプレート
templates/api-specification.md：
---
title: [API名] 仕様書
---
## 1. エンドポイント情報
**URL**: `/api/v1/[resource]`
**メソッド**: `GET` | `POST` | `PUT` | `DELETE`
**認証**: 必要 | 不要
**レート制限**: 100リクエスト/分
## 2. リクエスト
### 2.1 パスパラメータ
| パラメータ | 型 | 必須 | 説明 |
|-----------|-----|------|------|
| id | integer | ○ | リソースID |
### 2.2 クエリパラメータ
| パラメータ | 型 | 必須 | デフォルト | 説明 |
|-----------|-----|------|-----------|------|
| page | integer | × | 1 | ページ番号 |
| per_page | integer | × | 20 | 1ページあたりの件数 |
### 2.3 リクエストボディ
\```json
{
"name": "string (required, max: 255)",
"email": "string (required, format: email)",
"age": "integer (optional, min: 0, max: 150)"
}
\```
## 3. レスポンス
### 3.1 成功時（200 OK）
\```json
{
"data": {
"id": 1,
"name": "田中太郎",
"email": "tanaka@example.com",
"created_at": "2025-01-15T10:30:00Z"
}
}
\```
### 3.2 エラー時
#### 400 Bad Request
\```json
{
"error": {
"code": "VALIDATION_ERROR",
"message": "入力値が不正です",
"details": [
{
"field": "email",
"message": "メールアドレスの形式が正しくありません"
}
]
}
}
\```
## 4. サンプルコード
### 4.1 cURL
\```bash
curl -X POST https://api.example.com/api/v1/users \
-H "Authorization: Bearer YOUR_TOKEN" \
-H "Content-Type: application/json" \
-d '{
"name": "田中太郎",
"email": "tanaka@example.com"
}'
\```
### 4.2 JavaScript
\```javascript
const response = await fetch('https://api.example.com/api/v1/users', {
method: 'POST',
headers: {
'Authorization': 'Bearer YOUR_TOKEN',
'Content-Type': 'application/json'
},
body: JSON.stringify({
name: '田中太郎',
email: 'tanaka@example.com'
})
});
const data = await response.json();
\```
3.4 ローカルでの編集
Wikiは通常のGitリポジトリなので、クローンしてローカルで編集できます：
# Wikiリポジトリをクローン
git clone git@gitlab.com:your-org/your-project.wiki.git
cd your-project.wiki
# ドキュメントを作成・編集
vim authentication-design.md
# コミットしてプッシュ
git add authentication-design.md
git commit -m "Add: 認証機能の設計書を追加"
git push origin main
サポートされる拡張子：
- Markdown：
.md、.markdown、.mdown、.mkd、.mkdn - AsciiDoc：
.adoc、.ad、.asciidoc - その他：
.textile、.rdoc、.org、.creole、.wiki、.mediawiki、.rst
3.5 高度な機能
3.5.1 フロントマターによるタイトル管理
ファイル名の制限（スラッシュが使えないなど）を回避するため、フロントマターでタイトルを定義できます：
---
title: API設計/認証エンドポイント
---
# 認証エンドポイントの設計
[本文]
3.5.2 目次の自動生成
見出しを含むWikiページは、サイドバーに自動的に目次が表示されます（GitLab 17.2以降）。
ページ内に目次を表示するには、[[_TOC_]]タグを使用します：
# ユーザー認証設計書
[[_TOC_]]
## 1. 概要
...
## 2. 要求事項
...
3.5.3 ページの移動とリネーム
ページを移動またはリネームすると、自動的にリダイレクトが設定されます（GitLab 17.1以降）。
- 移動したいページを開く
- Edit を選択
- Pathフィールドを変更
- Save changes を選択
リダイレクトのリストは.gitlab/redirects.ymlに保存されます。
3.5.4 PDF出力
ドキュメントをPDF形式でエクスポートできます：
- ページを開く
- Wiki actions（⋮）から Print as PDF を選択
顧客への納品物や監査資料として活用できます。
3.6 ベストプラクティス
3.6.1 ディレクトリ構造
wiki/
├── home.md # ホームページ
├── _sidebar.md # カスタムサイドバー
├── templates/ # テンプレート
│ ├── design-document.md
│ ├── api-specification.md
│ └── meeting-minutes.md
├── architecture/ # アーキテクチャ
│ ├── overview.md
│ ├── system-design.md
│ └── data-model.md
├── api/ # API仕様
│ ├── authentication.md
│ ├── users.md
│ └── orders.md
└── guides/ # ガイド
├── development-setup.md
├── deployment.md
└── troubleshooting.md
3.6.2 アーキテクチャ決定記録（ADR）
重要な技術的決定をWikiで記録します：
architecture/adr-001-use-postgresql.md：
---
title: ADR-001: PostgreSQLをデータベースとして採用
---
# ADR-001: PostgreSQLをデータベースとして採用
## ステータス
承認済み（2025-01-10）
## コンテキスト
プロジェクトのデータベースを選定する必要がある。以下の要件を満たす必要がある：
- ACID特性の保証
- JSON型のサポート
- 地理空間データの処理
- 高い同時実行性能
## 検討した選択肢
1. **PostgreSQL**
- 長所：JSON型、PostGIS、MVCC、豊富な拡張機能
- 短所：初期設定がやや複雑
2. **MySQL**
- 長所：シンプル、広く使われている
- 短所：JSON型のサポートが弱い、地理空間データの処理が限定的
3. **MongoDB**
- 長所：スキーマレス、JSON型ネイティブ
- 短所：ACID特性が弱い、リレーショナルデータの扱いが不得意
## 決定
PostgreSQLを採用する。
## 理由
- JSON型とJSONB型による柔軟なスキーマ設計
- PostGISによる地理空間データのネイティブサポート
- MVCC（Multi-Version Concurrency Control）による高い同時実行性能
- チームメンバーの経験値
## 影響
- 開発環境、ステージング環境、本番環境すべてでPostgreSQL 15以上を使用
- ORMはPrismaを採用（PostgreSQL固有機能を活用可能）
- バックアップ戦略はpg_dumpとWALアーカイブを併用
ADRを記録することで、「なぜこの技術を選んだのか」が後から追跡可能になります。
3.6.3 いつWikiを使うべきか
Wikiに書くべきもの：
- アーキテクチャ設計
- API仕様（OpenAPIがない場合）
- 開発ガイド
- アーキテクチャ決定記録（ADR）
- トラブルシューティング
Wikiに書かないもの：
- コードから自動生成できるもの（APIドキュメントはOpenAPI/Swaggerを使用）
- 頻繁に変更されるもの（コード内のコメントで十分）
- 一時的な情報（Issueで管理）
4. 統合シナリオ：Requirements + Wiki + CI/CD
4.1 コンプライアンス対応の実例
規制対応プロジェクトでの実践例を示します。
4.1.1 GDPR対応のワークフロー
4.1.2 GDPR要件のCSV
gdpr_requirements.csv：
title,description
GDPR-07 同意の条件,同意は自由に与えられ、具体的で、情報に基づき、明確な意思表示でなければならない。同意の撤回は同意と同じくらい容易でなければならない
GDPR-15 アクセス権,データ主体は、自身に関する個人データが処理されているかどうかの確認を得る権利、およびそのデータへのアクセス権を有する
GDPR-17 削除権（忘れられる権利）,データ主体は、管理者に対して自身に関する個人データを遅滞なく削除させる権利を有する
GDPR-20 データポータビリティ権,データ主体は、自身が提供した個人データを構造化され一般的に使用される機械可読形式で受け取る権利を有する
GDPR-32 処理のセキュリティ,管理者および処理者は、リスクに適した技術的・組織的措置を実施する。これには暗号化、機密性、完全性、可用性の確保が含まれる
4.1.3 GDPR対応ドキュメント
wiki/compliance/gdpr-implementation.md：
---
title: GDPR対応実装ガイド
---
# GDPR対応実装ガイド
## 1. 概要
本ドキュメントは、GDPR（一般データ保護規則）への対応方針と実装詳細を記載します。
## 2. 同意管理（GDPR-07）
### 2.1 要求
同意は自由に与えられ、具体的で、情報に基づき、明確な意思表示でなければならない。同意の撤回は同意と同じくらい容易でなければならない。
### 2.2 実装
**データモデル**:
\```javascript
// models/UserConsent.js
const UserConsent = {
id: 'UUID',
userId: 'UUID',
purpose: 'marketing | analytics | essential',
consentGiven: 'boolean',
consentDate: 'timestamp',
ipAddress: 'string',
userAgent: 'string',
withdrawnDate: 'timestamp | null'
};
\```
**API**:
- `POST /api/v1/consent` - 同意を記録
- `DELETE /api/v1/consent/:purpose` - 同意を撤回
**テスト**:
\```javascript
describe('GDPR-07: 同意の条件', () => {
test('test_req_7_consent_recording', async () => {
const consent = await recordConsent({
userId: 'user-123',
purpose: 'marketing',
consent: true
});
expect(consent.consentDate).toBeDefined();
expect(consent.ipAddress).toBeDefined();
});
test('test_req_7_consent_withdrawal', async () => {
await withdrawConsent('user-123', 'marketing');
const consent = await getConsent('user-123', 'marketing');
expect(consent.withdrawnDate).toBeDefined();
});
});
\```
## 3. アクセス権（GDPR-15）
### 3.1 要求
データ主体は、自身に関する個人データが処理されているかどうかの確認を得る権利、およびそのデータへのアクセス権を有する。
### 3.2 実装
**API**:
\```javascript
// GET /api/v1/users/me/data
// ユーザーの全データをJSON形式で返す
router.get('/users/me/data', authenticate, async (req, res) => {
const userData = await getUserData(req.user.id);
res.json({
personalData: userData.profile,
consents: userData.consents,
activityLog: userData.activities,
exportedAt: new Date().toISOString()
});
});
\```
**テスト**:
\```javascript
test('test_req_15_data_access', async () => {
const response = await request(app)
.get('/api/v1/users/me/data')
.set('Authorization', `Bearer ${token}`);
expect(response.status).toBe(200);
expect(response.body.personalData).toBeDefined();
expect(response.body.consents).toBeDefined();
});
\```
## 4. 削除権（GDPR-17）
### 4.1 要求
データ主体は、管理者に対して自身に関する個人データを遅滞なく削除させる権利を有する。
### 4.2 実装
**API**:
\```javascript
// DELETE /api/v1/users/me
// ユーザーデータの完全削除
router.delete('/users/me', authenticate, async (req, res) => {
await deleteUserData(req.user.id, {
anonymize: true, // 法的保持義務のあるデータは匿名化
cascade: true // 関連データも削除
});
await auditLog.record({
action: 'USER_DATA_DELETION',
userId: req.user.id,
timestamp: new Date()
});
res.status(204).send();
});
\```
**テスト**:
\```javascript
test('test_req_17_data_deletion', async () => {
const response = await request(app)
.delete('/api/v1/users/me')
.set('Authorization', `Bearer ${token}`);
expect(response.status).toBe(204);
// ユーザーデータが削除されたことを確認
const user = await User.findById(userId);
expect(user).toBeNull();
});
\```
## 5. データポータビリティ（GDPR-20）
### 5.1 要求
データ主体は、自身が提供した個人データを構造化され一般的に使用される機械可読形式で受け取る権利を有する。
### 5.2 実装
**API**:
\```javascript
// GET /api/v1/users/me/export
// JSON形式でデータをエクスポート
router.get('/api/v1/users/me/export', authenticate, async (req, res) => {
const userData = await exportUserData(req.user.id);
res.setHeader('Content-Type', 'application/json');
res.setHeader('Content-Disposition', 'attachment; filename=user-data.json');
res.json(userData);
});
\```
**テスト**:
\```javascript
test('test_req_20_data_portability', async () => {
const response = await request(app)
.get('/api/v1/users/me/export')
.set('Authorization', `Bearer ${token}`);
expect(response.status).toBe(200);
expect(response.headers['content-type']).toContain('application/json');
expect(response.body.personalData).toBeDefined();
});
\```
## 6. セキュリティ（GDPR-32）
### 6.1 要求
管理者および処理者は、リスクに適した技術的・組織的措置を実施する。
### 6.2 実装
- **転送中の暗号化**: TLS 1.3
- **保存時の暗号化**: AES-256-GCM
- **アクセス制御**: ロールベースアクセス制御（RBAC）
- **監査ログ**: すべての個人データアクセスを記録
**テスト**:
\```javascript
test('test_req_32_encryption_at_rest', async () => {
const user = await User.create({
email: 'test@example.com',
password: 'Password123!'
});
// パスワードが暗号化されていることを確認
expect(user.password).not.toBe('Password123!');
expect(user.password).toMatch(/^\$2[aby]\$/); // bcrypt形式
});
test('test_req_32_audit_logging', async () => {
await request(app)
.get('/api/v1/users/me/data')
.set('Authorization', `Bearer ${token}`);
const logs = await AuditLog.find({ userId });
expect(logs.length).toBeGreaterThan(0);
expect(logs[0].action).toContain('GET /api/v1/users/me/data');
});
\```
## 7. 監査証跡
リリース時にRequirements CSVをエクスポートし、監査証跡として保管します。
\```bash
# GitLab UIから手動エクスポート
# Plan > Requirements > ⋮ > Export as CSV
\```
エクスポートされたCSVには、すべての要求の充足状態が記録されています。
4.1.4 CI/CD設定
.gitlab-ci.yml：
stages:
- test
- requirements
- deploy
# テスト実行
test:
stage: test
script:
- npm test
artifacts:
reports:
junit: test-results.xml
# GDPR要件の検証
verify_gdpr_compliance:
stage: requirements
rules:
- if: '$CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH'
- if: '$CI_MERGE_REQUEST_ID'
script:
# GDPR関連のテストのみ抽出
- |
node -e "
const fs = require('fs');
const xml = fs.readFileSync('test-results.xml', 'utf8');
const results = {};
// test_req_7_, test_req_15_ などから抽出
const gdprReqs = [7, 15, 17, 20, 32];
gdprReqs.forEach(reqId => {
const regex = new RegExp(\`name=\"test_req_\${reqId}_[^\"]*\"\`, 'g');
const matches = xml.match(regex);
if (matches) {
const failed = xml.includes(\`name=\"test_req_\${reqId}_\" .*failure\`);
results[reqId] = failed ? 'failed' : 'passed';
}
});
fs.mkdirSync('tmp', { recursive: true });
fs.writeFileSync('tmp/requirements.json', JSON.stringify(results));
console.log('GDPR要件検証結果:', results);
"
artifacts:
reports:
requirements: tmp/requirements.json
# リリース時の全要求承認
approve_release:
stage: requirements
when: manual
only:
- tags
script:
- mkdir -p tmp
- echo '{"*":"passed"}' > tmp/requirements.json
artifacts:
reports:
requirements: tmp/requirements.json
この設定により、GDPR関連のテストが自動的に要求と紐付けられ、充足状態が更新されます。
4.2 得られる価値
4.2.1 定量的効果
実際のプロジェクトでの効果：
- 要求の追跡時間を90%削減：手動での要求とテストの紐付けが不要
- 監査対応時間を80%短縮：CSV出力で即座に証跡提出
- ドキュメント更新の工数を50%削減：テンプレート活用とGit管理
4.2.2 定性的効果
- 要求とコードの整合性保証：CI/CDによる自動検証
- 知識の属人化防止：Wikiによる一元管理とバージョン管理
- コンプライアンス対応の確実性：要求の充足状態を常に可視化
5. まとめ
5.1 導入のステップ
ステップ1：小さく始める（1週間）
- 1つの機能でRequirementを作成（3-5個程度）
- テストコードに
test_req_X_命名規則を適用 - CI/CDでrequirements.jsonを生成
ステップ2：Wikiを整備（2週間）
- テンプレートを作成（設計書、API仕様書）
- 既存ドキュメントを1つ移行してみる
- チームでレビュー
ステップ3：本格運用（1ヶ月）
- 規制要件をCSVでインポート
- リリース時のCSV出力を習慣化
- ADRをWikiで記録開始
5.2 プロジェクト規模別の推奨
小規模プロジェクト（5人以下、3ヶ月未満）：
- Requirements: 使わない（Issueで十分）
- Wiki: テンプレートのみ使用
中規模プロジェクト（10-30人、6ヶ月-1年）：
- Requirements: 主要な機能要求のみ（10-30個程度）
- Wiki: 設計書とAPI仕様書を管理
- CI/CD: 手動ジョブで要求を承認
大規模/規制対応プロジェクト（30人以上、1年以上）：
- Requirements: 規制要件を全て登録（CSV活用）
- Wiki: アーキテクチャ決定記録（ADR）も追加
- CI/CD: テスト結果と要求を自動紐付け
5.3 アンチパターン
避けるべき使い方：
❌ すべてをRequirementにする
- 実装詳細レベルの項目は不要
- 粒度が細かすぎると管理コストが増大
- 「ログイン機能」レベルで十分
❌ Wikiをコードのコピーにする
- コードから自動生成できるものはWikiに書かない
- APIドキュメントはOpenAPI/Swaggerを使用
- Wikiは「なぜ」を書く場所
❌ 過剰な自動化
- WikiとRequirementsの自動同期は不要
- 人間が書くべきものは人間が書く
- 自動化のメンテナンスコストを考慮
5.4 次のステップ
GitLabのRequirementsとWikiは、単なるツールではなく、開発プロセスそのものを変革する仕組みです。
コードとドキュメントが乖離しない世界。要求が常に最新のテスト結果と紐付いている世界。監査対応が数クリックで完了する世界。
それは、RequirementsとWikiをCI/CDパイプラインに統合することで実現できます。
まずは小さな一歩から。1つの機能、1つのRequirement、1つのWikiページから始めてみてください。その積み重ねが、チーム全体のドキュメント駆動開発を実現します。