技術記事を書いたほうがいいの? 書かなくても技術は身につくの?

きのこたけのこ戦争と同じく、技術記事を書いたほうが良いvs書かなくてもいい論争は議論が平行線になることが多い。

一方は「技術記事を書くと理解が深まる感覚があるから書いたほうがいいんじゃないか」と主張し、一方は「技術記事を書かなくてもつよつよなエンジニアは沢山いるから書かなくてもいい」と主張する。¹

どちらもひろゆき氏に言わせれば「それってあなたの感想ですよね?」と棄却されてしまうこと請け合いなので、技術記事を書く学習効果について実験研究の結果をもとに科学してみたいというのがこの記事のテーマだ。

また、調査の結果や私の個人的なこれまでのアウトプット方法を踏まえて、どのように技術記事を書けば学習効果が高いのか、あるいはどんな技術記事は学習効果が低いのかについて考えてみたい。

本稿では技術記事の学習効果のみに焦点を当てるため、その他の効果(プレゼンテーション能力up、個人・企業の認知度up、学習のモチベーションup、同僚や知人、日本のエンジニアへの知識共有)については捨象する。

技術記事を書くメリット1：記憶定着

まずは、「技術記事を書くことで記憶が定着し、技術記事を書かないよりも書いたほうが技術が身につく」という言説について考えてみよう。本当に記憶定着率はいいんだろうか?あるいは、どれくらい定着するんだろうか?

学習に関する研究分野で記憶定着に効果があると着目されているのは「想起」というプロセスだ。これは文字通り「思い出す」という行動のことで、人間は「想起」することで対象物をより記憶することができるという。

そして、「想起」を引き起こす最も簡単な方法が「覚えているかテストする」というものだ。ちなみに、記憶をテストすることによって「想起」を引き起こし、記憶定着率が向上する効果をテスト効果と呼ぶ。

ここで、米ワシントン大学が行ったテスト効果に関する実験研究を紹介しよう²。この実験では、中学生の社会と理科の授業において以下のような方法を取った。

1)半分の事柄については授業を聞いただけ
2)もう半分の事柄については授業中に選択式のクイズを出す

すると、章末テストや期末試験、学年末試験においてクイズをやった事柄とそうでない事柄で顕著な差がでた。

例えば期末試験では、クイズをした方がただ習っただけの方よりも10〜13%正答率が上がっている。違いは授業中にクイズを取り入れたかどうかで、生徒のその後の学習についてはノータッチなので、「想起」あるいはテスト効果が記憶定着にかなり有効な方法であることが伺える。

これを技術記事に当てはめてみると、「ただ本を読むだけ、教わっただけよりも、記事を書く中で想起を行うことで記憶定着率が向上する」と言えるかもしれない。しかしながら、テスト効果を利用して記憶定着率を上げるなら、別に記事を書かなくても方法はいくらでもある。

プログラミングの入門書にはテスト問題がついているものがかなりある。学習した後にテスト問題に取り組めば文字通りテスト効果が得られるので、簡単にテストできるようなものは記事を書くよりも練習問題を解く数と頻度(頻度と記憶定着率の関係については割愛する)を高めればいい。

他にも、本を読みながら大事だと感じたことを(本を閉じてから)自分の言葉で書いたり、概念の関連付けをしてみたり、簡単なコードなら実際に書いてみたり、学習にテストを取り入れる方法は様々ある。テスト効果については、技術記事の専売特許ではなさそうだ。

技術記事を書くメリット2：理解度

記憶定着率が覚えているかどうかというシンプルな尺度だったのに対し、今度は技術記事を書くことがどれほど理解度に影響するかを考えてみよう。

ここでは、パデュー大学の研究論文を紹介する³。この論文では、科学の勉強を行う大学の学部生を4つのグループに分けて検証を行った

1回のセッションでテキストを読むだけ
複数回のセッションでテキストを読み返す
1回読んだ後にコンセプトマッピングを行う
1回読んだ後に思い出せる限りのことをフリーフォーマットで思い出してもらう(想起練習と言う)

