# 情熱プログラマー

市場を選ぶ
製品に投資する
実行に移す
マーケティング
研鑽を怠らない

# 市場を選ぶ

偶発的プログラミングという言葉がある
- 場当たり的に少しずつコードを書き足すこと
- トランプの城のように脆い
時に、君は偶発的キャリア選択をしていないか？
- 自分自身を「商品」と捉えて、戦略を考えて行動せよ

# 先んずるか、やられるか

テクノロジ採用曲線
- 新旧を横軸に、採用件数を縦軸に取ったグラフ
- 両端だとハイリスク・ハイリターン
- 中心付近はローリスク・ローリターン
バランスが大事かも

# 需要と供給

競争のポイントを価格から能力に帰ることが大事。そのためには：
- オフショアがやっているような仕事は避ける
- ニッチなテクノロジに注力する
  - ただし、コモディティ化された技術であっても、需要が拡大していく中でハイエンドな仕事も生まれていく、というパターンもあるのでそれはそれで OK

# コーディングはもう武器にならない

ビジネス・経営の言葉を話せるエンジニアになると非常に強い
- 技術がわかる経営陣だとうれしいでしょう？その逆と思えばいい
その意味で、どの業界を選ぶかはとても重要

# 一番の下手くそでいよう

ハイレベルな集団に身を置け
集団心理により周りに振る舞いを合わせた結果、成長できるから
怖いかもしれないが、君は思ったよりひどくないし、失うものはないんだから恐れるな

# 自分の知性に投資しよう

ニッチなテクノロジーを学ぶとよい。なぜなら：
- 採用機会が増える
  - 自己啓発と純粋な楽しみのために学べる人は、仕事にも意欲的な人物だと判断される
- 自分自身を高め、更に有能な人間になれる

# 親の言うことを聞くな

親の忠告は必然的に「不安」に根ざしたものであり、「失わないこと」が重視される
- しかし、面白さはリスクを犯した先にある。例えば転職とか。
  - 面白さがなければ情熱は保てない

# 万能選手になろう

ビジネスは流動的だから、生き残りの鍵は「柔軟性」になる
汎用性のある人間になる
特定の役割やテクノロジで自分自身を規定するな
- 地位 - Manager / Developer
- Platform/OS
- Code or Data
- Infrastructur or Application
- Business or Technology

# スペシャリストになろう

スペシャリストとは特定の分野について深い見識があること
単に他のことを知らない、という意味ではない

# 自分の人生を他人任せにするな

1 つのテクノロジに掛けるのは愚かな選択
どうしても選ぶならベンダ技術でなくせめてオープンソースを選択せよ
些末な詳細を学ぶよりも、抽象化された概念のパターンを習得することが最も大事

# 愛せよ、さもなくば捨てよ

情熱があれば
- 凡人からの一歩を踏み出せる
- 中毒者のように学べる、そしてそれが結果に現れる
情熱が持てるように色々探そう、試そう
- テクノロジ
- ビジネス
- チームの大きさ
- ウォーターフォール or アジャイル

# 製品に投資する

# 魚の釣り方を学ぶ

釣り方を自ら積極的に学び、一生の糧にしよう
どういう仕組みなのか、なぜそうなるのかを、問い続ける、学び続ける
- 仕事で使うツール
- 使っているテクノロジ
- ウィザードの裏側
- ビジネス

# ビジネスの仕組みを学ぶ

企業財務の基礎は時代に左右されないので学ぶ価値は高い
- ボトムライン（最終損益）
- コストセンター or プロフィットセンター
財務の知識があれることで、想像力を働かせて Profit を生み出す or コストを削減することができるようになる

# 師匠を探す

師匠の役割とは：

弟子の手本となる
- もって、弟子に対してより上を目指す動機を与える、など
何を学ぶべきかを示す
- 大量の学ぶべきものの中から最も重要かつ最適なものに絞り込んでくれる
評価・フィードバックを与える
- 成長の手助けになる
人脈を与える
- 「何を知っているかよりも誰を知っているかが重要」

# 師匠になる

教えることで物事を深く理解できる
強い社会的なつながりを得られる
教えることは気分がいい

# 一に練習、二に練習

実務で練習するという考えは捨てて、時間を投資しろ
練習の枠組み
- 身体的技術
  - ほとんど使ったことのない機能を探して学ぶ
  - 開発環境にあらかじめ用意されているツール群を学ぶ
- 初見
  - オープンソースのコードをダウンロードしてできるだけ短時間で理解してみる
- 即興
  - 小さいけど難しい問題を、タイマーを仕掛けて練習してみる

