プログラミング教育の「プログラミング的思考」ってRDBのテーブル設計で学ぶのがいいんじゃないかな
こんなコンテンツをやっていまして。
『プログラミング少女』という、中学生のタレント4名がプログラミングを勉強する、というものです。
まだまだこれからではあるのですが、
けっこう最近まじめに、そもそもプログラミング教育ってなんなのか？
どうすべきなのか？ ってことを、勝手に考えたりしています。
いろいろお話を聞いて、
2020年度からの小学校でのプログラミング教育の実情としては以下のような感じなのかな、と思いました。誤解をおそれず書いてみます。
・先生はプログラムができる人はほとんどいないから結構こまってる
・なぜそんなに準備もできていないのに見切り発車するのか？
→学習指導要領は10年に一回くらいしか更新されない。今やらないと、10年後になっちゃうから、無理やりねじこんだ。
・学ぶのはコーディングではなく『プログラミング的思考』
→とでも言わないと、コーディングを教えることになり、教えられる先生がいない。だからこんな曖昧な言い方になったんじゃ......?
なんか大変そうです。
だからダメ、とか言いたいわけではないです。
今、現場の先生や教育委員会の方たちはフル回転で頑張っているのだと思います。
怒られないように言っておくと僕の父親も小学校の校長先生だったので、揶揄したい気持ちはまったくないです。
そんな感じで、端から見てても結構大変そうな感じですけど、プログラミング的思考ってなんじゃい。とは思いますよね。
困った時のリンクです。
文科省の元々の内容は、ちょっとややこしいので、これがわかりやすいなーと思います。ていうか他のブログとかでもこれ引用してる人も結構いたような。。
このページには、四要素がある、と書かれています。
・分解
・抽象化
・一般化
・組合せ
どれも、大切な要素だと思います。
でも、上記サイトにもその例が書いてあるんですが、結局この説明で子供、理解できる？ というと、僕はできないんじゃねーかなーと思います。
そこで、表題の主張なのですが、
このまえふと、プログラミング教育関係の打ち合わせ中に、自分で、「DBのテーブル定義ってすごいおもしろくて、そういうおもしろさに行き着かせることができたら......」みたいなことを言いまして、あ、そうだ、僕がプログラム的なものを一番最初に、「ああ〜〜〜おもしろい！」と思ったのは、テーブル定義だった、と思い出しました。
テーブル定義、っていうのが正式な呼称かは知らないのですが、要はデータベース（DB)の設計をすることです。おそらく非エンジニアの方とか、クライアントサイドしかやらない人にはちんぷんかんぷんだと思うのですが、データベース、僕らの世代だとそれはそのままRDBMS(リレーショナルデータベースマネジメントシステムのことだよ）のことを指しました。MySQLとかですね。
そういうものに、「どうやってデータを格納するか、取り出しやすくするか」の方法を決める方法のことです。
それの何がおもしろいの？ っていうと、この世のいろんな要素を、そのシステムに最適な方法で、わかりやすく整理をしないといけないんです。
「コンピューターにはわかりやすく教えてあげないとダメ」というのは、プログラミング教育でも、Appleの教育プラグラムでも言われることみたいです。
そしてこの作業がとても面白いのは、情報という要素=世界を、自分はどうまとめるか？ という作業だからです。
物事を分解して、抽象化して、一般化する。組合せの部分は、ぶっちゃけ何やってたって出てくる部分ですが、前述の要素が全部入っていると思うんです。
（ここからが、伝わるかどうかあまり自信がない部分）
で、いろいろ説明方法はあると思うのですが、僕は『ワンピース』でテーブル定義を考えると、多くのキッズがわかりやすいのではないか、と思いました。
『ワンピース パーフェクト情報サイト』みたいなのを作るとしましょう。
そうしたとき、DBはどんな整理をすべきか？
(以下、僕はめちゃくちゃワンピースに詳しいわけではないので、記憶と検索を頼りに記載していきます。また、『関係性』を示さない、たとえばキャラの説明とか、そういう要素はカットしていきます。本当はぜったい必要だと思いますけど）
その前に、そもそもデータベースのイメージが、非エンジニアの人にはイメージがつかないですよね。これは、『Excelの表』がたくさんあるものだと思っていただいてOKです。Excelも『シート』で分かれていて、複数の表を持ちますよね。
それと一緒です。このシートをデータベースでは『テーブル』と呼びます。
（エンティティっていってもいいけど、こっちのほうがわかりやすいですよね？）
テーブルっていうのは、こんな感じになります。
キャラのチョイスとかは気にしないでください。
※ちなみにこの表は誤りがあります。あえてです。
一番上の列は、各要素の名前で「属性」とか言います。
ルフィとかそういうのは「データ」でいいです。
『テーブル』というのは、DBのなかで、データを管理する単位です。
一つのテーブルは『属性』を持ちます。
たとえば、ワンピースだったら、キャラクター名で検索したい。その場合は、キャラクターテーブルに、『名前』という属性が必要です。
他の要素はなんでしょうか。
ルフィで考えると、ルフィは『モンキー・D・ルフィ』という名前です。
また、『ゴムゴムの実』という『悪魔の実』を食べています。
そして『麦わらの一味』の『船長』ですよね。
ゾロとかサンジとかナミ、ウソップのような『仲間』がいます。
さらに『ポートガス・D・エース』という義兄がいます。
エースのお父さんは『ゴールド・D・ロジャー』(これをネタバレ、という人はいないですよね....)。『家族関係』はワンピースで結構重要な要素なので、「血縁」も管理する必要もありそうです。
『D』というミドルネームには強い意味がありますが、他にミドルネームに強い意味があるキャラクターはいない（ですよね？ ていうか、他にミドルネームあるい人いますっけ.....)、これはキャラクター全般に必要ではなさそうですね。
ルフィは『覇王色の覇気』を使います。『覇気』の分類も必要そうです。
ここが問題ですが、すでにルフィは全種類の覇気を使えますので、先ほどの表だとおかしいことになりますよね。これがもう、誤りです。
ちょっと工夫しないとダメです。
おそらく掘り下げれば、もっともっと要素は増えていきますが、いったんここまでで考えてみます。
以上から、「キャラクター」テーブルに必要そうな要素を列挙してみると、
・id
・名前
・生年データ
・性別
こんなもんですかね...。Wikiを見るともっとありますがとりあえずこんな感じで。
（idって何？ってなりますよね。
これはDBの一番都合のいいものなのですが、「その要素を一意に特定する要素」です。まあ、id=identificationのそのままの意味ですけど)
で、『悪魔の実』はどこいった！って思いますよね。
でも、『悪魔の実』は名前などと同列に扱うと、困ったことが起きます。
名前は絶対キャラクターからうごかせない要素ですが、『悪魔の実』は、食べた人が死んだら、また世界のどこかに『実』が現れて、それを食べた人が新しい能力の所有者になります。『メラメラの実』と、エースとサボの関係ですね。
あと、黒ひげも白ひげから『グラグラの実』の能力を奪っています。
キャラクターテーブルで『悪魔の実』を管理してしまうと、
エースとサボ二人が『メラメラの実』という情報を持ち、
黒ひげと白ひげ二人が『グラグラの実』という情報を持ってしまう。
これは『一事実一箇所』というDB設計の大事なルール(正規化）に反してしまいます。
『メラメラの実』という文字情報が二箇所にあると、
・エースとサボの能力が同じなのか別なのかわかんなくなっちゃう
・誰にも所有されていない状態の『実』が表現できない
など、色々問題が起きます。
なので、『悪魔の実』テーブルは別に作ります。
テーブルの要素は、以下です。
・id
・名前
・系統
系統は『超人系』『自然系』とかそういうのです。
「手が伸びる」とかそういうのはデータでは表現不可能なので、外します。
前述の通り、『実』はキャラクターに所有される(食べられる）ので、この二つを結びつけます。
方法は二つあります。
1.キャラクターに「悪魔の実id」をという要素を持たせる
こうすれば、たとえば、悪魔の実テーブルのid=1がゴムゴムの実だとしたら、ルフィはこう書けます。
これで、『ゴムゴムの実』のという名前の文字情報は悪魔の実テーブルにだけ存在し、ルフィがその能力を持っている、ということを表現できました。
でも、これだと困ったことがおこります。黒ひげです。
『ヤミヤミの実』と『グラグラの実』、ふたつの『実』の能力を持っているので、この表だと表現できません。idが二つになってしまうからです。
なので、この場合は次の方法が適しています。
2.交差テーブルを作る
キャラクターと悪魔の実の間に、「悪魔の実所有」テーブルを作ります。
・id
・キャラクターid
・悪魔の実id
こうすれば、以下のようなデータで、「黒ひげが二つの能力を持っている」
ことを表現できます。
まずは悪魔の実テーブル。一旦今必要な情報を入れておきます。
次に、キャラクターテーブル。
そして、この二つを交差させる、悪魔の実所有テーブル。
id=1のルフィはid=1のゴムゴムの実を持っています。
id=2の黒ひげは、id=2とid=3の実を持っていることが表現できました。
ただ....「悪魔の実」の「系統」属性が、文字で書かれて、「超人系」が二回書かれてしまっています。これは一事実が複数箇所になっている。
だから、「悪魔の実系統」テーブルを作って、
こんな感じで管理しておくと、悪魔の実テーブルを以下のようにできます。
同じノリで、キャラクターテーブルの「性別」も、性別テーブルに分けたいですね。
キャラクターテーブルは以下のようになる。
ちなみに無言で放置している「生年データ」ですが、
ワンピースには暦はあるみたいですが、名言されていないため(Wikipedia情報）、
作品の時間から年齢をあらわせる数値を入れておけばいいと思います。
作品開始を0とするなら、ルフィの場合17と入れておけば、0+17)=17歳。
新世界編は２年後で2+17=19歳。と導出可能になります。
あとは、この交差テーブルと関連づけたい要素があります。
『技』です。エースとサボは同じメラメラの実の能力者ですが、使う技は完全には一致しません。
エースは『火拳』『炎帝』とか『鏡火炎』とかいろんな技を使いますが、
サボは『実』の力を使った技は、『火拳』と『「火炎」"竜王"』という技だけのようです。
タチが悪いのが、サボはさらに『竜の鉤爪』などの『実』が関係ない技も使います。じゃあどんなデータ構造にすればいいのか.....。
技テーブルを作ります。
・id
・名前
で、技使用者テーブルを作る。
・id
・キャラクターid
・技id
これで、エースとサボ、二人とも「火拳」が使えますね。
キャラクターテーブル
悪魔の実テーブル
技テーブル
技使用者テーブル
これで二人が火拳を使えることが表現できました。
ただ、ほとんどのキャラクターの技は、『実』との関連がありますが、
サボの技『竜爪拳』は、『実』が関係ありません。ゾロやサンジの技もそうですよね。
更にめんどくさいのが黒ひげで、どっちの『実』の技なのか、わかりやすくする必要もありそうです。
サボの技の「火炎」"竜王"は、「実」と自力(竜爪拳)の両方の力で繰り出す技です。
さあ、じゃあそれの説明のために.......
というふうにガンガンテーブルが増えていって、データを関連付けていくわけですが、今までの過程でも、分解、抽象化、一般化を繰り返しています。
そして、プログラムが理解しやすいデータ構造に変化させています。
プログラミング教育というものが、ある一方で、ツールを使うだけ、Scratchを使うだけ、みたいになろうとしているのも、違うと思います。これは数学が「何のために使うのかがわからない」勉強になったのと、あっさり同じ道を辿る危険性があるからです。
そして、もう一方で、あまりにも『創意』を求めすぎるのも、酷なのではないか。もちろん誰も見たことのないものを作れ！ と言ってるわけでもないでしょうが、創造性を求められて、それに応えられる子供、いや、応えられる人間って、どれくらいいるのでしょうか。僕はほとんどいないと思います。
できる人はできるし、できない人はできない。
それは足の遅い人に速く走れ、と言ってるのに等しい気がします。
無理なものは無理。努力すればいいじゃん！ って思うかもしれませんが、現実には足の遅い人は大抵ずっと遅いです。がんばって速くなる人なんて、ほとんどいないです。
前述の分解、抽象化、一般化、組合せという考え方は、とても素晴らしいものだと思います。それは「理解」の過程だからです。
だから、何かを作り出さなくてもいいんじゃないか？
自分の好きなもの、興味があるものを、徹底的に考え抜く、というだけで、
得られる視座というものはあるのではないか。
DB設計はそのために最適なんじゃないかなーと思ったりします。
だって「現実」のこと以外、というと違うかな、「必要」なこと以外考えないんだから。常に「意味」を考える作業だから、「何やってんだかよくわからん」ということになりにくいんじゃないかなーと。
そもそも『作る』が偉くなりすぎてる気もするんですよね。
僕が小学生だったら、『作れ作れ』って言われたら、「うるせえ！」と思っちゃいそうです。
ちょっと論点ぶれちゃってるかもですが、
好きなものを作る、じゃなくて、好きなものを能動的に考えぬく、っていうのもいいんじゃないかなと。
その考え方を、自分のプロジェクトに活かせるといいなぁ、と思いつつ、無駄に長いブログを終わろうと思います。
※ちなみに今回の設計は、あくまでゴリゴリに正規化してくとこうなるんじゃない、っていう話で、パフォーマンスとかあんまり考えていません。
そっからの最適化というのはまた別の話です。でも正規化って楽しい。頭が整理されていくようで。
※あと、いまいち伝わってないかもしれませんが、少なくとも僕はワンピースのDB設計を考える作業はめちゃ楽しかったです。
これを小学生にやれ、というのはちょっと難しいのかもしれませんが、とっかかりさえつかめば、紙だけでできるし、いいんじゃないかなぁ、と。
※ただ、DB設計もいいけど、やっぱ実際創意を育むのも当然大事だし、自分で作りたいものを見つけられることは本当にラッキーだと思います。
この記事が気に入ったらサポートをしてみませんか？