勉強会聴講：「エンジニアとしてこの先生きのこるために」

この記事は JustSystems Advent Calendar 2017 の 19日目の記事です。

初めに

この記事は、サポーターズCoLab主催イベントの和田卓人先生の講演「エンジニアとしてこの先生きのこるために」の聴講記録です。

• 主催：サポーターズCoLab
• 講演者：和田卓人さん(@t_wada さん)
• 題目：「エンジニアとしてこの先生きのこるために」
• 聴講のきっかけ：新人研修で一度紹介して頂いていて講義内容に興味をもっていたため

参考資料

私が研修中の時は、スライドが公開されていませんでしたが、今年の6月5日に以下で資料が公開されています。

• 講義スライド

このスライドだけでももちろんためになるので、講演中にあった補足の話を中心に記述していこうと思います。

テーマ1：エンジニアとしての基本姿勢とは？→「学び続ける姿勢」

• 原則は現役（いつでも使える）、ただし要素は廃れていく
• 同じものを学ぶにしても効率の良い学び方がわかってないと手詰まりになってしまう

1. 四半期ごとに技術書を読む

• 三ヶ月に一回技術書を読もう
• 和田さんの学びを支えたのは読書
• 線形に読んでいくと限界がある（ただ技術書を手当たり次第読むのでは手詰まりになる）
• 本はネットワーク構造を持つ
  • 片方向に影響を与える（差分を読むだけでいいので読むスピードが上がる
  • 本の読み方

• このスライドでは、2004年のrailsを例にそれより前にあった青い本にはrailsのことを書いてないよね？という話があり、
  • railsは前で言われていたことを全て盛り込んでいる
  • それより前の本であったものでrailsに盛り込まれているならば、そのソフトウェアから過去方向に見ていくとその設計判断の意図が見える
• といった時系列の本の読み方を語っていました
• 今年の Advent Calendar で以下の読書術も似ているなと思いました
  • 学習を加速させるインデックス読書術

2. 手を動かして学ぶ

• できるからやるではなくやるからできるという話
• 上手くなると対象のことを知りたくなる・好きになる→いいループが回る
• できないなりにやらないと学習を強化する上のフィードバックループが回らない

効果的に学ぶために（デールの円錐）

• この図は下記を説明している
  • 読んだだけの人は10％覚えている
  • 読んで聞いた人は20％覚えている
  • 見た人は30％覚えている
  • 見て聞いた人は50％覚えている
  • 発話した人は70％覚えている
  • 発話して行動を伴った人は90％覚えている ← アウトプットが大切（後述）

効果的に学ぶために（写経）

• 4番以降をしないとリニアになってしまう
• 4番以降をすることで能動的行動がわかる（意外とコミットログを見直す）
• 受動的ではなく、能動的にやる（批判的に読む、変えてみる、新しい書き方、脱線が学びを助ける）

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

• どの言語を学ぶか
  • 最初の数年は仕事に使われている言語を学ぶ
• 何を学ぶか（いくつかの軸がある）
  1. 流行りの言語や流行りそうな言語を学ぶ（上のスライド）
     • ADOPT：適応されている
     • TRIAL：試してみる価値あり
     • ASSESS：視界に入れておこう
     • HOLD：辞めといたほうがいい
  2. パラダイムで選ぶ
     • ルビープログラマーだったら、似ている言語を選ぶと学びは浅い、遠すぎるとコストが高い
       • 動的型付きのオグジェクト指向だったら一つ変える（静的型付きのオブジェクト指向とか）
       • エディタとかIDEもそう
       • 酸欠にならないように
       • 仕事から遠ざかることもあるけど、利点を仕事の言語の書き方にいい影響を与える
       • 副作用を無くしたいなら、それを強制される言語を勉強したら普段の自分の仕事のコードの書き方時の気づきになるきっかけになる

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

• 仕事に離れれば離れるほどネタがなくなる
• だったら、身の回りをプログラミング対象にしよう（個人的にはこのQiitaが面白かったです）
• 講演の時は、本の執筆でプログラミングを使い、プログラマらしく本の執筆を行う環境を整えた話をしました
  • 今まで：wordで管理してたので、ミスが入りやすい環境だった
  • プログラマだしく本を執筆（バージョン管理、自動化。。。etc)
  • 非技術者の方にもわかりやすく、価値を提供することで環境を整えていった

5. アウトプットを行う

• ある陶芸の有名な実験を例に
  • 片方は作品の質で評価（1枚をじっくり作る）
  • 片方は作品の量で評価（100枚は作る）
  • 結果、質がいいの陶芸を出すのは量で評価したほうが圧倒的に多かった（練習量で質が向上した）

アウトプットのチャネルを使ってどんどんアウトプットしよう

