SANAAの《Grace Farms》とペーター・ツムトアの《テルメ・ヴァルス》を見ていると、建築が場所に「置かれている」のではなく「生えている」ように感じられます。その感覚から、設計の想像力について考えます。

良い習慣をつけてもらおうとすると、私たちはすぐに管理の方向に走るように思います。

やるべきことを整理する。
忘れないように通知する。
進捗を記録する。
完了したかどうかをチェックする。

それは、「正しい」。実際、多くの場面で役に立ちます。
特にデジタルサービスでは、こうした管理の仕組みはつくりやすく、分かりやすく、説明もしやすい。

けれど最近、その正しい管理に息苦しさを感じつつあります。

正直なところ、私は、ToDoを管理されたいわけではない。
毎日きっちりやるべきことを提示され、できたかどうかを確認され、抜け漏れを指摘されたいわけでもない。
ごちゃごちゃうるさいものからは距離をとりたくなる。

—

そんな素朴な感覚を肯定するような、少し違う角度から助ける道具があったらよいかもしれない。
行動を縛らない、強い習慣化を求めないもの。
管理されているという感覚をもたせないもの。

そんな、気にかけるくらいの傾斜をもったツールです。

ToDoにすると、失われるものがある

もちろん、ToDo管理が悪いわけではありません。

仕事の抜け漏れを防ぐ。
期限を守る。
複数人で進捗を共有する。
やるべきことを分解し、前に進める。

そうした場面では、ToDoはとても有効です。

ただ、人の暮らしのすべてが、ToDoに向いているわけではありません。

植物を育てること。
散歩すること。
本を読むこと。
誰かを気にかけること。
自分の体調と付き合うこと。

こうした営みは、やるべきこととして管理された瞬間に、少し別のものになってしまうことがあります。

たとえば、植物の世話を考えてみます。

水をやる日。
肥料をやる日。
植え替えのタイミング。

それらをToDoにして、通知し、チェックできるようにすることはできます。

「今日は水やりの日です」
「肥料をあげましょう」
「このタスクは完了しましたか」

たしかに便利そうです。
けれど、その瞬間に、植物との関係は少し仕事に近づいてしまう。
できなかった日は、負債になる。
通知を無視すると、少し後ろめたくなる。
開くたびに、やれていないことを思い出す。

本来は、植物の変化を見ること自体が楽しかったはずです。
少し葉が増えている。昨日より背が伸びている。新しい芽が出ている。
逆に、少し元気がないようにも見える。

ルールベースにすると、どうもそうした変化を見るより、TODOをこなすことに向かってしまう。
そこに違和感がありました。

実践としての『Plant Care』という小さなサービス

その考えを小さく試しているのが、最近形にしてみた『Plant Care』というサービスです。

Plant Care サンプル画面：
https://plant-line-bot-forme.vercel.app/share/e66f00d8-ae82-42c9-99ad-d133456d8cb6

Plant Careは、植物の世話を毎日のタスクとして管理するアプリではありません。
水やりを完了したかどうかを厳密に記録するものでもありません。

植物の種類を入れる。
写真を残す。
気になったときにヒントを見る。
必要なら、LINEから写真を送ったり相談したりする。

やっていることは、それくらいです。

写真を撮ることも、入力作業というより観察に近いものです。
変化を見ること自体が楽しいので、写真を撮ることはそれほど苦ではありません。
むしろ、植物との関係をほんの少し見つめ直す時間になります。

返ってくるものも、管理表ではなく、ジャーナルのようなものにしたいと思いました。

「今日のベランダは、こんな感じでした」
「この植物は少し元気そうです」
「こちらは少し気にしてもよいかもしれません」
「土の乾き具合も、ついでに見てみるとよさそうです」

そのくらいの声かけでいい。

管理されるというよりは、誰かが一緒に庭を眺めてくれるようにしたかった。

サンプル画面には、ベランダで育てている植物が並んでいます。
それぞれのカードには、置き場所や植えた時期、過去写真、ちょっとしたケアメモが添えられています。

ただし、画面は「今日のタスク一覧」ではありません。

Today’s pickでは、その日少し目を向ける植物が一つ選ばれる。
Care summaryでは、葉色、虫食い、土の乾き具合など、軽く見ておくと安心な観察ポイントがまとめられる。

「やりなさい」ではなく、「少し見ておくと安心です」。

それくらいのものを作ってみたかったのです。

気にかけるくらいの傾斜

ここで考えているのは、大きく行動を変える仕組みではありません。
「毎日必ず開く」「連続記録を伸ばす」「通知で戻ってきてもらう」といった、強い行動変容ではありません。

もっと小さなもので、「気にかけるくらい」の傾斜をつくることです。
強い義務ではないけれど、無関心でもない。
毎日完璧に向き合うわけではない。
でも、なんとなく気になって様子を見る。
少し変化があると嬉しい。
危うそうなら、少し手を入れる。

これくらいの曖昧さを壊さない、という挑戦をしたかった。

管理ではなく、手放す・ゆだねる

考えてみたかったのは、管理する設計ではなく、手放す設計です。

サービスが、利用者の行動をすべて引き受けようとしない。
次に何をすべきかを、細かく指示しすぎない。
正解に向かって、一直線に誘導しすぎない。

ただし、それは何もしないということではありません。

完全に放っておくのではなく、少し見やすくする。あるいは、見方を示す。
気づきやすくする。
迷ったときには、そっと助言する。
危うそうなときには、少しだけ声をかける。

でも、最後の関わり方は利用者に残しておく。ゆだねてしまう。

以前も書いたことがありましたが、この「ゆだねる」という感覚が大事なのではと思います。（過去投稿）

指示をしてもらうのは便利で楽かもしれませんが、息苦しい。

使う人が、自分のペースで関われること。
サービスが、すべてを管理しきらないこと。
それでも、関係が途切れにくくなるように、ほんの少しだけ場を整えること。

そういう道具になったら、と思いながら形にしてみました。

行動支援ツールは、管理者でなくていい

望ましい行動を「理想ジャーニー」として定義し、それに近づける強い行動変容支えるチャレンジも肯定されるべきです。それはそれでよいのです。

ただ、行動を支える仕組みが、いつも先生や監督者である必要はありません。
行動を最適化し、ユーザーを導く存在でなくてもいい。

ときには、一緒に眺める存在でいいのではないかと思います。

追記

このポストで紹介したPlant Careは、まだ試作に近いものですが、もう実際に使えるところまでは作り込んでいます。無料で使えるので、ベランダや室内で植物を育てている方がいれば、気軽に触ってみてもらえるとうれしいです。

Plant Care：
https://plant-line-bot-forme.vercel.app/

UXの仕事では、「ペインを捉える」という言葉をよく使います。

ユーザーは何に困っているのか。
なぜ、その行動がうまくいかないのか。
どこに支援の余地があるのか。

この問いはとても大切です。
ただ同時に、ここには落とし穴もあると感じています。

それは、ペインを見つけるつもりで、いつの間にか“もっともらしい物語”をでっち上げてしまうことです。

たとえば、ベランダで植物を育てている人がいるとします。

植物について詳しくない。水をいつあげればいいかわからない。日当たりが足りているのか判断できない。葉の色が変わったとき、それが危険信号なのかどうかもわからない。

このとき、私がまず捉えたいのは、

植物の世話をしたいのに、知識が足りず、うまく行動できない

という素朴な機能不全です。

ところが、この話を整理していると、時々こんな解釈が出てきます。

本当のペインは、花を枯らしてしまう罪悪感にある

もちろん、完全に間違いではないのかもしれません。
植物を枯らしてしまえば、罪悪感を抱く人もいるでしょう。
愛着や不安や、自分はちゃんと育てられないのではないかという感情もあるかもしれません。

ただ、こうした内面に入り込むようなペインの拾い上げは、どうも生活になじむツールづくりにフィットしないように感じます。
「だから、どう役立つものがつくれるの？」
という投げかけに対して筋道がたった仮説を立てにくい。

この内面に注目するというスタンスは、観察されていない物語を、設計者の側が勝手に作ってしまうということにもつながります。

しかもその物語は、たいてい少しだけ真実を含んでいる。
だから厄介です。

