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

テスト駆動開発の著者である t-wadaさんこと、和田卓人さんの講演会に行ってきました。

前回の【まつもとゆきひろ氏 特別講演】20代エンジニアのためのプログラマー勉強法と同様にエンジニアのみならず若手社会人すべてに通ずる「勉強」の話でもありました。
自分の整理のためにもアウトプットしていきます。

スポンサーリンク

t-wadaさんとは

テスト駆動開発(TDD)のスペシャリスト

僕はminitestやrspecを少々写経した程度でまだまだ初心者ですが、テストコードを書き、テストが成功することによってプログラムの品質・堅牢さを担保する手法である「テスト駆動開発」を日本で広めてくださっている方です

執筆者であり開発者でもある

その他にもいくつか執筆を手がけておられます。

また、JavaScriptのテストライブラリ「power-assert」の開発者でもあります。
power-assertはアリババグループで利用されているらしく、GitHubでの利用者数が激増したらしいです。
power-assert-js/power-assert

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

エンジニアにとって大切なことは以下2点。

  • 学び続ける姿勢
  • 常に自分の知識ポートフォリオに投資すること

4半期ごとに技術書を読む

  • 3年は続けてみよう
  • 技術書は過去方向へのリンクが貼られた構造になっているため、辿ることで体系的に学べる
  • 脳内インデックスを作ろう

人間の脳には、感覚記憶(~2sec) / 短期記憶(~15sec) / 長期記憶の3つのストレージがあり、長期記憶は死ぬまで格納されているとする説もある。

格納はされているがその情報に辿り着けないことを「忘れる」と表現する。
つまり脳内インデックスを作ればよい、というのがメッセージ。

そのために以下を鍛える。

  • ピッカーを育てる=反復練習、何度も長期記憶から出し入れする
  • 情報を他の情報とくっつけて、連想記憶を育てる

例:技術の歴史を時系列で整理して並べておく
これにより、2004年のRails登場前後で何が変わったか?何が変わらなかったか?が理解できる
(activerecordパターンやagile databaseの概念をRailsがうまくパッケージしている)

手を動かして学ぶ

  • やる⇒【できる⇔好きになる】のループ
  • やっていくうちにできるようになっていく
  • まだできないのでやれないです。。は誤り
  • 【できる⇔好きになる】の螺旋ループに入るための入り口は、唯一「やる」しかない

これを論理的に説明しているのが【デールの円錐】
デールは、何かを行った2週間後に人はどのくらい覚えているか?を実験した。

  • 読む:10%しか覚えていない
  • 聞く:20%
  • 見る:30%
  • 見て聞く:50%(受動学習の限界)
  • LTなどで発話した:80%
  • 実際に開発するなどの行動を伴う:90%

すなわち、技術書をそのままコーディングする「写経」という学習法は効果が高い。

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

  • 初学者は仕事で使う言語をマスターしよう(Rails, JS, CSS、バッチ処理言語)
  • 仕事には使わないかもしれない別パラダイムの言語に移ろう
  • Technology Radarなどを参考に潮流に乗ろう
  • もちろん、「英語」も忘れずに

ただし、パラダイムを一度に変えすぎると失敗するので要注意。
例:動的型付オブジェクト指向言語(Rails)⇒静的型付オブジェクト指向言語 or 関数言語

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

実務で利用する言語のパラダイムから離れるほど、インプットとリアルなユースケースが乖離していく。

(Todoリストを作ろう、とかHello, Worldを出力しよう、とか)

自分やその家族だけが利用するWEBサービスを作るなど自分の生活をプログラミング対象にしよう

アウトプットを行う

  • if you want to master something, teach it.(By Richard Feynman)
  • 正のフィードバックループ:アウトプットするとインプットが集まり、またアウトプットができる
  • 失敗が許されそうな場で練習をする
  • 量は質に転化する
  • 滞留型メディアであるブログを書く

ゴミ記事論や書いた情報の質、適切な表現に怯えることなく自分のベストを尽くせばよい。

そうしないとフィードバックループは回らない。どんなアウトプットであっても一定の否定意見が発生するので割り切る。

参考:Jenkinsの開発者である川口耕介氏の発言
情報発信・ブログ・発表・公開などは数学の未解決問題の証明ではなく料理のようなもの
(公開した一番手が手柄を総取りするものではなく、料理レシピレベルのゆるさであるべき)

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

毎日コードを書く

jQuery作者 John ResigのWrite Code Every Day
彼のような天才エンジニアでも週末は平日と同じ馬力では書けない。
毎週末予定がいつも空いているわけではない。
書かない週末があると忘れてしまう。

そこでたどり着いたのがWrite Code Every Day。

彼は4つのルールを課した。

  • ブログやドキュメントはカウントしない
  • 意味のあるコードを書く(フォーマット修正やリファクタリングはノーカウント
  • 24時までで作業を打ち切る
  • githubに上げて草を生やす

毎日コードを書くことの効果

  • 必要最小限のコードへの集中ができる
  • プログラミングが習慣化して自分の生活に溶け込む
  • 不安との戦いがなくなる
  • 週末が重要ではなくなりリアルタイムが充実した
  • 散歩・シャワー中など常にプログラミングの事をバックグラウンドで考えるようになった
  • ふとした瞬間にひらめくようになった
  • 気持ちの切り替えコストがなくなった
  • ワークライフバランスが良くなった
  • 周りからの理解も得られるようになった
  • どれだけコードを書いたかという充実感が得られた

t-wadaさんが実践しているWrite Code Every Day

  • 始発駅の近くに住み、座ってコーディング出来る時間を作る
  • 意図的にオフライン時間を作る
  • オフライン時間に締切があるとなお良い(新幹線・飛行機など)

年下から学ぶ

  • 定期的に自分のスキルを棚卸しする
  • 積極的に外部に出て、自分のスキルを相対化する

過去から未来をみる

  • 技術は振り子のようにみえる
  • 実際には螺旋であり、差分がある
  • その差分を実体験として理解できているのがベテランの価値
  • 参考:技術選定の審美眼
  • 技術は5年単位で揺れるのでT字型ではなく複数の柱でスキルを持つ

所感

写経やアウトプットのやり方・方向性はまちがっていなかったのでこのまま続けていきたい。
TDDはこれから挑戦!

この一週間は所属する事業とその組織戦略を考える時間を優先して取っていた。
連動して自分の人生観・ビジョンについても立ち返り、強みや保有スキル・これから伸ばしたいスキルを棚卸ししていたので良いタイミングではあった。

それが原因でGitHubに草を生やせていなかったが(言い訳)
考えがまとまってコーディングの時間がとれるようになったらWrite Code Every Dayしてみようかな。

※参考
t-wadaさんが技術顧問としてリクルートテクノロジーズの新人研修で講演された際のスライド

この記事の内容が役に立ったと思いました、SNSで記事を共有していただけますと幸いです。