ただ、同時に妙な忙しさも感じています。AIにタスクを渡して、出力を確認して、次のタスクを振る。その繰り返しの中で、「作っている」というより「捌いている」に近い時間が増えている。生産性は上がっています。しかし、それが楽しいかと聞かれると、正直よく分かりません。

以前、AI疲れについて書きましたが、そのときは「不安を煽るコンテンツに振り回されないこと」「70%ルールで自分の手を動かす余地を残すこと」を提案しました。不安を感じている方への提案でしたが、今は疲れや不安とは少し違うものを感じ始めています。「これってデザイナーにとって本当に楽しいのか？」という感覚です。

AI疲れや不安を感じている方へ

大事なのは、AIという道具を使って効率化することではなく、今の自分にとってちょうど良い付き合い方はどのようなものかを探ることです。

Yasuhisa HasegawaYasuhisa Hasegawa

エンジニアが感じ始めた「楽しくない」

ある開発者は、過去四半期の振り返りで「過去最高にコードを生成したが、同時に過去最高に疲弊した時期だった」と評価しています。流れの早い AI に「ついていけない」のではなく「もうやりたくない」と表現しているのが興味深い点です。つまり、情報収集やAI活用のスキルは高い一方で、エンジニアとしての楽しさを失いつつあるように見えます。

AIを使う開発者はプルリクエストのマージ数を劇的に伸ばしている一方で、時間外のコミットも増えています。 「トークンを使い続けないともったいない」という強迫観念を抱く方も増えてきています。生産性は上がっているかもしれません。しかし、上がった先にあるものが「もっと多くのレビュー」と「もっと密な管理」だとしたら、それはエンジニアがこの仕事を選んだ理由とは別のものだと思います。デザイナーと同様、多くのエンジニアも「自分の手で良いものを作りたい」のはずです。

Annie Vella の記事「The Software Engineering Identity Crisis」ではこの変化を、自分が渋々マネジメントに転向した経験と重ねています。好きだったことをやめて、 AIの出力を管理するという別の仕事に就いたような感覚を綴っています。これはデザイナーにとっても他人事ではないと思います。「自分で手を動かす」から「AIの出力を判断する」への変化を感じ始めている人も少なくありません。

AIを使ってアイデアを形にできるようになったこと自体は、多くのデザイナーにとって貴重な体験です。自分の頭の中にあるものが動く形になる瞬間には、純粋な発見の喜びがあります。私自身もそうした経験がありますし、最近はデザイナーが自らアプリをリリースするケースも増えています。

ただ、新しい道具を手にしたときの新鮮さと、その道具で毎日仕事をする感覚は違います。エンジニアが辿っている「できることが増える → もっと速く作る → もっと多く作る → 忙しいのに作っている感じがしない」という感覚は、デザイナーも遅かれ早かれ味わうものだと思います。

使いこなした上で離れる人たち

デザイナーの間では「テイストと判断力はAIには真似できない」という主張があります。AIが実行を担い、人間が判断を担う。デザイナーの関与が不可欠だと説く一方で、もしデザイナーの役割が「判断することだけ」になったらどうなるでしょうか。 デザイナーにとって判断が重要であっても、仕事を楽しいと感じるのは「作ること」です。

難しい問題に長時間向き合い、あれこれ試行錯誤し続けること。自分のアイデアを形にしていくうちに、少しずつ答えの輪郭が見えてくるその瞬間。時間をかけてようやく答えらしいものが形作られる過程はツライことも多いですが、同時に楽しいと感じられるからこそ、デザイナーを続ける人は多いのだと思います。そして、その過程こそが、テイストや判断力を養う唯一の方法です。

私が最近気になるのは、デザイナーやエンジニアが AI を使いこなせないから離れることではありません。使いこなした上で、この仕事が面白くなくなったから離れることが増えるのでは？という点です。能力の問題でも、品質へのこだわりの問題でもない。プロセスを踏まずにアウトプットだけが生まれ、見た目はそれなりに良くても充実感が得られない状態を、単に時代や定義の変化で片付けるわけにはいかないと思います。

仕事に惹かれた理由そのもの「自分の手で形にすること、苦闘を通じて学ぶこと、完成したときの手応え」が、効率化の名の下に最適化されて消えていく。残るのは管理、選別、確認となったとき、そこに自分なりの『デザイン』を見出せるのであれば続けられると思います。楽しさは千差万別なので、この変化に楽しさを見出せる人はたくさんいますが、それは今までのものとは別のものかもしれません。

