A Project of One's Own

Paul Graham

自分だけのプロジェクト

数日前、学校からの帰り道、9歳の息子が「早く家に帰って、書いている物語の続きを書きたい」と言いました。こんなに嬉しかったことはありません。物語に夢中になっているからというだけでなく、この働き方――自分だけのプロジェクトに取り組むというやり方――を見つけたのだと分かったからです。自分だけのプロジェクトに取り組むことは、普通の仕事とはまったく違います。歩くのとスケートで滑るくらい違うのです。より楽しく、そしてはるかに生産的でもあります。

この意味で滑りながら成し遂げられた偉大な仕事は、どれくらいあるのでしょうか。すべてではないにしても、確実にその多くはそうだったはずです。

自分だけのプロジェクトに取り組むことには、特別な何かがあります。幸せだと正確に言うつもりはありません。むしろ「わくわくしている」「夢中になっている」と言った方が近いでしょう。物事がうまくいっているときは幸せですが、多くの場合そうはいきません。私がエッセイを書いているときも、たいていは不安と困惑の中にいます。エッセイが駄作に終わるのではないかという不安と、まだはっきりと見えていないアイデアを手探りで追っていることへの戸惑いです。それを言葉で捉えることができるだろうか。たいていは、十分に時間をかければ最後にはできますが、最初から確信できるわけではありません。最初の数回はうまくいかないこともよくあります。

うまくいけば幸せな瞬間が訪れますが、それは長くは続きません。すぐに次の問題に取りかかることになるからです。では、なぜわざわざそんなことをするのでしょうか。こういう働き方を好む人にとっては、ほかにしっくりくるものがないからです。まるで生き物が本来の生息地で、本来すべきことをしているような感覚です。いつも幸せとは限りませんが、目が覚めている、生きているという実感があります。

多くの子どもが、自分だけのプロジェクトに取り組むわくわく感を経験しています。難しいのは、それを大人になってからの仕事へとつなげていくことです。そして私たちの慣習がそれをさらに難しくしています。「遊び」や「趣味」は「仕事」とは質的に違うものとして扱われています。ツリーハウスを作っている子どもにとって、そこから建築やエンジニアリングへと続く直接的な――たとえ長いとしても――道があることは明らかではありません。そして私たちは、その道を示すどころか、子どもたちがやっていることを本当の仕事とは違うものとして暗黙のうちに扱うことで、その道を覆い隠してしまっています。[1]

子どもたちに「君たちのツリーハウスは、大人になってからの仕事へとつながっているんだ」と伝える代わりに、私たちは「その道は学校を通るんだ」と教えます。そして残念なことに、学校の勉強は自分だけのプロジェクトとはまったく異なることがほとんどです。たいてい、それはプロジェクトでもなければ、自分のものでもないのです。だから学校が本格的になるにつれて、自分だけのプロジェクトに取り組むことは、あったとしても脇へ追いやられた細い糸のように残るだけになってしまいます。

高校生たちがみなツリーハウス作りに背を向け、試験に合格するためにダーウィンやニュートンについてせっせと暗記している姿を思うと、少し悲しくなります。ダーウィンやニュートンを有名にした仕事は、実際には試験勉強よりも、ツリーハウス作りの精神にはるかに近かったのですから。

もし子どもたちに良い成績を取らせることと、野心的な自分だけのプロジェクトに取り組ませることのどちらかを選ばなければならないとしたら、私は迷わずプロジェクトを選びます。甘やかしているからではありません。逆の立場を経験して、どちらが将来を予測するうえで価値があるかを知っているからです。Y Combinatorでスタートアップを選んでいたとき、応募者の成績は気にしませんでした。しかし、自分だけのプロジェクトに取り組んだ経験があれば、その話はぜひ詳しく聞きたいと思いました。[2]

学校が今の形であることは、あるいは避けられないのかもしれません。作り直すべきだと言いたいわけではありません(かといって、そうでないとも言いません)。ただ、学校が私たちの仕事に対する姿勢に何をしているのかを理解すべきだということです。学校はしばしば競争を餌にして、私たちを従順にこつこつとこなすタイプの仕事へと向かわせ、滑るような働き方から遠ざけます。