それから試験を行った結果が以下のグラフ。

A(テキストにそのまま書かれてあった逐語的な問題)においても、B(推論が必要な問題)においても、想起練習を行った学生グループが圧倒的に高い成績を修めている。単純にテキストを読んだだけの学生グループと比較すると、両者2倍以上も成績に差が出ているのは驚きだろう。

ここで、「あれ?中学生の実験の方は10%くらいしか変わらなかったのに、なんでこっちはこんなに差が出たんだ?」と思われるかもしれない。

ここからは私の想像だが、このテストの想起練習を用いた学習では、単にテスト効果が得られるだけでなく、自己説明効果も同時に得られているのではないかと考えている。

わからないことを人に相談しにいったのに、話しているうちに自己解決してしまった…みたいな経験はないだろうか?
これがまさに自己説明効果だ。

まず、中学生に対する実験とこの実験の大きな違いは、テストが選択式だったのかフリーフォーマットだったのか。フリーフォーマットで自分の理解をテストするとき、学習した内容を一度自分の言葉で置き換える必要がある。このプロセスを自己説明と呼ぶのだが、自己説明を行うことによって飛躍的に理解が深まる。これを(狭義の)自己説明効果と呼ぶ。

自己説明効果はエンジニア界隈でも「ラバーダック・デバッギング」という手法で古くから親しまれている。これは、デバッグを行う際にプログラマがアヒルの人形(ラバーダック)に書いたコードを1行1行説明することによってデバッグを行う手法のことだ。(ちなみにこの言葉が現れたのは1999年初版の書籍『The Pragmatic Programmer』だそう。)

これを技術記事に置き換えてみると、インプットした技術を自分の言葉で説明することで、パデュー大学の実験と同じく飛躍的に理解が高まると考えられる。

私事で恐縮だが、以前dockerを使った仮想環境構築について記事を書いたときは自分でもかなりdockerについて理解が深まったと体感したことがある。dockerで仮想環境が機能するように作り上げた段階ではまだ細かい部分の理解が不十分だったが、(自分に説明するつもりで)解説を書いたところ一気に理解が進んだように思う。この経験から、自分の理解が不十分な領域を記事にすることは高い学習効果を得られる可能性が高いのではないかと思う。特に、この特性は複雑であったり難解であったりする技術で効果が高い。

もちろん個人の力量に依存するが、dockerなどの環境構築、RDBMSでテーブルロックや行ロックが発生するメカニズム、AWSのアーキテクチャ設計など、入門書をさらっと読んだだけでは理解できない領域を自分なりに考えて記事にすることはかなり有効な学習につながる。

しかしながら、逆を言えば自分がほぼ100%理解できている領域をそのまま記事にしても学習効果はほとんど得られない。

技術記事を書いた人なら一度は経験があると思うが、記事を書いていて「なんかつまんないな〜…」「わくわくしないな〜」と感じたことはないだろうか?

特に、「理解してない技術は使わない」というプロ基準が備わっている人だったり、記事を書く前に自分でがちゃがちゃいじくり回したりしている人だとこうなりやすい。というのも、その人の中で明文化せずともすでに自己説明は完了しているからだ。(余談だが、一部の天才は言語化プロセスを経ない理解をしている場合がある。ノリで東大理三に行くような人がそうかもしれない。)

つまり、理解度を向上させるために記事を書くのであれば、自分がまだそこまで理解できていない領域に関するものを書くのが最も効果的だと考えられる。しかしながら、「自分があまり理解できてない」とモニタリングができているという時点で、それはすでに自己説明を無意識に行っている証左でもあるので、狙って記事を書くのは意外に難しい。

記事 vs 実際に作る経験

「技術記事を書かなくてもつよつよなエンジニア」は実際山程いる。おそらく彼らは、経験学習による効果を最大化しているのだと思われる。かつてレオナルド・ダ・ヴィンチが「知恵は経験の娘である」と言ったように経験による学習効果は計り知れない。