AIの時代だからこそ、職人技や作り込みがデザイナーの差別化につながるというメッセージは、勇気づけられます。ただ、データをよく見ると、少し違う風景が見えてきます。

分かるようで分からない「クラフト」

調査では「クラフトとは何か」という質問がありますが、デザイナーは「視覚的な洗練（Visual Polish）: 58%」「熟考に基づく問題解決 (Thoughtful Problem Solving) : 47%」「明快で直感的なUX（Clear intuitive UX）: 36%」「感情と喜び（Emotion and Delight）: 35%」「プロダクト間の一貫性 （Consistency across products）: 15%」と回答しています。

それぞれが指している「品質」の性質はかなり違います。成果物の表面に現れる品質（視覚的な洗練）、 プロセスの質（熟考に基づく問題解決）、 ユーザーの認知体験の質（明確で直感的なUX）、感情的反応を生むことを目指す目標（感情と喜び）、 システムとしての品質（プロダクト間の一貫性）と、様々な観点が入り混じっているのが分かります。最大3つまで選べるアンケートのため仕方ない面はありますが、デザイナー間で「クラフト」への捉え方の違いが見え隠れします。

デザイナー間でも捉え方が違うわけですから、エンジニアや PdM にとっては「分かるようで分からない言葉」に聞こえているかもしれません。

エンジニアは「技術的負債の軽減」や「スケーラビリティ」という言葉を使って、自分たちが何に時間をかけて品質を上げていきたいのか伝えています。評価可能であることから「このアーキテクチャは1万件の同時接続に耐えられない」と言われたら、PMは「どのくらい遅くなるのか」と聞き返せるので、対話が成り立ちやすいです。

一方、デザイナーが「もっと洗練させるべき」と言っても、周りは「ただもっと時間を使いたいという意味？」と頭の中で考えているかもしれません。「直感的な操作にすべき」と言われても、「アニメーションを加えることで本当にそれが直感的になるの？」と思うかもしれません。

「見た目を洗練させる」ではなく「ユーザーが情報の階層を迷わず読み取れる視覚設計」といった言語化をすれば良いと考えるかもれませんが、それほど単純な話ではありません。デザインには、感覚、直感、経験に裏打ちされた判断など、言語化しきれない要素があります。こうした要素の存在を軽視し、すべてを測定指標に変換してしまうことで、デザインの価値そのものが損なわれる場合があります。

ただ、「言語化できない部分がある」であって、「デザインは言語化できない」というわけではありません。私たちが「クラフト」と呼んでいるものの中で、何がどこまで説明可能で、どこからが感覚的な領域なのか。なんとなくでも良いので、境界を自分の中で見極めることは、一人ひとりのデザイナーができることではないでしょうか。

楽観と悲観が同居する

Figma の調査にあった「より明確な推進力を報告しています。リーダーシップによる支援、成長の機会、評価を通じてクラフトに投資することは、デザイナーと組織の双方にとって、より良い成果と相関しています」という指摘と、クラフトへの注力と職業への楽観度の相関を示すチャートも一歩踏み込むと興味深い矛盾が浮かび上がります。

「クラフトへの注力が増えた」と答えたグループでも、ビジネスの成長が「遅い」と感じている人が 47% います。「変わらない」グループの方が、職業への楽観度が高い場合もあります。むしろ、成長している企業にはクラフトに投資する余裕があるだけかもしれません。因果の方向が逆の可能性もあります。

この調査から、デザイナーはクラフトが大事だと信じているのが分かりますし、AIの時代でもクラフトが自分たちの差別化になると考えています。しかし同時に、クラフトがビジネスに貢献しているという確信は持てていないようです。

この矛盾を「ビジネスがクラフトを理解しない」と捉えるのは簡単です。しかし、この矛盾はデザイナー自身の中にあるように思えます。「クラフトとは何か」をデザイナー自身がはっきり説明できず、周囲も分かっているようで実は分かりにくいですから、確信が持てないのは無理もありません。

詳細な調査結果がみれる PDF では、「Craft is king — and subjective」と見出しをつけています。デザインには主観性が含まれています。しかし、この見出しは「主観的で構わない、クラフトが最重要だ」というメッセージと捉えることができます。

調査によってデザイナーに「あなたの定義は正しい」と伝えることは居心地の良いことかもしれません。しかし、その安心は問題の先送りです。クラフトの定義が一部の人にしか共有されず、組織内で通じないままなら、その定義を見直すべきではないでしょうか。

