機能を増やすほど分かりにくくなるのはなぜか SaaSの複雑化とどう付き合うか

Q: Q. なぜ機能を増やすと分かりにくくなる？

A. 情報設計の硬直化、既存導線への詰め込み、命名の一貫性低下、機能間の重複、が原因。機能数そのものより、構造を維持しないまま積み上げる のが問題です。

Q: Q. Feature Creep(機能膨張)を防ぐには？

A. 機能追加プロセス を設ける。Why(なぜ必要?)、Who(誰のため?)、Alternative(他で代替できない?)、Sunset Plan(使われなければ削除?) の4つを必ず議論します。

Q: Q. 機能を削除する判断は？

A. 利用率 5% 未満が継続、Sunset Notice 配信 → 90日後削除、のような段階的アプローチが定番。一部のヘビーユーザーが反対しても、プロダクト全体の健全性 を優先する判断が必要。

Q: Q. プログレッシブ・ディスクロージャーとは？

A. 必要な人に必要な機能だけ表示する 設計手法。初心者には基本機能のみ、上級者には全機能、と段階的に開示。Notion、Figma などが上手く使っています。

Q: Q. UI が複雑化したら作り直すべき？

A. 一気に作り直すリスクは大きい。Strangler Fig パターン で 新機能だけ新 UI、既存機能を段階的にリニューアル、で進めるのが安全。3〜5年かけてのリニューアル例も多いです。

Q: Q. AI 機能を追加するときの注意点は？

A. AI 機能を増やすほど SaaS は分かりにくくなる リスク高。既存機能の置き換え か 補助 か明確に、AI に何ができて何ができないか の期待値管理が大事。

最初に: 機能が増えること自体より、増え方が分かりにくさを生む

SaaS を育てていくと、機能は自然に増えます。
顧客要望に応え、競合に追いつき、対応業務を広げていけば、機能数が増えるのはむしろ普通です。

問題は、機能が増えることそのものではありません。
本当に効いてくるのは、増えた機能がどんな関係で並んでいるか 誰にとって必要なのか どの順番で理解されるのか が崩れていくことです。

その結果、

できることは多いのに、何を使えばいいか分からない
以前より高機能なのに、前より迷いやすい
ベテランしか使いこなせない
新規顧客の立ち上がりが遅くなる
サポートや営業が説明で補わないと前に進まない

という状態になりやすくなります。

この記事では、2026年4月25日時点で Pendo、Appcues、Nielsen Norman Group の公開情報を確認しながら、SaaS が複雑化する構造と、機能を削る以外にできる付き合い方を整理します。

なぜ機能を増やすほど分かりにくくなるのか

1. 選択肢が増えると、操作より先に判断が必要になる

初期の SaaS は、できることが少ない代わりに、どこを触ればいいかが分かりやすいです。
一方で機能が増えると、ユーザーは操作の前に判断を迫られます。

この機能とあの機能の違いは何か
どちらを先に設定すべきか
自分の権限で使うべきなのはどれか
今回の業務に必要なのはどこまでか

つまり、分かりにくさはボタン数だけではなく、考える分岐が増えること からも生まれます。

これは UI の見た目の問題だけではなく、情報設計の問題でもあります。
整理の軸が弱いまま機能を追加すると、ユーザーは毎回 どれだっけ から始めることになります。

2. 例外対応が増えると、理解コストが跳ね上がる

SaaS が成長すると、一般機能よりも 例外条件 が増えやすいです。

このプランでは使える
この権限だと一部だけ見える
この設定を先に有効化しないと動かない
A の場合はこの画面、B の場合は別画面

こうした条件は一つずつ見ると合理的でも、全体としてはかなり分かりにくさを生みます。

特に困るのは、例外が画面上からは見えにくいことです。
使えない理由や前提条件が先に見えないと、ユーザーは 壊れている 自分の理解が足りない どこで設定するのか分からない で止まりやすくなります。

3. 顧客ごとに必要な機能が違うのに、同じ画面で見せてしまう

SaaS は対象顧客が広がるほど、必要な機能が分かれます。

管理者向け
現場担当向け
請求担当向け
初期導入時だけ必要な機能
日常運用で毎日使う機能

この違いを画面に反映せず、全員に同じナビゲーションや設定画面を見せると、自分に不要な機能 がノイズになります。

すると、本当に必要な機能まで埋もれます。
Pendo や Appcues が機能採用をセグメントごとに見る前提を強調しているのも、この差が大きいからです。

4. 新機能が増えるほど、既存導線とのつながりが弱くなりやすい

新機能は追加時点では目立ちます。
でも時間が経つと、既存画面との関係が弱いまま残りやすいです。

機能はあるが、入口が深い
前提機能とのつながりが見えない
古い導線と新しい導線が並立している
同じ目的に見える機能が複数ある

前の記事でも触れた通り、新機能は出しただけでは使われません。
その積み重ねで、SaaS 全体が なんでもあるけど、どこで使うのか分からない 状態に近づきます。

5. 説明で補う運用が増えると、プロダクトが自力で伝わらなくなる

複雑化した SaaS では、営業、オンボーディング担当、カスタマーサクセス、サポートが説明で埋めていることが増えます。

もちろん、それ自体は悪くありません。
ただし、説明がないと使えない状態が広がると、プロダクトの理解が人依存になります。

その結果、

商談では理解できたのに、導入後に迷う
担当者が変わると使われなくなる
ヘルプ記事を読んでも全体像がつながらない
問い合わせが増える

となりやすくなります。

複雑化しているSaaSに起きやすいサイン

次のような状態が続いているなら、機能不足ではなく複雑化を疑った方がよいです。

