結論
複数の設計工程（PSやSSなど）とコーディング（PG）をごちゃ混ぜに勉強しているせいでプログラミングが理解できないんじゃね？
はじめに
この記事は、新卒で採用された会社の研修にて、プログラミングができない人と半年近く一緒に過ごした筆者が、現在のプログラミング教育の問題点を考察したものである。
googleで「プログラミング初心者 挫折」と調べると、大多数のホームページにて「質問できる機会がない！」だとか「エラーが解決できない！」などの定型文が転がっており、そうじゃねぇだろと思いこの記事を書こうと思った次第である。
この記事は大きく分けて2つに分かれる。1つ目は、プログラミング初心者に立ちはだかる大きな壁。2つ目に、私が考えたプログラミング教育だ。
あくまでも少ししかプログラミングに触れていないただの初心者がほざいているだけだが、もし一つでも共感できるところがあったらとても嬉しく思う。
自己紹介
ただの人。6年間独学でプログラミングに触れてきた。今年、人生で初めて会社で基礎的なプログラミング教育を受けた。それだけ。
立ちはだかる大きな壁
では早速本題に入っていこう。まず、プログラミングを学ぶ上で、初心者に立ちはだかる大きな壁として大きく3段階に分かれていると考えた。
第一段階
初めてプログラミング言語に触れる
プログラミング初心者はそもそもプログラムを見たことがない。普通の人が傍から見るとただの暗号であり、到底理解し難い英文が大量に書いてある。そもそもそのような状態でプログラムに触る事は無理だろう。
なんとか頑張って"Hello world"の表示やfor文、if文などを書けるようになっても、それはあくまでも「道具」を渡されたのみであり、実際の使い方は自分で理解する他ない。限られた時間の中で理解することはとても困難だ。何かしらプログラミングの問題を渡されても、その与えられた問題の解決には繋がらずただテストの問題を解くことと同じだろう。
第二段階
オブジェクト指向を学ぶ
さて、プログラミング言語に触れ多少なりともコードが書けるようになってきた頃に、更に大きな壁が立ちはだかる。そう、泣く子も黙るオブジェクト指向という考え方だ。現在開発現場で主流となっているプログラミング言語は、大抵オブジェクト指向が取り入れられている。誰がどう考えたって難しい考え方を初心者のうちに学ばせるのは非常に酷だろう。可哀想に。
第三段階
ライブラリを使い始める
オブジェクト指向を完全に理解したプログラミング初心者は、ライブラリを使いたくなるお年頃だろう。ただし、このライブラリというものが曲者で
- 今までと書き方が異なる
- これまでの親切な日本語のリファレンスが、とても不親切な英語のリファレンスに変わる（場合もある）
という強烈なダブルパンチを食らってしまい、自信の喪失につながる。あと初心者は「何故か」オブジェクト指向を完全に理解すると、ライブラリの中身も理解しようとして失敗するケースが見られる。（ほんとにオブジェクト指向を理解してんのかよ）
なぜ壁ができるのか
ここからが考察ポイントだ。何故このような壁ができてしまうのだろうか。
壁ができる原因
壁ができてしまう原因として現在主流となっているプログラミング教育の仕組みだと感じた。
初心者はまず、プログラミング言語を選びそのプログラミング言語について学びを深める。その後に他のプログラミング言語に移るというのがセオリーだろう。そもそものその過程が間違っているのではないだろうか。
実際の開発現場で考えてみよう。開発現場では、１人で行う事は稀であり大抵は複数人でプロジェクトを進めるところが大半だろう。また、「開発モデル」というどのようにシステムの開発を進めていくかということを決定する必要がある。
もし、プログラミング初心者がこの記事を読んでいたとして、「開発モデルってなんだよ」って思ったならば、今後壁にブチ当たる可能性が高い。
そう、自分が問題だと思っている点はここなのだ。そもそも開発の流れを事前に知っておかないと、挫折する可能性が非常に高い、つまり壁にブチ当たるのだ。
では、何故壁にブチ当たるのだろうか。それは先に結論で書いた通り、複数の設計工程をごちゃ混ぜに勉強しているから壁にブチ当たると考えた。今までのこの壁というのは「クラス定義、メソッド定義などのデザイン的な設計とコーディングを同時に行っている」からこそ生まれるものであり、それらを別々に勉強をすれば壁がなくなるのではないのだろうか。
そもそも設計とコーディングを同時に行っているとはどういうことなのかを実際に例を上げて説明しよう。
恐らくプログラミングを学ぶ上でこういった問題を一度は見たことはあるのではなかろうか。
年齢を入力させ、その年齢に応じた動物園の入場料を判定し出力するプログラムを作成せよ。
入場料は、0歳以上12歳以下は子供料金の200円、13歳以上は通常料金の500円とする。
また、0未満もしくは150以上の数値が入力されたら不正な値とし、再度数値の入力を促す。
この問題の回答を作成する際、経験者は恐らくそのままコーディングできるだろう。しかし、初心者にとっては難しいと感じる。これは先程言った通り、設計とコーディングを同時に行っているためである。
まず、経験者の思考回路を言語化してみる。
- 頭の中でどのような関数（メソッド）が必要になるか検討する
- 入力、演算、出力などにブロック分けを行う
- それぞれの関数（メソッド）の内部を記述していく
- 必要となったらその都度変数を宣言する
恐らくこういったプロセスでプログラムを組んでいくのではないだろうか。少なくとも自分はこういった考え方をしている（と思う...）
さて、ここで設計工程が含まれている事に気づかないだろうか。例えば1番, 2番は設計工程に入るだろう。
ここでの設計工程は、メソッドの内部を定義する詳細設計となる。
この詳細設計というのが厄介で、これについて触れている教材というのがあまりにも初歩的すぎてgoogleで検索してもあまりないのだ。検索をしたら、設計書の書き方などがヒットしてしまうだろう。また、コーディングに比べかなり難易度が高くなってしまう。そのため設計工程については初心者のうちはまだ触れさせるべきではないと考える。
ぼくのかんがえたさいきょうのプログラミング学習法
設計工程に触れさせるなと言ってもどのように学習を進めていけばよいのだろうか。まず大きく分けて2ステップに分かれる。
STEP1 設計モデルに触れる
そもそも言語を学ぶ前に設計モデルに触れる必要性があるだろう。設計モデルに触れることで、システムがどのように出来上がるか、体系的に学ぶことができる。まずは基本的な流れから学ぶべきだろう。
初心者にとって、プログラミングと言うとコーディングをイメージしやすいが、どちらかというと前段階の設計工程が重要となってくる。そのため、言語を学ぶ前に設計モデルに触れる必要があるだろう。
STEP2 コーディングをただの翻訳と捉える
そもそもコーディングとは、考えながら行うものではなく与えられた仕様（日本語）をコード（プログラミング言語）に変換する作業だ。つまり、コーディングとはただの翻訳に過ぎないのだ。そのため、1行1行を日本語で書いた課題を与え、その課題を基に翻訳作業に慣れさせるというものを行わせたほうが良いのではないだろうか。
例えば、先程の上記の問題で説明してみよう。
年齢を入力させ、その年齢に応じた動物園の入場料を判定し出力するプログラムを作成せよ。
入場料は、0歳以上12歳以下は子供料金の200円、13歳以上は通常料金の500円とする。
また、0未満もしくは150以上の数値が入力されたら不正な値とし、再度数値の入力を促す。
この問題に関して、仕様を1行づつ考えてみよう。
- メイン関数（メソッド）を定義
- コンソールから文字列を取得
- 取得した文字列を数値型に変換
- 数値が適正な値か判断
- 適正な値でなかった場合 2. に戻る
- 数値が12以下ならば200円と出力する
- それ以外ならば500円と出力する
恐らくこのように手取り足取り記述したものを繰り返しコーディングすれば間違いなく翻訳はできるようになるだろう。
そして、慣れたところでこの仕様を考えさせるのだ。このように仕様を記述すればコードに書き起こせるということが理解できるようになっているはずだ。
このようにして、設計工程とコーディングを分け、初学者に分かりやすくすべきだろう。
まとめ
最後に言いたいこととして、ここ最近の傾向として「プログラミングは簡単に出来る！」や「未経験者でも年収1000万円！！」など、まるで誰でも簡単にプログラミングが出来るかのように紹介をしているサイトなどがあるが、
そんな訳あるか！！！ プログラミングは普通に難しいわ！！！！
はい。
とりあえずの結論としては、設計工程とコーディングをごちゃ混ぜに勉強しているせいでプログラミング学習が進まないということを総括としてまとめさせていただきたい。
お詫び
まず、このような駄文を生成してしまったことをお詫び申し上げたい。こんな分かりづらい文章をよく最後まで読んでくださった方には感謝してもしきれない。
また、あくまでまだ経験の浅いぺーぺーがつらつらと書き連ねたのみであり、実際は違うわ！！ということもあるかもしれない。ただ、独学でプログラミングを学びある程度のコードが書けるようになった人から見た形式的なプログラミング教育の問題提起ということで、ご容赦願いたい。
追記
2023/11/22
①文章の校正
「設計工程」、「設計」という言葉が入り乱れており、非常に分かりづらい文章となってしまっていました。全て修正したつもりではありますが、まだ分かりづらい文章があるかもしれません。申し訳ありません。