少し当たっているから、深い洞察のように見える。
インサイトらしく聞こえる。
人間理解があるように感じられる。

でも、その物語が先に立つと、本来見るべきだったものがぼやけます。

何ができないのか。どこで迷っているのか。どの判断が止まっているのか。何があれば、次の行動に移れるのか。

つまり、行動のからくりです。

私は、UXデザインは、美しいコピーライティングではなく、機能性のある仕掛けだと思っています。

もちろん、言葉や感情を扱わないという意味ではありません。
ただ、設計者が最初に見るべきなのは、ユーザーの内面を文学的に読み解くことではなく、行動がどこで止まり、どうすれば自然に動き出すのかという機構です。

水やりのタイミングがわからない。
判断基準がない。
変化に気づけない。
気づいても、何をすればいいかわからない。

そうした小さな力学を見ていく。

そこに必要なのは、感動的なストーリーではなく、からくりを正しく捉える目線です。

そして、からくりをきちんと作っていくことが、意味のある仕組み、アーキテクチャになるのだと思います。

よいUXは、ユーザーの感情を勝手に代弁することから生まれるのではありません。

むしろ、うまく行動できないという機能不全を、素朴に、正確に捉えることから始まります。

生活者の内面を詩的に描写するようなワークは、後から慎重に扱えばいい。
でも最初にそこへ飛んでしまうと、設計は現実から離れていきます。

AI時代には、この危うさがさらに強まる気がしています。

AIは、もっともらしい意味づけが得意です。
小さな行動の詰まりを、きれいな物語に変換することができます。

だからこそ、設計者の側には、逆の力が必要になります。

深読みしたくなる気持ちを抑える。内面を想像した解釈に飛びつかない。
まず、行動の詰まりをそのまま見る。

設計者が勝手にありもしない物語をでっちあげることは害悪にさえなりえます。

私たちがまず向き合うべきなのは、その人が現実の中でうまく行動できなくなっている場所です。

そこに小さな道を通す。
判断できるようにする。
迷わず動けるようにする。
無理なく続けられるようにする。

そうして行動のからくりを整えていくこと。

それが、UXを「それっぽい物語」ではなく、本当に機能する仕組みに近づけていくのだと思います。

AIやClaude Codeのようなツールを使っていると、「これ、何時間で作りました」「週末だけでここまでできました」といった話をよく見かけます。

もちろん、それ自体が悪いわけではありません。

以前なら数日かかっていたものが、数時間、場合によっては数十分で形になる。画面ができる。動くものが出てくる。その変化は、たしかに大きい。ファーストアウトプットが速く出ることには、はっきり価値があります。

ただ、その「何時間でできた」こと自体を誇る空気には、どこか違和感があります。

なぜなら、UX改善という観点で本当に重要なのは、最初のアウトプットがどれだけ速く出たかではないからです。

大事なのは、その後です。

最初に出てきたものを触り、違和感を覚え、その理由を考え、言葉にし、もう一度画面に戻す。そのサイクルを、何回転できるか。

より本質的なのは、作って、触って、違和感を覚え、その理由を考え、もう一度画面に戻すまでの回転数が、桁ごと変わることです。

UX改善は、違和感から始まる

UX改善とは、何かをつくって終わりではありません。

むしろ、つくったあとに始まる仕事です。

実際に触ってみる。日常の中で使ってみる。そこで、「なんか違う」「ここで止まる」「気持ちよくない」「意味はわかるけど、使いたくならない」といった違和感が生まれる。

その違和感は、最初はたいてい言葉になりません。

ボタンの位置が悪いのかもしれない。文言が硬いのかもしれない。導線が遠いのかもしれない。あるいは、もっと根本的に、その機能が置かれている文脈や、使い手との関係性がずれているのかもしれない。

UX改善の仕事は、この違和感をただの感想として流さず、原因を探ることにあります。

表面で見つかるなら、表面を直せばいい。けれど、どうもそれだけではないと感じるなら、もっと深く潜る必要がある。使われる状況、生活の流れ、利用者の気持ち、提供者側の都合、行動の前提。そうした見えにくいところまで降りていって、そこからもう一度仕組みを更新する。

この営みこそが、UX改善なのだと思います。

価値は、3つの「短さ」にある

AI時代のUX改善で大きく変わったのは、この違和感を中心にしたサイクルの速度です。

特に価値があるのは、次の3つの時間が短くなることです。

1つ目は、アウトプットが出てから、違和感を捉えるまでの時間の短さです。

頭の中で考えているだけでは、違和感はなかなか立ち上がりません。仕様書やワイヤーフレームを見ている段階では、よさそうに見えることも多い。けれど、実際に画面になり、触れる状態になると、急に身体が反応します。

「あれ、ここで迷うな」 「この順番だと気持ちが乗らないな」 「機能はあるけれど、使う理由が弱いな」

企画書のレベルではなく、手に取って触れるもの、暮らしの中で使ってみることのできる「動くもの」が早く出てくるほど、この違和感に早く出会えます。

2つ目は、違和感を言葉にするために、こねくり回す時間の短さです。

違和感は、感じた瞬間にはまだ曖昧です。それを「なぜそう感じたのか」「何が引っかかっているのか」「これはUIの問題なのか、構造の問題なのか」と考える必要があります。

このとき、AIは単に答えを出す道具というより、違和感を言語化するための壁打ち相手になります。

「この画面、なんか重い」 「なぜ重く感じるのか」 「情報量か、順番か、期待とのズレか」 「そもそも、この場面でユーザーは何をしたいのか」

こうして何度も言葉をぶつけ、組み替え、掘り下げることで、曖昧だった違和感が少しずつ輪郭を持ち始めます。

3つ目は、違和感を言葉にしたあと、それがもう一度画面に出てくるまでの時間の短さです。

これが特に大きい。

以前なら、「違和感の原因がわかった」としても、それを修正して画面に反映するまでには時間がかかりました。デザイナーに伝え、エンジニアに依頼し、優先度を調整し、実装を待つ。その間に、違和感の熱は少しずつ冷めていきます。

しかし今は、言葉にした違和感を、そのまま次の画面に反映しやすくなっている。

「ここは説明ではなく、先に結果を見せたい」 「この導線は、ユーザーが迷わないように一段減らしたい」 「この機能は前面に出すより、使いたくなった瞬間に出したい」

そうした仮説を、すぐに形に戻せる。

そしてまた触る。また違和感を得る。また言葉にする。また画面に戻す。

この回転が速くなることに、本当の価値があります。

「何時間で作ったか」より、「その後に何回転したか」

ファーストアウトプットが速いことは、もちろん意味があります。

早く形になるから、早く触れる。早く触れるから、早く違和感が出る。だから、最初の出力速度は、回転を始めるための条件としては大切です。

でも、それはあくまでスタート地点です。

「何時間でここまで作りました」という話は、しばしばそのスタート地点だけを成果のように見せてしまいます。けれど、UX改善の品質は、最初に出てきたものの速さでは決まりません。

だからこそ、AIを使う側には、回転数を上げるという意識が必要になります。速く作れることに満足してしまうと、アウトプットの量は増えても、体験の質は十分には磨かれません。触って、違和感を捉え、言葉にし、もう一度形に戻すところまでを一つの単位として扱う必要があります。

むしろ、そこから何回触ったか。何回違和感を見つけたか。何回言葉にし直したか。何回画面に戻したか。

その回転数によって、体験は磨かれていきます。

だから、AIによって変わったのは、制作速度だけではありません。

むしろ重要なのは、一度外に出したものが、違和感を経由して、もう一度改善案として戻ってくる速度です。

作る。触る。違和感を覚える。言葉にする。直す。もう一度触る。
この一周が短いほど、UXの品質は上がっていきます。
なぜなら、UXの質は、最初のアイデアの美しさだけで決まるものではないからです。実際に触れたときに生まれる小さなズレを、どれだけ早く、どれだけ深く、どれだけ何度も扱えるかによって磨かれていく。

違和感は、失敗のサインではありません。
むしろ、改善の入口です。
そして、その入口に何度も戻れること。戻るためのコストが低いこと。戻ったあと、すぐにまた形にできること。

