しかも、この問題は見た目だけに留まりません。ずれたASCIIアートをもとにデザイン生成ツールへ渡すと、出てくるデザインもずれます。入力が曖昧なら、出力も曖昧になる。ASCIIアートは人間にとって多少見やすいですが、レイアウトを正確に伝える手段ではありません。

この不満をきっかけに、ワイヤーフレームをJSONで定義して、ブラウザでプレビューできる Claude Skill を作ってみました。

ワイヤーフレーム向けJSONファイル

JSONは構造化されたテキストフォーマットで、AI との相性が良いだけでなく、ツールやワークフローに縛られることなく自由に扱うことができます。JSON にはレイアウトの方向（縦か横か）、サイズ（固定か可変か）、間隔、階層が定義されています。例えば、サイドバー付きのダッシュボードなら、ヘッダーとメインコンテンツを縦に配置し、 メインコンテンツの中にサイドバーとメインを横に配置する。こうした構造が direction、width、grow といったプロパティで明示されるので、人でも機械でも解釈がズレません。

Skill には JSON 化したワイヤーフレームデータだけでなく、HTMLプレビューもあります。ドラッグ&ドロップで要素の並べ替えができ、変更はサイドパネルのJSONにリアルタイムで反映されます。JSONをコピーしてエディタで直接編集することもできますし、ファイルとして保存して別のツールに渡すこともできます。

つまり、ザックリとワイヤーフレームを作ったあとに、順番の微調整ができるようにしています。

だいぶ優秀になってきたAIデザインツールですが、細かくプロンプトで指示するのは非常に手間ですし、ちょっとした情報構成の指示を始めると延々と会話と続けることになってしまいます。JSON のメリットはプロンプトとしてそのまま使えるという点です。例えば、Figma Make のようなデザイン生成ツールに、ワイヤーフレームのJSONをそのままコピー＆ペーストで渡すと、情報構成を守ったデザインを生成してくれます。自然言語で「左にサイドバー、右にメインコンテンツ、上にヘッダー」と伝えるよりも、JSONで構造を渡したほうが正確です。構造が明示されているので、ツール側が解釈を間違えにくいのだと思います。

シンプルに「カフェサイトのワイヤーフレームを作って」と頼むのも良し。ブレストしたあとに「ワイヤーフレーム生成して」と頼むのも良し。AIにレイアウト設計の判断を Decision DNA として伝えてあるので、ニュアンスも汲み取ってワイヤーフレーム案を出力してくれます。もし少し間違っていたとしても、出力した HTML をドラッグ＆ドロップで微調整するだけです。

AIにルールではなく視点を渡す Decision DNA

デザインにあるルールやパターンマッチでもない、視点をもたせた AI ワークフローがあります。

Yasuhisa HasegawaYasuhisa Hasegawa

困ったら作って解決できる時代

テキストフォーマットであることは、特定のAIモデルに依存しないことも意味します。Claudeで作ったワイヤーフレームを、別のモデルやツールにそのまま持っていけます。私は Claude Code でこのスキルを活用していますが、Claude Desktop 版でも使えますし、SKILL.md フォーマットは他のツールでもサポートが進んでいます。 ちょっとした機能をパッケージ化して配布できる点も、Skill の魅力です。

この Skill は週末にふと思いついて数日で作ったものですが、小さな不満から始めたことが、思った以上の広がりにつながります。AIを使っていて、出力の形式やワークフローに違和感があるなら、試しに手を動かしてみてもいいかもしれません。最初から全体像が見えている必要はないと思います。目の前の不満をひとつ解消するだけで、想定していなかった使い道が後から見つかることがあります。

ワイヤーフレームスキルは GitHub で公開しているので、興味ある方はぜひ試してみてください。

GitHub - yhassy/wireframe-skill: A Claude Code skill that generates wireframes from natural language descriptions

A Claude Code skill that generates wireframes from natural language descriptions - yhassy/wireframe-skill

GitHubyhassy

デザインの判断は「ここを抑えていたらいかなる場合でも正解」とは言い切れず、文脈で変わります。同じECサイトでもターゲットが違えば必要な情報量が変わりますし、ある施策では正解だったデザインが、別の状況では通用しないことも珍しくありません。

文脈で正解が変わるという現実

デザインだけでなくヒューリスティック評価にも同様のことが言えます。専門家が同じ画面を見ても、見つける問題が一致する割合はわずか 27% と言われています。調査によって数値は前後しますが、誰もが同じように評価できるわけではないことが分かります。知識や経験が違うだけでなく、対象のデザインの目的やユーザーの文脈をどれだけ理解しているかどうかで、評価そのものが変わります。

How Large Is the Evaluator Effect in Usability Testing? – MeasuringU

MeasuringU LogoJeff Sauro, PhD

今のAIプロンプトの多くは「どこが正解でどこが間違いか」を明確に定義し、間違わない方向へ誘導する作り方です。しかし、デザインのように視点によって正解がグラデーションのように変わる領域では、そのアプローチだけでは足りません。評価者がどんな視点でものごとを捉え、それがどう結果に結びついているのかを理解しなければ、チェックリストをなぞるだけの表面的な出力になってしまいます。

ルールからパターンへ、パターンから視点へ

デザインを始めた頃のことを思い出すと、最初は四大原則 、余白、コントラスト比といったルールに沿って作っていたはずです。ルール通りにアプローチするのは、生物の知性の進化に捉えると、初期段階に近いです。光が来たら近づく、危険だったら逃げる。シンプルで確実ですが、想定外の状況には対応できません。

デザイナーとして経験を積み重ねると、パターンを覚え始めます。このレイアウトはこういう場面に向いている、このUIパターンはこのユーザー層に効く。うまくいった行動を繰り返し、失敗を避けながら少しずつ賢くなっていく。生物の進化でいえば強化学習の段階です。

ただ、デザイナーには一段先の成長があります。文脈を理解し、判断を微調整する力。作る前から「このユーザーがこの画面を見たら、おそらくこう感じるだろう」と頭の中でシミュレーションできる能力です。これはルールでもなく、パターンマッチでもない。視点を持っているということを意味します。

この視点を、AIにもインストールできるのではないか。そう考えて作ったのが Decision DNA です。 Decision DNAは4つの要素で構成されています。

• 文脈 : 誰のための判断なのかを定義する要素です。評価する前に「誰にとっての正解を探すのか」を明確にしなければ、出力はどうしても一般論になります。
• 認知 :デザインの問題をどう分解するかをインストールする要素。同じ画面でも何を塊として捉え、何を分けて捉えるかで問題の見え方が変わります。
• 較正 :見つけた問題の重さを文脈で調整する要素。同じ問題でも、誰にとっての問題かで深刻度が変わる。この重み付けを状況に応じて調整できる力をもたせます。
• 明文化 :AIがどういう判断で、どのようにしてその出力に至ったのかを記録するようにします。この記録を基に Decision DNAを改善を繰り返していきます。

ヒューリスティック評価で試してみた

この Decision DNA を組み込んだヒューリスティック評価のワークフローを実際に運用し始めています。全体を指示するディレクターが、評価対象のサイトに対して注意すべき点を整理し、それぞれ異なる視点を持たせた5人の評価者にタスクをアサインします。同じことを繰り返すのではなく、異なる視点を持った評価者がそれぞれ独立して評価し、その結果をもとにディレクターがレポートを整理します。

レポートも評価者が指摘した要素の多数決ではなく、与えられた課題や文脈に応じて評価を微調整した上で最終レポートを出す仕組みにしています。こうした考慮もただチェックリストだけでは難しいアプローチです。

評価が終わった後には、個々の評価者がどのような視点で、どういう順番でものごとを捉えて出力したのかをチェックしています。その傾向から見えてきた改善点を次のワークフローに還元する。明文化の仕組みがあらかじめ作られているからこそ、ワークフロー自体を少しずつ改善しています。

Decision DNAなしで「ヒューリスティック評価をしてください」と頼んだ出力は、「認知負荷がかかる」といった無難な文章を出力してしまいます。誰にとって、どんな状況で認知負荷がかかるのかがわからない。一方、Decision DNAを組み込んだ評価では「複数のタブで比較購買を行うユーザーは、計算を各商品ページで繰り返す必要がある」というように、文脈を考慮した具体的な指摘が出てきます。

また、評価の重み付けにも差が出てきます。シンプルなプロンプトでは「今すぐ買う」ボタンの誤操作リスクを一律に「中」と評価しますが、Decision DNAでは「有料会員は配送パターンに慣れているため影響は軽減される」という文脈を考慮した上で重要度を判断します。誰にとっての問題かが明示されるため、対応の優先順位がつけやすくなっています。

発見数も6件と18件で3倍の差があります（Decision DNA 版はアクセシビリティレポート付）。ただ多ければ良いわけではなく、各問題に信頼度、一致度、判断根拠のログが残っていることが重要な点です。これにより「なぜこの評価になったのか」が追跡可能になり、次の評価で視点そのものを改善できるようになっています。

最初の一行を書いてみる

次にデザインを作ったとき、なぜそれを選んだのか——一文でもいいので書き出してみてください。2つか3つ案を出してその中から選んだ理由は、おそらくルールや原則だけでは説明できないはずです。状況の制約かもしれませんし、ユーザーの文脈かもしれません。重み付けの違いかもしれません。

その一行が、自分だけの Decision DNA を作っていく最初の一歩になるはずです。

ここ数年で、Design Tokens を用いてデザインと開発の同期を図る組織が増えています。生成AIと組み合わせることで、意味付けされたセマンティックトークンによる効率化が期待されるケースも少なくありません。Token の仕組み作りはボトムアップでできるのでハードルが高くありませんが、プロダクト開発と連携したガバナンスは一筋縄にはいきません。

プロダクト開発の要望や優先順位を踏まえて、デザインシステムとどう同期させるかは Design Tokens に特有の課題ではありません。 デザインファイルの UI ライブラリのような単純なものから、Storybook を使った開発連携まで対象が変わっても、「誰が決めて、どう反映するか」という問題は変わりません。

