プログラミングスクールといえばグレーなビジネスモデルというようなイメージが蔓延ってしまって悲しいですが、プログラミングのスキルを多くの人が手にすることはとても有用なことではあるので今後も頑張っていきたいと思います。
プログラミングを習得しよう！と学習を始めた人たちをこれまで、数千人ほど観察してきました。その中で気づいたことは、プログラミング初学者は同様の場所で詰まってしまう傾向がみられるということです。多くの人にとって、同様のハードルというかステップがあるのだと思います。そういうことを書こうと思います。
ステップは0−4としました。しかし、Webや組み込み、ゲーム、データサイエンスなど、目指す世界によってその先にさらにたくさんのハードルがあると思います。ここでは、その後にどのような世界に進むかに限らず、プログラミング学習者に共通して現れるハードルに絞って記載しようと思います。
ステップ0：コンピューターに対するリテラシー
0-1. タイピングが間に合わない、誤字、タイプミスに心が折れる
0-2. 新たに登場する英単語の多さについていけない。学んだ次の日には用語を忘れてしまう。
0-3. コンピューターの一般用語に対する勘が働かない、例えばログイン/ログアウトとサインイン/サインアウトが同義語だと区別がつかない。サーバーという用語が1つのコンピューター端末を指すと認識できないなど
このハードルについて
ステップ0はプログラミングというよりもコンピューターに対する慣れ、リテラシーというようなステップです。そのため、ゲームやネットの世界を徘徊しているような人であればアドバンテージになる部分だと思います。
プログラミング用語に限らない「デバイス」や「メモリ」や「OS」などの用語がコンピューター初心者を苦しめます。これらのコンピューター用語に明るければ負担を少し減らせます。
プログラミングが必修化した今どきの子供にとってはゲームやネットも教養の一部になってるといえます。子供には恐れずにゲームやインターネットに触れさせると良いと私は考えています。
教養の差は後で効いてくるのでプログラミングを学び始めたら、プログラミングの学習だけではなく、より広いコンピューターリテラシーを持つように日々の積み重ねをスタートして欲しいです。育成者であればリテラシーを蓄積する課題を科してあげると生きた教育になると思います。
日経コンピューターなどの雑誌の過去ログを読んだり、タイピング練習を始めたり、パソコンを組み立てたり分解したりがおすすめです。就職するときやプロになってから本当に効いてくると思います。
ステップ1：エラーや失敗から学ぶスタンス
1-1. エラーが出るとパニックになる
1-2. エラー内容を読まない
1-3. 試行錯誤にトライしようとしない
このハードルについて
ステップ1は、初心者あるあるですが意外に深いテーマでもあります。エラーとの向き合い方は、極論すればコンピューターとの向き合い方だからです。
エラーは、コンピューターとの会話であり、融通の効かない世界に立ち向かう強い武器だと思います。エラーは、仲間であるコンピューター（というか言語設計者）からの優しさなのですが、初心者は「真っ赤になって怒られた！」と思ってしまいます。
「コンピューターは怒ってなどおらず。一緒に問題を解決したいと思っているんだ。」
そう教えるようにしています。
エラーメッセージを読み、原因について分析して仮説を立て、検証をして正解を導き出す姿勢こそが、プログラマにとって最も重要な姿勢です。そして、初学者をその姿勢に導けるかどうかが育成者としての手腕だと思ります。
コンピューターよりもさらに不確実な「現実世界」にはエラーメッセージのような親切な仕組みはありません。コンピューター、エラーメッセージと向き合って原因分析や仮説の検証、改善というプロセスを前向きに捉えられると、不確実で複雑な現実への向き合い方も変わってくると思います。
子供らにプログラミングを教える意義はここだとさえ思います。ビジネスの世界を含む、現実世界の様々な未知の課題解決においても役に立つ姿勢なのです。
ステップ2：制御とフローとデータのイメージ
2−1. ループのイメージがつかない。上から下に書いている文章が繰り返す意味が理解できない
2-2. 頭の中でデータの変遷が追えない。データのイメージが頭の中に作り出せない
2−3. 多次元配列やオブジェクトのイメージが頭の中に作り出せない
2-4. 多くのことをいっぺんに考えすぎていて手に負えないと思ってしまう
このハードルについて
ステップ2からは、プログラミングらしいハードルです。そのためプログラミング初心者は多かれ少なかれ経験するハードルです。ただ、その乗り越え方や乗り越える速さには個人差があります。いくつかの練習問題に取り組むだけで乗り越えられる人もいますが、他の人の何倍も理解に時間がかかる人もいます。
しかし、遅かれ早かれ諦めなければ必ずクリアできるハードルなのです。私はそう確信しています。頭の使い方の慣れの問題であって、いままで見てきた学習者の中で最終的にここがクリアできなかった人はいません。
ちなみに今では偉そうにプログラミングの先生を語る私も、ここで苦労しました。コンピューターリテラシーがなく、独学で取り組むしかなかった22歳の私は、8時間×3日間、1つの課題に悩み続けてようやくループとはどういうものかを体得したのです。
ステップ3：定義と実行のイメージ
3-1. 関数の定義と呼び出しについてイメージできない
3-2. 実行時の処理が移動することがイメージできない
3-3. 呼び出す側と呼び出される側が存在することがイメージできない
3−4. データを知っている、知らせる、戻すなどのイメージや、データの管理場所をイメージできない
このハードルについて
プログラミング学習を始めてからしばらくのうちは１つの関数定義で完結するプログラミング練習問題をクリアしていくことでしょう。
そこからステップアップしていく時に詰まってしまうハードルとして構造化や関数化があります。そして、その延長にはオブジェクトやクラス・型が難関として待ち構えます。
特に、異なるファイルに書かれた関数やオブジェクトを呼び出すことは、どのような言語でも学習者にとっては、慣れるのに時間を要するポイントです。ただ、ここも慣れの問題なので時間をかければ必ずクリアできます。諦めなければ。
ステップ3のハードルに際しては、できるだけたくさんのプログラミングの課題演習に触れるのが良いと感じます。しかし、市販の書籍やスクールのテキストでは、このパートをさらっと進めてしまうものがあります。
もっというと、このステップ3に限らず、スクールテキストなどで「慣れ」に目を向けないものは多いと感じます。１回説明したらわかるだろうというスタンスのテキストだ。関数やオブジェクトといった概念は、説明を聞いて理解するというよりも、体で慣れなくては使えるようになりません。説明は１回でもいいが、演習はたくさん欲しいと感じます。初心者の気持ちによりそうテキストかどうかは、こういったパートでの演習量をみてみると良いでしょう。
慣れに目を向けないテキストが生み出されるのは、エンジニアらしい部分でもあるといえます。プロのエンジニアにとっては、同じことを繰り返しドキュメントに記載するのは悪だとされています。できるだけ1箇所に事実を書いて、同じ概念が出てきたら何ページを参照というようにリンクづけすることが、プログラミング的な考え方では正解なのです。
ステップ4: アルゴリズムデザイン
4-1. 自分が発想した解決するべき課題に対して、処理の流れを組み立てることができない
4-2. 自分でデータの構造を作りだせない
4-3. 正しさの検証手順を考えられない
4-4. 大きな物事を大きなままで考えている
このハードルについて
答えのある演習課題を使ってプログラミングを学び始めるのが一般的です。しかし、ある時点で自分でオリジナルのアルゴリズムを組み立てることが必要となります。漠然とした課題に対する解決を自分で考案しなくてはならなくなると、アルゴリズムデザインの力が求められます。
アルゴリズムというと、なぜかネット上の情報や本では「ソート」や「サーチ」しか扱われません。そのため「アルゴリズムとはバブルソート、クイックソートのような高度で洗練された手順である」などと思い込んでいる人もいて、難しく捉えすぎているケースが多いです。
アルゴリズムデザインは、解決する手順を組み立てられる力です。不格好でも、非効率でも問題が解決される手順が示せることが大事で、最適化はあとでスキルが上がった時にやればいいと割り切るのが大事です。
アルゴリズムデザインで大事なことは、3つ。
・大きな物事を手に負えるサイズまで分解して考えること
・順序を組み立てて過不足なくつなげること
・小さくテストしていくこと
アルゴリズムのデザインを含めた「デザイン」つまりソフトウェアの設計こそ、プログラミングのクリエイティブな部分であり、面白いところです。
問題に対する解決策を提案して実装し、それがバチっとハマったときの快感や、より効率的なアルゴリズムによって、いままでの処理が劇的に効率化したときの快感がえられたら、あとはほっておいても学びたくて仕方なくなるものです。
冒頭にも記載したとおりに、この先にもたくさんのハードルがあるのですが、ステップ４までのハードルの意味が理解でき、乗り越えた実感がえられたら、あとは突き進むだけだと思います。
プログラミング学習が、育成者にとっても学習者にとっても幸せな時間になればいいですね。
