ハクソク

世界を動かす技術を、日本語で。

何かを作る前に考慮すべき三つの制約

1日前原文(jordanlord.co.uk)

概要

  • 創造性を引き出すための3つの制約について解説
  • ワンページルールで複雑さと曖昧さを排除
  • コア技術の分離で長期的な価値を創出
  • 明確な定義制約でプロダクトの個性を確立
  • いずれかの制約に合致しない場合は開発しない方針

創造性を引き出す3つの制約

  • 制約は創造性を妨げるのではなく、発想の幅を絞り込むことで革新的な解決策を導く手段
  • 10年以上の開発経験を経て、失敗から学び得た実践的な指針
  • 複雑すぎるプロダクトや、個性のないプロダクトは失敗の原因

ワンページルール

  • アイディアごとに1ページの要約文（ワンページャー）作成が必須
  • 複雑さと曖昧さの排除、目的やビジョンの明確化
  • ワンページャーは投資家、チーム、家族などあらゆる関係者への共通コミュニケーションツール
  • 議論や衝突点もワンページャーに基づいて判断
  • 1ページでまとめられない場合は、構想が未熟である証拠
  • 調査・計画・プロトタイプを経て再度ワンページャーを練り直す反復プロセス
  • 1ページを超える場合は複雑すぎるため開発しない判断

コア技術の分離

  • **プロダクト本体とは独立した「コア技術」**の開発が必須
  • **再利用可能なIP（知的財産）**としての価値創出
  • コア技術はプロダクトの方向転換にも耐えうる長期的資産
  • 例：Linus Torvaldsのgit、HashiCorpのHCL、GoogleのKubernetes
  • 大企業でなくても、ライブラリや独自手法など小規模でも実践可能
  • コア技術は自身や組織の長期ビジョンと一致している必要
  • コア技術を生み出せないアイディアはレバレッジが低く、開発対象外

明確な定義制約の設定

  • プロダクトの中心となる制約を明文化し、常にユーザー体験の核とする
  • この制約がプロダクトの個性や世界観を生み出す要素
  • 例：Minecraftのブロック、IKEAのフラットパック家具
  • 制約があることで意思決定の範囲が狭まり、本質的な課題に集中可能
  • 制約が曖昧・不適切だと、機能過多でアイデンティティのないプロダクトになるリスク
  • ワンページャーにもこの制約を明記し、設計の軸とすること

開発判断の最終ルール

  • 上記3つの制約のいずれかを満たさない場合は、絶対に開発しない方針
  • 制約を守ることで、明確な基準と高い完成度を維持

Hackerたちの意見

