メニューがごちゃごちゃしてきたので、整理する #13

New Issue

akira · 2026-04-07T01:56:35Z

akira commented

2026-04-07 01:56:35 +00:00

現在の状態（なぜOpenか）

進行中

次にすること（Next Action）

メニューやURLの仕様を固める

ブロック要因

なし

問題・背景

機能追加に伴って、共通ナビゲーションに画面をそのまま足してきたため、トップレベルのメニューが増えすぎている。

現状の問題は主に以下。

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

このため、トップレベルの情報設計を整理し直す必要がある。

ここまでの議論で合意した方向

1. トップレベルは 5 分類に絞る

現時点の第一候補は以下。

ホーム
計画
実績
マスター
帳票・連携

理由:

日常的に使う業務カテゴリだけを上段に残すため
個別機能名ではなく、業務のまとまりで探せるようにするため
今後機能が増えてもトップレベルの項目数を増やしすぎないため

2. 「マスター」を独立カテゴリにする

当初は 資材・帳票 という案もあったが、議論の中で以下が明確になった。

圃場管理 は本質的にマスターデータ管理である
作物 品種 も本来はマスター管理に属する
資材マスタ 肥料マスタ はすでに独立画面がある

したがって、圃場管理 作物 品種 資材マスタ 肥料マスタ を マスター として集約する方が自然、という判断になった。

3. 「帳票・連携」は補助業務の受け皿とする

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

そのため、トップ階層を増やしすぎないためのまとめ先として 帳票・連携 を置く。

補足:

データ取込 は日常操作ではなく、年度切替時や初期設定時の補助導線として扱う
メール は個別トップにせず、帳票・連携 配下にまとめる
設定 は現状パスワード変更のみなので、右上ユーザー操作に残す

URL とメニュー構成についての議論

議論の中で、/fertilizer と /fertilizer/spreading のように、URL 構造がメニュー階層と一致していないことが衝突の原因ではないか、という指摘があった。

これはその通りだが、次の理由から「今回のメニュー再編で URL を全面変更する」のはスコープ外とする。

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

今回の基本方針

URL はリソース・機能識別子として安定性を優先する
メニュー構成とは意図的に分離して扱う
ナビのアクティブ判定はメニュー定義側のルールで管理する
ただし、全件をルーターのように再定義するのではなく、通常ケースは href ベース、衝突ケースだけ例外ルールを持つ

現時点で明確になっている衝突

/fertilizer = 計画 > 施肥計画
/fertilizer/spreading = 実績 > 散布実績
/materials = 帳票・連携 > 在庫管理
/materials/masters = マスター > 資材マスタ

このため、少なくとも上記のペアについては「より具体的なパスを優先する」判定が必要。

メニュー定義の持ち方についての議論

議論の結果、メニュー定義はフラットな 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 ベースで扱う
例外ケースだけ match を使う
match は全件定義用ではなく、衝突回避用の最小限の逃げ道とする

また、Next.js App Router の Route Groups は「コード整理の手段」として有効だが、ナビ判定そのものとは分けて考える、という整理にしている。

Phase 導入で決めたこと

Phase 1

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

Phase 2

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

Phase 3

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

検討事項

メニュー仕様をどこまで Issue 本文に持ち、どこから仕様書へ委譲するか
作物 品種 の独立画面追加時に URL をどう切るか
帳票・連携 が今後広くなりすぎた場合の再分割基準
Route Groups をコード整理のために採用するかどうか

参考仕様書

改善案/ナビゲーション再編仕様書.md

この Issue は「なぜこの分類にしたか」「どの論点をどう切り分けたか」を残す親議論として扱い、実装詳細は上記仕様書に集約する。

完了条件

メニュー再編の情報設計が確定している
URL とナビの関係について基本方針が確定している
実装者が Issue を読んだだけでも、判断理由とスコープ境界が分かる

関連

仕様書: 改善案/ナビゲーション再編仕様書.md

