ポール・グレアム 53

生 1964年
米国のLispプログラマーでエッセイスト。『ANSI Common Lisp』や『ハッカーと画家』の著者としても知られている。...-ウィキペディア

私たちが創業者に最初はビジネスモデルを気にかけるなと言っているのは
人々が望む何かを作り上げることの方がずっと難しいからだ。

金を儲けるのが重要でないからではない。

アイデアのためのマーケットというのはあまりないのだ。
それが製品として実現され、ユーザベースが拡がるようになるまでは
誰もアイデアを信用しないのだ。
彼らはそれが実現されたときになって始めて大金を払う。

争いの多くは状況のためではなく、人のために起る。
それはつまり、争いは避けられないということだ。

入れてあげないと取り残されたように感じるだろうという理由で
同居者をあなたのスタートアップに加えないこと。
誰かがあなたの必要とするスキルを持っており
他に見つけられないかもしれないという理由で
嫌いな人をあなたのスタートアップに加えないこと。
人はスタートアップにとってもっとも重要な成分であり、そこで妥協してはいけない。

最も一般的なタイプの失敗は、見事に失敗するものではなく
たいしたことを何もしないというものだ。
スタートアップを殺す１８の誤り より
http://www.aoky.net/articles/paul_graham/startupmistakes.htm

多くのスタートアップは人々の望むものを作らないために失敗しており
そして多くのスタートアップがそれを作らない理由は
彼らが十分熱心に努力していないためなのだ。

思い切ってフルタイムでやっていれば成功できたのに、そうしなかったために失敗したという人たちもいると思う。
広告

あなたにコントロールできないものというのもいくつかある。
特に愚かさと不運がそうだ。

スタートアップを殺す１８の誤り より
http://www.aoky.net/articles/paul_graham/startupmistakes.htm

成功するスタートアップを作るには3つのことが必要になる。
優れた人たちと始めること、
顧客が実際に欲しがるものを作ること、
可能な限りわずかの金しか使わないこと。
失敗するスタートアップのほとんどは、これらのうちのどれかをやり損ねたために失敗している。
この3つをちゃんとやったスタートアップはたぶん成功するだろう。

スタートアップには解決に天才を要するような
魔術的で困難な部分というのは何もない。
スタートアップの始め方 より
http://www.aoky.net/articles/paul_graham/start.htm

重要なのはアイデアではなく、そのアイデアを持っている人々だ。
優れた人々はまずいアイデアを修正することができるが
いいアイデアがまずい人々を救うことはできない。
あなたが誰かに実施するようにと手渡せるようなものではないのだ。

営業であれば、ノーという答を決して受け取ろうとしないような人だ。
ハッカーであれば、コードにバグが残った状態でベッドに行くくらいなら
朝の4時まででも起きているような人だ。
広報であれば、自分の携帯でニューヨークタイムズの記者に
売込みの電話をかけるような人だ。
グラフィックデザイナなら、何かがしかるべき位置から2ミリずれていると
肉体的苦痛を感じるような人だ。
私たちのところで働いていた人たちはみんな、自分の領域に関してそういう動物だった。
広告

純粋に頭のいい人というのは
｢知らない｣｢たぶんあなたの方が正しい｣｢私はxのことは良く理解していない｣
というようなことを言える能力によって識別できる。
頭のいい人ほど、頭が良さそうに振る舞わなきゃいけないというプレッシャーを感じないものだ。
    純粋に頭が悪いひとは何も行動を起こさない。 - 銘無き石碑
    分からないことは分からないって言えてます。 - 銘無き石碑

ロバートのいるところでは誰も頭が良く見せようとすることはなかった。
ロバートが彼らより頭がいいだろうことは明らかであり
そのロバートは頭が良く見せようなどとはまるでしなかったからだ。
Viaweb共同創業者のロバート・T・モリスについて

大学でやるべきなのは、自分のプロジェクトに取り組むということだ。
それがプログラミングを学ぶ唯一本当の方法だからだ。

単に問題の解き方を変えるということではなく、解いている問題自体を変えるのだ。
これはプロジェクトのはじめにおいては特に価値がある。
http://www.aoky.net/articles/paul_graham/head.htm

あなたの書くコードは、探索している問題に対するあなたの理解を表している。
だから頭の中にコードを保持できたときに初めて
問題を本当に理解したと言えるのだ。
プログラムの全体を頭の中に入れたなら、それを思い通りに操れるようになる。

スケジュールされた気を散らすものは
不意の気を散らすものよりももっと有害になりうる。
1時間後にミーティングがあるとわかっていると、難しい問題に取り組もうという気にもならないだろう。

プログラムを書き直すためにはそのプログラムを完全に理解している必要があり
プログラムを頭の中に入れる方法としてこれ以上のものはない
http://www.aoky.net/articles/paul_graham/head.htm

人に読めるようにコードを書くのがいいことだとはわかっている。
しかし最も重要な読み手が誰かというと、それは自分自身なのだ。
入門書みたいに書き下してやれば、他の人が読みやすくなるかもしれない。
一方で自分の頭にロードしやすいようにコードを書こうとするときには、簡潔にするのが一番だ。

個々人の才能に依存するという考えを組織が嫌うのは
単に事実であるだけでなく、トートロジーと言える。
それが組織の定義の一部を成しているのだ。
少なくとも現在の我々の持つ組織という概念はそうだ。

「ソフトウェア会社」という言い方はそもそも矛盾を含んでいる。
二つの言葉は、逆の方向に引っ張っていこうとする。
ソフトウェアは即ちアイディアであり、個人から生まれるものだが
会社は個性を殺すことを必然的に行う

大きな組織にいるいいプログラマは組織と折り合いが悪いもので
それは組織というのがプログラマのやろうとすることを妨げるように
デザインされているためだ。
いいプログラマはそれでもどうにかして多くのことを成し遂げる。
しかしそのためには雇い主である組織に対して実質反逆といえる振舞に出ることがしばしば必要になる。

大企業の最大の弱点は、個々のプログラマに偉大な仕事をさせないということだ。
だからあなたが小さなスタートアップにいるなら、そこが攻撃すべき場所になる。
大きなひとつの頭の中で解く必要がある問題に取り組むことだ。

プログラミングをする上で一番難しいことは、
その人がどれくらい優れているかによって違います。
へたなプログラマには、へたな料理人と同じように、
プログラミングの仕組み自体が難しいものとなります。
一方優れたプログラマの場合には、優れた料理人と同じように、
やろうと思ったことは何でもできるので、
何を作るか決めるというのが一番頭を悩ませる部分になります。
http://www.aoky.net/articles/paul_graham/int.htm

優れたプログラマなら、プログラミングの仕事を見つけるのはいつだって簡単です。
経済状況の悪いときであっても、優れたプログラマは足らないものだからです。
http://www.aoky.net/articles/paul_graham/int.htm