Files
keinasystem/改善案/ナビゲーション再編仕様書.md
2026-04-07 10:01:02 +09:00

12 KiB

ナビゲーション再編仕様書

作成日: 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. メニュー定義データ化

個別ボタンの直書きはやめ、カテゴリ配列で管理する。

想定イメージ:

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 分類へ再編し、個別画面はドロップダウン配下に置く。

この構成により、利用者は「画面名」ではなく「やりたい業務」から機能を探せるようになり、将来の機能追加にも耐えやすくなる。