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

サポーターズColabのイベント【和田卓人氏特別講演】若手エンジニアに送る、"心構え"と"キャリア観"」に参加してきました。講演内容の備忘録です。

プロフィール

テスト駆動開発（TDD）のスペシャリストとして知られる和田卓人氏。

タワーズ・クエスト株式会社取締役社長
リクルートテクノロジーズ技術顧問
技術コンサルティングや本業の開発以外に技術書の監修、監訳、翻訳も手がけている。

• プログラマが知るべき97のこと
• SQLアンチパターン
• テスト駆動開発

テスト駆動開発の普及者。
15年近くテスト駆動開発の重要性を説いている。

「テストコードを書いていないコードはレビューに値しない。」と言うほど重視する会社もある。
現代ではテストコードの重要性が増している。

日本では、テスト駆動開発で知られていて、海外ではPower-assertの作者で知られる。

<本日の資料>
https://speakerdeck.com/rtechkouhou/enziniatositekofalsexian-sheng-kifalsekorutameni

キャリア

• プログラミングを始めたのは大学1年次18歳から。
• 大学3年次から設計とプログラミングのアルバイトを始める。
• 卒業後プログラマとしてのキャリアを受託開発として開始。
• 電子政府のサブプロジェクト（数千人規模）でリードプログラマ。
• XP*のコーチとして4人アジャイルチームに参加。

〜〜〜

• 現在

*XP（エクストリームプログラミング）はアジャイルの前に流行ったチーム開発の手法
〜〜〜で割愛したキャリアについては本日の講演で話される。

前書き

• プログラマが知るべき97のこと（https://xn--97-273ae6a4irb6e2hsoiozc2g4b8082p.com/）

↑107本の技術エッセーが綴られている。

• 達人プログラマー

↑2000年代に出版された和田さんのバイブル

この2冊の解説というのが今日の裏テーマ。

四半期毎に技術書を読む

手を動かして技術書を学ぶ。
↑達人プログラマーの中にも出てくるメソッド

四半期毎にこれを20年続けるとどうなる？
3年続けると力が付いてくる。
ルールは、ビジネス書や啓蒙書は除き、技術書のみをカウントすること。

次に何を読むかを迷うけれど、自分が良いと思った本が参考としている本を数珠繋ぎで辿っていくのが良い学習方法。本は、リンクが張り巡らされているように、参照構造によって成り立っている。

学びの仕組み

記憶の種類

• 感覚記憶...0.5〜2sec
• 短期記憶...15〜30sec
• 長期記憶...死ぬまで？

脳内に入っていても今すぐに辿り着けない情報がほとんど。
それは記憶されていないに等しい。

ではどうやって効率的に物を覚えられるかというと...

反復練習によって長期記憶から出し入れする。
情報を再整理する。
これで脳内インデックスを強化。

そして、情報を他の情報に繋げて覚える。
連想記憶を強化する。

例えば、時系列に並べる。
技術はその時に突然出現するものではなく過去の積み重ねから生まれてきている。

2004年に生まれたRuby on Railsも例外でない。

手を動かして学ぶ

✖️出来るようになったら→やる
◯ やったら→出来るようになる

これが正しいあり方。

もうちょっと情報が集まったら、事例が集まったら、ではなく...やろうと思った時がそのタイミング。

デールの円錐

2週間後の記憶率

• 読むだけ...10%

• 聞くだけ...20%

• 見るだけ...30%

• 見て聞く...50%

• 話す...70%

• 話してかつ実践もしてみる...90%

passive leaningよりもactive leaningの方が記憶の定着が良い。
本を読むだけじゃなく自分で追体験をするのが重要。

t_wada氏の写経のやり方
https://twitter.com/t_wada/statuses/9000231741

毎年少なくとも1つの言語を学習する

これは達人プログラマに書かれている姿勢。

まず、自分の会社で使われている言語を能動的に学習して、うまく書けるようにする。

今度は、仕事には使わないかもしれないけれど、違うパラダイムの言語を学ぶ。
例えば、Rubyを使っている人は動的型付けかつスクリプト言語のRubyは習得しているので、今度は静的型付け言語でスクリプト言語のGoを習得する等。
あまりにも複数のパラダイムを一度に変えてしまうとカオスになるので、それは注意。
学習する際は1つだけパラダイムを変えて自分の出来る範囲を広げて行くのがベスト。

言語の波に関してはTechnology Rader等の第３指標を参考に。
https://www.thoughtworks.com/radar/languages-and-frameworks

技術者と英語について

英語の方が情報の量も質も遥かに高い。
破綻なく読めるレベルに身につけるべき。

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

言語を学ぶって言ったって、チュートリアルでTODOリストを使っても、それはリアルなユースケースとは乖離している。

事例

• 自分がユーザーとして使いたいサービスを自分が学びたい言語で作る。

• 当初Wordで書いてEmailでやり取りして作られていた「プログラマが知るべき97のこと」を、markdown形式で書いて、gitでバージョン管理して、変更点をdiffで確認するようにして刊行まで漕ぎ着ける。（t_wada氏の事例）

