技術はあとからついてくる。

就活開始の半年前にエンジニアに目覚めた人

【和田卓人氏特別講演】若手エンジニアに送る、"心構え"と"キャリア観" を受けて

これからのキャリアに悩んでいたので、どの話も目から鱗でした。
とりあえずメモっただけなので、思ったことや綺麗なまとめは後ほど..(2018/11/11)

エンジニアとしてこの先、生き残るために

講演の裏テーマになる本

大切な考え方

  • 常にあなたの知識ポートフォリオに投資すること
  • 技術を学ぶのではなく、技術の学び方を学ぶ

エンジニアとして生きていくということは学び続けていくということ
学び方の効率をあげないと限界がやってくる

学び方を学ぶ

① 3ヶ月に1冊、技術書を読む(達人プログラマ)

どういう風に技術書を読んでいるかという話

  • 技術書はほとんど参照関係になっている
  • 読んだ技術書が参考にしている本を読む(過去方向へのリンク)

学びの仕組み

  1. 感覚記憶(0.5~2sec)
  2. 短期記憶(15~30sec)
  3. 長期記憶(死ぬまで?分かっていない。格納はされているけど忘れている)

思い出せない、という事象は
長期記憶として脳内にはあるけど、どこにあるか記憶を取り出せないから起こる

脳内インデックス作る

脳は巨大な図書館と捉えると

  • ピッカー(本を探しにいく人)を育てることが大切 = 反復練習

何度も長期記憶から出し入れする

  • 荷物を他の荷物とくっつける、連想記憶を作る

例えば時系列に並べる

  • 技術書は、突然出てくるわけでなく、それまでの技術書を踏まえて、時代の先頭として出版されている
  • 過去方向へのリンクがある

時系列に並べると...
技術書の差分がわかる

② 手を動かして学ぶ(きのこ本)

やる→(できる⇄好きになる)のループ

やっていくうちに強化されていく
できるようになると好きになっていく
好きになると、それに関わる周辺のものも好きになる

このループに入るためには、まず"やる"ことが必要。

やろうと思った時が始めどき。

デールの円錐

「何かを行なった2週間後に、その人はどれくらいのことを覚えているか」という有名な実験

-- パッシブ --

  • 読むだけは全体の10%を記憶

  • 聞いた人は20%

  • 見た人は30%

  • 見て、聞いた人は50% (受動的な学び)

-- アクティブ --

  • 議論や発話したものは70%

  • 発話だけじゃなく行動が伴った場合、90%のことを覚えている

手を動かして学ぼう、の根拠の1つ

写経

しっかり読み込みたい本に対して行う

  1. ローカルで使えるSCMを用意
  2. 「本ホルダー」などで対象の本を固定
  3. ひたすらサンプルコードを写して実行
  4. 実行するたびにコミット
  5. 疑問点があったらコミットログや本に書き込む
  6. 章ごとにタグを埋め込む

③ 毎年少なくとも1つの言語を学習する(達人プログラマ)

1年目であれば、まずメインで使ってる言語をマスターする。

自分の仕事に関わる言語を学ぶという過程を終えたら
自分の仕事では使わない言語を学ぶフェーズに入る

言語のパラダイムを見るようになる
パラダイムを変えていく際には、一気に変えず、挫折しないようにする

動的型付言語をやっていたら静的型付言語やろうなど
180度ガラッと変えないで学ぶことが大事。

モダン言語を学ぶほど、言語の歴史がわかる

TECHNOLOGY RADAR

  • Techniques
  • tools
  • platforms
  • langauge & Frameworks

今学んだほうがいい順で書いてある
ADOPT>TRIAL>ASSESS>HOLD

技術者と英語について

英語ができるようになるというのは、「大きな図書間の鍵」を渡されるようなものです。
一人ひとりの人生にいろんな可能性を与えてくれます --- 高松珠子

④ 身の回りをプログラミング対象にする

TODOリスト作成やHello, Worldで学ぶことに限界がある。

日々の仕事に新しく学んだことを還元する術がないのなら
自分のためのwebサービスとかガジェットを作る。
(自分のためだけに作っている人は世の中にたくさんいる)

本の監修をした経験から...

プログラマらしく

  • 怠惰、傲慢、短期
  • プレーンテキスト
  • バージョン管理自動化
  • 変化を抱擁する(編集者をサポートしていく)

  • 原稿はmarkdown

  • 原文はスクレイピング
  • git
  • heroku
  • 監修差分はdocdiff

⑤ アウトプットを行う

デールの円錐によって考えると
効率よくインプットするにはアウトプットすることが大切

