はじめに
和田さん（@t_wada）の講演が素晴らしく良かったのでメモを残しておきたいと思います。和田さんと言えば...
ですね！本講演では、「技術の学び方を学ぶ」ことを目的として二部構成で論が展開されました。「技術の学び方の学び」とは、メタレベルの学びのことを指しています。すなわち、効率的に新しい技術を学ぶためにはどのように学べば良いのかという話です。内容は以下の通りです。
第一部
- 四半期ごとに技術書を読む
- 手を動かしながら学ぶ
- 毎年少なくとも一つの言語を学ぶ
- 身の回りをプログラミング対象にする
- アウトプットを行う
第二部
- 毎日コードを書く
- 年下から学ぶ
- 過去から未来を見る
- 人のつくる渦を見る
- 大事なことに集中する
いずれも非常に興味深い内容だったのですが、細かい事項については2017年の講演メモのエントリーがありましたので、ぜひそちらをご覧いただければと思います。（記事へのリンク）
本エントリーでは、以下の2点について深く取り上げたいと思います。
- 技術書の読み方
- アウトプットの仕方
本を読む目的
技術書を読む目的は主に2つ：
- 自分の脳内にインデックスを作る
- 書かれている内容について習熟する
「自分の脳内にインデックスを作る」というのは「この本にはこんなことが書いてあったな」というインデックスを脳内に作り、書かれている内容については忘れてしまう（覚えているに越したことはないのですが、人間そんなにうまくできていない）ということです。書かれている内容について習熟することは一般的な本を読む目的として知られていることと思います。
脳内にインデックスを作ることの効用は書くまでもないかもしれませんが、これを作っておくことで、その技術が必要になったときに即座にアクセスできることはもちろん、どの技術を用いてどんなことができるのかを知ることができる点にあります。車輪の再発明を避けることができますね。
本の読み方
先にも述べた通り、本を読む目的は2つありました。インデックスを作ることが目的であれば、短時間でサラッと読めばいいのですが、深く読み込むためにはそれなりに工夫が必要です。本講演で和田さんは「写経」することを勧めていました。写経の手順は以下のツイートの通りです。
技術書の「写経」の方法。 1.ローカルで使える SCM を用意 2.「ほんたった」などで対象の本を固定 3.ひたすらサンプルコードを写して実行 4.実行するたびにコミット(コミットログにページ番号を含める) 5.疑問点があったらコミットログや本に書き込む 6.章ごとにタグを打つ
— Takuto Wada (@t_wada) February 12, 2010
いいですね。もちろん、すべての本に対してこの方法をとっていては時間が幾らあっても足りませんので、身に付けたい技術を絞り、本も定番とされているものを一冊決めてじっくり読み込むことを推奨していました。
アウトプットの仕方
インプット型の学びは極めて楽です。しかしながら、受け身で学んだ内容が身に付きにくいことは周知の通りです（Ref:デールの円錐）。新しい技術を学んだのであれば、その技術を全くの初心者に対して理解させることを目指すべきだし、新しいプログラミング言語を学んだのであれば、その言語を用いてまっさらな状態から何かしら自分の困っていることを解決するためのツールを作ることを目指すべきです1。
したがって、何らかの方法でアウトプットを行うことが肝要なわけです。手法は様々だと思いますが、既存のサービスを使うのがいいと思いますし、@t_wadaさんも以下のようなサービスをアウトプットのチャネルとしてお勧めされていました。
ここでの注意点として、文書でアウトプットを行う場合はflow型であるTwitterなどのチャネルよりも、stock型のblogやQiitaに投稿した方が良いということです。最大瞬間風速が重要となるflow型のサービス（e.g.,Twitter）は一時的にバズりやすく快感を伴います（？）が、後からその内容を検索することが困難です2。もちろん、まずはTwitterでラフに考えていることを記述しておいて、その後にhatenablogなどでしっかり記述するというやり方はアリだと思います（わたしはよくやります）。
技術書の読み方に関して様々なアドバイスを受けたのですが、その中でも「本というのは過去方向に依存関係を有するグラフ構造を成している」という話は刺さりました。当たり前ではあるのですが、一冊で完結する本などありませんし、その本は過去の何らかの本から強く影響を受けています。
— みるか🌷 (@mirucaaura) June 23, 2020
また、初心者には敷居が高いという件に関してですが、もちろん誤った情報を公開してしまうことはなるべき避けたいわけですが、初心者は初心者ならではの価値を提供できます。どういうことかと言うと、初心者は経験者が気付けないようなハマりポイントを取り上げることができます。経験年数が上がれば上がるほど、初心者がどんなことに躓くのかが分からなくなってしまうということは少なくないかと思います。なので、詳細かつ省略をせずに行ったことを記載することから始めていけば良いという意見でした。
最後に、勇気付けられる引用を。
情報発信、blog，発表、公開などは数学の未解決問題の証明ではなく、料理のようなもの
Jenkins 開発者である川口耕介さんの言葉だそうです。私たちが公開しようとしているものは、学術論文ではありません。新規性がなくてもいいのです。査読もありません。気楽にいきましょう。再現性は担保しましょう。
おわりに
（わたしのTwitterをフォローしていただいている方には分かるかと思いますが）学ぶべき事項が多すぎるあまり、気の焦りから様々なことに手を出して全てが中途半端になってしまっているような状況がここ最近ずっと続いていました。何から手を付けたらよいのか、何に焦点を当てればよいのか、何に集中すべきなのか、そういったことが脳内をグルグルし続け、精神が疲弊していました。このことを最後のQ&Aで質問したところ、次のような回答を得られました。
最初の数年のうちは、私はこれでいいと思っています。色んなことに手を出して中途半端になるということは、その内容が自分にとってそこまで気を引かれるものではないからかもしれません。だから、発散フェーズにいるうちは、色んなことに手を出して良いと思っています。今のうちにリッチなWebデザインや機械学習に手を出してみたり、Androidのアプリを作ってみたり、新しい言語に触ってみたり、色んなことに手を伸ばすことは若いうちはいいことだと思います。（対象を絞るのは、）気を引かれる技術があれば、今年はこれをやろうと決めて取り組んでもいいし、Thought WorksのTechnology Radarを見たりして、今は興味はないけど、これから流行るであろう言語をやるでもいいと思います。やっていくうちに段々と好きになり習熟度が上がることはよくあることだと思います。
色んなことに手を出して全てが中途半端になることは悪いことではないと思っています。手を出してみたことを例えばブログなどに記録していけばそれも大きな価値を伴います。途中までやったことを数年後に再開することもザラにあります。色んなものを摘み食いしていくうちに、面白いと感じるものや自分が手を動かしているうちに「なるほど、これは面白いな」と思えるような技術が幾つか出てくると思うので、それらを専門性として育てていけば十分だと思います。
また、色々と削減していかなければならないフェーズは、もっとベテランになってきたりライフステージが変わってきたりしたときで、そうなるまでに色んなものを食べておけば、様々な道具が自分の道具箱に入っていると思うのでより生き残りやすくなると思います。
このタイミングで@t_wadaさんの話を伺うことができて本当によかったです。