## 現在の状態（なぜOpenか）進行中 ## 次にすること（Next Action）メニューやURLの仕様を固める ## ブロック要因なし --- ## 問題・背景機能追加に伴って、共通ナビゲーションに画面をそのまま足してきたため、トップレベルのメニューが増えすぎている。現状の問題は主に以下。 - 横並びのメニュー数が多く、目的の画面を探しにくい - `計画` `実績` `設定` `補助機能` が同じ粒度で並んでいる - 画面名ベースでメニューが増えており、業務単位でまとまっていない - 今後さらに機能が増えると、視認性と拡張性の両方が悪化するこのため、トップレベルの情報設計を整理し直す必要がある。 --- ## ここまでの議論で合意した方向 ### 1. トップレベルは 5 分類に絞る現時点の第一候補は以下。 1. ホーム 2. 計画 3. 実績 4. マスター 5. 帳票・連携理由: - 日常的に使う業務カテゴリだけを上段に残すため - 個別機能名ではなく、業務のまとまりで探せるようにするため - 今後機能が増えてもトップレベルの項目数を増やしすぎないため ### 2. 「マスター」を独立カテゴリにする当初は `資材・帳票` という案もあったが、議論の中で以下が明確になった。 - `圃場管理` は本質的にマスターデータ管理である - `作物` `品種` も本来はマスター管理に属する - `資材マスタ` `肥料マスタ` はすでに独立画面があるしたがって、`圃場管理` `作物` `品種` `資材マスタ` `肥料マスタ` を `マスター` として集約する方が自然、という判断になった。 ### 3. 「帳票・連携」は補助業務の受け皿とする `在庫管理` `帳票出力` `データ取込` `気象` `メール` は完全に同質ではないが、いずれも日々の主作業そのものではなく、補助・出力・連携・参照の性質が強い。そのため、トップ階層を増やしすぎないためのまとめ先として `帳票・連携` を置く。補足: - `データ取込` は日常操作ではなく、年度切替時や初期設定時の補助導線として扱う - `メール` は個別トップにせず、`帳票・連携` 配下にまとめる - `設定` は現状パスワード変更のみなので、右上ユーザー操作に残す --- ## URL とメニュー構成についての議論議論の中で、`/fertilizer` と `/fertilizer/spreading` のように、URL 構造がメニュー階層と一致していないことが衝突の原因ではないか、という指摘があった。これはその通りだが、次の理由から「今回のメニュー再編で URL を全面変更する」のはスコープ外とする。 - 既存のリンク、ブックマーク、テストへの影響が大きい - フロント側のルーティング変更コストが高い - メニュー構成は将来も変わりうるため、URL にメニュー階層を埋め込むと変更コストが増える ### 今回の基本方針 - URL はリソース・機能識別子として安定性を優先する - メニュー構成とは意図的に分離して扱う - ナビのアクティブ判定はメニュー定義側のルールで管理する - ただし、全件をルーターのように再定義するのではなく、通常ケースは `href` ベース、衝突ケースだけ例外ルールを持つ ### 現時点で明確になっている衝突 - `/fertilizer` = 計画 > 施肥計画 - `/fertilizer/spreading` = 実績 > 散布実績 - `/materials` = 帳票・連携 > 在庫管理 - `/materials/masters` = マスター > 資材マスタこのため、少なくとも上記のペアについては「より具体的なパスを優先する」判定が必要。 --- ## メニュー定義の持ち方についての議論議論の結果、メニュー定義はフラットな `group` 管理より、階層構造で持つ方が可読性が高いという結論になった。イメージ: ```ts type NavItem = { label: string; href: string; match?: (pathname: string) => boolean; }; type NavGroup = { key: string; label: string; type: 'link' | 'group'; href?: string; items?: NavItem[]; }; ``` ポイント: - グループ構成そのものが定義から読み取れる - 通常ケースは `href` ベースで扱う - 例外ケースだけ `match` を使う - `match` は全件定義用ではなく、衝突回避用の最小限の逃げ道とするまた、Next.js App Router の Route Groups は「コード整理の手段」として有効だが、ナビ判定そのものとは分けて考える、という整理にしている。 --- ## Phase 導入で決めたこと ### Phase 1 - トップナビを 5 分類へ再編する - `マスター` 配下に表示するのは `圃場管理` `資材マスタ` `肥料マスタ` のみ - `作物` `品種` はマスター体系には含めるが、独立画面がまだないため Phase 1 ではメニューに表示しない - スマホメニューも同じ情報設計に合わせる ### Phase 2 - `作物管理` `品種管理` を独立画面として追加 - `帳票・連携` 内の `メール` を必要に応じてサブグループ化 ### Phase 3 - 将来マルチユーザー化した場合のみ再検討 - 単独利用前提の間は実施対象外 --- ## 検討事項 - メニュー仕様をどこまで Issue 本文に持ち、どこから仕様書へ委譲するか - `作物` `品種` の独立画面追加時に URL をどう切るか - `帳票・連携` が今後広くなりすぎた場合の再分割基準 - Route Groups をコード整理のために採用するかどうか --- ## 参考仕様書 - `改善案/ナビゲーション再編仕様書.md` この Issue は「なぜこの分類にしたか」「どの論点をどう切り分けたか」を残す親議論として扱い、実装詳細は上記仕様書に集約する。 ## 完了条件 - メニュー再編の情報設計が確定している - URL とナビの関係について基本方針が確定している - 実装者が Issue を読んだだけでも、判断理由とスコープ境界が分かる ## 関連 - 仕様書: `改善案/ナビゲーション再編仕様書.md`

akira referenced this issue from a commit

2026-04-07 02:19:09 +00:00

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

akira referenced this issue from a commit

2026-04-07 02:19:09 +00:00

マスタードキュメント化しました。追加したのは 17_マスタードキュメント_ナビゲーション再編編.md です。

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: akira/keinasystem#13