学校の勉強が自分だけのプロジェクトになるときが、たまにあります。私の場合、論文を書かなければならないときは、それが自分だけのプロジェクトになりました――皮肉なことに英語の授業を除いては、ですが。英語の授業で書かされるものはあまりにもインチキだったからです。そして大学に入り、コンピュータサイエンスの授業を取り始めると、書かなければならないプログラムが自分だけのプロジェクトになりました。何かを書いているときも、プログラミングをしているときも、私はたいてい滑っていましたし、それは今も変わりません。

では、自分だけのプロジェクトの境界線は、正確にはどこにあるのでしょうか。これは興味深い問いです。答えがとても複雑だからでもありますし、そこに大きなものがかかっているからでもあります。仕事が「自分のもの」であるということには、実は二つの意味があることが分かります。一つは、誰かに言われたからやるのではなく、自発的にやっているということ。もう一つは、それを自分一人でやっているということです。

前者の境界線はかなりはっきりしています。仕事に強いこだわりを持つ人は、引っ張られて進むのか、押されて進むのかの違いにとても敏感です。そして仕事はたいてい、どちらかに分かれます。ただし、言われたことをやるかどうかが単純な判定基準になるわけではありません。言われたことでも、自分から選んでやることはできます。実際、そう指示した人よりも、ずっと徹底的に自分のものにすることさえできるのです。

たとえば、数学の宿題は多くの人にとって言われてやるものです。しかし数学者だった父にとっては違いました。私たちの多くは、数学の教科書の問題を、各章で説明された内容への理解を試したり深めたりするためのものと考えます。しかし父にとって重要だったのは問題の方で、本文は単なる注釈のようなものでした。新しい数学の本を手に入れると、それは父にとってパズルを与えられたようなものでした。そこには解くべき新しい問題が詰まっており、父はすぐにそのすべてを解きにかかるのでした。

もう一つの意味での「自分のプロジェクト」――自分一人で取り組むということ――の境界線は、ずっと曖昧です。それは徐々にコラボレーションへと溶け込んでいきます。興味深いことに、その溶け込み方には二通りあります。一つは、一つのプロジェクトを共有する形でのコラボレーションです。たとえば、二人の数学者が会話の中で形になっていく証明に共同で取り組むような場合です。もう一つは、複数の人がそれぞれ自分のプロジェクトに取り組み、それらがジグソーパズルのように組み合わさる形です。たとえば、一人が本の本文を書き、もう一人がグラフィックデザインを担当するような場合です。[3]

もちろん、この二つのコラボレーションの形は組み合わせることもできます。しかし条件が整えば、自分だけのプロジェクトに取り組むわくわく感は、大組織の乱流の中に拡散してしまうまで、かなり長い間保つことができます。実際、成功した組織の歴史は、そのわくわく感を保つための技術の歴史でもあるのです。[4]

初期のMacintoshを作ったチームは、この現象の素晴らしい例です。バレル・スミスやアンディ・ハーツフェルド、ビル・アトキンソン、スーザン・ケアといった人たちは、ただ命令に従っていたわけではありません。彼らはスティーブ・ジョブズに打ち出されたテニスボールではなく、ジョブズによって解き放たれたロケットだったのです。彼らの間には多くのコラボレーションがありましたが、誰もがそれぞれ自分だけのプロジェクトに取り組む興奮を感じていたように見えます。

アンディ・ハーツフェルドはMacintoshについての本の中で、彼らが夕食後にオフィスに戻り、夜遅くまで働いた様子を描いています。自分が夢中になれるプロジェクトに取り組むスリルを経験したことがない人は、このような長時間労働を、汗水たらす工場や詰め込み営業所での長時間労働と区別できません。しかし両者はまったく対極にあります。だからこそ「ワーク・ライフ・バランス」を独断的に主張するのは間違いなのです。そもそも「ワーク/ライフ」という表現自体が間違いを含んでいます。仕事と生活が別物であるという前提があるからです。「仕事」という言葉から自動的に従順にこつこつこなすタイプの仕事を思い浮かべる人にとっては、確かに別物でしょう。しかし滑るように働く人たちにとって、仕事と生活の関係はスラッシュよりもダッシュで表す方が適切です。私は、自分の人生を乗っ取りたいと思えないような仕事はしたくありません。