# 開発プロセスを大事にする

方法論（methodology）
- 良いソフトウェアを作るためのプロセスをまとめたもの
開発プロセスの整備に関する専任者がいないことも多い
- だからあなたも主体的に参加しよう
開発プロセスの整備ができる人は、開発ができる人より遥かに貴重
方法論には役に立たないものも多いが、探求し続ける努力は必要

# 巨人の肩の上で

他人のコードから有益なパターンやトリックを見つけ出す
- ≒ デザインパターン
- 他人のコードを見て、自分のスタイルや能力を見直せ
車輪の再実装（再発明ですらない）に無駄なお金を使うな

# 自動化する

生産性を向上させる方法として何が考えられる？

作業員の作業スピードを上げる
- => これは証明が難しい
作業員を増やす
- => 増やしてもスピードは上がらない
作業を自動化する
- これしか道はない！
- まずはコードジェネレータでも作ってみるといい
  - この際、再利用性は無視して OK
  - あなたの作業が楽になりさえすればいい

# 実行に移す

# 今すぐに

切迫感があれば生産性はたやすく２倍３倍になる
切迫感は自分で演出したっていい

# 読心術

マネージャや顧客が要望しそうなことを先回りして実行しておくと大喜びされる
ただし、
- 変な方向に突っ走らないように小さなことから始める
- ビジネス上の意思決定が必要なくらいの大きな変更はしない
- UI の変更には要注意

# デイリーヒット

日単位(or 週単位)で目標を設定する
- みんなが毎日手間を取られているが誰も改修しない問題を解決するなど
毎日それをこなしてマネージャに報告する
そうすれば高い評価を得られる

# 誰のために働いているのか思い出す

マネージャの役割
- 優先順位の判断と設定
- チームに必要なものを用意
- チームがやる気と生産性を維持できるよう配慮
- 要求の達成を実現すること
- 仕事を自分でやることではない
エンジニアの役割
- 全ての仕事をやること
Lv1. 顧客の問題
- Lv.2 CEO や株主の問題
  - Lv.3 チームの問題
    - Lv.4 マネージャの問題 ← このレベルの目標を知ったうえで行動することが、最終的に顧客の問題を解決することにつながる
あなたのキャリアを握っているのはマネージャであることを忘れるな

# 今の職務を全力で

今の職務に全力で取り組むと：
- 日々の小さな勝利を楽しめる
- そのことが結果（昇進等）に結びつく。逆説的だけど。
昇進のことだけを考えたり今の職務を疎かにしたりすると：
- いま能力が低いやつを昇進させようと思う上司はいない
- 昇進欲は終わりがない不毛なラットレースのようなもの

# 今日どれだけうまく仕事ができるか

退屈な仕事とは
- 創造的でない仕事
- 挑戦したいという意欲をそそらない仕事
退屈な仕事をどう楽しくするか
- 完璧を目指す
  - 例えばテストカバレッジ 100％とか
- 同僚と賞金をかけて競争する

# 自分にどれだけの価値があるか

会社は君の給与のだいたい２倍のコストをかけている
そのコスト x 収益率をハードルレートと呼ぶ
つまり会社のボトムラインにハードルレートを超える寄与をしないと雇ってもらえない
自分の価値を上乗せできそうな場面を見つけよう

# バケツいっぱいの水の中の小石一つ

その心は「君がやめても会社は困らない」
謙虚でいよう
- 成功しすぎると傲慢になる
- 傲慢になると盲点が生まれる
- 結果、足元をすくわれる
代替可能であることを積極的に認め、あえてその状態を目指そう
- そうすることが、逆にステップアップにつながる

# 保守作業の真価を知る

保守作業
- リソースや資金は少なめ
- 期待値や要求水準は低め（現状維持だけで OK）
- リファクタは創造的な作業
  - 設計からテストまで一人でできる
- 顧客に近いため、ビジネスロジックに詳しくなれる
開発作業
- 負債コードなどがない
- 期待値や要求水準は高め（ビジネス改善が必須）
- 実際には保守作業も含まれる
  - コードを 1 行でも書いた瞬間に保守の義務が生ずるから

# ８時間燃焼

長時間働いてもだめ
作業に使える時間が過剰にあると、その感覚的な価値は大幅に低下する
８時間以上は働けないというくらい徹底的に働くことで、生産性を向上させろ

# 失敗する方法を学ぶ

誰もが必ずミスをするし、予測不能な問題も必ず起こる
- 防御的プログラミングを心がけるしかない
それでも失敗したらどうすれば？
- 間違いに気づいたらすぐに問題として取り上げる
  - 隠さない、握り潰さない
