akira/keinasystem
1
0
Fork 0
Code Issues 7 Pull Requests Actions Packages Projects Releases Wiki Activity
Files
main
keinasystem/document/17_マスタードキュメント_ナビゲーション再編編.md
akira ac0bc7b6a9 マスタードキュメント化しました。追加したのは 17_マスタードキュメント_ナビゲーション再編編.md です。 
内容は、今回の仕様案をそのまま移すだけでなく、

なぜこの再編が必要になったか
なぜ マスター / 帳票・連携 という分類にしたか
URL とメニューをどう切り分けるか
Phase 1〜3 をどう進めるか
まで、長期参照向けに整理してあります。
改善案/ナビゲーション再編仕様書.md は実装向け詳細、今回追加したマスタードキュメントは長期保管用、Issue #13 は議論の背景、という役割分担にしています。必要なら次に、既存のどこかからこの 17_...md へ参照リンクを足します。
2026-04-07 11:12:19 +09:00

10 KiB
Raw Permalink Blame History

マスタードキュメント：ナビゲーション再編

作成: 2026-04-07 最終更新: 2026-04-07 対象機能: グローバルナビゲーション再編（トップメニュー整理・カテゴリ再編・PC/スマホ共通情報設計） 実装状況: 仕様策定完了・未実装

概要

機能追加に伴って共通ナビゲーションのトップレベル項目が増え、画面名ベースで並ぶ構造になってきたため、業務カテゴリ単位で再整理する。

今回の再編では、トップナビを ホーム / 計画 / 実績 / マスター / 帳票・連携 の 5 分類に絞り、個別画面はドロップダウン配下に集約する。 これにより、利用者が「どの画面名か」ではなく「何をしたいか」で画面を探せる状態を目指す。

また、URL 構造とメニュー構成は意図的に分離して扱う。既存 URL は安定性を優先して原則維持し、アクティブ判定はナビ定義側で吸収する。

機能スコープ（IN / OUT）

IN（今回対象） OUT（今回対象外）
PC ヘッダーのトップメニュー再編 各業務画面自体のUI改修
スマホ用ハンバーガーメニュー再編 権限別メニュー出し分け
メニュー分類、並び順、開閉仕様 お気に入り、ピン留め
アクティブ判定ルール整理 ダッシュボード内容の刷新
NavGroup / NavItem ベースのメニュー定義整理 URL の全面変更
作物 品種 を将来のマスター画面として位置づけ 矢印キー移動を含む高度なメニューアクセシビリティ

背景と判断理由

現状の課題

  • 横並びのトップメニュー数が多く、目的の画面を探しにくい
  • 計画 実績 設定 補助機能 が同じ粒度で並んでいる
  • 画面名ベースで項目が増えており、業務単位でまとまっていない
  • 今後も機能追加が続くと、視認性と拡張性の両方が悪化する

採用した考え方

  1. トップレベルは日常的に使う業務カテゴリだけに絞る
  2. 個別機能名ではなく、業務単位で束ねる
  3. URL はリソース識別子として安定性を優先し、メニュー構成とは分離する
  4. 例外的な URL 衝突のみナビ定義側のルールで吸収する

関連議論

  • 判断理由、論点の切り分け、URL とメニューの関係整理は Gitea Issue #13 に残す
  • 実装向けの決定事項は 改善案/ナビゲーション再編仕様書.md に集約する
  • 本ドキュメントは、その内容を長期参照用に固定化したものとして扱う

情報設計

トップレベル構成

  1. ホーム
  2. 計画
  3. 実績
  4. マスター
  5. 帳票・連携

右上ユーザー操作:

  • パスワード変更
  • ログアウト

カテゴリ構成

ホーム

  • ダッシュボード

計画

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

実績

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

マスター

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

帳票・連携

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

この分類にした理由