もちろん、Macintoshのようなものを作っているときは、このレベルのモチベーションを達成しやすいのは確かです。新しいものは、自分のプロジェクトのように感じられやすいのです。それが、プログラマーが書き直す必要のないものを書き直したり、すでに存在するものの自分版を作ったりしたがる理由の一つでもあります。これはしばしばマネージャーを不安にさせますし、タイプされた文字数だけで測れば、最適な解決策であることはめったにありません。しかし、それは単に傲慢さや無知から来ているわけでもないのです。ゼロからコードを書く方がはるかにやりがいがある――優秀なプログラマーなら、文字数を驚くほど無駄にしたとしても、差し引きで得をするほどにやりがいがあるのです。実際、資本主義の利点の一つは、このような書き直しを奨励する点にあるのかもしれません。何かをするためのソフトウェアが必要な企業は、他社ですでに書かれたソフトウェアを使うことができないため、自分たちで書かなければならず、その結果、しばしばより良いものができあがるのです。[5]

滑るように働くことと、新しい問題を解くことの自然な親和性は、スタートアップの見返りがこれほど大きい理由の一つでもあります。未解決の問題は市場価格が高いだけでなく、そうした問題に取り組むときには生産性が割引になるからです。実際、生産性は二重に上がります。白紙から設計するときは、滑るように働く人を採用しやすくなりますし、彼らはすべての時間を滑ることに費やすことができるのです。

スティーブ・ジョブズは、スティーブ・ウォズニアックを見てきたことで、滑るように働く人についてよく理解していました。適任の人さえ見つけられれば、最も高いレベルで何をすべきかを伝えるだけでよいのです。細部は彼らが引き受けてくれます。いや、むしろそうさせてほしいと主張するのです。プロジェクトを自分のものだと感じるためには、十分な自律性が必要です。指示通りに働いたり、官僚主義に足を引っ張られたりしていてはなりません。

自律性を確保する一つの方法は、上司をまったく持たないことです。それには二つのやり方があります。自分自身が上司になることと、仕事以外の場でプロジェクトに取り組むことです。財政的な規模では正反対に位置しますが、スタートアップとオープンソースプロジェクトには多くの共通点があります。どちらも滑るように働く人たちによって運営されていることが多いという点を含めて。そして実際に、規模の一方の端からもう一方の端へと抜けるワームホールがあります。単に楽しいからという理由でプロジェクトに取り組むことが、スタートアップのアイデアを発見するための最良の方法の一つなのです。

もしあなたのプロジェクトがお金を生むタイプのものであれば、それに取り組むのは簡単です。そうでないときは難しくなります。そしてたいてい、最も難しいのは士気を保つことです。そこが大人が子どもよりも難しいところです。子どもは、時間を無駄にしているかどうかや、他のツリーハウスと比べてどうかなど気にせず、ただ飛び込んでツリーハウスを作ります。正直なところ、この点で私たちは子どもから学ぶべきことがたくさんあります。大人の多くが「本当の」仕事に対して持っている高い基準は、必ずしも私たちの役に立つとは限りません。

自分だけのプロジェクトで最も重要な局面は、最初の段階です。「xをやったら面白そうだな」と思うところから、実際にxをやり始めるところへ移る瞬間です。そしてその時点では、高い基準は役に立たないどころか、むしろ有害でさえあります。あまりに多くの新しいプロジェクトを始めてしまう人は少数ですが、失敗への恐れから、やれば成功したはずのプロジェクトを始めない人の方が、はるかに多いのではないかと思います。