If you want to master something, teach it. -Richard Feynman

教えることはピッカーが整理されて引き出されやすくなる。

正のフィードバックループ
インプット⇄アウトプット

情報を発信する人のところに情報は集まる
アウトプットはやっていくうちに上手くなる
失敗が許される場でアウトプットしていく(社内とか有志の勉強で)

量は質に転化する

お皿を2グループに分けて作らせた

  • お皿の質だけで評価するグループ

  • お皿を作った量だけで評価するグループ

結果、量のみで評価するグループの皿の質が一番高かった。

渾身の一作を作るのではなく、駄作でもいいからたくさん作る

blogをかく

情報が正しいかどうかを取捨選択する義務を持っているのはメディア側
書く側に義務はない、これは間違ってるんじゃないかという恐れからアウトプットをしないのは非常に勿体無い
自分のベストを尽くす、それが世の中のベストじゃなくても
SNSの意見は気にするな、自分の学びに対してフィードバックループを回すことを考える

アウトプットしたら批判は必ずあると思って進む。

情報発信、blog、発表、公開などは、数学の(未解決問題の)証明ではなく、料理のようなもの (川口さん、jenkinsの作者)

数学の未解決問題の照明は一番最初のアウトプットだけに価値がある。
料理のレシピの発表ぐらいのゆるさで構わない。

5年前、作者が書いた動かしてみた記事と昨日誰かが書いた動かしてみた記事はどっちが価値があるか。
どっちにも価値があるが、今の自分に役に立ちそうなのはどっちだ?

エラーログを割愛せずに貼るの大事。
溝にハマったという情報をエラーログと共に出しておくだけで、誰かの役に立つ。価値はある。

執筆する(まずは雑誌から)

技術書展で技術同人誌を書くというハードル低めなステージがある。
そこでいいものを書いていけると雑誌の執筆や書籍を書くチャンスを得られる。

コードを公開する

power-assertはアリババで使われている

  • ライブコーディングはインパクトが強い(ハイリスク・ハイリターンなので準備が大事) 人が書いてるところを見るのは、すごく学びがある

現役プログラマでいるために

① 毎日コードを書く

write code everyday

jQueryの作者(John Resig)は週末に自分のプロダクト開発を頑張ろうとしたが失敗

  • 平日と同じ馬力では書けない
  • 全ての週末が空いてるわけではない
  • 1週間は長い、コードを忘れてしまう

そこでJhon Resigがやったこと

  1. 毎日コードを書くこと
    ブログ、ドキュメントは、その他はコードを書いたらやって良い

  2. 意味のあるコードを書くこと
    できればリファクタもコード書きにはカウントしない

  3. 深夜24時前に終わらせること

  4. 書いたコードをgithubで全てOSSに出すこと

続きそうになかったらルール自分でアレンジしても良い。
あくまでも、書く習慣をつけることが大切。

良い変化 ①

  • 必要最小限のコードへの集中 一日30分〜1時間程度で意味のあるコードを書くことが強いられる
  • プログラミングの習慣化 草を生やすのが目的ではない。生活習慣を変えるのが大事
  • 不安との戦い 進んでいるという実感は、実際の進捗と同じくらい重要だと気づいた

良い変化 ②

  • 週末の過ごし方 リアルライフを充実できるようになった
  • バックグラウンド処理 散歩中、シャワー中、常にコードのことをバックグラウンドで考えるようになり、良いアイデアが浮かぶようになった。
  • コンテクストスイッチ 以前は週に一回の開発だったので、コンテクストスイッチ(週末と平日の自分の違い)のコストがあったが、毎日やっているとノーコスト。

良い変化 ③

  • ワークライフバランスの撮り方がわかった 毎日やるということはバランスを取るということ

  • 周りからの理解 毎日コードを書く、という習慣を公言したことで、パートナーからの理解も得られる

  • どれだけコードを書いたか この習慣を続けると、書くコードやアウトプットを自分で覚えられなくなり、充実感が得られる。

スーパープログラマーのJohn Resigですら学びに対して悩んでいた。

住む場所を工夫する

  • 遠くてもいいから始発駅に住む
  • どれだけ満員電車でも座れればコードがかける

意図的にオフライン時間を作る

  • 勉強捗るのは、新幹線や飛行機(オフライン)
  • 締め切りがある(乗る時間が分かる)

② 年下から学ぶ

一生プログラマーで入れるかどうかは、言い換えれば年下から学べるか否か。

若手の方が先入観なしに学べたりする そういう人から謙虚に学ばなければいわゆる老害になる

