# 03_development_rules.md
# SPS BACK OFFICE 開発ルール・役割分担マニュアル

**保存先**: `/backoffice/docs/03_development_rules.md`  
**作成日**: 2026-03-18  
**バージョン**: 1.0

---

## 1. 役割構造

```
真柴 直也（オーナー）
  └── 要件定義・最終承認・指示
        ↓
全管理者アシスタント
  └── 設計書管理・整合性確認・担当間調整・ツリー承認
        ├── 会計システム担当アシスタント
        ├── 案件管理システム担当アシスタント
        └── （今後追加）
```

### 1.1 真柴さん（オーナー）の役割
- 「何が欲しいか」を指示する
- 最終承認を行う
- 技術的な整合性の判断は全管理者アシスタントに委ねる

### 1.2 全管理者アシスタントの役割
- 全設計書・ツリーを把握・管理する
- 担当間のデータ構造の依存関係を理解し整合性を担保する
- 「会計がこう変えたら案件管理に影響する」を判断できる
- 共有ファイルの変更を承認する
- 各担当アシスタントへの指示・調整を行う
- ツリー（`01_folder_structure.md`）の最終承認権限を持つ
- **全管理者なしに担当同士が共有ファイルを直接変更することを禁止する**

### 1.3 各担当アシスタントの役割
- 担当領域の設計書・実装を担当する
- 他担当の領域に影響する変更は必ず全管理者に通す
- 共有ファイルを変更した場合は理由を改訂履歴に明記する

---

## 2. 開発フロー

```
真柴さん：「こういう機能が欲しい」
  ↓
全管理者アシスタント
  - 関連する設計書を確認
  - 影響範囲を調査（他担当への影響含む）
  - ツリーを修正（案）
  ↓
真柴さんに確認・承認
  ↓
各担当アシスタントに指示
  - 仕様書を修正
  - 真柴さんに確認・承認
  - ファイルを作成・修正
  ↓
全管理者アシスタントが整合性確認
  ↓
真柴さんに報告・完了
```

**絶対に守る手順：**
```
① ツリー（01_folder_structure.md）を修正
       ↓ 真柴さん確認・承認
② 仕様書（該当の.md）を修正
       ↓ 真柴さん確認・承認
③ ファイルを作成・修正
```

この順番を守らないと仕様とコードがズレる。

---

## 3. 担当別ファイル権限

### 3.1 全管理者アシスタント（全権限）
| ファイル・フォルダ | 権限 |
|------------------|------|
| `docs/01_folder_structure.md` | 読み書き・最終承認 |
| `docs/` 配下の全設計書 | 読み書き |
| 全HTMLファイル | 読み・レビュー |
| 共有マスタJSON | 読み書き（承認後） |

### 3.2 会計システム担当アシスタント
| ファイル・フォルダ | 権限 | 備考 |
|------------------|------|------|
| `common/accounting/` | 読み書き | |
| `private/accounting/` | 読み書き | |
| `corporate/accounting/` | 読み書き | |
| `master/api/save_receipt.php` | 読み書き | OCR・領収書保存 |
| `master/api/ocr_receipt.php` | 読み書き | OCR処理 |
| `docs/07_accounting/` | 読み書き | |
| `docs/03_ui_design/` | 読み書き | UIルールは会計に直結 |
| `index.html` / `login.html` | 読み・修正提案 | 変更は全管理者承認後 |
| `master/*.json` | 読み・追加のみ | 既存フィールドの変更・削除は全管理者承認後 |

### 3.3 案件管理システム担当アシスタント
| ファイル・フォルダ | 権限 | 備考 |
|------------------|------|------|
| `private/cases/` | 読み書き | |
| `corporate/cases/` | 読み書き | |
| `docs/04_business_flow/01_case_management.md` | 読み書き | |
| `master/api/save_receipt.php` | 読みのみ | 会計担当が実装・共用 |
| `master/api/ocr_receipt.php` | 読みのみ | 会計担当が実装・共用 |
| `master/*.json` | 読み・追加のみ | 既存フィールドの変更・削除は全管理者承認後 |

### 3.4 共有ファイルの変更ルール
- **追加はOK**（他担当に影響しないため）
- **既存フィールドの変更・削除は全管理者承認必須**
- 変更した場合は改訂履歴に「担当・理由・影響範囲」を必ず記載