ここに、AI時代のUX改善の大きな可能性があります。

動くものを、日々の暮らしで試せること

これまでのUX改善でも、調査をし、仮説を立て、プロトタイプをつくり、検証するという流れはありました。

けれど、その多くは、動くものになるまでに時間がかかりました。日々の暮らしの中で自然に試せる状態にたどり着くまでに、距離がありました。

いま起きている変化は、そこが決定的に違います。

動くものをすぐにつくれる。日々の中で触れる。触った瞬間に違和感が立ち上がる。その違和感をすぐに言葉にし、すぐに次の形に戻せる。

これは、単なる効率化ではありません。

UX改善の回転数が、桁ごと変わるということです。

そして、その回転数の変化こそが、いま起きているもっとも重要なイノベーションなのだと思います。

違和感に何度でも戻れる人が、品質を上げていく

UX改善の核は、完成品を一度でつくることではなく、触って、感じて、考えて、直すという繰り返しのプロセスにあります。

実際に使いながら、表面の問題だけでなく、奥にある構造のズレにも気づいていく。利用者の行動、生活の流れ、気持ちの動き、仕組みの前提。そうしたものを少しずつ捉え直しながら、体験を更新していく。

AI時代に本当に価値を持つのは、最初から正解を出せる人ではなく、違和感に何度でも戻れる人なのだと私は思います。
そして、その違和感を曖昧なままにせず、言葉にし、また形に戻し、何回転もさせられる人。

UX改善において、これほど大きな武器はないはずです。

何時間で作ったかよりも、その後に何回転できたか。

そこに、これからのUX改善の本当の価値があるのだと思います。

「壊れにくい」だけでは足りない

タレブの『反脆弱性』という本を、最近少しずつ読んでいます。
癖の強い本です。文章も、主張も、ところどころかなり強い。けれど、読み進めていると、妙に残る考え方があります。

反脆弱性。

壊れにくい、という意味ではありません。

壊れにくいものは、ただダメージに耐えるものです。揺れても倒れない。叩かれても壊れない。もちろん、それも強さの一つです。
けれど反脆いものは、少し違います。
揺らされることで、むしろ強くなる。傷つくことで、次の変化に適応していく。小さな失敗や摩擦を取り込みながら、かえってよくなっていく。ヒュドラの首が1本切れたら2本生えてくるように。

そんなタレブの考え方に触れながら、とくに組織運営に関する部分が印象に残ったので少し考えを残しておきます。

組織運営では、ロスの少ない道がよく見える

ここで「組織はもっと大胆であるべきだ」といった、外側からの勇ましい話をしたいわけではありません。

実際に組織を動かす側にいると、大胆さだけでは済まない現実がいくらでもあります。

方針を変えると、関係者への説明が必要になります。
既存の計画との整合を取らなければならない。
予算や人員の再配置も起きる。
誰に、どの順番で、どう伝えるかも考えなければならない。

ひとつの判断を変えるだけでも、その背後には多くの調整が発生します。

だから、組織の中で慎重になることは、決しておかしなことではありません。むしろ、その場にいれば当然の感覚だと思います。

説明責任を果たすこと。
関係者の納得を得ること。
余計な混乱を起こさないこと。
既存の約束を乱さないこと。
限られた予算と時間の中で、できるだけロスを少なく進めること。

どれも、その状況においては十分に正しい。

組織の中で慎重に判断している人たちを、外側から悪く言ったり、下に見たりすることには意味がないと思っています。そこには、そこで働く人たちの現実があり、その状況なりの正しさがあります。

ただ、その正しさを内側から眺めていると、別の危うさも見えてきます。

正しい判断が積み重なると、大きく試せなくなる

運営上のコストがよく見えすぎると、大きく向きを変えることに躊躇が生まれます。

いま大きく方針を変えれば、相応の混乱が起きる。
うまくいかなかったとき、説明が必要になる。
戻すにも手間がかかる。
関係者を巻き込んだ以上、簡単には「やっぱり違いました」とは言いにくい。

そう考えると、人は自然に、いちばんロスの少ない道を選ぶようになります。

誰かが強く止めたわけではない。
誰かが「挑戦するな」と命じたわけでもない。

それでも、気づくと摩擦の少ない道が選ばれている。

自分たちで決めているようでいて、実際には、状況に決めてもらっている。

説明しやすいほうへ。
合意を取りやすいほうへ。
あとから責められにくいほうへ。

その選択は、一つひとつを見ると、たぶん間違っていません。

けれど、それが続くと、組織はだんだん「大きく試す」ことから遠ざかっていきます。

タレブの議論に引き寄せて考えるなら、ここに中央集権的な安定の危うさがあるのだと思います。

中央で方針を決め、全体を揃え、計画通りに進める。

それは平時には、とても合理的に見えます。

内部的な説明もしやすく、資源配分もしやすい。全体として何をしているのかも語りやすい。
組織が大きくなればなるほど、そうした安定は必要になります。誰もが好き勝手に動けばよい、という話ではありません。

ただ、波が大きくなると、その安定は別の顔を見せます。

中央が状況を読み切れなくなる。
現場の小さな違和感が、方針に反映されるまでに時間がかかる。
一度決めた計画を変えるコストが高くなり、変えたほうがよいと分かっていても、変えにくくなる。

つまり、平時には「安定」として機能していたものが、変化の大きい時代には「慣性」になります。

波が大きくなると、安定は慣性に変わる

これは、「波が来れば揺れる」というだけの話ではありません。

むしろ怖いのは、中央集権的な安定が、波を見えにくくすることです。

現場では、小さな変化が起きています。

顧客の反応が少し変わる。
使われ方がずれる。
以前なら通用した説明が、通用しなくなる。
自分たちが価値だと思っていたものの置きどころが、少しずつ変わっていく。
小さな違和感が、あちこちに出てくる。

けれど、中央で整えられた計画は、それらをすぐには扱えません。

なぜなら、小さな違和感は、説明しにくいからです。

まだ数字になっていない。
まだ失敗とは言えない。
まだ方針を変えるほどの材料ではない。

そうしているうちに、違和感は「ノイズ」として処理されます。

平時には、それでよかったのかもしれません。
ノイズをいちいち拾っていたら、組織は進まない。中央で決めた方針に沿って、多少の揺れを抑えながら進むほうが、効率がよい。

でも、環境の変化が大きくなると、ノイズの中にこそ次の兆しが混ざり始めます。

そのとき、中央集権的な安定は、組織を守る力であると同時に、兆しを捨てる力にもなってしまう。

タレブが繰り返し警戒している脆さも、こういうところに現れるのではないかと思っています。

波が高いときこそ、強くリードすべきなのか

よく言われる「べき論」は、
「波が大きいときこそ、強いリーダーシップが必要」
「迷いを断ち切り、中央が大きく方向を示し、組織全体を一気に動かすべき」
のようなものだと思います。
実際、その感覚はよく分かります。
不確実性が高いときほど、人は「決めてほしい」と感じます。方針が見えない状態は不安ですし、現場がそれぞれ別々に動けば、混乱も生まれます。だから、中央が状況を読み、強く進路を示すことには、確かに意味があります。

ただ、それでもなお、少し疑ってみたいのです。

波が大きいときに本当に必要なのは、中央がもっと正しく、大きく操舵することなのだろうか。
むしろ、そもそも大きく操舵しなければ変われない組織設計そのものが、波の大きい時代には脆いのではないか。

タレブの議論を借りれば、問題は「未来を読み切れないこと」そのものではありません。
未来を読み切れないにもかかわらず、中央が読み切れる前提で組織を動かしてしまうことです。

タレブのいう「反脆さ」を組織に引き寄せて考えるなら、むしろ、未来を読み切れないことを前提に、小さな単位で試せる組織が強い。

失敗しても全体が壊れない。
損失は小さく閉じる。
一方で、うまくいった試みは大きく育てられる。

そのためには、挑戦のすべてを中央承認の対象にしないことが重要になります。

現場の小さな違和感や仮説を、最初から全社方針や投資対効果の言葉に翻訳させると、試す前に生命力が失われてしまう。

階層が多く、小さな挑戦が上に上がる途中で丸められる組織は、平時には安定して見えます。

