tl;dr
- コンパウンドSaaSプロダクトで、各ドメインの初期設計を大量にこなしたことを振り返って、徒然なるままに
- プロダクトデザインとは、価値を最大化する最適解を導く行為
- 設計の最適解の求め方には、物理学的なアプローチと統計学的なアプローチがある
- 不確実性世界＆リソース制約のある世界の中で最適解を爆速で導き続けることは、決して妥協ではない
- スケールするために不可逆な設計は外せない
コンパウンドSaaSプロダクトの初期設計を大量にこなしたことを振り返って、徒然なるままに
コンパウンドSaaSプロダクトが指すのは、人事、情報システム、総務、財務、経理など、あらゆるバックオフィス業務を爆速にこなすことができるようにする"DRESS CODE"という製品のことです。最初期から、デザイナーとしてプロダクトの設計を担当してます。将来、製品や会社が大きくなってきたタイミングで、負債となるようなことのないように初期設計を頑張っている中での随想録です。
釣り的な表現をすると、コンパウンドSaaSプロダクトの初期設計を通して得られた、プロダクトデザインの本質と、不確実な状況下で最適解を導き出すための考え方を紹介します。
プロダクトデザインとは、価値を最大化する最適解を導く行為
設計とは、最適化する営みです。（と少なくとも私はそう考えています。）プロダクトのデザインも同様。
Product Design/プロダクトデザインは、Benefit/価値を最大化するために、Product/プロダクトを最適化します。十人十色のUser/ユーザーに関する定式化、定量化されないさまざまな要因までも考慮しながら、多くの選択肢の中から最適な選択をする意思決定過程を設計のプロセスとして捉えています。私の経験がSaaSの文脈に閉じているために、Operation/業務を掛け合わせていますが、広くは体験と置き換えても良いかも。
デザイナーに限らず、プロダクトを作り、顧客やユーザーに届けることに関わる人が、デザインや設計という言葉の持つ行為がどういう意味なのか、と考える時には、このような視点でも捉えられるなぁと思ってもらえたら嬉しいです。世のデザインの定義に対して、これが正解だろ！と一般化したいわけではなく。
設計の最適解の求め方には、物理学的なアプローチと統計学的なアプローチがある
Softwareのようなデジタルなモノに限らず、設計には、いくつか異なる性質を持った方程式を持つとよさそうだなと感じています。物理学的なアプローチと統計学的なアプローチの2つを思いつきました。
物理学的なアプローチ → Databaseの設計
物理学的なアプローチでは、自然現象のような揺るがない普遍的な法則が存在するという前提で、その法則を見つけ出し、その法則に基づいて設計を行います。
例えば、データベースの設計では、扱うデータの性質やデータの関係性を考慮して、データベースの構造やスキーマを決定します。データベースは、実世界を投射、もしくは記述したものでなくてはならない。エンジニアとドメインのエキスパートと共に、実世界の現象を紐解いて、設計に落とし込みます。
運動方程式のように、無駄のないデータベース設計を目指します。そうすれば、変数を明らかにし、値を方程式に代入すれば必ず解が求められます。解は基本的にいつも一つです。
とはいえ、実世界を観測しきることに限界があること、不完全情報の世界であることを意識しなくてはいけません。ともすれば、
ほにゃららを求めよ（摩擦係数はゼロとする）。
カッコ書きばかりのような机上の設計になりがちです。如何にドメイン知識を深め、実世界を理解するとともに、観測の限界を加味したうえで、柔軟に対応できる設計を目指します。
統計学的なアプローチ → Interfaceの設計
統計学的なアプローチでは、収集されたデータの中に潜むパターン、傾向、変数間の関係性を見つけ出し、とあるパラメータにおいての予測値に基づいて設計を行います。
例えば、Interfaceの設計では、全てのユーザーを100％満足させるのは不可能です。統計学で名高い、p値が、観測結果が偶然に起こる確率がX％以下であることを示すように、一定の確率でこぼれ落ちます。p値が小さければ小さいほど、その結果は偶然ではなく有意な結果であると言えるように、UIもより多くのユーザーにとって、満足のいく体験になるように設計します。
多数の要素の振る舞いから現象を予測するということからして、統計的な解は、必ずしもひとつではありません。
この統計学的なアプローチは、物理学的なアプローチと比べて、しっくりきにくいだろうなぁと思っています。説明している私自身も含めしっくりきにくい。そもそも統計学ってしっくりこない人のほうが多い。
連想ゲームをしてみたらわかりやすくなるかもしれません。
迷路があります。迷路の中の様々な場所にいる人たちに一つの地図を渡します。より多くの人がゴールにたどり着けるように、地図を描きましょう。
入口からの道順を示すだけでは足りず、袋小路に迷い込んでいる人に対しても、ゴールを案内しなくてはならない。無理ゲーもいいところですが、UIの設計はこういう地図を描くことに似ていると思っています。袋小路に迷い込んでいるユーザーも、迷路の中で行動した結果の現象です。そこに物理法則はないかもしれませんが、統計的に導けるパターンはあるかもしれない。
不確実性世界＆リソース制約のある世界の中で最適解を爆速で導き続けることは、決して妥協ではない
スタートアップにしろ何にしろ、資本主義な世の中は、不確実性世界かつリソース制約のある世界（Resource-Constrained Environmentの意）です。
上述の設計方程式に対し、別の関数が導入されなくてはならず、解が変化します。別の関数に扱われるものは、つまりはリソースの制約による工数制限、ビジネスニーズ、目の前のユーザーニーズ、ビジネスモデル、マーケティング、資金などなど。
実際の設計業務では、複数の目的関数を持つ多目的最適化問題を解く必要がある、ということです。これ以上、いずれかの評価項目を悪化させることなく、ある評価項目を改善することができない、というパレート最適解を求める戦いです。パラメータを変更しては、改善量と改悪量のトレードオフをにらめっこし続ける、しかありません。この観点においては、設計は探索行為であるとも言えそうです。不正解を潰していくことで、Betterな解を探すような。
工数もないし、時間もないしで、テキトーに設計したら、それは妥協ですが。
ダブルダイアモンドのデザインプロセスとかは、不確実性もなくリソース制約もない理想郷においては、良いのかなと思いますが、私個人がスタートアップで設計業務をするにあたっては、助けにならないと感じました。なので、自分なりに考え方の整理してみた結果が、設計を物理学的なアプローチと統計学のアプローチで捉える、いうものです。
パラメータの不確実性を都合よく隠蔽して、解の絶対性を謳うことができないので、コミュニケーションの面でも、メンタル的にも、楽かと思います。特定のコンテクストでは、間違った解が出てしまうこともあると納得できます。
スケールするために不可逆な設計は外せない
とはいえ、スタートアップがスケールしていくには、不可逆な設計を外したくありません。不可逆な設計とは、Databaseの根幹部分、情報アーキテクチャ、ナビゲーション構造、概念整理などなど、SCRAP&BUILDを要するような改修でないと変更できないものです。連想ゲームとしては、車を走らせながら、タイヤを修理することができないことを想像するとよいです。将来、どうしても車を走らせながら、タイヤを修理したいのであれば、それ相応の構造設計をしておく必要があります。タイヤを8個とか付けてウィーンと4個ずつ接地して走れるようにするとか、2つ目の車を並走させて、積載物をすべて移すとか、そういうこと。家のリフォームでは、構造体は変えられないのと同じです。
不可逆な設計を、不確実性世界かつリソース制約のある世界で、爆速でやる必要があるので、とてもヒリヒリします。プロダクトの初期設計では、仮に天秤にかけるなら、ユーザーに届ける画面の美しさを整えることよりも、不可逆な設計を外さないことの方が優先されて然るべきです。こういった設計を担うのは、職種で言えば、アーキテクトに当たるのだと思います。アーキテクトがデザインの文脈やデザイナー界隈であまり聞かないのは、需要が希薄だからでしょうか。エンジニアだと、アーキテクトをよく耳にしますが。
肩書きとしてのタイトルがつかないと、流行らない、知識の伝搬もなく、初期設計の質が上がらないというのも、あると思います。日本のガラパゴスSaaSだったり、Vertical SaaSがプロダクトを横展開してもあまり価値を発揮できてないことには、一理あるのかも。日本においては、内需というか、需要の最大値がそこそこある今はまだいいが、、、、と脱線してきたのでここらへんでストップ。
まとめ
プロダクトデザインとは、価値を最大化する最適解を導く営みです。最適解の求め方には、物理学的なアプローチと統計学的なアプローチがあります。不確実性世界＆リソース制約のある世界、AKAスタートアップ、の中では、そのほか多様な目的関数を持つ多目的最適化問題を解く必要があります。不正解を消し込みながら、Betterな解を探していきます。その解は決して妥協ではなく、最適解になるはずです。スケールするためには不可逆な設計を外せないので、条件厳しい負け戦の中でも、最適解を爆速で出していかなきゃいけない。さぁ大変！ 将来、ユーザーはもちろん、プロダクトに関わる人すべてが頭を抱えないように、どんどこ設計していきます。
Discussion