**改訂履歴の書き方：**
```markdown
| 日付 | 版 | 担当 | 内容 | 理由・影響範囲 |
|------|----|------|------|--------------|
| 2026-03-18 | 1.1 | 会計担当 | statusフィールド追加 | 案件管理からの転記データを未確認状態で管理するため。申告集計はconfirmedのみ対象 |
```

### 3.5 設計書（.md）の変更ルール
- 設計書の修正は全体管理者・担当どちらが行ってもよい
- 修正した場合は必ず改訂履歴を記載すること（連絡の代替とする）
- 改訂履歴には「担当・理由・影響範囲」を明記する
- 他担当の設計書を修正した場合は影響範囲を必ず記載する

### 3.6 設計書・マスタの参照URL
- 設計書・マスタJSONの参照先: **`https://docs.scsps.jp/`**
- アシスタントはファイルを受け取る前にまずこのURLを確認する
- `master/` 配下のJSONもこのURLで確認できる状態を維持する
- 設計書を更新したら必ずサーバー上のファイルも更新すること（バージョンの不一致防止）

---

## 4. 全管理者アシスタントへの引き継ぎ情報

### 4.1 必ず読むべき設計書（優先順）
1. `docs/01_folder_structure.md` ← **最初に必ず読む**
2. `docs/03_development_rules.md` ← このファイル
3. `docs/00_overview/00_system_overview.md`
4. `docs/00_overview/02_development_process.md`
5. `docs/07_accounting/` 配下（会計システム全設計）
6. `docs/04_business_flow/` 配下（業務フロー）

### 4.2 現在の担当領域
| 領域 | 担当 | 状態 |
|------|------|------|
| 会計システム | 会計担当アシスタント | 実装中 |
| 案件管理 | 案件管理担当アシスタント | 未着手 |
| 営業管理 | 未定 | 未着手 |
| 労務管理 | 未定 | 一部実装済 |

### 4.3 担当間の共有ポイント（整合性要注意）

**仕訳データと案件管理の接続：**
- `journals` の `case_id` が案件管理の案件IDと紐付く
- 案件管理からの転記データは `status: "pending"` で仕訳帳に入る
- 会計集計は `status: "confirmed"` のみ対象（`pending` は除外）
- 詳細: `docs/07_accounting/11_receipt_ocr.md` 11節

**領収書画像の共用：**
- `save_receipt.php` / `ocr_receipt.php` は会計担当が実装
- 案件管理担当はこれを共用する（独自実装不要）
- 詳細: `docs/07_accounting/11_receipt_ocr.md` 10節

**案件終了条件（会計との連動）：**
- 案件に紐付く全仕訳が `confirmed` かつ全領収書あり（公共交通機関除く）
- これを満たさないと案件終了不可
- 詳細: `docs/07_accounting/11_receipt_ocr.md` 11節

---

## 5. 実装ルール

### 5.1 HTMLファイル
- サンプル・ダミーデータの埋め込み禁止
- データなし状態で正しく動作すること
- アイコン原則不使用（指示がある場合のみ）
- 絵文字使用禁止
- 詳細: `docs/03_ui_design/01_design_guideline.md`

### 5.2 fetchURL
- `/master/accounts.json` → `https://docs.scsps.jp/master/accounts.json`
- その他のマスタ → サーバーの `/master/` を参照（相対パスでOK）

### 5.3 localStorage キー形式
- 仕訳データ: `journals_v2_[会社コード]_[年]`
- 例: `journals_v2_SPS_2024` / `journals_v2_SCSPS_2024`

### 5.4 和暦変換
- 2019年は「令和1年」ではなく「令和元年」
- 法人第1期: 令和元年11月1日設立（2019年が第1期）

---

## 6. 改訂履歴

| 日付 | 版 | 担当 | 内容 | 理由・影響範囲 |
|------|----|------|------|--------------|
| 2026-03-18 | 1.0 | 全管理者 | 初版作成 | この会話での開発ルール・役割分担を文書化 |
| 2026-03-20 | 1.1 | 全体管理者 | 3.5節「設計書の変更ルール」を追加 | 設計書修正時の連絡方法を明確化。改訂履歴への記載を連絡の代替とする |
| 2026-03-20 | 1.2 | 全体管理者 | 3.6節「設計書・マスタの参照URL」を追加 | https://docs.scsps.jp/ をアシスタントの参照先として明記 |