けれど波が大きくなると、現場の違和感を試す前に失っていく。
これは、脆い組織です。

必要なのは、より強い統制ではなく、小さく揺れられる地形

では、どうすればいいのか。

まだ自分の中で完全に整理できているわけではありません。ただ、タレブの本を読みながら考えているのは、より強いコントロールではなく、もう少しゆだねることの重要性です。

小さな単位で試す。
現場の違和感を拾う。
いくつかの仮説を並走させる。
うまくいったものが自然に残り、合わなかったものが静かに消えていく。

全体を一つの方向に強く動かすのではなく、複数の小さな揺らぎを許し、その中から次の形が立ち上がるのを待つ。
そういう組織のほうが、揺れに強いのかもしれません。

「失敗を許容する文化が大事だ」とはよく言われます。
それはその通りです。ただ、言葉として「失敗してもいい」と言うだけでは、おそらく足りません。
もし失敗したあとに戻すコストが高いままなら、人は試しません。
もし方針変更の説明が重すぎるなら、人は最初から無難な案を選びます。
もし評価が短期の成果だけに寄っているなら、人はアップサイドよりも減点回避を選びます。

波の大きい時代に危ういのは、間違える組織ではありません。
間違える前に、試す芽を潰してしまう組織です。

小さく試し、小さく失敗し、うまくいったものだけが大きくなる余白を残しておくこと。
そのほうが、波の大きい時代には強いのだと思います。

今は、反脆い組織とは何かを考える、とてもよいタイミングなのだと思います。

波が大きくなり、仕事の前提や価値の置きどころが揺らぎはじめると、組織の脆さは表に出てきます。

どこで試す芽が潰れているのか。
どの違和感が、まだ言葉になる前に捨てられているのか。
そうしたものが、以前よりも見えやすくなる。

だからこそ今は、反脆い組織をどうつくるかを模索するには、素晴らしいタイミングなのかもしれません。

揺らぎが大きい時代だからこそ、揺らぎを消すのではなく、揺らぎから学ぶ組織をつくる。
中央が未来を読み切るのではなく、あちこちで生まれる小さな兆しを、次の形へ育てていく。

それは、単なる組織改革ではなく、これからの時代における「強さ」の定義を問い直すことなのだと思います。

揺れないことではなく、揺れながら強くなること

中央集権的な安定は、平時には組織を強く見せます。けれど、波が大きくなると、その安定は、変化を受け止める力ではなく、変化を遅らせる慣性として現れることがある。

タレブの反脆弱性から受け取っているのは、おそらくこの感覚です。

強い組織とは、揺れない組織ではない。
小さく揺れながら、その揺れを学びに変えられる組織なのだと思います。
揺らぎを消すことで安定するのではなく、揺らぎを取り込みながら形を変えていく。

今、組織に必要なのは、揺れない強さではなく、揺れを取り込む強さなのかもしれないと感じています。

最近、自分で作ったClaude Skillsを使いながら、少し不思議な感覚を覚えています。

便利だな、というよりも、懐かしいな、という感覚です。

何が懐かしいのかというと、フィードバックの厳しさです。しかもそれは、表現やロジックに対する厳しさではありません。もっと手前にある、「ちゃんと現実を見たのか」という厳しさです。

何かをレビューしてもらうと、こちらが考えた仮説や改善案に対して、すぐに評価を返してくれるわけではありません。

むしろ、まず問われます。

それは本当に観察したのか。
事実に触れたのか。
一次情報はあるのか。
実際に使った人の反応を見たのか。

さらに、そこにはもう少し強い含意があります。

現実を見ていないのであれば、そもそもフィードバックには意味がない。
そのくらいの厳しさで、こちらの思考を押し戻してくるのです。

この感覚が、私には妙に懐かしく感じられました。

「一次情報に触れよ」という原則を登録したので、こう返してくれるのも当然といえば当然なのですが、言葉の強さも含めて、現代っぽくはありません。

昔は、こういうことを言う人がもう少しいた気がします。
「それはファクトなの？」
「その仮説は、観察から来ているの？」

そうやって、考える前に現実へ戻される。議論を始める前に、まず見に行かされる。フィードバックの場も、前提が整っていなければもってもらえない。

少し面倒で、少し怖くて、でも結果として仕事の質を支えていたような厳しさです。

最近は、そういうタイプのマネージャーがずいぶん減ったように感じます。
理由は分かります。強く言えば関係性が傷つく。場の空気も悪くなる。心理的安全性という言葉もあります。何より、厳しく問い続ける側も疲れます。

人間のマネージャーは摩耗します。
何度も「調査したのか」と言うのは、案外しんどいことです。言われた側の反応も受け止めなければいけません。だから少しずつ丸くなる。あるいは、最初から言わなくなる。

その点、AIは摩耗しません。

何度でも、淡々と聞いてきます。

観察したのか。
根拠は何か。
何が起きたのか。

しかも、それは人格的な圧としては受け取りにくい。人間に言われれば反発したくなることでも、AIに言われると、少し距離を置いて受け取ることができます。

ここに、AIによるマネジメントや助言の面白さを感じています。

AIは、答えをくれる存在として語られることが多いです。文章を書いてくれる。アイデアを出してくれる。実装を手伝ってくれる。もちろん、それは大きな価値です。

けれど今回感じたのは、また別の価値、「知的規律を、もう一度こちらに返してくる存在になりうるのではないか」という点です。
特にUXやサービスづくりの仕事では、本当に大事なのは、きれいなコンセプトをつくることだけではありません。むしろ、現実を見ることです。使っている人を見ることです。自分の思い込みが外れる瞬間に耐えることです。

その地味で、手間がかかり、時に痛みを伴う部分を、私たちはつい飛ばしてしまいます。

しかし、そこを飛ばしたままでは、どれだけきれいに考えても、それが本当に体験をよくするのかは分かりません。

AIが単に「もっとよい案」を出してくれるのではなく、そもそも案を評価するための材料が足りていない、と指摘してくる。考えの精度より前に、現実への接触量を問うてくる。それは予期しなかった面白みでした。

もちろん、AIの言うことをそのまま正解にする必要はありません。AIの指摘もまた、ひとつの仮説として扱うべきです。
けれど少なくとも、「調査していないなら判断できない」という当たり前の姿勢を、繰り返し突きつけてくれる存在としては、かなり頼もしい。

人間が失いつつある厳しさを、機械が別の形で補完する。
それは少し皮肉でもあり、同時に希望でもあります。

AIは、私たちの創造性を拡張するだけではないのかもしれません。
AIは私たちに、かつて仕事の中にあった規律を思い出させる存在にもなりえるのかなと感じています。

前回、Claude Skillsを使って感じた衝撃について書きました。（過去投稿）

自分の専門性の一部が、ファイルになって外に出ていく。
しかもそれは、プロダクトの価値を捉え、表層の奥にある「見えないデザイン」を読み取るところまで到達している。
この現実を、まずは受け止める必要がある。
――前回は、そこまでを書きました。

では、その現実を前に、人間には何が残るのでしょうか。

現時点の私の答えは、かなりシンプルです。
現実に触れ、そこから意味のある発見をし続けること。

レビューが外部化されていくなら、これから価値が移るのは、レビューの前にある仕事です。
まだ情報になっていないものを見つけること。
まだ誰も言葉にしていない違和感を拾うこと。
現場に出て、一次情報に触れ、そこから新しい問いを立ち上げること。

そこに、焦点が移っていくのではないかと思っています。

レビューは、すでにあるものを読む仕事

まず、レビューとは何かを考えてみます。

レビューは、基本的には「すでにあるもの」を読む仕事です。

すでに画面がある。
すでに資料がある。
すでに仮説がある。
すでにユーザーフローがある。
すでにプロトタイプがある。

それを読み、構造化し、論点を出し、不明瞭な点や煮詰めが足りない部分をあぶりだす。
フォーカスが効いていないようなら、優先順位をつける。

良いレビューが簡単だと言いたいわけではありません。
ただ、レビューには「対象がすでに存在している」という特徴があります。

