Files

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

反映した内容は次の通りです。

5-3 に、初期実装ではブラウザ標準の Tab 移動を基本とすることを追記
5-3 に、矢印キーでの項目間移動は Phase 1 の必須要件外と明記
9 に、ドロップダウン展開後は Tab で各項目へ到達できることを追加
9 に、矢印キー移動は将来のアクセシビリティ強化項目として扱うと追記
これで、キーボード操作の範囲について実装者が迷いにくくなったはずです。

2026-04-07 11:09:51 +09:00

18 KiB

Raw Permalink Blame History

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

作成日: 2026-04-07 対象: frontend/src/components/Navbar.tsx 方針: 第一候補「上段5分類 + ドロップダウン」

0. 背景

現状のグローバルナビゲーションは、機能追加のたびに横並びのボタンを増やしており、以下の問題が出ている。

上位階層の導線が多すぎて、目的の画面を探しにくい
「計画」「実績」「設定」「補助機能」が同じ粒度で並んでいる
メール関連のように、単独トップに置くほどではない機能が場所を取りやすい
今後も機能追加が続くと、横幅不足と認知負荷の両方が悪化する

このため、トップナビは「日常的に使う業務カテゴリ」だけを見せ、個別画面はドロップダウン配下へ整理する。

1. 目的

1-1. 目指す状態

1階層目では「何をしたいか」で探せる
似た役割の画面を同じカテゴリに集約する
画面数が増えても、トップレベルの見た目を増やしすぎない
PC とスマホで同じ情報設計を維持する

1-2. 今回の対象

共通ヘッダー内のグローバルナビゲーション再編
メニュー分類、ラベル、並び順、開閉仕様の定義
各画面がどのカテゴリに属するかの明確化

1-3. 今回やらないこと

各業務画面そのものの UI 改修
権限別メニュー出し分け
お気に入り機能、ピン留め機能
ナビゲーションと連動したダッシュボード内容の刷新

1-4. 関連 Issue との役割分担

Issue #13 メニューがごちゃごちゃしてきたので、整理する は、背景、論点、判断理由を残す親議論として扱う
本仕様書は、その議論を踏まえた実装向けの決定事項をまとめる文書として扱う
後から判断理由を確認したい場合は Issue #13 を参照する

2. 基本方針

2-1. トップレベル構成