Design Tokens によるメリットはあるものの、それだけで従来からあったガバナンスの課題は解消されません。

プロダクトチームはプロダクトの KPI や OKRで評価されます。クロスプロダクトの一貫性で評価されることはありませんし、効果が期待できるなら、ガイドラインにないパターンが使いたくなる場合もあります。デザインシステムの採用にも追加や調整の手間がかかるため、機能のリリースを優先して対応することはありません。

何かを始めるなら、まずはボトムアップで着手する方が早く進みます。 自分たちの担当範囲であるUIライブラリや実装フレームワークに手を入れると、作業を速く進められます。 デザインシステムの初期段階であれば、採用コンポーネント数のような指標が有効です。しかし、それをデザインチーム唯一のKPIとして続けていると、プロダクト側とのインセンティブや優先順位にズレが生じます。その結果、コンポーネントの採用が進まなくなったり、運用が複雑化したりします。

運用モデルが有効と言われているのは「Federated Model」と呼ばれる、 プロダクトを担当するデザイナーと開発者が、デザインシステムチームに派遣されて連携しながら運用していくというものです。プロダクトチームの状況が見えやすくなることで、どのコンポーネントを追加・改善すればよいかの判断もしやすくなります。

ただ、Federated Modelは回避策に過ぎず、根本的な解決にはなりません。デザインシステムチームがプロダクトチームの文脈を理解する機会にはなりますが、その先の対応が不明確です。もしデザインシステムチームが引き続き「一貫したUIを維持する仕組み」を最重要視するなら、プロダクトチームが求める「ユーザーの成果をどう支援するか」とは乖離します。

AI を使った Design Tokens 活用でも、「何を使うか」は指示だけでは十分ではありません。「なぜこの選択がこの文脈に合うか」まで調整が必要ですし、その明文化のためにはガバナンスが不可欠になります。AI には大きな可能性を秘めているとはいえ、解決すべき課題は今までと大きく変わりません。

デザインシステムのガバナンスの目的が、「トークンの使い方をドキュメント化（もしくはAIが理解できるように）して一貫性を保ちやすくすれば、チームはより速くリリースできる」 という仮定に基づていることがあります。開発効率化や一貫性は重要とはいえ、ボトルネックがこれらが不明確なら、どれだけトークンガバナンスを整えても解決しません。ドキュメントの整った、しかし依然として速くリリースできないコンポーネントができるだけです。

長年デザインシステムのガバナンスが答えようとしている「デザインシステムとプロダクトニーズが対立するとき、誰が判断するのか」という問いは、ほとんどの組織で答えをもっていません。「良い感じに、議論しながら決める」といったルールでは、判断の一貫性が失われ、次第にプロダクトとデザインシステムの差が広がっていきます。

例外があるとしたら「デザインシステムがプロダクトそのもの」である場合。Shopify、Airtable、Softr、Kintone のようなプラットフォーム企業は、デザインシステムがプロダクト開発だけでなくユーザーも扱う大事な道具になるので、プロダクト戦略とデザインシステム戦略がアラインしやすいです。言い方を変えるなら、デザインシステムそのものが売り上げに直結しています。

#372 AIもデザインシステムも銀の弾丸ではない（sakitoさん）

http://yhassy.heteml.net/mp3/automagic372.mp3

Yasuhisa HasegawaYasuhisa Hasegawa

多くの組織でデザインシステムがプロダクトそのものではない場合、問いは「プロダクト開発のボトルネックが本当に実装レイヤーにあるのか？」に移ります。 現場の効率化が進んでも、開発工程全体の観点で見たときに、 「コンポーネント採用数」で成果を示す。デザインシステム評価として、これは分かりやすい指標です。ただ、デザインステムが成長期に差し掛かっているにもかかわらず、自分たの効率化だけを物差しにし続けると、問いはいつも「もっとってもらうには？」に戻ってきます。使ってもらうための座組や、複雑な判断ツリーを作るといった活動を何年も続いているのではないでしょうか。

デザインシステムに過度な期待をしないほうがいいと言われて久しいです。ただ、Design Tokens や AI への注目が高まったことで、期待は形を変えて再び膨らみ始めているように見えます。技術や手段は新しくなっても、「仕組み化すればうまくいく」という前提は変わっていません。これは以前から繰り返されてきたトラップと同じ構造です。手段ではなく、前提そのもの疑うところから始める必要があるのではないでしょうか。

組織の文脈を置き去りにしたデザインシステムの罠

デザインシステムの成功は手段の選択に大きく左右されるわけではなく、実際には計画の不備が失敗の原因となることが多いです。

Yasuhisa HasegawaYasuhisa Hasegawa

探索ツールから始めてみる

先述したように、Design Tokens によるメリットはありますし、様々な可能性を示しています。最終ゴールは、プロダクションインフラとして位置づけですが、そこへいきなり突き進もうとするとプロダクトチームとの連携で悩み始め、使えるモノができる前に仕組み化の議論が増えてしまうことがあります。

最近、試し始めているのが Design Tokens をつかったプロトタイプ制作です。今でもバイブコーディングでプロトタイプを作っている方はいますが、 Design Tokens を活用することで、早期に「自社プロダクトっぽい見た目」のプロトタイプでアイデア発散ができます。詳細なところまで Design Tokens を定義していなくても、Semantic Tokens がある程度揃ってさえすれば『らしい』デザインを出力することができます。きちんと Design Tokens が作られることを待つことなく、現場で検証できるのも魅力です。

ここで重要なのは、ただ Design Tokens を使うだけでなく、判断の記録を残すことです。コンポーネントをはじめ、色の使い方、スペース、配置など、どのように出力したかログを残しています。どういう文脈（企画案）で、どんなコンポーネントが必要になるのか。間違えやすいデザインの判断ポイントはどこかも見えてきます。記録情報が プロダクションインフラとして Design Tokens を活用する際の貴重な資産になります。

Design Tokens の可能性は、制作効率化だけにとどまらない思います。トークンという共通の基盤があることで、制作・実装だけでなくプロダクトチーム全体が貢献しやすくなります。

また、仕組みの作り方にも見直す余地が生まれます。インタビューや会議で「こうしてほしい」と言れたことをもとに設計するのではなく、実際にどう使われてるかという行動から積み上げていく。言葉ではなく行動を起にすることで、長年の課題だったアライメントに少しずつ近けるのではないかと思います。

「試したけど、使えなかった」

プロンプトを書いて、出てきたものを見て、「これじゃない」アウトプットが生成される。何度か試して、結局 Figma でデザインを始める。「それっぽい UI」が出来ても、ちょっとした調整に疲れていつしか触らなくなったという経験は私だけではないはず。

想像していたデザインが生成できなかったからといって諦めるのはもったいないです。 デザインプロセスは混沌としています。最初に計画したものをそのまま作り上げるのではなく、見たものに応じて少しずつ調整していく過程です。 つまり、混沌としたプロセスをすべてAIに任せるのではなく、その中から一部を抜き出して作るというアプローチを取ることで、様々な可能性が見えてきます。

先に言語化を求めるAIツール

デザイナーがAIをまったく使っていないわけではありません。

ISCA TOKYOの調査によると、アイデア出しやブレストにAIを活用しているデザイナーは67.9%に達しています。一方で、Figma AI Report 2025では、UIレイアウトの探索にAIを使っているのは21%程度に留まっています。

「使っていない」のではなく「ブレストで止まっている」のが実態です。アイデア出し、テキストやダミー画像出力では活用できているのに、実際のデザインプロセスに組み込むところに壁があるようです。

新規案件や探索向けのアイデア向けであれば精度が随分上がりましたが、様々な制約を考慮したうえでの「意図通りのデザインアウトプット」は、現時点では少し早いかもしれません。

デザインは「作りながら考える」プロセスです。手を動かしながら「こっちのほうがいいかも」という発見が生まれます。ところが、現在のAIツールは「先に言語化」を要求します。作る前に、作りたいものを言葉で説明しなければならない。このミスマッチが、壁を作っている一因ではないかと思います。

ただ、だからといってこれらの AI に触れる価値がないわけではありません。期待の置き方を変えると、見えてくるものがあります。

デザインツールによる『縛り』

デザインツールで作業していても、「こっちのほうがいい」という新しい発見は、ツールがもつ機能の中に閉じこもることがあります。

レスポンシブwebデザインが当たり前になった時期にデザイナーが「可変するデザイン」を作るのに苦労していた時期がありました。当時は Figma や Sketch のような選択肢がなく、Photoshop を使っていました。しかし Photoshop ではレスポンシブ対応を試みても、ツール上で可変状態を表現する機能がありませんでした。デザイナーの能力や可能性がツールによって制限されてしまったひとつの例です。

それと似たようなことが今起こっていると思います。素材に触れながら、試しながら、「これだ」という感覚にたどり着く。その探索のプロセス自体は、Figmaの外でも実現できるようになってきました。

昔から「デザイナーはコードを学ぶべきだ／知るべきだ」という論調があります。今でも1, 2年に一度はSNSなどでその議論が持ち上がります。「Design in Browser（ブラウザ上でデザインする）」という考え方もあり、デザイナーは制作物の素材を理解した上で設計すべきだという主張が込められています。

一昔前であれば、コードを知ろうとするだけでも難しかったです。また、簡単なものを作るにしても、実装環境を整えるのが大変でしたし、そこから模索するための無難なインターフェースもありませんでした。コードも書けるデザインエンジニアだけが、コードに触れながらデザインするという状況が生まれたと思います。

そうした背景から、デザイナーはデザインツールに閉じこもり、そのツールで可能な表現だけを考えるようになったのではないでしょうか。そのことが、デザインと実装の連携をより複雑にしたとも感じます。Figmaではこう見えるが実装ではできない、あるいは実装ではこうだがFigmaではその見た目を継承できない、といったギャップと戦ってきた人もいると思います。

