Original English language title:
The Passionate Programmer: Creating a Remarkable Career in Software Development by Chad Fowler
Published by The Pragmatic Programmers, LLC
Copyright c 2009 Chad Fowler
Translation Copyright c 2010 Ohmsha, Ltd.
All rights reserved.
No part of this book may be reproduced, stored in a retrieval system, or transmitted, in any form, or by any means, electronic, mechanical, photocopying, recording, or otherwise, without the prior consent of the publisher. 本書を発行するにあたって、内容に誤りのないようできる限りの注意を払いましたが、本書の内容を適用した結果生 じたこと、また、適用できなかった結果について、著者、出版社とも一切の責任を負いませんのでご了承ください。 本書に掲載されている会社名・製品名は一般に各社の登録商標または商標です。 本書は、「著作権法」によって、著作権等の権利が保護されている著作物です。本書の複製権・翻訳権・上映権・譲渡 権・公衆送信権（送信可能化権を含む）は著作権者が保有しています。本書の全部または一部につき、無断で転載、複 写複製、電子的装置への入力等をされると、著作権等の侵害となる場合がありますので、ご注意ください。 本書の無断複写は、著作権法上の制限事項を除き、禁じられています。本書の複写複製を希望される場合は、そのつ ど事前に下記へ連絡して許諾を得てください。 • オ ー ム 社 開 発 部「 情 熱 プ ロ グ ラ マ ー ソ フ ト ウ ェ ア 開 発 者 の 幸 せ な 生 き 方 」係 宛 、E-mail（ kai-hatu@ohmsha.co.jp）または書状、FAX（03-3293-2825）にて
“The Passionate Programmer”
読者の声
もし君がソフトウェアを書く技術に情熱を傾けているなら、もし君がすごいソフト ウェア開発者になりたいなら、もし君が自分の仕事が大好きなら、あるいは、もし 君が業務でソフトウェアを書く人ではなくソフトウェア開発の専門化になりたいな ら、この本を読むといい。この本には、自分の仕事に敬意をもち、愛せるようにな るための実用的な経験則、習慣、それに態度が見事に記されている。I
Bob Martin
,
社長, Object Mentor, Inc.
この本には、具体的な方策、つまり実行できる話が満載だ。自分の状況に対する責 任は、自分自身にある。この本は、自分が一人ぼっちではないこと、自分の状況だ けが特別に恐ろしいものではないこと、今日できること、明日できること、そして、 これから先ずっとできることを教えてくれる。
I
Kent Beck
,
プログラマーChad
の本を読む6
カ月ほど前、僕は仕事を変えようかと悩んでいた。11
月から5
月まで続いたさまざまな出来事を通じて、僕はソフトウェア開発者であり続けるこ とに決めた。それも偉大なソフトウェア開発者になりたいという情熱を持って。今 君が手にしているこの本には、その目標への道のりを照らす刺激がいっぱいだ。I
Sammy Larbi
,
スパゲッティ コーダー 主任, codeodor.com
日本の読者の皆さんへ
日本文化を愛して止まない者であり、日本人の血を引く者の一人（僕の母親の母 親は日本人だ）として、“The Passionate Programmer”
の日本語版にこの特別な ページを書けるのは、この上ない喜びだ。日本語版の翻訳制作中に、僕は、「
The Passionate Programmer
」というタイト ルの意味について教えてくれないかと訊かれた。僕は次のように答えた： 「Passionate Programmerというタイトルは、牽引、決断、技巧の追求、創造性、 熱意、できる限り最上でありたいという欲求、といったことを示唆している。」 こ れが僕にとって、キャリアという文脈における情熱の意味だ。 僕には情熱について数年かけて学んできたことがある。この本を読むときは、そ れを心に留めておいてほしい。すなわち、情熱とは君のクリエイティブなエネル ギーの一番の源だ。君がアーティスト、ミュージシャン、プログラマ、ライター、 その他職人的な人間なら、君が君の仕事をする上で獲得し、消費するエネルギーの 基本単位が情熱だ。そして、情熱というのは再生可能なエネルギーだけれども、再 生するまでに時間がかかるから、賢く使わなきゃならないと僕は思っている。 ある種の作業は、消耗するのと同じくらいの割合で情熱的なエネルギーを生成す る。それに対し、情熱をとても速く燃焼し、欠損したままにしてしまう作業もある。 情熱のないプログラマは良いプログラマとは言えない。でもありがたいことに、情 熱はこうあるべきだ、なんていう決まりはない。情熱はあくまでも資源であり、各 自が責任をもって使えばいい。 僕はこれを事実として知っている。僕は、2000
年代の前半の2
年間を、賢くな いキャリア選択と情熱の消耗に費やしてしまった。その2
年間の終わりには、僕は ただ生活のためにプログラミングをしなくちゃならない、疲れきっていて創造的で ない人間になっていた。この間違いを犯す前に自分の仕事について尋ねられていた ら、「魅力的な品物を創造するソフトウェア開発者だ」と誇らしげに答えていたこ とだろう。情熱が枯渇した後、僕のパフォーマンスは人並みとなり、やる気もなく なってしまっていた。 僕は、この本が、君が選ぶ道でどのように成功するかのアドバイスを提供すると 共に、君の情熱をどのように使うかについて正しく選択する上での助けになると信 じている。どんなに意思を強く持ってもキャリアは見誤ってしまうものだ。これは 僕が過ちの2
年間から得た教訓である。でも、もし僕らが自身の情熱に従うなら、 僕ら自身や顧客にとってベストの選択ができるだろう。2010
年2
月Chad Fowler
vii本書に寄せて
誰もが光る部分を内に秘めているが、それを発揮するにはやりがいのあることを 見つけないといけないと思う。自分の環境や、自分の道具や、自分の専門分野を好 きになれなければ、輝かしいことはできない。僕自身、
37signals
とRuby on Rails
にひらめきを覚える前はいろいろな仕事を経験したが、目覚ましい結果は出せなかった。毎日をただなんとなく過ごしていた。 いつの間にか半年が過ぎても、これといった成果は何ひとつなかった。 とても悔しかった。僕がいてもいなくても関係ない、僕が仕事をしようがしまい が世界は大して変わらない、と思うのは嫌なものだ。自分が輝くためには、この世 界に何かしら影響を及ぼせるという実感が必要だ。 仕事がぱっとしなかった頃、それは私生活にまで及んだ。仕事中に何かを成し遂 げている実感がないせいで、仕事が終わった後も、これといったことをやってみる 気持ちになれなかったのだ。 僕にとっては、輝かしいキャリアを目指すことは、輝かしい人生を目指そうとい う意欲に火をつける一番いい方法だ。働く者として向上するだけでなく、人間とし ても向上できる。 この本の意義はそこにある。より良い製品を作って仕事を確保することだけが大 切なのではない。より実りある人生を送るためのスキルと感性を磨くことも大切 だ。人生には素晴らしいことがたくさんある。仕事はそのひとつにすぎない。
I
David Heinemeier Hansson
, Ruby on Rails
作者, 37signals
パートナー謝辞
Dave Thomas
とAndy Hunt
がいなければ、僕が本を書くことは決してなかったと思う。『
The Pragmatic Programmer
』[HT00]
*1は僕に衝撃を与えた本であ り、それ以来、僕はいつも彼らの仕事に刺激を受けている。Dave
の励ましと指導 がなければ、このような本が書けるとは自分自身全く思わなかっただろう。Susannah Pfalzer
は、この本の第2
版の編集を担当してくれた。「編集」とはつ まり、尻を叩き、励まし、支え、推し進め、そしてもちろん……編集してくれたと いうことだ。この本を完成できたのは、彼女が辛抱強く、しかも僕を怖気付かせず に鼓舞することを言ってくれたおかげだ。Susannah
がいなかったら、この本はま とまりのない中途半端な考えの羅列に終わっていただろう。David Heinemeier Hansson
は「本書に寄せて」を書いてくれた。37signals
のパートナーであり、
Rails
の作者である彼の経歴は、この本で言いたいことの輝 くばかりの見本だ。また、仕事で出会った素晴らしい人々の協力を得ることができ たのも幸運だった。Stephen Akers
、James Duncan Davidson
、Vik Chadha
、Mike Clark
、Patrick Collison
、Tom Preston-Werner
、僕とこの本の読者への助 言をありがとう。第
2
版の原稿には、多くのレビュー担当者から優れたフィードバックをもらっ た。最初の原稿にこれほど欠陥があることにはいつも驚くが、素晴らしいレビュー 担当者のおかげで見違えるようになるのも驚きだ。Sammy Larbi
、Bryan Dyck
、Bob Martin
、Kent Beck
、Alan Francis
、Jared Richardson
、Rich Downie
、Erik
Kastner
に感謝する。Juliet Thomas
は編集者として本書の第1
版の執筆初期段階から協力してくれた。彼女の熱心さと視野の広さには大いに助けられた。第
1
版のレビューを担 当してくれたCarey Boaz
、Karl Brophey
、Brandon Campbell
、Vik Chadha
、Mauro Cicio
、Mark Donoghue
、Pat Eyler
、Ben Goodwin
、Jacob Harris
、Adam
Keys
、Steve Morris
、Bill Nall
、Wesley Reiz
、Avik Sengupta
、Kent Spillner
、Sandesh Tattitali
、Craig Utley
、Greg Vaughn
、Peter W. A. Wood
からは、驚 くほど多くのフィードバックをもらった。彼らのおかげでこの本は本当に良くなっ た。彼らが本書に割いてくれた時間、労力、洞察に対しては、いくら感謝しても足 りない。 この本で紹介している考え方は、幸運にも長年にわたって公私共々巡り合う機会 があった多くの優れた人たちからヒントを得たものだ。相談に乗ったり、教えてく *1［邦訳］村上雅章 訳『達人プログラマー―――システム開発の職人から名匠への道』ピアソン・エデュケーション. xixii 謝辞
れたり、語ってくれたりした
Donnie Webb
、Ken Smith
、Walter Hoehn
、James
McMurry
、Carey Boaz
、David Alan Black
、Mike Clark
、Nicole Clark
、Vik
Chadha
、Avi Bryant
、Rich Kilmer
、Steve Akers
、Mark Gardener
、Ryan
Ow-nens
、Tom Copeland
、Dave Craine
、John Athayde
、Marcel Molina
、Erik
Kast-ner
、Bruce Williams
、David Heinemeier Hansson
、Ali Sareea
、Jim Weirich
に感謝する。常に変わらぬ支えである我が両親、そして、すべてのことにやりがいを与えてく
イントロダクション
この本は自分のキャリアにおいて充足感と幸福感を得るためのものである。充足 感と幸福感は偶然に得られるわけではない。間違いを犯したときに進路を変えるた めには、思索、意思、行動、そしてやる気が必要だ。この本ではソフトウェア開発 におけるキャリアで（したがって人生で）根本的に成功を収めるための戦略を提示 する。 この本は退屈しない人生を送りたいという思いを育むためのものでもある。どう いうわけか、これから自分のキャリアを積んでいこうというときに、そういう人生 を目指さない人がいる。時流に身を任せることに甘んじている人は多い。メディ ア、友人、知人、それに家族のおかげで、低い目標しか見えなくなってしまってい る。そのため、まずは退屈しない人生というのが目指すべき目標であることに気が ついてもらわないといけない。これは自明なことではないんだ。 ほとんどの人は、大人になってからの時間を何よりも仕事に多く使っている。米 国労働統計局の2006
年の調査によれば*2、平均的アメリカ人は起きている時間の 半分を仕事に費やしているそうだ。レジャーとスポーツには起きている時間の15
パーセントしか費やしていない。この数字からわかるように、要するに人生とは仕 事だ。 人生が主に仕事に費やされるとすれば、自分の仕事を好きになることが自分の人 生を好きになるための最も重要な鍵の1
つだといえる。退屈で平凡な仕事よりも、 困難でやりがいがあって報いのある仕事のほうが、朝も元気よく起きる気にさせて くれるはずだ。仕事をうまくこなすということは、使える時間の50
パーセントに おける活動が自分の得意分野であることを意味している。逆に仕事がうまくできな ければ、自分の時間のかなりの部分を、最善を尽くしていないという不完全燃焼感 や罪悪感を持ちながら過ごすことになる。 結局のところ、僕らはみんな幸福を追い求めている。食物やねぐらといった人間 として基本的な需要が満たされてしまえば、僕らの目標の大半は幸福の探求へと切 り替わる。それなのに、僕らの行動は、その何よりも大切な目標とかみ合っていな いことが多い。人間というのは手段にかまけて目的を忘れるものだからだ。 もっと金があれば今より幸福かもしれない。もっと業績が評価されれば今より幸 福かもしれない。会社で昇進するか有名になれば今より幸福かもしれない。しか し、もし仮に、貧しくて平凡な仕事をしていても幸福だとしたら？ そんなこと、あ りえるだろうか？ ありえるとしたら、その人はもっと金を欲しがるだろうか？ あ *2 http://www.bls.gov/tus/charts/ xiiixiv イントロダクション るいは、もっとましな仕事を欲するだろうか？ きっと欲しない。僕らは、幸福という定まった目標を最優先に見据えていれば、 その目標を勝ち取るための小さなステップについては適切な判断が下せる。それは 疑う余地がない。高い給料は確かに魅力的だし幸福につながるかもしれないが、最 優先の目標から目をそらしてしまうと、幸福を犠牲にして高い給料を選ぶことにな りかねない。滑稽な話に聞こえるかもしれないが、僕はその失敗を経験してきた。 君だってそうだろう。思い返してごらん。 僕がこの本を通して示すのは、より幸福でやりがいのあるキャリア（そして結果 として幸福な人生）へと君を導くアドバイスだ。そのアドバイスに従うことで収入 が増えるかもしれない。評価が高まるかもしれないし、有名にだってなれるかもし れない。しかし、それらは目標ではなく、目的のための手段だ。このことは忘れな いでほしい。
失敗はレーダーに映らない！
僕自身が注目に値するキャリアを築くためにとった主な手段の1
つが、皮肉にも 本書の初版本を書くことだった。その本は『My Job Went To India
オフショア時 代のソフトウェア開発者サバイバルガイド』と呼ばれていた。表紙に使われている 写真の男は「Will Code for Food
（食うためにコードを書きます）」と書かれた看 板のようなものを持っていた。その姿は滑稽だったし、本のタイトルと赤い表紙は 自分たちの仕事が低コストのオフショアプログラミングチームに外注されるのでは という西洋圏の不安を刺激しようとするものだった。 けれども、その写真がまずかった。実際のところ、君が自分の仕事を「守る」必 要があると思っているなら、僕が助けてあげることはできない。この本はクビにな らずに済む程度の並のスキルを維持しようとあがくためのものではない。そうでは なくて、素晴らしい存在になるためのものである。勝利するためのものである。失 うまいと努めていてはレースに勝てない。失敗しないように努めていても人生の勝 利者になれない。幸い、この本の内容は失敗しないように努めるためのものではな かった。僕はそんなふうに考えることはできないし、君だってそうすべきじゃない。 僕は自分のキャリアが注目に値するんじゃないかと思ったときのことを覚えてい る。僕はそれまでの仕事で大して努力もせずにぬくぬくと過ごしていた。高校、大 学、そしてプロのサックス奏者としての短くてやや平凡なキャリアでもずっとそう だったんだけど。幸運と才能があったおかげで、かなりの成功を収めてはいた――― 「世界で最も賞賛される企業」の1
つで高評価の技術スタッフとして給料のいい職 にありつけた程度には。しかし、僕はなんとなく毎日をやり過ごしているだけだっ たし、その自覚もあった。失敗はレーダーに映らない！ xv
ある日、仕事帰りに地元の書店で本をあさっていると、新刊書の棚に置かれて いた
Kent Beck
の『Extreme Programming Explained
』[Bec00]
*3が目にとまっ た。その本のサブタイトルは変化を受け入れる（Embrace Change
）となってい た。変化という考え方には前々から興味を引かれていた。僕は堪え性があまりなく て、そのときまで次から次へと転職を続けていた。「ソフトウェア開発の方法論」と いう考え方は、ひどく退屈でマネジメントっぽい響きがあるが、多くの変化を伴う ものであれば、次の職を探すはめになるのと退屈さを避けるために職場で売り込め るかもしれないと思った。 その本を手に取ったのは本当に幸運な気まぐれだということがわかった。いった ん読み始めると、途中で閉じることができなくなった。夢中で読み終わってから、 インターネットにアクセスし、エクストリームプログラミング（XP
）というアイ デアに関して可能な限りのものを読み漁った。このアイデアに大いに感動した僕 は、最高情報責任者（CIO
）のところに行って、このアイデアを売り込もうとした。CIO
と彼のスタッフは納得し、彼はエクストリームプログラミング採用の条件として、
Object Mentor
のExtreme Programming Immersion
コースに僕らの仲間を大勢送り込んだ。
Extreme Programming Immersion
はXP
について学ぼうとするならぜひ行くべき場所である。それはお気に入りのロックスターたちによる
1
週間にわたるコン サートのバックステージパスを手に入れるようなものだった。あの場所であの人た ちと一緒に過ごしたことで、僕はとても賢くなった。前よりも創造的になった。そ してコースが終わったときは本当に悲しかった。再び職場に戻って、それまでどお りの仕事を繰り返すなんて考えられなかった。 同僚のSteve
（p.138
のエッセイを寄稿してくれた人物）と僕は同じ結論にたど り着いた。あの人たちとできる限り頻繁に交わる唯一の方法は、あの人たちの一人 になることだ。つまり、自分を高めてくれる人たちと交わりたかったら、そんな職 場や大学のコースはない。あの人たちの一人であるとはどういうことかを明確にし て、それを実現すればいい。だから僕はSteve
に、自分はあの人たちの一人になれ そうだって宣言した。 あれがまさに僕のキャリアの転換点だった。僕は彼に、会議の基調講演を初めて 依頼されたと伝えたんだ（何年もたってからSteve
に言われるまで、なぜかそのこ とを忘れていた）。僕は、ソフトウェア会議でも主要な演説の1
つを、ほかでもなく 僕にやってほしいと言われて感動した。ぜひそうなりたいと望んでいたとおり、僕 はあの人たちの一人になったんだ。 僕はコンピュータプログラミングの正式な教育を一度も受けずに、これをやって *3［邦訳］長瀬嘉秀監訳、テクノロジックアート 訳『XPエクストリーム・プログラミング入門―変化を受け入れ る 第2版』ピアソン・エデュケーション.xvi イントロダクション のけた。僕はコンピュータプログラマになる前はミュージシャンだった。大学に 行ったのは音楽を学ぶためだった。ミュージシャンにとって大学の学位はあまり意 味がないので、優れたミュージシャンになるのに役立たない授業は避けることにし た。僕が大学をやめたときには、どんな学位にも必要とされる以上の履修単位以上 を取得していたが、それでも卒業するためにはまだ数年分の授業時間が残っていた。 だから、僕はプロのソフトウェア開発者としての資格がないわけだ。少なくとも、 求人市場でソフトウェアエンジニアリングの職に必要とされている典型的な条件に 照らせばそういうことになる。 確かに僕には典型的なソフトウェア開発者としての資格はないけれど、ミュージ シャンとしての経験から得られた
1
つの重要な洞察によって、結局は典型的なソ フトウェア開発者になるというステップを飛ばすことが可能になったのだ。就職し て安定した楽な生活を送りたいという理由でミュージシャンになる奴などいない。 音楽業界はそんなに甘いところではない。プロのミュージシャンになるすべての 人が、偉大なミュージシャンになりたがっている。少なくとも駆け出しのミュージ シャンにとって、音楽の世界における偉大さは二者択一だ。偉大になる（そして結 果的に有名になる！）ことを望むか、そもそも初めから音楽をやらないか。 僕はよく、優れたソフトウェア開発者でもある優れたミュージシャンが大勢いる のはなぜだろうと聞かれるが、その答えはこうだ。脳の機能が同じだからではない し、両者とも細部を重視したり創造性が要求されたりするからでもない。偉大に なることを望んでいる人のほうが、自分の仕事をこなせばよいと思っている人よ りも、偉大になる可能性がずっと高いからだ。みんながMartin Fowler
やLinus
Torvalds
、あるいはDave Thomas
やAndy Hunt
（『達人プログラマー』の著者たちだ）になれるわけではないが、それでも高い目標を設定すれば、少なくとも平 均よりずっと上まで行ける可能性が高くなる。
自分のものにする
たいていの人は他人の計画にばかり従っている。自分自身を差別化したいなら、 まず立ち止まって自分のキャリアを見つめることだ。君は他人のではなく自分の計 画に従う必要がある。 この計画をどうやって作ればよいのだろうか。ソフトウェアはビジネスである。 だから、僕らソフトウェア開発者はビジネスマンだ。会社は僕らを好きだから雇っ ているんじゃない。会社はそんなこと思っちゃいない。それはビジネスの役目では ない。ビジネスの目的は、僕らの居場所を提供することじゃない。ビジネスの目的 は利益を上げることだ。会社で抜きん出るには、利益を上げるためのビジネスプラ ンに自分がいかに適合しているかを理解しなきゃならない。新版について xvii 後で詳しく見ていくけれど、会社は君を雇っておくためにかなりの費用をかけて いる。会社は君に投資しているわけだ。君は誰が見ても良い投資物件になる必要が ある。君は君を雇っている組織やお客にもたらすビジネス価値という観点から自分 自身のパフォーマンスを評価すべきだ。 君のキャリアを、今君が作っている製品のライフサイクルと同じように考えてほ しい。この「製品」は、君と君のスキルから成る。この本では、企業が製品の設計、 製造、販売において注意しなければならない
4
つの側面を見ていく。そして、この4
つの側面を僕らのキャリアに応用する方法を説明していきたいと思う。s
市場を選ぶ。焦点を当てる技術分野およびビジネス分野を慎重に選ぶ必要があ る。リスクとリターンのバランスをどう考えればよいだろうか？ この選択に おいて、需要と供給の要因をどのように考慮すればよいだろうか？s
製品に投資する。君の知識とスキルは、君という製品の土台となる。知識とス キルに適切な投資をすることは、君自身の市場競争力を増すための重要な鍵と なる。Visual Basic
でプログラムを書く方法を知っているだけでは、もはや十 分ではない。ニューエコノミーの時代にはほかにどんなスキルが必要になるだ ろうか？s
実行に移す。強力なスキルを持つ従業員を雇っただけでは、会社の利益にはな らない。その従業員が期待どおりの仕事をする必要がある。泥沼に突っ込まず に、期待どおりのペースで仕事を続けるためにはどうしたらよいだろうか？ 自 分が企業に適正な価値を提供しているかどうかを確認するにはどうしたらよい だろうか？s
製品を売り込む。どんなに素晴らしい製品でも、その存在を誰も知らなければ 買い手はつかない。こびへつらったりせずに自分の価値を雇い主や広く業界全 体に認めてもらうためには、どうしたらよいだろうか？新版について
この本は『
My Job Went To India
オフショア時代のソフトウェア開発者サバイ バルガイド』の改訂改題版だ。この改訂版の目的は、第1
版が真に意図していたも のをさらに掘り下げることにある。それは注目に値するキャリアを築くことだ。そ のためにタイトルを前向きなものに改め、さらに新しい内容も追加した。Ruby on Rails
の作者で37signals
のパートナーであるDavid Heinemeir
Hansson
が「本書に寄せて」を寄稿してくれた。各章には、僕が出会ったり一緒に仕事をしたりした本当にすごい人たちのエッセ イを掲載した。これらのエッセイには、イノベータや開発者やマネージャや企業家 が成功に至る過程で下した意思決定への洞察が含まれている。それに、これらの
xviii イントロダクション エッセイは、この本で紹介している方法が完璧な環境にしか当てはまらない単なる 理想主義的な提案ではないことの証拠にもなっている。現実の人間が実践して達成 できる現実の話というわけだ。 第
1
版にあった節をいくつか削除して新しい節を追加した。第1
版の最後の章、 「勝てないならば」はすべて削除した。この本全体にわたり、第1
版の出版後に僕が 学んだ新しい教訓を踏まえた新しい節を追加してある。 第1
版から引き継いだ節のなかには、「今すぐ始めよう！」の項目を増やしたもの もある。 このイントロダクションと最後の「楽しもう」は、注目に値するキャリアを築く という本書の趣旨をはっきりさせるために差し替えてある。 この本の目的は、ソフトウェア開発で注目に値するキャリアを築くための方法を 体系的に説明することだ。具体的な例を交えながら、君が今すぐ実践でき、短期的 および長期的なプラス効果が期待できる一連のアクションを紹介していく。 既に述べたように、この本では君の仕事を守る方法を教えようとしているわけ じゃない。今君が仕事を失うのではと不安になっているなら、注目に値するキャリ アを築くために君が取る行動によって、その不安が取り除かれるだろう。注目に値 するソフトウェア開発者はくよくよしない。無駄に職探しなどしない。だから心配 することはない。勝利をしっかり見据えてほしい。そうすれば、失職の不安は永遠 に過去のものになるだろう。目次
“The Passionate Programmer”読者の声 iii
日本の読者の皆さんへ vii 本書に寄せて ix 謝辞 xi イントロダクション xiii 失敗はレーダーに映らない！
. . . xiv
自分のものにする. . . xvi
新版について. . . xvii
目次 xix 第1章 市場を選ぶ 11
先んずるか、やられるか. . . .
3
2
需要と供給. . . .
6
3
コーディングはもう武器にならない. . . .
9
4
一番の下手くそでいよう. . . 12
5
自分の知性に投資しよう. . . 15
6
親の言うことを聞くな. . . 18
7
万能選手になろう. . . 22
8
スペシャリストになろう. . . 27
9
自分の人生を他人任せにするな. . . 30
10
愛せよ、さもなくば捨てよ. . . 32
第2章 製品に投資する 3711
魚の釣り方を学ぶ. . . 40
12
ビジネスの仕組みを学ぶ. . . 43
13
師匠を探す. . . 45
14
師匠になる. . . 48
15
一に練習、二に練習. . . 50
16
プロセスを大切にする. . . 54
17
巨人の肩の上で. . . 57
xixxx 目次
18
自動化によって仕事を確保する. . . 60
第3章 実行に移す 6519
今すぐに. . . 67
20
読心術. . . 69
21
デイリーヒット. . . 72
22
誰のために働いているのか思い出す. . . 74
23
今の職務を全力で. . . 76
24
今日どれだけうまく仕事ができるか？. . . 79
25
自分にどれだけの価値があるか？. . . 81
26
バケツ一杯の水の中の小石ひとつ. . . 83
27
保守作業の真価を知る. . . 86
28
8
時間燃焼. . . 90
29
失敗する方法を学ぶ. . . 93
30
できないことは「できない」とはっきり言う. . . 96
31
あわてるな. . . 99
32
言って、成して、示す. . . 102
第4章 マーケティング. . . スーツ族だけのものじゃない 10933
視点が違えば認識も異なる. . . 112
34
アドベンチャーツアーガイド. . . 115
35
オレ、作文的なのは得意っすよ. . . 117
36
そこに居ること. . . 119
37
スーツ語. . . 122
38
世界を変えよう. . . 124
39
業界で名前を売ろう. . . 126
40
自分のブランドを築こう. . . 129
41
自作のコードをリリースしよう. . . 131
42
目立つこと. . . 134
43
コネを作る. . . 136
第5章 研鑽を怠らない 14144
既に時代遅れである. . . 143
45
君は既に職を失っている. . . 145
46
終わりのない道. . . 147
47
自分のロードマップを作る. . . 149
48
市場に気を配る. . . 151
xxi
49
鏡の中の太った男. . . 153
50
南インドのサル捕獲トラップ. . . 156
51
ウォーターフォール式のキャリア計画はやめよう. . . 159
52
昨日よりよく. . . 162
53
独立する. . . 165
楽しもう 169 参考文献 171 監訳者あとがき 1731
第
1
章
市場を選ぶ
2 第1章 市場を選ぶ
君は大きな投資をしようとしている。投資しようとしているのはお金ではなく、 君の時間―――つまり君の人生だ。多くの人は、自分のキャリアがどこに向かうのか わからないまま流れに身を任せている。たまたまJavaやVisual Basicにぶつかっ て、そして話題になっている新しいテクノロジのトレーニングクラスに雇い主がポ ンと金を出してくれたりする。ほかの何かが与えられるまでは、その流れに乗って 漂っていく。僕らのキャリアは方針のない偶然が延々と連なったものだ。
『The Pragmatic Programmer』[HT00]*1の中で、Dave ThomasとAndy Hunt
は「偶発的プログラミング」の話をしている。あるコードから始めて、そのあちこ ちに少しずつコードを書き加えていくやり方だ。たいていのプログラマには思い当 たるふしがあるだろう。Webサイトからコピーしてきたサンプルプログラムから 偶発的プログラミングを始める人もいるんじゃないかな。うまく動作しているよう に見えるので、少し変更を加えて自分が必要とするプログラムに近づける。自分が 何をしているのか本当にはわかってないけれど、ほぼ自分のニーズに合ったプログ ラムになるまでいじり続けるわけだ。ところが、そのプログラムがどのように動い ているのかわからないので、新しい機能を加えるたびにプログラムが崩壊する危険 が高まっていく。まるでトランプの城のように。 ソフトウェア開発者として、偶発的プログラミングがまずいのは明らかだろう。 キャリアを左右する大事な選択についても同じように考えてほしい。事実上、僕ら 開発者のほとんどは、偶発的キャリア選択をしてしまっている。どのテクノロジに 投資すべきか？ どの分野で専門技術を磨くべきか？ 知識を広げるべきか深めるべ きか？ 僕らは今、こうした問題を自分自身に問うべきなんだ。 こんな状況を想像してほしい。君は会社を立ち上げ、ある商品を自社の主力商品 にすべく開発を進めている。この商品が「ヒット」しなければ、君の会社は破産す ると思ってほしい。ターゲットにする顧客が誰かについて、どれくらい注意を払う か？ 実際にどんな商品にするかについて、商品を生産する前にどれくらい深く考え るか？ こんなことを誰か他人に決定してもらいたいと思うだろうか。意思決定プロ セスの詳細にいたるまで、徹底して慎重になるんじゃないだろうか。 それなら、自分のキャリアにかかわる選択にも同様の注意を払ってよさそうなも のだ。キャリアをビジネスと見るなら（まさにそうなんだけど）、「商品」としての 君は、どんなサービスを提供できるかで決まる。 そのサービスは何か？ サービスを売り込むべき相手は誰か？ そのサービスに対 する需要は拡大するか縮小するか？ こうした判断に際し、どこまで大きな賭けをす るつもりか？ この章では、これらの重要な問いに君自身で答えを出す手助けをしようと思う。 *1［邦訳］村上雅章 訳『達人プログラマー―――システム開発の職人から名匠への道』ピアソン・エデュケーション.
1先んずるか、やられるか 3
ttttttttttttttttttttt
1
先んずるか、やられるか
Lead or Bleed? お金を投資するときには選択肢がたくさんある。銀行に預金もできるけど、それ じゃあ利息がインフレに追いつかないだろう。貯蓄国債を買うこともできる。いず れも、あまり儲からないけど安全な方法だ。 小さな新会社に投資するという手もある。数千ドルを投資して株主になるとか。 その会社のアイデアが良くて、しかもきちんと経営されるなら、大金を手にできる かもしれない。でも元本すら回収できない危険性もある。 ここで言わんとしていることは別に目新しいことじゃない。子供の頃から遊びを 通じて学んできたことだ。「今三塁まで一気に走れば、みんな驚いちゃって、誰も タッチできないかも」日々の生活でも、例えばミーティングに遅れそうなとき、職 場までのルートをリスクと見返りのトレードオフで考える。「道が混んでなければ 32番街を通って15分早く着ける。混んでたら万事休すだな」 リスクと見返りのトレードオフは、投資すべきテクノロジとビジネスの選択でも 重要な役割を演じる。15
年前なら、COBOL
プログラミングを学ぶのはとてもリ スクが低い選択だっただろう。もちろん、COBOL
プログラマは大勢いたので、当 時のCOBOL
プログラマの平均的な給料はそれほど高くなかった。仕事を見つけ るのは簡単でも、あまり金にならなかったのだ。つまり、リスクは小さく見返りも 小さい。 それに対し、当時まだ目新しかったJava
に取り組もうと心に決めていたら、仕 事を見つけるのは難しかったかもしれない。当時、Java
が主流の言語になるかもし れないなんて、誰が予想しただろう？ でも当時の業界の様子をよく見ていれば、Sun
がそうだったように、Java
に何か 特別なものを感じたかもしれない。ことによると、そのうち大化けしそうな予感が したかもしれない。Java
に早々と投資していれば、やがて来るテクノロジの大潮流 を率先することになっていただろう。 もちろん、今になってみれば、それは正しい選択だった。当時Java
というカー ドを正しく切っていれば、とても儲かる投資だったといえる。つまり、リスクが大 きく見返りも大きい。 それと同じ頃、1995
年に、Be
による新しいBeOS
のデモンストレーションが あったことを思い起こしてほしい。当時、BeOS
は常識を超えるものだった。BeOS
はマルチプロセッサを活用すべく全く新たに作り出されたOS
だった。マルチメ ディア機能のすごさには仰天させられた。業界は沸き立ち、識者たちはOS
の世界 に有力な競争者が現れたと大騒ぎした。もちろん、この新しいプラットフォームと ともに、新しいプログラミングの方法、新しいAPI
、そして新しい考え方のユーザ4 第1章 市場を選ぶ インタフェースが生み出された。学ぶのは大変でも、それだけの価値があると思っ た人もいるだろう。君も大いに努力していれば、
BeOS
用のFTP
クライアントや 個人情報管理プログラムの最初の作者になっていたかもしれない。Be
がIntel
対応 バージョンのOS
をリリースすると、このテクノロジを次世代のMacintosh OS
の 基盤に使うためにApple
がBe
を買収するという噂が流れた。 でもApple
はBe
を買収しなかった。結局、Be
はニッチマーケットさえ獲得で きないことが明らかになった。BeOS
は定着しなかった。BeOS
環境用のプログラ ミングをマスターした多くの開発者は、自分たちの投資が報いられないことに気付 いた。結局、Be
はPalm
に買収され、BeOS
は打ち切られた。BeOS
はリスキーな がら投資対象として魅力的なテクノロジだったが、BeOS
に投資した開発者に長期 的なリターンをもたらさなかった。つまり、リスクが大きく見返りもない。 ここまでは、最前線のテクノロジと地最後に勝つのは
テクノロジ採用曲線の両端かも
歩を固めたテクノロジの選択について話 をしてきた。世界中の生産現場で必ずと 言っていいほど使われている安定したテ クノロジを選択するのは、まだ誰も注目していない斬新なテクノロジよりも安全だ。 しかし、それほどの見返りは期待できない。それじゃあ、行きつくところまで到達 してしまったテクノロジの場合はどうだろう。寿命が尽きるのを待っているだけの テクノロジならどうだろうか。 そうしたテクノロジの最期を看取るのは誰だろう。こんな話をすると、定年まで 指折り数えて過ごしているRPG
プログラマの老兵たちを思い浮かべるかもしれな いね。新世代の若者は皆Java
と.NET
を学んでいるから、RPG
なんて聞いたこと もないだろうけど*2。古びて消えかけているテクノロジを最後まで死守している人 たちのキャリアがテクノロジそのものと同じデススパイラルに陥っているのは想像 に難くない。 でも、古いシステムは単に死ぬだけじゃない。交換されるんだ。しかもたいがい、 自家製のシステムは段階的に交換される。全部が交換されるまでは、古いシステム と新しいシステムとがやり取りできなくちゃいけない。誰かが新旧のシステムに手 を加えて両者が対話できるようにする必要がある。ところが、若い連中は概して古 いシステムのことがわからない（知りたいとも思わないだろう）。引退目前の老人た ちも新しいシステムのことはわからない。 だから、そこには抜け目のないテクノロジストの活躍する場がある。いわば テク ノロジのホスピスだ。古いシステムを尊厳死に導くという役目は決して軽く見ては いけない仕事だ。もちろん、ほとんどの人は船が沈没する前に脱出する（引退や別*2［訳注］ロールプレイングゲームのことではない。RPG（Report Program Generator）とは、主に汎用機で 使われている、要求に応じてレポートプログラムを作成する汎用プログラムのことだ。
1先んずるか、やられるか 5 のテクノロジへの転進という形で）。だから、もうひと働きしなければならないシ ステムの面倒を見るために最後まで残れば、責任者として大いに活躍できる。ただ し、そのテクノロジが本当に逝った後は、もはや存在しないものの専門家になって しまう。その意味ではリスキーな選択だ。でも、早めにうまく立ち回ることができ れば、その次の世代の（死にかけている）レガシーシステムを見つけて、また同じ ことを繰り返せるだろう。 商品の採用曲線（
adoption curve
）が示すように、両端にいくほど市場は狭くな る。君なら採用曲線のどこを狙う？今すぐ始めよう！
1.
現在の市場におけるテクノロジの年齢を若年、中年、老年に分類し、表にまと めてみよう。それらを紙の上に左から右へとマップしてほしい。左側に最先端 にテクノロジが、右側に衰退しつつあるテクノロジが並ぶ。できるだけたくさ んのテクノロジを挙げよう。採用曲線の上に並べたときに、できるだけ同じ位 置に重複するテクノロジがないようにしてほしい。考えつく限りのテクノロジ を採用曲線にマップしたら、自分自身がよく知っていると思うテクノロジに印 を付ける。それから、いくらか経験があるという程度のテクノロジに別の色で 印を付ける。印を付けたテクノロジは採用曲線のどのあたりに多く存在するだ ろう？ 塊になっているだろうか？ 均等に分散しているだろうか？ 両端付近 に、特に関心を持っているテクノロジはあるだろうか？6 第1章 市場を選ぶ
ttttttttttttttttttttt
2
需要と供給
Supply and Demand
Web
が本格的に動き始めた頃は、企業のために簡単なHTML
ページを作れば大 儲けができた。あらゆる企業がWeb
ページを持ちたがり、作り方を知っている人 が比較的少なかったからだ。企業は「経験豊富な」Web
デザイナに最高給を払うの も厭わなかった。なお、当時における「経験豊富な」という意味は、HTML
やハイ パーリンクやサイトの組み立て方について基礎的な知識があるということだ。HTML
ページを作るのは難しくない。本当に見映えのいいページを作るのは難 しいけれど、基本的なことを理解するのは簡単だ。そういうWeb
デザイナが高い 報酬をもらっているのを見て、もっとたくさんの人たちがHTML
に関する本を読 んで勉強し始めた。市場はホットで、月給も時間給も魅力的だったので、その結果HTML
の専門家の供給量も増え始めた。 市場にWeb
デザイナが溢れるようになると、Web
業界の人たちは本物の芸術家 と功利主義者を区別するようになった。その上、競争のせいで料金が下がり始めた。 料金が下がったことで、インターネットへの露出を商売の手がかりにしようとする 企業が増えた。Web
サイトの構築コストが5,000
ドルなら躊躇したけど500
ドル なら払ってもいいってことだろう。 もちろん、現実離れしてまるで夢のようなWeb
サイトに大枚を投じようという 企業もあった。そして、依然として法外な報酬を要求できるWeb
デザイナも確か にいた。 そうこうしているうちに、コストレベルが中程度以下の（過剰気味だった）Web
デザイナの数が減った。あまり才能のないWeb
デザイナは、必ずしもHTML
デザ インが専門でない人たちとエンドユーザに取って代わられた。この時点で、HTML
制作の需要と供給と価格が平衡状態に達したのだ。Web
デザイナの歴史を簡単に振り返ってみたわけだけど、これは需要と供給とい うおなじみの経済モデルの実例といえる。需要と供給と聞くと、たいていの人は、 売り買いの価格についての話だと考える。ある商品の価格は、その商品の数が買い たい人の数より多ければ下がる。逆に買いたい人の数が多いと、買いたい人同士の 競争になって、価格が上がる。 商品やサービスの価格を予測するだけでなく、価格変動が商品やサービスを売買 しようとする人たちの数にどう影響するかも、需要と供給のモデルで予測できる。 どんな商品でも、一般に価格が安いほうが買う人は多くなる。 僕たちにとって需要と供給が重要なのはどうしてだろう？ ソフトウェア開発の オフショア化によって、低コストのIT
労働者が米国の経済に大量に流入してきた。2需要と供給 7 僕らは国内で職を失わないか心配してるけれど、実際にはプログラマあたりのコス トが下がったことで総需要は増大する。同時に、需要が増えるほど価格は下がる。 需要の多い商品とサービスなら、より安い価格のものが競争に勝つ。労働市場にお ける価格は、すなわち給料だ。価格競争に勝ち目はない。安売り競争になったらお しまいだ。じゃあ、どうしたらいいんだろうか。 オフショア市場から低コストのプログ
価格競争に勝ち目はない。
安売り競争になったら
おしまいだ
ラマが投入されているテクノロジ分野は、 範囲が比較的限られている。インドにはJava
や.NET
のプログラマが掃いて捨て るほどいる。Oracle DBA
も大勢いる。 非主流のテクノロジは、オフショアで開発している企業ではとても過小評価されて いる。キャリアにすべきテクノロジ分野の選択にあたっては、供給の増加と価格の 低下が自分の今後のキャリアにどう影響するのか考える必要がある。.NET
プログラマの場合、労働市場で張り合うことになる人たちが大勢いて、例 えばPython
プログラマに比べると何万人も多いだろう。その結果.NET
プログラ マの平均コストは大幅に下がり、ことによると需要が増加する（つまり.NET
の仕 事が増える）かもしれない。だから職探しは楽になるかもしれないが、賃金はそれ ほど高くならないだろう。Python
プログラマなら、需要に対する供給が.NET
プ ログラマに比べてずっと少ないかもしれない。Python
の労働市場で著しく高いプログラマあたりのコストが維持されるなら、 この高値でサービスを供給しようとする人たちが増え、結果として競争が激化し、 価格が下がるかもしれない。 何事も結局は平衡状態に向かう。しかし、今のところ確実に見えることが一つあ る。インドは既に平衡状態に達しているIT
サービス市場にサービスを提供してい る。インドの主流のオフショア企業は新奇なテクノロジには飛びつかない。彼らは 先駆者ではない。一か八かの選択をすることは、まずない。技術サービス市場が平 衡状態になるのを待ち、圧倒的に安いプログラマ単価で市場を粉砕するんだ。 だとすると、労働市場のなかでもまだ需要が少ない分野で競争するという道が考 えられる。直感ではわかりにくいかもしれないけど、君がオフショアに負けて職を 失うことを心配しているなら、オフショア企業がやっているような仕事を避けるの も一つの手じゃないだろうか。オフショア企業は需要が多い分野の仕事をしてい る。それなら、ニッチなテクノロジに注力してみよう。需要が少ないから必ずしも 競争が楽になるわけじゃないけど、競争のポイントを価格から能力に変えられるか もしれない。これこそ君に必要な戦略だ。価格で競争することはできなくても、能 力でなら競争できる。 主流技術のプログラマのほうも、平均価格が下降しているので需要は増加するだ8 第1章 市場を選ぶ ろう。例えば