マスター

  • 圃場管理 は圃場マスタとして独立性が高い
  • 作物 品種 も本来マスター管理である
  • 資材マスタ 肥料マスタ はすでに独立画面が存在する

そのため、基礎データ管理を マスター に集約する。

帳票・連携

  • 在庫管理 帳票出力 データ取込 気象 メール は完全に同質ではない
  • ただし、いずれも主作業そのものではなく、補助・参照・出力・連携の性質が強い

そのため、トップ階層を増やしすぎないための受け皿として 帳票・連携 にまとめる。

補足:

  • データ取込 は日常操作ではなく、年度切替時や初期設定時の補助導線とみなす
  • メール は個別トップにしない
  • 設定 は現状パスワード変更のみなので、右上ユーザー操作に残す

画面と所属カテゴリ

カテゴリ ラベル パス
ホーム ダッシュボード /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

URL とナビゲーションの関係

基本原則

  1. URL はリソース・機能識別子として安定性を優先する
  2. メニュー構成とは意図的に分離して扱う
  3. メニュー再編のたびに URL を変更しない
  4. アクティブ判定はナビ定義側のルールで吸収する

採用理由

  • URL をメニュー階層に合わせて変更すると、既存リンク、ブックマーク、テストへの影響が大きい
  • メニュー構成は将来も変わりうるため、URL にメニュー階層を埋め込むと変更コストが増える

衝突する既存パス

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

通常判定:

  • /fertilizer /fertilizer/new /fertilizer/[id]/edit は 施肥計画
  • /materials /materials?tab=... は 在庫管理

表示仕様

PC

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

表示ルール:

  • ホーム は単独リンク
  • 計画 実績 マスター 帳票・連携 はドロップダウン
  • 開いているメニューがある状態で別メニューを開く場合は、前のメニューを閉じる
  • メニュー外クリック、Esc キーで閉じる
  • 項目選択後は遷移して閉じる

スマホ

  • ハンバーガーメニューを採用する
  • ホーム は単独リンクで /dashboard へ遷移する
  • それ以外のカテゴリはアコーディオン形式で開閉する
  • 現在表示中の画面が属するカテゴリは初期状態で展開してよい
  • 項目タップ後はメニューを閉じて画面遷移する

アクセシビリティ方針

  • トップメニューへキーボードでフォーカス移動できること
  • Enter または Space でドロップダウンを開閉できること
  • ドロップダウン展開後、各項目へ Tab で到達できること
  • Esc で閉じられること
  • 現在位置が視覚的に分かること

初期実装でやらないこと

  • 矢印キーによるドロップダウン項目間移動

これは Phase 1 の必須要件には含めず、将来のアクセシビリティ強化項目として扱う。

実装方針

メニュー定義

メニュー定義はフラットな group 管理ではなく、階層構造で持つ。

type NavItem = {
  label: string;
  href: string;
  match?: (pathname: string) => boolean;
};

type NavGroup = {
  key: string;
  label: string;
  type: 'link' | 'group';
  href?: string;
  items?: NavItem[];
};

方針:

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

Next.js App Router との関係

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

段階導入

Phase 1

  • トップナビを 5 分類へ再編する
  • マスター 配下に表示するのは 圃場管理 資材マスタ 肥料マスタ のみ
  • 作物 品種 はマスター体系には含めるが、独立画面がまだないため Phase 1 ではメニューに表示しない
  • PC / スマホともに同じ情報設計にそろえる

Phase 2

  • 作物管理 品種管理 を独立画面として追加
  • 帳票・連携 内の メール を必要に応じてサブグループ化

Phase 3

  • 将来マルチユーザー化した場合のみ再検討
  • 単独利用前提の間は実施対象外

受け入れ条件

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

参照

  • 議論の背景・判断理由: Gitea Issue #13 メニューがごちゃごちゃしてきたので、整理する
  • 実装向け詳細仕様: 改善案/ナビゲーション再編仕様書.md
Reference in New Issue View Git Blame Copy Permalink