ポール・グラハム：設計と研究

ポール・グラハム、 設計と研究 、2003年1月



ハッカーとアーティスト 、第15章

設計と研究

knagaevを翻訳していただきありがとうございます



（この記事には基本的に2002年秋のNEPLSでの基調講演が含まれています）



アメリカに来る人は、アメリカ人が「何をしているの？」という質問で会話を始めるのに驚かされることがよくあります。私はこの質問が好きではありませんでした。 私はそれに対してまともな答えをほとんど聞いていません。 しかし今、私はこの問題を解決したと思います。 今、誰かが私が何をしているのかと尋ねたら、私は彼をまっすぐ見て、「 新しいLisp方言を設計しています」と言います。私はこの答えを彼らの仕事に興味がない人にお勧めします。 会話はすぐに他のトピックに変わります。



プログラミング言語を勉強しているとは思わない。 私はそのうちの1つを設計していますが、誰かが建物、椅子、または新しいフォントをどのように設計できますか。 私は新しい何かを発見しようとはしていません。 プログラミングに適した言語を作成したいだけです。 ある程度までは、人生がずっと楽になります。



デザインと研究の違いは、新しいものと良いもののコントラストに似ています。 アーキテクチャソリューションは新しいものではありませんが、高品質でなければなりません。 この研究の結果は正確である必要はありませんが、新しいものでなければなりません。 これらの2つのパスは上に収束すると思います。最高のデザインは、新しいアイデアの使用に基づいて前任者を上回り、最高の研究は、実際には解決に値するほど新しいものではない問題を解決します。 そのため、最終的な分析では、1つのことを目指して努力します。異なる側面から移動するだけです。







今日は、あなたの目標がどのように見えるかについてお話したいと思います。 プログラミング言語を研究のトピックとしてではなく、デザインのオブジェクトとして考えるとき、あなたはどう違うのですか？



最大の違いは、ユーザーにより重点を置くことです。 設計は質問から始まります。これは誰のために、何のために必要なのでしょうか？ 特に、優れたアーキテクトは、ソリューションを作成してユーザーに強制的に絞るのではなく、可能性の高いユーザーを調べてニーズを評価することから始めます。



注意してください、私は「彼らの願い」ではなく「彼らのニーズ」と言いました。 デザイナーの仕事とは、クライアントだけが欲しくないものをすべて焼き上げるような仕事を意味するという印象を与えるつもりはありません。



「買い手は常に正しい」ということは、デザインがユーザーにとって有効であるということです。 誰もが退屈する小説を書いたり、ひどく不快な椅子を作った場合、あなたは時代遅れに働きました。 あなたは小説や椅子が最新の理論的原理を念頭に置いて設計されているという事実についてはまったく許されていません。



それでも、ユーザーに合ったものを開発することは、彼があなたに言うことをすることを意味しません。 ユーザーはすべての機能を知っているわけではなく、多くの場合、本当に欲しいものを間違えています。



私の意見では、このパラドックスの解決策は、ユーザー専用に設計する必要がありますが、彼が話しているウィッシュリストではなく、彼が必要とするものを設計することです。 これは治療に非常に似ています。 患者のみの症状を治療することはできません。 患者が彼の症状についてあなたに話すとき、あなたは彼の本当に悪いことを解明し、それを治療しなければなりません。



ユーザーの要件に焦点を当てることは、適切な設計の技術のほとんどが基盤としている原則の1つであり、ほとんどの問題が焦点を当てています。



正しいソリューションがユーザーの要件を満たす必要がある場合、このユーザーは誰ですか？ 設計はユーザー向けであるべきだと言っても、これは品質プロジェクトが最小公分母を目指すことを意味するものではありません。 必要なユーザーグループを選択できます。 たとえば、ツールを開発している場合、初心者から専門家まで誰でも設計できますが、あるグループにとっては良いソリューションになるものは、別のグループには受け入れられないかもしれません。 一番下の行は、ユーザーの特定のグループを選択する必要があるということです。 ある仮想ユーザーに関連する場合を除いて、あなたはデザインを貧弱に評価する権利さえ持っていないと思います。



