情熱プログラマーを読んだので、大事だなと思ったことをまとめる。
大雑把には、『ソフトウェア開発で注目に値するキャリアを築くための方法』を学べた。
第1章 市場を選ぶ
1 先んずるか、やられるか
市場価値の高いエンジニアを目指す。
『先んずる』場合は、これから流行るであろうテクノロジに取り組み、市場の先をゆく。もちろん、次世代で流行らないと言うリスクもある。
『やられるか』場合は、テクノロジを最後まで看取り、死にゆくシステムの保守という作業を繰り返す。市場的には、死にゆくテクノロジのため、市場に取り残されると言うリスクもある。
安定したテクノロジの場合、リスクは無いが市場価値という意味では見返りは少ない。
2 需要と供給
価格競争に勝ち目はない。市場の不均衡を狙う。需要の高い労働市場は、最終的にプログラマの価格は下がる。理由は、参入者(供給)も多くなるため。
企業の中には、需要の高い労働市場にエンジニアを派遣する企業もあり、どうしたって、そんなの相手には戦えない。
だったら、ニッチなテクノロジに注目するのも手と言える。
一番いいのは、オフショア*1の進出がなく、国内で需要が多そうに見えるスキルを身につけること。
3 コーディングはもう武器にならない
テクノロジは、金で手に入る日用品になっている。そう考えると、コーディング能力だけでは食べていけない。コーディングだけでいいなら、買えばいいので。
大事なのは、ビジネス(業界)の分野における経験。ビジネスの分野もテクノロジと同様に選択する。つまり、どんな企業と業界で働くかを選ぶ。
自分の時間を、どんなビジネスに投資するかを考える。そのために、ビジネス屋と話をしたり、業界誌を読んだりして、情報を集める。
4 一番下手くそでいよう
簡単に言えば、レベルの高い環境に身を置けということ。
自分の周りの人たちが、自分自身のパフォーマンスに影響する。自分と違う環境に身を置いたとき、その環境を自分に取り入れる。
周りの人間が自分よりも能力が高い場合、その人たちに近づこうという心理が働き、自身の能力を高めることができる。
5 自分の知性に投資しよう
注目すべきテクノロジを選ぼうとすると、一番仕事が多いテクノロジに目を奪われがち。その観点からすると、ニッチなテクノロジへの投資は、馬鹿げているといえる。
しかし、仕事が多いテクノロジのエンジニアでは、差別化しないと埋もれてしまう。ニッチなことも知っているというのは、大きな武器になる。
新しい言語を学び、新しい考え方を理解し、自身の幅を広げる。
6 親の言うことを聞くな
親世代と価値観が異なることを認識する。親世代のキャリア選択の決定的要因は安定だった。
今はそんな時代ではない。市場価値として、1つのやり方(1つの企業でしか働いたことのない)しか知らないエンジニアよりも、いろんな環境で多彩な成功と失敗してきたエンジニアの方が価値がある。
7 万能選手になろう
ソフトウェアは製造業の製造ラインのようにはいかない。理由は、ビジネスが流動性を持つように、ソフトウェアも柔軟性がある。変化が激しいので、型にはまったやり方はやりにくい。
よって、開発の特定のプロセスしかできない場合、要求の変化等があると、すぐに手待ちが発生してしまう。もっと言えば、特定しかできないエンジニアは、替えが効きやすい。
自分自身をどこでもやれる万能選手を目指すことで、市場価値が上がる。
8 スペシャリストになろう
スペシャリストは、『一つのことしかできない』という意味ではない。わからないことも自身や周りの力を借りて、解決する人のことを言う。
人に教える機会は、自分自身が学ぶための最善の方法。
9 自分の人生を他人任せにするな
ベンダーに依存しすぎない。よって、一つのテクノロジにのみ投資するのは賢明ではない。
10 愛せよ、さもなくば捨てよ
自分の仕事に情熱を注ぐ。理由は、それが結果に表れるから。情熱を持てる仕事を見つけることで、凡人から大きな一歩を踏み出すことができる。どうしても情熱を注げないのであれば、新たな一歩を踏み出す時なのかもしれない。
『とにかくやれ、やれないはずはない。』
第2章 製品に投資する
キャリアアップに役立つ、自身への下記のような投資戦略を学ぶ。
- スキルや技術の選択の仕方
- 投資方法
11 魚の釣り方を学ぶ
アクティブに学ぶ姿勢を作り、知識や技術をきっちりと身につけて、自分でできるようにする。
その際には、自分の仕事の中で、完全に理解できていないところを掘り下げてみる。そして、『なぜ』、『どうして』を自問し、理解を深めるようにする。
12 ビジネスの仕組みを学ぶ
『ビジネスを学べ』
ビジネスで利益を上げる方法を知らないと、想像力を使って付加価値を生み出せるような仕事はできない。ビジネスがどう成り立っているかを知ることで、攻め方を知ることができる。
そのために、MBA(経営学修士)志望者向けの本を読んでみる。
13 師匠を探す
誰かに頼ってもいいが、相手を選ぶ。
手本となる人を何人か見つけて、その特徴を洗い出す。その特徴に重要度と、現時点での自身の能力値の差分をとり、最も大きな差となっているものを、最優先課題として能力向上に努める。
14 師匠になる
何かを教える時には、誰かに教えるのが1番の近道。教える際には、自身が理解しており、さらに頭の中で整理されてなければならない。教えることで、自身の理解が整理され、さらに理解が深まる。
15 一に練習、二に練習
練習の目的は、自分の能力を伸ばすこと。部活と同じように、自主トレをしないと大会で戦えない。つまり、自分の技術に対して投資しなければ、品質という世界では戦っていけない。
自主練では、自分の限界ギリギリを攻めることが大事。本では次のことを薦めている。
- できる範囲を広げるために使ったことのないAPIや関数を使ってみる
- コードを理解する力をつけるためにOSSのToDoにチャレンジしてみる
- コーディング力を鍛えるためにプログラミングコンテンストに参加してみる
プログラミングコンテストは、AtCoderとかpaizaみたいなやつならやったことがあるので、今後も時間があればチャレンジしてみよう。
16 プロセスを大切にする
プロセスとは、方法論として体系化されたもの。ここでいう方法論は、上から押し付けられる意味のないものではなく、先人たちの知恵を体系したもの。
プロセスを身につけるためには、実践が一番。プロセスを色々学び、実践の中で自分達にとって有益となるように、プロセスを選び出し、プロセス自体を磨いていくことが重要。
17 巨人の肩の上で
先人たちの優れたコードから色々学ぶ。
広く普及したOSSで公開されたコードを読み、どんな書き方をしており、どんな意図があるかを考える。OSSを色々知ることで、車輪の再実装といったことも起きにくくなる。
18 自動化によって仕事を確保する
生産性向上に確実な方法は、自動化する能力。自動化さえできれば、人手不足にも対応できる。まずは、繰り返しコーディングしている処理などがあれば、コードジェネレータを作ってみるのも手。
MDA(Model Driven Architecture)*2について調べてみる。
第3章 実行に移す
すぐに実行に移せる人材になるために何をすべきかを学ぶ
19 今すぐに
コンテストのような気持ちでプロジェクトにあたる(決められた時間に決められた機能を実装するような)
20 読心術
読心術を磨いて、相手の信頼を得る。日頃のふたした会話などから、真の要求を読み取り、不言実行で進めてみる。UIような部分については読み取るのは難しいので、やめておく。
21 デイリーヒット
報告できる成果を毎日あげる。チームがいつも我慢しているような些細な問題(自動化できるようなもの)をメモして片付けてしまうというのも有効。
22 誰のために働いているのかを思い出す
日々の仕事がどうチームの目標に貢献できているかを確認する。そうすれば、目的意識が生まれ、働く意味も見えてくる。
23 今の職務を全力で
野心を抱け。でも前面には押し出さない。野心を押し出しすぎると、上からの印象が悪くなり、投資されなくなる。
今の職務に全力を尽くし、きっちりこなす。現在のタスクが、自身の評価の指標になる。
24 今日どれだけうまく仕事ができるか?
退屈な仕事を楽しくする工夫を取り入れる。楽しさが増えれば仕事もそれだけうまくいく。
退屈な仕事の多くは、非創造的で義務的なもので、日常業務に占める割合も多い。なので、ここの楽しさを増せれば、仕事にも退屈しなくなり情熱を持って取り組めるようになる。
例えば、退屈な業務をこなした数を見える化して、同僚と競争できるようなことをするのもあり。賞金などもあると、さらに良いかもしれない。
25 自分にどれだけの価値があるのか?
給料の2倍の価値を生み出さなければ、会社にとって利益になる人材にはなっていない。いかにその値に近づけられるかは、日頃から自身の価値について考える必要がある。
常に、今日の自分の仕事に価値(会社にとって利益を生み出したか)があったかを自問する。
26 バケツ一杯の水の中の小石の一つ
『謙虚であれ、成功に溺れるな』
いくら能力が優れた人であっても、その人が抜けても悲しいかな、会社は回る。
今まで順調である場合、自分に自惚れ、自身のやり方に固執しやすくなる。常に最良の方法があるはずと自身に問う。
誰もが代替可能な存在であることを認め、その状態(例えば、誰でも保守できるコードになっているとか、誰かに依存している作業をなくす等)になるようにチームをリードできる人材が特別な存在となる。
27 保守作業の真価を知る
保守業務も自由で創造的にできる。保守業務であってもコードのリファクタリングなどができる。また、アプリケーションの品質が測定可能なリスト(応答時間、稼働時間等)を作って、そこに対してパフォーマンス改善を実施することもできる。
そう考えると、保守作業では創造的にいろいろな開発ができるといえる。
28 8時間燃焼
プロジェクトはマラソンであり、短距離走ではない。労働時間を長くして、短期的な生産性を向上しても、結局は燃料切れを起こして、効率は激しく落ち込む。
決められた時間の中で、最大限の効果を出すように努力する。つまり、8時間燃焼は8時間で力を出し切ると言う意味になる。
そのためには、早め早めに段取って、作業をうまく凝縮させるようにして事に当たる必要がある。
29 失敗する方法を学ぶ
人間なんだから、誰でも仕事の中、愚かなミスをする。大事なのは、ミスに対処、対策すること。
間違いに気づいて、ミスに対処する上での原則は次のもの。
- 直ちに問題として取り上げる
- 責任を負う。罪を負わせようとしない。責任の追求も時間の無駄。問題を解決する。
- 解決策を提示する。なければ、解決を見出すための方策を計画する。方策は、具体的かつ予測可能な期限を設定したものにする。
- 助言を求める。プライドを捨て、解決に向けた協力を依頼する。
失敗こそ成功につなげる絶好の機会。なぜなら、ミスした時の自分の振る舞いで、熱烈な支持を得られるか、それともぶち壊すかが決まる。真摯に対応する。
30 できないことは『できない』とはっきり言う
何でもかんでもできると言って、結果できない場合、信頼されない。『できません』と言えるチームの『できる』という言葉には信用がある。言うべきことを言い、より良い提案ができるのが価値のある開発者。
注意としては、『できません』の乱用はダメ。試しにやってみたい場合には、『簡単ではないがチャレンジしてみたい』と言う感じで伝える。
31 あわてるな
問題発生時に1番大事なことは慌てないこと。慌てると判断できなくなり、最善を尽くすことができなくなる。
また、そうしたピンチがあったとしても自分のキャリアには大して影響を与えないので、深刻に考えなくても良い。
慌てないためのコツは、その状況を第三者の視点で俯瞰すること。第三者として、困っている人を助けるという意識で、自分の状況を見てみると冷静に行動しやすい。
パニック日記をつけて自分の性格を分析するのも有効。
32 言って、成して、示す
計画をする。まずは1日のタスクをリスト化し、計画を立てる。このとき、リストのものを全て完了できなくてもOK。見積もりには誤差が絶対に乗るから。大事なのは、優先度をつけてやることを整理し、見通しを立てること。
1日の計画になれてきたら。30〜90日程度の大局的な、つまり戦術的な計画を立てる訓練をする。訓練をすることでそうしたレベルの計画の精度も上がっていく。
計画したら、必ずそれを報告し、計画に対してどうなったかを記録する。計画が省みられていない場合、誰も自分の計画を信用してくれない。
第4章 マーケティング...スーツ族だけのものじゃない
どんな優れた製品も知ってもらえないと買われない。ソフトウエア開発者にも同じことが言える。
リーダに自分の能力を理解させる方法と、業界全体に視野を広げる方法を学ぶ。
33 視点が違えば認識も異なる
他人の評価を気にすること。また、他人の評価は、認識の主体に(環境)よって変わる。 環境に応じて何をアピールすべきかを、次のような要因リストとして洗い出し、各環境に適した見せ方をする。
グループ | 認識の決定因子 |
---|---|
チームメイト | 技術的技能、社会技能、チームワーク |
マネージャ | 指導力、顧客重視、コミュニケーション能力、遂行力、チームワーク |
顧客 | 顧客重視、コミュニケーション能力、遂行力 |
プロジェクトマネージャ | コミュニケーション能力、遂行力、生産性、技術的技能 |
周りからの自分への認識=自身の評価。
34 アドベンチャーツアーガイド
マネージャーや顧客(この節では、以降顧客)が求めるものは、プロジェクトについて彼らに安心感を与えてくれる人間。
ソフトウエアエンジニアは、開発において顧客のツアーガイドのようなもの。大柄な態度は最悪。常に謙虚で。
そうして、顧客から信頼を勝ち取ることで、顧客から支持を得たエンジニアになれる。
35 オレ、作文的なのは得意っすよ
作文技術は大事。自身の認識を左右する要因として文章力の比重が大きくなっている。
自分自身を言葉で表現できなければ、プログラムだってうまく組み立てられるわけがない。
わかりやすく表現できるのは、明快な設計とシステム実装能力とそれほど変わらない。
36 そこに居ること
直接会う方が、高い生産性と意思疎通が見込める。コミュニケーションがより効果的だから。
つまり高い生産性にはコミュニケーション能力が重要である。
会社にとって、欠かせない人材になるためには、一緒に働く人と密にコミュケーションを取る努力が必要。
37 スーツ語
ビジネスを運営している人たちの興味は、ビジネスの結果にある。よって、自分の業績を売り込むときは、そのビジネスに合った言葉を使わないと効果がない。
自分の成果が、ビジネスにとってどんな利益をもたらしたかを語る。
常にエレベータースピーチを用意しておく。
38 世界を変えよう
社員同士で、それぞれの業績を知らないのはヤバい。
使命を持って仕事をする。自分自身や目先の仕事ではなく、チームや組織、会社の人たちに変化をもたらせる必要がある。
改善の余地があるなら、変化をもたらす人材になれ。
39 業界で名前を売ろう
人脈が多いほど、適職やキャリアブレイクにつながる可能性が高くなる。
ブログで自身の考えなどを発信する。コメントなどもしてみる。そうしたところから、繋がりを増やしていく。
地域コミュニティ(開発者グループ)でスピーチすることも有効。
40 自分のブランドを築こう
認知と尊厳を得たいと言っても、Webでうざったい奴になってはいけない。
自分のブランドが落ちてしまう。世間の印象はそうしたところから形成され、いったんできると中々変わらない。
41 自作のコードをリリースしよう
オープンソースに寄与することは、ソフトウエア開発に対する情熱や技能の証明になる。
無償でやる気があることの裏付けは、積極性のアピールとなる。
42 目立つこと
行動に移し、アウトプットする。そして、注目度を高められる状況を作る。
43 コネを作る
普通の人間とプロを隔てているのは恐怖心。『虎穴に入らずんば虎子を得ず』の精神で、プロのコミュニティに関わってみる。
第5章 研鑽を怠らない
一発屋にならない方法を学ぶ
44 既に時代遅れである
IT業界は常に新しいことを学ぶ必要がある。人はビジネスが成功すると、そのビジネスモデルに安住しがち。
誰かが革新的なアイディアで市場に参入してくると、その成功は簡単に崩れる。
今何を学ぶべきかを、先取りして考える必要がある。週に一回は最前線技術を調査する時間を設ける。くれぐれも怠けない。
45 君は既に職を失っている
職務にこだわらない。現代は特定の職務だけでこなしていればなんとかなるというキャリアはない。
テスターやプロジェクトマネージャーになったつもりで仕事をして、職務の幅を広げるのが大切。
46 終わりのない道
努力を怠らない。成果が重要ではなく、成果のために努力することが大事。
成果ばかりを追い求めると、プロセスの質を高めるのを怠りがち。
悪いプロセスは悪い製品を生み出す。目の前のことではなく、将来の発展を見据えて行動する。
47 自分のロードマップを作る
自分という製品の『機能』を具体的な目標として設定する。
目標がないとどこに進めばいいかわからないので、一時的にでもいいので何に投資するかを決定する。
そして、ときおりその選択の結果の集合(自分のスキル)として、どんな製品になれるかを考える。
これまできたキャリアのロードマップを立てて、どう更新していくかを考える。
48 市場に気を配る
アンテナを高くして、技術系ニュースに目を通す。市場がどんなエンジニアを求めているか、変化していくかに気にかける。
そうすることで時代に取り残されない。
49 鏡の中の太った男
50 南インドのサル捕獲トラップ
硬直した価値観が自分をダメにする。一つのキャリアや技術に固執しすぎない。色々な技術を試してみて、食わず嫌いにならない。
51 ウォーターフォール式のキャリア計画はやめよう
アジャイル開発は、変化を受け入れ反復的なアプローチによって開発を進める手法。複雑な問題を解決しようとする時に、苦労を少なく進めるのに効果的。
人生のキャリアもある意味で開発と一緒。自分自身を製品と考えると、ウォーターフォール式に決められるものではない。変化に柔軟に対応していくことが求められる。
人生のキャリアにおける顧客は自分自身。自分自身が満足できるように、経験し進みながら、目標(キャリア)を変更していく。
52 昨日よりよく
大きて困難な目標を目指すときは、大抵の人間はその複雑さやハードルの高さからやる気を失ってしまう。そんなときは、『その目標に近づけたかではなく、昨日よりも努力できていたか?』を考えるのが大切。
目に見える形で自分の行為を着実に改善し続ければ、『大きくて困難な目標』を目指す際に受ける罪悪感や先送りの連鎖に囚われなくなる。
53 独立する
タイトルの通り。目覚ましい業績を目指すのであれば、独立する。後ろ盾がない状況となれば、自分自身の力でしか勝負ができないので、必然的に売り込む力や技術を身につけなければ生きていけない。
いきなり独立はなかなかハードなので、少し小さい企業や新興企業に転職するのも手。