プログラミング学習における「コードの写経」は是か非か。質の良い振り返りのための経験学習モデル
「経験学習の理論的系譜と研究動向」より引用。
プログラミング学習における写経とは
プログラミング学習において、自分が慣れていない言語のサンプルコードをそのまま書き写すスタイルは写経と呼ばれています。
この写経について、有意義な学習方法だと考える人もいれば、学習効果はそれほど大きくないと考える人もいます。
自分でも興味を持ったプログラミング言語を学ぶ際は、いつも公式のチュートリアルを写経しています。
そもそも人が新しいことを学ぶプロセスとは、どのようなものなのでしょうか。
コルブ氏の「経験学習」における循環型モデル
物事は推測や個人的な経験からではなく、データや事実といったファクトから思考することが重要です。
これにより、前提を誤ったり間違った概念化をしたり、あるいは十分に議論されてきた概念を再発明することを避けることができます(このことは「ファクトフルネス」という本が詳しいです)。
そこで、人の学習についてGoogle Scholarを使って検索すると、アメリカの教育理論家であるデイビット・コルブ氏の経験学習という学習モデルを要約しているパンフレットがありました。
経験学習モデルでは、学習はサイクルであると仮定します。
曰く、具体的経験、内省的観察、抽象的概念化、能動的実験という4つのフェーズが循環しているという学習モデルです。
以下の経験学習の内容は経験学習の理論的系譜と研究動向というパンフレットから引用しています。
具体的な経験を省察して抽象化して教訓を得る
具体的経験
具体的経験は以下のように定義されています。
学習者が環境(他者・人工物等)に働きかけることで起こる相互作用
自分が環境を変化させるような行動をとってみる、ということですね。
仕事に当てはめると、まずはアウトプットを出してみた、というフェーズに当たります。
内省的観察
この具体的経験をしたのち、次は内省的観察のフェーズに移ります。
ある個人がいったん実践・事業・仕事現場を離れ,自らの行為・経験・出来事の意味を,俯瞰的な観点,多様な観点から振り返ること,意味づけること
内省的観察は、「内省」や「反省的思考」と呼ばれることもあります。つまり、経験を振り返ることです。
振り返りと言っても、その対象は「仕事の出来栄え」や「仕事の出来栄えを左右するプロセス」です。
その対象と程度としては「ある状況下の個人の行動・振る舞い」、「ある個人が存在している前提・状況、あるいはその個人に作動している権力や社会関係」など様々です。
プログラマに当てはめると、前者は自分の書いたコードの良し悪しという成果物や、バグが多いシステムに対してバグの混入率を減らすためにテストコードを書いていこうというプロセスの話ですね。
後者は、そもそもバグを含む可能性があるコードをデプロイせざるを得なかったのはリリース日が決まっていたのでとても焦っていたからであるという状況が想像できます。
あるいは、そもそもエンジニアが工数を見積もる際にビジネス側から「これくらいの機能ならもっと早くリリースできるでしょ」と言われ、社内ではエンジニアがNoと言えない力関係であるというようなケースです。
抽象的概念化
次のフェーズは抽象的概念化です。この定義は以下のようなものです。
経験を一般化,概念化,抽象化し,他の状況でも応用可能な知識・ルール・スキーマやルーチンを自らつくりあげること
振り返りの内容を抽象化することにより、他の場面でも応用可能なルールを作り上げることです。
前出の例を続けると、そもそも同じエンジニアでも正社員やフリーランスという切り口から考えることが挙げられます。
また、出社が必須の時とフルリモートで働く時の社内コミュニケーションの取り方の違いなど、大きな切り口から自分の経験を捉え直します。それにより、深い考察ができるようになります。
能動的実験
最後に能動的実験のフェーズがあります。
これは、前段階で構築した理論を実践することです。
この実践が経験になり、その経験を振り返る。そして、また自分なりの新しい理論を構築する、あるいは既存の理論を修正することが経験学習における学習モデルです。
プログラマにおける経験学習の例
プログラマの例を続けると、以下のようなケースを想定できます。
具体的経験:コードをデプロイしたが、バグが混入していたので切り戻しをした
内省的観察:そもそもデプロイ前にバグを検知することはできなかっただろうか
抽象的概念化:アプリケーションにおけるバグには、実行時エラーというものがある
能動的実験:デプロイ前に必ずテストコードを書いて、アプリケーションを実行するようにする
抽象的概念化が4つのフェーズで最も重要
自分は経験学習の4つのフェーズのうち、3つ目の抽象的概念化が最も重要だと考えています。
上記の例では実行時エラーを予め回避するためにテストコードを書くという結論を出しています。
しかし、他にも考え得る選択肢は存在します。
例えば、その実行時エラーの内容があるクラスの存在しないメソッドを呼び出していたというものであるとします。
この場合、抽象的概念化のフェーズにおいて、運よく静的解析という概念があることを知ることができたとします。
すると次回はコミット時に静的解析ツールを走らせるようにするとか、IDEを使うであるとか、そもそも静的型付け言語やコンパイラを使う言語を使って開発するというアクションを選ぶことができます。
プログラマにとって写経は是か非か
自分は写経をすること自体はニュートラルだと思っています。
しかし写経という経験をした後、振り返りや抽象的概念化、または次のアクションを怠っていると写経の学習効果は薄いのでしょう。
新しい言語や構文を写経する中で、文法や背景にある概念やプログラミング言語の歴史的変遷を調査することで、学習効果は大いに高まります。
抽象化の果てには、知的に刺激的な問題にまでたどり着き、実験的な行動に移ることができることでしょう。
動的型付け言語は実行時エラーがある
→ 静的型付け言語を写経して学ぶ
→ コンピュータに型を教えてあげなければならない
→ 現実世界ではモノに型なんてないのに、コンピュータに扱えるデータの型は限定されている
→ 現実世界のモノ(オブジェクト)をコンピュータで再現するために、どのようなモデルを作ればいいのだろうか
→ アラン・ケイによるオブジェクト指向の定義を調べる
→ オブジェクト指向言語の見方、書き方が変わる
終わりに
今回はコルブ氏の経験学習という学習モデルの切り口からプログラミングにおける写経の意義を考えました。
写経以外にも、仕事で振り返りを行ったり、日報を書く機会があれば、具体的経験、内省的観察、抽象的概念化、能動的実験という4つのフェーズを意識してみてくださいね。
Happy Coding 🎉