例えば「写経」という言葉を避けてみる。
サイボウズ式「続・エンジニアの学び方」の第5回が公開されました。この回では、小崎さんが「どうしてコードを読もうと思ったのか」と、コードを読むために新しい言語を学ばなければいけない場合に「どうやって学ぶか」を聞きました。
ところで、小崎さんは自分の学び方を「写経」と読んでいて、僕もこの用語は自然に理解できるのですが、公開後のTwitterの反応を見ていると「写経と呼ぶことが嫌」もしくは「仏教での写経の印象で、内容を勘違いしている」という事例がいくつも見つかりました。
プログラミングの学習法としての「写経」という言葉は色々な書籍で使用されています。例えば「100人のプロが選んだソフトウェア開発の名著 君のために選んだ1冊」の70ページでは「まず写経することから始めた」というエピソードが紹介されています。また「改訂新版 コンピュータの名著・古典100冊」の99ページでは「技術書の内容にそって深い理解を得ることができる」とおすすめされています。
ですが、まあそれでも誤解する人が何人もいるということは、いわば「関数名が関数の処理の内容にあってない」的状態なわけです。こういう状況で「関数名を変えるべき」派と「だったら対案を出せよ or もう広く使われてるから無理だよ」派との争いが起きるのはよくある自転車置場の議論ですね。
この連載の目的は、いろいろな人の学び方を知ることで、読者や僕が自分の学び方を改善するきっかけを作ることです。「小崎さんが『写経』と読んでいる勉強法」をどう呼ぶのが正しいかという議論は、学び方の改善に全く寄与しません。そこで議論を避けるために、ここでは「小崎さんが『写経』と読んでいる勉強法」を略して「コサキメソッド」と呼ぶことにしましょう。
コサキメソッドの特徴
- コードの粒度は細かい
- 考えながら書く
- 「体を動かすことで、脳が活性化される」と小崎さんは思っている
- 絶対書き換える (出典)
- 実行して、結果がどうなったかを確認する
最後の「実行して、結果がどうなったかを確認する」は僕が口に出してしまったのですが、本当は僕は「その『写経』という言葉で指している行動は具体的にはどういうものですか？」って聞くべきでした。うっかりしてました。このインタビューは僕の人生初インタビューなんで勘弁して下さい。
t_wadaメソッド
今回、写経の話題で盛り上がったことで2010年に @t_wada さんが書いたTweetが発掘されました。この内容も面白いので転載しておきます。 https://twitter.com/t_wada/status/9000231741
技術書の「写経」の方法。
1.ローカルで使える SCM を用意
2.「ほんたった」などで対象の本を固定
3.ひたすらサンプルコードを写して実行
4.実行するたびにコミット(コミットログにページ番号を含める)
5.疑問点があったらコミットログや本に書き込む
6.章ごとにタグを打つ
書いている時に思いついた疑問点などを書き込むという話から、明らかに「考えならが書く」を実践していることがうかがえます。サンプルコードはたぶん粒度が小さいでしょうね。また「実行する」というのは「実行し、結果を確認する」と同じでしょう。
コサキメソッドとの共通点
- コードを写した後、実行し、結果を確認する
- 考えながら書く
- コードの粒度は小さい（たぶん）
バージョン管理する点は独特ですね。興味深いです。
shokaiメソッド
橋本商会 » プログラムの写経で紹介されている方法も面白いです。
- 外から書け
- 処理される順番に書け
- エラーでググれ
- うまい人の作業を見る
エラーが出ていることから、もちろん写した後実行しています。
「外から書け」「処理される順番に書け」は独特な視点で興味深いです。その目的は「1行書く毎に実行できるので、文法の間違いもすぐ気付ける。」「プログラミングの初心者は、とにかく全部完成してから実行して、エラーが10個ぐらいでて助けを求めてくるんだけどこまめに実行した方が良いし、こまめに実行できるような順番でコード書いたほうが良い。」から察するに、コードの粒度を小さくすることです。サンプルコードとして掲載されているコードですら、本当の初心者にとっては粒度が大きすぎる、だから書く順番を変えることで粒度を細かくするということでしょう。
コサキメソッドとの共通点
- コードの粒度は小さい
- コードを写した後、実行し、結果を確認する
エラーが出た後の対処法（ググれ）や、うまい人の作業を見ることによる学びに言及している点は独特ですが、僕には納得感があります。
nishioメソッド
我田引水ですが僕も昔、写経について書いたことがあるので紹介します。プログラミング学習手段としての写経について
写経は自分の中にモデルを作るための行動で、他のもっと効率のよい方法と比べた場合の利点は「自分の中にモデルがなくても使える」点に尽きる。全く知識ゼロでいきなり「自分で考えて書く」ができる人はいない。考えるための材料となる知識をまず脳内に運び込む、それが写経だ。
- 早く学びが得られるように、なるべく小さいコードで実験し、すぐに結果を確認する。
- 疑問に思ったこと、考えたこと、気づいたことを書き留める。どうしてこういう書き方をするのだろう？もしかしてXをYに書き換えたらエラーになるのだろうか？そうか、さっき疑問に思ったあれは、今写しているところとペアになるようになっているのか、などなど。この思考が、次の学びのための足がかりになる。
- 一字一句同じに写すのではなく、自分が必要ないと思ったら省略すること。必然的に何が重要で何がそうでないかを考えることになる。
コサキメソッドとの共通点
- コードの粒度は小さい
- コードを写した後（実行し）結果を確認する
- 考えながら書く
t_wadaメソッドとは「考えたことを記録」が共通ですね。
まとめ
4人のプログラマが「写経」だと考えている学び方について整理してみました。4人で共通するポイントを抜き出してみましょう。
4人で共通
- コードの粒度は小さい
- コードを写した後、実行し、結果を確認する
3人で共通
- 考えながら書く
2人で共通
- 考えたことを記録する
shokaiメソッドだけ「考えながら書く」がないですが、たしかにまったくの初心者だと「考えながら書け」と言われても何を考えたらいいかわかんないですよね。でも「無心で書け」という意味ではない。「やってる最中に思ったことは書き留めよう」ぐらいに柔らかくするといいのかな。
というわけでこの結果を参考にまとめると以下のようになりました。
- コードの粒度はなるべく小さくする。（可能なら1行とかで。上から順に書かなくてもいい。）
- 実行し、結果を確認する。（全部移し終わらなくてもいい。なるべく早い段階で。）
- やってる最中に思ったことは書き留めよう。
さあ、これに名前をつけるとしたら、なんてつける？