• blogを書く（大事にしてほしい考え方）
  • 自分が書く必要があるんだろうか？→ある！
  • 日々のやったことのアウトプット自体が価値につながる
  • 技術情報で言えば、周りの技術は変わるので今のブログの方が信頼できるようになる（2012より2017のほうが信頼度高い）
  • ただし、考えられる中で質が一番高いものを出すという意識を持つ
• 執筆する（先ずは雑誌から）
  • 雑誌は短距離・中距離（頑張れば数日）
  • 書籍は長距離（一年越え）
• コードを公開する
  • ここから機能の要望や意見などのFBが来る
• 公演する
  • 資料を作る→構成する→裏どりする＝知識の整理→アウトプットになる
• できればライブコーディング（これが一番いいアウトプット・極み）
  • 見ている人に対して与える情報が一番多い
  • 視聴者の評価が最も高いかつ安定しているのがこれ
  • ハイリスク・ハイリターン
    • 準備はクッソ大変
    • でも一番FBが得られる

テーマ2： 現役プログラマでいるために

1. 毎日コードを書く（草を生やす）

• ネタはJohe Resigさんの毎日コードを書こうというブログエントリを書いたのが元
• 毎日コードを書くにあたって4つのルール
  1. 毎日コードを書く
  2. 意味のあるコードを書く（リファクタリング等はカウントしない）
  3. 深夜24時までに終わらせる
  4. githubでOSSにする
• やってみるといろいろ変化が起こり、アウトプットの実感が持てるようになる
  • ワークライフバランスの変化が重要だった

2. 年下から学ぶ

• できる→←好きになるはループ危険性もある（過剰適合とタコツボ化）
  • それがオワコンになる可能性がある（他人から気づく・自分で気付きにくい
  • 離れづらい
• ペアプログラミング
  • ベテランにはアンラーニングのチャンス
  • 若者から学ぶ機会・打ちのめされてベンチマークを作る機会が得られる

3. 過去から未来を見る

• 技術は「振り子」ではなく「螺旋」であり
  • 全く同じものではなく、差分を学ぶ必要がある
  • ベテランエンジニアの唯一のアドバンテージ:
    • 「差分に対しての意識・理解」、「技術の見極め」ができるとこ
• T字型ではなく複数の柱を持とう
  • T字型：一つは深いそして他は浅くみたいなものではなく
    • 柱ってのは下が砂地になるパターンもある
    • 一本だと脆弱
  • 二本か三本持っていた方がエンジニアとして長生きできる
    • 一本がなくなっても二本が支えてその間にもう一個作ることができる
    • 性格の違う柱を持っていた方がいい

4. 人のつくる渦を見る

• 組織の時代から個人の時代へ(GitHubの登場）
• ロードマップ指向からエコシステム指向へ（ロードマップ指向とエコシステム）
  • 中心より周辺の方が生き残りが容易
  • 本気で行くなら中心部で勝負をして、片手間の人は中心は避けるべき

Q&A

Q: 新しい言語は何を持って学んだとするのか？

A: 動くものを作った瞬間に学んだとなる

• ライブラリかアプリケーションを作ったとき（どちらを作るかはその人の気質による）
• 本を写経しただけでは学んだことにはならない
  • OSSを公開して人に使ってもらう状態にするところまでがゴール（これは高いゴール)
  • 本とかAPIとかのリファレンスを引かなくてもある程度書けるのがところまで頑張る
    • 一年では難しい、二年くらいかな？

Q: write code everydayをできるようにGit commitするとネタが尽きてしまう。
　ネタを探すのはどうする？

A1: 機能を増やすより機能を深めると良い
A2: たくさんやると勝手にやることが出て来る

• 4つのルールでは、2番が厳しすぎるので自分に合わせる
  
• たくさんやると勝手にやることが出て来る
  • 言語のバージョン移行やOSのアップデート対応など
• 大事なのは自分の生活にコードを書く習慣をつけること
• ライブラリの移植とかも結構良い

Q: 技術書を読むときに、時系列というのがあるがどこまで遡るべきか？
　キリがないのでは？

A: 技術の歴史で見るならば20年くらいをアンテナにしとくべきかな？

• 黒い本は前半はいいこと書いてあるが、後半は全然
• 心構え等はよくもち、技術的な部分は短命
• 作った本人が出した本は読む
  • 作った本人にしかわからない軸がある

まとめ

スライドに書かれていないことを中心に講演内容をまとめてみました。
アウトプットをする人に情報は集まるというのは配属されてからも感じることなので、意識していきたいと思います。
またこの四半期では、ほんたったを買って技術書を一冊読むことが出来ました。

スライドの全部を紹介しきれているわけではないので気になった情報があった方はスライドも併せて見てみてください。