はじめに
独学で本格的にプログラミングをやり始めて約1年半になる。
学んだことは、自分なりのルールでメモに残している。
もともと趣味が多く、いろいろな分野に手を出すタイプなので、しばらく時間がたった後でも思い出せるように、学んだことは自分なりのルールでメモに残している。
このメモを取る習慣をプログラミングにも当てはめて、何か実装するときには、日付や気づいたことや疑問などをメモに残すようにしている。
きっかけは、過去にやったこともう一度やる機会が来たとき、内容をあまり覚えておらず、また似たような検索をして同じルートをたどるのが面倒に感じたことだった。
メモに残しておけば、後で読み返したときに早く思い出せる。特に、その概念を理解できたときの文章や、自分なりのたとえで言い換えた説明を残しておくと、思い出すのが速いし、そこからさらに深掘りもできる。だから、メモを取るようにしている。
プログラミングにおいて、そのメモを、ざっくり「調べたこと(search)」と「試したこと(try)」の2種類に分けて管理しているのだが、最近ある偏りに気づいた。
searchのメモは増え続けるのに、tryのメモがほとんど増えない。
最初は「自分の腰が重いだけ」「実装が面倒だからサボっているだけ」だと思っていた。でも、よく考えると、それだけでは説明がつかなかった。この記事は、その偏りの正体を考えた記録である。
技術的なノウハウの記事ではなく、考察寄りの内容。
メモを search と try に分けている
学習メモを残すとき、自分は行動を表す動詞でファイルを分類している。その中に、大きく2つのカテゴリがある。
- search … 調べる。「〇〇の仕組みを調べる」
-
try … 試す。「〇〇を実装してみる」「〇〇を動かして検証する」
のようなタイトルにして、その中に内容や疑問、結果を記述するようにしている
この分け方の良いところは、自分の学習状態がそのまま可視化されることだ。searchが多ければインプット過多、tryが多ければ手を動かしている、と一目でわかる。いわば学習のダッシュボードになっている。そして時間がたった後でも、ファイル名を見てどういう内容/結果だったかをすぐに確認できる。
また、テーマを決めることにより調べている内容から脱線しすぎることがなくなったり、能動的に情報収集や懸賞をしている感じが個人的にすきだからだ。
そして、そのダッシュボードを見ると、はっきりと「searchに偏っている」と示していた。
tryよりもsearchフォルダーにファイルが圧倒的にファイル数が偏っていた。
最初の仮説：着手のハードルの問題
最初に考えた理由は、searchは着手が軽い。検索して、読んで、自分の言葉でまとめる。すぐ始められるから。
一方でtryは重い。実装は、細部を詰める作業が必要で、手を動かして、エラーを潰して、動くまで持っていかなければならない。そして場合によっては時間がとんでもなくかかるときもある
だから、軽いsearchばかりやって、重いtryを後回しにしている。
これは部分的には当たっている。
本当の理由：今やっているのが「答えのあること」だから
過去、趣味の範疇でプログラミングしていた時のこことを思い出した。
- あるゲームのボスを最速何ターンで倒せるか、シミュレーションを書いて検証した
- あるゲームのモンスター捕獲確率を、仮想的に計算して確かめた(ドラクエジョーカー)
これらに共通していたのは、ネットを調べても、整備された答えが載っていなかったし、検索してもヒットすることがほとんどなさそうなことだった。(検索が下手な可能性)
答えが存在しないから、自分で仮説を立てて、コードを書いて、動かして確かめるしかなかった。検証する以外に、答えにたどり着く方法がなかった。
実際のものとあっているかわからないがそれっぽいものを作ろうとすることで、それに必要な知識が副作用として得られた。
初めて、個体値や種族値などを含めて、ポケモンのステータスを出力するプログラムを書いてみて、エラーが出たとき
「こうしたらエラーがなくなるのではないか？」「ここの内容を書き換えたらどうなるか？」などをtryをして解決したことが何度もあった。
未知のことをやろうとすると、検証と結果が必要になり、おのずとtryが増えていく。
未知に向かうとき、searchとtryは必ずセットになる。調べても答えが出ないから、tryで確かめるしかない。tryは「構造的に必須」になる。
答えがあるから、searchすればたどり着ける。tryで検証する必要がない。 だからsearchばかりが増える。
tryが増えないのは、サボりではなく、今いる場所が「答えのある領域」だからだった。
AIが「もし」に答えてしまう
ここからが、自分がいちばん引っかかった部分だ。
少し前であれば、「もしこう書いたらどう動くか」を知るには、検索か自分で実装して動かすしかなかった。
検索してもひっからなければ、うまくいくか検証をする必要があった。
しかし今は違う。AIが、その「もし」に先回りして答えてしまう。
もし、だったらどうなるかをAIに聞くことで「このコードはこう動く」「この場合の挙動はこうなる」を、自分がtryする前に、AIが出力する。検証する前に、答えが返ってくる。
しかも、実際に動くことが多いし、動かなくても修正をＡＩがやってくれるし、何があったかもＡＩが教えてくれる(searchが増える)
だから、わざわざ手を動かして確かめる動機が消える。tryが発生しない。
整理すると、こういう構造になっていると思う。
検索とAIの発達は、かつて「未知だったもの」を「答えのあるもの」に変える。
その結果、人間が try（自分で確かめる経験）をする機会そのものが減っていく。
searchが増えてtryが増えないという、自分のメモの偏り。これは個人の怠惰の話ではなく、ツールの進化が学習の構造そのものを変えていることの、小さな現れなのかもしれない。
tryを取り戻すには「答えのないこと」をやるしかない
検索してもAIに聞いても答えが出てこないことをやる。
過去に夢中でtryしていたゲームのシミュレーションは、まさにそれだった。整備された答えが存在しなかったから、自分で確かめるしかなく、だからこそ面白かった。
逆に言えば、今tryが増えないのは、自分が「答えのある領域」にいるからだ。
地図を広げて横断的に知識を集めている段階であればそれでいいのかもしれない。
でも、本当に手を動かして確かめたくなるような問いは、地図の外にしかない。検索とAIが答えられない場所だ。
その場所に行くためには、膨大なsearchとインプットが必要だと考える。
この記事を書いていて思った
ここまで書いてきて思ったのだが、tryが増えづらいのは、もしかするとプログラミング関係に限った話かもしれない。例えば、スポーツや料理でAIに聞いたことをやっても、微妙な結果に終わることはよくある。
自分はテニスをやっているが、AIに「こうすればいい球が打てる」と言われた通りにやっても、実際にはうまくいかないことが多い。そして、何度も打ってみた結果として、ようやく「自分の場合はこうしたほうがいい」という答えが得られる。
つまりプログラミング以外の、身体や物理が絡む分野では、AIの答えがそのまま通用しないからこそ、自分で確かめる必要が出てくる。AIに聞くことが、むしろtryを増やすきっかけになるのかもしれない。
逆に言えば、プログラミングでtryが減りやすいのは、答えが情報やコードだけで完結してしまう領域だからだ。AIの出力が、そのまま正解になりうる。だから、自分で確かめる手間が省けてしまう。
同じ「AIに聞く」でも、分野によってtryへの作用が逆になる——というのは、自分にとって意外な発見だった。
おわりに
未熟な文章で最後までよんでくれてありがとう。普段何気なしにメモを取っていると、「単語の意味集めになっているよな」っていうところから始まり、能動的に学習をしようとしたところ「searchは増えるのにtryが増えない」という、ただのメモの偏りから始まった話だった。掘っていくと、それは「答えが先に手に入る限り、AIがtryを肩代わりしてしまう」という構造に行き着き、さらに「それはプログラミングのように、答えが情報で完結する分野に特有かもしれない」というところまで来た。
効率だけを考えれば、自分で確かめるより、AIに聞くほうが速い。それは間違いない。だから「なぜ効率を犠牲にしてまで自分でtryするのか」という話も当然あるが、それはそれで長くなるので、ここでは置いておく。
ひとつ言えるのは、searchが増えるのは悪いことではない、ということだ。調べ尽くした先にしか、自分で確かめるしかない問いは出てこない。tryが要るのは、そこから先だと思う。
自分のメモが、たまたまそれを可視化してくれた。記録する仕組みは、もしかすると知識を貯めるだけでなく、自分の学び方の構造まで映し出してくれるのかもしれない。同じように学習メモを取っている人がいたら、search と try に分けて、その比率を眺めてどちらに偏っているのか見てほしい。何か見えてくるかもしれない。