キッチンのリノベーションを考えてるんだけど、この3つの制約がデザインに役立つって分かるな。デザインのためにやってみるつもりだよ…
> 「一つの決定的な制約が製品を形作るべきだ… Minecraftは完全にブロックでできてる。IKEAはフラットパックのセルフアセンブリー家具だ。これらのことを「プロダクトプリミティブ」って呼んでる。どこでその言葉を聞いたかは忘れたけど、Notionのブロックとか、Telegramのメッセージや会話、Figmaのフレームやレイヤー、Twitterのツイート、Excelのセルやシート、Photoshopのツールやレイヤー、CLIのコマンドみたいなものを指してると思う。良いプロダクトデザインは、非常に少数のプリミティブを持つことだと思う。悪いプロダクトは、自分のプリミティブが何か分からないか、すごく多くのプリミティブを持ってる。プロダクトの中のすべてが独自の方法で動くユニークなものに感じる。だからユーザーはたくさんの異なるトップレベルのプリミティブや概念を学ばなきゃいけない。混乱するし、 intimidatingだし、教えるのも難しい。理想的には、1つか2つか3つの主要なプリミティブがあればいい。アプリの複雑さやパワーは、深みがあって組み合わせ可能な強力なプリミティブを選ぶことから来る。Notionのブロックでできることはたくさんあるし、Excelのセルでもできることは多い。CLIのコマンドでも、Minecraftのブロックでも、深みがあるんだよね。
└
この哲学はちょっと単純化しすぎかも。Tanaは基本的に2つのプリミティブ（バレットとスーパータグ）しかないのに、使うのがすごく複雑で、簡単なことをするために何時間もチュートリアルを見なきゃいけないくらいだ。一方で、Googleマップはたくさんの「プリミティブ」があるけど、90%のユースケースに対してはUXがかなりしっかりしてる。
└
これを「コンセプトカウント」って呼んでた。通常、製品を構成するコアコンセプトの数を最小限にしたいよね。製品の「名詞と動詞」って聞いたこともある。
└
> CLIのコマンド … 良い製品デザインに必要なのは、非常に少数のプリミティブだと思う。小さいけど、あまりにも小さくはない。具体例としては、シェルスクリプト（POSIXシェル、bash）で、スクリプト部分がコマンドとしてモデル化されることに決められたため、別の概念の束を導入しなかった。結果はみんな知ってるよね（熱い、遅い混乱）。
└
プログラミング言語を評価する時に、似たような指標を使ったことがある。言語が大きくても、概念的に小さければ学びやすいし、あとは経験で補完できるからね。概念的に大きい言語は、私にとってはハードルが高かった。特に感じたのはPerlだったな。
制約は過小評価されがちだよね。最もエレガントな解決策は、無限の自由度から生まれるんじゃなくて、特定の制約を念頭に置いて構築することから生まれると思う。これって1つ目のポイントとも関係してると思う：ワンページャーを作ることで、その制約を定義するのに役立つんだ。
ハッカーニュースの制約って何？
└
HTML 4.0
└
一番大きな制約の一つは、ユーザーには直接見えないけど、その影響は見えると思う。HNはArcという小さなLISP方言で作られていて、長い間パフォーマンスが良くなかった。ここに情報があるよ： https://lisp-journey.gitlab.io/blog/hacker-news-now-runs-on-...
└
- リンクとスレッドコメントを提出したばかり - 高度なランキングアルゴリズム - モデレートされた貢献と議論
ワンページのアイデアが大好き。制約をページ分書き出す時間がないなら、進むにつれてそれを発見するのに苦労することになるよ。これは「バグ」じゃなくて、「あ、間違ったものを作ってる」っていう欠陥なんだ。裏付けるデータはないけど、私の経験上、みんなが同じページに立つために時間をかけるプロジェクト（たとえそれが1ページの高レベルなもので、「これをやるし、これをやらない」っていうものでも）って、適当にやるプロジェクトよりも成功することが多い。適当にやるプロジェクトは、意見を持ってた人たちをいつも失望させる結果になるんだよね。
著者が制約の具体例を完全に示してくれたらよかったのに、3つ目が実際にどうなるのかちょっと分からないな。
著者は、私の元研究メンターと私がどのようにビジネスを構築したのか、その核心を見事に引き出してくれた。私たちは最初に後の二つのポイントから始めた。私たちのコア技術は、スパースデータのための任意の階層ベイズグラフモデルを実現するサンプラーで、制約はCPUに依存した計算可能性だった。私たちが最も長い時間をかけて発見したのは、最終製品は基盤技術とは別である必要があるということだった。これは、始める前から多くの人からいろんな言葉でアドバイスをもらったけど、学ぶためには実際に経験しなければならないこともあるんだよね。
└
コアの信念
> コア技術は製品から分離可能でなければならない うーん、でも、どの例も私には意味がわからない。特に： > GoogleにはKubernetesがある そうだね、それで？ GoogleはもともとPageRankというコア技術を中心に構築された製品だったんじゃない？
└
まあ、そうだけど、違う。ユーザーにとっては、何を基に作られているかは重要じゃなかった。重要なのは、その時点で利用可能なものよりもずっと速く、ずっと関連性のある検索ができたことだ。
ソロSaaSに追加したい制約は「今週中にベータユーザーを一人見つけられるか」だ。時間、範囲、技術は私のワンページにおいて合理的だったけど、プロジェクトはそのフィルターを通過しても、誰も来なければ死んでしまう。配布の制約を最初に加えることで、機能に深く入る前にオーディエンスを検証する必要があったんだ。
このページはどれくらい大きいの？フォントサイズは？