トップナビでは以下の 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`
マスター	作物	`未実装: allocation 内管理を独立予定`
マスター	品種	`未実装: allocation 内管理を独立予定`
マスター	資材マスタ	`/materials/masters`
マスター	肥料マスタ	`/fertilizer/masters`
帳票・連携	在庫管理	`/materials`
帳票・連携	帳票出力	`/reports`
帳票・連携	データ取込	`/import`
帳票・連携	気象	`/weather`
帳票・連携 > メール	メール履歴	`/mail/history`
帳票・連携 > メール	メールルール	`/mail/rules`
右上ユーザー操作	パスワード変更	`/settings/password`

4-2. アクティブ表示ルール

その画面自身、またはその配下詳細画面にいる場合、所属カテゴリをアクティブにする
ドロップダウン内の該当項目も個別にアクティブ表示する
パス接頭辞だけで判定するとカテゴリが衝突する画面があるため、より具体的なパスを優先して判定する
特に 施肥計画 と 散布実績 はともに /fertilizer 配下を使うため、/fertilizer/spreading を先に判定し、計画 側から明示的に除外する
同様に 在庫管理 と 資材マスタ はともに /materials 配下を使うため、/materials/masters を先に判定し、帳票・連携 側の 在庫管理 から明示的に除外する
例:
- /fertilizer は 計画 をアクティブ
- /fertilizer/new は 計画 をアクティブ
- /fertilizer/[id] および /fertilizer/[id]/edit は 計画 をアクティブ
- /fertilizer/spreading は 実績 をアクティブ
- /fertilizer/spreading?... も 実績 をアクティブ
- /materials は 帳票・連携 をアクティブ
- /materials/masters は マスター をアクティブ
例:
- /fields/123 の場合は マスター がアクティブ
- /fertilizer/10/edit の場合は 計画 がアクティブ
- /mail/history の場合は 帳票・連携 と メール履歴 がアクティブ

5. PC 表示仕様

5-1. レイアウト

PC ではヘッダーを 3 ブロック構成とする。

左: ブランド名 KeinaSystem
中央: トップメニュー 5 項目
右: パスワード変更、ログアウト

5-2. トップメニューの見せ方

ホーム は単独リンク
計画 実績 マスター 帳票・連携 はドロップダウン付きメニュー
ラベルの横に開閉アイコンを表示する
開いたメニューは白背景のパネルとして表示する

5-3. 開閉ルール

クリックで開閉
開いている他メニューがある場合は、それを閉じてから新しいメニューを開く
メニュー外クリックで閉じる
Esc キーで閉じる
キーボード操作は初期実装ではブラウザ標準の Tab 移動を基本とする
矢印キーによるドロップダウン項目間移動は Phase 1 の必須要件には含めない
項目クリック後は遷移して閉じる

5-4. ドロップダウンの表示内容

各項目は以下の順で並べる。

計画

作付け計画
施肥計画
田植え計画
運搬計画

実績

散布実績
畔塗記録
作業記録

マスター

圃場管理
作物
品種
資材マスタ
肥料マスタ

帳票・連携

在庫管理
帳票出力
データ取込
気象
メール

メール は 2 段構造にする方法と、直接展開せず一覧モーダル風に見せる方法があるが、初期実装ではシンプルさを優先し、帳票・連携 ドロップダウン内に個別リンクを直接置く。

初期実装の並び:

在庫管理
帳票出力
データ取込
気象
メール履歴
メールルール

なお情報設計上の名称としては メール を維持し、将来的に機能が増えた時点で再度サブグループ化する。

6. スマホ表示仕様

6-1. 基本方針

スマホではハンバーガーメニューを採用する。 PC と同じカテゴリ構成を維持し、見た目だけ縦並びにする。

6-2. 表示ルール

初期状態ではロゴ、メニューボタン、ログアウト系導線のみ表示
メニューボタン押下で全画面または右スライドのメニューを開く
カテゴリはアコーディオン形式で開閉する

6-3. 並び順

ホーム
計画
実績
マスター
帳票・連携
パスワード変更
ログアウト

6-4. 開閉ルール

ホーム は単独リンクとし、タップ時はそのまま /dashboard へ遷移する
カテゴリ見出しタップで開閉
現在表示中の画面が属するカテゴリは初期状態で展開してよい
項目タップ後はメニューを閉じて画面遷移する

7. ラベル方針

7-1. トップ階層ラベル

短く、役割が伝わる言葉を使う
詳細機能名は 2 階層目へ寄せる

7-2. 用語ルール

ホーム は利用者に最も分かりやすいため維持
計画 は作付け、施肥、田植え、運搬を含む包括名として使用
実績 は記録系業務のまとめ先とする
マスター は日々の業務を支える基礎データ管理の置き場とする
帳票・連携 は出力、取込、通知、補助参照のまとめ先とする

将来 帳票・連携 に機能が増えすぎた場合は、次の再編を検討する。

帳票
連携
通知

8. アイコン方針

8-1. トップ階層

トップ階層には必要最低限のアイコンのみ使用する。

ホーム: 家またはダッシュボード系
計画: 作物または計画系
実績: チェック、記録系
マスター: 設定、リスト、データベース系
帳票・連携: ファイル、送受信、クラウド系

ただし、文字認識を優先し、アイコンは補助扱いとする。

8-2. ドロップダウン内

現行アイコンを流用してよいが、すべてに付ける必要はない。視認性よりも一覧性を優先し、テキスト中心でも可。

9. 操作性・アクセシビリティ要件

キーボードでトップメニューにフォーカス移動できること
Enter または Space でドロップダウンを開閉できること
ドロップダウン展開後、各項目へ Tab で到達できること
Esc で閉じられること
矢印キーによる項目間移動は初期実装の必須要件には含めず、将来のアクセシビリティ強化項目として扱う
現在位置が視覚的に分かること
タップ領域は十分に確保すること
スマホで誤タップしにくい行間と余白を確保すること

10. 実装方針

10-1. コンポーネント構成案

Navbar.tsx を以下の責務に分ける。

ブランド表示
トップメニュー定義
ドロップダウン表示
モバイルメニュー表示
右端ユーザー操作

必要に応じて次のような補助構成へ分割してよい。

navGroups 定数
DesktopNav
MobileNav

10-2. メニュー定義データ化

個別ボタンの直書きはやめ、カテゴリ配列で管理する。メニュー定義はフラットな group 管理ではなく、階層構造で持つ。

方針:

グループ構成そのものが定義から読み取れることを優先する
通常ケースは href ベースで扱う
href ベースで判定しきれない例外ケースだけ match を持つ
match は全件定義用ではなく、衝突回避用の最小限の逃げ道として使う

想定イメージ:

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',
    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 と各項目の対応パターンで管理する。

基本原則:

URL はリソース・機能識別子として安定性を優先し、メニュー階層とは分離して扱う
メニュー再編のたびに URL を変更しない
アクティブ判定はナビ定義側のルールで吸収する
ただし、全件をルーターのように再定義するのではなく、通常ケースは href ベース、衝突ケースだけ match を使う

補足:

Next.js App Router の Route Groups は、URL を変えずにコード構造を整理する手段としては有効
ただし Route Groups はナビ判定そのものの代替ではなく、実装整理の補助手段として扱う

パス接頭辞衝突が起きる組み合わせは、具体パス優先で次のように扱う。

優先判定するパス	所属カテゴリ	除外される側
`/fertilizer/spreading`	実績	計画 > 施肥計画
`/materials/masters`	マスター	帳票・連携 > 在庫管理

通常判定の例:

/fertilizer
/fertilizer/new
/fertilizer/[id]/edit

はすべて 施肥計画 所属として扱う。

/materials
/materials?tab=...

は 在庫管理 所属として扱う。

実装上は、上記の衝突ケースのみ NavItem.match を使う想定とする。

11. 段階導入案

Phase 1

PC ナビを 5 分類へ再編
作物 品種 はマスター体系に含めるが、Phase 1 ではメニューに表示しない
Phase 1 の マスター 配下に表示するのは 圃場管理 資材マスタ 肥料マスタ のみとする
作物 品種 は未実装項目として仕様上は位置づけ、独立画面が用意できる Phase 2 でメニュー表示を開始する
モバイルも同じ情報設計へ変更

Phase 2

作物管理 品種管理 を独立画面として追加
帳票・連携 内の メール をサブグループ化
よく使う画面の履歴や最近使った機能を補助表示

Phase 3

将来マルチユーザー化した場合の再設計検討
権限や担当業務ごとの表示最適化の要否整理
単独利用を前提とする間は、Phase 3 は実施対象外とする

12. 受け入れ条件

トップレベルに常時表示される業務メニューが 5 項目に収まっていること
現在存在する主要画面が、いずれかのカテゴリに漏れなく所属していること
各画面でアクティブ状態が期待通りに表示されること
PC とスマホで同じカテゴリ構成になっていること
メニューが増えても、トップレベルの項目数を増やさずに拡張できること

13. 想定される懸念と対応

13-1. 「マスター」に含める範囲

現時点では、圃場管理 作物 品種 資材マスタ 肥料マスタ を マスター として集約する。日々の入力対象ではなく、業務の前提データを整える画面群としてまとめるのが自然である。

補足:

圃場管理 は圃場マスタとして独立性が高い
作物 と 品種 も本来マスター管理であり、現状は allocation 画面内で扱っているだけで、メニュー上は独立させる前提で考える
資材マスタ と 肥料マスタ はすでに独立ページがあり、マスター 配下に置くのが自然である
将来、地図、圃場グループ、所有者管理などが増えた場合は、圃場マスタ の再独立も検討する

13-2. 「帳票・連携」が少し広い

現時点では 在庫管理 帳票出力 データ取込 気象 メール をまとめる。完全に同じ性質ではないが、いずれも補助業務、参照、連携、出力に近い機能であり、トップ階層を増やしすぎないために同居させる。

13-3. 「データ取込」は日常操作ではない

データ取込 は日常的に何度も使う画面ではなく、年度切替時や初期設定時に使う補助導線である。そのためトップレベル常設には置かず、帳票・連携 配下に置く判断は妥当とする。

ただし今後、取込対象や運用頻度が増えた場合は、設定 または 運用 系カテゴリへの移設も検討対象とする。

13-4. 既存ユーザーが場所を見失う

初期導入時は以下を行う。

並び順をできるだけ業務の流れに合わせる
ドロップダウン内で既存画面名は変更しない
ダッシュボード上に主要導線を残す

14. 結論

現行の 1 画面 1 ボタン方式は、今後の機能追加に対して拡張性が低い。そのため、トップナビは ホーム / 計画 / 実績 / マスター / 帳票・連携 の 5 分類へ再編し、個別画面はドロップダウン配下に置く。

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

18 KiB Raw Permalink Blame History

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

0. 背景

1. 目的

1-1. 目指す状態

1-2. 今回の対象

1-3. 今回やらないこと

1-4. 関連 Issue との役割分担

2. 基本方針

2-1. トップレベル構成

2-2. 設計ルール

3. 情報設計

3-1. カテゴリ構成

ホーム

計画

実績

マスター

帳票・連携

3-2. メールの扱い

3-3. 設定の扱い

4. 画面とメニューの対応

4-1. 現在の主要画面の所属

4-2. アクティブ表示ルール

5. PC 表示仕様

5-1. レイアウト

5-2. トップメニューの見せ方

5-3. 開閉ルール

5-4. ドロップダウンの表示内容

計画

実績

マスター

帳票・連携

6. スマホ表示仕様

6-1. 基本方針

6-2. 表示ルール

6-3. 並び順

6-4. 開閉ルール

7. ラベル方針

7-1. トップ階層ラベル

7-2. 用語ルール

8. アイコン方針

8-1. トップ階層

8-2. ドロップダウン内

9. 操作性・アクセシビリティ要件

10. 実装方針

10-1. コンポーネント構成案

10-2. メニュー定義データ化

10-3. アクティブ判定

11. 段階導入案

Phase 1

Phase 2

Phase 3

12. 受け入れ条件

13. 想定される懸念と対応

13-1. 「マスター」に含める範囲

13-2. 「帳票・連携」が少し広い

13-3. 「データ取込」は日常操作ではない

13-4. 既存ユーザーが場所を見失う

14. 結論

18 KiB

Raw Permalink Blame History