先に結論
- 設定画面が分かりにくくなる最大の原因は、項目が多いことそのものではなく、情報設計の軸が混ざることです。
- `何の設定か` `誰の設定か` `どこまで影響する設定か` `今この画面で触るべき設定か` が同時に分からなくなると、ユーザーは迷います。
- 特に崩れやすいのは、グローバル設定、ワークスペース設定、個別項目設定、権限別表示、例外オプションが後付けで積み上がったサービスです。
- 改善には、ラベル修正より先に、主語、階層、影響範囲、依存関係を整理し直す必要があります。
設定画面が分かりにくいサービスを見ると、よく 項目が多すぎる 文言が難しい と言われます。
もちろんそれも一因です。
ただ、実際にはもっと根本にあるのは、設定の並べ方そのものが崩れていることです。
見た目を整えても、構造が崩れたままでは迷いは消えません。
設定を開いた人が どこに行けばよいか この変更がどこへ効くのか 自分に見えていない設定があるのか を判断できないからです。
この記事では、2026年4月28日時点で Atlassian Administration の新しい情報設計案内と Microsoft Learn の情報アーキテクチャ関連資料を確認しながら、設定画面が分かりにくくなるサービスに共通する構造の問題を整理します。
まず結論: 設定は「一覧」より「地図」が必要
設定画面で困るのは、選択肢が多いことだけではありません。
本当に困るのは、設定同士の地図が見えないことです。
たとえば利用者は、次のどれかを知りたいことが多いです。
- 通知を止めたい
- メンバーの権限を変えたい
- 請求先を変えたい
- ある機能を特定チームだけに有効化したい
- この設定変更が全体に効くのか、一部にだけ効くのかを知りたい
このとき必要なのは、設定項目のフルリストではありません。
目的から辿れること と 影響範囲が分かること です。
Microsoft Learn でも、ナビゲーションはユーザーが何を利用できるか、どう操作するかを理解できるように設計すべきだと整理しています。
設定画面でも同じで、内部の実装都合ではなく、利用者の判断に必要な単位で構成しないと分かりにくくなります。
1. 分類軸が混ざる
最も多いのは、設定の並び方に複数の軸が混ざることです。
たとえば、同じ設定メニューの中に次の軸が同居している状態です。
- 機能ごとの分類
- 部門やチームごとの分類
- 権限者向けの分類
- 請求や契約など運用上の分類
- セキュリティや監査など管理上の分類
これが混ざると、利用者は 通知設定 を探しているのに、アカウント にあるのか ワークスペース にあるのか プロジェクト にあるのか分からなくなります。
同じ 設定 という言葉で包まれていても、主語が違うからです。
設定画面が分かりにくいサービスでは、たいてい
- 何を設定する画面か
- 誰のための設定か
- どの単位に効く設定か
が分離されずに並んでいます。
2. 主語と影響範囲が見えない
設定の怖さは、変更すると影響が出ることです。
そのため利用者は、ラベル以上に 誰に効くか を知りたがります。
ところが分かりにくい設定画面では、次が見えません。
- 自分だけに効くのか
- チーム全体に効くのか
- 組織全体に効くのか
- 新規作成分だけに効くのか
- 既存データにも遡って効くのか
この情報がないと、設定変更は単なる入力作業ではなく、賭けになります。
結果として、ユーザーは触るのを避けるか、逆に何となく変えて事故を起こします。
Atlassian が Administration で features and settings を見つけやすくする improved information architecture を打ち出しているのも、設定そのものより、設定の置き場所と見つけ方が運用上のボトルネックになりやすいからです。
3. 継承と上書きの構造が隠れている
設定画面が一気に難しくなるのは、継承と上書きが入った瞬間です。
たとえば次のような構造です。
- 組織全体のデフォルト設定がある
- ワークスペースで一部だけ上書きできる
- 個別プロジェクトでさらに例外を持てる
- 個人設定でも表示だけ変えられる
この構造自体は悪くありません。
問題は、どこで継承され、どこで上書きされているかが画面上で分からないことです。
Microsoft Learn の SharePoint 情報設計資料でも、古い階層的な構造は継承されたナビゲーションや権限を持ちやすく、いったん組むと柔軟性が低く保守しにくいと整理されています。
設定画面も同じで、階層が深いのに継承の見え方が弱いと、今見ている値はどこから来たのか が追えなくなります。
これは特に、RBAC や通知設定、公開設定、承認フロー設定のように、複数の単位で制御がかかる画面で起きやすいです。
4. 権限で見える世界が変わりすぎる
設定画面は、権限によって見える項目が変わることが多いです。
これは必要ですが、雑にやると強い分かりにくさを生みます。
よくある問題は次の通りです。
- 管理者だけに一部タブが見える
- 一般ユーザーには説明なしで項目が消える
- 別の権限を持つ人の画面と構造が違いすぎる
- ヘルプ記事や案内文と自分の画面が一致しない
この状態では、設定が存在しない のか 自分に見えていないだけ なのかが判別できません。
結果として、ユーザーはサポートに聞くしかなくなります。
権限設計があるサービスほど、見せない だけでなく どの権限で見えるか を説明する必要があります。
社内ツールや管理画面でここが崩れると、運用者も迷い続けます。
権限そのものの分け方は 社内の業務システムを構築する際のセキュリティ対策は？どこまでやるべきかを整理 でも整理していますが、設定画面ではその権限差が情報構造の見え方まで左右します。
5. 例外が後付けで積み上がる
設定画面が崩れるサービスは、最初から悪い設計だったとは限りません。
むしろ多いのは、最初は分かりやすかったのに、あとから例外を足し続けて崩れるケースです。
たとえば、
- 一部プランだけの機能
- 特定顧客向けの挙動
- 旧仕様を残す互換設定
- 監査要件に合わせた追加オプション
- 新UIと旧UIの並存
のようなものです。
こうした例外は1つずつ見ると合理的でも、設定画面全体では 普通の設定 と 特殊条件の設定 が混ざり、判断のコストが上がります。
分かりにくい設定画面では、通常フローよりも ただしこの場合は別 が増えています。
これは UI の問題というより、プロダクトの歴史がそのまま露出している状態です。
6. 内部組織の都合で分割されている
ユーザーは 何をしたいか で設定を探します。
でも、サービス側は どのチームが担当しているか で設定を分けがちです。
その結果、
- 請求チームが持つ請求設定
- セキュリティチームが持つ認証設定
- プロダクトチームが持つ機能設定
- サポートチームが持つ通知設定
が別々に育ち、利用者から見ると一貫性がなくなります。
ラベルだけ揃えても、遷移の考え方や影響範囲の示し方が揃っていないと、同じサービスなのに設定ごとに流儀が違う と感じます。
Atlassian が複数製品間でナビゲーションの一貫性を強めようとしているのも、この断絶が横断利用の摩擦になるからです。
7. 初回設定と日常運用の設定が同居する
設定の中には、最初だけ決めればよいものと、日常的に調整するものがあります。
この2種類を混ぜると、使いづらさが一気に増します。
たとえば、
- 初期導入時に一度だけ決める認証方式
- 管理者が毎週見る通知先
- 月に一度見直す請求情報
- 現場担当者が頻繁に変える表示設定
が同じ階層に並ぶと、重要度も利用頻度も違うため、どこを日常的に触る場なのか分かりません。
特に、導入直後に迷わせる設定構造は、オンボーディングの失敗にも直結します。
初回体験の設計を広く見たい場合は オンボーディングとは何か？最初の利用体験を設計する考え方 も関連します。
よくある崩れ方
| 崩れ方 | 何が起きるか | 根本原因 |
|---|---|---|
| 似た設定が複数の場所にある | どれが正しい入口か分からない | 分類軸が混ざっている |
| 今の値の由来が分からない | 変更を怖がって触れない | 継承と上書きの見せ方が弱い |
| ヘルプどおりに項目が見えない | サポート依存が増える | 権限差の説明がない |
| 高度な設定が通常設定に混ざる | 日常運用の邪魔になる | 利用頻度と重要度の整理不足 |
改善するときに先に決めたいこと
設定画面を改善するとき、先に色や余白をいじっても限界があります。
まずは次を決める方が効きます。
1. 何を主語にするか
設定の主語を、少なくとも次のどれかに固定します。
- 個人
- チーム / ワークスペース
- プロジェクト / 個別項目
- 組織全体
これが決まるだけで、同じ 通知 でも置き場所がかなり明確になります。
2. 影響範囲を必ず明示する
各設定に対して、少なくとも
- 誰に効くか
- いつから効くか
- 既存データへ影響するか
- 元に戻せるか
を見せる方が安全です。
3. 継承元と上書き先を見える化する
この値は組織設定を継承中 このプロジェクトで上書き中 のように、値の出どころを見せるだけで理解しやすさは大きく変わります。
4. 例外設定を隔離する
通常利用の設定と、移行用・互換用・高度設定を同じ棚に置かない方が崩れにくいです。
詳細設定 に押し込めればよいという話ではなく、通常フローと例外フローを分けることが大事です。
まとめ
設定画面が分かりにくくなるサービスに共通するのは、UI の細部より、情報設計の構造が崩れていることです。
分類軸の混在、影響範囲の不明瞭さ、継承と上書きの見えにくさ、権限差の断絶、例外の積み上がりが重なると、設定は増えるほど迷路になります。
逆に言えば、改善の出発点は 文言を少し分かりやすくすること だけではありません。
まずは
- 主語を固定する
- 影響範囲を見せる
- 継承関係を見せる
- 権限差を説明する
- 例外設定を隔離する
この順で構造を整える方が効きます。
設定画面は、機能が増えた結果として自然に複雑になるものではなく、構造を放置すると複雑さが利用者へ漏れ出る場所だと考えた方が、長く運用しやすいサービスになります。
参考リンク
- Atlassian Support: Navigate Atlassian Administration
- Microsoft Learn: Information architecture in modern SharePoint
- Microsoft Learn: Information architecture models and examples