Files
keinasystem/document/06_ドキュメントvs実装_差異レポート.md
Akira 50e23872f3 ドキュメント更新(6ファイル)
03_データ仕様書.md — 全面書き直し(M:N関係、中山間17列モデル、面積単位、PDF出力仕様)
04_画面設計書.md — 全面書き直し(Navbar追加、圃場管理/新規作成画面追加、インライン編集方式、PDF帳票フォーマット仕様 E-1)
01_プロダクトビジョン.md — CSV→PDF、M:1→M:N
05_実装優先順位.md — CSV→PDF、Django 5.0→5.2、モーダル→インライン、init_crops削除
00_Gemini向け統合指示書.md — CSV→PDF、Django 5.2、M:N関係、中山間17列モデル、init_crops削除、IsAuthenticated
CLAUDE.md — 既知の課題一覧、次タスク優先順追加、中山間モデル拡張、差異レポートリンク
コード修正(4件)
D-1: reports/views.py — plan.crop / plan.variety の null チェック追加
D-2: init_crops.py を削除
D-3: settings.py — LANGUAGE_CODE/TIME_ZONE の二重定義を解消
D-4: settings.py — AllowAny → IsAuthenticated に変更
次のタスクは CLAUDE.md の優先順リストに従うと A-8(圃場詳細に共済/中山間情報表示)です。続けますか?
2026-02-17 10:56:09 +09:00

444 lines
16 KiB
Markdown
Raw Blame History