トランジションのイージング。インタラクションのタイミング。ホバー時の挙動、スクロールに連動したアニメーション、マイクロインタラクションの細部。本当は「こうしたい」というのがあっても実現できなったデザイナーもいると思います。それらは、コードが書ける人たちの『特権』となってしまったところがあります。

コードと接点をもちながらデザインすることの最大のメリットは素材に直接触れてデザインできることです。先述したようにデザインは「作りながら考える」プロセスです。実装された状態で見たり触ってはじめて気付くことがたくさんありますし、そこから新しいアイデアが生まれることがあります。

Webflow や STUDIO のようなノーコードツールでデザインしている人も似たような感覚があると思います。実装済みのページを実際に触りながら、「こうしたらどうか」「ああでもない」と試行錯誤して詰めていく感覚は、デザインツールではなかなか得られません。

素材に触れながら作ってみる

AI やノーコードツールは「コードを知るべき、書けるべき」といった議論から解放され、自分で素材を使ったデザインできる良い手段です。AIも「画面全部を作ってもらう」ではなく、「素材に触れながら模索するスケッチブック」のように扱うと、可能性が広がります。

例えば、コンポーネントのちょっとした動きでも、コンマ単位でどんな挙動をするのかをチェックしながら試したいときがあると思います。そこで私は、パラメータ付きのUIコンポーネントを実装し、実際に触りながらどれくらいの数値が適切かを考えられるツールを作りました。

従来であれば、こうしたツールを作るのは非常に面倒でしたし、エンジニアにわざわざ作ってもらうのは負担だと感じる人も多かったと思います。しかし、今ではデザイナー1人で30分ほどで作れてしまうようになりました。

こうしたツールが作れると分かれば、「このコンポーネントでマイクロインタラクションをどう作ればよいか」「触ったときの感触はどうか」といったことを自分で模索できるようになります。また、セオリーだけに頼るのではなく、自分の感覚を研ぎ澄ます機会にもなります。

AIを、自分の仕事の成果物を代わりに作ってもらうツールと考えるのではなく、自分の仕事の幅を広げるための道具として捉えてみるとどうでしょうか。自分だけの道具（スケッチブック）。素材に直接触れることでアイデアが広がりそうなコトは何でしょうか。最初は時間がかかると思いますが、きっと自分だけの道具が作れるはずです。ぜひ試してみてください。

心理的安全性（psychological safety）は、ハーバード・ビジネススクール Amy Edmondson 教授が1999年に提唱した概念です。彼女はこれを「チームメンバーが対人関係のリスクを取っても安全だと共有された信念」と定義しています（Edmondson, 1999）。アイデアを共有したり、質問をしたり、ミスを認めたりすることが、罰や恥辱を恐れずにできる状態を指します。

この概念が広く知られるようになったのは、Googleが2012年に実施した「Project Aristotle」です。生産性が高いチームには心理的安全性が最も重要な要因であることを示しました（Google re:Work）。Edmondsonの研究でも挙げられている心理的安全性の条件は、リーダーシップやチームマネージメント文脈でも語られています。

• 「どう思いますか？」「他に考えはありますか？」と積極的に尋ねる
• 批判や懸念に対して、感謝を示し建設的に応答する
• 「私にもわからない」「間違っているかもしれない」と認める

心理的安全性を作るためには、誰に対しても、どこでも、気兼ねなく発言できることが推奨されいます。しかし、状況や相手を問わず、いつでも率直に発言することが、本当に安全な場と言えるのでしょうか。 特に関係性を重視する人にとっては、不安を煽るだけです。

関係性を重視する人 は、相手との関係性、状況、文脈に応じてコミュニケーションを適切に調整することで安全なコミュニケーションの場を育んでいます。誰が相手なのか、どのような場なのか、何が問われているのかといった要素を無視して一律に率直に発言することは、不適切であり、むしろ関係を損なう行為と捉えます。状況を読んで適切に振る舞えるという信頼が、発言の正当性を支えることもあります。

チームコミュニケーションにおいて「場の空気を読む」ことが 否定的に語られることがあります。「気兼ねなく発言するべきなのに、空気を読んでは意味がない」と言われるものの、関係性を重視する人にとって、文脈を読むことが安全を作り出す行為ですから、空気を読むことが必然的です。心理的安全性を作るために推奨される行動は、ある特定のコミュニケーション文化において安全を作り出しますが、それを普遍的な手法として適用しようとすると、別のコミュニケーション文化では逆に安全ではなくなります。

「チームの心理的安全性をどう育むか」を考える前に、まず「自分たちが安全だと感じるのはどんなときか」を問い直す必要があります。ある一つのコミュニケーション様式を普遍的とみなすことが、かえって安全を損ないます。日本のチームで安心してコミュニケーションできる環境とは、どのようなものでしょうか？

多くの場合、美術館に行くこと、たくさんの本を読むこと、様々なアプリやwebサイトを触ってみることを指します。こうした体験を積むことは確かに大切で、感覚を養う上で重要です。

ただ、それだけで本当に成長へつながるのでしょうか 。美術館で見た展示デザインを写真に撮っても、実際の仕事では使わない。参考になりそうな素敵なUIを保存しても、自分のプロジェクトに活かせない。こうした経験は、多くのデザイナーが持っているはずです。

ここで言う「好奇心」は様々な作品に触れるだけでなく、もうひとつの意味があると思います。今自分が目にしているアプリやwebサイトが、どのような文脈や制約に基づいて作られているのかを考えることです。

たとえその考えが間違っていたとしても、「なぜこのような見た目になっているのか」「どのような状況がこの見た目を生み出しているのか」と想像を巡らせることが大切です。そうすることで、見た目だけでは分かりにくい制約や事業の状況、またユーザーのことが見えてくることがあります。

なぜこの機能は目立つ位置にあるのか。なぜこのフローは3ステップではなく5ステップなのか。なぜこのボタンを目立たせているのか。こうした「なぜ」を問い続けることで、見た目の背後にある意思決定の構造が見えてきます。

収集と文脈理解、両方があって初めて好奇心は仕事に活きてきます。
最近見たデザインは、どのような文脈から生まれたと思いますか？

しかし、現場ではどうでしょうか。リリース前には長時間の議論があり、複数のレビューと検証を重ね、慎重に意思決定を進めます。振り返りでは「〇〇の考慮が足りなかった」「もっと早く相談すべきだった」という反省が出るものの、かえって慎重になることもあります。

「失敗から学ぶ」は素晴らしいメッセージですが、実際は「学ぶ」というより失敗を「避ける」ことに注力していることがあります。

失敗から何を学ぼうとしているのか

Harvard Business Reviewで、組織行動学者の Amy C. Edmondsonは「ほとんどの経営者は失敗から学ぶことは簡単だと考えているが、この信念は誤りだ」と指摘しています。失敗から学ぶには、失敗の種類を理解し、文脈に応じた対策が必要だと述べています。

Strategies for Learning from Failure

Reprint: R1104B Many executives believe that all failure is bad (although it usually provides lessons) and that learning from it is pretty straightforward. The author, a professor at Harvard Business School, thinks both beliefs are misguided. In organizational life, she says, some failures are inevitable and some are even good. And successful learning from failure is not simple: It requires context-specific strategies. But first leaders must understand how the blame game gets in the way and work to create an organizational culture in which employees feel safe admitting or reporting on failure. Failures fall into three categories: preventable ones in predictable operations, which usually involve deviations from spec; unavoidable ones in complex systems, which may arise from unique combinations of needs, people, and problems; and intelligent ones at the frontier, where “good” failures occur quickly and on a small scale, providing the most valuable information. Strong leadership can build a learning culture—one in which failures large and small are consistently reported and deeply analyzed, and opportunities to experiment are proactively sought. Executives commonly and understandably worry that taking a sympathetic stance toward failure will create an “anything goes” work environment. They should instead recognize that failure is inevitable in today’s complex work organizations.

Harvard Business ReviewAmy C. Edmondson

先述した Snap と NVIDIA の例も、美談に聞こえますが事情は少し複雑です。Snap のアプローチは、準備や知識が不十分なままプレゼンを行わせるため、デザイナーに負担がかかります。また、アイデアから学ぶ機会が提供されているかどうかも不明確です。NVIDIAの会議では「ジェンスンの設問」と呼ばれる厳しい質問攻めに遭うこともあるそうです。事業への誠実な姿勢が、失敗を避ける姿勢を生み出してしまう可能性があります。

そもそも「失敗から学ぶ」という言葉の解釈は、人によって異なります。ある人にとっては、同じ失敗を繰り返さないことが学習です。Snap や NVIDIA の例は、従業員にとっての「失敗から学ぶ」はこれに近くなると思います。一方で、別の人にとっては、うまくいかなかった状態がなぜ起きたのかを理解することが「失敗から学む」かもしれません。

つまり、失敗を防ぐための「予防」と、失敗を引き起こす「仕組みの理解」では、学習に対する姿勢やアプローチが大きく異なります。どちらも正しい考え方ですが、チームメンバーがそれぞれ異なる解釈を持っていると、貴重な学習機会を逃す恐れがあります。

失敗の原因を探る際に、「何が悪かったか」を考えるのは避けるべきです。このような問いは、次第に「誰が関わったのか」という責任追及に発展し、チームメンバーが積極的に行動できなくなります。「〇〇の考慮が足りなかった」「もっと早く相談すべきだった」という結論は、誰も傷つきませんが、具体策がないまま慎重な姿勢が強まるだけです。だからといって「意思決定などプロセス問題がある」といった既存のやり方への指摘は、言いにくいものですし、具体性が欠けています。

KPTのようなふりかえりでも、同じようなパターンが見られることがあります。Problem（何が悪かったか）を列挙し、Try（次に試すこと）を設定する。多くの場合、Tryは「事前に○○する」という予防策になりがちです。もっとテストする、もっとレビューする、もっと早く相談する。これらは間違いではありません。ただ、ふりかえりの時間のほとんどが予防策の議論に使われ、「仮説との違いはどこから生まれたのか」を振り返る時間がないことがあります。