新機能より既存機能の説明に時間がかかる
ベテランは使えるが、新規導入でつまずく
問い合わせの中身が どこにあるか分からない に寄る
同じ目的に見える画面が複数ある
権限やプラン差分の説明が長い
管理画面が育つたびにサイドバーが増える
機能は増えたのに、採用率は一部しか伸びない

Pendo の公開データでは、多くのソフトウェアで利用が一部の機能に偏りやすいことが示されています。
つまり、増やした機能の多くが十分に使われていないなら、単に訴求不足ではなく、構造上の複雑さも疑うべきです。

機能を減らさなくても、複雑化と付き合う方法

1. 画面を増やす前に「目的」を整理する

機能単位で増やすと、似た目的のものが並びやすいです。
そこで、まず ユーザーは何を達成したいか で束ね直します。

たとえば、

データを見る
承認する
共有する
設定する
エラーを直す

のように目的単位で整理すると、画面やボタンの役割が見直しやすくなります。

2. 全員に全部見せない

SaaS が大きくなるほど、役割別・利用段階別に見せ方を変えた方がよいです。

初期導入中の人には最初に必要なものだけ見せる
管理者だけに高度な設定を見せる
日常利用者にはよく使う導線を優先する

これは情報を隠すというより、今その人に必要な複雑さだけ出す という考え方です。

3. 高度機能は「深く」置き、基本導線は「浅く」置く

何でもトップ階層に置くと、かえって全体が読めなくなります。
毎日使うものと、管理者がたまに触るものは、同じ深さに置かない方が分かりやすいです。

この差をつけないと、ナビゲーションが広がるだけでなく、ユーザーの視線も散ります。

4. 最初に覚える順番を設計する

複雑な SaaS ほど、全部を一度に理解させようとしない方がうまくいきます。

Appcues が強調するように、オンボーディングは機能一覧の説明より 最初の成果 を作ることが重要です。
つまり、覚える順番は

最初に必要な機能
使い始めてから困る機能
慣れてから効く高度機能

のように分けた方が定着しやすいです。

5. 使われない機能を残す理由を明確にする

すべての機能を同じ熱量で維持する必要はありません。

コア機能なのか
一部顧客にとって必須なのか
今は使われなくても契約要件上必要なのか
代替導線があるのか

この整理がないと、あるだけの機能 が積み上がります。
逆に、残す理由が明確なら、見せ方を変える、深い階層へ寄せる、強い訴求をやめる、といった判断がしやすくなります。

複雑化を防ぐために見るべき数字

複雑さは主観だけでは判断しにくいので、数字も必要です。

初回利用から最初の成果までの時間
主要機能ごとの利用率
役割別の利用差
新規顧客の立ち上がり期間
どこにあるか分からない 系の問い合わせ件数
高度機能の継続利用率

こうした数字を見ると、単に機能数が多いのか、あるいは 理解できる構造になっていない のかが見えやすくなります。

SaaSの機能複雑化のよくある質問

Q. なぜ機能を増やすと分かりにくくなる？

A. 情報設計の硬直化、既存導線への詰め込み、命名の一貫性低下、機能間の重複、が原因。機能数そのものより、構造を維持しないまま積み上げる のが問題です。

Q. Feature Creep(機能膨張)を防ぐには？

A. 機能追加プロセス を設ける。Why(なぜ必要?)、Who(誰のため?)、Alternative(他で代替できない?)、Sunset Plan(使われなければ削除?) の4つを必ず議論します。

Q. 機能の優先度はどう決める？

A. RICE スコア(Reach × Impact × Confidence ÷ Effort)、ICE スコア(Impact、Confidence、Ease)、Kano モデル、などで定量評価。声が大きい顧客の要望に流される を防ぎます。

Q. 機能を削除する判断は？

A. 利用率 5% 未満が継続、Sunset Notice 配信 → 90日後削除、のような段階的アプローチが定番。一部のヘビーユーザーが反対しても、プロダクト全体の健全性 を優先する判断が必要。

Q. プログレッシブ・ディスクロージャーとは？

A. 必要な人に必要な機能だけ表示する 設計手法。初心者には基本機能のみ、上級者には全機能、と段階的に開示。Notion、Figma などが上手く使っています。

Q. UI が複雑化したら作り直すべき？

A. 一気に作り直すリスクは大きい。Strangler Fig パターン で 新機能だけ新 UI、既存機能を段階的にリニューアル、で進めるのが安全。3〜5年かけてのリニューアル例も多いです。

Q. AI 機能を追加するときの注意点は？

A. AI 機能を増やすほど SaaS は分かりにくくなる リスク高。既存機能の置き換え か 補助 か明確に、AI に何ができて何ができないか の期待値管理が大事。

まとめ

機能を増やすほど SaaS が分かりにくくなるのは、機能数が悪いからではありません。
本当の問題は、選択肢、例外条件、対象ユーザーの違い、導線の分断が積み重なって、理解するための負荷 が増えることです。

だから、複雑化と付き合うには、やみくもに機能を削るより先に、

目的で束ねる
全員に全部見せない
覚える順番を設計する
残す機能の理由を明確にする

という整理が効きます。

SaaS は成長すると複雑になるのが普通です。
でも、複雑であることと、分かりにくいことは同じではありません。
その差を作るのが、設計と見せ方です。

この記事と一緒に読みたい

参考リンク

Pendo: The 2019 Feature Adoption Report
Pendo Help Center: Measure overall feature adoption
Appcues: Why digital adoption fails (and what the pros do instead)
Appcues: The ultimate guide to product adoption
Appcues: What is user onboarding?