プログラミング言語はいろいろな種類があり、それぞれに文化があります。
特にスクラッチのプログラミングは、ブラウザの画面の中で全てが完結するようにできています（※）。
「スクラッチのプログラミングは、こういうものだ」
というスクラッチの流儀みたいなものを最初に理解しておくと後が楽です。
このページでは、そのことについて説明します。
※ただしマイクラミングではブラウザの他にマインクラフトも同時に使います。スクラッチの命令がブラウザから飛び出して、マインクラフトに届いて実行されるように、特別な拡張がされています。
スクラッチの画面構成
最初に、スクラッチの主な画面構成と呼び方を下図に示します。
- ツールバー ・・・ プログラムの保存や表示言語の切り替えなどをおこないます。
- ブロックパレット ・・・ 利用できる命令がカテゴリ別に整理されています。
- スクリプトエリア ・・・ プログラミングする場所です。
- ステージ ・・・ プログラミングの結果を見るところです。
- スプライトリスト ・・・ キャラクターを設定します。
- ステージリスト ・・・ 背景を設定します。
プログラミングのスタイル
スクラッチは、「ステージ」と呼ばれる舞台に、「背景」と「キャラクター」を設定して、それらを動かすためにプログラミングをします。
それに必要なすべての作業ができるように、上のような画面構成になっています。
次のように、もしも何かのキャラクターを追加したら、その都度、プログラムも追加していくようなスタイルです。
- 背景を用意したら、その背景用のプログラムもつくる
- キャラクターを用意したら、そのキャラクター用のプログラムもつくる
ただしスクラッチ用語では、次のように呼びます。
- スプライト ・・・ キャラクターのことです
- スクリプト ・・・ プログラムのことです。
- コード ・・・ これもプログラムのことです。
- ブロック ・・・ プログラムの部品（命令）のことです。
このほかに、音や音楽の設定もできます。
ブラウザ上の画面の中だけでプログラミングに必要なすべてが揃っている（※）。正にオールインワンのプログラミング環境。
それがスクラッチのプログラミングです。
※ただしマイクラミングではブラウザの他にマインクラフトも同時に使います。マインクラフトを操作するブロック（命令）が独自に追加されています。
スクラッチの主な作業
次に、スクラッチで行う具体的な作業について、もう少し細かく説明します。
ただその前に、どうしても「背景」「スプライト」「コスチューム」というキーワードを理解しておくことが必須です。
背景とスプライトとコスチューム
「コスチューム」という言葉の意味は、一般に「衣装」のこと、つまり「着せ替え」のことですね。
スクラッチでは、絵のバリエーションのことを言います。
背景もキャラクターも絵を組み合わせです。
そしてスクラッチでは、背景には背景のバリエーションを、スプライト（キャラクター）にはスプライトのバリエーションを用意する事ができます。
背景もスプライトも「絵」ですから、どちらのバリエーションのことも「コスチューム」と同じ言葉で呼びます。
それでは、なぜバリエーションが必要なのかを考えてみましょう。
例えば、１つのキャラクターを歩かせようとしましょう。すると、右足を出している絵と、左足を出している絵の、少なくとも２枚の絵を交互に表示させる必要があります。
このように、１つのキャラクターには複数の絵のバリエーションを用意して、それらを切り替えて使いたくなる時がよくあります。
そこで、スクラッチでは次のように言葉を整理しています。
- スプライト ・・・ キャラクターの絵のグループ名のこと
- コスチューム ・・・ キャラクターの絵のバリエーションのこと
同じように、背景もプログラムの進行で切り替えたい時があります。そのため背景にもバリエーションを用意できます。
- 背景 ・・・ 背景の絵のグループ名のこと
- コスチューム ・・・ 背景の絵のバリエーションのこと
つまり、スプライトのコスチュームを変えることは、まさにキャラクターの衣装を着せ替えるような感じですね。背景についても同じです。
スプライトや背景の着せ替えもプログラミングで指定します。
プログラミングの作業は大きく３種類
スクラッチは「背景」と「スプライト（キャラクター）」を配置して、それぞれにスクリプト（プログラム）を組み込むのでした。ですから次のような作業がメインになります。
- 背景やスプライトの絵を用意する（編集する）
- 用意した背景やスプライトを動かすためにプログラミングをする
- できたプログラムを実行させて確かめる
この様子を、画面の構成と対応づけて図示すると、下のようになります。
スプライトの種類だけスクリプトを作る
ステージには、複数のスプライト（キャラクター）を置いて、それらを同時に動かすこともできます。
例えば、猫と犬がケンカをするようなプログラムを作るとします。すると
- 猫のスプライトと猫のスクリプトを１セットをつくる
- 犬のスプライトと犬のスクリプトを１セットをつくる
という作業が発生します。
例えば、ケンカでケガをする様子をプログラムする場所は、およそ次のようになります。
- 猫のスクリプトには、犬の牙に当たったら猫の体力が減るようにプログラムする
- 犬のスクリプトには、猫の爪に当たったら犬の体力が減るようにプログラムする
この様に、それぞれのスプライトの役割に応じて、それぞれに独立にプログラミングをします。
こうすることで、猫と犬のプログラムが混ざりにくくなり、プログラミングが解りやすくなります。
（コラム）オブジェクト指向プログラミング
背景は背景のプログラム、猫は猫のプログラム、犬は犬のプログラム・・・
この様に、モノにはモノの役割に応じたプログラムを、モノ毎に独立してプログラミングする考え方を
「オブジェクト指向プログラミング」
と呼びます。もう少し正確に言うと、
「モノを情報と機能の集合体として、１まとまりにプログラミングすること」
がオブジェクト指向プログラミングです。
現代のプログラミング言語はオブジェクト指向プログラミングの考え方を取り入れているのが普通です。
昔は「手続き型」だった
これに対して、古くからあるプログラミングの考え方のことを
「手続き型のプログラミング」
と呼びます。これは、
「機能と情報を分けて考え、機能に情報を与えると、答えの情報が得られるようにプログラミングする」
「関数にインプットを与えると目的のアウトプットが得られるように、関数をプログラミングする」
という考え方です。
コンピューターは計算機から発展してきました。プログラムは計算の「型」を定義するのに使われました。そのため自然に
「高度な計算の集合」＝「機能」＝「関数」
「計算対象のデータ」＝「情報」＝「インプット」「アウトプット」
と分けて考えるようになりました。
これはこれで分かりやすいです。プログラマーは、どの情報がどの機能（関数）で、どのように扱われるべきかを、すべて把握しながらプログラムを組み立てる事ができるからです。
手続き型プログラミングの限界
しかし手続き型のプログラミングには欠点がありました。
プログラムの規模が大きくなると、情報と関数の関係を、すべて覚えきれなくなってしまうからです。
あるいは覚えきれたとしても、長いプログラムを理解するのに多くの時間がかかり過ぎるのです。
もしもプログラマーが病気で不在になったり交代したりした時に、新しいプログラマーが理解できなくて困ってしまいます。
これはプログラムに不具合があっても気が付きにくいことになります。
コンピューターが高性能になり、利用が多様になるほど、プログラムの規模もどんどん大きくなってきました。
しかしプログラムの規模が大きくなるにつれて、商品の品質を保てなくなる、そういう限界に当たりました。
ちなみに、現代のプログラムは、数十万行から数百万行の規模になることも、珍しくはありません。
私が技術者だった２０年前ですら、すでにプロジェクト全体で１００万行の開発規模を超えていました。
オブジェクト指向で限界を突破
そのため、情報を機能を分けて考えることを止め、セットにしてしまう発想が出てきました。
情報と機能をセットにしたものがオブジェクト（モノ）です。
これは人間が物事を理解する方法に近いので、プログラムも同じようにすると解りやすく、まとまりが良いことが分かりました。
こうして、現代のプログラミングは、オブジェクト指向が主流になりました。
本格的に学ぶならオブジェクト指向から理解すべき
もっとも、小さなプログラムでは「手続き型」と「オブジェクト指向」の区別がつかないことが多いです。手続き型プログラムの上に、オブジェクト指向プログラムが成り立ってきたからです。
逆に言えば、オブジェクト指向にすべきところを、手続き型で無理やり作ってしまうようなプログラムも可能です。
たまに、そういうプログラムを目にします。
特に年配の人が古い知識のままプログラミングを「知っている」という場合にありがちです。
動くので問題ありませんが、良くはありません。
小中学校におけるプログラミング教育は、「試行錯誤」で「最適解」を出して「問題解決」するようなカリキュラムの一環にするのが狙いです。人間が物事をどうに理解し、プログラムをそれにどれくらい近づけるのか、という本質的な議論までは、もちろんしません。取り組むプログラムの規模はとても小さいです。
ですから、仮にプログラミングが手続き型のスタイルに偏った指導になってしまっても、実害はないでしょう。
しかし、子供たちが大学生になって、研究室で大きなプログラミングをするかもしれません。あるいは本格的にプロを目指すかもしれません。
そういう可能性に悪影響を与えないように、指導する側も、できれば「オブジェクト指向」がどういうものか、軽く少し調べておかれると良いと思います。