もっと慎重にするための振り返りが続くと、プロセスは重くなり、失敗への恐れが増していきます。次の失敗が起きたときも「もっと慎重にすべきだった」と考え、同じループが繰り返されます。失敗から学ぶことはある程度できていますが、「失敗を恐れるな」という考えからは徐々に離れていきます。

振り返りのリフレーミング

経営者やリーダーが「失敗から学ぼう」と言うときの意図は何でしょうか。恐らく、リスクを取ることを推奨し、イノベーションへの投資を促そうとしているのではないでしょうか。失敗を恐れずに挑戦してほしい、という期待です。

一方、実務での「学習」は、同じ失敗を避ける仕組みを作ることや、問題の特定と修正、より慎重なプロセスの導入になりがちです。これらも学習のひとつの形ですが、失敗を恐れずに挑戦というより、失敗が起こらないように調整に近いです。

このギャップに気づかないまま、同じ「失敗から学ぶ」という言葉を使っていることがあります。「失敗を恐れるな」と言われても、学習の形は「失敗を防ぐ」になっています。言葉と実装が噛み合っていません。チーム内でも、メンバーそれぞれが「学習」に対して異なるイメージを持っていることがあります。ある人は再発防止を、別の人は根本原因の理解を、また別の人はプロセス改善を期待しているかもしれません。この認識のズレが、ふりかえりでの議論を難しくすることがあります。

「失敗から学ぶ」という言葉が機能しないのは、個人の姿勢の問題ではなく、言葉の意味が揃っていないことが一因かもしれません。では、どこから始められるでしょうか。

まず、チームで「失敗から学ぶ」の意味を共有することがスタートです。私たちが「失敗から学ぶ」と言うとき、何を指しているでしょうか。同じ失敗を繰り返さないことでしょうか。仮説が外れた要因を理解することでしょうか。

もうひとつは、ふりかえりでの質問を少し変えてみることです。例えば、KPTに加えて、以下のような問いを追加してみるのはどうでしょうか。

• 仮説と結果にはどんなギャップがある？
• 上手くいっているとどう判断する？
• 途中で上手くいっていないと気付けることある？
• 今回の結果を生み出したステップを振り返ろう

これらの問いは、「次はもっと慎重に」ではなく、「何を見落としていたか」を明らかにします。前提条件や成功基準を明らかにすることで、「きちんとドキュメントを書く」というぼんやりとした対策から、「〇〇についてチェックリストを作成する」といった具体的な方法が導き出されます。

「同じように失敗予防しているだけじゃないか」と思うかもしれません。しかし、予防は「失敗を避ける」ことを強調してしまうのに対し、上記のような問いは「なぜ仮説が外れたか」を理解し、次の判断精度を上げることを目指しています。予防が「もっと気をつける」なら、学習は「何を見るべきだったか」を知ることです。後者のほうが失敗の捉え方も少し前向きになると思います。

私たちは実際に失敗から何を学ぼうとしているのでしょうか。
意思決定プロセスの見直しやチーム構造の理解まで踏み込むことは、容易ではありません。説明責任が問われますし、キャリアや人間関係へのリスクを感じることもあります。

しかし、すべてを変える必要はありません。KPTのような現存する仕組みのなかで、問いかけを少し変えてみる。チームで「学習」の意味を話し合ってみる。こうした小さな変化が、経営者の期待と実務のギャップを少しずつ埋めていく一歩になります。 あなたのチームは「失敗から学ぶ」をどう捉えているでしょうか。次の振り返りで、少し問いかけを変えてみてはいかがでしょうか。

GitHubは88%のCopilotユーザーが生産性向上を感じていると報告しています。また、JPMorgan Chaseのエンジニアは10〜20%の生産性向上したという発表をしています。こうした数字を見ると、生成AIが個人の作業を加速させていることが分かります。

しかし、組織レベルで見ると様相は一変します。LeadDevの調査では、617人のエンジニアリングリーダーのうち、大きな生産性向上を報告したのはわずか6%でした。McKinseyの調査では、生成AIを導入した企業の80%近くが、大きな成果を得ていないと報告しています。今年の夏に発表された Harvard Business Review による「State of AI in Business 2025 (PDF)」でも同様に、生成AIによる生産性の向上が見られないと発表しています。
個人の効率化が、なぜ組織の生産性向上に繋がらないのでしょうか？

生産性向上が生む、新しい負荷

最近、「Slop」という言葉を耳にすることが増えました。質が低く、意図のないコンテンツを指す言葉です。生成AIの登場でアウトプットが容易になった一方で、こうしたコンテンツが増えています。こうしたコンテンツは「Slop」または「AI Slop」と呼ばれることが多く、メールでいうスパムに似た使われ方をしています。

SNSなどに出てくるコンテンツだけでなく、仕事でも「Slop」が増えてきています。プロンプトや関連ファイルを活用して生成された内容が、一見すると良い感じに見えても、実際に読むと使えないことがあります。生成物を作った方は「AIを活用して効率化できた」と感じるかもしれませんが、レビュー作業や確認のために多大な時間を浪費する人も出てきています。こうした、AIを活用して仕事をしているように見えて、実際にはそうではない成果物を「Workslop」と呼ぶそうです。

AI-Generated “Workslop” Is Destroying Productivity

Despite a surge in generative AI use across workplaces, most companies are seeing little measurable ROI. One possible reason is because AI tools are being used to produce “workslop”—content that appears polished but lacks real substance, offloading cognitive labor onto coworkers. Research from BetterUp Labs and Stanford found that 41% of workers have encountered such AI-generated output, costing nearly two hours of rework per instance and creating downstream productivity, trust, and collaboration issues. Leaders need to consider how they may be encouraging indiscriminate organizational mandates and offering too little guidance on quality standards. To counteract workslop, leaders should model purposeful AI use, establish clear norms, and encourage a “pilot mindset” that combines high agency with optimism—promoting AI as a collaborative tool, not a shortcut.

Harvard Business ReviewKate Niederhoffer

もちろん、生成AIが登場する以前から、ショートカットして質の低い成果物を作る人はいました。
しかし、短いプロンプトで簡単に何かを生成できる手軽さは、これまでなかったと思います。この手軽さによって、組織の中で生成物の確認作業に埋もれてしまう人が増えてきています。個人の効率化と組織の生産性の間には、調整コスト、レビュー負担、認識合わせの時間という見えない溝があるのではないでしょうか。

こうした品質問題への対策として「Human in the Loop（人間参加型）」が重要であると答える人もいます。人間が工程に入って確認すれば大丈夫という考え方です。ただ、スピードと量が評価される文化では、レビューがあっても結果は変わらないのではないでしょうか。パッと見良さそうなら承認する。これは生成AIで成果物をサッと作る場合と同じです。

人間関係の問題が絡むと、「Human in the Loop」どころか、コラボレーション自体が難しくなることがあります。上司の Workslop を指摘した場合、どのような反応が返ってくるのか不安に感じることもあるでしょう。工程が順調に進んでいるにもかかわらず、Workslop 対策を提案すると、雰囲気が悪くなるのではないかと心配する人もいるはずです。

個人レベルの実験で組織の学習を準備する

問題はAIツール自体ではありません。真の課題は「価値を生む使い方」と「見てくれだけの使い方」を区別できないことです。「1時間かかっていたものが15分でできた」という数字は明快ですし、あたかも生産性が向上したかのように見えます。一方「こういう使い方によって組織全体の価値を高まる」は単純な測定や評価が困難です。

組織活用で必要なのは、「どのAIツールを使うか？」ではなく、「私たちは何を達成しようとしているのか？」を明らかにすることではないでしょうか。生産性向上、効率化といった抽象的な表現に留めず下記の解像度を上げる必要があります。

• そもそも「良い」とは何か？ : 何を基準に良いとするのか？ どの部分が良いと十分なのか？ そのあたりの定義が概念で留まるケースがあります。
• 人間は実際にどう関わるのか？: 「確認して」と言われたとき、何を確認するか？ デザインの意図を理解するために質問しているか、それとも表面的な見た目だけをチェックして承認しているか？
• 何があると差し戻しなのか？: 即NGになるような基準はあるのか？それとも特定の場合であれば、たとえ全ての基準を満たしていなくても次の工程を進めるのか？

AIから価値を引き出せる組織は、単に「やる気のある人たち」が集まっているだけではありません。何が機能して、何が機能していないかを評価できるようになるためにも、利用パターンと価値を結びつけるフィードバックループが必要です。つまり、どの使い方がどの成果と相関しているかを明らかにすることです。

組織全体でフィードバックループを構築するのは容易ではありません。測定システム、権限構造、組織記憶—これらを整えるには時間もリソースも必要です。しかし、組織が準備できるまで待つ必要はありません。個人レベルでも、同じ原理を小規模に試すことはできます。

私自身、Claude Projectを使ったコミュニケーション分析で、こうした実験を始めています。Instructionを定期的にAIとレビューし、改善ログを記録しています。個人利用のため、そのまま組織に展開できるものではありませんが、生成と改善のフィードバックループを作ることで、そもそも「良い」とは何か？、どの部分を確認すればよいのか？といった暗黙知を、少しずつ明文化する機会になっています。また、「どんな測定が必要か？」「どんな判断基準を共有すべきか？」のヒントを、失敗コストが低い状態で探れるのは価値があると感じています。

AIツールの導入で作業速度は向上しましたが、個人の効率化が組織全体の価値に結びついていないことがあります。AIによって時間が生まれたように見えても、実際には新たな調整コストが増えている可能性があります。「効率化」や「自動化」といった言葉を漠然と使うのではなく、組織として何を効率化するのかを明確にし、そのために必要な学習内容を特定することが重要です。デザインも、生成AIを使って多くのバリエーションを作ることにとどまらず、何を早く作ることで物事が前進するのかを考えることが重要です。決定時に必要な最低限の「良さ」を明らかにすることで、AIとの関係が変わるかもしれません。

