学習過程においては、解決策に飛びつかない

R言語の標準であるsubset()やaggregate()によるデータの前処理は、多少込み入ってくると非常に読みにくくなる。その解決策としてパイプ演算子 %>% を用いた magrittr が存在しているが、僕は学習者にいきなりパイプ演算子 %>% を紹介するのは最善策ではないという立場である。

学習において躓く原因となる要素はいくつかある。典型的なのは解決策がうまく使えない（部分積分に気づけない、%>%で言えば入力でベクターを渡しているのかスカラーをを渡しているのかを誤るなど）ことだが、見逃しがちな原因の一つとしてその解決策が解決しようとしている問題を深刻には実感できていないということがある。

その結果が「なぜアルゴリズムXを学ぶのか」「なぜこれを扱うのか」の集積である。なんだか良さそうだが、なんで使ったら良いのかはあまり分からない。ゆえに解決策を学んでいるときも、どこかピントがボケていて、何が欠かせない性質なのかが読めない。

この原因の発生過程には、教育それ自体は短時間で解決策を多く紹介しようとする（それこそが効率的な教育だから）のに、実際には多少紹介する数を緩めたほうがよいというパラドックスが絡んでいる。実際にはこの最適化問題は制約付きで、人間は実感したことのない問題の解決策はうまく覚えられないのだ。その場合、実は解決策の数を減らしてでも、問題の深刻さをしみじみと実感する時間を取った方がよい。多くは試行錯誤の時間であり、一見すると無駄のようにも見え、実際度を過ぎると無駄である。ここの調節は非常に難しい。確率的にしか成功しないと覚悟して臨んだほうがいい。

最初のうちはsubsetやaggregateで良いのだが、データの前処理過程が複線化して複数の処理済みデータを作成する段になってくると、それらの関数を正しく使えているのに読みにくいという事態が生じる。この事態こそがパイプ演算子が解決しようとしている問題であり、つまるところ用法と複線化は別々の課題なのだ。前者だけを解決するデフォルト関数から、後者も含めて解決する dplyr などのパッケージの関数へ、というのが恐らく論理的な流れとしても正しく、ここは飾りではなく本質である。

教える側としては、R言語の前処理と可視化を題材とするケースが多く、教えられる側としては、特別なデータ構造やアルゴリズムが多い。学習をその両面から検討するにあたって、この「いつ解決させるか？」というテーマは注目に値すると思う。