実装とドキュメントの差異を吸収中

This commit is contained in:
Akira
2026-02-18 13:33:25 +09:00
parent d70b5ee551
commit bcb7413bad
2 changed files with 101 additions and 301 deletions

View File

@@ -16,6 +16,9 @@
### 📝 更新義務
**ドキュメントドリブンの徹底**
- ✅ 仕様に変更がある時は、まず関連するドキュメントから更新する事。
**機能追加・変更時は、必ずこのファイルを更新すること。**
- ✅ 新機能実装時 → 「実装状況」セクションを更新
@@ -25,6 +28,7 @@
- ✅ 問題解決時 → 「トラブルシューティング」に追加
- ✅ 更新時は必ず「更新履歴」セクションに記録
**更新を忘れると、次のセッションで情報が失われます。これは最優先事項です。**
---

View File

@@ -1,10 +1,8 @@
# ドキュメント vs 実装 差異レポート
> **作成日**: 2026-02-16
> **最終更新**: 2026-02-17
> **目的**: ドキュメントと実装の差異を洗い出し、対応方針を決定する
>
> 各項目の「対応方針」欄に指示を記入してください。
> 記入例: 「実装する」「ドキュメント削除」「Phase 2に延期」「現状維持」など
---
@@ -15,11 +13,9 @@
- **ドキュメント**: 画面設計書 画面2 - 概要サマリー(全圃場数/作付け済み/未割当)、クイックアクセスボタン、最近の変更履歴
- **実装**: `/` はトークンの有無で `/allocation``/login` にリダイレクトするだけ
- **影響**: なくても作付け計画画面から全機能にアクセス可能。Navbarで各画面に遷移できる
- **状態**: 🔜 未着手
**対応方針**:
```
将来、機能追加する時には、ここにボタンが増えていく形式になっていくはずなので必要です
```
**対応方針**: 将来、機能追加する時には、ここにボタンが増えていく形式になっていくはずなので必要です
---
@@ -28,12 +24,9 @@
- **ドキュメント**: 画面設計書 画面3 - 各行にチェックボックス、複数選択→一括割当
- **実装**: チェックボックスなし、一括操作UI なし
- **補足**: Backend には `POST /api/plans/bulk_update/` APIが既に存在する
- **状態**: 🔜 未着手
**対応方針**:
```
利便性向上の為必要です。
```
**対応方針**: 利便性向上の為必要です。
---
@@ -42,11 +35,9 @@
- **ドキュメント**: ユーザーストーリー P1-5、画面設計書 画面3 - [前年度をコピー]ボタン
- **実装**: Backend API (`POST /api/plans/copy_from_previous_year/`) は存在するが、Frontend にボタンがない
- **影響**: 毎年手動で39筆を設定する必要がある
- **状態**: 🔜 未着手
**対応方針**:
```
必要な項目です。
```
**対応方針**: 必要な項目です。
---
@@ -55,11 +46,9 @@
- **ドキュメント**: 画面設計書 画面4 - [+ 新しい品種を追加]ボタン、その場で入力して即座にマスタ登録
- **実装**: 既存品種からの選択のみ。新品種の追加はDjango管理画面からのみ可能
- **影響**: 運用中に新品種が出てきた場合、管理画面を開く必要がある
- **状態**: 🔜 未着手
**対応方針**:
```
追加出来る事は必要です。削除も出来ないと間違って追加した時に不便です
```
**対応方針**: 追加出来る事は必要です。削除も出来ないと間違って追加した時に不便です
---
@@ -68,11 +57,9 @@
- **ドキュメント**: 画面設計書 画面6 - [プレビュー]ボタンで新タブにPDF表示
- **実装**: ダウンロードボタンのみ(プレビューなし)
- **影響**: ダウンロード前に内容確認ができない
- **状態**: 🔜 未着手
**対応方針**:
```
プレビューしてから保存、もしくは、印刷出来るようにしたいです。
```
**対応方針**: プレビューしてから保存、もしくは、印刷出来るようにしたいです。
---
@@ -81,11 +68,9 @@
- **ドキュメント**: 画面設計書 画面7 - 全圃場データCSV、作付け計画CSV、全データZIPバックアップ
- **実装**: 未実装
- **影響**: バックアップ手段がないDBダンプのみ
- **状態**: 🔜 未着手
**対応方針**:
```
必要です。近い将来サーバーに移行するので、その時に、このローカル環境で設定したデータを移動できるようにしたいです。
```
**対応方針**: 必要です。近い将来サーバーに移行するので、その時に、このローカル環境で設定したデータを移動できるようにしたいです。
---
@@ -94,350 +79,161 @@
- **ドキュメント**: 画面設計書 画面3 - 圃場名・住所で部分一致検索、作物で絞り込み、未割当のみトグル
- **実装**: 並び替え(カスタム順/グループ順/作付け順)のみ。テキスト検索なし
- **影響**: 39筆なので目視でも探せるが、検索があると便利
- **状態**: 🔜 未着手
**対応方針**:
```
優先度は低いですが必要です。
```
**対応方針**: 優先度は低いですが必要です。
---
### A-8: 圃場詳細画面の共済/中山間情報表示
### ~~A-8: 圃場詳細画面の共済/中山間情報表示~~ ✅ 対応済み
- **ドキュメント**: 画面設計書 画面5 - 共済情報(耕地番号/分筆、中山間情報IDを表示
- **実装**: 基本情報(名称、住所、面積、所有者、グループ)の編集のみ
- **影響**: 圃場と申請区画の対応がUI上で確認できない
**対応方針**:
```
これ絶対に必要!
```
- **対応内容**: 圃場詳細画面 (`/fields/[id]`) に共済情報テーブルと中山間情報テーブルを追加
- **対応日**: 2026-02-17
- **確認**: Playwright E2E テストで検証済み
---
## B. 実装されているがドキュメントに記載がないもの
### B-1: グループ機能
### B-1〜B-5: ドキュメント追記対応 ✅ 対応済み
- **実装**: `group_name`(エリア分け)、`display_order`(表示順)フィールド。圃場一覧・作付け計画で並び替え可能
- **ドキュメント**: CLAUDE.md にのみ記載。データ仕様書・画面設計書には未記載
- **経緯**: マイグレーション0004で後から追加された機能
**対応方針**:
```
ドキュメントに追記する / 現状維持
```
---
### B-2: 圃場管理画面(/fields
- **実装**: 圃場一覧(テーブル形式)、グループ編集、表示順変更(上下ボタン)、削除機能
- **ドキュメント**: 画面設計書に独立した画面としての記載なし画面5は「圃場詳細」のみ
**対応方針**:
```
ドキュメントに追記する / 現状維持
```
---
### B-3: 圃場新規作成画面(/fields/new
- **実装**: 手動で圃場を1件ずつ作成可能
- **ドキュメント**: インポートODS/Excelのみ想定。手動作成の記載なし
**対応方針**:
```
ドキュメントに追記する / 現状維持
```
---
### B-4: インライン編集方式(作付け計画)
- **実装**: テーブル内で直接作物・品種・備考を編集(即時保存)
- **ドキュメント**: 画面設計書 画面4 ではモーダルウィンドウでの編集を想定
**対応方針**:
```
実装に合わせてドキュメント更新 / モーダルに変更
```
---
### B-5: Navbarナビゲーションバー
- **実装**: 左サイドに常時表示のナビ(作付け計画、圃場管理、帳票出力、データ取込、ログアウト)
- **ドキュメント**: 画面設計書ではヘッダー内にハンバーガーメニュー(スマホ)を想定
**対応方針**:
```
ドキュメントに追記する / 現状維持
```
以下の項目は 2026-02-17 のドキュメント一斉更新で対応済み:
- **B-1**: グループ機能 → データ仕様書・CLAUDE.md に記載済み
- **B-2**: 圃場管理画面(/fields → 画面設計書に追記済み
- **B-3**: 圃場新規作成画面(/fields/new → 画面設計書に追記済み
- **B-4**: インライン編集方式(作付け計画) → 画面設計書をモーダル→インラインに更新済み
- **B-5**: Navbar → 画面設計書に追記済み
---
## C. ドキュメントと実装で食い違っているもの
### C-1: Field と共済/中山間の関係M:1 vs M:N
### C-1: Field と共済/中山間の関係M:1 vs M:N ✅ 対応済み
- **ドキュメント(データ仕様書)**: M:1ForeignKey- 「複数の実圃場が1つの共済区画に対応」
- **実装**: M:NManyToManyField- 1つの実圃場が複数の申請区画に紐づくケースにも対応
- **CLAUDE.md**: M:N に更新済み
- **影響**: データ仕様書のER図、紐付けロジックのコード例が古い
**対応方針**:
```
データ仕様書を M:N に更新
```
- **対応内容**: データ仕様書を M:N に更新
- **対応日**: 2026-02-17
---
### C-2: 共済マスタのフィールド型
### ~~C-2: 共済マスタのフィールド型~~ ✅ 対応済み
- **ドキュメント**: `k_num` = IntegerField, `s_num` = IntegerField、(k_num, s_num)のペアで一意
- **実装**: `k_num` = CharField(unique=True), `s_num` = CharField(null許容)
- **影響**: 紐付けロジックの仕様が異なる。k_num 単独で一意になっている
**対応方針**:
```
(k_num, s_num) ペアで一意が正しいです
```
- **対応内容**: `k_num` = CharField, `s_num` = CharField に統一。`unique_together = [['k_num', 's_num']]` を設定マイグレーション0005
- **対応日**: 2026-02-17
- **確認**: Playwright E2E テストで重複拒否を検証済み
---
### C-3: 中山間マスタのフィールド型
### C-3: 中山間マスタのフィールド型 ✅ 対応済み
- **ドキュメント**: `c_id` = IntegerField, `chiban` = IntegerField
- **実装**: `c_id` = CharField, `chiban` = CharField
- **影響**: 数値でないデータが入る可能性(実運用で問題ないか要確認)
**対応方針**:
```
数値でないデータが入る可能性あります。イとかロとかがあります
```
- **対応内容**: `c_id` = CharField, `chiban` = CharField で実装。データ仕様書も CharField に更新済み
- **理由**: 地番に「イ」「ロ」等の非数値データが入るため
---
### C-4: 面積フィールドの単位
### ~~C-4: 面積フィールドの単位~~ ✅ 対応済み
- **ドキュメント**: 共済マスタ `area` = m2 (FloatField)、中山間マスタ `area` = m2 (IntegerField)
- **実装**: 両方とも `area` = DecimalField(ha表記)
- **影響**: PDF出力時の面積表示が m2 ではなく ha になっている可能性
**対応方針**:
```
面積の内部表現がm2に統一。表示上は反=10aに統一してください
```
- **対応内容**:
- 共済マスタ・中山間マスタの `area` は IntegerFieldm2に統一
- 共済インポート時に ODS のアール値を m2 に変換 (×100)
- PDF テンプレートの面積表示を m2 に修正
- **対応日**: 2026-02-17
- **発見したバグ**: ODS カラム名 `本地面積 (m2)` のスペース有無でインポートが失敗し全件 area=0 になっていた → 修正済み
---
### C-5: 作物マスタの初期データ
### C-5: 作物マスタの初期データ ✅ 対応済み
- **ドキュメント**: 米、トウモロコシ、エンドウ、野菜、その他
- **実装init_crops.py**: 水稲、大豆、小麦、そば、とうきび
- **品種も全く異なる**:
- ドキュメント: にこまる、たちはるか、たちはるか(特栽)、久留米豊、完全休耕 等
- 実装: コシヒカリ、ひとめぼれ、あきたこまち、つや姫、タマホマレ 等
- **影響**: ドキュメントはユーザー固有のデータだが、init_crops.py は汎用的なサンプルになっている
**対応方針**:
```
初期データはいらないです消して入れなおさなきゃいけない事になっている
どうしても必要なら、今登録されているデータに準拠してください
```
- **対応内容**: `init_crops.py` を削除。作物・品種は管理画面やUIから登録する運用
- **対応日**: 2026-02-17D-2 と同時対応)
---
### C-6: 申請書の出力形式CSV vs PDF
### C-6: 申請書の出力形式CSV vs PDF ✅ 対応済み
- **ドキュメント(複数箇所)**:
- 01_プロダクトビジョン.md: 「申請書水稲共済・中山間のCSV出力」
- 05_実装優先順位.md: 「水稲共済細目書のCSV出力」「中山間交付金のCSV出力」
- 02_ユーザーストーリー.md: 「PDFでダウンロード」
- 04_画面設計書.md: 「PDFダウンロード」
- **実装**: PDF出力WeasyPrint
- **影響**: ドキュメント内で CSV と PDF が混在している
**対応方針**:
```
全ドキュメントをPDFに統一
```
- **対応内容**: 全ドキュメントを PDF に統一
- **対応日**: 2026-02-17
---
### C-7: Django バージョン
### C-7: Django バージョン ✅ 対応済み
- **ドキュメント(統合指示書)**: Django 5.0
- **実装**: Django 5.2.11
**対応方針**:
```
ドキュメントを 5.2 に更新
```
- **対応内容**: ドキュメントを Django 5.2 に更新
- **対応日**: 2026-02-17
---
### C-8: DEFAULT_PERMISSION_CLASSES
### ~~C-8: DEFAULT_PERMISSION_CLASSES~~ ✅ 対応済み
- **ドキュメント(統合指示書)**: `IsAuthenticated`(認証必須)
- **実装**: `AllowAny`(認証なしでアクセス可能
- **影響**: 現状では誰でもAPIにアクセスできる状態。開発中は便利だが本番では危険
**対応方針**:
```
IsAuthenticated に変更
後で変えると、漏れが怖いです
```
- **対応内容**: `AllowAny` `IsAuthenticated` に変更
- **対応日**: 2026-02-17D-4 と同時対応
- **確認**: Playwright E2E テストで未認証時 401 を検証済み
---
## D. 潜在的な不具合
### D-1: PDF生成時の variety/crop が null でクラッシュ
### ~~D-1: PDF生成時の variety/crop が null でクラッシュ~~ ✅ 修正済み
- **該当コード**: `backend/apps/reports/views.py` 20行目、24行目
- **問題**: `plan.crop.name` / `plan.variety.name` を直接参照。variety は nullable (blank=True, null=True)、crop も nullable
- **再現条件**: 品種を設定せずに作物だけ設定した圃場があるとPDF生成時にエラー
- **修正案**: `plan.variety.name if plan.variety else ''` のように null チェックを追加
**対応方針**:
```
修正する
```
- **修正内容**: `plan.crop.name if plan.crop else '未設定'` / `plan.variety.name if plan.variety else ''` の null チェック追加
- **修正日**: 2026-02-17
- **確認**: Playwright E2E テストで PDF 生成200 応答)を検証済み
---
### D-2: init_crops.py の不正データ
### ~~D-2: init_crops.py の不正データ~~ ✅ 修正済み
- **該当コード**: `backend/apps/plans/management/commands/init_crops.py` 12行目、26行目
- **問題**:
- `'ミヤギром'` — 日本語 + キリル文字(ロシア語の「ром」が混入)。正しくは「ミヤギシロメ」等?
- `'ゴールdent'` — 日本語 + 英語混在。正しくは「ゴールデント」等?
- **影響**: マスタデータの品種名が不正。品種選択UIで表示される
**対応方針**:
```
削除する — init_crops.py 自体を消す。作物・品種は管理画面やUIから登録する運用にする
```
- **修正内容**: `init_crops.py` 自体を削除
- **修正日**: 2026-02-17
---
### D-3: settings.py の二重定義
### ~~D-3: settings.py の二重定義~~ ✅ 修正済み
- **該当コード**: `backend/keinasystem/settings.py`
- 113行目: `LANGUAGE_CODE = 'en-us'`、115行目: `TIME_ZONE = 'UTC'`
- 152行目: `LANGUAGE_CODE = 'ja'`、154行目: `TIME_ZONE = 'Asia/Tokyo'`
- **問題**: 後の定義で上書きされるので動作に影響はないが、コードが紛らわしい
- **修正案**: 前の定義を削除し、後の定義のみ残す
**対応方針**:
```
`LANGUAGE_CODE = 'ja'`、154行目: `TIME_ZONE = 'Asia/Tokyo'`
```
- **修正内容**: 前の `LANGUAGE_CODE = 'en-us'` / `TIME_ZONE = 'UTC'` を削除。`LANGUAGE_CODE = 'ja'` / `TIME_ZONE = 'Asia/Tokyo'` のみ残す
- **修正日**: 2026-02-17
---
### D-4: AllowAny で全API公開
### ~~D-4: AllowAny で全API公開~~ ✅ 修正済み
- **該当コード**: `backend/keinasystem/settings.py` 137行目
- **問題**: DEFAULT_PERMISSION_CLASSES が AllowAny。認証トークンなしでもすべてのAPI圃場データ、作付け計画、インポート、PDF生成にアクセス可能
- **影響**: ローカル開発のみなら問題ないが、外部公開時にはデータ漏洩リスク
- **備考**: C-8 と同じ内容。セキュリティ面での対応
- **修正内容**: `DEFAULT_PERMISSION_CLASSES``IsAuthenticated` に変更
- **修正日**: 2026-02-17
- **確認**: Playwright E2E テストで検証済み
**対応方針**:
```
```
セキュリティ必須
---
## E. 追加で修正の要望
### E-1: PDF帳票フォーマットの再設計
### ~~E-1: PDF帳票フォーマットの再設計~~ ✅ 対応済み
**現状の問題:**
- タイトルに中国語「申请书」が混入
- セクション分け形式(表形式でない)
- `@page` 指定なしA4サイズ・余白未設定
- 面積が ha 表示
**対応日**: 2026-02-17
**対応方針:** 表形式1行1区画で、紙の書式に合わせる
**対応内容:**
- E-1a: 水稲共済細目書 PDF — A4 縦、表形式1行1区画@page 設定、ページ番号、日本語タイトルに修正
- E-1b: 中山間交付金 PDF — A4 横、表形式1行1区画@page 設定、ページ番号、日本語タイトルに修正
- E-1c: OfficialChusankanField モデル拡張 — 6→17 フィールドに拡張マイグレーション0006
- 中山間インポート修正 — ODS 17 列すべて読み込み対応
- 共済インポートバグ修正 — 面積カラム名スペース不一致 + アール→m2 変換(×100)
- reports/views.py — ロジック全面書き直しフラットテーブル、null 安全、prefetch_related
- シリアライザ — OfficialChusankanFieldSerializer に 11 フィールド追加
**確認**: Playwright E2E テストPDF 200 応答、中山間 17 フィールド返却、共済面積 > 0で検証済み
---
#### E-1a: 水稲共済細目書 PDF
## 対応状況サマリー
**フォーマット:** A4縦、表形式、31行
| # | 列名 | データ元 | 備考 |
|---|------|---------|------|
| 1 | 漢字地名 | OfficialKyosaiField.kanji_name | 例: 四万十町 笹ヶ谷 374-1 |
| 2 | 耕地-分筆 | k_num + "-" + s_num | 例: 2-1 |
| 3 | 本地面積 (m2) | OfficialKyosaiField.area | 内部 m2 で保存 |
| 4 | 作付品目 | Plan.crop.name | システムの作付け計画から |
| 5 | 品種 | Plan.variety.name | 〃 |
| 6 | 圃場名称 | Field.name | 吉田農地台帳の名称。複数圃場の場合はカンマ区切り |
**補足:**
- 1つの共済区画に複数の実圃場が紐づく場合 → 作物・品種・圃場名をカンマ区切りで列挙
- 作付け未設定の場合 → 「未設定」と表示
- ヘッダー: 「水稲共済細目書YYYY年度
- ページ番号あり
---
#### E-1b: 中山間交付金 PDF
**フォーマット:** A4横列が多いため、表形式、71行
| # | 列名 | データ元 | 備考 |
|---|------|---------|------|
| 1 | 所在地 | 大字+字+地番+枝番 連結 | 例: 口神ノ川 壱町切 1694 |
| 2 | 植栽面積 | OfficialChusankanField.planting_area | ODS「植栽面積」列 |
| 3 | 作付け品目(元) | OfficialChusankanField.original_crop | ODS「作付け品目」列役場記入 |
| 4 | 協定管理者 | OfficialChusankanField.manager | ODS「協定管理者」列 |
| 5 | 所有者 | OfficialChusankanField.owner | ODS「所有者」列 |
| 6 | 作物 | Plan.crop.name | システムの作付け計画から |
| 7 | 品種 | Plan.variety.name | 〃 |
| 8 | 圃場名称 | Field.name | 吉田農地台帳の名称 |
**補足:**
- 1つの中山間区画に複数の実圃場が紐づく場合 → 作物・品種・圃場名をカンマ区切り
- ヘッダー: 「中山間地域等直接支払交付金YYYY年度
- ページ番号あり
---
#### E-1c: OfficialChusankanField モデル拡張
現在のモデルに存在しない列を追加するODSの17列全部を保存:
| 追加フィールド | ODS列名 | 型 |
|--------------|---------|---|
| chusankan_flag | 中山間 | CharField (〇など) |
| branch_num | 枝番 | CharField (-, 1, イ, ロ等) |
| land_type | 地目 | CharField (田, 畑等) |
| planting_area | 植栽面積 | IntegerField (m2) |
| original_crop | 作付け品目 | CharField (役場記入) |
| manager | 協定管理者 | CharField |
| owner | 所有者 | CharField (nullable) |
| slope | 傾斜度 | CharField (1/20等) |
| base_amount | 基本金額 | IntegerField |
| steep_slope_addition | 超急傾斜加算額 | DecimalField |
| smart_agri_addition | スマート農業加算額 | DecimalField |
※ 既存フィールド: c_id, oaza, aza, chiban, area(農地面積), payment_amount(交付金額)
---
## 対応の進め方
上記すべての項目に対応方針を記入後、以下の順序で作業を進めることを推奨します:
1. **不具合修正** (D-1, D-2, D-3) — すぐに直せるもの
2. **セキュリティ** (C-8 / D-4) — 運用方針の確認
3. **データの食い違い修正** (C-1〜C-7) — ドキュメントか実装の修正
4. **未実装機能の追加** (A-1〜A-8) — 優先度を決めて順次対応
5. **ドキュメントへの追記** (B-1〜B-5) — 実装済み機能の記録
| カテゴリ | 項目 | 状態 |
|---------|------|------|
| A-1 | ダッシュボード画面 | 🔜 未着手 |
| A-2 | チェックボックス一括操作 | 🔜 未着手 |
| A-3 | 前年度コピーボタン | 🔜 未着手 |
| A-4 | 品種インライン追加・削除 | 🔜 未着手 |
| A-5 | PDFプレビュー | 🔜 未着手 |
| A-6 | エクスポート機能 | 🔜 未着手 |
| A-7 | 検索・フィルタ | 🔜 未着手 |
| A-8 | 圃場詳細 共済/中山間表示 | ✅ 完了 |
| B-1〜B-5 | ドキュメント追記 | ✅ 完了 |
| C-1〜C-8 | ドキュメント/実装の食い違い修正 | ✅ 全件完了 |
| D-1〜D-4 | 不具合修正 | ✅ 全件完了 |
| E-1 | PDF帳票再設計 | ✅ 完了 |