- 責任問題にしない
  - さっさと自分で責任を負ってしまえ(実際はどうであれ)
  - さっさとやるべきことをやるのが大事
- 解決策を提示する
  - 少なくとも解決策を見つけるための方針を決定し期限の設定をする
- 助言を求める
  - プライドや責任感により一人で抱え込むとより悪い結果を生む
企業がミスした時の顧客への対応は、熱烈な支持を生むか、関係をぶち壊すかの分かれ道

# できないことはできないとはっきり言う

以下の二つを区別する
- 成せばなると言う気持ちで、少し高めの目標に意欲的に挑戦してみること
- 自分の能力を偽って伝えること
誠実に「わかりません」「できません」を言え
- そう言える人の「わかります」「できます」は信頼できる
- 結果として上司から信頼される

# あわてるな

慌てる必要はない
- 過去を思い返してみて、本当に災難だったことなんてないだろう？
慌てて
- 良いこと
  - 何もない
- 悪いこと
  - 全体が見えなくなる
  - 小手先の対応しか思いつかなくなる
  - 最善を尽くせなくなる
慌てた時は、スマホがバグってうろたえている君の母ちゃんと、自分を重ねて笑い飛ばせ

# 言って、成して、示す

計画
- 計画があれば、すっきりと見通しの立った状態で自信を持って作業を始められる
- 締切りにプレッシャーを感じるからといって毛嫌いしてはダメよ
戦術計画
- 主にソフトウェア開発者の領分
- 1day - 1 week
- ≒ 1 日のタスクリストを作ろう
  - 大きな敵が、小さな勝利で分割される
  - リズムが生まれる
戦略計画
- 主にマネージャの領分
- 1month - 3month
- 別にマネージャじゃなくても作っていい
  - 計画をたて、(正直に)記録を取って進捗をマネージャに報告しよう
  - 着々と完了させていけば信用が生まれ、影響力を持つことができる
    - 新しいことを試す自由を得られる

# 優れたプログラマになるには

優れたプログラマの美徳は怠惰、短期、傲慢
- というのは半分冗談なので少し真面目に
優れたプログラマに必要なもの
- 「失敗」
  - 失敗をすることで真の知識が身につくから
    - Web アプリばっか作ってると、最初から成功しちゃうから、失敗する経験が少ない
    - たまには自作のインタープリタでも書いてみろ
- 「模倣」
  - 書き写すことで血肉となるから
  - 車輪の再実装を防ぐことで前に進む促進力になるから

# マーケティング

# 視点が違えば認識も異なる

他人からどう評価されているかを気にするべきだ
- あなたの評価は他人の主観で 100%決まる
- 主観とは、個人的な好みのこと
  - e.g.
    - チームメイトなら技術力を評価してくれるだろう
    - PM なら指導力を評価してくれるだろう
    - 顧客ならコミュニケーション力を評価してくれるだろう
- 客観的な評価など世界のどこにも存在しない
良い仕事をしていれば自然と評価される、というのは幻想
- 「森の中で木が倒れても、その音を聞く者がいなければ、音はしたといえるか？」

# アドベンチャーツアーガイド

顧客（ここではユーザだけでなく君の上司も含む）は自分に安心感を与えてくれる人間を求めている
- 技術に詳しいことは二の次
- もっと言えば、顧客は技術者を怖がっている
  - 立場を逆にして考えてみたら分かるだろう
だから、顧客のツアーガイドになってあげよう
ちなみに、コンピュータの専門家は、そうでない人たちをを見下しがち
- しかし、実際には平均すれば知性は大体みんな一緒だから、変な勘違いをするな
- 各々が得意な分野を分担して会社を運営しているに過ぎない

# オレ、作文的なのは得意っすよ

文章力は重要。鍛えよ。
- グローバルチームでは文章でのコミュニケーションは必須
- 文章をまともに書けない奴はコードもまともに書けないし、評価もされない
文法や漢字の間違いはもってのほか

# そこに居ること

遠くにいることによる障壁
- 物理的な距離
- タイムゾーン
- インフラ
- 文化
- 言語
近くにいるメリット
- 身振り手振り
- ホワイトボード
- 表情
仕事部屋にこもって外部との接触を断つようなスタイルは、キャリアとしては不利よ
ではどうするか？
- メールで済む話であっても、たまにはあえて電話してみよう、会って話をしてみよう
- あまり話をしていない人をリストにして、相手に了解をとった上で、話す時間を作ってみよう(1on1)

# スーツ語