しかし、子どもの頃にツリーハウスが大人になってからのプロジェクトへと続く道の上にあると知って恩恵を受けられなかったとしても、大人になった今、自分のプロジェクトがツリーハウスへと遡る道の上にあると知ることで、恩恵を受けることはできます。新しいことを始めるときに、子どもの頃に持っていたあの無邪気な自信を覚えているでしょうか。あれを取り戻すことができれば、とても強力な武器になります。

大人になると、あのような自信を保つのがより難しいとしても、私たちは少なくとも自分が何をしているのかをより意識できるようになります。子どもは、次から次へとある働き方から別の働き方へ、ほとんど何が起きているのかわからないまま、飛び跳ねたり、追い立てられたりします。一方で私たちは、さまざまなタイプの仕事についてより多くを知り、どれをやるかをより自分で選べます。理想的には、両方の世界の良いところを併せ持つことができます。すなわち、自分のプロジェクトに取り組むことを意識的に選びつつ、新しいことを始めるときには無邪気に自信を持つということです。

[1] 「hobby(趣味)」という言葉は不思議な言葉です。今では「本当の」仕事ではない仕事――評価の対象にならない仕事――を意味しますが、もともとは子どもが木馬(hobby-horse)にまたがるように、人がまたがる強迫観念全般(たとえば政治的意見でさえ)を比喩的に指していました。最近の、より狭い意味が良い変化なのか悪い変化なのかは判断が難しいところです。確かに誤判定はたくさんあります――当初は単なる趣味として退けられながら、結局は重要なものになるプロジェクトがたくさんあるのですから。しかし一方で、この概念は初期の醜いアヒルの子のような段階にあるプロジェクトにとって、貴重な隠れ蓑にもなっています。

[2] いわゆる教育熱心な親たちは、親がよくそうであるように、前回の戦争を戦っています。成功への道が、あらかじめ決められた梯子を登りながら資格を身につけることだった昔は、成績がより重要でした。しかし彼らの戦術が成績に集中しているのは、むしろ好都合です。もし彼らがプロジェクトの領域にまで侵入し、子どもたちにそれを強制することでこの種の働きへの嫌悪感を植え付けてしまったら、どれほどひどいことでしょう。成績はすでに厳しく偽りに満ちた世界であり、親の介入でそれほど害を受けることはありません。しかし、自分だけのプロジェクトに取り組むことは、より繊細で私的なものであり、とても簡単に傷ついてしまうのです。

[3] 自分だけのプロジェクトに取り組むことと他者とコラボレーションすることの間の、複雑で緩やかな境界線は、「孤高の天才」という考えについてこれほど意見が分かれる理由の一つです。実際には人々はさまざまな形でコラボレーションしたりしなかったりしますが、「孤高の天才」という考えがまったくの神話というわけでもありません。特定の働き方に伴う、確かな真実の核があるのです。

[4] コラボレーションもまた強力です。理想的な組織は、コラボレーションとオーナーシップの両方へのダメージが最小になるように両者を組み合わせるでしょう。興味深いことに、企業と大学の学部は、この理想に正反対の方向から近づいています。企業はコラボレーションを必須としつつ、ときに滑るように働く人を採用し、滑らせてあげることにも成功します。一方、大学の学部は独立した研究ができること(それが実際に滑るように働いているかどうかに関わらず、慣習的にそう見なされています)を必須とし、採用された人々は望むだけコラボレーションするのです。

[5] もし企業が、そこに新しくやって来た優秀なプログラマーが常に白紙の状態から始められるようにソフトウェアを設計できれば、一種の永遠の若さを保つことができるかもしれません。それは不可能ではないかもしれません。十分に明確なルールを持つゲームを定義するソフトウェアの基盤があれば、個々のプログラマーがそれぞれ自分のプレイヤーを書くことができるでしょう。

謝辞 Trevor Blackwell、Paul Buchheit、Andy Hertzfeld、Jessica Livingston、Peter Norvigの各氏に、この草稿を読んでいただいたことに感謝します。

原文は Paul Graham により に公開されました。

この記事は「muse-spark-1.2-contributor」を使用して翻訳されました。