プロダクトデザインにおける「動かせる変数／動かしてはいけない変数」について
はじめに
今回、何かをデザインするときに「動かせる変数は何か、動かしてはいけない変数は何かを認知し、整理すること。」これを最初に考えて答えを出しておくと、その後の具体的なパーツの検討や、何を採用して何をドロップするかの判断のベースとして非常に有用だったので、今後またプロダクトデザイン(UI/UXなどの)の際に活かせるように復習・整理していく。
背景：新しいホーム画面のデザインでの苦戦
今回、新たなホーム画面を作っていく中で、既存の参考例のままでは我々が求めるプロダクトの強みを作りきれないことが分かっていた。
そのため新たなエレメントの構成を考える必要があり、ここに非常に苦戦した。
デザインの対象はUIだけではない。UXも、後ろ側のロジックも、さらに画面の外でユーザーがどう動くかという行動の構造まで含めて、全体をデザインすることで、我々が求めるベネフィット、一言で言えば、プロダクトとしてのバリュープロポジションと、ユーザーにとってのWOW体験をどう作るかに取り組んでいた。
当たり前だが、白紙に対してUI/UXを考えるのは本当に難しい。
突飛すぎてもだめで、一般的すぎればただの今までのSaaSのようなプロダクトになってしまう。
さらに今は生成AIの時代で、後ろ側（いわゆるバックエンド処理）が変わったからこそ、フロント側も新しい体験でなければ、処理の良さをユーザーに届けられなくなっている。
生成AI以前の時代のUIは、当たり前だが新しい生成AIでの価値が考慮されていないため、参考にできるポイントがずれていて、参考にできるデザインが
少ない。ここがすごく苦慮した原因の一つだ。リファレンスが少ない以上、自分でリファレンスを作り上げる必要があったのだ。
転機：「この画面で何を提供すべきか」に立ち返る
行き詰まる中で、そもそも我々はこの画面で何を提供しないといけないのかを思い返すタイミングがあった。
考え直してみると、二つのことに気づいた。
提供すべきジョブやバリューを、自分が思った以上に具体で書けていなかった。
逆に別の部分では具体的すぎて、不必要な制限まで自分の中で規定してしまっていた。
例：ToDoアプリ
簡単なAI ToDoアプリを作るPJを例にすると、「すごく簡単にToDoが登録できること」を最初に想起してしまいがちだ。
しかし、そもそもなぜ登録しやすい方がいいのかを掘ると、本質は「その人がToDoマネジメントをしやすいこと」にある。
そう捉え直すと、「登録しやすい」よりもむしろ「メール、ミーティングから自動で生成されて、そもそも登録しなくてもいい」という発想で作っていくことができる。
（ちょっとこの例自体はもう一般的すぎて、それくらいは思いつけよという気もしなくもないけど、イメージとして理解いただけますと）
私の場合も、どこに制限を作るべきで、どこに制限を持たないべきかの認識が間違っていた。
逆にそこを正しく認識し規定した途がしやすくなり、一気に進めやすくなった。
ジョブ理論を「画面単位」に降ろす
また、少し別の気づきの話だが、起業・新規事業作成のレイヤーでよく言われる、ジョブ理論や「ユーザーの課題から考えよう」「コンセプトを重視しよう」は、スタートアップ界隈でよく言われる基本のキだ。
今回の私にとって重要だったもう一つの気づきは、これがサービス単位だけでなく、画面単位でも言えるということだ。
この画面でユーザーにどういうジョーザーはどういう課題を解決したくてこの画面に来ているのか。画面単位で考えることも、非常に有用だと思った。
そして、それを抽象化した学びが冒頭に書いた今回の学び「動かせる変数は何か、動かしてはいけない変数は何かを認知し、整理すること。」になる。
つまり、「ジョブ理論」や「ユーザーの課題から考えよう」「コンセプトを重視しよう」を、画面単位でやると、動かしては行けない重要な変数が明確化できるのが。
これらを新規事業に対してやるのも、そのような解空間が無限にある中で、狭めていくHowなのだろう。
画面で言えば、動かしてはいけない変数は、ジョブの話かもしれないし、法的にここではこれを出さないといけないという要件かもしれないし、ユーザーからの強いニーズかもしれない。
検証：この学びはオーセンティックか
この考え方についてAIにも調べてみたところ、「製品を作る際に、動かせない変数（変わらないもの・制約）をきちんと認識し規定すること」の重要性を唱えている著名な言説は非常に多くあり、この学び自体がオーセンティその観点からも今回は良い復習のワークになった。
非常に参考になったので、以下に列挙する。
1. Clayton Christensen — Jobs to Be Done：「ジョブは安定し、プロダクトは変わる」
Christensen のジョブ理論の核心は「Jobs are stable; products are not.（ジョブは安定している。プロダクトはそうではない）」という一文にある。
顧客は製品そのものが欲しいのではなく、自分の生活の中の「片付けたい用事（ジョブ）」を果たすために製品を「雇う」。
そして技術・製品・競合がどれだけ入れ替わっても、そのジョブ自体は驚くほど長期にわたって変わらない。
だからこそ、変わり続けるソリューション側ではなく、変わらないジョブ側を戦略の土台に据えろ、というのがこの理論の主張だ。
今回の学びの言葉に翻訳すると、ジョブ＝動かしてはいけない変数、プロダクト（UI・機能・実装）＝動かせる変数、ということになる。
私の気づきは、これをサービス単位ではなく画面単位に降ろした形、「この画面のジョブは何か」を先に固定すると言える。
参考：Strategyn — Jobs to Be Done / thrv — Clayton Christensen, Jobs-to-be-Done
2. Jeff Bezos — 「今後10年で変わらないものは何か？」
Bezos は 2012 年の AWS re:Invent で、「『今後10年で何が変わるか』はよく聞かれるが、『今後10年で何が変わらないか』はほとんど聞かれない。しかし重要なのは後者だ」と語っている。
Amazon の小売でいえば、顧客が「低価格・速い配送・豊富な品揃え」を求めなくなる未来は想像できない。
「ジェフ、Amazon は大好きだけど、もう少し価格が高ければなあ」と言う顧客は現れない。時間が経っても真であり続けるものにこそ、安心して大きなエネルギーを投資できる、これが Bezos の戦略の建て方だ。
参考：Quote Investigator — What's Not Going To Change? /
Working Backwards — PR/FAQ Process
3. Charles Eames — 「デザインは制約に大きく依存する」（1969）
家具デザインの巨匠 Charles Eames は、1969 年のルーヴル「What is Design?」展に際したインタビューで、「デザインは制約を許容しますか？」という問いにこう答えた。「デザインは制約に大きく依存する（Design depends largely on constraints）」。続けて、「デザインの問題を解く数少ない有効な鍵のひとつは、デザイナーができるだけ多くの制約を認識する能力と、その制約の中で熱意をもって働く意欲だ。制約には価格、サイズ、強度、バランス、表面、時間などがあり、問題ごとに固有のリストがある」と。
半世紀以上前の言葉だが、これは「動かせる変数／動かしてはいけない変数をまず仕分ける」という今回の学びの、ほぼ原型だ。
重要なのは、Eames が制約を創造の敵ではなく「鍵」と呼んでいること。制約の認識が甘いままではデザインは評価も判断もできない、今回私がホーム画面で体験したことと同じ構造だ。
参考：Herman Miller — Design Q & A: Charles and Ray Eames
4. Tony Fadell『BUILD』 — 「why を理解して初めて、how に集中できる」
iPod の父であり Nest の創業者であり、私の憧れの人でもあるTony Fadell は、著書『BUILD』で「なぜその製品が必要なのかを理解して初めて、どう動くかに集中できる」と繰り返し説いている。
優れた製品は機能の集合ではなく、ユーザーの現実の痛み（ペイン）から始まる物語の上に建つ。まず痛みとストーリーがあり、それを解く体験があり、機能や実装はその後に来る。だから Fadell は「顧客体験の全体をできる限りプロトタイプせよ」とも言う。派手な部分だけでなく、体験の地味だが重要な部分を見落とさないためだ。
これも順序の話として今回の学びと一致する。why（ユーザーの痛みと、それが解かれた状態＝ベネフィット）が動かしてはいけない変数で、how（UI・機能・実装）が動かせる変数。順序を逆にしてhowから入ると、動かしてはいけないものを知らずに動かしてしまう。
参考：Dave Martin — "Build" by Tony Fadell book notes
まとめ
家具デザインの巨匠 Charles Eamesによる、「デザインの問題を解く数少ない有効な鍵のひとつは、デザイナーができるだけ多くの制約を認識する能力と、その制約の中で熱意をもって働く意欲だ。」という言葉は今回改めて勉強になったし、何かデザインをするということにおいて非常に重要なコアの一つなんだろうなということが新たに学びになり、特筆すべきポイントでと私は思った。
私の元々の体験、そしてこれらのインプットを踏まえた結論として、このようなUIUX、そして新たなプロダクトを作るというような広義のデザインの問題を解くときの一つの有効な鍵として、「制約するべきこと、そして何を制約しないのかを整理する」ことは、本当に非常に強力な武器であると私は非常に強く思った。
また、「多くの制約を認識する能力」を会得・体現するためには、今回の経験をリファレンスするならば、今回のデザインにおいて何が制約・重要で変えてはいけない変数として規定するか、反対に自分で勝手に制約してしまっているという事を認識できること、が重要なのではないかと私は思った。
今後、デザイン力を持つ人間になるべく、その重要な能力の一つが、「多くの制約を認識する能力」と「その制約の中で熱意をもって働く意欲」であるのは、強く心に刻んで働いていきたい。
