GUIDE / 学習の意思決定 / 更新 2026-11-02
プログラミング学習、タイピング速度より鍛えるべきは思考速度か
プログラミングを始めたばかりの人に「今、何を練習していますか」と聞くと、タイピング練習という答えがよく返ってくる。タイピングゲームで指の動きを滑らかにし、ショートカットを覚え、ホームポジションから目を離さずにコードを打てるようにする。悪いことではない。ただ、そこに時間を割くのは、本当にそれが上達の速度を決めているからなのか、それとも単に「測れる」からなのかは、一度分けて考える価値がある。
なぜタイピング速度だけが可視化されるのか
初学者が最初に手に入れる進捗の指標は、驚くほど限られている。設計力が伸びたかどうかは数値化できないし、バグをどれだけ早く見抜けるようになったかも、自分では測りづらい。一方でタイピング速度は、タイピングゲームのスコアという形で、毎日、数字で、しかも右肩上がりに可視化される。先週より速くなった、という事実は誰の目にも明らかで、練習すれば確実に積み上がる。
人は、進捗が見える場所に時間を注ぎたくなる。これは意志の弱さではなく、ごく自然な反応だ。問題は、「測れること」と「効くこと」が同じ軸に乗っているとは限らない点にある。タイピング速度が学習の中心に居座ってきたのは、それが最も伸びやすい指標だったからという理由が、思っている以上に大きい。
AI以前から、律速はそこではなかった
AIが登場する前の時代でも、実務経験のあるエンジニアに聞けば、タイピング速度がボトルネックだと答える人はほとんどいなかった。コードを書く時間の大半は、手を止めて考えている時間だったからだ。何を実装すべきか、どこから手をつけるべきか、この条件分岐は本当に必要か――そうした判断に比べれば、実際に打鍵している時間はいつも短かった。
それでも初学者にとってタイピングが重要に感じられたのは、覚えたことをコードという形に落とす最後の一手が、まだ本人にとって重く、遅かったからだ。構文を思い出すのに時間がかかり、入力ミスをその都度拾い直す段階では、打鍵の遅さが思考の遅さと見分けづらく混ざって見える。だから「速く打てるようになれば上達した気がする」という感覚自体は、間違いではなかった。ただそれは、最初の数か月だけに効く、賞味期限の短い指標だった。
AIが打鍵を引き受けたあとに残るもの
ここに、今の学習環境を考えるうえでの転回がある。AIの補完やチャット駆動のコード生成が当たり前になった今、実際にキーボードを叩く作業そのものは、学習者の手からどんどん離れていっている。構文を正確に思い出す必要も、タイプミスを一文字ずつ拾う必要も、以前より小さくなった。打鍵が担っていた仕事の比重が下がれば、打鍵を速くする練習の価値も、当然それに比例して下がる。
その結果、以前は打鍵の遅さに隠れて見えなかったものが、はっきりと前面に出てくる。何をAIに書かせるかを決める速さ――つまり、曖昧な「こうしたい」を、AIが実行できる具体的な指示や検証可能な小さな問題に分解する速さだ。これは指の運動神経とは何の関係もない、別の技能である。タイピング練習をどれだけ積んでも、この分解の速さは一切上がらない。両者は同じ「速さ」という言葉でくくられていても、鍛える筋肉がまるで違う。
分解の速さが見えにくいのには理由がある
厄介なのは、この問題分解の速さには、タイピングゲームのスコアのような分かりやすい数字が存在しないことだ。今日は先週より速く問題を分解できた、と教えてくれるアプリはない。進捗が可視化されない技能は、重要であっても後回しにされやすい。むしろ、可視化されないからこそ、多くの人がそこに時間を割かずに済ませてしまっている、という見方もできる。
手の速さを上げると、たしかに「前より強くなった」という実感が得られる。だがその実感と、実際にボトルネックになっているのが指ではなく頭だとしたら、両者はずれている。伸びているはずの技能が、実は一番伸ばしたかった技能ではなかった、という状態に陥る。
数字がまったく無いわけではない。代わりの手がかりになりそうなのは、むしろAIとの対話そのものの中にある。一つの指示を書いて、それがそのまま通った回数と、言い直し・条件の追記・分割し直しを重ねた回数の比率。最初の一文で「入力・出力・確認すべき条件」まで言い切れていれば、往復は少なく済む。曖昧なまま投げてしまえば、AIの出力を見てから初めて自分の要求の輪郭に気づき、何度も書き直す羽目になる。この言い直しの回数は、打鍵速度のように画面に表示される数字ではないが、自分の指示履歴を遡れば誰でも後から数えられる、分解の速さの代用指標になる。
では何を練習すればいいか
問題分解の速さを鍛える方法は、打鍵練習ほど単純ではないが、やることははっきりしている。AIに頼る前に、やりたいことを一文か二文で書き出してみる。曖昧な要望のまま手を動かさず、「入力は何で、出力は何で、途中で確認すべき条件は何か」を自分の言葉で言い切ってから着手する。大きな課題を渡されたとき、いきなり実装に入らず、検証可能な小さな単位にいくつ切り分けられるかを数えてみる。どれも地味で、スコアでは測れないが、実務で効いてくるのはこちら側だ。
タイピング練習をやめる必要はない。最初の数か月、構文に慣れる助けにはなる。ただ、学習時間の配分を決めるときに、「測りやすいから」という理由だけでそこに時間を積み続けていないか、一度立ち止まって確認する価値はある。本当に時間を投資すべき場所は、スコアが出ない方にある。
学ぶ内容そのものを選ぶ段階でも、同じ判断が効いてくる。tasklogは、実際に読まれ、引用されている技術書や学習記事を集めて見られる場所として置いている。次に何を学ぶか迷ったときの参考にしてみてほしい。