はじめに
2017/04/05にリクルートテクノロジーズで行われた和田卓人（@t_wada）先生の『エンジニアとしてこの先生きのこるために』の講義録です。
- 講義内容が大変面白かったのですが、共有されているスライドだけでは講義内でカバーされてない内容もあり、せっかく喋られていた良き内容を詳細な部分までフォローできかねてると感じること
- 和田先生自身が、本講義の内容をどんどんWeb上に投稿することを講義内で推奨されていたこと（下部、"質疑応答"の項参照）
上記理由より、この講義録を投稿します。
講義スライド
https://speakerdeck.com/rtechkouhou/enziniatositekofalsexian-sheng-kifalsekorutameni
スライドと一緒に、以下の講義録を読むとより理解が深まります。
講義録
自己紹介
@t_wada(2004年辺りからこのネーミング)
※ハイフンのアカウント、アンダースコア使わないアカウントも
『プログラマが知るべき97のこと』監修
『SQLアンチパターン』監訳（共に監訳している和田省二は実の父親）
gihyo.jpの連載、power-assert-js（非英語圏での人気高い）
『プログラマが知るべき97のこと』『達人プログラマ（職人から名匠の道）』
→ この２つの本をベースに今日は話します
※『達人プログラマ（職人から名匠の道）』 → 新装版になって本のサイズ小さくなっている。このほうが売れるからである。
エンジニアは学び続ける姿勢が大事
『プログラマが知るべき97のこと』（きのこ）
『達人プログラマ（職人から名匠の道）』（達人）
きのこ18: 学び続ける姿勢
達人5: キャリアに対する考え方
“常にあなたの知識ポートフォリオに投資すること”
技術を学ぶのではなく、技術の学び方を学ぶ
1. 四半期ごとに技術書を読む（1冊）
最初の1〜2冊は定番の本を読む
定番の本でいえば、八重洲ブックセンターは技術書の宝庫
リンクを辿って別の本を読んでいく
・本はリンク構造になっているから関連付けて読んでいく
・被参照数の多い本を読むべし
(ex) アジャイル、プログラミング作法、デザインパターンなどなど
学びの仕組み
感覚記憶(0.5 ~ 2sec)、短期記憶(15~30sec)、長期記憶(一生？)
ポートフォリオを脳内で整理していない → 結局記憶は難しい
大事なのは何度も長期記憶から出し入れする（反復練習）
どういう順番でその記憶に辿りつけるか整理しておく
たとえば、時系列に並べる
1つ基点を作って、時系列順に読んでみる。
「Railsはそれまでの良いものを詰め合わせて作られ、Railsが2004年に出来たことで、それ以後のWeb開発が変わった」
とか流れを知る。
2. まず手を動かしてやる
「やる → できる ⇄ 好きになる」
より好きになると、より出来るようになる。より出来るようになると、より好き（ry
学びの中で読むだけではダメ。
目からのインプットだけではなく、手も動かす。
デールの円錐（２週間後の記憶）
読んだものは10%覚えている
聞いたものは20%覚えている。
見たものは30%覚えている
見て&聞いては50%覚えている
話したものは70%覚えている
話して&行動したものは90%覚えている（声を伴うアウトプットすることで）
人に教えるのが、一番効率よく学習できる
『写経』これも大事
https://twitter.com/t_wada/status/9000231741
3. 毎年少なくとも1つの言語を学習する
キャリアの最初は、仕事に直結する言語
4年目以降は仕事と関係しない言語に（これが難しい）
(ex) オブジェクト指向、関数型プログラミング、リアクティブプログラミング言語
→ どんどん新しいパラダイムでてくる
例えば、Rubyの次どうする？
・考え方の根っこが同じ（PHP）→ 方言みたいなもの、これはオススメしない
・全然違うパラダイムの言語学ぶ（Scala）→ 関数型プログラミングで違うのでオススメ
他にも動的型付け言語使っていたら静的型付け言語使ってみるとか
haskel, lisp, smalltalk, euler
・技術者と英語
→ 最新の情報の速さ、量、質
全てに決定的な差がある。英語はエンジニアとしてやる上で必須。
読めるだけでもインプット総数全然変わる。
ストレスなく読めるようにするべき。
「英語が使えるのは、大きな図書館の鍵が渡されるということ」
・言語を学んでいくことのフロー
①わからないことの調べ方、学び方がわかる
②定番のライブラリをテーピングできる
③OSSで何らかのアウトプットを公開
4.身の回りをプログラミング対象にする
日々の手作業の自動化、副業の自動化などなど
以下のようなプログラマの考え方に基づいて
・怠惰、傲慢、短期
・プレーンテキストを好む
・すべてをバージョン管理する
・すべてを自動化する
・変化を抱擁する
(ex) 本の翻訳作業
・怠惰、傲慢、短期 → 原稿はmarkdownで書く
・プレーンテキストを好む → 原文はスクレイピングして取得（直接コピペしたら文字が壊れたりする）
・すべてをバージョン管理する → gitを使いバージョン管理
・すべてを自動化する → herokuにPushしてサイトに反映
・変化を抱擁したい → 監修差分はdocdiffで表示
5.アウトプットを行う
インプット ⇄ アウトプット（正のフィードバックループ）
アウトプットを行うことで、それに対してのフィードバックを受けることもできる。
量は質に転化する
何回も小さく失敗して、フィードバックを受ける。
どう次の周期に活かすかサイクルを作る。
アウトプットのチャネル
・Twitter
・blog, Qiita etc
・雑誌記事（Web、紙媒体、電子媒体） → ブログより短命、フィードバックが強烈
・書籍（共著、翻訳、監訳、単著） → 雑誌記事より長生き
・講演（社内勉強会、社外LT、社外講演）→ 人前でしゃべるのは強烈。知識整理してインプット。
・ライブコーディング → 人前でコーディング。アウトプット/インプットが一番強烈で最強。プログラミングのプロセスが見える。ただ、一番忘れがち。
・Github → オープンソース
基本線は、ストック型メディア（blog, Qiita）に自分のアウトプット書いていく。
→ ブログ・講演（まず、これをしっかり書く。）
→ 雑誌・書籍（上記アウトプットが認められてやっと出来る。まずは雑誌から。）
(ex)Jenkins作者の川口さん
「情報発信は、（最初に出すことに価値がある）証明ではなく（たくさんの人が共有してる）料理」
このとき、「僕が書いたことはみんな書いている、ハマっていることは共有しなくてもいい」という考えも浮かぶと思うが...
・情報鮮度の観点で出す価値あり
・第一人者の情報は、わからないこと多い（どこがわからないか/どこが読みにくいか）
→ 上記理由から、どんどんやったほうがいい
・プログラマはコードで価値を出している（OSSもしっかり）
・消すくらいだったら、修正して残す（リンク切れで残ってないのは寂しい）
・責任を考えてアウトプット鈍るくらいなら、責任持たずアウトプットどんどんしたほうが良い（フィードバックで修正サイクルできるし）
ポストのタイトルに【2015年初旬編】とか、寿命短そうなのであえてそう付けるなども手
現役プログラマであるために
1.毎日コードを書く
John Resig（jQuery作者）
週末に頑張ろうとしていたが、失敗。
週末が平日と馬力で書けない、全ての週末が空いているわけではない。
『Write Code Every Day』にトライ
http://ejohn.org/blog/write-code-every-day
まとめると、
①毎日コードを書く。ドキュメントはこれに含まない。
②意味のあるコードを書く。
③深夜24時前に終わらせる。
④書いたコードを全てGithubでOSSする。
John Resigに起こった変化
・必要最小限のコードへの集中（1日30分〜1時間で意味のあるコードを書く必要がある）
・プログラミングの習慣化
・不安との戦い … 進んでいるかという不安と同時に進んでいるという実感が持てるように（これ大事）
・週末の過ごし方 … リアルライフを充実できるようになった
・バックグラウンド処理 … 散歩中、シャワー中にいいアイデアうかぶように
・コンテクストスイッチ … やるというスイッチのハードル落ちる
・ワークライフバランス … 毎日やるということはバランスをとるということ
・まわりからの理解
・どれだけコードを書いたか … 充実感を得られる
t_wadaさんもチャレンジ中（Github）
住む場所の戦略
始発駅の近くに住む。
まず座席に座れる。なので、コードを書ける。
電車で40分でコードを書く。
意図的にオフライン時間を作る（ネットに繋がないことで集中できる） → そうすることで、アウトプットをコントロール
電車周りに他人だらけ（人の目を気にしなくて済む）
2.年下から学ぶ
「一生プログラマでいれるか = 言い換えれば年下から学べるか否か」
若いエンジニアのほうが、新しい概念をインプットをしやすい
35歳定年説
どう若者と同じ土俵に立てるか
過剰適合とタコツボ化
「できる⇄好きになる」
上記、ある日丸々なくなる（例えば、Flashとか）
・外部に出てどんどん自分の立ち位置を相対的に
・IDEとかエディタとかも変えてみる
40歳くらいの人はemacs使ってる（無くならないが先細り）
→ emacs以外も使えるようにならないととなる
だけど、20年使ってきてなかなか離れられない
だから若者とペアプロする（彼らは固定観念のないところからスタートしている）
3.過去から未来を知る
技術は「振り子」ではなく、「らせん」
10年前に何が限界で、何故その限界だったものが現在再び戻ってきているか
「T字型」ではなく複数の柱を持つ
複数の専門性を持つべき
4.人の作る渦を見る
組織の時代から個人の時代に
GitHubでのOSS公開
(ex) 1個人から作ったRailsが、組織を作っていく
個が多く集まると何かが起こる
OSSについて、組織に所属する必要なくなった
OSSにしたほうがよいものを作れる
ロードマップ指向からエコシステム指向へ
（アウトプット、ゴミも増えたが宝も増えた）
http://d.hatena.ne.jp/essa/20140330/p1
エコシステムの中心は、レッドオーシャン。だが中心部のほうがよいことも。
Worse Is Better（悪い方が良い）- Richard P.Gabriel
Merge Kernel(？)のほうが技術的に正しかったが、Linuxのほうが生き残った。
→ 技術的正しさより、実装のやりやすさ
正しさよりもシンプルさをつねに取りにいった結果
構造としては綺麗ではないが、とっつきやすいもの
例えば、3日で覚えられる言語（技術的正しさよりも）
→ たくさん使われる。使用量多くなることで、質も上がる。
こっちのほうが生き残る。
より多機能、より綺麗なコード
→ だからと言って生き残らないことも多い
おわりに
「技術を学ぶのではなく、技術の学び方を学ぶ」
誇りあるプロになってください。
質疑応答
※ 上手く議事録を取れていないため、和田さんが質疑応答のパートでおっしゃられてたコメントを抜粋する形でこちら記載します。
「ライブラリ開発型、アプリケーション開発型の人がいる。」
「自分の生活の中でどうプログラミングの習慣を作っていくかが大事。」
「早く出して、質をキープする。遅れるほど情報も古いものになる。」
「ブログ等のアウトプットとして書くものは、どんな小さなことでもよい。例えば、この講義のこともどんどん公開して良い。」
「みんなやってる技術ならまず押さえておいた方がいい。例えば、Railsでどうアプリケーションを作るかとか。」
「主流の技術を受け入れられないと思っても、まず触ってみてそれで良かったら続けて、やっぱりダメなら我流をいく。」
「Laravelは良いフレームワーク。Symfonyは技術的に正しいけど使うのが難しいフレームワークだったが、Laravelはこの技術的正しさの流れを汲んでいて、技術的に正しくて使いやすいフレームワークだと思う。Laravelが今後PHPフレームワークの主流になることは歓迎したい。」