Figma の立場を考えれば、デザイナーが自分たちの仕事に誇りを持てるようなフレーミングを選ぶのは自然なことです。デザインツールの会社がデザインの価値を肯定するのは当たり前です。だからこそ、読み手の側で「このデータは本当は何を映しているのか」を考える必要があります。

自分の「クラフト」を問い直す

私たちデザイナーは、クラフトについて2つの考えを同時に持っています。「クラフトは自分たちの固有の価値である」ということと、「周囲はその価値を理解してくれない」ということ。この2つが長く同居し続けているなら、問題はクラフトそのものの価値ではなく、私たちが「クラフト」と呼んでいるものの解像度にあるのかもしれません。

「視覚的な洗練」とは具体的に何を指すのか。
それは、認知負荷を下げるためのタイポグラフィの階層設計なのか。
情報構造を明確にするための色使いなのか。
それとも単に「見た目が美しいこと」なのか。

「楽しさ」とはどのような概念か。
完了時のフィードバックを指すのか。
エラー時の体験を指すのか。
操作の効率性を意味するのか。

これらを全部「クラフト」という一語にまとめてしまうと、身近な人たちの中では通じても、エンジニアや PdM には何も伝わりません。Figma の調査は、その一語のままでいいと暗に肯定してしまっているようにも見えます。デザインには直感や感覚でしか説明できない部分が多いものの、それに甘えて言葉で伝えられる範囲まで曖昧にしてしまっていることがあるかもしれません。

Figma の調査は、デザイナーの現状を切り取った貴重な情報です。しかし、そのデータが伝えているのは「デザイナーは間違っていない」という結論ではなく、私たち自身の内にある未解決の矛盾だと思います。まずは自分にとって「クラフト」が具体的に何を意味するのかを問い直すことが、矛盾をほどく出発点になるはずです。

新しいAIモデルの登場や新機能の発表を見て、不安や焦りを感じたことはありませんか？

SNSに流れてくる「週末でアプリを作った」という投稿を見て、自分は遅れているのではないかと不安になったことがあると思います。AIを日常的に使っている人でさえ、この感覚から逃れられません。すでに活用している立場であるにもかかわらず、十分ではないと感じてしまう。この漠然とした焦りの正体は、一体何なのでしょうか。

AIによって効率化が進み、様々なことが変わり始めているように見えますが、現実はもう少し複雑です。 Goldman Sachs の調査によると、AI導入と生産性の間に、経済全体レベルでは有意な関係が見られなかったそうです。コーディングやカスタマーサービスのように効果がみられた領域はあるものの、それでも30%くらいの向上です。

Goldman finds ‘no meaningful relationship between AI and productivity at the economy-wide level,’ but a 30% boost for 2 specific use cases | Fortune

Have you got “AI-nxiety?” Goldman took a closer look at the last earnings season and found a mismatch between hype and reality.

FortuneNick Lichtenberg

6,000人のCEOを対象としたNBERの調査でも同じ傾向が見えます。大多数がAIの雇用・生産性への影響はほぼないと回答しました。MIT Media Labの報告では、95%の組織で測定可能なリターンが出ていないとされています。

2025年から2026年にかけて「AIによって従業員削減」と発表する海外のテック企業が増えています。 しかし、実際はコロナ禍での オーバーハイヤー や買収に伴う組織再編が背景にあるケースも少なくありません。最近だと、Block のニュースが好例です。記事見出しに「AI」と書かれると、原因がAIであるかのように受け取られ、不安が広がってしまうことがある。

AIに意味や効果がまったくないわけではありません。実際に起きている変化は、静かでゆっくりとしたものです。それにもかかわらず、私たちはなぜ焦った気持ちになるのでしょうか。

不安を作り上げているのは、AIではなくコンテンツ

SNSに流れるAI関連の投稿には、共通の偏りがあります。例えば「これで生産性が10倍になりました」みたいなテクニックやツールは、デモであって実務での光景ではないという点です。「AIでデザインが完成」という投稿の裏には、プロンプトの試行錯誤や人間の手直しがありますが、その過程は共有されません。「AIシアター」 といった表現が示すように、本当に使えているかがではなく、 あたかも本当の業務で支えているかのように見せる演出が多く見られます。

ただし、そうした大げさな表現はSNSのアルゴリズムに好まれるため、タイムラインはAIによる演出で埋め尽くされがちです。見た目は情報提供でも、多くは発信者の立ち位置を示すための発信です。「AIでこれができた」のようなコンテンツは情報共有ではなく、「私はあなたより先にいる」という暗黙の宣言です。受け手がそこから受け取るのは知識ではなく、「遅れている」という感覚が残ります。