AIは、すでにある情報を読む力を急速に高めています。
画面、資料、文章、仮説。
そこにレビューの観点が与えられ、Skillとして整理されていれば、AIは良さとリスクを整理し、次の一手まで出せるようになっている。
前回、私が揺さぶられたのはまさにそこでした。

「すでにあるものをレビューする仕事」は、これからかなり外部化されていく。

もちろん、人間のレビューが不要になるわけではありません。
しかし、「レビューができる」こと自体は、これまでほど強い差別化要因ではなくなっていく気がしています。

では、何が差になるのか。

私は、レビューの手前にあるものだと思います。

何をレビューすべきか。
そもそも何が問題なのか。
どの現実を見に行くべきか。
まだ誰も気づいていない問いはどこにあるのか。

AIは、与えられた情報の中で賢い

AIはとても強くなっています。
ただし、その強さには前提があります。

AIには、何かが与えられている。
資料、画面、調査ログ、議事録、レビュー対象、誰かが言葉にした仮説。
AIは、その中で考えるのが得意です。

一方で、私たちの仕事の本当に難しい部分は、そもそも何を問題として定義するのか、あります。
まだ誰も言葉にしていない違和感。本人も困っていると自覚していない摩擦。当たり前すぎて誰も説明しない習慣。「便利です」と言っているのに使い続けない理由。

こうしたものは、最初から資料になっているわけではありません。

現場に行き、人と話し、使われ方を見て、沈黙を見て、手元を見て、表情を見る。
その中から、「これは問題かもしれない」と感じ取る。

そこから初めて、情報が生まれる。

AIは、情報になったものを扱うのは得意です。
しかし、まだ情報になっていないものを情報として立ち上げる仕事は、簡単には外部化できません。

ここに、しばらくは人間の仕事が残るのだと思います。

一次情報は、材料ではない

UXやサービスデザインの仕事では、一次情報が大事だとよく言われます。
ユーザーに会いましょう。現場を見ましょう。自分で使ってみましょう。
それはもちろん正しい。

ただ、AI時代における一次情報の意味は、少し変わって見えてきました。

一次情報は、単に「正確な材料」ではありません。

もちろん、思い込みを外してくれることはあります。数字だけでは見えない背景が分かることもあります。でも、それだけではありません。

一次情報に触れることは、自分の感覚を更新することです。

現場に行くと、想定していなかったことが起きます。

ユーザは「困っている」とは言わない。
でも、同じところで何度も手が止まる。

「便利ですね」と言う。
でも、その後、使い続けない。

「特に不満はありません」と言う。
でも、実際には別のやり方で回避している。

「慣れれば大丈夫です」と言う。
でも、慣れるまでに多くの人が離脱している。

こうしたものは、表面的な発話だけを見ていると拾えません。

一次情報に触れるとは、言葉になっていない現実に触れることです。
そして、自分の中に違和感を生むことです。

「あれ、思っていたより根が深いかもしれない」
「こんな出し方だと、生活に入らないかもしれない」
「この反応は、継続にはつながらないかもしれない」

そうした感覚は、机の上では育ちにくい。

一次情報は、AIに渡す材料である前に、自分の感覚を鍛える場なのだと思います。

発見は、現実との摩擦から生まれる

発見は、頭の中だけでは生まれにくい。
もちろん、考えることは大事です。仮説を立てることも大事です。
でも、本当に意味のある発見は、現実に触れて、肌で感じるところから生まれることが多いように思います。

プロダクトを前にして当惑している。
言っていることと、やっていることが違う。
便利なはずなのに、使われない。
不便なはずなのに、なぜか残っている。
誰も問題視していないが、よく見ると想定していなかったところにブレーキがある。

こうしたズレに触れることで、問いが生まれます。

その問いは、最初からプロンプトには書けません。なぜなら、まだ自分でも気づいていないからです。
現場に触れて、違和感を覚え、考え直す。そこではじめて、「本当に問うべきこと」が見えてくる。

レビューは、すでにある問いに答える仕事に近い。
発見は、まだ問いになっていないものを問いにする仕事です。
この差は大きい。

そして、これから価値が上がるのは、後者なのだと思います。

調査ができる、だけでは足りない

ただし、「現場に行けばよい」という話でもありません。

現場に行くこと自体はできます。
インタビューをすることもできます。
観察メモを取ることもできます。

でも、現場には情報が多すぎます。

人はたくさん話します。
言葉を拾い上げようとしても、矛盾も混じりますし、本質的な摩擦も、単なる好みも、同じような顔をして現れます。

そこから、何を発見として持ち帰るのか。

これが難しい。

ユーザーが言ったことを、そのまま要件に変えるだけでは足りません。
不満リストを作るだけでも足りません。
発話をきれいに分類するだけでも足りません。

必要なのは、現場で見たものを、設計すべき課題として立ち上げる力ではないかと思います。
これは個人の好みなのか。それとも、多くの人に共通する地形なのか。
これは一時的な不便なのか。それとも、仕組みの前提がずれているサインなのか。
そこを見極める必要があります。

だから、これから強くなるのは、単に「調査ができる人」ではありません。
一次情報に触れ、そこから発見し、その発見をチームやAIが扱える問いに変えられる人だと私は思います。

AIに渡す前の仕事

AIを使うほど、AIに渡す前の仕事が重要になります。

何を見てきたのか。誰に会ってきたのか。どんな場面を観察したのか。どの発言を重要だと感じたのか。どの沈黙に引っかかったのか。どの行動のズレを、問いとして持ち帰ったのか。

ここが弱いと、AIはそれっぽく浅い答えを返します。

表面的な材料を渡せば、表面的な分析が返ってくる。
よくあるペルソナを渡せば、よくある打ち手が返ってくる。
既知の論点だけを渡せば、既知の範囲で整った答えが返ってくる。

AIは文章を整えるのが上手いので、むしろ危険に思います。
浅い材料でも、かなり説得力のある文章になってしまう。

一方で、現場で拾った違和感、本人もまだ言葉にできていない摩擦らしきもの、当たり前すぎて誰も説明していない習慣。
そういった材料をAIに渡せる人は、ものすごく強い。

「発見」をしよう

レビューする能力はAIによってかなり強化されるだけでなく、外部化されていくことは確定的だと思います。
すでにあるものを評価する。すでにある資料を整理する。すでにある画面を改善する。すでにある仮説にフィードバックする。こうした仕事は大切ですが、かなりの部分を機械に任せられるようになっていく。

一方で、まだ誰も言葉にしていない摩擦を見つける仕事、たとえば、生活者自身も気づいていない不便を拾う。誰も問題だと思っていなかったことを、設計すべき問いとして立ち上げる――こうした部分は、まだ簡単には外部化できないように思います。
それは既にある情報を処理する仕事ではなく、何を情報として扱うかを決める仕事だからです。

現実に触れ続ける人が強くなる

AIはこれからさらに強くなるでしょう。
レビューも、整理も、文章化も、かなりの部分が外部化されていくはずです。

それでも、現実に触れ続けることの価値は下がらないと思います。むしろ上がる。
なぜなら、現実に触れ続ける人だけが、新しい違和感を拾えるからです。

過去に言語化された知は、やがて古くなります。Skill化された判断も、放っておけば古くなります。

でも、一次情報に触れ続ける人は、現実の変化に合わせて知を更新できます。
その人は、AIに置き換えられるというより、AIを更新する側に回る。
ここに、希望があると思っています。

Claude Skillsを初めて使ってみて、ぞわっとしました。
いや、もう少し正確に言うと、頭に血が上って動悸が早まるような感じがありました。

「作業が速くなった」という次元ではなく、もっと根本的に、自分の中にあった判断や手順や癖のようなものが、外に切り出され、再利用可能な部品になっていく感じがあったのです。

正直に言うと、AIによって仕事が代替されていくという話を、私はどこか他人事のように聞いていたところがあります。プログラミングを仕事にしてきた人は大変だ、どんな商売になっていくんだろう、と漠然と考えはしましたが、どこかで「自分の専門性の中核は、まだ大丈夫だろう」と思っていたのだと思います。

私は、プロダクトやサービスをみて、暮らしに入り込むためのからくりを読み、作り直すスキルがあります。プロダクトが何を大切にしつづけ、何を直すべきかを見立てることができます。また、具体的な改善にあたってはクリエイターの意欲を折らずに、前に進むための視点と、当面のフォーカスを定めることができます。
こうしたものは、簡単には代替されない。
そう思っていました。

