私のプログラミング学習方法

最近プログラミングする仕事に転職した。今の私は Web アプリケーションを作っている？会社で働いており、主に JavaScript を書いている見習いプログラマだ。何かの役に立つかなと思ったので、学習方法について書く。

全部書いた後で「特に目新しいこと言ってないな…」と思ったが、せっかく書いたので文章として残しておくことにした。

1. 公式ドキュメントを読む

まずは学習したい対象のソフトウェアやライブラリ、その他技術的な仕組みの公式ドキュメントを読む。全部読むと時間がなくなってしまうので、まずは動かせるようになるくらいを目標にする。

公式ドキュメントは大抵の場合その技術を開発した人たち、つまり世界で最もその技術に詳しい人が書いているので、何回読んでも勉強になる。しかもインターネットさえあれば無料で、どこにいてもすぐに読める。

本を買って勉強するのもよいのだが、公式ドキュメントは無料ですぐ読めるし、多くの人が協力してメンテナンスしているので最新の情報が書かれていることが多いし、本などを買う前に公式を読んだ方が良いんじゃないかなと考えている。

2. 手を動かす

公式のチュートリアルがあれば2周以上する。チュートリアルが無い場合でもどのような場面でどう使うかはドキュメントに書かれているはずなので、それを**必ず**一度は自分の手元の環境で動かす。

文字を読むだけでは自分が理解していないこと自体を理解することはできない。しかし、実際に手元で少しずつ変更しながら動かすと、何を理解できていないかを理解することができる。

だいたい思った通りに全てが上手くことはないので、 Stack Overflow とかを読みながら何とかする。ここで失敗につぐ失敗で自己肯定感がガリガリと音を立てて削られていくが、物事の理解はたいてい何も分からないところから始まるので仕方がない。

敗北を知る

ところで私は将棋が好きなのだが、かの有名な加藤一二三九段が藤井聡太四段（当時）がプロ棋士デビューから29連勝した後はじめて公式戦で負けたときにこんなことをおっしゃっていた。

加藤先生は14歳でプロとなり18歳でA級昇進、20歳で名人挑戦（つまり日本で最も将棋が強い10人が集まるA級順位戦で1位を獲ったということ）、通算対局数歴代1位、通算勝利数歴代4位など素晴らしい実績をお持ちだが、通算敗戦数歴代1位という記録も持っている。

私は毎日のように敗北し続けているので、加藤先生の言葉を思い出して自分を勇気づけながらプログラムを書いている。やる気がなくなったら復活するまで詰将棋を解いている。

3. 公式ドキュメントを感じる

個人ブログや Qiita 等の公式以外の資料を読むときは、必ず公式ドキュメントとの対応関係を意識しながら読む。

本来その技術を使うために必要な情報の大部分は公式ドキュメントに書かれているはずなので、ブログ等はそれを補完する存在として考えるのが良いと思う。

4. 記録に残す

最後に、**必ず**学んだ内容や上手くいかなかったこと、思考の過程などを文章や画像で残す。

記録を残すことで忘れたときに戻ってこられるし、書いている途中に「こっちのパターンだとどうなるんだろう？」というような新たな発想が浮かび、知識を有機的に繋げることができる。また、他人に自分の理解を説明するときにも役に立つ。

記録には何でも自分が使いやすいものを使えば良い。私は主に Markdown が使える Wiki である Crowi に書いている。Crowi はとても記事が書きやすく Syntax highlight もあるので気に入っている。PlantUML Server を用意すれば UML 図も描ける。ちょっとしたアイデアは iPhone/Mac の標準メモアプリに書きとめておき、どこか別の場所（Crowi やブログなど）に文章を書いたら対応するメモを消している。

SaaS では最近だと Notion がアプリの出来がよい印象がある。あとは Inkdrop や Document Node や Typora のような Markdown エディタもよさそう。文書の整理が苦手な人や複数人で同時に作業する人には Scrapbox が合うかもしれない。GitHub Pages やはてなブログ、 Qiita や note 等で公開するのも面白そうだ。syntax highlight が無い場合はプログラムを Gist に書いて埋め込むとよい。絵が得意なら紙とかイラレとかに絵を描いて覚えるとかでも良いと思う。

とにかく好きな道具を好きなように使えばよくて、大事なのは自分がやったことを記録に残すことだ。

5. 現実の問題を解決する

プログラミングはコンピュータを用いて問題を解決するための手段の一つなので、私は問題を解決できなければならない。

本を読んだりチュートリアルをこなしたり公式ドキュメントやブログのコードをコピペするだけでは「その仕組みのどこがどう優れているのか」とか「実際にどのような場面で応用できるか」みたいな問いに正確に答えることは難しい。

そのため、現実に存在する問題を解決するソフトウェアを書き、そこに既存の技術がどのように役立っているのかを一つ一つ認識していくことで現実の問題をソフトウェアで解決するための引き出しを増やすのが重要だと考えている。

ここは私の不足していることなので、最近は仕事終わった後や休みの日に個人で Web アプリを作っている。完成したら Firebase とかを使って趣味の範囲で動かしたい。