#はじめに
2017/09/23 にサポーターズで行われた和田卓人先生の『若手エンジニアに送る"心構え"と"キャリア観"』の講義録になります。テストケース関連でググっていた際に下記画像に出会ってT和田さんに興味を持ち、たまたま良さげなイベントが見つかったため参加させていただきました。
今回の講演スライドはあがっていませんが、内容に共通したものがある過去講演資料があったので参考までに貼っておきます。
https://speakerdeck.com/rtechkouhou/enziniatositekofalsexian-sheng-kifalsekorutameni
下記書籍のエッセンスをベースとした、プログラマーとして生き続けるための「学び続ける姿勢」と「技術の学び方」がメインテーマの講演です。
『プログラマが知るべき97のこと』
→きのこ本：学び続ける姿勢
『達人プログラマ（職人から名匠の道）』
→達人：技術の学び方
また、「学び方を学ぶ」については５部構成で説明されています。
・四半期ごとに技術書を読む
・手を動かして学ぶ
・毎年少なくとも１つの言語を学習する
・身の回りをプログラミング対象にする
・アウトプットをする
今回の講演は他の方も議事録などを書き残されていらっしゃいますが、私からも一応共有させていただきます。お手隙の際にご確認いただけますと幸いでございます。
#四半期ごとに技術書を読む
"常にあなたの知識ポートフォリオに投資すること"
"技術を学ぶのではなく、技術の学び方を学ぶ"
＊差分を抽出して効率良く読む
・本はリンク構造になので関連付けで読んでいく
・被参照数の多い本を読むべし
＊学びの仕組み
感覚記憶(0.5 ~ 2sec)、短期記憶(15~30sec)、長期記憶(一生？)
長期記憶のストレージにデータが格納されても、インデックスが付いていなければ見つからないので「脳内インデックス」をつくることが大切になる。
長期記憶の引き出し反復練習でピッカーを育てる
関連付けて連想記憶を育てる
例えば上記を育てるために、
1つ基点をつくって時系列順に読んでみる。
「Railsはそれまでの良いものを詰め合わせて作られ、Railsが2004年に出来たことで、それ以後のWeb開発が変わった」
という流れや、何が何に影響を与えて過去の参照を貼っている、どの時代に何が書かれていないといったようなことを時系列順に押さえるのも効果的。
#手を動かして学ぶ
人前でアウトプットをするのは「まだ上手くできなくて恥ずかしい」などと考えて物怖じしてしまいがちだけど、アウトプットをすると少しずつできるようになってきて「やる → できる ⇄ 好きになる」の学習を強化するフィードバックループが生まれる。
デールの円錐に照らし合わせて考えれば、技術書を読むだけでは全然覚えられないので技術者はよく「写経」をしている。
デールの円錐（２週間後の記憶）
読んだものは10%覚えている
聞いたものは20%覚えている
見たものは30%覚えている
見て&聞いては50%覚えている
話したものは70%覚えている
話して&行動したものは90%覚えている（声を伴うアウトプットすることで）
人に教えるのが、一番効率よく学習できる
#毎年少なくとも1つの言語を学習する
キャリアの最初は仕事に直結する言語を深化させるべきだが、新しい言語の習得には学び方にテーマ性を持たせることが大事である。
例えば、Rubyの次は何を学ぶか
・根っこの考え方が同じ（PHP） → 方言みたいなもの、似通いすぎるとあまり学びがないためオススメしない
・全然違うパラダイムの言語を学ぶ（Scala） → 関数型プログラミングで違うのでオススメ
他には動的型付け言語なら静的型付け言語を学ぶなど、自分が持っているスキルセットを一つづつ変えていくのがポイントになります。
＊技術者と英語について
英語ができるようになるというのは「大きな図書館の鍵が渡される」ということである。英語が読めるだけで情報量、速度、質などのインプット総数が大きく異なる。
#身の回りをプログラミング対象にする
仕事で使う言語から離れると「何を作ろう」とネタ切れになってしまいがちだが、身の回りをプログラミング対象にすることで解消できる。また、使ったことがない言語で取り組むのも良い学習負荷が掛かる。
プログラマの考え方に基づいて、本の翻訳作業で学びを取り入れるのであれば、
・怠惰、傲慢、短期 → 原稿はmarkdownで書く
・プレーンテキストを好む → 原文はスクレイピングして取得（直接コピペしたら文字が壊れたりする）
・すべてをバージョン管理する → gitを使いバージョン管理
・すべてを自動化する → herokuにPushしてサイトに反映
・変化を抱擁したい → 監修差分はdocdiffで表示
#アウトプットを行う
情報は情報を後悔した人の元により集まるため、インプットとアウトプットを回してより良い強化学習を行うことができる。
インプット ⇄ アウトプット（正のフィードバックループ）
アウトプットを行うことで、それに対してのフィードバックを受けることもできる。
量は質に転化するので、何回も小さく失敗してフィードバックを受けよう。プログラミングもアウトプットすればするほど洗練されてコストも下がり、心理的負荷も下がります。
アウトプットのチャネル
・Twitter
・blog, Qiita etc
・雑誌記事（Web、紙媒体、電子媒体） → ブログより短命、フィードバックが強烈
・書籍（共著、翻訳、監訳、単著） → 雑誌記事より長生き
・講演（社内勉強会、社外LT、社外講演）→ 人前でしゃべるのは強烈。知識整理してインプット。
・ライブコーディング → 人前でコーディング。アウトプット/インプットが一番強烈で最強。プログラミングのプロセスが見える。ただ、一番忘れがち。
・Github → オープンソース
基本線は、ストック型メディア（blog, Qiita）に自分のアウトプット書いていく。
→ ブログ・講演（まず、これをしっかり書く。）
→ 雑誌・書籍（上記アウトプットが認められてやっと出来る。まずは雑誌から。）
(ex)Jenkins作者の川口さん
「情報発信は、（最初に出すことに価値がある）証明ではなく（たくさんの人が共有してる）料理」
このとき、「僕が書いたことはみんな書いている、ハマっていることは共有しなくてもいい」という考えも浮かぶと思うが...
・情報鮮度の観点で出す価値あり
・第一人者の情報は、わからないこと多い（どこがわからないか/どこが読みにくいか）
→ 上記理由から、どんどんやったほうがいい
・プログラマはコードで価値を出している（OSSもしっかり）
・消すくらいだったら、修正して残す（リンク切れで残ってないのは寂しい）
・責任を考えてアウトプット鈍るくらいなら、責任持たずアウトプットどんどんしたほうが良い（フィードバックで修正サイクルできるし）
#現役プログラマであるために
＊毎日コードを書く
John Resig（jQuery作者）
『Write Code Every Day』にトライ
http://ejohn.org/blog/write-code-every-day
①毎日コードを書く。ドキュメントはこれに含まない。
②意味のあるコードを書く。
③深夜24時前に終わらせる。
④書いたコードを全てGithubでOSSする。
John Resigに起こった変化
・必要最小限のコードへの集中（1日30分〜1時間で意味のあるコードを書く必要がある）
・プログラミングの習慣化
・不安との戦い … 進んでいるかという不安と同時に進んでいるという実感が持てるように（これ大事）
・週末の過ごし方 … リアルライフを充実できるようになった
・バックグラウンド処理 … 散歩中、シャワー中にいいアイデアうかぶように
・コンテクストスイッチ … やるというスイッチのハードル落ちる
・ワークライフバランス … 毎日やるということはバランスをとるということ
・まわりからの理解
・どれだけコードを書いたか … 充実感を得られる
＊住む場所の戦略
始発駅の近くに住む。
座れる電車に乗ることで意図的にオフラインの時間を作ることができ、移動時間に集中してコードを書くことができる。
＊年下から学ぶ
「一生プログラマでいれるかは、言い換えれば年下から学べるか否か」
「過剰適合とタコツボ化（できる⇄好きになる）」
「できる好きになるループだけでなく、あえて選択肢から外してアンラーニングしなければいけないタイミングがある」
「定期的に自身スキルの見直し」
・外部に出て自身の立ち位置やスキルを相対化する
・IDEとかエディタとかの使う道具を定期的に変える
・未知のコミュニティに参加する
・若者から学ぶ
・若者と同じ土壌で競う
40歳くらいの人はemacs使ってる（無くならないが先細り）
→ emacs以外も使えるようにならないととなるが、20年使ってきてなかなか離れられない。従って、若者とペアプロすることでアンラーニングする機会をもつ（彼らは固定観念のないところからスタートしている）など
＊過去から未来を知る
技術は「振り子」ではなく「螺旋」
10年前に何が限界で、何故その限界だったものが現在再び戻ってきているか
「T字型」ではなく複数の柱を持つ
ジャンルの柱には寿命や流行などその他外的要因により、オワコンになる可能性があるので３つ以上の専門性を持つべき。その上で性格が違う柱を選択する方がいい。
＊人の作る渦を見る
「組織の時代から個人の時代に」
GitHubでのOSS公開
(ex) 1個人から作ったRailsが、組織を作っていく
「個が多く集まると何かが起こる」
OSSについて、組織に所属する必要なくなった
OSSにしたほうがよいものを作れる
「ロードマップ指向からエコシステム指向へ」
http://d.hatena.ne.jp/essa/20140330/p1
「エコシステムの中心はレッドオーシャンなので避けるべきだが、ロードマップは中心を進むべき」
例えばiOSデベロッパーの場合、Apple社の指し示すswiftではなく「それでも僕はCでいく」というような姿勢は危険だということ。
Worse Is Better（悪い方が良い）- Richard P.Gabriel
Merge Kernel(？)のほうが技術的に正しかったが、Linuxのほうが生き残った。
→ 技術的正しさより、実装のやりやすさ
正しさよりもシンプルさをつねに取りにいった結果
構造としては綺麗ではないが、とっつきやすいもの
例えば、3日で覚えられる言語（技術的正しさよりも）
→ たくさん使われる。使用量多くなることで、質も上がる。
こっちのほうが生き残る。
より多機能、より綺麗なコード
→ だからと言って生き残らないことも多い
#おわりに
「技術を学ぶのではなく、技術の学び方を学ぶ」
「自分の生活の中でどうプログラミングの習慣を作っていくかが大事」
「大事なことに集中する」
自身の人生を進めていくにあたって、大事じゃないものは断って、選択して大事な何かに集中する必要がある。結構や子供ができるなどのライブイベントによって今まで取れていた時間も取れなくなる。
エンジニアは勉強し続ける必要がある。しかし時間は有限であるため、最小限で最大効率の学びを得る必要がある。
#質疑応答
Q：新しい言語は何をもって「学んだ」とするのか?
A：自分で作ったサービスを公開するところまで。エンジニアにはライブラリ型とアプリケーション型がいるので成果物は異なる。また、何も見ずにスラスラ書けるようになる、というのが一つの到達点。
アプリケーション指向：サイトやアプリを公開
ライブラリ指向：ライブラリを公開
Q：WriteCodeEveryDayに取り組んでいるが毎日コミットできるネタしか選べない縛りが苦しい
A：大事なのはプログラミングを習慣化すること。手段が目的化しやすいので注意、John Resig氏のルールは厳しすぎるので適度に緩めよう。意味のあるコードはリファクタリングも１カウントしたい。また、ライブラリをたくさん作ってサービスを公開していればユーザからバグ報告や要望として降ってきて、更新しなきゃいけないリストがたまる。
Q：書籍はどのように取捨選択すればいいか
A：制作者本人しか出せない内容があるため言語作者本人の書いた本は抑えたい。時代を遡って読む場合は、探索の幅を20年程度に狭める。