でも、Claude Skillsを触って、その油断が揺らいでいます。
自分の中にある判断の型や、レビューの観点や、編集の癖のようなものが、ファイルとして外に出る。
そして次からは、自分がいなくても呼び出される。

これは、補完というより、代替に近い。
AIが仕事を助けてくれるのではなく、自分の仕事の一部が、自分なしでも動き始める。

その感覚に、当惑しました。
自分が代替されるかもしれないという、かなり根源的な怖さを感じたのです。

Claude Skillsで何が起きるのか

Claude Skillsは、ざっくり言えば、特定の仕事に必要な指示や資料や手順をひとまとまりにして、Claudeが必要に応じて呼び出せるようにする仕組みです。

たとえば、部下に対するレビューの観点、調査品質を保つチェックポイント、プロダクトやサービスを見るときの優先順位、コミュニケーション上の配慮すべき点などをSkillとしてまとめておくと、Claudeはその型を使って仕事を進めます。

いろいろな使い方ができるようですが、私が今回試したのはレビュアーとしての活用です。

もちろん、これまでもプロンプトで似たことはできました。
「この観点でレビューして」と依頼すれば、AIはそれなりに応えてくれます。

ただ、Skillは単発の依頼とは少し違います。

そこには、繰り返し使える「仕事の型」が保存されます。
判断の観点や、手順や、優先順位が、ファイルとして置かれる。

つまり起きているのは、単なるプロンプト改善ではありません。
専門性が、「人に宿るもの」から、「一部はファイルとして保存され、呼び出されるもの」に変わり始めている。

前提：自分の知を読ませていた

今回Claude Skillsに入れてみたのは、この数年、自分がUXやプロダクトについて考え、書いてきた文章です。そうした、自分なりに言葉にしてきた知を、Skillとして参照できるようにしました。

また、この秋に出版予定の最初の書籍の内容も参照できるようにしました。作った仕組みが生活になじんでいくためには、そもそもどんなことを考えるべきか。これまでの試行錯誤をまとめたナレッジをSkillに与えています。

つまり今回起きたことは、Claudeが突然、私の仕事を理解したという話ではありません。
自分が長い時間をかけて言葉にしてきたものを、AIが参照できる形に置いた。
その結果として、その知が「読まれるもの」から「実行されるもの」に変わり始めた。

Claude Skillsは随分まわりの評価も高いので期待はもちろんありましたが、自分が代替される水準とは思っていませんでした。

Claudeがプロダクトの価値を理解している

いくつかのアプリやプロダクトについて、Skillにレビューをさせてみると、どれも興味深い結果でした。
それぞれのプロダクトが何に賭けているのか、どこに強さがあり、どこで体験が途切れているのかを、思った以上に深く読もうとしていました。

ここでは一例として、以前個人ワークとして作ったオタマトーンの練習アプリに対するレビューを紹介します。

https://otamelo.vercel.app

オタマトーンという、少し不思議な電子楽器があります。音符のような形をした、玩具のようにも見える楽器で、触れば音は出るのですが、狙った音を出すのは意外に難しい。私自身、買ってはみたものの、うまく弾けずに挫折した経験がありました。

そこで、大好きな曲を少しずつ練習できるアプリを作ってみました。題材にしたのは「エイトメロディーズ」という、あるゲームの中で流れる印象的な曲です。知っている人にとっては、ただの練習曲ではなく、「いつか自分で弾いてみたい」と思えるような、記憶に残る曲でもあります。

曲を6つのステージに分け、まず音を鳴らし、音名を確認し、フレーズごとに練習し、最後に通して弾いてみる。
そういう、ごく個人的な練習アプリです。

このアプリをSkillにレビューさせたところ、返ってきた内容は、単なるUI改善リストではありませんでした。

説明するより、実際に出てきたものを見てもらったほうが早いかもしれません。

以下は、Skillが返したコメントの一部です。

資産①：「エイトメロディーズ」という選曲の破壊力

なぜ重要か。 楽器練習で最も難しいのは「何のために練習するのか」という動機の維持だ。このアプリはその問いに最初から答えている。「やりたい曲が決まっている人」に向けた設計は、汎用練習アプリが根本的に持てない引力を持つ。MOTHER2のエイトメロディーズは、特定の世代に「ずっと心にある曲」として刻まれており、アプリを開く動機として最強クラスだ。

何のリスクを減らすか。 練習を続けるための外発的動機（やらされ感）ではなく、内発的動機（弾きたい）が最初から存在している。これは多くの楽器支援アプリが解決できずにいる問題だ。

守り方。 将来の機能追加で「汎用的な楽器練習アプリ」に広げようとする誘惑に注意。選曲の絞り込みはバグではなく戦略資産だ。

ここを読んだとき、どこにも明示していない作り手の狙いを、よくここまで言葉にするな、という驚きがありました。

このレビューが見ていたのは、曲名そのものの有名さではありません。
「この曲を弾きたい」という個人的な動機が、練習を続ける理由になるという構造です。

練習アプリは、つい曲数や機能を増やしたくなります。
でも、このアプリの場合、最初から弾きたい曲が決まっていること自体が、生活に入り込むための引力になっている。

だから、「選曲の絞り込みはバグではなく戦略資産だ」という指摘は正しいのです。
どこにも書いていなかった、このプロダクトが何によって成立しているのかを読んでいる。

そして、機能の核心についてはこう書かれていました。

資産④：リアルタイム音名表示が解決する「オタマトーン最大の難所」

なぜ重要か。 オタマトーンを諦める人の最大理由は「自分がどの音を出しているのか分からない」だ。マイクで音を拾い、「レ#」「ファ」と即座に表示するこの機能は、楽器の不透明性に直接メスを入れる。これ単体で「他にない理由」になり得る。

何のリスクを減らすか。 「弾いていても手応えがない」という初心者最大の不安を解消する。フィードバックループのない練習は苦行だが、音名が見えると「いま何をしているか」が分かる状態になる。

守り方。 マイク機能を「任意オプション」のような見せ方にしないこと。このアプリの核心機能として前面に出し続けること。チューニング問題の解決と合わせて、インジケーターの精度も守り続けること。

これも、どこにも書いていませんが、その通りなのです。

オタマトーンは、音を出すこと自体は簡単です。
でも、自分がどの音を出しているのかが分からない。
そこが、初心者にとって大きな壁になります。

だから、リアルタイム音名表示は、単なる便利機能ではありません。
「弾いていても手応えがない」という不安を減らし、練習を成立させるためのフィードバックループです。
このレビューは、その機能を「任意オプション」ではなく、「このアプリの核心機能」として扱っていました。

さらに、総評ではこう整理されていました。

総評

このアプリはプロダクト仮説として強い。選曲、作者が手掛けた背景、ビジュアル品質、マイク機能ーーこれら4つが揃っているアプリは少ない。商業的な動機なしに、本当に必要だから作ったという誠実さがプロダクト全体に染み出ている。

現状の主な問題は、良い構造が体験として届いていないことだ。ステージという「階段」が設計されているのに、ユーザーには「6つの部屋が横に並んでいる」と見える。Stage 1で最初の成功体験が発生するかどうかが設計上保証されていない。ここだけが、このアプリが仮説を証明できるかどうかの分岐点だ。

単に「よくできています」「ここを直しましょう」ではない。プロダクトの価値と、その価値が届かない懸念を、かなり正確に見ている。
このアプリがなぜ成立しうるのか。どこに強さがあるのか。何が届いていないのか。どこが仮説検証の分岐点なのか。
そこを読んでいる。

プロダクトの表面に見えない部分、奥にある「仕組み」を扱っていることが衝撃でした。

「見えないデザイン」を読みとってくれることの衝撃

私がマネージャとしてまず考えるのは、ディテールに入る前の部分です。

そもそも、このプロダクトはなぜ暮らしに入り込めるのか。
どんな放置されたペインに触れているのか。
なぜそのペインは、これまで解消されないまま残っていたのか。
それを、このプロダクトはどんな仕掛けによって、自然に軽くしようとしているのか。

