穴埋め問題を解く人生は、穴を他人から与えられない限り、人生の穴を埋めることはできません。

いい大学に入るとか、
いい会社に入るとか、
この仕様書のとおりに実装するとか
穴があれば、それを埋めることはできるかもしれないですが、

そういう他人が作った穴を埋めることの効率を極めただけの人は、
どう人生を生きたらいいかとか、
どういうシステムを作ったら、要求はみたせるのか？
とか、穴を作るところから始めることはできません。

---

前に書いた「誰もが知ってるけど敢えて言わない確実に身につくプログラミング学習法」に１００％同意するの話の元、

誰もが知ってるけど敢えて言わない確実に身につくプログラミング学習法
https://wirelesswire.jp/2016/04/52633/

（以下太字は上記サイトより引用）

　最初はまさしくサンプルプログラムをファイルで配り、それを少しずつ改造することで教えるスタイルをとっていました。

　ところがこのやり方では、全くうまくいかないことに二回目の授業で気付きました。


多くの人、多くの会社では、このような教育がなされ、「いや、すごく成果が出ているよ！」というお話があると思います。実際、前のブログでは、私は新人担当を首になったという話を書きましたが、その後、このようなやり方になり、私と違い、「ものすごい劇的な成果が出た！」ということで二度と私が教育担当になることはなくなりました。

・・・なのに、元ネタの筆者は、ところがこのやり方では、全くうまくいかなと言っています。このことに違和感を覚える人がいるかと思います。たぶん、上記の方法で、（私が首になったように）劇的な成果を出している企業さんもとても多くいるはずだからです。

なので、そのへんのフォローをしてみたいと思います。

---

「サンプルプログラムを改造」というのは、要するに穴埋め問題みたいなもんです。
穴埋め問題を早く解くには、同じ穴埋め問題を多く解き、パターンを見抜くことです。
考えてはいけません。

その結果どうなるか・・・・


どんなに穴埋め問題を早く正確に解けても、
そして穴埋め問題を早く解くことでいい大学に行き、出世できたとしても
穴埋め問題を解く人生は、穴を「他人から」与えられない限り、埋めることができません。


真っ白な白紙の問題に、「自分が」問題を作って、穴を作ることは、できません。
真っ白な紙には、パターンがない（厳密に言うと「真っ白な紙」という１つのパターンはあるが・・）からです。

　自分が問題を見つけ、問題を解決するには、先人がどうやって問題を見出し、それを解決していったかを、「自分の視点で解釈」し、それを実行してみて、先人との差異を測り、自分の解釈を修正していくという作業が必要になります。その「自分の視点で解釈」するために写経という作業が必要で、解釈することが、理解することになります。

　ところが、穴埋めは、穴を埋めてもらうために、何らかの「他人の見え見えの意図」があって、そこに穴があいていて、回答者は、その「他人の見え見えの意図」を見透かして？見透かさないけど、何となく感じて、「他人の見え見えの意図」にあったものを答えるわけです。そうすると、評価されます。
基準は、他人です。

---

コンピューター業界のＳＥには、２つの種類があります。

ＳＥ１：お客さんが課題とっていることから、「自分が課題を解釈して」
　　　　問題を作りだし、要件定義・概要仕様書に落としていくＳＥさん（上級ＳＥ）
ＳＥ２：上級ＳＥ（＝他人）が作った要件定義や概要仕様書をもとに、
　　　　実装するための仕様書を作る（現在ではＳＥ２は実質、ＰＧと一緒になっている）

ＳＥ１は、何もないところから作りだすので、写経のような教育が必要です。
ＳＥ２、つまり誰かが書いた仕様書をもとに、プログラミングするのは、
他人の意図を読み取り、その中から効率よく穴埋めをすることになるので、
穴埋め型の教育が有効です。

穴埋め型の教育（サンプルコードの修正）が有効なのは、ＳＥ２です。
（実際、首になった会社もＳＥ２に方向転換した会社でしした）。
さっきの記事の筆者は、まさに無から何かを生み出す人なので、考え方として
ＳＥ１的な考えなのでしょう。

ＳＥ２はＳＥ２向きの教育をしたほうが、無駄がないので、劇的に成果が上がります。
なので、そういう会社であれば、写経はしなくてもいいと思います。
なんとなくわかっただけで・・・

ただ、そういう人たちに、ＳＥ１的な仕事は無理です。他人が何もしてくれない
（ユーザーが仕様を固めてくれない、発注元が何も分かっていない等）といって、
結局仕事が進まなくなってしまいます。

そして今はＳＥ２の仕事が減り、ＳＥ１の仕事が増えているという現実があるのも
事実ですけどね・・