多くのデザイナーは、この指摘に深く頷いたと思います。日々の業務で「なぜこのデザインが良いのか数値で説明できますか？」と問われることもありますし、言葉にしづらい価値を説明することはある種のこじつけに感じられます。

これに対するアイブ氏の回答は、どこか物足りなさを感じます。彼が提案する解決策は、チームの信頼関係を築き、お互いのために何かを作り、細部に愛情を注ぐといった儀式的なアプローチかつ精神論ようにも聞こえます。これらの実践は確かに意味がありますが、権威や文化に大きく依存していて、体系的にデザインの質を組織の意思決定に組み込む方法としては限界があります。

すべてを計測しようとする現状を良いと思えない一方、彼の言葉を手放しで称賛できないと思います。

今のデザインを見回すと、質を評価する方法が二つの極端に分かれてしまっています。

一方は完全な定量化です。すべての決定をメトリクス、実験、最適化で判断し、デザイナーの裁量はA/Bテストで勝利した選択肢に限定されます。「ユーザーの離脱率が2％改善しました」という数値が、デザインの良し悪しを決める唯一の基準になってしまうことがあります。

もう一方はデザインの神秘化です。デザインの質は測定不可能で、どこか神聖なものとして扱われ、適切な感性やスキルを持つ人だけがアクセスできるものとされます。「これは感覚的なものなので説明できません」「質にこだわる姿勢を大事にしよう」といった具合に、説明責任を回避する盾として使われることもあります。

どちらのアプローチも、最終的にはデザインを傷つけていると思います。純粋な定量化は人間を最適化のターゲットに還元し、純粋な神秘化はデザインを聖職者の領域に押し込め、権威に基づく判断を正当化しつつ説明責任を避けることになります。

アイブ氏が測定不可能なものを擁護する視点は重要です。デザインの質には、分析に抗う要素が実際に存在します。素材の手触り、インターフェースのユーモア、小さなパッケージの細部に込められた配慮。これらの体験は、スプレッドシートで記録したり証明することはできません。そして、そういった計測できないものが人々の心を動かします。

私たちがプロダクトを使うとき、機能的な満足だけでなく、「なんとなく心地よい」「使っていて楽しい」といった感情的な体験を求めていることがあります。これは数値では表現しきれない価値です。

だからといって、そこで停止するのも良くありません。「質は説明できない」という前提から、デザイナーには特別な判断力とスキルが必要だと権威の正当化ができる。しかし、いざ具体的な説明を求められると、ビジョンやパーパスといった抽象的な概念に逃げ込んで説明責任を回避する。この論理の矛盾により、デザイナーが組織内で「理解されない専門家」として他の職種とは異なる特別な地位を占めてしまうという歪みが生まれる可能性があります。

アイブ氏の議論から抜け落ちているもの、そして業界全体の議論から抜け落ちているものは、中間のアプローチです。説明できない要素を盾として使わずに大切にする方法。デザインの魔法を生かしつつ、それを組織的な推論の一部にする方法です。

アイブ氏の「当時は、私たちは人類に奉仕する存在だという強い目的意識があった」「私の仕事は道具をつくることであり、その目的は人々の可能性を広げ、鼓舞することだ」という言葉はデザイナーであれば刺さったと思います。しかし、もしそれが真実なら、デザイナーは個人的な権威だけに頼って「質が大事」と語ることはできないはずです。質を業界内の賞や同業者からの認知によってのみ検証される自己言及的な概念にしてしまうこともできないと思います。

デザインが社会に影響を与えるものであるなら、質は議論され、明文化され、テストされるものでなければなりません。魔法を殺すような方法ではなく、デザイナーが自分たちの仕事の効果に責任を持てるような方法で、です。

デザインの質についての議論は、定量化か神秘化で終わるべきではありません。むしろ、この二つの緊張関係から始まり、最も大切なことについて推論できる仕組みを構築するべきです。それが完璧に測定できないものであったとしても。

ベストプラクティスには不思議な魅力があります。道しるべとして頼りになる存在でありながら、うまくいかないことも多いです。一方で、手法や方法論を伝えたい立場も、できるだけ多くの人に役立つ方法を伝えたい気持ちと、「これは万能ではない」と伝えたい気持ちの間で揺れることがあります。

多くの人がベストプラクティスを求めていますが、なぜ期待した結果が得られないことがあるのでしょうか。

すれ違いが生み出す落とし穴

「ベストプラクティス」という言葉に関しては、過去に何度も議論されてきました。「これが成功率が高い手法です」という強いニュアンスを持つ言葉ですが、実際には文脈に依存した個人の信念に過ぎないという見解もあります。以下はアクセシビリティのベストプラクティスに関する記事ですが、デザインだけでなく、広い分野で共通する点があります。

“Best practice” is just your opinion

Why we need a different term for best practice

craigabbott.co.ukCraig Abbott

この問題の本質は「ベストプラクティス」という言葉の曖昧さだけではありません。実際、知識やノウハウを提供する側と求める側の期待に根本的なズレがあります。

知識やノウハウを提供する側は、経験したプロセスや直面した制約、試行錯誤の過程を含めて、文脈をしっかり共有したいと考えます。伝えるべきは具体的な手段や手順ではなく、「なぜそれが機能したのか」「どのような条件下で効果があるのか」といった背景情報です。一方で、ベストプラクティスをはじめとした情報を求める側は、時間的制約の中で、説明可能で再現性のある解決策を必要としています。上司や同僚に説明できる根拠、リスクを軽減できる先例を探しています。「どのような条件下で効果があるのか」といった知識は大切ですが、情報を求める人たちが求めているのは深い理解ではなく、目の前にある問題をいかに解決するかです。

他社の成功を根拠にすることで、言語化・共有が容易になります。組織での意思決定において「Aという会社がこの手法を使って成功した」という情報は、安全性を確保するための有効なでもあります。表面的に見えるかもしれませんが、実際に変化を推進するためには必要な場面があります。

一方で、間違いのない選択をしていると感じやすくなるバイアスも生まれやすくなります。このバイアスは「これを導入すれば上手く」といった、コピー＆ペースト式の変革を引き出すことがあります。Spotify が生み出した「スクワッドの自主運営構造」は多くの組織が取り入れようとしましたが、同じ文化的背景や信頼ベースの文化が自社にないまま導入した結果、混乱、コミュニケーションギャップ、非効率につながったケースもあります。

The Insidious Threat of Copy/Paste Change Management

When the need for changing the organizational process is clear, what to do is not so obvious.

New World Of WorkRick Waters

ベストプラクティスとの良い付き合い方

これはベストプラクティスに価値がないという話ではありません。組織で新しい取り組みを始めるには相当なエネルギーが必要であり、ベストプラクティスは重要な推進力となります。実績のある手法として紹介できることで、ステークホルダーの理解を得やすくなり、予算や人的リソースの確保につながることも多いです。

問題は、ベストプラクティス自体ではなく、それとの向き合い方にあるのではないでしょうか。何かを始めるための『入口』として使えますが、組織の文脈に合う最適解ではないことが多いです。ただ、その前提を考慮してあえてベストプラクティスを試すことで、組織に合う手法の特徴が見えてくることがあります。

では、ベストプラクティスにどう向き合うべきでしょうか。ベストプラクティスを学ぶときや実践した後で、3つの視点（レンズ）で分析することで、組織に適した方法が見えてきます。

1. 仕組みのレンズ : このベストプラクティスは、どのような技術制約、組織規模、開発プロセスを前提としているでしょうか。使用しているツールスタック、リソース配分、品質基準や評価指標はどのようなものだったのか。
2. ビジネスのレンズ : どのような事業判断のもとで、そのアプローチが選択されたのでしょうか。リスク許容度、意思決定に求められるスピード、ステークホルダーの関心事や優先順位、予算制約やROIへの期待値。これらの要因が自分の状況とどう違うのでしょうか。
3. チームのレンズ : ベストプラクティスが機能したチームは、どのような専門性レベルや経験値を持っていたでしょうか。コミュニケーションパターン、ユーザーとの距離感、フィードバックループの構造は自社とどう違うでしょうか。

うまくいかなかった時こそ、3つのレンズから観察することが重要です。これにより、「仕組みの前提が異なっていたために機能しなかった」や「リスクの許容は適切だったが、ステークホルダーの関心度に差があった」といった分析が可能になります。これが次の改善に具体性をもたらします。繰り返し分析することで、世にあるベストプラクティスが自社に合うかどうかもすぐに判断できるようになります。

ただ、こうした分析続けると、すべてのベストプラクティスが自社で使えないという結論に至ると思います。組織はそれぞれユニークなわけですから当然の結論です。「いいとこどり」のような部分的な適用も、かえって期待と異なる結果を招くことがあります。ベストプラクティスとして紹介されている手法は、一つの体系として全体が整合している からこそ成り立っています。部分的に切り出して適用しても、同じような効果は期待できません。

丸ごと移植もできず、部分的な適用も効果的でないとすれば、何が残るのでしょうか。
ベストプラクティスから抽出できる価値は、手法とは別のところにあるかもしれません。

• 思考の枠組みを理解する : なぜその判断をしたのか、何を重視していたのか、どのような制約の中で選択したのか。
• 注目すべき観点や問いかけ : 自分たちの文脈と重ねることで「この側面を見落としていたかもしれない」という気づきが得れることがあります。
• 問題を表現する言葉の発見 : 私たちがうまく言語化できていなかったことが、ベストプラクティスが適切な表現で提供されていることがあります。
• 失敗パターンにも注目 : 何がうまくいったかよりも、何がうまくいかなかったか、どこで軌道修正が必要だったかを理解する方が、異なる文脈でも応用しやすいことがあります。