そうした、表面には現れにくい「からくり」の部分です。

プロダクトの価値は、画面に見えている機能だけで決まるわけではありません。
むしろ本当に重要なのは、画面の背後にある、見えない仕組みのほうだったりします。

なぜ人はそれを開くのか。
なぜ続けようと思えるのか。
なぜ少し詰まっても離脱せず、もう一度やってみようと思えるのか。
なぜその体験が、その人の日々の中に置かれる理由を持つのか。

私は、そこに練り込んだ軌跡があるかを見ています。

ただ、これは教えにくい。
チェックリストにもしにくい。
学ぶには時間がかかります。

現場で何度もプロダクトを見て、使われなかった理由を考え、生活者のペインに触れ、機能ではなく行動の変化を見る。
そうした経験を重ねる中で、少しずつ身についていくものだと思っていました。

だからこそ、Claude Skillsがそこを美しく言葉にして返してきたことに、強く揺さぶられました。
私が大切にしてきた「見えないデザイン」の読み取りに近いものが、そこにあった。

だから、補完ではなく代替に近いと思ったのです。

専門性が外に出る

ここで起きていたことは、単に「レビュー用プロンプトがうまく書けた」という話ではないと思います。Skillの中に、かなり高度なレビュー作法が埋め込まれ始めていました。

どの抽象度で見るか。
何をブラしてはならない資産として扱うか。
何が生活者の日々に入り込む理由になるのか。
狙った価値が、体験として届いているかどうか。

これは、ひとりのシニアマネージャが持っている暗黙知にかなり近いものです。

これは、遠くで起きている「AIによる仕事の変化」ではありませんでした。
自分が大事にしてきた専門性の中核に、急に手が届いてしまった感覚がありました。

この変化は、かなり大きいと思います。

これまで、UXデザインの専門家がフィーをいただけたのは、一定の水準を確度高くクリアできたからだったと思います。
一定水準のレビューができる。
一定水準のリサーチ企画と整理ができる。
一定水準の要件定義とタッチポイント化ができる。

もちろん、それは大切な能力です。

でもSkill化が進むと、「ちゃんとできる」は外部化されていきます。

強いSkillと良い素材があれば、平均的にちゃんとしたアウトプットはかなり出せるようになる。
中堅レベルの仕事の一部は、相当な速度で圧縮されていくはずです。

これは、少し残酷です。

経験年数がある。
一通りできる。
それっぽいレビューができる。

そうした能力は、これまでよりも差別化要因になりにくくなる。

今回のレビューで私が揺さぶられたのは、まさにそこでした。

AIが代替し始めているのは、単純作業だけではありません。
表面的な調整だけでもありません。

プロダクトの価値を読むこと。
何を守るべきかを見ること。
何が生活者の日々に入り込む理由になるのかを見立てること。

そうした、自分が専門性の中核だと思っていたものの一部まで、外に出始めている。

これはもう、「起きるかどうか」ではなく、起き始めている現実です。

専門性は、人の中だけに宿るものではなくなっていく。
一部はファイルになり、呼び出され、再利用されるものになっていく。
Claude Skillsを使って感じた衝撃は、そこにありました。

まずは、その現実を受け止める必要があるのだと思います。

最近、UXデザインを始めて間もないメンバーの仕事を見ていて、私にとっては興味深い気づきがありました。

ジャーニーを書いたあと、それをそのままプロンプトとして投げ込み、画面を作ろうとするのです。
プロンプトを投げ込むタイミングが適切かどうかはあまり考えず、文章になればとりあえず投げ込み、画面を生成してもらおうとする。
少し手が止まると、考え続けるよりも、まずは生成する。

今まで私がやってきた仕事の仕方とは違います。
それでも最終成果に近いものがでてくれば、結果ショートカットになる。

率直に見ている感想を言えば、そのときに出来上がるものは「何かちょっと違う」。
それっぽいが、そのまま使えるわけではない。
とはいえ、そんな感覚をもちながらも、作業を進めている本人としては前進している気になるので、プロンプトを投げ込み続ける。

これは、今の若手の典型的な仕事の仕方なのだと思います。
独力でデリバリする力がない時期であれば、多少ずれていても、自分で練りこむより質が高い面もあります。そうであれば、あえて仕事の仕方を変える理由もありません。
若手も、若手なりに、最善手を選んでいるのだと思います。

ジャーニーと画面のあいだにあるもの

ジャーニーとして描いた記述を投げ込んでも、しっくりこない画面が生成されるのは、その間にある思考を飛ばしているからです。

本来、そのあいだには「ジャーニーを実現するためには、どんな機能をつくるのか」を考える段階があります。ジャーニーをただ描いても、それを実現する「からくり」がなければ、ただの無邪気な願望でしかありません。

なぜその不便が起きているのか。どうすればそれが起きない仕組みにできるのか。ペインポイントがなぜ起き続けるかを分解し、そこにどんな「からくり」をいれるとゲインポイントに転じうるのかを考える。しかもそれが現実的に実現可能で、かつあまたある広義の代替品よりも、ぴったりのものであることでなければならない。

こうした地道な検討は、進んでいる実感も得にくく、むしろどこか手応えのない状態が続くものです。しかもこれが少し規模の大きいジャーニーになると、範囲も広い。
正直、広範囲のものを詳細化するというのは、タフで不快です。

だから、つい飛ばしてしまう。
ジャーニーから、そのまま画面へ。

いま起きていることは、そういうショートカットなのだと思います。

最初の単機能まで絞る

スキップされる、この「あいだ」をどう扱えばよいのか。
べき論でいえば「さぼらず、丁寧に分解して機能定義をせよ」なのですが、プロンプトに何かしらを放り込めばアウトプットが出てくるという体験の魅力には抗えません。
時間に追われながら、不快な積み上げをするという仕事はもうできないでしょう。

では、どうするか。

私なりの解ですが、「広げながら（＝ジャーニーを描きながら）、詳細化する（＝ペインを軽減する機能定義をする）」のはもうやらなくていい。

ただ、ジャーニーを大雑把にイメージした後は、全体を精緻化しなくてよいので、「最初に作る単機能まであたりをつける」を丁寧にやる。
その後は、時流に乗り、AIとのものづくりに進んでしまえばいい。

設計とは、すべてを考えきることではなく、最初の単機能を決めることに近づいている――まだ模索の途中ですが、そんなことを考えています。

すべての機能を洗い出すのではなく「最初に作る一つ」を決める

例えば、最近つくった簡単なアプリがあります。
フリーストック写真サイトを横断して検索できるものです。

https://free-image-search.vercel.app

普段、自分でブログを書くときなどにUnsplashで検索して、その後同じキーワードでPexelsを検索して、と繰り返していたことが煩雑だったのでそれを解消したかったのです。
丁寧にジャーニーを書くなどのワークはしていませんが、文章を書いた後、フィットするイメージ画像を探すペインに目を付けたのですね。

最初つくったのは、APIを提供しているフリーフォトストックの横断検索だけです。
まずはそれだけを形にして自分で使い始めました。

実際に日々に組み入れてみると、次に欲しいものが見えてきます。

たとえば、ブログだけでなく出版物にそのまま使える権利関係のものだけを絞り込みたい。
たとえば、そもそも文章にフィットする画像を探すための単語を考えるのも面倒だから、提案してほしい。
たとえば、以前ダウンロードした写真を再度入手できるように履歴が欲しい。
そんなアイデアが浮かんできます。

こうした機能は、最初からすべて考えていたわけではありません。
使いながら、自然に出てきたものです。

もし最初にすべてを書き出そうとしていたら、もっとエネルギーが必要だったでしょうし、時間もかかったでしょう。精度もそれほど高くなかったと思います。

ジャーニーを描くことはもちろん有用ですが、精度の高いジャーニーを描くのはタフです。
はやくプロンプトに落として具体化したい。一番スピードがでるのはこのプロセスに素早く入ることだとわかっています。
そうであれば、最初に作る機能のあたりをつけるためにジャーニーがある、と割り切ってはどうか。
その後の精緻化は、具体化してからできるのではないか。

自分の個人ワークを通してですが、そんな暫定解を置いています。