おそらく、デザイナー自身がターゲットユーザーのグループに含まれる場合、優れたソリューションを実現できます。 関係のないグループのために何かを開発するとき、通常、これらの人々は自分に比べて単純であると考えることがわかります。



これは困難な状況です。なぜなら、ユーザーを軽、しているにもかかわらず、デザイナーは必然的に破損するからです。 アメリカでは、後に住むことを計画している建築家によって開発された住宅建築プロジェクトはほとんどないと思われます。 プログラミング言語でも同じことがわかります。 C、Lisp、Smalltalkは自分用に作成されました。 Cobol、Ada、およびJavaは、他の人が使用するために作成されました。



あなたがばかのために設計していると思うならば、あなたがばかのためにさえ、あなたが良い何かを作成するほとんどチャンスがありません。



それでも、最も資格のあるユーザー向けに何かを設計したとしても、それは人々のために行います。 研究分野の別の状況。 数学では、人々が簡単に理解できるように抽象化を選択しません。 プルーフを短くするものを選択します。 これはすべての主要な科学分野に当てはまると思います。 科学的な計算は人間工学的である必要はありません。



アートでは、すべてが異なります。 完全に人のために設計する。 人体は奇妙なデザインですが、椅子をデザインするとき、それはまさにあなたが何のために何をしているのかであり、それ以外の何のためでもありません。 芸術のすべての形態は、人間の願いと彼の欠点に応えるべきです。 たとえば、他の同じコンテンツでペイントする場合、人のいる写真は人のいない写真よりも面白いでしょう。 そして、これはルネサンスの偉大なキャンバスが人々の画像で満たされているという単なる歴史的な事故ではありません。 そうでなければ、芸術としての絵画はそれほど人気が​​ありません。



好むと好まざるとにかかわらず、プログラミング言語も人々を対象としています。人間の心は人間の体と同じくらい不器用で独特なものだと思います。 一部のアイデアは人々が簡単に把握でき、一部はそうではありません。 たとえば、個々の要素を操作する機能は非常に限られているようです。 これが、プログラミング言語をそもそも有用な発明にする理由です。 多くの要素を念頭に置くことができれば、マシンコードでプログラムするだけです。



また、言語は、原則として、既成のプログラムを作成するための手段ではなく、どのプログラムを開発する必要があるのか​​ということに注意してください。 芸術家なら誰でも、異なる状況では異なる素材が必要になるかもしれないと言うことができます。



たとえば、大理石は既製のアイデアをデザインするための美しく信頼性の高い素材ですが、新しいアイデアを作成するのにはふさわしくありません。



証明のようなプログラムは、誤って分岐を開始し、不良な分岐が削除されるツリーです。 そのため、言語の品質をチェックすることは、完成したプログラムがどれほど美しく見えるかではなく、この完成したプログラムへの道がどれほど単純かということです。 完成したプログラムの優雅さを提供するオプションは、必ずしもエレガントな開発プロセスを提供するわけではありません。 たとえば、小さなダイヤモンドのように見えるネストされた逆引用符でいっぱいのマクロ定義を使用していくつかのマクロを書いたが、それらを書くことは試行錯誤によってうんざりするコーディングに何時間もかかりました、そして正直に言うと、それらが完全にあるかどうかは完全にはわかりません完璧です。



多くの場合、完成したプログラムの外観を使用して言語を評価します。 2つの異なる言語で書かれた問題の解決策を検討すると、これは非常に妥当なように見え、プログラムのバージョンの1つが他のバージョンよりもはるかに短いことが判明しました。 しかし、芸術の観点からこの問題に取り組むと、おそらくこの方法でのテストへの依存度は低くなります。 最終的に大理石のようなプログラミング言語を手に入れたいとは思わないでしょう。



