【本メモ】『情熱プログラマー ソフトウェア開発者の幸せな生き方』
『情熱プログラマー ソフトウェア開発者の幸せな生き方』を読んだので、本メモを公開。
この本は退屈しない人生を送りたいという思いを育むためのものである。 どういうわけか、これから自分のキャリアを積んでいこうというときに、そういう人生を目指さない人がいる。 時流に身を任せていることに甘んじている人は多い。 優れたソフトウェア開発者でもある優れたミュージシャンが大勢いるのはなぜだろうと聞かれる。 偉大になることを望んでいる人のほうが、自分の仕事をこなせばよいと思っている人よりも、 偉大になる可能性がずっと高いからだ。 高い目標を設定すれば、少なくとも平均よりずっと上まで行ける可能性が高くなる。 一番の下手くそでいよう ぱっとしないバンドとカジノやちっぽけなバーで一緒に演奏していたときには、 その連中と同じような演奏しかできなかった。 しかも、呑んでないのにろれつが回ってないアルコール依存症の患者みたいに、そういうバンドで身に付けた悪い癖がほかの場所で演奏するときにも出てしまった。 こうして僕は、人はどんな仲間と一緒にやるかで腕を上げることもあれば落とすこともあると学んだ。 その上、ある集団との長い付き合いが、その後もずっと人の能力に影響を与えることがある。 この経験で身に付けた習性、すなわち最良のミュージシャンたちを探し求める習性は、 IT業界に移ってプログラマになってからも変わらなかった。 チームで一番下手くそでいるのは、バンドで一番下手くそでいるのと同じ効果がある。 どういうわけか自分自身が賢くなるんだ。 話し方や書き方さえ以前より知的になる。 自分の生み出すコードや設計が以前よりエレガントになり、 難しい問題をますます創造的なソリューションで解決できるようになる。 今すぐ始めよう！ 自分自身にとって「一番下手くそになる」状況を見つけよう。 もっと優れた人たちと仕事がしたいというだけの理由で、すぐにほかのチームや会社に移るのは難しいだろう。 だから、良い影響を与えてくれそうな開発者たちと一緒に仕事ができるボランティアのプロジェクトを探そう。 君から見て高く評価できて、自分の目指している「次の段階」の開発者たちがいるOSSを選ぶ。 そのPJのTODOを調べ、何らかの機能やメジャーなbug fixを選び出し、コーディングに励もう。 コーディングの際は、そのPJの周辺コードのスタイルを真似るようにする。 そして、それを楽しむこと。 そのうち、もとの開発者でさえ君の設計とコードを誰が書いたものかわからなくなる。 それくらいPJのほかの部分になじんでいこう。 そして満足のいくものができたら、それをパッチとして投稿するんだ。 出来が良ければPJに受け入れられるだろう。これを繰り返す。 良い人材は新しいものを学ぶのが好きなので変化を追い求める。 今すぐ始めよう！ 仮装マシン上でコンパイルし実行するプログラミング言語を使っているなら、 その仮装マシンの動作の仕組みを学ぼう。 ソースファイルのコンパイル時に何が起きているのかしっかり把握してほしい。 入力したコードは、どのようにして人間が読めるテキストからコンピュータが実行できる命令に変換されるだろうか？ 自分自身でコンパイラを書くことにどんな意味があるだろうか？ 外部ライブラリをインポートすることの本当の意味は？ コンパイラ、OS、仮装マシンは、いくつものコードからどうやって統一のとれたシステムを構築する？ こういう事柄を学んでいくことで、自分が選んだテクノロジの本物のスペシャリストに近づくことができる。 今すぐ始めよう！ 1 本当に情熱を持てる仕事を探そう 2 来週の月曜から始めて、2週間分の簡単な日誌をつけよう。 毎朝目覚めたら、自分のやる気の度合いを10点満点で採点するのだ。 毎朝、明日どうやって10点を取るかを考えてほしい。 毎日、昨日のやる気度を記録してほしい。 2週間後、事態が悲観的であれば、大きな進路変更を検討すべきかもしれない。 今すぐ始めよう！ 1 「なぜ」「どうして」を考える。 この場で、あるいは次に職場に行ったときに、自分の仕事のなかで完全には理解していないことについて考えてみてほしい。 ある領域をさらに深いところまで掘り下げていくときに役立つ2つの質問がある。 それは「その仕組みはどうなっているか」と「そうなるのはなぜか」だ。 質問に答えることはできないかもしれない。 でも、こうした質問について考えるという行為そのものが、新しい考え方をもたらし、 自分が働いている環境について高い意識を持つことにつながる。 当然これらの質問に答えることで、新たによくわからない部分が出てくることもある。 「なぜ」「どうして」のツリーをこれ以上進むことができなくなったら、十分に分析が進んだといえる。 2 役に立つヒントを探す いつも使っているツールのなかから、重要だけれどもあまり使い込んでいないツールを選び、それに注目してみよう。 ツールを選んだら、毎日少し時間を作り、そのツールの使い勝手を良くしたり生産性を高めたりする。 何か新しいことを勉強するようにする。 もっと知識があって何でも自分で解決できる技術者になるにはどうすればいいか教えてくれとせっついたところ、 彼はシンプルなレシピを伝授してくれた。 曰く、ディレクトリサービスの構造をよく知ること、 何らかのバージョンのUNIXに親しむこと、 スクリプト言語を習得すること。 クラシック音楽の作曲家も同じことをする。 小説家や詩人も同様だ。 彫刻家や画家もそうだ。 巨匠の作品を研究することは巨匠になるために欠かせないステップだ。 ニュートンの言葉に 「もし私が人より遠くを見ているとしたら、それは巨人の肩の上に乗っているからだ」 というものがある。 ニュートンのように頭の良い人でも、先人に学ぶべきことが多いと認めてるんだ。 僕らもニュートンにならおうじゃないか。 今すぐ始めよう！ 1 何かプロジェクトを選び、コードを本のように読もう。 要点はメモに記しておく。 そのプロジェクトの長所と短所を簡単にまとめよう。 そのプロジェクトについて批評を書き、公表してみよう。 自分のコードに利用できそうなトリックやパターンを少なくとも1つ探す。 さらに自分がソフトウェアを開発するときの「べからず」チェックリストに加えるポイントを少なくとも1つ探す。 GEでの仕事は楽しかったが、ある重要な部分が欠けていた。 IT専門家としての僕の技能はある方面において向上するだけで、 企業がどのように運営され、収益を上げ、存続を目指し、革新を起こすかを理解する機会はあまりなかったのだ。 僕はそのことに不満を抱くより、自発的にビジネスと企業家精神を学び、何か自分で行動を起こすことにした。 大学で経営学を履修したこともなかったから、 起業のノウハウを学ぶには泥臭いやり方（つまり、試行錯誤しながら学ぶ）しかないと思った。 信頼できる紹介者を通したことがどれほど重要だったかを僕が知るのは、それからずっと後になってのことだ。 このとき得た教訓は、ベンチャーキャピタリストと接触したければ、 まずは何としても行為的な紹介者を探せ、ということ。 それが最初の足掛かりを得る最良の方法だ。 良いマネージャーの役割は「ピンチヒッター」ではない。 チーム全員の仕事を把握しておいて難しい局面で自分が手伝うのが良いマネージャーの役割じゃないんだ。 良いマネージャーの役割は、チームの仕事に優先順位を設定し、チームが仕事をこなすために必要なものを用意し、 チームがやる気と生産性を維持できるように配慮し、最終的に要求を実現することにある。 チームがうまく仕事をこなすには、マネージャーがうまく仕事をこなせばいい。 目標を持つのはいいことだし、成功を望むのもいいことだ。 でも、さっき言ったようなネガティブで恨み深い人間が成功者になれると思うかい。 まどろっこしく感じるかもしれないが、気持ちを現在に集中するほうが、目標そのものにこだわっているよりも目標に近づけるんだ。 現在見つかっているバッハの最古の直筆の楽譜も、他の作曲家のオルガン曲を写譜したものだった。 ビル・ゲイツがハーバード大学でゴミ箱に捨てられているソースコードを漁った話の方が有名かもしれない。 書き写すことで、筋肉に記憶が残る。 ざっと目を通しただけでは見逃してしまうような、微妙な部分が感覚的に掴める。 今すぐ始めよう！ 1 開発日誌をつけ始めよう。 何に取り組んだかの説明、設計上の決定についての理由、難しい技術的/専門的な決定の詳細を毎日少しずつ書く。 たとえ君自身が主な（または唯一の）読み手であっても、文章の質と自分自身を明確に表現できているかという点に気を配ろう。 時には前書いたものを読み返し、批判的な目で分析しよう。 その反省に立って、次にどのように書けばよいかを考える。 日誌を利用することで、文章力も向上し、自分が下した決定に対する理解も深まる。 また、前にやったことの理由と方法を確認する必要があるときにも日誌が役立つ。 2 タイピングを習おう。 入力が楽にできるようになれば、気持ちよく自然に文章を書けるようになる。 もちろん、素早いタイピング方法を習得すれば、これからやることになる作文で時間を節約できる。 自作のコードをリリースしよう 今や人気のある有名なソフトウェアを開発するために大企業で働く必要はない OSSへの寄与は、君が自分のフィールドに情熱を持っていることの証となる。 OSSへに寄与することは技能の証明になる。 本格的なコードを書き、本格的なプロジェクトに寄与すれば、何かのテクノロジについて知識があると主張するだけよりずっと説得力がある。 誰でもRailsを使えるがRailsコントリビュータを名乗れるのは少数 誰かが君のことを知るようになり、君のソフトウェアがコミュニティに広がるにつれて、君の名前と評判も広がっていく。 要するにマーケティングだ。それこそ君の望んでいるものだろう？ 今すぐ始めよう！ ワークショップの大筋は次のようになっている。 単体テストが用意されているOSSを使う。 単体テストをコードカバレッジアナライザにかけて実行する。 テストが最も不十分な部分を探し、そのコードのカバレッジを向上させるテストを作成する。 テストされていないコードは、テストできないコードであることが多い。 そのコードをテストしやすくなるようにリファクタリングする。 変更をパッチとして投稿する。 これの素晴らしいところは、測定可能であり、しかも短時間でできることだ。 やってみない手はない。 大きな目標を立てたら、それを常に見直すようにしよう。 経験から学び、進みながら目標を変更していこう。 最終的に目指すのは、要件の達成ではなく顧客の満足なのだから。 （そして、キャリア設定においては、顧客は君自身だ） 昨日よりよく 小さな変更で全体が大きく変わるというわけではない。 職場でもっと高い評価を受けたいとか、もっと健康な体になりたいとか願っても、 毎日の小さな改善は、目に見える結果に直接結び付かないことが多い。 既に述べたとおり、大きな目標を前にするとやる気が失せるのはそのせいだ。 だからこそ、大きくて困難な目標を目指すときには、毎日その目標に近づけたかは気にせず、 その目標へ向かって昨日より努力できたかを考えることが大切だ。 例えば、僕は昨日より今日のほうが痩せたとはいえなくても、痩せるための努力を昨日より多く実践することはできる。 そうすることによって、自分の行動に満足できる。 目に見える形で自分の行為を着実に改善し続ければ「大きくて重要なこと」を目指す際に僕らを打ちのめす罪悪感と先送りの連鎖にとらわれずに済む。 小さな改善で満足することも大切だ。 「単体テスト」への取り組みの改善」という目標に近くには、昨日より1つ多くテストを作成するだけで十分。 初日がゼロだとしたら、毎日昨日より1つ多くテストを作成するくらいなら続けられる。 そして、これ以上は無理というところまでくれば、「単体テストへの取り組みの改善」は達成しているはずで、 もう改善を続ける必要はない。 これが、作成するテストの数を1日目にゼロから50個にするという計画だったら、 1日目はとても大変になってしまい、翌日からは続けられないだろう。 だから、改善は小さく少しずつでいい。 ただし、毎日行うこと。小さな改善は、失敗の代償も小さい。 1日くらいだめでも、翌日新たに再開できる。 このシンプルな方法のいいところは、プロジェクトの完了やソフトウェアの改善といった当面の目標に使えるだけでなく、 もっと高次元の目標にも使えることだ。 キャリア向上に向かって、今日は昨日よりどんなことを努力できたか？ 人脈を1人増やす。 OSSにパッチを投稿する。 ブログに内容のある記事を公開する。 自分の専門分野のテクニカルフォーラムで、昨日より1人多くの人の役に立つ。 自己改善に向かって毎日昨日より少しでも多く努力していけば、 目覚ましいキャリアを築くという途方もなく広大に見えた目標も、だんだん現実味のあるものになるだろう。 今すぐ始めよう！ 個人的なことでも仕事関係でもいいから、実行したい困難な改善または複雑な改善のリストを作る。 リストは長くなっても構わない。 次に、リストのそれぞれの項目について、自分自身またはその項目を昨日よりよくするためにどんな努力ができるか考える。 翌日、もう一度リストを見る。 昨日は一昨日より努力できたか？ 今日はどうすればもっと努力できるか？ 翌日も同じことを繰り返す。 カレンダーにそれを書き込む。 毎朝それについて2分間考える。