単機能は「生活との接点」になる

ここで重要なのは、その「最初に作った単機能」が使われるかどうかです。

使われれば、次に進みます。
使われなければ、そこで止まります。

そして「使われるかどうか」は、日々の暮らしの中に入り込めるかどうかにかかっています。
ふと思い出して使う。
特別な意識をしなくても、手が伸びる。

そこまでいかなければ、その機能は育たないのです。

そう考えると、最初の単機能は、単なる試作ではなく、「生活との接点」をつくるためのものになります。

育てるか、見切るか

もし、その単機能が暮らしに入らなければどうするか。

従来であれば、改善を重ね、磨き続けるという選択が一般的でした。
しかしいまは、少し状況が変わっています。
作るコストは下がり、試すスピードは上がりました。
だからこそ、その機能を磨き続けるのではなく、捨てるという判断も現実的になっています。

ワークフローの新旧対比

これまでやってきた仕事の仕方と、このポストで触れた仕事の仕方を並べてみた図を作ってみました。

これまでの進め方は、全体を描ききり、分解し、順番に実装していくものとしていました。
今回提示したアプローチは、入口となる機能を決め、そこから育てていく流れです。

もちろんケースバイケースですし、パーソナリティやスキルにフィットしたやり方があるのだと思います。

ただ、プロンプトにとりあえず放り込みたくなるという衝動を殺さず、どんどん具体化して多産多死のなかで良いものを生んでいく。この発想は、私はとても現代的だと思いますし、好きです。

何を最初に作るべきか

設計という仕事の性質がかわり、「すべてを決める」というよりも「最初の単機能をどこに置くか」を決めること、そしてそれが生活の中に入り込むかどうかを見極めることになるかもしれない――こうした視点はしばらく育ててみてもよいと感じています。

そもそも、思いついたものをすぐに形にできるというのは楽しいものです。
すべてを考えてから作るのではなく、意味があると確信している単機能を先に作るというのはその「楽しい勢い」を殺さない面もあると感じています。
逆に、その確信をもって作った単機能が使われないという真実が素早く手に入るのであれば、無理無駄な投資もなくなる。

「ジャーニーは最初につくる単機能を定めるためにある」と仮置きし、もう少し、この仮説で試行錯誤を重ねてみようと思います。

前回、「デザインプロセスが消えた」というより、実際には「仮で試す」必要が薄れ、実体でまわせる領域が広がったのではないか、と書きました。（過去投稿）

試して、直して、また試す。
この反復的なプロセス自体は変わっていない。
ただ、その対象が「仮のもの」から「実際に動くもの」へ変わりつつある。
そう捉えると、いま起きている変化は、少し見通しやすくなる気がします。

ただ、この変化にはもう一つ、別の側面があります。

実体でまわせるようになったことで、私たちは以前よりも速く作れるようになりました。
思いついたものを、すぐに形にできる。

これは大きな進歩です。

しかしその一方で、少し危うさもあります。

作れるようになったことで、思った以上に早く収束してしまうのではないか、ということです。

作ることは、基本的に収束である

何かを作るという行為は、基本的には収束です。

一つの案を選ぶ。一つの画面を作る。一つの仕様に落とす。
その瞬間、他の可能性は少しずつ後ろに下がっていきます。

もちろん、作りながら変えることはできます。
作り直すこともできます。

それでも、一度動くものができると、人はそこに引っ張られます。

「せっかくここまでできたのだから」
「まずはこの方向で直してみよう」
「ここを少し調整すればよさそうだ」

そう考えるのは自然です。

動くものには、強い説得力があります。
だからこそ、作るスピードが上がると、収束のスピードも上がります。

便利さは、発散を奪うことがある

これは、少し不思議な逆説です。

作ることが難しかった時代には、作る前にいろいろ考えざるを得ませんでした。

複数の案を並べる。
別の導線を検討する。
そもそも違う切り口はないかと考える。

実装に入る前に、いったん立ち止まる時間があった。

もちろん、それが良いことばかりだったとは思いません。
会議が増え、資料が増え、なかなか前に進まないこともありました。

ただ、その時間の中には、「広げる」という仕事も含まれていました。

今は違います。

作ろうと思えば、すぐに作れる。
一つ目の案が、すぐに動く。

すると、気づかないうちに、最初に思いついた案を磨き続けてしまうことがあります。

作ることが容易になった結果、
作る前に広げる時間が、静かに削られていく。

これは、かなり気をつけるべき変化だと思います。

Diverge / Converge はまだ生きている

昔、IDEOのTim Brownが、デザイン思考の文脈で「Diverge」と「Converge」の話をしていました。

いったん広げて、そこから絞る。
可能性を拡張し、その後で選び取る。

この考え方は、いまでもかなり重要だと思います。

むしろ、作ることが簡単になった今こそ、改めて意味を持ち始めているのかもしれません。

なぜなら、自然に任せると、私たちはすぐにConvergeしてしまうからです。

一つの案を作る。
それを直す。
さらに直す。
また直す。

この反復は、一見すると前に進んでいるように見えます。

しかしそれは、同じ方向を深掘りしているだけかもしれない。

本当は、別の入り口があったかもしれない。
もっと軽い解き方があったかもしれない。
そもそも、別の問題を解くべきだったかもしれない。

そうした可能性は、意識的に広げないと見えなくなります。

Jenny Wen が Figma を使う理由

Claudeのデザインを率いるJenny Wenは、AI時代のデザインについて語る中で、Figmaはまだ使っていると言っていました。
ただし、その意味は以前とは少し違います。
彼女にとってFigmaは、最終的な画面を美しく整えるためだけの道具ではありません。
むしろ、複数の選択肢を並べて考えるための道具として使われているようです。

コードを書き始めると、どうしても一つの方向に入っていきます。
実装は線形に進みやすい。

一方で、Figmaのようなキャンバスでは、複数の案を横に並べ、行きつ戻りつしながら練りこみやすい。
A案、B案、C案。少し違う導線。まったく違う構成。細かな表現の違い。
そうしたものを一覧できる。

これは、単なるツールの話ではありません。
並べて考える場所を持てるかという話です。

もちろん、それが必ずFigmaである必要はないと思います。
紙でもホワイトボードでも、スライドでもいい。
コードで複数パターンを一気に出せるなら、それでもいい。

重要なのはツールではありません。

収束しすぎないための場を、意識的に持つことです。

作ることが速くなったからこそ、広げることは自然には起きにくくなる。
だから、Divergeはプロセスとして意識的に置いた方がよい。

これは、昔ながらのデザインプロセスを懐かしむ話ではありません。
むしろ、AIで作る時代に合わせて、発散という営みを再定義する必要がある、という新しい危機感です。

発散とは、作る前に戻ることではない

ここで少し注意したいのは、発散とは「作る前に戻ること」ではない、ということです。

昔のように、実装に入る前に延々と議論する。
あらゆる可能性を資料化する。
すべての案を合意してから作る。

そういう話ではありません。

むしろ、実体でまわせるようになった今だからこそ、発散のやり方も変わるはずです。
たとえば、違うコンセプトを短時間で試す、いったん作ったものを捨てる前提で扱うといったやり方が、以前より現実的になっています。

つまり、発散もまた、実体で行いうる。
「案を出す」のではなく、「別の可能性を小さく動かしてみる」。
これが、これからのDivergeなのかもしれません。

速く作れることに、引っ張られすぎない

AIによって、作ることは本当に楽になりました。
これは素晴らしいことです。
ただ、作れることに引っ張られすぎると、最初に思いついた方向を、ただ速く磨くだけになってしまう。

そしてそれは、必ずしも良いものにつながりません。

いいものを作るには、やはり一度広げる必要があります。

誰の、何の役に立つのか。
他に解き方はないのか。
解けるとすれば、もっとシンプルな解き方はないのか。

こうした問いは、作れるようになったからといって消えるわけではありません。
むしろ、作れるようになったからこそ、早く収束しないように扱う必要がある。

広げて、絞る。
作れる時代だからこそ、すぐに作り始める。でも、作れる時代だからこそ、意識的に広げる。

その両方を持てるかどうかが、これからのデザインの質を左右するように思います。