「記事を書く暇があれば経験した方がいい」というのも至極妥当な見解のように思われる。

学ぶ→理解する→使う→理解していないところがわかる→理解して使う

このサイクルを通してでも、テスト効果や自己説明効果は十分に得られるだろう。

最近では「経験学習」というアクティブ・ラーニングが一般的になってきたのもあって、オンライン学習サイト(Udemy, progate, etc)などでハンズオン形式の学習方法が流行している。では、この「経験学習」とはどのようなものなのか、ここで一度確認しておきたい。

コルブの経験学習モデル

これは1970年代に提唱されたモデルで、21世紀の現在も未だに経験学習において支配的なポジションにあるモデルだ。このモデルにおいて、経験学習は4つのプロセスで構成される。

1)具体的経験
2)内省的観察
3)抽象的概念化
4)能動的実験

ここでの詳しい説明は割愛するが、これはPDCAサイクルにかなり近しい概念だと思って貰えればいい。Planは無いが、Do→Check→Actionのようなプロセスを経ることで学習効果を(別次元にまで)高めることができる。

ここで今一度振り返ってみてほしいのだが、あなたの経験による学習は、このプロセスのどの段階まで実行できているだろうか?

私も恥ずかしながら、2〜4を経験だけできちんとできているとは言えない…。

つまり、ただ具体的経験を得るだけでは学習は不十分で、2)内省的観察、3)抽象的概念化プロセスを実行する手段として技術記事を書くことが、技術記事の学習効果を高める最も効果的な方法なのではないだろうか?

以下では、それぞれ具体的にどんなことを意識しながら書けば良いのか提案として書いてみる。これは私自身まだ実際にやったわけではないので、あくまで案として捉えていただきたい。

高次元の理解を養うために技術記事を書く

内省的観察を行う

内省的観察とは、自分が経験した出来事を多角的・俯瞰的に振り返ることを言う。

例えば、あるエラーで数時間スタックした経験をしたとする。具体的経験による学習のみだと、おそらく「エラーの原因はしょうもないタイポだった」「APIのバージョンがサポートされなくなっていた」など、具体的な原因とその対応を学ぶのみになるだろう。

これを俯瞰的に考えてみると、、、

なぜタイポを見逃したのか→ブラインドタッチできていないことが問題かもしれない
なぜAPIバージョンが古いと気づくのに時間がかかったのか→エラー文の意味をちゃんとわかっていなかったのが問題かもしれない

という問いを立て、解決策を考えたり調べたりすることにつながる。

抽象的概念化を行う

これはつまり、帰納的にあるものを一般化するということだ。

上記の例で言えば、稚拙ではあるが

最もよくあるエラーの原因はタイポ
エラーが起きた際はまずその内容を正確に把握する

といったものになるかもしれない。つまり、次に似たようなパターンに遭遇した際に適用できる原理原則(あるいはヒューリスティック)を身につける工程と言える。

メタ認知/推論

内省的観察も抽象的概念化も、メタ認知や推論を伴う。そして、メタ認知や推論を行うアクションとしてこれらを捉え直すのであれば、

出来事や物事の構造的理解

も具体的体験だけでは得られないものだろう。例えば、javascriptにおいてletやconstを使って変数を宣言できることは少し勉強したことがある人なら誰でもわかるが、1)let, const, varと2)再代入、再宣言の可否をマトリクスで理解している人はそこまで多くはないだろう。他にも、以下に挙げるような記事は過去の経験から、

1)発生した事象をまとめ
2)デメリットについて考察し
3)様々なコンテキストにおいて多角的に考察し
4)解決策を考案している

https://qiita.com/tatsumi_t2/items/dfd29454cae0463eb5c2

非常に素晴らしい出来の記事だが、筆者の方に取って大いに学びになったのではないかと思われる。