自分のスキルを競争力あるものにするためには過剰適応にならないように気をつける

ベンチマーク・アンラーニング * 定期的にジオ分のスキルを棚卸する * 外部に出て、自分のスキルを相対化する * 使う道具を定期的に変える * 若者から学ぶ * 若者と同じ土俵で来そう

ペアプログラミング
ベテランにはアンラーニングのチャンス

新しいものを本気で日々使っている人が本気で使っているところをみる。
(このエディタを本気で使うとこんなことができるなど)

③ 過去から未来を見る

技術は「振り子」に見えるが...

分散コーピューティングと集中コンピューティングなど

技術は「らせん」である

振り子のように同じことをループしてるように見えるが、必ず差分がある。
それを同じだと指摘することは老害

今流行ってるものが何らかの理由で廃れて、10年後ぐらいに似たような技術が出てくる。
その時に、差分を追えるかどうかが、現役プログラマで入れるかどうかに関わってくる。

(技術選定の審美眼 / Understanding the Spiral of Technologies - Speaker Deck)

T字型ではなく複数の柱を

技術者として何年か立ったときに複数の柱があるといい

④ 人の作る渦を見る

織音時代から個人の時代へ

ロードマップ指向からエコシステム指向へ

ロードマップとエコシステム指向 「エコシステムの時代」

ロードマップの中では真ん中を進むべきで エコシステムの中では真ん中を避けるべきだ

フロントエンドはレッドオーシャン

ロードマップ指向はiOSアプリなど これからswiftだ、といったらswift

ロードマップ指向とエコシステム指向

The Rise of "Worse is Better"

技術的な優劣だけで生き残りが決まるわけではない。

Worse Is Better に関する自分の解釈は「設計の正しさ/美しさと実装の単純さが対立する(両立できない)ときは、実装の単純さを選択した方が、たとえそれが漏れのある抽象になったとしても現実の問題を解決し、実装の単純さによって開発参加のハードルが下がり、進化的な強さを獲得できる」というもの

⑤ エッセンシャル思考

最小の時間で成果を最大にする

  • 時間はあるうちを手を広げる
  • 柱を立てる確率を増やす

20年くらい経つとそうも言ってられなくなる

まとめ

技術を学ぶのではなく、技術の学び方を学ぶ

質疑応答

モチベーションについて

技術書を読み通すのが難しい

みんなモチベーションは下がる。 モチベーションが落ちるとき、それは技術書は最後まで読む必要がないということ。 頭の中にインデックスをつける、この本にはこんなことが書いてあった気がする。という程度でも大丈夫。

全ての本を通読する必要はない。 最後の方でモチベーションが下がるのは当たり前という温度感でもいい、

毎年少なくとも1つ言語を学ぶ

学習したというゴールをどこに置いているか

C++完全に理解した問題

自分が書いたコードを誰かが使ったということ(OSS, 家族でのサービスでも)

毎日コードを書く上で大変だったこと、乗り越えたこと

  • ネタ切れ問題は発生する
  • ライブラリ開発型、アプリケーション開発型プログラマ
  • アプリケーション型のほうがモチベーションが続く
  • ライブラリは終わりが訪れる

過去、和田さんがどの組織で働くか、個人で働くかの優先順位

アウトプットをやっていった結果、自分のブランディングがある。 ブランディングされると仕事はやってくる必要がある。 日々、アウトプットをしていたことがキャリアを変えた。 twadaになる前はほとんどアウトプットしていなかった。

自分の持っている柱が折れそうになったときにどう判断するか

自分の柱を打倒しうるのか NoSQLはRDBMSを打倒したかというとしてない 使い分けが起きる ゲームチェンジを見極める(クラウドコンピューティング、Docker)

個人のスキルの柱は古くて硬いもの。そう簡単に折れない。 新しい技術が出てきたときには、自分の柱が折れるか、や 技術のらせんについて考える。

長時間プログラミングをやると疲れるのですが、何か工夫してますか

工夫はあまりしてない。 短時間で結果を出せるようにしているが。 キーボード自作、良いディスプレイを使うなど。 次は老眼が怖い。

  • 20歳上問題 自分の20歳上の目標とする人って思い浮かばない

感想

アウトプットに関する話は勇気付けられた。(量は質に転化するなど)
技術はふり子のように見えるが、らせんであるという考えも大切だと思った。
技術書の過去方向へのリンク話もそうだが、過去があって今の技術があるということは大前提。
新しい技術が出てきたら、その変化をしっかりと観察し、どのレベルまで学ぶかを判断して自分に取りこむ力が今後生きていく上で必要だと感じた。