クロノス・クラウン - 記事検索

おすすめ
自作の本やゲーム他を販売
便利なWebアプリが多数
ソフトウェア
めもりーくりーなー Winのメモリーを掃除
Novel Supporter 小説推敲補助ソフト
PCソフト まとめ
ゲームブック
闇の聖杯の儀式 電書のゲームブック
ゲーム
Little Land War... Win向けSRPG
Little Bit War Switch向け高速RTS
TinyWar... 1面数分の8bit風RTS
EX リバーシ 変形盤面、盤面多数
https://note.com/yanai/n/n5e50dbd9ead8
2022年05月07日 03:53:42
(2020年10月9日 note投稿の再掲)

 ここ最近、プログラミングと学習について仕事で関わることがあり、いろいろと考えることが多かったので、少し書こうと思います。

 さて、10月8日に、以下のまとめを読みました。おそらく、プログラムを書いている人と、書いていない人とで、大きく認識がずれているんだろうなと感じつつ、コメント欄まで読みました。

> IT業界に教える文化は無いよ。だってネットにノウハウが転がっているもの。 - Togetter
> https://togetter.com/li/1604939

 それで、ツイッターに連ツイしたりしたのですが、もう少し丁寧にまとめておこうと思います。

> 柳井政和「現代のプログラミング言語は、仕様が肥大化して、普通の人が記憶の範囲で書けるものではなくなっている。必要に応じて、仕様やサンプル、ノウハウや解説を見ながら書かないと、無理な複雑度になっている。」 / Twitter
> https://twitter.com/ruten/status/1314289565948018688

 最近、プログラミングスクールを攻撃するような現役プログラマーの言葉などを見る機会も多く、いろいろと思うところもあったので……。大きくすれ違っているなあと。

 というわけで、以下本題です。

 プログラムを書く人で、ネットで発言している人の何パーセントかは「自分でプログラムを書いて自学すること」の重要さをよく説きます。それに対して、プログラムを書かない人の何パーセントかは「教えるノウハウがない」ということで非難しています。

 その意見の中には、プログラムを書く人が「自学できる」選民思想を持っていると、攻撃する内容が含まれています。この不幸な対立が、なぜ起きているのか。現時点での私の中での考えを書きます。

 私は四半世紀ほどプログラムを書いています。その中で、徐々に知識を蓄積してきました。その知識の範囲で言えることは、現代のプログラミング言語は、仕様が肥大化しており、普通の人が記憶の範囲で書けるものではなくなっているということです。

 必要に応じて、仕様やサンプル、ノウハウや解説を見ながら書かないと、無理な複雑度になっています。ここに重要な前提条件があります。

 こうした現状のため、プログラムを書くという行為には、「ドキュメントを読む」という作業が含まれます。また「必要な資料を探してくる」という作業も必要です。

 プログラムを「書く」以上に、「読む」「調べる」能力が重要になっているのです。

 たとえばプログラミング言語やライブラリは、バグがけっこうあります。そして、バッドノウハウが大量にあります。そのため「調べる能力」がないと、開発が進まない、もっと言うと「詰む」という現実があります。

 そのため「プログラミングの学習をすれば、プログラムが書けるようになるわけではない」という現実が生じています。実際にアプリケーションを作るには、文書読解と資料調査の能力が必須になります。

 知らないことを埋めるために、浴びるほど文書を読まないといけない。プログラミングには、そうした現実が立ちはだかってきます。そして「プログラマー界隈」を非難する人たちは、そうした自己解決の行動原理に拒否感をあらわします。

 そうした意見の背景には、おそらく「与えられる教育」への慣れがあるのだと思います。しかし"現在"の時点で、プログラミングを身に付けるには、「知らないことを研究する学習」に頭を切り替える必要があります。現代のプログラマーにとって「知らないこと」を調べるのは、当たり前のことになっています。

 ただ、この「与えられる教育」を提供できていないプログラマー側の現状も問題です。解決しなければならない大きな問題であり続けています。後述しますが、プログラミング自体が、抽象概念の塊という問題もあります。多くの人が使いこなせるようにするには、この問題を解決していく必要があります。

 ……脱線したので、話を戻します。「自分で何かを開発するのが重要」という意見には、この「文書読解と資料調査」による「問題解決」の重要性があるからです。座学だけでは、この泥臭い部分は身につかないです。理想と現実が違うという不幸な現状です。

 よく見るボタンの掛け違いは「プログラムの勉強をすれば、ある時点でプログラムが書けるようになる」というものです。そうした想定で学習している人が、少なからずいます。そして「プログラムが書けるようにならない」と嘆いています。

 しかし、いわゆる箱庭の学習では、この問題解決の能力は身に付きません。答えが用意されていないことをして、初めて身に付くからです。部族の成人の儀式で、長期の狩りに行くような、およそスマートではない行為が求められるのです。

 そして実際のところ「プログラミング言語の仕様の何パーセントか」を把握すれば、プログラムは書けてしまいます。そして、必要に応じて足りない仕様を調べて埋めていけば、アプリケーションは完成するのです。

 プログラミング言語の仕様を網羅的に把握して、内部実装のレベルまで分かっている人はほとんどいません。それでも大きく困ることはないのです。サンプルを見て、それを改造して、望む形に近付けていく。そして足りないところを調べて埋めていく。

 実際にプログラムを書く人が「自走の重要性」を語るのは、現実問題としてプログラミングという行為に、問題解決のための「文書読解」と「資料調査」という作業が含まれているからです。そして、ときにその比重が8割、9割になることも多いからです。

 仕様を読んだり、コードを読んだり、ときにはアルゴリズムを検討するために論文を読んだりしないといけないわけです。プログラムを書くという行為の下に、そうした見えない作業が大量にあり、それは習慣化しないと、なかなか身に付かないものです。

 そもそも論として、現代のプログラミング言語の仕様を把握するのは、かなりの脳容量がなければ難しいです。それも初学者がいきなり飲みこめるボリュームではありません。そのために、相当刈り込みをして縮小した状態でプログラミングを学ぶ必要があります。

 そうした「簡略化した脳内プログラミングイメージ」と「文書読解」と「資料調査」で、多くの人のプログラミングという行為は成り立っています。そのため「自走できないと辛い」という意見が出るのは、こうした現代のプログラミング言語の複雑性と不完全性が招いているのだと感じています。

 実際にプログラムを書いている人たちは、この状況にベターなやり方を身につけています。それは「断片的知識の必要に応じた調達」と「後進のための断片的知識の開陳」です。最適解ではないと思いますが、ベターな解だとは思います。このウェーブに乗るのが、現状では最もよい選択肢です。

 ただこの方式の問題は、「文書を読むのが得意な人」でないと付いてこられないということです。

 文書至上主義なので「プログラムを書く=文書を大量に読む」ことが受け入れられない人には辛いという現実があります。

 実際、プログラミング教育に少し関わると、文書至上主義がいかに危ういかを感じさせられます。

 プログラマーの多くが使いこなしている抽象的思考や、そのための語彙というのは、かなり特殊なものです。複数、結合、代入、差分、変更などといった、現実世界と切り離して概念操作する言葉は、そもそも単語レベルで理解できない人が多いです。また、本を1年に1冊読んでいる人も少ないです。

 そのため、プログラミング言語の仕様や解説書、入門サイトなどを読んで理解できる人は、非常に少ないです。それらをもとに自学できる人は、かなり特殊な人たちです。

 そもそも日常生活で、抽象的に物事を考える習慣がある人自体が少ないです。そのため、「変数」で詰む人もいます。そこを超えられても「繰り返し処理」で挫折する人もいます。真偽値や論理演算も厳しいです。そもそも説明用のコードが、コピペで使えるものでないと、一切受け付けない人も多いです。

 プログラミングは、大量の文書を読むことが前提になっています。そして、その文書には、大量の抽象概念が含まれます。

 現実のプログラマーの世界が文書至上主義で走っていることと、万人プログラマー時代のあいだには、大きな隔たりがあると感じています。

 どうやって、この溝を埋めるのか。この数ヶ月、そのことを考えており、難しさを感じ続けています。

 なのでまあ、プログラミングに触れたいという、ぼんやりとした希望を持っている人は、プログラミング言語の修得を目指すのではなく、大人でもまずはScrachなどから触れるのがよいのではと、ぼんやりと思っています。
最新20件 (全て見る)

オススメ電書 (全て見る

動画講座 (全て見る

サイト目次

おすすめ

PCソフト/Webアプリ

ゲーム

マンガ

記事

柳井の同人活動

開発

携帯・スマホ

アナログ・ゲーム

Cronus Crown(クロノス・クラウン)のトップページに戻る
(c)2002-2024 Cronus Crown (c)1997-2024 Masakazu Yanai
ご意見・お問い合わせはサイト情報 弊社への連絡までお願いします
個人情報の取り扱い、利用者情報の外部送信について