アウトプットを行う

まずはアウトプット出来る場を作るのが大切。
量は質に転化する。
BlogやMediumやNoteやQiita等ストック型の物を書く。

• フロー型...Twitter

• ストック型...BlogやMediumやNoteやQiita等

"情報発信、Blog、発表、公開などは、数学の（未解決問題の）証明ではなく、料理のようなもの"
（By CIツール「Jenkins」作者 川口耕介氏）

執筆をする。（まずは雑誌等から。）
最近は技術書典など技術同人誌の登場も目覚ましい。

コードを公開する。
Power-assert
Alibabaグループでも使われている。

講演する。
できればライブコーディング人前で出来ると最高。

アウトプットのチャネル毎の特性を理解して活かそう。

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

毎日コードを書く

jQuery作者John Resig氏は、週末に自分のプロダクトを作ろうとしたが上手くいかなかった...
そこで、John Resig氏が行ったことは

• 毎日コードを書くこと。ブログ、ドキュメント、その他は、コードを書いたらやって良い。
• 意味のあるコードを書くこと。インデントやフォーマットの修正、可能ならば、リファクタリングもコード書きにはカウントしない。
• 深夜24時前には終わらせること。
• 書いたコードをgithubで全てOSSにすること。

実践して起こった変化は

• 必要最低限のコードへの集中...1日30分から1時間程度で意味のあるコードを書くのが強いられる。
• 週末の過ごし方...以前は開発の全てを週末にかけて失敗していたが、今や週末はそれほど重要ではなくなり、リアルライフを充実出来るようになった。
• バックグラウンド処理...散歩中、シャワー中、常にコードのことをバックグラウンドで考えるようになり、良いアイデアが浮かぶようになった。
• 周りからの理解...毎日コードを書くという習慣を公言したことで、パートナーからの理解も得られるようになった。

（一部割愛）

ただ、今のJohn Resig氏は、スタンスが変わったのか毎日コードを書いている訳ではなさそう。
Write Code Every Dayが書かれたのは約5年前。

住む場所を工夫する

遠くても良いから始発駅の近くに住む。
満員電車でもコード書けるので。移動をもプログラミングの時間に変えられる。

t_wada氏の場合、自宅には子供がいるのであまり集中時間を作れず、始発駅からの電車を集中時間としている。

意図的に移動の時間をオフライン時間にする

Twitterやはてブが1番の作業の妨げである。
移動は数時間で必ず到着するという締め切り効果がある。

年下から学ぶ

"一生プログラマーでいれるかどうかは、言い換えれば年下から学べるか否か"
（By Dan Kogai氏）

過去から未来を学ぶ

技術は振り子や螺旋に例えられる。
過去と今の差分を理解しろ。

技術選定の審美眼
https://speakerdeck.com/twada/understanding-the-spiral-of-technologies

一般に「これだけは負けないという専門の柱を作っておけ。」と言うT字型のキャリア形成を推奨されるが
それだと技術変動で柱が折れるとキャリアが頓挫してしまう。

プログラマとして10年以上スパンでキャリアを考えておくならばT字型ではなく複数の柱を作っておくべき。

人の作る渦を見る

Githubの登場によって、個の技術者が力を持つようになり、そして現代はロードマップ指向からエコシステム指向になりつつある。

ロードマップ指向とエコシステム指向
https://essa.hatenablog.com/entry/20140330/p1

技術的な優劣だけで技術が生き残る訳ではない。

The Rise of "Worse is Better"
http://chasen.org/~daiti-m/text/worse-is-better-ja.html

大事なことに集中する

エッセンシャル思考
https://www.amazon.co.jp/dp/B00QQKCV6E/ref=dp-kindle-redirect?_encoding=UTF8&btkr=1

結婚ではそんなに減らなかったけれど子供が生まれてから本当に自分の時間が無くなるようになった。
時間があるうちはドンドン手を広げて、柱を立てる可能性を増やす。
そして、ある程度キャリアを積んだ数十年後は、限りある時間を捻出して新たな柱を作りつつ踏ん張る。

質疑応答

Q：技術書を読んでも途中でモチベーションが下がってなかなか読了できない。
A：技術書は律儀にすべて読む必要はない。この本のこのへんにこれが書いてあると言うインデックスが貼れれば良い。社内勉強会のように複数人で学習するのもコツかと。

Q：1年で1つの言語学習を完了するとおっしゃっていたが完了したという定義は？
A：自分の書いたものを他の人が使った時（リリースされて他の人が使える状態になった時）

Q：毎日コードを書くのはどうやって継続していた？
A：自分だったら電車移動の時間だったけれど、喫茶店でも良いし、他の人に妨げられない1人の時間をいかに作るか。あとは、途中でネタ切れになると思う。プログラマには、アプリケーション開発型のエンジニアとライブラリ開発型のエンジニアがいるが、アプリケーション開発型はユーザーからの反響があるから割とネタが保つと思う。ライブラリ開発型だと日々現状に疑問を持って、要件以外にも細かい箇所を直す姿勢が求められる。