作る前に課す3つの制約
(jordanlord.co.uk)- プロダクトのアイデアは、まず制約条件を課すことで探索空間が狭まり、複雑すぎたりアイデンティティのない成果物に流れてしまうのを防げる
- すべてのアイデアは1枚のone pagerにまとめるべきで、そこに収まらないなら、調査・計画・プロトタイプがさらに必要な状態だと見るべき
- プロダクトとは別に生き残れるcore techもあわせて作るべきで、方向転換があっても蓄積が続く累積資産として残るべき
- ユーザーに継続的に見える1つのdefining constraintがプロダクトの中心にあるべきで、この制約がプロダクトのfeelとアイデンティティを自然に規定する
- 3つの基準のうち1つでも通過しなければ作らないという姿勢が、スコープ管理と長期的なレバレッジ確保に重要
作る前に課す3つの制約
- プロダクトを作る前に制約条件を先に置くと、探索空間が狭まり、複雑だったりアイデンティティのない成果物に流れてしまうのを防げる
- 10年間にわたり複数のプロダクトを作る中で、複雑すぎたりアイデンティティのないプロダクトが失敗につながり、その試行錯誤の末に3つの基準へと絞り込まれた
-
1ページを超えるなら作らない
- すべてのアイデアはone pagerにまとめる必要があり、この文書はnorth starの役割を果たす
- one pagerは妥協できず、正確で、野心的でありながら無駄があってはならない
- 投資家、貢献者、チームメンバー、友人、家族など、さまざまな相手とのコミュニケーションに同じ文書を使える
- 協業中に衝突が起きたとき、one pagerにない内容は争う価値がなく、本当に重要なら文書を修正して反映すべき
- 1ページを埋められなかったとしても、無理に内容を膨らませるのではなく、まだ作る準備ができていない状態と見るべき
- その場合はまず調査・計画・プロトタイプを経てからone pagerを書き直すべき
- 1ページを超えるほどなら複雑すぎるため、作らない
-
コア技術はプロダクトと分離されていなければならない
- プロダクトそのものとは別に、プロダクトを支えるcore techを作る必要がある
- core techは方法論、技術、ツール、あるいは別個のプロダクトでありうるし、現在のプロダクトがなくても生き残れるべき
- この分離によって1つのプロダクトに閉じ込められず、方向転換があっても蓄積を継続できる
- プロダクトはしばしば方向が変わるが、core techは持続的で累積的な資産として残る
- 長期的には、こうした累積的な努力が非線形の利益を生みうる
- 例としてLinus Torvaldsのgit、HashiCorpのHCL、GoogleのKubernetesが挙げられている
- 必ずしも大企業レベルのリソースが必要なわけではなく、コードベースから切り出したライブラリや、継続的に磨き上げる方法論でもよい
- core techはプロダクトの方向性とは独立しているべきだが、個人や企業の長期ビジョンとは一致していなければならない
- アイデアがcore techを可能にしないなら、十分なレバレッジはない
-
1つの決定的な制約がプロダクトを規定しなければならない
- プロダクトの中心には、ユーザーに常に見えるdefining constraintがあるべき
- この制約は、ユーザーが継続的に向き合い、相互作用する要素であるべきで、プロダクトのアイデンティティを作る
- 良い制約はプロダクトのfeelを生み、ユーザー体験全体に染み込む
- Minecraftはブロックだけで構成され、IKEAはflat-packの組み立て式家具である、というように、アイデンティティは制約からすぐに表れる
- このような制約は意思決定空間を狭めてスコープを制限し、本当に重要な問題へ集中させてくれる
- 制約を選ばなかったり、誤って選ぶと、あらゆることをやろうとする肥大化したプロダクトへ流れてしまう
- うまく設計された制約があれば、プロダクトデザインはその制約から自然に導かれる
- この制約もまたone pagerの前面に置かれるべき
締めの基準
- 3つの制約のうち1つでも通過しなければ作らない
1件のコメント
Hacker Newsのコメント
私はこういうものを product primitives と呼んできた。
Notionのblocks、Telegramのmessages/conversations、Figmaのframes/layers、Twitterのtweets、Excelのcells/sheets、Photoshopのtools/layers、CLIのcommands みたいなものだ。
良いプロダクトデザインは、こうした primitive の数がごく少ないときに生まれると思う。
悪いプロダクトは、自分たちの primitive が何なのかわかっていないか、多すぎて、プロダクト内のあらゆる要素がそれぞれ別々に動いているような印象を与える。
するとユーザーは、互いに異なる高レベル概念を大量に学ばなければならず、混乱し、萎縮し、教えるのも難しくなる。
理想的には、核となる primitive は1つ、2つ、せいぜい3つで十分だ。
アプリの複雑さと力は、組み合わせ可能で深みのある primitive を選ぶことから生まれる。
Notion block、Excel cell、CLI command、Minecraft block のように、小さな単位でも多くのことができるべきだ。
これは Alexandrian Pattern Language に似ているように見えるが、実際には pattern よりも、Alexander が後年語った Centers に近い気がする。
私の理解では、ソフトウェア業界は彼の pattern を大きく取り入れたが、Alexander は晩年、システムの究極的な構成単位を Center だと見ていた。
明るい中庭、窓辺の席、暖炉のように、局所的な有用性と凝集の焦点になるものだ。
強い center は自然に組み合わせ可能で、局所的な緊張を解消し、より小さな center で構成され、より大きな center を生み出すビルディングブロックとして機能する。
プロダクトが混乱し肥大化するのは、たいてい意図が悪いからではない。
ユーザー要求は経験的に比較的見つけられるが、その要求を優雅に吸収できる真の中心構造は非常に繊細で、発見が難しい。
そのため、目の前の要求ごとに固有で硬直したインターフェースを1つずつ貼り付けるのが、常にいちばん楽な道になる。
そうした要求を自然に吸収する核となる primitive を見つけるには、深いアーキテクチャ作業が必要だ。
だから結局、faster horses を作り続けてしまうのかもしれない。
昔はこれを concept count と呼んでいた。
プロダクトを構成する中核概念の数は、通常は最小化したほうがよく、プロダクトの nouns and verbs とも呼ばれていた。
この哲学はやや 過度に単純化 されている気がする。
Tana は primitive が実質 bullets と supertags の2つしかないのに、とても単純な作業ですら数時間のチュートリアルを見ないと使えないほど複雑だ。
一方で Google Maps は primitive がかなり多くても、ユースケースの90%では UX がかなりしっかりしている。
私はプログラミング言語を見るときにも似た基準を使っていた。
言語の規模が大きくても 概念的に小さければ、学んだあとは残りが経験の蓄積とともについてくるが、概念的に大きい言語は参入障壁が高かった。
それを強く感じた例が perl だった。
小さければよいが、小さすぎてもいけない。
典型例が shell script（POSIX shell、bash）で、スクリプティングですら command としてモデル化して新しい概念を導入しないようにしたが、結果はご存じのとおり、熱く、遅く、めちゃくちゃな混合物になった。
3つの制約はどれも気に入っているが、1ページ文書 はプロジェクトの複雑さに応じて変わるべきだと思う。
小規模〜中規模のプロジェクトなら1ページで十分だろうが、火星飛行制御ソフトウェアなら、実装を始める前に数多くの下位仕様へハイパーリンクされた one-pager が必要かもしれない。
技術と製品の分離 は本当に賢明だ。
たとえば Skype を見ると、バックエンドの P2P 通信技術とフロントエンドの通話アプリケーションがあり、賢い創業者たちはこの2つを別会社に入れておいた。
その結果、フロントエンドアプリである Skype が Microsoft に売却されたあとも、中核 IP と P2P バックエンド技術を持つ会社は引き続き別に保有できた。
1つの制約を中心に据える のも理解できるが、私はときどき複数の制約や優先順位つきのリストを持つほうがよいとも思う。
最上位原則が商業化しにくいなら、それを不変の教義のように扱った瞬間に、事業は破綻へ向かう可能性がある。
チーム内に、もっと売りやすい方向へ大きく pivot できるアイデアがあるなら、元とはかなり違っていても生き残る道が開けるかもしれない。
Twitter ももともとは別のことをしようとしていて、public status update は脇道のプロジェクトから出てきた例だった。
この記事は、以前に研究メンターと一緒に事業を作っていたやり方を本当にうまく要約している。
私たちはまず後ろの2つ、つまり 中核技術 と 制約 から固めた。
中核技術は、sparse data のための任意の hierarchical Bayesian graph model を可能にする sampler で、制約は CPU バウンドで計算可能でなければならないというものだった。
いちばん時間がかかったのは、最終製品が基盤技術から分離されるべきだと気づくことだった。
始める前から何人もの人に似たような助言を受けていたが、教訓というものは自分で経験して初めて身につくこともある。
one-pager というアイデアは本当に良い。
制約を1ページ分ですら明確に書き出す時間が取れないなら、結局は進めながら慌ててその制約を後から発見することになる。
しかもそれはバグではなく、私たちはそもそも間違ったものを作っていた というレベルの欠陥になる。
データで証明はできないが、私の経験では、全員を概念的に同じページに乗せられているプロジェクトのほうが、ずっと高い頻度で成功していた。
たとえ1枚の高レベル文書でも、何をやり、何をやらないのかを明確にしておけば効果は大きい。
逆に、その場の勢いで押し進めたプロジェクトでは、自分の考えをはっきり言わなかった人たちまで、結局は全員が失望することになった。
著者には、制約が実際に機能する完全な例 を1つ示してほしかった。
とくに3つ目の項目が実際にはどういう形になるのか、いまひとつピンとこない。
結局は自分で何かを思いつかなければならないようだ。
Linux の everything's a file のようなアイデアは良いと思う。
そういう強い概念1つだけでも、かなり遠くまで行ける。
制約 は過小評価されている。
もっともエレガントな解決策は、たいてい無限の自由度から生まれるのではなく、明確な制約を置いて作るときに生まれる。
そしてこれは1番目の項目にもつながっている。
one-pager を書くプロセスそのものが、その制約を定義する助けになる。
Google が Kubernetes を持っているのは、何より 競合の無力化 が目的に見える。
solo SaaS なら、私が追加したい制約は 今週中にベータユーザーを1人見つけられるか だ。
時間、スコープ、技術が one-pager 上では問題なく見えても、誰も入ってこなければプロジェクトはそのまま死ぬ。
だから最初から 配布・流通の制約 を入れておくことで、機能を深く掘る前に需要層を検証するようになった。
中核技術は製品と分離可能であるべきだ という話は、抽象化を早くやりすぎたり、デザインパターンを乱用したりすることにつながらないだろうか。
もちろん関心の分離や、ビジネスドメインレイヤーを persistence/network/UI のようなものからきれいに分けるのはその通りだ。
それでもドメインレイヤーは、結局のところ製品と非常に強く結びつかざるを得ない。
それは避けようがないと思う。
おそらく、買い手を惹きつける 外側の見た目 があって、実際に内部を動かしているものは買い手の関心事ではない、という意味ではないだろうか。
2つの層の間でインターフェースになる概念はいくつかあり得るが、内部がどう進化するかは外側の製品レイヤーから分離されているべき、という話に思える。
今ちょうどキッチンのリフォーム設計をしているのだが、この 3つの制約 はソフトウェアよりもっと一般的なデザイン作業にもかなり役立ちそうだと思う。
私もすぐ試してみるつもりだ。
単純すぎる気もするが、空間と流れで考えるともっと面白くなる。
人の流れ、光の流れ、食べ物の流れ、遷移のようなことを考えられるので、かなり面白い。