自社の文脈の複雑さを理解していないままだと、ベストプラクティスで期待した結果が得られないことが多くあります。ベストプラクティスが生まれた環境と、それを適用しようとする環境の間には、表面的には見えない無数の違いがあります。組織文化、技術制約、ステークホルダーの関心事、チームの専門性など、様々な要因が相互作用し、同じ手法でも異なる結果をもたらします。

外部の手法に目を向けることで「自分たちの組織はどのように物事を進めているのか？」という内省的な問いが生まれ、組織の特性をより深く理解するきっかけになります。ベストプラクティスは万能薬ではありませんが、自分たちの文脈を見つめ直す役割を果たしてくれるはずです。

アプリのランディングページに利用者の声を掲載することがあります。「ワークライフバランスが改善しました」というメッセージが並んでいると、多くの人は「このアプリでワークライフバランスが改善されるに違いない」と感じるでしょう。カレンダーアプリなので予定の管理が主要機能なのにも関わらず、ランディングページを訪れたユーザーは「カレンダー → ワークライフバランス」という因果関係を頭の中に思い浮かべてしまいます。

カレンダーアプリは、ワークライフバランスを変えるアプリとして売り込んでいるわけではありません。しかし、近接性による因果の錯覚が生じることがあります。私たちがレイアウトで隣り合わせに配置した要素を、ユーザーは無意識に因果関係があると解釈してしまうことがあります。

「近接の原理」とは、要素を近くに配置すると関連があるように見え、離すと無関係に見えるという視覚デザインの基本原理です。これは情報を分かりやすく伝える重要なテクニックですが、バイアスを作り出す場合もあります。

社会心理学の領域では、近接性に基づく認知バイアス（隣接性バイアス（proximity bias））が知られており、近いものへの過剰な好意や関連付けが起こす現象があります。情報が隣接しているだけで、誤った結びつきを生むリスクがあります。先述した「カレンダー → ワークライフバランス」という因果関係も隣接性バイアスによるものです。

似たようなパターンを、Harvard Business Review の記事で見つけました。ハンブルク市の住宅危機対応でAIプラットフォーム「CityScope」が迅速な意思決定を実現したと紹介されています。

How AI Can Help Tackle Collective Decision-Making

When a big decision must be made by multiple constituencies with different goals, it can often fall victim to challenges from drawn-out processes to data overload. But AI is helping. One field—city planning—is already applying its ability to analyze vast troves of data, understand group preferences, and so on to collective decision-making. Specifically, officials in Hamburg, Germany partnered with MIT Media Lab’s CityScope tool to better work with residents and other stakeholders when addressing a housing crisis. The tool’s success in Hamburg demonstrates ways to use AI for better insights, predictions, deep scenario planning, and consensus-building.

Harvard Business ReviewMathis Bitton

「AIで複数人の意思決定をもっとスムーズに」「AIによる合意形成のサポート」「AIが議論の長期化や情報過多に課題を解決」といった表現がところどころにあると、AIが意思決定のスピードアップをしたと解釈した読者もいると思います。データの視覚化やARの活用が画像で紹介されているので、そのイメージが余計強まります。

きちんと記事を読むと、AIプラットフォーム以外の要因が、実際のスピード向上において重要であることがわかります。AIの役割はデータ統合と可視化に役立ったのは間違いないですが、承認プロセスの高速化は、政治的・手続き的変更によるものです。

• 通常の官僚手続きを迂回した特別プロセス
• 8万家族対象という明確な制約設定
• 5,000人参加の構造化ワークショップ
• 際限のない都市計画議論から具体的問題への焦点化

記事の最後には「実際の行動に移せるかどうかは、ツールではなくリーダーシップ次第」と書かれています。つまり、AIが意思決定を速めることを伝えたいわけではないことが明らかです。しかし、記事のタイトルと冒頭でAIを主語にし、成果と並べて配置しています。プロセス設計の要素は文中に埋め込まれ、重要度が低く見えます。記事構造によって「AIが意思決定を高速化する」という誤解を生んでいるのではないでしょうか。

意図しないナラティブを避けるための問い

私たちは日々、何気なく情報を消費しています。しかし、その情報の構成によって、意図せずに因果関係を作り出してしまうことがあります。作り手が意図していなくても、受け手に誤った印象を与えることも少なくありません。カレンダーアプリやHBRの記事の例では、情報が近くに配置されていることで、意図していないストーリーが受け手の脳内に植え付けられています。

例えば、プロダクトの機能説明セクションとユーザーの成果事例セクションを並べて配置することがあります。しかし、その配置によって「機能Aが成果Bを直接生み出す」という因果関係を暗示してしまうことがあります。これが作り手の意図であれば問題ありませんが、誤解を避けるためにいくつかの問いを立てることができます。

• 隣り合わせ配置で、ユーザーはどんな因果関係を想像する？
• 因果関係は本当に成立する？単一要因による結果に見えてない？（成果は多くの要因から生まれるので、単一機能を強調し過ぎてないか確認します）
• この配置で期待値を上げすぎている？
• 隣接以外の方法で関連を示すならどうする？（色、大きさ、ラベルの工夫で誤解を避けることができます）
• 補足説明や文脈情報で勘違いは免れる？小見出しやキャプションを添えるだけでも誤解を防げる場合があります）

配置は想像以上に強い影響力を持ちます。近くに置かれるだけで、ユーザーは関係や因果を補完し、自分なりのストーリーを作り上げます。特に流し読みの際にはこの傾向が強く、意図を超えた期待や誤解が生じやすいです。バズったりシェアされている情報をよく見ると、明示されていないが暗示的な伝え方をしているものが少なくありません。だからこそ、この配置でユーザーが何を因果と感じるかを問う機会がますます重要になります。

セクションの順序だけでなく、中身の距離や語順も因果をつくります。例えば、右肩上がりのグラフの直後に「新機能を公開」と記載すると、価格改定など他の要因を無視して、その機能のおかげだと解釈されがちです。また、セキュリティ説明の横に認証バッジを並べると、プロダクト全体がフル認証済みだと受け取られることもあります。だからこそ、この配置でユーザーが何を因果と感じるかを、ページ全体と同じ粒度で各コンテンツに対しても考慮する必要があります。

ChatGPTやClaudeをはじめとした生成AIツールの登場で、デザイナーのなかには「スペシャリストになるべきか、ジェネラリストになるべきか」と迷っている人がいるかもしれん。一方では「AIに代替されない深い専門性を」という声があり、他方では「AIと協働するには幅広いスキルが必要」という主張も聞かれます。

人材モデルが分かりやすい理由

スペシャリスト、ジェネラリストだけでなく、様々な人材モデルがあります。

「T字型（T-shaped）」という人材モデルを聞いたことがある方はいると思います。一つの分野での深い専門性（縦棒）をもちつつ、複数の分野での幅広い協働能力（横棒）を持つ人材像のことを指します。元々はIDEOなどのデザインコンサルティング企業が、チームでのコラボレーション能力を表す概念として広がりました。深い専門性があることで独自の価値を発揮しつつ、横の幅広さによって他分野の専門家と共通言語で対話し、橋渡し役になれる点が特徴です。

他にも、単一分野での深い専門性を持つ「I字型（I-Shaped）」、T字型の幅広さと深さに加えて、強力なリーダーシップ資質と、協働やイノベーションを推進する「X字型（X-Shaped）」。他にも、二つの分野にそれぞれ深い専門性を持ち、その二本の柱を横断する幅広い理解で支える「π型（π-Shaped）もあります。

これらのモデルは、自分のこれからを考える上で参考になるブループリントのように見えます。特にスタートアップや新興業界では、伝統的なキャリアパスが存在しません。「次に何をすべきか」という不確実性があるだけでなく、自分の市場価値を測る物差しが不足しているので、不安や焦燥感が増すこともあります。

そうしたなか、人材モデルに対する安心感や納得感を抱くポイントは、例えば以下のようなものがあります。

• 曖昧な将来像を具体的な形に置き換えられる
• 進むべき方向や成長の優先度が明確になる
• 曖昧な将来像を具体的な形に置き換えられる
• 同じ型の人と比較・参照しやすい

不確定要素が多い環境では、そもそも「何を身につければいいのか」や「評価軸がどこにあるのか」が曖昧になりやすいです。T字型やπ型のようなモデルは、その曖昧さを図式化し、安心できる枠組みに提供してくれますが、大きな落とし穴が潜んでいます。

「何になるか」思考が生み出す最適化の罠

モデルには優れた点がありますが、「アイデンティティ最適化」として扱うとやっかいです。「T字型人材になりたい」と考えるデザイナーが、UXの周辺知識を学び始めることがあります。例えば、「UXデザイナーとしての成長には、デザインスキルに軸足を置きつつ、行動経済学を学ぶと良いかも」と考えるかもしれません。しかし、こうした「T字型になる」という目標で学習を進めても、周囲の評価が変わることはありません。

「何になるか」に注目しすぎる経験は、多くの人が一度はしたことがあると思います。しかし、T字型スキルの概念を広めたマッキンゼーやIDEOが本当に重視していたのは、「T字型になること」ではありません。重要なのは、複数の専門分野をまたいで問題を解決する能力です。つまり、T字型の形状は結果であり、意図的に目指すものではないわけです。

IDEO CEO Tim Brown: T-Shaped Stars: The Backbone of IDEO’s Collaborative Culture

An Interview with IDEO CEO Tim Brown

ChiefExecutive.netmorten t. hansen

しかし、モデルが一人歩きすると、形状そのものが目標になってしまいます。人々は「T字型デザイナー」「π字型プロダクトマネージャー」といったアイデンティティを追求し、実際の問題解決から遠ざかってしまうことがあります。

問題解決中心のキャリア思考への転換

「どんな人材になるべきか？」といったアイデンティティを目標にしないためにも、発想の転換が必要です。そのヒントになりそうなのが JP Michel が提唱する「Challenge Mindset（チャレンジ・マインドセット）」です。仕事や肩書き（職業）ではなく、「自分が解決したい課題」へ焦点を当てる考え方で、なりたい職業を探すのではなく、「組織や社会に意義のある課題」を起点にキャリアを考えるアプローチです。

