# 抽象化とUXに関する話 > プロダクト設計におけるUIとUXの重要性、抽象化の適切な設計、競争優位性の要素について考察し、最新のトレンドや生成AIの影響を踏まえた洞察を提供します。 - 公開日: 2025-04-24 - 著者: やました - タグ: UX, プロダクトマネジメント - URL: https://tech.anycloud.co.jp/articles/abstraction-and-ux --- 最近、Xで「UI ≒ 画面レイヤはもはや差別化にならない」という議論が盛り上がっていて、考えてきたことを整理したくなりました。プロダクト設計の本質って何だろう？と改めて考える良い機会かなと思います。

プロダクトの使い勝手みたいな話になるとUIの工夫をしようとする人が多いんだけど、あまりにひどいUIでない限り、使い勝手の鍵は画面じゃなくてビジネスの話だったりするんだよね。料金体系だったり、商品の単位の括り方だったり、オペレーションだったり。

— Aki (@LoveIdahoBurger) April 19, 2025
## UIがコモディティ化した理由と、その先にあるもの UIがコモディティ化した理由は、よく考えると単純なことかもしれません。 Figmaや、Tailwind、Shadcnといった「綺麗なUI」を効率的に作るためのツール群が手軽にキレイなそれっぽいUIの実現を拡散させました。その結果、ベストプラクティスがテンプレ化され、「見た目の良さ」という希少価値が前に比べて減っているように見えます。 また、BtoBでもBtoCでも、ユーザーの期待値が標準化されています。UIは今や「ハイジーン要件」、つまり壊れていなければ問題ない要素へと変わったように感じます。 > UIを「丁寧に作れば勝てる」という考えは、もはや神話と言えるかもしれません。優位性は"どの情報を、いつ、誰に、どう繋ぐか"というサービス構造へと移行したと思います。 ## UXはサービス構造のデザインである 僕が常々考えているのは、「ビジネス要件 → サービスインターフェイス → ユーザー」という三層です。 この三層を貫通する一貫した抽象構造を設計し続けること。情報設計(IA)と業務/組織オペレーションを"積極的に編集"できなければ、本当の意味でのUXとは呼べないのではないかと思います。 「UIはユーザーとの最終接点。UXは"何をサービスとして切り出すか"という抽象度で設計を主導する部分」この考えが、僕のUXに対する基本的な捉え方です。 ## SaaSを3つのレイヤーに分解してみる SaaSを分解してみると、こんな構造が見えてくるように思います。 ```plaintext ┌────────────┐ │ ①データ │ ← 顧客&外部ソースの全集合 └────────────┘ ▲ │ "②業務フロー" (ロジック/権限/自動化) ▼ ┌────────────┐ │ ③インターフェース │ UI または API └────────────┘ ``` 競争優位性は、①と②の複合資産にあると考えています。非公開スキーマや、ワークフロー知見、独自のネットワーク効果など、目に見えない部分が実は価値の源泉だと思います。 ③は顧客接点ではありますが、うまく抽象化ができていれば比較的付け替え可能な要素。だからこそ、コア資産を外に漏らさずに再利用できる抽象境界をどう設計するかが勝負だと思うんです。 ## 抽象化の適切な設計 最近考えているのは抽象化のレイヤー設計（「顧客が自力で理解し、迷わず操作できる最適な粒度」にプロダクトを切り分ける設計）。 この抽象化のレイヤー設計は、プロダクトの思想そのものであり、これを適切に行うことでユーザー体験が洗練され、後々の機能追加や事業拡張もスムーズになります。一方、この設計を誤ると、プロダクトは複雑化し、新機能の追加が困難となり、急激に負債化するリスクがあると思います。 具体例として、NotionとGoogle Driveを比較します。 - **Notion** は、*Workspace → Page → Block → Database* という階層を用い、ページを「作業空間」と位置づけています。ページの中でブロック（[Block](https://www.notion.com/ja/help/guides/block-basics-build-the-foundation-for-your-teams-pages?utm_source=chatgpt.com)）を組み合わせて、文章・データベース・タスクなどを自由に作成し、柔軟に拡張できるよう設計されています。これは「書く、考える、整理する」などの作業（ワークフロー）そのものを支えるための設計です。 - 一方、**Google Drive** は、*Folder → File* というシンプルな二層構造で、「ファイルの格納・管理」を明確にしています。このシンプルな抽象化により、ユーザーが直感的にファイルを整理・共有できるようになっています。また最近ではラベル（Label）を追加することで、階層的な整理にとどまらず、柔軟なメタデータ管理を可能にしています。 両者は具体的な機能で見ると一見同じように見えます。しかし、抽象化の方法やそれぞれが解決しようとしている課題（ワークフロー）が異なるため、目指す方向性や価値提案によって、最適な抽象化のレイヤーが変わり、たまたま同じ機能が提供されているように見えるだけ。 プロダクト設計者は、対象となるユーザーのワークフローやニーズを深く理解し、どのような粒度や構造が最も適しているのかを継続的に評価・調整していくことが重要です。 （実際、抽象化がうまくいっていないものを抽象レイヤーから設計し直し、プロダクトを作り直すのはほぼ0から作り直すのと同義ではある気がしており、そこに踏み切れる人って少ないように思います） ## 「最低限のUI」はやはり必要条件 一方で、一般的なUI品質は依然として低レベルにとどまっていることも事実です。UIは競争優位にならないとはいえ、ハイジーン要件を満たせないと体験全体を破壊してしまいます。 逆説的に言えば、「壊れていないUI」すら確保できない組織は、それ以前の段階で顧客を失うことになるでしょう。これは見落とされがちだけれど重要なポイントだと思います。 ## 生成AIについてもちょっと考察 生成AIとAPI-firstの時代は、UIフレームワークの淘汰をさらに加速させるでしょう。 競争軸は **データの質と量、ワークフロー自動化、適切な抽象化設計** の三点にほぼ収斂していくのではないかと考えています。 プロダクト戦略は「UI牙城」から「サービスOS」へと再定義する必要があるかもしれません。 ## まとめ 差別化は**UX (= 構造) の抽象度と結合度をどう最適化するか**に存在する。**UXデザイナーはそのレイヤーを"設計し続ける"行為**を専門とするのが良いかもしれない。 UXを語るなら「画面をどう作るか」ではなく「サービスをどの粒度で世の中に現すか」を問うべき。 まだ考察の途中ですが、この視点が誰かの役に立てば嬉しいです。