This file contains ambiguous Unicode characters
This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.
# ドキュメント vs 実装 差異レポート
> **作成日**: 2026-02-16
> **目的**: ドキュメントと実装の差異を洗い出し、対応方針を決定する
>
> 各項目の「対応方針」欄に指示を記入してください。
> 記入例: 「実装する」「ドキュメント削除」「Phase 2に延期」「現状維持」など
---
## A. ドキュメントに書かれているが実装されていないもの
### A-1: ダッシュボード画面
- **ドキュメント**: 画面設計書 画面2 - 概要サマリー(全圃場数/作付け済み/未割当)、クイックアクセスボタン、最近の変更履歴
- **実装**: `/` はトークンの有無で `/allocation``/login` にリダイレクトするだけ
- **影響**: なくても作付け計画画面から全機能にアクセス可能。Navbarで各画面に遷移できる
**対応方針**:
```
将来、機能追加する時には、ここにボタンが増えていく形式になっていくはずなので必要です
```
---
### A-2: チェックボックスによる一括操作
- **ドキュメント**: 画面設計書 画面3 - 各行にチェックボックス、複数選択→一括割当
- **実装**: チェックボックスなし、一括操作UI なし
- **補足**: Backend には `POST /api/plans/bulk_update/` APIが既に存在する
**対応方針**:
```
利便性向上の為必要です。
```
---
### A-3: 前年度コピー機能(フロントエンド)
- **ドキュメント**: ユーザーストーリー P1-5、画面設計書 画面3 - [前年度をコピー]ボタン
- **実装**: Backend API (`POST /api/plans/copy_from_previous_year/`) は存在するが、Frontend にボタンがない
- **影響**: 毎年手動で39筆を設定する必要がある
**対応方針**:
```
必要な項目です。
```
---
### A-4: 品種のインライン追加
- **ドキュメント**: 画面設計書 画面4 - [+ 新しい品種を追加]ボタン、その場で入力して即座にマスタ登録
- **実装**: 既存品種からの選択のみ。新品種の追加はDjango管理画面からのみ可能
- **影響**: 運用中に新品種が出てきた場合、管理画面を開く必要がある
**対応方針**:
```
追加出来る事は必要です。削除も出来ないと間違って追加した時に不便です
```
---
### A-5: PDFプレビュー機能
- **ドキュメント**: 画面設計書 画面6 - [プレビュー]ボタンで新タブにPDF表示
- **実装**: ダウンロードボタンのみ(プレビューなし)
- **影響**: ダウンロード前に内容確認ができない
**対応方針**:
```
プレビューしてから保存、もしくは、印刷出来るようにしたいです。
```
---
### A-6: エクスポート機能CSV/ZIP
- **ドキュメント**: 画面設計書 画面7 - 全圃場データCSV、作付け計画CSV、全データZIPバックアップ
- **実装**: 未実装
- **影響**: バックアップ手段がないDBダンプのみ
**対応方針**:
```
必要です。近い将来サーバーに移行するので、その時に、このローカル環境で設定したデータを移動できるようにしたいです。
```
---
### A-7: 作付け計画画面の検索・フィルタ
- **ドキュメント**: 画面設計書 画面3 - 圃場名・住所で部分一致検索、作物で絞り込み、未割当のみトグル
- **実装**: 並び替え(カスタム順/グループ順/作付け順)のみ。テキスト検索なし
- **影響**: 39筆なので目視でも探せるが、検索があると便利
**対応方針**:
```
優先度は低いですが必要です。
```
---
### A-8: 圃場詳細画面の共済/中山間情報表示
- **ドキュメント**: 画面設計書 画面5 - 共済情報(耕地番号/分筆、中山間情報IDを表示
- **実装**: 基本情報(名称、住所、面積、所有者、グループ)の編集のみ
- **影響**: 圃場と申請区画の対応がUI上で確認できない
**対応方針**:
```
これ絶対に必要!
```
---
## B. 実装されているがドキュメントに記載がないもの
### B-1: グループ機能
- **実装**: `group_name`(エリア分け)、`display_order`(表示順)フィールド。圃場一覧・作付け計画で並び替え可能
- **ドキュメント**: CLAUDE.md にのみ記載。データ仕様書・画面設計書には未記載
- **経緯**: マイグレーション0004で後から追加された機能
**対応方針**:
```
ドキュメントに追記する / 現状維持
```
---
### B-2: 圃場管理画面(/fields
- **実装**: 圃場一覧(テーブル形式)、グループ編集、表示順変更(上下ボタン)、削除機能
- **ドキュメント**: 画面設計書に独立した画面としての記載なし画面5は「圃場詳細」のみ
**対応方針**:
```
ドキュメントに追記する / 現状維持
```
---
### B-3: 圃場新規作成画面(/fields/new
- **実装**: 手動で圃場を1件ずつ作成可能
- **ドキュメント**: インポートODS/Excelのみ想定。手動作成の記載なし
**対応方針**:
```
ドキュメントに追記する / 現状維持
```
---
### B-4: インライン編集方式(作付け計画)
- **実装**: テーブル内で直接作物・品種・備考を編集(即時保存)
- **ドキュメント**: 画面設計書 画面4 ではモーダルウィンドウでの編集を想定
**対応方針**:
```
実装に合わせてドキュメント更新 / モーダルに変更
```
---
### B-5: Navbarナビゲーションバー
- **実装**: 左サイドに常時表示のナビ(作付け計画、圃場管理、帳票出力、データ取込、ログアウト)
- **ドキュメント**: 画面設計書ではヘッダー内にハンバーガーメニュー(スマホ)を想定
**対応方針**:
```
ドキュメントに追記する / 現状維持
```
---
## C. ドキュメントと実装で食い違っているもの
### C-1: Field と共済/中山間の関係M:1 vs M:N
- **ドキュメント(データ仕様書)**: M:1ForeignKey- 「複数の実圃場が1つの共済区画に対応」
- **実装**: M:NManyToManyField- 1つの実圃場が複数の申請区画に紐づくケースにも対応
- **CLAUDE.md**: M:N に更新済み
- **影響**: データ仕様書のER図、紐付けロジックのコード例が古い
**対応方針**:
```
データ仕様書を M:N に更新
```
---
### 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) ペアで一意が正しいです
```
---
### C-3: 中山間マスタのフィールド型
- **ドキュメント**: `c_id` = IntegerField, `chiban` = IntegerField
- **実装**: `c_id` = CharField, `chiban` = CharField
- **影響**: 数値でないデータが入る可能性(実運用で問題ないか要確認)
**対応方針**:
```
数値でないデータが入る可能性あります。イとかロとかがあります
```
---
### C-4: 面積フィールドの単位
- **ドキュメント**: 共済マスタ `area` = m2 (FloatField)、中山間マスタ `area` = m2 (IntegerField)
- **実装**: 両方とも `area` = DecimalField(ha表記)
- **影響**: PDF出力時の面積表示が m2 ではなく ha になっている可能性
**対応方針**:
```
面積の内部表現がm2に統一。表示上は反=10aに統一してください
```
---
### C-5: 作物マスタの初期データ
- **ドキュメント**: 米、トウモロコシ、エンドウ、野菜、その他
- **実装init_crops.py**: 水稲、大豆、小麦、そば、とうきび
- **品種も全く異なる**:
- ドキュメント: にこまる、たちはるか、たちはるか(特栽)、久留米豊、完全休耕 等
- 実装: コシヒカリ、ひとめぼれ、あきたこまち、つや姫、タマホマレ 等
- **影響**: ドキュメントはユーザー固有のデータだが、init_crops.py は汎用的なサンプルになっている
**対応方針**:
```
初期データはいらないです消して入れなおさなきゃいけない事になっている
どうしても必要なら、今登録されているデータに準拠してください
```
---
### C-6: 申請書の出力形式CSV vs PDF
- **ドキュメント(複数箇所)**:
- 01_プロダクトビジョン.md: 「申請書水稲共済・中山間のCSV出力」
- 05_実装優先順位.md: 「水稲共済細目書のCSV出力」「中山間交付金のCSV出力」
- 02_ユーザーストーリー.md: 「PDFでダウンロード」
- 04_画面設計書.md: 「PDFダウンロード」
- **実装**: PDF出力WeasyPrint
- **影響**: ドキュメント内で CSV と PDF が混在している
**対応方針**:
```
全ドキュメントをPDFに統一
```
---
### C-7: Django バージョン
- **ドキュメント(統合指示書)**: Django 5.0
- **実装**: Django 5.2.11
**対応方針**:
```
ドキュメントを 5.2 に更新
```
---
### C-8: DEFAULT_PERMISSION_CLASSES
- **ドキュメント(統合指示書)**: `IsAuthenticated`(認証必須)
- **実装**: `AllowAny`(認証なしでアクセス可能)
- **影響**: 現状では誰でもAPIにアクセスできる状態。開発中は便利だが本番では危険
**対応方針**:
```
IsAuthenticated に変更
後で変えると、漏れが怖いです
```
---
## D. 潜在的な不具合
### 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 チェックを追加
**対応方針**:
```
修正する
```
---
### D-2: init_crops.py の不正データ
- **該当コード**: `backend/apps/plans/management/commands/init_crops.py` 12行目、26行目
- **問題**:
- `'ミヤギром'` — 日本語 + キリル文字(ロシア語の「ром」が混入)。正しくは「ミヤギシロメ」等?
- `'ゴールdent'` — 日本語 + 英語混在。正しくは「ゴールデント」等?
- **影響**: マスタデータの品種名が不正。品種選択UIで表示される
**対応方針**:
```
削除する — init_crops.py 自体を消す。作物・品種は管理画面やUIから登録する運用にする
```
---
### 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'`
```
---
### D-4: AllowAny で全API公開
- **該当コード**: `backend/keinasystem/settings.py` 137行目
- **問題**: DEFAULT_PERMISSION_CLASSES が AllowAny。認証トークンなしでもすべてのAPI圃場データ、作付け計画、インポート、PDF生成にアクセス可能
- **影響**: ローカル開発のみなら問題ないが、外部公開時にはデータ漏洩リスク
- **備考**: C-8 と同じ内容。セキュリティ面での対応
**対応方針**:
```
```
セキュリティ必須
---
## E. 追加で修正の要望
### E-1: PDF帳票フォーマットの再設計
**現状の問題:**
- タイトルに中国語「申请书」が混入
- セクション分け形式(表形式でない)
- `@page` 指定なしA4サイズ・余白未設定
- 面積が ha 表示
**対応方針:** 表形式1行1区画で、紙の書式に合わせる
---
#### 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) — 実装済み機能の記録