最近、SNSでデザイナー同士が「Figmaは必要か不要か」と議論しています。 その議論には「遅れている」という単純な不安だけでなく、もっと複雑な不安感が絡んでいます。

AIの話題で時折「職を失う恐怖」が挙げられますが、実際はアイデンティティを失う恐怖に近いと思います。研究者たちはその状態を「アルゴリズミック・アンクザイエティ (Algorithmic Anxiety)」と呼んでいます。長年かけて磨いたスキルが一夜にして価値を失うという感覚が、自分の失敗ではなく、アルゴリズムの進歩によって起こっているという現象です。 FIgma に関する議論で漠然とした不安を感じるのも、ツールが私たちデザイナーのアイデンティティの一部だからとも考えられます。

The Age of Algorithmic Anxiety

Interacting online today means being besieged by system-generated recommendations. Do we want what the machines tell us we want?

The New YorkerKyle Chayka

従来のFOMO（Fear of Missing Out / 見逃す恐怖）との決定的な違いがあります。World Economic Forum のレポートでは FOBO（Fear of Becoming Obsolete）という言葉が紹介されています、FOBO は、見逃しではなく陳腐化の恐怖です。FOMOが「情報や機会を取りこぼすかもしれない」という焦りであるのに対し、FOBOは「自分という存在が不要になるかもしれない」という不安です。

デザイナーとして、エンジニアとして積み上げてきた「自分は何者か」という感覚に、AIが疑問符をつけ始めています。「このまま同じツールを使っていて良いのか？」「なぜ自分の作り方が本当にダメなのか？」「周りはどんどん生産的にモノを作れているのか？」そんな問いがさらに不安を助長します。周りはどんどん効率的にAI活用しているように見えるのに、なぜか自分は遅くなっているように感じてしまうこともあります。

先述したように、AIはまだ経済全体の生産性を大きく変えていません。しかし、SNSやメディアを見ると、あたかも今すぐ大きな変化が起こるかのように受け取られがちです。成功のハイライトだけが切り取られ、プロセスや失敗を省略し、変革がすでに起きたかのような印象を作り出しています。

この漠然した印象が、私たちのアイデンティティへの不安へ侵食していきます。つまり、焦りのや不安の原因は、AI技術の進歩そのものではなく、「AI技術の進歩についてのコンテンツ」と「自分が何者であるかという不安」の掛け算とも言えます。

自分のペースと関係性を見つけよう

理由が分かっても、不安がすぐに消えるわけではありません。「SNSを見ない」「AIの利用をやめる」といった極端な対処法も効果がないことが多いです。 情報に偏りがあると理解しても、「自分が陳腐化するかもしれない」という不安は自然に消えることはありません。

正直なところ私も明快な答えは持っていませんが、最近は「70%ルール」をつかって気持ちを調整しています。

素晴らしいAI活用事例はすぐに使える優れたワークフローに見えますが、それらを目標にして90〜100%を目指すと、いつまでも到達できないばかりか「なぜ自分はできないのか」と不安が強くなります。AIが生成するものは 70% くらいの完成度を目指し、そこから自分で考え、手を動かして調整するようにしています。実際、この記事のドラフトは AI に書いてもらいましたが、構成や文体は書き換えていますし、伝えたいメッセージは自分で考えて書いています。

他にもいろいろ AI を使ったワークフローを作ってありますが、「どうせ70%だから」という理由で自分の目で確認する癖がついています。 AIだけで完結しないという前提を置くことで、「これで十分か」「これは省いてよいか」「ここからどう展開すべきか」といった判断をする機会が生まれます。 こうした判断は単にプロンプトやルールで作れるものではなく、私たちの感覚や経験によって培われるものです。

大事なのは、AIという道具を使って効率化することではなく、今の自分にとってちょうど良い付き合い方はどのようなものかを探ることです。 最近の『AI疲れ』は、物事の速さだけが問題なのではなく、周囲が大きく変わっているように感じられることが主な原因です。 70%ルールは、そんな周囲との距離の置き方にも適用できます。 周囲との距離を適度に保ち、自分とAIとのちょうど良い関係を探ることに集中することで、不安感はある程度和らぎます。

しかも、この問題は見た目だけに留まりません。ずれた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字型などの人材モデルは、キャリアやスキル開発を考えるきっかけにはなりますが、目標そのものではありません。大切なのは、今の職場にどのような課題があるのか、何をすれば少しでも前進できるのかという視点です。そういう意味では、ユーザーの立場に共感しながら課題を解決する日々のデザイン業務と、大きくは変わらないかもしれません。

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