Design

Context¶

Teams Board の docs/ ディレクトリには概念モデル（index.md）と技術アーキテクチャ（architecture.md）が存在するが、業務視点のドキュメントが未整備。RIDW カスタマイズドキュメントの規約（CLAUDE.md 記載）に従い、業務定義・業務シナリオを docs/ 配下に追加する。

ドキュメント作成には writing-documents スキルを使用し、実装コード（src/services/, src/pages/）を参照して業務フローとシナリオを正確に記述する。

Goals / Non-Goals¶

Goals:

業務定義2件（参加状況管理業務、グループ情報管理業務）を作成
業務シナリオ3件を作成（メンバー実績確認、グループ実績確認、グループ名称修正）
MkDocs ナビゲーション用 .pages ファイルを作成
業務用語（参加者レポート、取り込み、開催実績）を一貫して使用

Non-Goals:

機能定義・機能シナリオの作成（別フェーズ）
既存ドキュメント（index.md, architecture.md）の変更
ソースコードの変更

Decisions¶

D1: ドキュメント構成¶

CLAUDE.md で定義された RIDW ドキュメント構造に準拠する。

docs/
├── .pages
├── 01.参加状況管理業務/
│   ├── .pages
│   ├── 参加状況管理業務.md
│   ├── 01.参加者レポートの取込とメンバー活動実績の確認.md
│   └── 02.参加者レポートの取込とグループ開催実績の確認.md
└── 02.グループ情報管理業務/
    ├── .pages
    ├── グループ情報管理業務.md
    └── 01.グループ名称の修正.md

理由: RIDW 規約に準拠することで、今後の機能定義追加時にも一貫した構造を維持できる。

D2: 業務シナリオの粒度¶

参加状況管理業務では「取り込み」と「確認」を1つのシナリオにまとめる（管理者と閲覧者のコラボレーション）。

理由: 取り込みのみ、または確認のみでは業務価値が完結しない。管理者の取り込み → 閲覧者の確認、という一連の流れにより業務価値が実現される。

D3: 用語方針¶

業務定義では業務用語を使用し、システム用語を避ける。

業務用語	システム用語
参加者レポート	CSV file (UTF-16LE/TSV)
取り込み	CSV parse + merge + save
開催実績	Session data
参加実績	Attendance data

理由: 業務定義は利用者視点のドキュメントであり、技術的な実装詳細から独立させる。

D4: writing-documents スキルの利用¶

ドキュメント作成には writing-documents スキルを使用する。スキルが RIDW テンプレートに準拠したドキュメントを生成する。

理由: RIDW 規約への準拠を自動化し、テンプレート漏れを防止する。

Risks / Trade-offs¶

[リスク] 実装との乖離 → 実装コード（csv-transformer.js, index-merger.js, index-editor.js, AdminPage.jsx）を直接参照してシナリオステップを記述することで軽減
[リスク] 用語の不統一 → 用語マッピング表を定義し、レビュー時に確認
[トレードオフ] シナリオの詳細度 → システム内部処理（解析・ID生成）も業務シナリオに含める。透明性を優先するが、将来的に機能定義に分離する可能性がある