00:02
ソルラジ、ゲーム開発の挫折共有トーク。この番組は、素人ゲーム開発者たちが、プログラミングにおける挫折を、つれづれなるままに共有していく番組です。
ゲーム開発に興味のある方や、開発者の方の参考になることを目指した番組です。
今回の話題は、ソルラジ プログラミング学習の挫折をなぜなぜ分析してみた 、です。
今回の話題は、ソルラジ プログラミング学習の挫折をなぜなぜ分析してみた 、です。
第5回目ということで、今日はプログラミング学習の挫折理由を深掘っていきましょうということで、
学習の挫折したことがどういうことから起きたのかを調べてみました。
プログラミングの学習ってやっぱりむずいんですよ。
むずいよね。
むずいというか、もうだるい。
今日はそのキャラでいくのかな?
そういうキャラでいく。
ギャルみたいな理由。
ごめんごめん。
なんで謝らなくていいの?
僕はもともと大学の時に、情報科学研究科っていう、情報学部ですね。
プログラミングを学ぶ学部に行ったんですけど、なんとプログラミングの授業を3回単位落としてます。
それ必修のやつを3回落としたってこと?
卒業は誤まれたレベル?
そうそうそうそう。
一番嫌いな科目だった。
プログラミング。
覚えてるのが、ひたすら参考書の、その時はC言語っていうプログラミング言語の勉強してたんですけど、
ポインタっていう章あるんですよ。
学習項目で。
そこのポインタのサンプルプログラムを一生読んでて、一生わかんないって電車の中で読んでた記憶がある。
全然わかんないんだ。
わかんない。ただただ開いてた。
でも参考書はだから。
もうなんとかこうね、卒業せんといかんからね。
そうそうそうそう。
もう読まんといかんよね。
結局わからなかったけどね。
すごいね。え、でも3回目行って4回目OKだったね。
あ、4回目はOKだった。
まあいろいろねきっかけがあってプログラミングが好きになったっていうのはあるんですけど、
そうして今回テーマにしたかった理由でもあるんですけど、
そのプログラミングって、なんかわかったって思うとすごいなんか簡単に見えてくるんですよ。
03:06
だけど、なんかわかる前は全くわかんない感じする。
なんかあのギャップすごいあるなっていうのがあって。
なんかこう切り替わる瞬間あるね。めっちゃ簡単やんみたいな。
そうそうそうそう。
で、自分の中ではその理由が考え方とか概念とかを学ぶに近いと思ってるんですよ。
だから1回それを得得するとか。
学ぶとあとはなんか当たり前に見えるみたいな。
そういうような考え方みたいなのもあったりするし。
なるほど。
慣れもあるんだと思うんだけど。
なんか覚えるんじゃなくて、なんか理解する、慣れるみたいな感じなの?
そっちの方が大きいと思う。
なんかいっぱいいろんなことを覚えなきゃいけないのかなと思ってたけど。
そうそうそうそう。
なんかね、覚えるとかはむしろ全然してないと思っている。
仕事とかでプログラミングとか全然あるんですけど、やることはあるんですけど、
基本的な公文とかも言語によって書き方とかは全然違うじゃないですか。
違うんですよ。
違うから、例えば一個フォーブンっていう繰り返し文みたいなのを書くとしても、
Javaだったり、PythonだったりC言語とかで書き方違ったりする。
けど、するから全然調べるんですよ、Googleって。
これ何だっけなみたいな。
だけど、なんか考え方とかは理解してるから、どう使うかとか、どこに入れるかとか、
そういったところをわかってるから実装できてるとかだと思う。
わかる。なんかExcelの関数とかも同じだよね。
なんかこういうことできるやつあったなって言って、
もう忘れてるけど検索して持ってくるみたいな。
そうそうそうそう。
あるある。
だから逆のことを当時はしてたのかなって思ったりしてるんですよ。
なるほどね。
参考書から書いてあることを、なんか覚えようみたいなスタンスで多分取り組んでたのが、
多分めちゃくちゃ大回りした理由かなとも思ったりする。
なるほど。学習の仕方もあるんですね。理解。
だからこそ、今の小学生とかプログラミング学習が教育の中で義務化された中で、
プログラミング言語を書くとかそういうところからやらせない理由っていうのは、
まずプログラミング的思考だったり、プログラムの仕組みというか、
そういうのを概要というか概念的に理解をしようねっていうところから始めるために、
あえて言語とかそういうのから入らない。
なるほど。
っていうことを大事にしてるのはすごく納得が出た。
なるほどね。
どういう構図でどうなってるのかって理解してやった方が、
学習もすごく分かりやすくなるって感じね。
そうですね。大学に行ったの大体8年9年前とかなんですけど、
その時急にプログラミング言語みたいなのを学んでたんですけど、当時は。
全く知らないところから。
その入りは多分僕にとってはやりづらかった、難しかった入りだったんですよね。
急に。
06:00
っていうのも、コンピューターとかそういう機械的な仕組みだったりとか、
メモリとかそういう原理を知らないのと知ってるのとで、
結構プログラミングの理解のしやすさって変わるかなと思ってるんですよ。
そうなんだ。
だから今は結構プログラミング言語を学ぶ最初のステップとしては、
コンピューター科学を学ぶっていうのが今多分主流になりつつあると思ってるんですけど。
コンピューター科学ってコンピューター自体をどういう構造なのかって学ぶってこと?
そうそう。
そのコンピューターの仕組みだったりとか、歴史までやるのかちょっと分からないけど、
そういったところから急にプログラミング言語を書くってところから始めなくて、
その背景だったりとか、そういうところから入っていくっていう流れは
個人的にはめっちゃ好き。
なるほど。
しかも意外と近道で理解するのが早くなるみたいな。
そうそうそうそう。
そうですね。
僕はこのジョー君にプログラミングについては結構教わったりはしてたんですけど、
確かにコンピューターを紐解いていくとすごく理解しやすくなるプログラミングっていうことが確かにあったので。
あったんだ。
第何回だっけ?2回目か3回目に、第2回目かな?
デジタルの世界について、デジタルとはみたいな話したじゃないですか。
なんかしたかもね。01ね、01。
01、そうそうそうそう。
01世界ね。
あれ一番大事にしてるんですけど。
2回目だね、たぶん。
2回目だっけ。
ああいうところから本当は話をしていきたいんですよね。
なるほどね。
01の世界とはっていうのを理解して、その世界の成り立ちだよね。
今ここに酸素がありますよねとか、そういう前提があって生き物がいますよね。
だから肺があるんだよとか。
そうそうそうそう。
なんでこうなの?みたいなのが結構説明しやすいんですよね。
特に僕が最初学んだプログラミング言語がC言語なんですけど、
C言語は特徴としてコンピューターのメモリの操作っていうのが得意なんですよ。
でもメモリのことをそもそも知らなかったら、全然価値がわかんないというか目的もわかんないみたいな。
メモリが何してるかよくわかってないもん。
そうそうそうそう。
で、結局メモリ操作っていうところで一番直接的なポインタっていうところが全然理解できなかったのもそれが理由かなって。
メモリ操作をするためのポインタなんだね。
そうそうそうそう。
メモリとポインタが何かわかってないけどそれを操るためのポインタっていう言葉がわかった。
そうそうそうそう。
だからメモリ知らずにポインタ学べないよね。
難しいね難しいね。
空気知らずにはいの意味がわかんないみたいな。
そうそうそうそう。
っていうところ、ちょっと脱線気味にはなっちゃったんですけど、絶対僕だけじゃないと思うんですよ。
プログラミングの挫折。
実際世の中的にはプログラミング学習の挫折率っていうのが90%。
09:02
はいはいはい。
で出てるんですよ。
プログラミング学習のやってるスクールさんがアンケートとか取って出してたじゃないですか。
ちょっとスクールさんがあるんでちょっと案件感あるんですけど90%にしたいっていう感じがあるのかわかんないですけど。
でもそれぐらい本当に実際に取ってみたらいたっていうのは事実。
挫折とか人それぞれ困ったことがありましたかって言ったら絶対何かしらある。
あるあるある。
数値の信頼性とかいろいろあるけど、とにかく確かにまだまだプログラミングの学習っていうところはもっとやりやすくできたりとかわかりやすく楽しくっていうのは全然改善の余地があると思っているので、
そこの深掘りっていうのをまず第一にやりたくて、だいぶ前なんですけどね。
みんなで有識者も含めてその深掘りっていうところをしたのを今回はお話ししたいなと思っています。
なるほど。あれですよね、結構すごい図表に図解でまとめて作ってもらって、
なんか4つの種類の観点で見たらこういうことが起きてますよみたいなところまでちょっと累計化してまとめたんですよね。
まとめた。まずこれって今回貼ろ。
貼る貼る。
貼る。
これ概要欄にみんな見れるように。
見るのが一番早い。
早いよね。
スマホの人とか見づらいかもしれないけど、ちょっとこれをね、パソコンとかで。
要はそのプログラミングでなんで学習挫折するのかっていうところを、なぜなぜ分析的にマインドマップを使ってみんなで案出ししたりして、
その中の重点的な理由っていうところを赤字にしてまとめて、まとめたといっても結構数がある。
これすごいね、ほんとすごいね。
30個ってあるね、理由は。
そうね。
で、考え方としてはそのプログラミングの学習の挫折っていうところで、
なんでっていう理由を考えるときの観点として、
人の観点だったり方法っていうところだったり環境、
あとはその学習内容、プログラミング学習っていうそのものっていうところの観点で理由を検討したっていうところの資料になります。
なるほど、なんでこれ4つに分けてるんでしたっけ?
考え方としてはQCストーリー。
QCストーリー、QCサークルって一時期流行ったやつね。
そうなんだ、流行りあったんだあれ。
あれ分かんない、何年か前に会社でやった記憶がある。
ソフトウェア設計とかプログラムの開発とかでは、QC製造技術とかそういったところでよく使われたりするんですけど、
一言で言うと何か課題が起きたときの解決する手段だったり、よりこれを改善したいな、現状から改善したいなっていうときに使われる手法なんですよね。
その中のQCの7つ道具って言われているその1つが特性要因図っていうのがあるんですよ。
12:01
魚の骨とかって言ったりするんですけど、
それはある課題があったときにその理由をみんなで探り出す、ブレストから始まって重要なところをキーとして決めていくというか、
そういったところの結構いい図、使える図なんですけど。
それをちょっとマインドマップ的に落とし込んだような感じになってます。
プログラミング学習の挫折ってなると、まず大きく何個出したっけ、5個ぐらい出してるよね。
5個出してる、これ図に書いてるやつ?
そうそう、まず直接的な理由っていうところで、プログラミング学習に挫折するから、
最初に入っているのが、左上で言うと時間が確保できないっていうのがそもそもあったりするね、環境として。
あとはエラーを解決できない。
これが個人的にめちゃくちゃあると思う。
いやー、エラー出たり、なんかどうしようもないときいっぱいあるよね、これ。
そうそう。
分かるわ。
エラーを解決できないっていうところは、
調べて出てこないしね。
そうそう。
プログラミングって人それぞれじゃないですか、作りたいもの次第というか。
なんで、自分の作ったプログラムの場合のエラーっていうのは、簡単に検索して出てこなかったり。
はいはい。
で、出てきたとしても英語とかで、すでに赤字英語抵抗ある。
あと数もめちゃくちゃ出るときあるし。
分かる分かる。
で、そもそも英語を日本語に訳してみても、何言ってるのか分からないって多々あると思うんですよね。
翻訳にペタって貼ってもね。
そうそうそうそう。
あとそもそも専門用語とか出てるから。
ニュアンスが変わっちゃうんだよね。
それを理解するためのプログラムの知識もないみたいなこともあると思うし、概念を知らないとかもあると思うんで。
そのエラーを解決できないっていうのは一個大きくあるなとは思ってます。
なるほど。
で、その次はモチベーションが続かない。
さっきのエラーを解決できないってところに関わるところではあるけど、モチベーション続かないっていうのは一個大きな要素としてある。
あるね。
モチベーション、なんかこうやらなきゃいけないからやろうみたいな流れだと、英語とちょっと似たような感じがあって。
世の中、プログラミングと英語だからとりあえずやっとくかみたいなんだと、あれ?みたいな気が付いたらなんでやってんだろうみたいな。
そうそうそうそう。
よくある。
あとは教材や参考にしているサイトを読んでも意味がわからないっていうところもあると思うんですよね。
そうね、読学厳しいよね。
そうそうそうそう。
参考のサイトって、確かに参考になるのもたくさんあるんですけど、ありがちな、結局わからないパターンって自分の中では二つあると思ってて。
一つが、例えば繰り返し文の書き方とか、そういったものを調べると出てくるわけじゃないですか、公文とか。
で、こういう風に書けばこういう処理するんだなっていうのはわかるんだけど、その一文がわかったとしてもそれを活用して自分のゲームで敵をいっぱい出す方法とか、
15:04
そういうもっと実用、自分の中の作りたいものに実用化するときにその方法がわかんないっていうパターンがあると思うんですよ。
はいはいはい。
一文。
で、もう一個のパターンとしては、RPGゲームが作りたいですってなったときにRPGのゲームの参考のサイトがあったとしたら、それは逆に完成されすぎてて、そのまま引っ張ることしかできない。
なるほど。ペタって貼って、それ以上改造できないっていう。
あ、そうそうそうそう。一個一個があまり理解できてなかったりとか、これとこれが実は連携している処理があったりとか、
確かに。
そういうのがわかんなくて、分解できなくて、アレンジもできないみたいな。その2パターンが僕の中で結構多いっていう印象がありますね。
はいはい。なんか作ってる感覚じゃないよね。ほぼコピペして再現してるだけっていう。
そうそうそうそう。
なんだろうねあれ。
そう、プログラムしてる実感もないし。
ないないないない。
なんかイメージね、あのRPGゲームでなんかそのまま引っ張ってきたら、じゃあそのこのアイテム欄とかを自分の考えたアイテムに差し替えればいいかなとか、
敵のキャラクターの名前とか敵を差し替えればいいかなとかって、なんか骨組みはできてるからそれをベースに変えればいいかなって思って引っ張りがちなんだけどコピペで。
でも実はそれらが相互作用している処理があったりとか、そういうケアをしてないしないといけないところって、それってそのゲームの作り方次第で全然変わるわけなんですよ。
はいはい。
ということは結局はそのゲームの全体の作りだったり構造とか仕組みを知ってないといけない。
しかもその作者の考えとかも理解しないといけない。
なるほどね。
ってなると結局ゼロから作ってった方が早くねみたいなことも結構あるような印象を受けてますね。
結構ゲーム作りにおいてもプログラミングと一緒で構造理解が大事なのかもしれないですね。
なぜこれがこの動きをしているのか、どういう世界観でどういう演算が行われているからこういう動きなのかとか。
もっと言うとそれを自分で作るのが設計だって構造。
その人はこういう考えでこういう構造で設計をしたんです。
データのまとめ方とか使い方とか処理のタイミングとか。
こういう困ったことがあってこういう処理に変えてたりとか、いろんなストーリーの結果がサイトに載ってるだけなんですよ。
だから理由わかんないから、ただうまくいってるってことしかわかんないんですよ。
そのまま何かこう…。
ちょっと変えようとすると、その作者がたぶん道の途中で問題が起きてそれを対策した結果今の形になってるけど、
自分がアレンジ加えるとそれにちょっと戻るみたいな。
文脈が変わっちゃうもんね。
たぶん重力の話とかもまさにそれだと思っていて、
月に行った時にめっちゃジャンプできるけど、地球だと普通のジャンプしかできないみたいなのがあって、
環境とかどの星にいるんだみたいな理解がないと全く再現できないみたいな。
そうそう。ちょっと力踏ん張ってジャンプすれば8メートルぐらい飛ぶよって言われてもわかんないわけですよ。
わかんない。地球にいるからわかんないみたいな。
そうそうそうそう。っていうところがあるから、だからそこが難しいんですよね。
18:02
意外と出来上がったものを引っ張ってこれるのはすごく理解している人じゃないとできないんじゃないかなと思ってます。
わかんないね。これなんだっけ?モチベーションだっけ?
あ、ごめん。教材やサイト、参考サイトを読んでも意味がわからない。
意味がわからないか。そうだね。わかんないね。文脈とか構造が理解できるようなものがないってことだね。
そうそうそうそう。
枝葉しか見えてこない。
っていうのがありますね。あとは、学習の順番っていうのもなんかわかりづらい。
いやわかんない。どこから何を勉強しているのか未だにわかんない。
なんかよくあるのは、プログラミングって最初変数から始めて。
一番疑問が最初のそれねっていう。
そうそう変数から始まって、あとは演算、その後は処理の分岐、あとは繰り返しとか。
そこでほぼほぼプログラムの、っていうものの大事なところは抑えてはいるんですけど。
俺個人的にはなんですけど、関数とかから多分学んだ方が僕は好きなんです。
そうだね。
なんでかっていうと、プログラミングって何のために使うんですかっていうのも知らないところから始まるわけじゃないですか。
確かに確かに。
プログラミングの学習者って。
確かに。なんでプログラミングを学ぶんでしょうね。しかも国を挙げてこんなになんで頑張ってるんでしょうね。
そうそうそうそう。
よくあるのが、プログラミングって自動化できるだったり、処理が早いとか、正確であるとか、機械との相性もいいとか、色々あると思うんですけど、そのメリットっていうのはね。
ただ、自動化をできるってどういうこと?みたいなこともプログラミング知らない人ってイメージつきづらいと思うんですよね。
なった時に、いつも自分が最初に説明する時に言ってることが、例えばプログラミングをすると自動でツイートをするプログラムとかが作れますよ、アプリで。
自動でツイートするってどういうこと?っていう時の説明でしやすいのが関数なんですよ。
関数なの?学習の順番が分からない。
そう、分かんないってとこで、関数から話したいなっていう理由の話なんだけど、よく言うのがプログラムの動いている例の説明をするときに、そのツイートを、Twitterね、今はXって言ったりするけど、
Twitterのツイートをするプログラムを実装しますっていう時のイメージとしては、APIの話をするんですよ。
APIって?
難しいでしょ。
それ何の略かっていうと、アプリケーションプログラミングインターフェースでAPIって言うんですよ。
API、アプリケーションプログラミングインターフェース。
一言で言うと、Twitterが用意している関数なんですよ。
Twitterが用意している関数、より分かんない。
プログラミングって、ファイルの中にテキストファイル、イメージですよ。テキストファイルの中に文字を打って、それを実行してプログラミングとして動作させるんですけど、
21:01
その書くテキストの内容として、いろいろ書けるんですけど、関数っていうものを書くことができるんですよ。
それ何かっていうと、コマンドのイメージなんですよ。コマンド。
ゲームのコマンドみたいな感じ?
そう。
波動圏と。
波動、そんな感じ。
下斜め下前みたいな。
それのコンピュータ版みたいなものなんですよ。
だから、テキストの中に波動圏って書くじゃないですか。で、実行ってやると波動圏打つみたいな。
そういうイメージなんですけど、それのツイートするっていう関数があるイメージなんですよ。
なるほど。じゃあこの波動圏っていうものをワンポチで、どっかから飛ばしたやつのデータが来たら飛んでくんだ。
そう。そのために、プログラムでツイートするっていうコマンドが書けます。
でもツイートするためにログインとかも必要だったりするじゃないですか。
だから最初にログインするっていう関数をコマンド打ってログインする。
その次はログインするときのIDとパスワードを入力するっていうのを打ってツイートする。
でもツイートするときもどんなツイートするっていうのがあって文字列打つじゃないですか。
今日はいい天気ですねってツイートするっていうコマンドを打つっていうことをやって書いて実行するんですよ。
わかった。その超必殺技をR2、L2とかでワンボタンでできるようなやつがAPIなんだ。
そうそう。気をつけないといけないのはツイートするって普通にコマンドを書いても
ちゃんとツイッター社が用意しているデータを使わないと実際にはツイートできないんですよ。
要はツイッター会社さんが用意しているコマンドっていうのをデータをインポートしてきて、
インストールしてきてそこに書いてあるコマンドを使わないといけない。
何もせずに急にテキストにツイートするってやってもツイートするって動かないんですよ。
なるほど。さっきの書き方とした斜め下前みたいなところをちゃんと理解してそこに打ち込んでいくっていうのをやらなきゃいけない。
そうそう。なので、要は自分がなんで関数から教えたいって思ってるかっていうと、
一番シンプルな動きやすいプログラムを書くときに実用的なプログラムを作るってなったときに、
そういうAPIを使って関数を使ってツイートするってやって、ツイートするやん、プログラムを作れるっていう意味では
結構関数がわかりやすいって意味では、あ、動く、ちゃんとプログラムがみたいな、
そういうのがあるから関数を最初に教えたいなっていうのは結構思ってるんですよ。
なるほどね。一番実感しやすそうな動きをしてくれるやつだよね。
そうそう。結構ね、プログラミングの勉強を始めた人とかは知ってると思うんですけど、
最初よくやることってプリントっていう関数を使って、
ある、ハローワールド。
わかりやすいでしょ。
わかる。
あれわかりやすいじゃないですか、ハローワールドって。
あれって結局プリントっていう関数を使ってるんですよ。
あー、そういうことか。自分で書いてるのね。ここに表示するよっていう関数がプリントってやつで、
その後ろに書いてあるやつを表示してねっていう関数だね。
24:00
そう。で、そのプリントFっていうのは、コンソール画面というか結果の画面にプリントFこんにちはってやったらこんにちはって表示されて、
うわ、動いたってなるじゃないですか。
で、なのに1回目はそれやるのに2回目から変数の話になるんですよ。
で、そのままプリントFみたいな関数の話を展開していったほうが、
あ、いろいろできるんだなってなると思うんですよね。
だから入りとしては、なんか僕の中では関数からいろいろ話をしていったほうが、
あ、プログラミングって便利だなみたいなことをイメージできながら学習できると思ってるんですよ。
なんかこいつ使えるやんっていうのがわかりやすいっていうね。
そうそうそうそう。
そういうことだね。
確かに。
ちなみにハローワールドってなんでハローワールドってそのプリント最初、
プログラミング学習の最初ってプリントって言って、
画面上に何かを表示するっていう学習から必ず始まるって思ってるんですけど、
で、それの時の言葉がハローワールドっていうのが、
どの教科書見ても必ず最初それなんですよね。
あれ何の宗教なんだろうって。
こんにちは世界って。
こんにちは世界。
あれね、なんかあるっぽいよ歴史。
あるんだ。
ごめん俺あんまりよくわかってないんだけど、
コンピューター視点なのか人視点なのかもわかりづらいじゃんあれって。
確かに。
新たなプログラミングっていうデジタルの世界に来たよ、こんにちはみたいなイメージでいいんじゃない?
知らないけど。
もうなんかお決まり伝統芸能みたいな感じ。
そうそうそうそう。
あれは面白い。
たぶんね調べたら出てくる。
あ、そっか。語源とかあんのかな。
うん。
ありがとう。
学習の順番は関数からやった方がいいってことですね。
個人的にはね。
うん。
わかりよいね。
そうそうそうそう。
っていうのはあるかな。
そう、だから学習の順番がわからないっていうのも、
結局これ学ぶとこれできるとかいろいろあるけど、
作りたいもので関係ないやつもあったりするし、
これを学ぶためにこれが必要みたいなのも、
あったりなかったりとかいろいろあったりするから、
そこら辺はわかりづらいっていうのも一個疎外してる理由かなっていうところを挙げてます。
あるね、確かに。
あとは不明点聞けないっていう環境だったり、
面倒くさかったりとかいろいろね。
聞くっていうところはちょっと一個ハードルとしてあるよねっていうのは挙げてるよね。
確かに。
聞ける人いないよね、普通に聞いてたら。
あ、そうそうそうそう。
だからその手でヤブさんとかは聞ける人いるかいないかとかで、
結構やりやすさ変わってたんじゃないかな。
大きく変わったね、そこは。
ああ、そうか。
やっぱ聞けると進みやすい。
進みやすいですね、もちろん。
疑問に思ったことを一応聞けるんで、疑問に思って。
だから僕最初、17、18ぐらいのとき、高校生ぐらいのときに一度ゲーム作りに興味があって、
教科書買って10分で出したんですけど、
その時は誰にも聞くこともないし、できないしっていうのは大きかったですね、今も考えてみると。
あとさ、なんかよくあるんだけど、パソコンとかに絡むさ、質問とかってさ、
なんかスペックどうかとか、
もうわかんないね、それ。
なんか環境だったりとか、
使ってる言語とかもあるけど、やりたいこと何かっていう説明からしないといけないじゃないですか、
27:02
プログラムとかって、人それぞれ違うんだから。
だから質問する手間っていうのも単純に大きいんですよね。
てか質問するときどういう言い方をすればいいのかなとかも、質問しやすさに遠のいていくというか。
わかるなあ、説明のコスト高いよね。
そう、それ結構あるんですよね。
気軽になんかこれができないみたいなパターンがあんまりないっていうのが結構難しいですね。
そうか、この場合はこれみたいなのが無数にあるから、
そこだけ言われても聞かれてる方もわかんないみたいな。
そうなんですよ。
そもそもそれブラウザが何みたいな。
開いてるインターネットのブラウザによって違うのかとか。
そう、よくあるのがこのエラー出ちゃったんだけどみたいな。
このエラー出ちゃったんだけどどうすればいいっていうのは、
質問された側もなんでこれが出てるのか次第。
だからその理由とか現状とかを知らないといけないから。
なるほど。
そのためにプログラム一回見せてってみたいな話もあったりとか。
聞けない、不明点を聞けないっていうのは、
人っていう聞けないもあれば、
わかってる上で何を説明していいのかわかんなくて聞けないっていうのもあって、
二重句だねこれ。
そうなんですよ。
だから不明点を聞けないっていうところは、
なんか人っていう環境だけじゃなくいろいろあるねっていう。
そうか、前提の理解がまず難しい。
難しい。
何でエラーが起きてるのか。
もしくはそれが、むしろそれがわかってれば多分解決できるんだよね。
そうそうそうそう。
そこから一緒に考えてほしいってやつね。
あとまた他にもあるのが、
エラーは出てないけど、
自分の意図したような動きをしない。
はあ。
だから自分の意図って何っていうところも聞かないといけない。
本当はどう動かせたいの。
なるほど。
こういうふうに現状動いてる。
そのギャップみたいな。
プログラムはもう書いた通りにしか動かないんで、
それがそうそうそう。
なるほど。
これでもプログラミング学習の話してるようで、
意外と人生に全部転用できそう。
他にも質問のしづらさとか。
そうそうそう。
仕事とかね。
何がわかんないのかわかりませんっていうよくある質問。
そうだよね。
悩み相談とかも含めてね。
そうそうそう。
全部に使えそう。
そうだよね。
っていうところはありますよね。
他にはマスターするまでの道のりが長いように見えるっていうところも。
確かに。
最初の頃は特になんですけど、
これちょっとしたもの作ろうとしてるだけなのにめっちゃ時間かかるやんってなって、
絶対無理。
じゃあ1年以上かかるじゃん作りたいものみたいな感じになって、
挫折するパターンもあったり。
そうね。
する。
なんかすぐ作れないってなって逆にね、
心折れるというか。
そう。
イメージしづらいと思うんですよ。
自分がプログラムできるようになったら、
これはすごく早くできるようになるとか、
そういったものイメージできるわけないじゃないですか。
そもそも上手くなったことないんだから。
だからずっとこのペースなのかなっていう感じにもなっちゃうし。
30:01
なるほど。
実はいろいろスピードアップできるところがいろいろあったりするけど、
その要所っていうのもわからなかったりとかあったりするから、
道のりが長いように見えるっていう言い方をしてるんだけど、
そういったところがまずあるかなと思って。
確かに。
ざっくり説明したつもりだったけど、
結構なかなかといろいろと理由を言った感じになる。
主要な7つのやつね。
そうそう。
1個1個見ていくと、
時間が確保できないっていうものと、
エラーが解決できないっていうところと、
教材や参考サイトを読んでも意味がわからないっていうところと、
学習の順番がわからない、
不明点を聞けない。
これは人に対しても説明に対しても聞き方がわからないってところも含めて、
マスターするまでの道が長いように見える。
どうもないと。
モチベーションが続かないと。
この7つからどんどん派生して、
その7つの中でさらに細分化して、
どんな理由があるのかみたいなのを今図解にまとめてるっていう。
そうなんですよ。
それをそこには重要な理由ではないと思って、
これはあるあるっていうか、
そういうことは1つの表面観にされてるだけであって、
本当はその真意みたいなのが出てあるから、
そういったところをこれからは1個1個紐解きながら話していきたいなと思っています。
なるほど。
この中のあるあるの部分ちょっと話していこうみたいな。
赤字で書いてるところは特にね。
ヤブさんとかはどう?
共感というか、
ヤブさんの中でこれそうだったなとか、
なんかあったりする?
僕でいうと、
エラーを解決できない。
エラーが出てきたときはやっぱりもう絶望するよね。
マジか。絶望レベル?
絶望してた。
ふわ。これ。
だから僕が学習の仕方というか、
僕がプログラミングっていうものを始めたときは、
ゲームを作る。
Unityでゲームを作るっていうところから始めてて、
最初に何をしたかっていうとコピペ。
サイトを参考サイトを使って、
この機能を作りたいなっていうのを調べてコピペをしていく。
さっき言ってたやつ。
1つ目はOK。
じゃあ次のこの機能を入れよう。
ときに何故かエラーが出るみたいな。
要はアレンジを加えたりとか、
追加をしようとしたときってことだよね。
そう。
っていうときにもう中身が分からないから。
何のエラーかも分からないし。
そう。
っていうのでもうどうしようもなくなるっていうパターンが一番大きかったかな。
そのよくあるのがね、
エラーが出たときの設計者としてのスタンスとかも、
色々社会とかではよくトラブリがちなところだったりするんですよ。
エラーが出て、
エラー出たら無理ってなって、
エラーはまず何を言ってるのか調べたのか。
このエラーは何で出てるのかっていうのを自分なりに調べたのか。
デバッグログとかプリントFを使って。
なんか難しい言葉出たな。
要はどこで出てるか。
自分の書いたプログラムのどの行で出てるかとかを調べる方法もあったりするんですよ。
33:02
なるほど。
どこで躓いてるのかっていうのは、
当たりはつけられるんだね。
そうそうそう。
じゃあ何で出てるのかっていうところの、
そこがね、何でもかんでも調べて出るもんでもないし。
なるほどね。
でも知識もないと考えることもなかなか難しかったりするし。
そういったところで、
人に聞きたいなって思ってるのも、
人がいなかったりとか。
はいはいはいはい。
それ結構挫折のポイントだったりするんですよね。
悩み方怒られたりするんですよ。
へー。
もうなんか罪ゲーじゃないですか。
そうそう。
もう何やってもバッドエンドやん。
何もせずに悩むなみたいなこととかも、
言われたりするわけですよ。
質問の仕方とかにもよるとね。
いろいろあるんですけど、
思いはね。
質問する側もされる側もね。
あるんだけど、
大きくエラーっていうところがきっかけで、
挫折する人は多いと思うんで、
そこはちょっとエラー解決できないっていうところは、
重点的に話していきたいところかなと思ってるんですよね。
エラーは特に大事なポイントってことですね。
その解決の仕方と、
さっきの話で言うと、
聞き方とか、
考え方とか、
処理の初動のあたりも大事そうですね。
どう対応していくかっていう姿勢というか、
周りの協力の得方とか、
だいぶいろんな要素が必要だね。
コミュニケーションとか、
考え方とか、
だからプログラミングっていうよりかは、
人生に役立つ課題解決方法を学べる感じがすごいしてるかも。
なんか通ずるところは何かしらあると思う。
するかも。
そうだよね。
いいね。
それを転用して、
人生いきやすくなればいいな。
あればいいけどね。
いいけどね。わかんないけどね。
そうだね。
だからそういう意味では、
エラーを解決できないっていうのは、
ちょっと次回っていうか、
次のテーマの話をするときに話したいかな。
向き合う。
向き合い方っていうところかな。
すごい。ちょっと哲学的やん。
向き合ってるようで向き合ってなかったりとかするんですよ。
なんじゃそりゃ。
最初。
向き合いたくねえってなったりするんですよ。
本当にそうですよ。
あの赤字とか英語とか。
確かに確かに。
情報量の多さとか変な。
向き合いたくないっていうのがあるんじゃない?
山本さん向き合いたくなかった?
山本 僕の場合は、
Unity開発してて、
エラーが出たときに、
エラーは出たんだけど、
挙動は特に異常ないんじゃないか?
みたいなドキュメントがあるんですよ。
けど、エラーメッセージは出てる。
もう、その瞬間向き合いたくなくなって、
これは後回しで。
なるほど。
みたいな。
なるほど。
まだわからない。
これはちょっと調べてもわからないな。
出るね。
挙動自体は、
意図した挙動になってる気がするんだよな。
まあいいか。
後回ししよっか。
自分との戦いだ。
そういう向き合い方というか、
そういうことは多々ありましたね。
それで、毎回ジョークに怒られてました。
36:01
ジョークさん、厳しいな。
これさ、エラー出てるからさ、
エラーは解決しよ。
その中では、
スタンスっていうところの共有というか、
自分の中のスタンスなんですけど、
エラーを潰すべがない状態で、
開発を進めたほうが、
結局楽なって考えてるんですよ。
その理由が、
エラー出るじゃないですか。
で、放置するじゃないですか。
放置するとどうなるかっていうと、
プログラムがだんだん大きくなってくるんですよ。
そしたら、どこが原因なのかが、
だんだん分からない。
どんどん闇に深くなっていくんですよ。
なるほど。放置がダメなんだね。
そうなんよ。
影響がでかくなっちゃう。
そうそうそう。
だから、エラーを、
しかもその対策をするってなった時も、
そんな箇所を対策しないといけないんですよ。
影響範囲とかがすごい大事になってくるんですよ。
ってなると、
一番難易度低い状態なんですよ。
エラーが出た瞬間が。
そうか。
エラー解決の。
火事で火が出た瞬間なわけね。
そうそうそう。
そういうことそういうことそういうこと。
火がめちゃくちゃ、
もういろいろ燃え上がってから、
対処するより早いじゃないですか。
そうだね。
そう。
だから少なくともそのバージョンで、
出た時と出なかった時、できれば。
もう保存して、
そうか。
その概念でいくと、
このプログラミング学習の中の、
7つの自分がどこに躓いているのか、
ってことをすぐに理解して、
引消しをするっていうのが、
学習を続けられることに続きそう。
そうそうそう。
っていうのはあるんですよね。
じゃあこの辺、
もうちょっと広げたいですね。
そう。
今そういえば、
ちらっと見たけど、
コンボになってんだよね。
挫折する。
エラーが出る、向き合いたくない、
向き合ったとしても聞ける人がいない、
もうそれだけでやめられるもんね。
もうトリプルコンボぐらいで、
モチベーションが続かなくなるよね。
そうそうそう。
モチベーションが続かなくなって、
マスターも道の長いように見えるし、
参考サイトも参考にしづらいから。
確かに。
格ゲーだったら、
フルフルのHPがほぼ瀕死になってるもんね。
そうそうそう。
だからね、
本当はなんだけど、
参考サイトとか教材も、
本当は個人的には、
完成された一品だけを載せるんじゃなくて、
作り途中も含めて、
プログラムをこれを、
今回はこの機能を実装するから、
これ変わりましたみたいな、
そういう段階的なやつが、
もっと説明として、
あると分かりやすいのになって思うサイトは、
結構個人的に思ったりするんですよ。
ストーリーなんだね。
文脈とか。
そうそうそう。
ストーリー大事。
ストーリー、文脈なんだね。
めっちゃ大事。
以前話したっけ、
ソフトウェアって、
品質の話をするときに、
ソフトウェアの品質っていうのは、
どうやって評価するかっていうのは、
ある程度も決まってて、
出来上がったもので、
品質高い低いかって、
測るよりも、
出来るまでにどういう設計を、
どういうストーリーを踏んで、
作ったかっていうのが、
ソフトウェア品質なんですよ。
何が言いたいかというと、
出来る過程が大事なんですよ。
チェックした過程とか。
なるほどね。
そうそうそう。
バグが起きません、このソフトはって。
39:00
言い切ること絶対できないんですよ。
何でかっていうと、
バグが出ませんって言った後に、
やったことないことをやったら、
バグが出たら、
これはバグが出るものなんですよ。
だから言えることは、
この時点で、
これだけの確認をしたら、
バグは出ませんでした、
っていう言い方しかできないんですよ。
なるほど。
品質の話は。
ここまでねっていう。
そういうことです。
しかも調査した範囲は、
ここまでの範囲っていう。
そうそうそう。
本当限定的なことを、
確認しながらしか進めない。
そうなんですよ。
保証できる範囲っていうところも、
すごい大事になってくるんで。
だから、
そのプロセスとかを含めて、
なんかその教育とか学習の中で、
見える化をした方が、
本当は分かりやすかったりするんじゃないかな、
って思ったりしてます。
めっちゃ大事だわ。
本当そう。
それ大事。
大事すぎるわ。
会社の中の商品を、
なぜこれを作ってるのかとか、
企業体の動きとかも、
全部それに通じそう。
その文脈を理解していくんだったら、
こういう売り方だよねっていうのが、
自然とやっぱ分かるもんね。
それがプログラミングの構造理解とか、
ゲームの中の構造理解っていうのと、
なんか似たようなものがあるかも。
そうなんですよ。
っていうのもあって、
一応、
ソルベンタで作ってるゲームっていうことだったり、
学習項目っていう観点で見ると、
このゲームをすると、
自分でRPGゲームが作れるレベルの
プログラミングっていうのが学習できます
っていうところを掲げてるんですよ。
そのRPGゲームを作るためには、
例えば、
アイテムとかコレクションできる機能必要だよね。
アイテム一覧とか。
キャラクターのステータスだったり、
敵と味方の区別だったり、
アニメーションだったり、
コマンドだったり、
そういったものをどんどん実装していくじゃないですか。
戦闘のシーンだったり。
そういったものを、
ちょっとずつ、
作る過程と機能の追加っていうのが
見えるような形で、
その学習っていうところを
表現していきたいなっていうところは、
設計の中で意識しているところですね。
なるほどね。
このゲームを学ぶことによって、
何かRPGと一本が作れるぐらいの
構造理解ができるってことね。
そういうこと、そういうこと。
なるほど。
そういうところを目指すために、
この挫折をどう潰すかっていうところを今検討して、
ゲームにも落とし込もうとしてるって感じですね。
あとは、美女にエラーの言葉とかを言わせたい。
じゃあこれぐらいでですね、第5回目を。
ちょっと待って、大事だって。
大事なんだって。
エラーを、
ちょっと待って、終わらん。
エラーを、
エラーと向き合いたくないのは、
やっぱり向き合いたくないような事態になってる。
赤字とか。
味気ないコンソール。
楽しくないもんね。
楽しくないでしょ。
だから、
可愛い女の子だったり、
もうイケイケの面。
イケメン。
そう。
イケイケの面。
イケイケの面。
ちょっと美味しそうだったもん。
流行りのラーメン屋みたいな感じだね、多分。
イケイケの面とか、
可愛い子が、
エラーの話をすごく分かりやすく、
話してくれるとかが、
個人的には大事な機能なんだと思うんですよね。
そういう機能も大事だね。
盛り込んでいきたいですね。
そうですね。
じゃあそろそろジョーさんに黙っていただくということで、
第5回目を終えていこうと思いますけど、
じゃあ今日話した7つのプログラミング学習に関する挫折の図解っていうのは、
42:03
概要欄に入らせてもらいますっていうところで、
ぜひこれを聞きながら、
冒頭に言ったほうがよかったかな。
そうね。
っていうのと、
あとこれはどんどん改範をしていきたい。
はい、改編ね。
改編をしていきたい。
そうそうそうそう。
改善。
バージョンアップしていきたい。
もうバージョンアップしていきたい、これ。
そうね。
これで答えですっていうつもりはなくて、
大事なのは、
これの深掘りをし続けること。
そうね。
だからこれはね、
これはずっと考え続けていきたいテーマ。
皆さんからの声もいただきたいところですね。
嬉しい。
そのために、
うちらもですね、
僕たちもツイッターをやってますので、
ツイッターというか、
XQツイッターで、
SOLVENTERで検索していただければ、
僕たちのですね、
弱小Xツイッターがおりますので、
そこで絡んでいただけると嬉しいなと思っております。
よろしくお願いします。
よろしくお願いします。
以上で第5回目ですね、
ソルラジ置いていきたいと思います。
ありがとうございました。
ありがとうございました。
ありがとうございました。