自分の業績を売り込むときは、相手が理解できる言葉で説明すること
- 経営陣が理解できる言葉で説明する
- 専門用語、技術用語は使わない
あなたが成し遂げたことは、会社にとってどんな意義があったのか

# 世界を変えよう

使命感や信念を持って、やるべきことをやろう、チームや組織を変えよう
- 小さな変化でもいい
- 単体テストを充実させて無知なプログラマにテストを書くよう仕向けるとか
- これまでより優れた新しいテクノロジの導入とか
そうすれば君が何をやっているか、何ができるかが知れ渡る
怒りを買うこともあるが気にするな

# 業界で名前を売ろう

キャリアは人脈が全て
発注者が既に君のことを知っている、という状況を作れれば最高
本を書く、Web ブログを書く、講演をする

# 自分のブランドを作ろう

ブランドの構成要素は「認知」と「尊敬」
情報発信をしよう、ただしお粗末なものであってはならない

# 自作のコードをリリースしよう

オープンソースで自作コードをリリースすれば、結果的に自分自身を売り込むことにつながる
世界規模のネットワークになる

# 目立つこと

マーケティングの目的は、サービスの提供者と消費者を繋ぐこと
マーケティング手法の主流は「口コミ」であり、口コミに重要なのは「目立つ」こと
目立つとは
- 聞かれる前から勝手に話題に登る状態であること
- 人々が話題にせずにはいられない状態であること
「何かである（＝素晴らしい能力を持っていること）」だけでは不十分
「何かをする（＝知られる努力をすること）」ことが大事
- オープンソースソフトウェアをリリースし
- 本や記事を書き
- 講演会をする

# コネを作る

コネを作りに行くことを躊躇するな、恐れるな
- 凡人で終わるかどうかは「恐れ」で決まる
ただし手当たり次第に無駄話をするのは賢明ではない
- 共通点を探す
- 相手を称賛する
- 自分の仕事への意見を求める、などが良いのでは

# 研鑽を怠らない

# 既に時代遅れである

主流になった技術は廃れる時もあっという間
- ただし COBOL は例外だけどな
次の波を予測し、研鑽をせよ
- ある意味ギャンブルだが、どのみち賭けなければ確実に負けるゲームだ
週に数時間は最新技術にキャッチアップする時間を取れ

# 君は既に職を失っている

状況は常に変化している
雇われた時点で求められていた職責は、一時的なものに過ぎない
自分の役割を固定するな、やるべきことをやれ

# 終わりのない道

ソフトウェア開発に「完成」や「終わり」はない
目的指向、結果重視の考え方だと、短期的な結果にのみ注目しすぎてしまう
永遠に続く継続的な開発（≒ プロセス）に重点をおけ

# 自分のロードマップを作る

ロードマップで確かめられること
- 軌道を外れていないか
- 着実に前進しているか
- 実現すべきものの全体像
ロードマップなしでは、路頭に迷いかねない

# 市場に気を配る

コーディングばかりに目を向けていると、技術動向の変化（大波）に気づかないことがある
Alpha Geek(最先端の情報を追いかける超マニア) な友達を作ってそいつらが興味を持っているものを調べてみるのが手っ取り早い

# 鏡の中の太った男

自分が太ったことには気づけない。気付けるのは第三者だけ。
ソフトウェア開発者の市場性やスキルも、自分では評価できない。
信頼できる第三者に積極的にフィードバックをもらい、自分を改善していこう。フィードバック結果は文書に残しておこう

# 猿の捕獲トラップ

価値観の硬直化
- あるものの価値を強く信じるあまり、それに対して客観的な疑いを持てなくなること
猿が米をつかんだまま逃げられずに死ぬトラップ
- 米の価値を信じ過ぎて、死ぬかもしれないということが見えない
あなたは特定の技術を信じ過ぎていないか？または特定の技術を毛嫌いしていないか？

# ウォーターフォールのキャリア計画はやめよう

大きな目標を立てて、それをいつも見直そう
経験から学び、進みながら目標を変更していこう
計画通りに進むことなんてないんだから

# 昨日よりよく

ほんの少しでも、昨日より良くなっていれば OK と考えよう
大きな問題には挫折しそうになるが、小さなステップなら難なくやれる
小さな改善で満足しよう。ただし毎日やろう。
クソコードの山も、毎日改善していけば、徐々に改善スピードも上がり、思いのほか良いコードになる

# 独立する

独立(or 小さい会社に転職)すれば
- 市場に自分を売り込む方法を、いやでも学べる
- 注力する技術分野についての自分の選択を見極める試金石になる