2020年春、シンシナティ大学の芸術科学部で行われた研究では、61名の学部生が「世界を変えるなら何を変えたいか？」というテーマでキャリア探索を行いました。多くの学生は専攻とは直接関係のない社会課題に興味を持ち、その結果、より具体的で動機づけられたキャリアの検討と行動につながったことが明らかになりました。

A Problem-Solving Approach to Career Exploration: Using the Lens of Challenge

By encouraging students to engage in real-world problems using the Challenge Method, career professionals can help students take tangible steps toward career decision-making and planning.

DefaultMapping the Future of Undergraduate Career Education

もちろん、組織で働くデザイナーが、いきなり世界を変える課題探しを始める必要はありません。代わりに、今の組織にどのような課題があるのかから考え始めると良いでしょう。

例えば、UXリサーチの結果をプロダクト改善の判断に十分活用できていないという課題があるとします。このとき、「リサーチ能力や伝え方のスキルをもっと高めよう」と考えると、課題がより大きく膨らむ可能性があります。リサーチ結果を活用できない原因を明らかにするために、「なぜ活用できていないのか」と問いかけることが、次に何を学ぶべきかを見極める手がかりになります。

もしかすると、意思決定とリサーチのタイミングが合っていない、意思決定者の間で合意が取れていない、エビデンスがPRDやロードマップの単位に変換されていない、インセンティブの方向性が異なっているなどが考えられます。もし意思決定とリサーチのタイミングが噛み合っていない場合は、自社が採用しているプロジェクトマネジメント手法を深く学ぶことが有効です。そうすることで、適切なタイミングを見つけられるだけでなく、どのような形式のレポートなら組み込みやすいかも検討しやすくなります。

他にも下記のような問いが、次に何をすべきか探し出すヒントになります。

• 「デザインの実装で最も困っているのは何か？」
• 「コミュニケーションのやりとりが上手くいっていないところは？」
• 「チームや組織で意思決定が止まっている箇所はどこか？」
• 「デザイナーの立場だからこそ見える課題は何か？」

重要なのは、これらの問いから出発してスキル開発の方向性を決めることです。問題解決に基づくキャリア開発の研究では、課題から逆算してスキルを選択することで、より効果的で動機的な学習が可能になると言われています。

スキルは課題解決のためにある

ジェネラリスト、スペシャリスト。そして、T字型などの人材モデルは、キャリアやスキル開発を考えるきっかけにはなりますが、目標そのものではありません。大切なのは、今の職場にどのような課題があるのか、何をすれば少しでも前進できるのかという視点です。そういう意味では、ユーザーの立場に共感しながら課題を解決する日々のデザイン業務と、大きくは変わらないかもしれません。

「あるべき姿」や「理想像」を追い求めるよりも、目の前の人たちの困りごとに向き合うほうが、ずっと本質的かもしれません。デザインで培った観察力と共感力は、実はキャリア開発においても非常に強力な武器になるのではないでしょうか。

2025 | contents.nagoya

コンテンツ ドット ナゴヤ とは、「コンテンツ」をテーマに掲げ、コンテンツを作る・コンテンツを管理する・コンテンツを届けるという3つの視点から、多くのクリエイターや企業が集まり、交流し、学び合うイベントです。

contents.nagoya 2025

従来アプローチの最適化で良いのか

例えば、Google の AI Overviews は、検索結果の 18-64% のトラフィック減少を引き起こすと言われています。特に情報系サイトへの影響は大きいとされ、ユーザーはゼロクリックで必要な情報を得られるようになっています。 これは 、ChatGPT や Perplexity といった AI サービスにも当てはまります。Webサイトを訪れなくても目的を達成できると実感している人はたくさんいると思います。ゼロクリックになれば、従来の広告やオーガニック検索結果の可視性が低下するわけですから影響は大きいはずです。

Google’s AI: Impact on Search & Business | Bounteous

Discover how Google’s AI transforms organic and paid search, and how businesses can adapt their SEO strategies.

BounteousChris Marshall

これは単なる表示形式の変更ではありません。人間と情報の関係性そのものが変わり始めていることを意味しています。従来の検索では、ユーザーがキーワードを入力して情報を「引き出す」プル型のプロセスでした。しかし。今は AI エージェントが情報を集めてユーザーに合わせてまとめてユーザーに提示するプッシュ型に移行し始めています。HubSpot のトラフィック流入が半年で80%減少や米ニュースサイトはGoogleからの流入半減したニュースからも、今での延長線でSEOができないことを示しています。

長年、SEOやコンテンツマーケティングでは「いかに発見されるか」を考えてきました。数年後にはAI検索が従来のキーワード検索を上回る見通しが高いという可能性があります。たとえば、2026年までに従来の検索が25%も減少するといった Gardner の予測記事だけでなく、Google や Microsoft のAI検索への舵きりする現状を見ても、その流れは明らかです。

この変化は検索領域にとどまらず、CMSにも言えます。ページというwebサイトの見た目に縛られない、構造的なデータを扱えるヘッドレスCMSは、Webサイト以外で情報を得るユーザーが増えた今、重要性を高めています。 ヘッドレスCMS市場は、2024年から2033年にかけて20.5%の成長が見込まれています。 これは、従来の「Webサイト管理」からAIを含む複数チャネルでのコンテンツ管理へと移行が進んでいることを示しています。

エンタープライズ向けのAdobe Experience Manager（AEM）だと、すでにこの方向性を実現していますが、この変化はエンタープライズ以外の領域にも急速に広がっています。コンテンツ管理は、特定のサイトやアプリのためではなく、あらゆるチャネルでコンテンツを再構成・配信できるワークフローを前提とした設計へと向かっています。つまり、Web サイトにコンテンツを載せることを前提とするワークフローに限定しない体験設計が求められるはずです。

こうして情報の接し方が変わってきている中で、従来からあるWebサイト制作ワークフローの最適化という文脈でのAI活用だけでは、単にAIのポテンシャルを十分に引き出せないだけでなく、今起こっていることへの対応が十分にできない最適化を行っている可能性があるかもしれません。 もちろん、直近の課題を解決することは重要ですが、既存業務の効率化に留まれば視野が狭くなりがちです。

PwCの調査によると、日本企業の多くが生成AIを「単なる効率化ツール」として捉える一方、米国企業は「業務や事業構造の抜本的改革の手段」として新しい顧客体験創出や新規事業投資に活用しています。 この差は、ツールの使い方の違いではありません。情報アクセスの多様化というパラダイムシフトに対する根本的な認識と対応戦略の違いだと思います。

生成AIに関する実態調査2024 春 米国との比較

本調査では、日本企業と米国企業における生成AIの認知度、活用状況、課題を比較しました。日本企業は既存業務効率化に生成AIを活用しているのに対して、米国企業は顧客サービスへの活用や新規事業への還元に取り組むなど、活用の実態に大きな差があることが明らかになりました。

PwCPricewaterhouseCoopers

誰も答えはもっていないから

「では、具体的にどうすればよいのか」といった疑問を抱くはずです。
明確な答えが見えない漠然とした不安こそが、AIへの関心を高めている人もいるはずです。

過去20年くらい、web制作のワークフローは比較的安定していました。テクニックは進化を続けているとはいえ、SEOの基本原則、デザインプロセス、ユーザビリティの捉え方、情報へのアクセス方法は大きく変わっていません。だからこそ、ベストプラクティスやフレームワークといった「型」を整えやすかったのだと思います。カンファレンスや勉強会が「型を学ぶ場」として定着したのも、こうした安定期があったからかもしれません。

しかし、現在の状況は全く異なります。毎月新しい技術やサービスが登場し、前月のベストプラクティスが別のものに入れ替わることが頻繁にあります。web やアプリ系のイベントは、専門家が「答えを教える」「ベストプラクティスという型を伝える」場が中心でした。しかし今必要なのは、みんなで悩んで、検証し、学習する集合的センスメイキングではないでしょうか。誰も明確な答えを持っておらず、分野も多岐にわたるため、一人や少人数で考えるには限界があります。

最近、わたしはカンファレスのセッション参加はほどほどにして、スポンサーブースにいる担当者と話をしたり、参加者と雑談するようにしています（contents.nagoya でもそうでした）。異なる経験、専門性を持つ参加者の意見の断片を組み合わせることで全体像が見えてくることがあります。 AI や CMS の活用でも、明確な答えがないまま模索する過程を聞いたほうが、変化が早いなかでの学習の糧になります。

今おこっている変化に対して、従来の延長線上で対応するのか、それとも新しい前提で思考し直すのか。その選択が、今後数年間の競争力を大きく左右すると思っています。たぶん、従来のデザインプロセスそのものに疑いの目を向けてるのは私だけではないはずです。答えはまだ誰も分かりません。ベストプラクティスがどこかにある状態から、皆でベストプラクティスを創り出していく時代になったのは、個人的にはとてもエキサイティングなことだと思います。

生成AIツールを本格的に使い始めて2年ほど経ちますが、今でも働き方が変わり続けています。プロトタイプの作成、アイデアの整理、リサーチの分析など、以前に比べて時間短縮ができているだけでなく、模索の幅も広がってきました。

ハーバード大学とボストン・コンサルティング・グループの共同研究結果によると、AI利用者は平均12.2％多くのタスクを完了し、25.1％速く作業を終え、40％高い品質の結果を生み出したそうです。数字だけ見れば、効率的かつ生産的な仕事をしているように見えます。

Navigating the Jagged Technological Frontier: Field Experimental Evidence of the Effects of AI on Knowledge Worker Productivity and Quality - Working Paper - Faculty & Research - Harvard Business School

Harvard Business School

しかし、脳科学の観点から見ると、別の観点が見えてきます。MITによる研究によると、ChatGPTを使ってエッセイを書いた人たちは、AIを使わず考えて書いた人たちと比べて、脳内のネットワークが約半分しか働いなかったそうです。また、ChatGPT使用者の8割以上が、自分が数分前に書いた文章を思い出すことができないなど、長期的に思考力や学習能力が衰える可能性があることを警告しています。

