メニューの整理案

This commit is contained in:
akira
2026-04-07 10:01:02 +09:00
parent 4516a74772
commit 71b8258281

View File

@@ -0,0 +1,428 @@
# ナビゲーション再編仕様書
> 作成日: 2026-04-07
> 対象: `frontend/src/components/Navbar.tsx`
> 方針: 第一候補「上段5分類 + ドロップダウン」
---
## 0. 背景
現状のグローバルナビゲーションは、機能追加のたびに横並びのボタンを増やしており、以下の問題が出ている。
- 上位階層の導線が多すぎて、目的の画面を探しにくい
- 「計画」「実績」「設定」「補助機能」が同じ粒度で並んでいる
- メール関連のように、単独トップに置くほどではない機能が場所を取りやすい
- 今後も機能追加が続くと、横幅不足と認知負荷の両方が悪化する
このため、トップナビは「日常的に使う業務カテゴリ」だけを見せ、個別画面はドロップダウン配下へ整理する。
---
## 1. 目的
### 1-1. 目指す状態
- 1階層目では「何をしたいか」で探せる
- 似た役割の画面を同じカテゴリに集約する
- 画面数が増えても、トップレベルの見た目を増やしすぎない
- PC とスマホで同じ情報設計を維持する
### 1-2. 今回の対象
- 共通ヘッダー内のグローバルナビゲーション再編
- メニュー分類、ラベル、並び順、開閉仕様の定義
- 各画面がどのカテゴリに属するかの明確化
### 1-3. 今回やらないこと
- 各業務画面そのものの UI 改修
- 権限別メニュー出し分け
- お気に入り機能、ピン留め機能
- ナビゲーションと連動したダッシュボード内容の刷新
---
## 2. 基本方針
### 2-1. トップレベル構成
トップナビでは以下の 5 項目のみを常時表示する。
1. ホーム
2. 計画
3. 実績
4. 資材・帳票
5. その他
右端には従来どおりユーザー操作を置く。
- パスワード変更
- ログアウト
### 2-2. 設計ルール
- 毎日使う業務カテゴリだけをトップに置く
- 個別機能名ではなく、業務単位で束ねる
- 設定、履歴、通知、補助系は単独トップにしない
- 同じ業務の前後工程は可能な限り同じカテゴリに寄せる
---
## 3. 情報設計
### 3-1. カテゴリ構成
#### ホーム
- ダッシュボード
#### 計画
- 作付け計画
- 施肥計画
- 田植え計画
- 運搬計画
#### 実績
- 散布実績
- 畔塗記録
- 作業記録
#### 資材・帳票
- 圃場管理
- 在庫管理
- 帳票出力
- データ取込
#### その他
- 気象
- メール
- 設定
### 3-2. メールの扱い
メール関連はトップ階層に個別表示しない。
`その他 > メール` の中にまとめる。
内訳:
- メール履歴
- メールルール
### 3-3. 設定の扱い
現状はパスワード変更のみだが、将来の設定追加を見越して `その他 > 設定` という置き方を前提にする。
ただし初期実装では、右上アイコンからのパスワード変更導線は維持してよい。
---
## 4. 画面とメニューの対応
### 4-1. 現在の主要画面の所属
| カテゴリ | ラベル | パス |
|---|---|---|
| ホーム | ダッシュボード | `/dashboard` |
| 計画 | 作付け計画 | `/allocation` |
| 計画 | 施肥計画 | `/fertilizer` |
| 計画 | 田植え計画 | `/rice-transplant` |
| 計画 | 運搬計画 | `/distribution` |
| 実績 | 散布実績 | `/fertilizer/spreading` |
| 実績 | 畔塗記録 | `/levee-work` |
| 実績 | 作業記録 | `/workrecords` |
| 資材・帳票 | 圃場管理 | `/fields` |
| 資材・帳票 | 在庫管理 | `/materials` |
| 資材・帳票 | 帳票出力 | `/reports` |
| 資材・帳票 | データ取込 | `/import` |
| その他 | 気象 | `/weather` |
| その他 > メール | メール履歴 | `/mail/history` |
| その他 > メール | メールルール | `/mail/rules` |
| その他 > 設定 | パスワード変更 | `/settings/password` |
### 4-2. アクティブ表示ルール
- その画面自身、またはその配下詳細画面にいる場合、所属カテゴリをアクティブにする
- ドロップダウン内の該当項目も個別にアクティブ表示する
- 例:
- `/fields/123` の場合は `資材・帳票` がアクティブ
- `/fertilizer/10/edit` の場合は `計画` がアクティブ
- `/mail/history` の場合は `その他``メール履歴` がアクティブ
---
## 5. PC 表示仕様
### 5-1. レイアウト
PC ではヘッダーを 3 ブロック構成とする。
1. 左: ブランド名 `KeinaSystem`
2. 中央: トップメニュー 5 項目
3. 右: パスワード変更、ログアウト
### 5-2. トップメニューの見せ方
- `ホーム` は単独リンク
- `計画` `実績` `資材・帳票` `その他` はドロップダウン付きメニュー
- ラベルの横に開閉アイコンを表示する
- 開いたメニューは白背景のパネルとして表示する
### 5-3. 開閉ルール
- クリックで開閉
- 開いている他メニューがある場合は、それを閉じてから新しいメニューを開く
- メニュー外クリックで閉じる
- `Esc` キーで閉じる
- 項目クリック後は遷移して閉じる
### 5-4. ドロップダウンの表示内容
各項目は以下の順で並べる。
#### 計画
1. 作付け計画
2. 施肥計画
3. 田植え計画
4. 運搬計画
#### 実績
1. 散布実績
2. 畔塗記録
3. 作業記録
#### 資材・帳票
1. 圃場管理
2. 在庫管理
3. 帳票出力
4. データ取込
#### その他
1. 気象
2. メール
3. 設定
`メール``設定` は 2 段構造にする方法と、直接展開せず一覧モーダル風に見せる方法があるが、初期実装ではシンプルさを優先し、`その他` ドロップダウン内に個別リンクを直接置く。
初期実装の並び:
1. 気象
2. メール履歴
3. メールルール
4. パスワード変更
なお情報設計上の名称としては `メール` `設定` を維持し、将来的に機能が増えた時点で再度サブグループ化する。
---
## 6. スマホ表示仕様
### 6-1. 基本方針
スマホではハンバーガーメニューを採用する。
PC と同じカテゴリ構成を維持し、見た目だけ縦並びにする。
### 6-2. 表示ルール
- 初期状態ではロゴ、メニューボタン、ログアウト系導線のみ表示
- メニューボタン押下で全画面または右スライドのメニューを開く
- カテゴリはアコーディオン形式で開閉する
### 6-3. 並び順
1. ホーム
2. 計画
3. 実績
4. 資材・帳票
5. その他
6. パスワード変更
7. ログアウト
### 6-4. 開閉ルール
- カテゴリ見出しタップで開閉
- 現在表示中の画面が属するカテゴリは初期状態で展開してよい
- 項目タップ後はメニューを閉じて画面遷移する
---
## 7. ラベル方針
### 7-1. トップ階層ラベル
- 短く、役割が伝わる言葉を使う
- 詳細機能名は 2 階層目へ寄せる
### 7-2. 用語ルール
- `ホーム` は利用者に最も分かりやすいため維持
- `計画` は作付け、施肥、田植え、運搬を含む包括名として使用
- `実績` は記録系業務のまとめ先とする
- `資材・帳票` はやや広いが、現状機能数とのバランスを優先
- `その他` は補助機能置き場として扱う
将来 `その他` に機能が増えすぎた場合は、次の再編を検討する。
- `連携`
- `設定`
- `通知`
---
## 8. アイコン方針
### 8-1. トップ階層
トップ階層には必要最低限のアイコンのみ使用する。
- ホーム: 家またはダッシュボード系
- 計画: 作物または計画系
- 実績: チェック、記録系
- 資材・帳票: 箱またはファイル系
- その他: 省略記号または設定系
ただし、文字認識を優先し、アイコンは補助扱いとする。
### 8-2. ドロップダウン内
現行アイコンを流用してよいが、すべてに付ける必要はない。
視認性よりも一覧性を優先し、テキスト中心でも可。
---
## 9. 操作性・アクセシビリティ要件
- キーボードでトップメニューにフォーカス移動できること
- `Enter` または `Space` でドロップダウンを開閉できること
- `Esc` で閉じられること
- 現在位置が視覚的に分かること
- タップ領域は十分に確保すること
- スマホで誤タップしにくい行間と余白を確保すること
---
## 10. 実装方針
### 10-1. コンポーネント構成案
`Navbar.tsx` を以下の責務に分ける。
- ブランド表示
- トップメニュー定義
- ドロップダウン表示
- モバイルメニュー表示
- 右端ユーザー操作
必要に応じて次のような補助構成へ分割してよい。
- `navGroups` 定数
- `DesktopNav`
- `MobileNav`
### 10-2. メニュー定義データ化
個別ボタンの直書きはやめ、カテゴリ配列で管理する。
想定イメージ:
```ts
const navGroups = [
{
key: 'home',
label: 'ホーム',
type: 'link',
href: '/dashboard',
},
{
key: 'planning',
label: '計画',
type: 'group',
items: [
{ label: '作付け計画', href: '/allocation' },
{ label: '施肥計画', href: '/fertilizer' },
{ label: '田植え計画', href: '/rice-transplant' },
{ label: '運搬計画', href: '/distribution' },
],
},
];
```
### 10-3. アクティブ判定
アクティブ判定は、現在の `pathname` と各項目の対応パターンで管理する。
例:
- `/fertilizer`
- `/fertilizer/new`
- `/fertilizer/[id]/edit`
はすべて `施肥計画` 所属として扱う。
---
## 11. 段階導入案
### Phase 1
- PC ナビを 5 分類へ再編
- `その他` は単純なリンク群として実装
- モバイルも同じ情報設計へ変更
### Phase 2
- `その他` 内を `メール` `設定` にサブグループ化
- よく使う画面の履歴や最近使った機能を補助表示
### Phase 3
- 利用頻度に応じたパーソナライズ
- 権限や担当業務ごとの表示最適化
---
## 12. 受け入れ条件
- トップレベルに常時表示される業務メニューが 5 項目に収まっていること
- 現在存在する主要画面が、いずれかのカテゴリに漏れなく所属していること
- 各画面でアクティブ状態が期待通りに表示されること
- PC とスマホで同じカテゴリ構成になっていること
- メニューが増えても、トップレベルの項目数を増やさずに拡張できること
---
## 13. 想定される懸念と対応
### 13-1. 「資材・帳票」が少し広すぎる
現時点では機能数のバランスを優先し、この分類を採用する。
今後、帳票やマスタ管理が増えた場合は `資材``帳票・管理` に再分割する。
### 13-2. 「その他」が曖昧
現時点では補助機能数が少ないため許容する。
メール、設定、外部連携系が増えた段階で再分割を検討する。
### 13-3. 既存ユーザーが場所を見失う
初期導入時は以下を行う。
- 並び順をできるだけ業務の流れに合わせる
- ドロップダウン内で既存画面名は変更しない
- ダッシュボード上に主要導線を残す
---
## 14. 結論
現行の 1 画面 1 ボタン方式は、今後の機能追加に対して拡張性が低い。
そのため、トップナビは `ホーム / 計画 / 実績 / 資材・帳票 / その他` の 5 分類へ再編し、個別画面はドロップダウン配下に置く。
この構成により、利用者は「画面名」ではなく「やりたい業務」から機能を探せるようになり、将来の機能追加にも耐えやすくなる。