仕様書を更新しました。変更先は ナビゲーション再編仕様書.md です。

今回入れた主な追記はこの3点です。

1-4 に Issue #13 との役割分担を追加
10-2 に NavGroup / NavItem の階層構造と match の位置づけを追加
10-3 に URL とナビゲーションの分離原則、Route Groups の扱い方を追加
これで、仕様書だけ読んでも実装方針が分かり、なぜそうしているかは Issue #13 にたどれる構成になりました。必要なら次に、10-2 のサンプル navGroups を今の分類に合わせてもっと具体化します。
This commit is contained in:
akira
2026-04-07 11:01:44 +09:00
parent 8de27de335
commit 0cd90e61db

View File

@@ -41,6 +41,12 @@
- お気に入り機能、ピン留め機能
- ナビゲーションと連動したダッシュボード内容の刷新
### 1-4. 関連 Issue との役割分担
- Issue `#13 メニューがごちゃごちゃしてきたので、整理する` は、背景、論点、判断理由を残す親議論として扱う
- 本仕様書は、その議論を踏まえた実装向けの決定事項をまとめる文書として扱う
- 後から判断理由を確認したい場合は Issue `#13` を参照する
---
## 2. 基本方針
@@ -52,8 +58,8 @@
1. ホーム
2. 計画
3. 実績
4. 資材・帳票
5. その他
4. マスター
5. 帳票・連携
右端には従来どおりユーザー操作を置く。
@@ -90,23 +96,26 @@
- 畔塗記録
- 作業記録
#### 資材・帳票
#### マスター
- 圃場管理
- 作物
- 品種
- 資材マスタ
- 肥料マスタ
#### 帳票・連携
- 在庫管理
- 帳票出力
- データ取込
#### その他
- 気象
- メール
- 設定
### 3-2. メールの扱い
メール関連はトップ階層に個別表示しない。
`その他 > メール` の中にまとめる。
`帳票・連携 > メール` の中にまとめる。
内訳:
@@ -115,8 +124,8 @@
### 3-3. 設定の扱い
現状はパスワード変更のみだが、将来の設定追加を見越して `その他 > 設定` という置き方を前提にする
ただし初期実装では右上アイコンからのパスワード変更導線維持してよい
現状はパスワード変更のみのため、独立カテゴリにはしない
初期実装では右上アイコンからのパスワード変更導線維持し、設定系機能が増えた場合に別途 `設定` グループ化を検討する
---
@@ -134,14 +143,18 @@
| 実績 | 散布実績 | `/fertilizer/spreading` |
| 実績 | 畔塗記録 | `/levee-work` |
| 実績 | 作業記録 | `/workrecords` |
| 資材・帳票 | 圃場管理 | `/fields` |
| 資材・帳票 | 在庫管理 | `/materials` |
| 資材・帳票 | 帳票出力 | `/reports` |
| 資材・帳票 | データ取込 | `/import` |
| その他 | 気象 | `/weather` |
| その他 > メール | メール履歴 | `/mail/history` |
| その他 > メール | メールルール | `/mail/rules` |
| その他 > 設定 | パスワード変更 | `/settings/password` |
| マスター | 圃場管理 | `/fields` |
| マスター | 作物 | `未実装: allocation 内管理を独立予定` |
| マスター | 品種 | `未実装: allocation 内管理を独立予定` |
| マスター | 資材マスタ | `/materials/masters` |
| マスター | 肥料マスタ | `/fertilizer/masters` |
| 帳票・連携 | 在庫管理 | `/materials` |
| 帳票・連携 | 帳票出力 | `/reports` |
| 帳票・連携 | データ取込 | `/import` |
| 帳票・連携 | 気象 | `/weather` |
| 帳票・連携 > メール | メール履歴 | `/mail/history` |
| 帳票・連携 > メール | メールルール | `/mail/rules` |
| 右上ユーザー操作 | パスワード変更 | `/settings/password` |
### 4-2. アクティブ表示ルール
@@ -149,16 +162,19 @@
- ドロップダウン内の該当項目も個別にアクティブ表示する
- パス接頭辞だけで判定するとカテゴリが衝突する画面があるため、より具体的なパスを優先して判定する
- 特に `施肥計画``散布実績` はともに `/fertilizer` 配下を使うため、`/fertilizer/spreading` を先に判定し、`計画` 側から明示的に除外する
- 同様に `在庫管理``資材マスタ` はともに `/materials` 配下を使うため、`/materials/masters` を先に判定し、`帳票・連携` 側の `在庫管理` から明示的に除外する
- 例:
- `/fertilizer``計画` をアクティブ
- `/fertilizer/new``計画` をアクティブ
- `/fertilizer/[id]` および `/fertilizer/[id]/edit``計画` をアクティブ
- `/fertilizer/spreading``実績` をアクティブ
- `/fertilizer/spreading?...``実績` をアクティブ
- `/materials``帳票・連携` をアクティブ
- `/materials/masters``マスター` をアクティブ
- 例:
- `/fields/123` の場合は `資材・帳票` がアクティブ
- `/fields/123` の場合は `マスター` がアクティブ
- `/fertilizer/10/edit` の場合は `計画` がアクティブ
- `/mail/history` の場合は `その他``メール履歴` がアクティブ
- `/mail/history` の場合は `帳票・連携``メール履歴` がアクティブ
---
@@ -175,7 +191,7 @@ PC ではヘッダーを 3 ブロック構成とする。
### 5-2. トップメニューの見せ方
- `ホーム` は単独リンク
- `計画` `実績` `資材・帳票` `その他` はドロップダウン付きメニュー
- `計画` `実績` `マスター` `帳票・連携` はドロップダウン付きメニュー
- ラベルの横に開閉アイコンを表示する
- 開いたメニューは白背景のパネルとして表示する
@@ -204,29 +220,34 @@ PC ではヘッダーを 3 ブロック構成とする。
2. 畔塗記録
3. 作業記録
#### 資材・帳票
#### マスター
1. 圃場管理
2. 在庫管理
3. 帳票出力
4. データ取込
2. 作物
3. 品種
4. 資材マスタ
5. 肥料マスタ
#### その他
#### 帳票・連携
1. 気象
2. メール
3. 設定
1. 在庫管理
2. 帳票出力
3. データ取込
4. 気象
5. メール
`メール``設定` は 2 段構造にする方法と、直接展開せず一覧モーダル風に見せる方法があるが、初期実装ではシンプルさを優先し、`その他` ドロップダウン内に個別リンクを直接置く。
`メール` は 2 段構造にする方法と、直接展開せず一覧モーダル風に見せる方法があるが、初期実装ではシンプルさを優先し、`帳票・連携` ドロップダウン内に個別リンクを直接置く。
初期実装の並び:
1. 気象
2. メール履歴
3. メールルール
4. パスワード変更
1. 在庫管理
2. 帳票出力
3. データ取込
4. 気象
5. メール履歴
6. メールルール
なお情報設計上の名称としては `メール` `設定` を維持し、将来的に機能が増えた時点で再度サブグループ化する。
なお情報設計上の名称としては `メール` を維持し、将来的に機能が増えた時点で再度サブグループ化する。
---
@@ -248,13 +269,14 @@ PC と同じカテゴリ構成を維持し、見た目だけ縦並びにする
1. ホーム
2. 計画
3. 実績
4. 資材・帳票
5. その他
4. マスター
5. 帳票・連携
6. パスワード変更
7. ログアウト
### 6-4. 開閉ルール
- `ホーム` は単独リンクとし、タップ時はそのまま `/dashboard` へ遷移する
- カテゴリ見出しタップで開閉
- 現在表示中の画面が属するカテゴリは初期状態で展開してよい
- 項目タップ後はメニューを閉じて画面遷移する
@@ -273,13 +295,13 @@ PC と同じカテゴリ構成を維持し、見た目だけ縦並びにする
- `ホーム` は利用者に最も分かりやすいため維持
- `計画` は作付け、施肥、田植え、運搬を含む包括名として使用
- `実績` は記録系業務のまとめ先とする
- `資材・帳票` はやや広いが、現状機能数とのバランスを優先
- `その他` は補助機能置き場として扱う
- `マスター` は日々の業務を支える基礎データ管理の置き場とする
- `帳票・連携` は出力、取込、通知、補助参照のまとめ先とする
将来 `その他` に機能が増えすぎた場合は、次の再編を検討する。
将来 `帳票・連携` に機能が増えすぎた場合は、次の再編を検討する。
- `帳票`
- `連携`
- `設定`
- `通知`
---
@@ -293,8 +315,8 @@ PC と同じカテゴリ構成を維持し、見た目だけ縦並びにする
- ホーム: 家またはダッシュボード系
- 計画: 作物または計画系
- 実績: チェック、記録系
- 資材・帳票: 箱またはファイル
- その他: 省略記号または設定
- マスター: 設定、リスト、データベース
- 帳票・連携: ファイル、送受信、クラウド
ただし、文字認識を優先し、アイコンは補助扱いとする。
@@ -337,10 +359,32 @@ PC と同じカテゴリ構成を維持し、見た目だけ縦並びにする
### 10-2. メニュー定義データ化
個別ボタンの直書きはやめ、カテゴリ配列で管理する。
メニュー定義はフラットな `group` 管理ではなく、階層構造で持つ。
方針:
- グループ構成そのものが定義から読み取れることを優先する
- 通常ケースは `href` ベースで扱う
- `href` ベースで判定しきれない例外ケースだけ `match` を持つ
- `match` は全件定義用ではなく、衝突回避用の最小限の逃げ道として使う
想定イメージ:
```ts
type NavItem = {
label: string;
href: string;
match?: (pathname: string) => boolean;
};
type NavGroup = {
key: string;
label: string;
type: 'link' | 'group';
href?: string;
items?: NavItem[];
};
const navGroups = [
{
key: 'home',
@@ -366,7 +410,26 @@ const navGroups = [
アクティブ判定は、現在の `pathname` と各項目の対応パターンで管理する。
:
基本原則:
- URL はリソース・機能識別子として安定性を優先し、メニュー階層とは分離して扱う
- メニュー再編のたびに URL を変更しない
- アクティブ判定はナビ定義側のルールで吸収する
- ただし、全件をルーターのように再定義するのではなく、通常ケースは `href` ベース、衝突ケースだけ `match` を使う
補足:
- Next.js App Router の Route Groups は、URL を変えずにコード構造を整理する手段としては有効
- ただし Route Groups はナビ判定そのものの代替ではなく、実装整理の補助手段として扱う
パス接頭辞衝突が起きる組み合わせは、具体パス優先で次のように扱う。
| 優先判定するパス | 所属カテゴリ | 除外される側 |
|---|---|---|
| `/fertilizer/spreading` | 実績 | 計画 > 施肥計画 |
| `/materials/masters` | マスター | 帳票・連携 > 在庫管理 |
通常判定の例:
- `/fertilizer`
- `/fertilizer/new`
@@ -374,6 +437,13 @@ const navGroups = [
はすべて `施肥計画` 所属として扱う。
- `/materials`
- `/materials?tab=...`
`在庫管理` 所属として扱う。
実装上は、上記の衝突ケースのみ `NavItem.match` を使う想定とする。
---
## 11. 段階導入案
@@ -381,12 +451,15 @@ const navGroups = [
### Phase 1
- PC ナビを 5 分類へ再編
- `その他` は単純なリンク群として実装
- `作物` `品種` はマスター体系に含めるが、Phase 1 ではメニューに表示しない
- Phase 1 の `マスター` 配下に表示するのは `圃場管理` `資材マスタ` `肥料マスタ` のみとする
- `作物` `品種` は未実装項目として仕様上は位置づけ、独立画面が用意できる Phase 2 でメニュー表示を開始する
- モバイルも同じ情報設計へ変更
### Phase 2
- `その他` 内を `メール` `設定` にサブグループ化
- `作物管理` `品種管理` を独立画面として追加
- `帳票・連携` 内の `メール` をサブグループ化
- よく使う画面の履歴や最近使った機能を補助表示
### Phase 3
@@ -409,26 +482,27 @@ const navGroups = [
## 13. 想定される懸念と対応
### 13-1. 「資材・帳票」が少し広すぎる
### 13-1. 「マスター」に含める範囲
現時点では機能数のバランスを優先し、この分類を採用する。
今後、帳票やマスタ管理が増えた場合は `資材``帳票・管理` に再分割する。
現時点では`圃場管理` `作物` `品種` `資材マスタ` `肥料マスタ``マスター` として集約する。
日々の入力対象ではなく、業務の前提データを整える画面群としてまとめるのが自然である。
補足:
- `圃場管理`本来、圃場マスタとして独立性の高い機能であり、`資材` と完全に同質ではな
- ただし現時点では、単独トップにするほどの件数ではなく、`資材・帳票` にまとめるのが最も全体バランスが良い
- 将来、圃場関連の設定や地図系機能が増えた場合は、`圃場・マスタ` のような独立カテゴリ化を再検討す
- `圃場管理` は圃場マスタとして独立性が高
- `作物``品種` も本来マスター管理であり、現状は allocation 画面内で扱っているだけで、メニュー上は独立させる前提で考える
- `資材マスタ``肥料マスタ` はすでに独立ページがあり、`マスタ` 配下に置くのが自然であ
- 将来、地図、圃場グループ、所有者管理などが増えた場合は、`圃場マスタ` の再独立も検討する
### 13-2. 「その他」が曖昧
### 13-2. 「帳票・連携」が少し広い
現時点では補助機能数が少ないため許容する。
メール、設定、外部連携系が増えた段階で再分割を検討する。
現時点では `在庫管理` `帳票出力` `データ取込` `気象` `メール` をまとめる。
完全に同じ性質ではないが、いずれも補助業務、参照、連携、出力に近い機能であり、トップ階層を増やしすぎないために同居させる。
### 13-3. 「データ取込」は日常操作ではない
`データ取込` は日常的に何度も使う画面ではなく、年度切替時や初期設定時に使う補助導線である。
そのためトップレベル常設には置かず、`資材・帳票` 配下に置く判断は妥当とする。
そのためトップレベル常設には置かず、`帳票・連携` 配下に置く判断は妥当とする。
ただし今後、取込対象や運用頻度が増えた場合は、`設定` または `運用` 系カテゴリへの移設も検討対象とする。
@@ -445,6 +519,6 @@ const navGroups = [
## 14. 結論
現行の 1 画面 1 ボタン方式は、今後の機能追加に対して拡張性が低い。
そのため、トップナビは `ホーム / 計画 / 実績 / 資材・帳票 / その他` の 5 分類へ再編し、個別画面はドロップダウン配下に置く。
そのため、トップナビは `ホーム / 計画 / 実績 / マスター / 帳票・連携` の 5 分類へ再編し、個別画面はドロップダウン配下に置く。
この構成により、利用者は「画面名」ではなく「やりたい業務」から機能を探せるようになり、将来の機能追加にも耐えやすくなる。