Your Brain on ChatGPT: Accumulation of Cognitive Debt when Using an AI Assistant for Essay Writing Task – MIT Media Lab

 This study explores the neural and behavioral consequences of LLM-assisted essay writing. Participants were divided into three groups: LLM, Search Engine…

MIT Media LabNataliya Kos’myna

ChatGPT’s Impact On Our Brains According to an MIT Study

The study, from MIT Lab scholars, measured the brain activity of subjects writing SAT essays with and without ChatGPT.

TimeAndrew R. Chow

特に若い世代の思考力に多大な影響が出ているという調査結果もあります。

AI Tools in Society: Impacts on Cognitive Offloading and the Future of Critical Thinking

ブレストやアイデアの壁打ちなど、生成AIを使って一緒に考える方法があります。しかし実際は、私たちが思考しているのではなく、AIが作り出した結果を評価したり、プロンプトで調整しているだけです。つまり、純粋な意味での思考とは言えず、思考しているように錯覚しているだけで、実際には思考をサボっている場合もあるわけです。

思考には、不確実な状況の中で手探りしながら進む苦悩が伴います。どこに向かえばよいかわからない混沌とした状態から、少しずつ方向性を見つけていく。その過程は非常に辛いものですが、そこを経なければ納得のいく結論にたどり着けないことがあります。一方で、AIとの対話は、私たちは評価者の立場にいるだけで、実際に考えているのは生成AIです。（厳密には思考していないですが）。

クリエイティブプロセスにおいて、探索と収束は避けて通れない過程です。アイデアを広げ、可能性を模索し、最終的に一つの解決策に絞り込んでいきます。AIがあるワークフローでも、この流れ自体は変わっていないように見えますが、各段階で行われている認知活動の質は、根本的に変化し始めています。その変化のなかで、デザイナーは文脈と制約を深く理解し、判断力を養う機会を失い始めているかもしれません。

探索では、プロジェクトの背景を深く理解することが欠かせません。また、過去の経験から得た直感も重要です。何をリサーチするか、どの要素をA/Bテストすべきか、どんなバリエーションを提案するかなど、探索に関わるさまざまな活動にはデザイナーの意図が必要になります。そして、その意図がアウトプットに大きな影響を与えます。

特に探索は苦しみが伴います。どう進めばいいかわからない不安、無数の選択肢の中から最適解を見つけ出す困難、制約の中で実現可能なアイデアを探し出す過程。できれば避けて通りたいと思ってしまいますが、この苦しみこそが、デザイナーの判断力と洞察力を育てる貴重な機会でもあります。

生成AIは、この苦しみを取り除いてくれます。しかし同時に、効率性という名のもとに、私たちの思考の筋力が衰えていきます。

判断すらAI任せになってない？

AIとの協働の時代においては、人は「良い問いをすること」「人らしい評価や判断をすること」「適材適所で AI モデルを使い分けること」が重要であると言われています。複数の提案から最適解を選び、生成された内容の品質をチェックし、必要に応じて修正を指示するといった働き方です。しかし、評価や選択の能力は、深い思考の蓄積によって育まれるものだと思います。なぜこのデザインが優れているのか、なぜこのコピーが響くのか、なぜこのユーザーフローが使いやすいのか。こうした判断力は、過去に自分自身で苦労して作り上げた経験と、その過程で培ったインサイトから生まれます。

AIに思考の大部分を委ねることで、判断や観点の基盤が蓄積されなくなります。結果、評価や選択の基準も曖昧になり、「なんとなく良さそう」「AIが言っているから正しいはず」というバイブスに頼った判断が増えていきます。出力結果のハルシーネーションは気にしているにもかかわらず、どのようなプロセスで出力されているのか気にならないのは、自らが問いを立て、仮説を検証する力が失われつつあるからかもしれません。

AIとの対話で感じる「思考しているような感覚」は、実際にはAIが代わりに思考した結果を私たちが受け取っているだけかもしれません。そして、その結果を受け取ることに慣れてしまうと、私たち自身の思考力は確実に衰えていきます。

AI活用は多くの場面で有効ですすし、今更「使わない」という選択肢は考えられません。言葉にできずモヤモヤしている気持ちを整理したり、図や絵に表せず諦めていた人の背中を押してくれます。しかし、その提案を自分たちの文脈に合わせて適切にカスタマイズし、判断する力がなければ、表面的な解決にとどまってしまいます。

MITの研究であった、数分前に書いた内容を引用することすらできなかった現象は、デザインプロセスでも同様に起こりうることです。自分が作ったはずのデザインなのに、その根拠や意図を説明できなくなる日が来るかもしれません。選ぶ力は、作る力と密接に関連しています。作る苦労を知っているからこそ、良いものと悪いものの違い分かるのではないでしょうか。

効率化だけが答えではない

生成AIによって「思考した」「アウトプットした」という感覚を手軽に得られるようになりました。この感覚は新鮮で楽しいですし、ある種の達成感も味わえます。物事がスピーディに進んでいるようにみえますが「これからどうしよう」といった迷いが生まれ、考えるのが面倒になり「これでいいや」と生成結果をコピペするだけになってしまいます。こうした疑似思考感から逃れるためにできることは、少しだけ手間をかけることだと思っています。

要約をあまりAIに任せないようにしたり、あえて紙のノートに書き込むなど、意図的に『手間』をかけるようにしています。実際、この記事も AI との会話がキッカケですが、一度ノートで考えを整理して「自分のもの」にしたあとに書き始めています（最近の記事はそのように書いています）。もちろん、仕事でも似たようなプロセスで考えを整理した後にアウトプットをしています。

これは、確実に時間がかかります。AIを使えば数秒で済むことを、30分くらいかけて行うわけですから、明らかに非効率です。しかし、この「非効率」を選ぶことでようやく自分なりの考えをまとめることができます。手を動かし、迷い、修正し、また考える。こうした過程は、楽で効率的な方向に進みがちなAIとの対話では難しいです（少なくとも今のところは）。

AIは重要な思考パートナーになり得ます。しかし、ふと立ち止まって考えると、「実際に考えているのはAIで、自分はその結果を評価しているだけかもしれない」と感じることもあります。もちろん、深く考えたら良い結果が生まれるのかというと、そんな単純な話ではありません。しかし、デザイナーとして必要な文脈を読み取ったり、制約の中で創造したり、ユーザーの本質的なニーズを見抜くには、思考力が欠かせないと思います。養う方法は様々ですが、生成AIと対話しているだけでは難しいと感じる今日この頃です。

まだβ期間のため、使い勝手やアクセシビリティに課題が目立ちますが、個人的に気になったのは説明の仕方です。利用体験の紹介やデモは少なく、デザインの一貫性やインタラクションの詳細といった設計者の論理を説明する内容が中心でした。実践的な問題解決より、デザインの理論的正当化に重点を置いているように見えます。

下記は「Aqua」を発表したときの Steve Jobs の動画です。

一貫性や歴史的背景を語らず、ただ「これ、すごくない？」という感覚だけで伝えるデモ。Aqua を最初に紹介したとき「You wanted to lick it.（なめてみたくなるよ）」といったコメントもしていました。Aquaも使い勝手やアクセシビリティの課題があり、優れたデザイン言語とは言い切れませんでした。しかし、デザインの論理をしっかり’説明する最近のアプローチとは異なり、感覚的な体験の話をしている姿は逆に新鮮さを感じます。

当時は（iPhone前！）、ユーザー数も少なかったため、直感的にアピールしやすい環境だったと思います。現在は世界一のグローバル企業となり、ユーザー数も多いだけでなく多数のステークホルダーへの説明が不可欠です。そのため、「Liquid Glass」のような説明が求められることにも共感できます。

しかし、外向きの説明論理が内部のデザイン判断を支配し始めると、論理のための論理になりがちです。説明できることが重要という考えが行き過ぎると、感覚的な領域まで明文化を強要される環境が生まれます。その結果、「理論的だが使いにくい」デザインが生まれてしまうことがあります。説明できることを重視する環境だと、理論で裏付けできない良いアイデアが却下されたり、実験や模索ができなくなります。

私はよく明文化や定量化を重視するよう伝えていますが、感覚的な領域には踏み込まないよう線を引いています。デザイナーが感覚的に納得していれば、それで十分だと思っています。時には「なんか良い感じ！」という直感だけで進めて良いのではないでしょうか。

ドナルド・ノーマンが著書『エモーショナル・デザイン』人間がプロダクトやサービスを体験する際に、本能的（Visceral）、行動的（Behavioral）、内省的（Reflective）という3つの異なるレベルで感情が動くと説いています。行動的レベルであれば明文化は必要ですが、本能的レベルにまで広げてしまうと、本来の意図とは違う正当化のための説明になってしまいます。

エモーショナル・デザイン―微笑を誘うモノたちのために | ドナルド・A. ノーマン, 岡本明, 安村通晃, 伊賀聡一郎, 上野晶子 |本 | 通販 | Amazon

Amazonでドナルド・A. ノーマン, 岡本明, 安村通晃, 伊賀聡一郎, 上野晶子のエモーショナル・デザイン―微笑を誘うモノたちのために。アマゾンならポイント還元本が多数。ドナルド・A. ノーマン, 岡本明, 安村通晃, 伊賀聡一郎, 上野晶子作品ほか、お急ぎ便対象商品は当日お届けも可能。またエモーショナル・デザイン―微笑を誘うモノたちのためにもアマゾン配送商品なら通常配送無料。

Amazonのストアでお買い物 ›フォロー

理論的説明は、チーム間の合意形成や、継続的改善のためには欠かせません。しかし、すべてを説明しようとすることで、デザインの本質的な価値を損なう危険性があります。「Liquid Glass」には賛否両論あると思いますが、私のなかでは、すべてを説明しようと努力した結果に生まれたのものと想像してしまいました。