たとえば、ソフトウェア開発の大きなブレークスルーはトップレベルのインタラクティブ環境であり、LispではREPL環境またはread-eval-printループと呼ばれます。 そして、そのような環境が実現されると、言語の設計に実際の効果があります。 たとえば、使用する前に変数を宣言する必要がある言語ではうまく機能しません。 対話式環境で単純に式を入力する場合、x値を割り当てて使用を開始します。 最初に型xを宣言することを強制されたくありません。 これらの各仮定に挑戦することができますが、実装されたトップレベル環境を持つ言語が便利な言語と見なされ、必須の型宣言がこの環境と互換性がない場合、型宣言を必須にする言語はどれもプログラミングに便利ではありません。



実際には、優れたデザインを実現するためには、ユーザーの親しい友人になって、それらを維持する必要があります。 特に初期段階では、実際のユーザーを使ってアイデアを継続的に磨く必要があります。 ジェーンオースティンの小説がとても良い理由の1つは、彼女が家族に大声で読んだことです。 だからこそ、彼女は自分の弱点を決して甘やかすことはなく、風景や哲学の哲学の美的描写に陥ることはありませんでした。 （哲学は存在していましたが、物語のように織り込まれ、ラベルのように上にくっついていませんでした。）「文学」の平均的なサンプルを開いて、自分で書いたように友達に声を出して読んだと想像すると、読者に何がかかるのかをはっきりと感じるでしょう。



ソフトウェア開発の世界では、このアイデアは「悪いほど良い」として知られています。 実際、この概念にはいくつかのアイデアが組み合わされていますが、その真理はまだ議論されています。 しかし、このコンセプトの主要なコンポーネントの1つでは、新しいものを開発する場合は、できるだけ早くプロトタイプをユーザーの前に置く必要があると述べています。



逆のアプローチは、Hale Mary戦略（「幸運を祈る」）と呼ばれます。 プロトタイプを迅速にリリースしてから徐々に改善するのではなく、タッチダウン付きの1つのロングパスとして完全な完成品をすぐに作成することができます。 私の知る限り、これは災害のレシピです。 この道は、ドットコムバブルの間に無数のスタートアップによる自己破壊をもたらしました。 このアプローチが機能する単一の事例は聞いたことがありません。



プログラミングの世界以外では、「悪いほど良い」という原則がアートの至る所に見られることに気付かない人もいるかもしれません。 たとえば、視覚芸術では、この考えはルネッサンスの間に発見されました。 ほぼすべての描画教師が、正確な画像を取得するための唯一の正しい手法は、オブジェクトの輪郭に沿ってゆっくりと移動することではないことを教えてくれます。不正確さが蓄積され、最終的に線が一致しないことがわかります。 それどころか、適切な場所でいくつかのクイックストロークをスケッチしてから、この最初のスケッチを徐々に改良する必要があります。



芸術の多くの分野では、プロトタイプを作成するために他の材料が長い間使用されてきました。 金属から切り取られたフォントの行列は、最初にブラシで紙に描かれます。 青銅で鋳造するための彫像は、ワックスから事前に成形されています。 タペストリー刺繍の飾りはインクで紙に描かれています。 石造りの建物は、木製模型の形で縮小されたスケールで検査されます。



15世紀に人気が出たときに油彩画がとても有望だったのは、プロトタイプから最終結果を得る機会でした。 必要に応じて、大まかなドラフトを作成できますが、添付されていません。 すべての詳細を明確にし、それに取り組むプロセスで大幅な変更を加えることができます。



ソフトウェアを使用すると、同じことができます。 プロトタイプは単なるレイアウトである必要はありません。 変更して最終製品を入手できます。 これが可能な場合は、すべての場合にこれを行うべきだと思います。 これにより、開発プロセス中に生じる新しい洞察を活用できます。 しかし、非常に可能性が高く、さらに重要なのは、プロトタイピングが前向きな姿勢に役立つことです。



ポジティブな仕事精神はデザインの決定的な要因です。 注目する人が少ないことに驚かされます。 私の最初の絵師の一​​人が私に言った：あなたが絵を描いて退屈していると、あなたの絵は退屈になるだろう。 たとえば、建物を描く必要があり、各レンガを個別に描くことにしたとします。 必要に応じてそれを行うことができますが、途中で退屈を感じ、それぞれの品質を観察するのではなく機械的にレンガを彫刻し始めると、画像を指定した場合よりも悪くなります。



