この記事の途中に、以下の記事の引用を含んでいます。
I Is for Intent (2024)
「イケてるUXはデータ設計から」──意外な仕掛け人は設計思想？
近年、優れたソフトウェアを開発するうえで、「なぜこの体験が直感的なのか？」という疑問にぶつかることが多くなっています。
この記事「I Is for Intent」では、表層的なUI変更や機能追加の背後で、実は“意図（Intent）”主導のデータモデル設計という、開発上の本質的なトピックが語られています。
記事の筆者は独自開発のCADアプリの設計思想を例に挙げつつ、現代ソフトウェアに潜む構造上の問題、その根源的な解決法を提示します。
特に「データの姿勢」と「ソフトウェアの柔軟性」の密接な関係にフォーカスし、実体験に基づいた重厚な議論が展開されています。
データモデル×意図設計、現場でのリアルな主張
記事では、筆者が触れた独自CADの開発哲学をこう述べています。
“The (private) CAD app I showed glimpses of above is entirely built this way. It’s patch all the way down and it’s had undo/redo from day 1. …When the in-house designers come to me with new UX requests… It’s ‘sure, and we can do more.'”
この一節が示唆するのは、データモデルが「patch all the way down（パッチ＝変更内容の積み重ねが基本）」という構造のもとに設計されている点です。
これにより、“最初から誰もがundo/redo――取り消し/やり直し”が自由自在に機能する。
しかも、新たなUX改善の要請に対しても「ほぼ即答で『できますよ』と言える」設計思想がコアとなっています。
さらに、著者は以下のような現場の認識ギャップについても鋭く指摘します。
“If you’re not actively aware the design of schemas and code is tightly coupled, your codebase will explode, and the bulk of it will be glue. …Much of it just serves to translate generalized intent into concrete state or commands.”
この部分は、単なる「データスキーマ」の設計が、実は「コードの書きぶり」「運用コスト」「将来の技術的負債」まで、本質的に連動していることを暗示しています。
現代ソフトウェアにありがちな“膨大な接着剤コード”が量産されてしまう最大の理由も、実はデータ構造とビジネスロジック/意図とのズレに根ざしているという主張です。
なぜ「パッチ型」設計思想は重要なのか？
手戻り・変更・多様化の時代に最適解
この主張の背景には、今日のシステム開発における柔軟性要求の高まりがあると考えられます。
現代の開発現場では、「リリース後に仕様変更」「ユーザー要求への細かな対応」「失敗からの回復（undo/redo）」が日常茶飯事です。
従来型の“CRUD（Create/Read/Update/Delete）ベース”一辺倒のデータ設計だと、思わぬ手戻りや改修コストが積みあがりやすい。
一方、「patch all the way down」、つまりすべての変更を“パッチ（差分記録）”として積み重ねるアプローチだと、変更の履歴管理やロールバックが自然に実現できます。
実世界で利用されているGitや、Google Docsの変更履歴と同じ発想です。
筆者が言う
“In an interactive UI, you also need a reverse path, to apply edits. What I hope you are starting to realize is that this is really just the forward path in reverse, on so many levels. …I want is to query and mutate the same damn store you do, and be told when what changes. It’s table-stakes now.”
この“双方向性（forward path ↔ reverse path）”を意識した設計の重要さも、現代のユーザー体験改善・トレーサビリティ強化・多人数コラボレーション対応を考えると納得できるところです。
フロントエンド開発者の苦労を減らす本質とは
記事では、「プリアセンブルされたデータはむしろ迷惑」という以下の発言もあります。
“If you pre-assemble the associated record data for me, you actually make my job as a front-end dev harder, because there are multiple forward paths for the exact same data, in subtly different forms.”
これは、多様な活用文脈に応じて“意図が違うアクセスパターン”が発生するため、一律に用意されたデータでは柔軟なUI体験を阻害してしまうという経験的な知見です。
たとえば、ECサイトで「商品をリストで見る」場合と「1商品を詳細に編集する」場合、必要なデータ粒度は当然異なります。
この両立を安易な“便利API”や“事前まとめデータ”で済ませようとすると、どこかで必ず柔軟性かパフォーマンスを犠牲にすることになります。
だからこそ、「意図（Intent）」に応じて同じストア（データの倉庫）を自在にクエリ・変更でき、その変化をシステム側が適切に通知できる設計が“現代的なデータ設計の必須要素（table-stakes）”になっているのです。
「意図主導」はソフトウェア設計の新しい標準となるか？
従来の「モデル＝DB構造」の落とし穴
現時点で多くの日本企業で導入されている「モデル＝DBテーブルの状態の写しをUIで編集する」という設計は、とにかく“状態の一貫性”と“権限管理”が重視されがちです。
しかし筆者はこれについて
“The fact that the data store should not be corruptible, and should enforce permissions and quotas, is incorrectly extended to the entire model stored inside. But that model doesn’t belong to Stanley, it belongs to the user.”
と警鐘を鳴らしています。
ここでいうStanleyとは、“IT部門・インフラ担当者の都合でシステムが設計されすぎる”状態への揶揄でもあります。
「データのガチガチな制約やエクスポート機能の不自由化」ではなく、“ファイル保存＝ユーザーの作業意図の丸ごと保存”であった昔のデスクトップアプリの思想が、本来ユーザー体験の本質であった、と指摘しています。
SaaS以降の時代にこそ見直すべき思想
この主張には現代のクラウドSaaSの罠も透けて見えます。
実際、多くのWeb連携サービスや他社製アプリケーションに対し、「エクスポート機能が不十分」「自分のデータがちゃんと取り出せない」「バージョン管理が面倒」などの不満がある方も多いと思います。
私自身の現場経験でも、“ユーザーにとって本当に保存したいもの＝その人の作業意図や変遷履歴そのもの”であり、単なる記録や管理情報よりも、履歴・差分・操作パターンなどの情報こそが価値になる場面が急増しています。
「意図（Intent）」時代のデータモデル──この発想が未来を切り開く
上記のような議論から、私は「主役は“意図”＝何をしたくて今こうなったか」をきめ細かく記録・復元・応答できるデータモデルと、それに裏打ちされた設計思想に本質があると考えます。
具体例：現代API設計、エディター、バージョン管理……
-
APIの設計
従来：RESTfulなCRUDで足りると思いきや、実際は「こういう理由でAからBに移った」という“Intent Patch”の管理が必須となる。
たとえばGoogle DocsやNotionの「変更履歴」や「共同編集」は、まさにIntent Patchによるリアルタイム追跡が根幹です。 -
エディター系アプリ
古典的なWordやExcelは「保存」＝その時点のファイル全体を書き出す世界観です。
一方、FigmaやMiroなど現代的なWeb系エディターは、「変更パッチ」を連続的に保存し、Undo/Redoや共同編集に柔軟に対応しています。 -
バージョン管理
ソフトウェア開発の現場ではGitの「diff/patch」型設計がもはや標準。
意図と差分に基づいたコミット管理が、最も柔軟で透明な運用を実現しています。
“ユーザーの意図”を中心に据えることの示唆とは？
真にユーザー体験を進化させる開発の根本
「I Is for Intent」が教えてくれる最大のポイントは、“意図の記録と実現”という視点でシステム設計を見直すことが、単なる技術論を超えてユーザー体験の進化や競争力の源泉となる、ということでしょう。
たとえば、
– 「データ整合性」や「権限管理」ばかりにこだわると、ユーザーの柔軟な作業や情報持ち出しがしにくくなる
– しかし「意図」の差分をベースに管理・保存・復元できれば、Undo/Redoやコラボレーション、さらには独自のデータ活用まで、劇的に自由度が上がる
現場の開発者にとっても、「設計の本質は“意図の流れ”をいかに記述・伝播・再構成できるか」にある、と言えます。
これから意識すべき設計思考
- データストアは汚してはいけないもの、という“システム都合主導”からの脱却
- UI/UX要求に耐えうる“意図Magnet”なデータモデルの設計
- 履歴・差分・Intent Patchを前提としたAPI/データ通信設計の重要性
- そして、「Load/Save＝意図そのものの保存・再現」という、昔ながらのデスクトップ設計の良さの再評価
この流れを押さえておくことで、より少ない「接着剤コード」で、最大の柔軟性・進化速度を持つシステムを作ることができるでしょう。
結論：「意図」ベースの設計思想が開発・体験を革新する
現代ソフトウェア設計が抱える“膨大なコード爆発”や“本質ニーズとのミスマッチ”は、突き詰めると「意図」をどう扱うかに行き着きます。
本記事の提言は、“状態”ではなく“意図の流れ”をデータモデル・API・システム全体で管理する設計思想こそが、今後のアプリケーションの柔軟性、ユーザー体験、さらには将来的な拡張性を支えるカギである、という点にあります。
もはや「単なる状態保存」や「データの一貫性」だけでは乗り越えられない時代。
今こそ「Intent is King（意図が全て）」という新たな観点からプロダクト設計を見直してみてはいかがでしょうか。
categories:[technology]
コメント