プロトタイプを徐々に改善しながら何かを作成することは、あなたが情熱を持ち続けるため、気分に良いです。 ソフトウェア開発では、このルールがあります。コードは常に機能している必要があります。 1時間以内に確認できるものを書くと、やる気を起こさせる迅速なプロモーションの見込みがあります。 アート、特に油絵でも同じことが言えます。 ほとんどのアーティストは漠然としたスケッチから始まり、徐々にそれを描きます。 このような方法で作業する場合、未完成に見える何かのために夕方に本質的に停止することはありません。 確かに、アーティストには「図面は決して完成することはできません。作業をやめることしかできません」という格言さえあります。 この考え方は、ソフトウェアを開発した人なら誰でも知っています。



態度は、熟練していないユーザーのために何かをすることが難しいもう1つの理由です。 自分が嫌いなものに興味を持ち続けるのは難しいです。 良いものを作成するときは、「すごい、それは本当に素晴らしい」と考えるべきであり、「一体何なのか」ではありません。 まあ、これらのバカはそれを好きになるでしょう。」



設計は、人々の創造性として理にかなっています。 しかし、ここでは人々は単なるユーザーではありません。 デザイナーも人間です。



通知、私は常に特定の個人としての「デザイナー」について話します。 設計ソリューションが任意の品質であることが判明するためには、単一の専門家の監督の下で開発する必要があります。 同時に、1人の研究プロジェクトで複数の人が一緒に作業することも許容されると考えられます。 私にとって、これはデザインと研究の最も興味深い違いの1つと思われます。



芸術における集団研究の事例は知られていますが、それらのほとんどは核融合のようではなく、分子化合物のように見えます。 オペラのジャンルでは、一人が台本を書き、もう一人が音楽を書くときによく起こります。 ルネサンス期には、北欧の見習いがしばしば雇われ、イタリアの巨匠の背景画の風景を描きました。 しかし、これは本当の協力ではありません。 これらのケースは、ロバート・フロストのフレーズをより連想させます：「良いフェンスのために-良い隣人」。 良いデザインのパーツを接着することはできますが、各パーツには個々のプロジェクトの所有者が1人必要です。



良いプロジェクトが、一人がすべてを熟考することを要求するという意味ではありません。 信頼できる決定を下す専門家のアドバイスほど価値のあるものはありません。 しかし、議論が完了した後、最終的な選択は責任のままです。



なぜ研究は一緒に実施できるのに、設計はできないのですか？ これは興味深い質問です。 そして、私は答えを知りません。 おそらく、設計と研究が同時に行われると、最良の研究結果が優れた設計になり、実際の生活ではこれを共著者が行うことはできません。 最も有名な科学者の膨大な数はおそらく一人で働いていたでしょう。 しかし、ここにパターンがあるかどうかを言うのに十分なデータがありません。 たぶん、集合的な創造性がまだ一般的ではなかった時代に、多くの有名な科学者が働いていたという事実だけかもしれません。



しかし、科学やアートのように、本当の集団的創造性は、めったにありません。 共同設計決定は、不十分な設計決定と同義です。 これはなぜですか？ これを回避する方法はありますか？



私はそうは思わない傾向があります-良いプロジェクトには独裁者が必要です。 その理由の1つは、すべてのコンポーネントの品質が同じで、優れた設計が堅実であるべきだということです。 決定が1人の頭に収まるアイデアである場合、ユーザーの頭にも収まる可能性があります。



（まだ新鮮- ポール・グラハム：「Why Y Combinator？」とポール・グラハム：ハイテク社会 ）

---

本「ハッカーとアーティスト」









別の107+記事ポール・グレアム Habré。

（翻訳を手伝いたい人-接続）



Y Combinatorに興味があり、Grahamのアイデアがあなたに近い場合は、個人的な手紙に書いてください。いくつかのアイデアがあります。



あなたのスタートアップはY Combinatorに応募する準備ができていますか？