(2020/12/14 追記：お知らせ)
別のアドベントカレンダーに今度は教える側ではなく、大学でコンピュータ科学を学んだ学生視点での記事も書きました。よければ合わせてお読みください。
大学でコンピュータ科学を学びながら、個人でアプリやフロントを書き続けた結果得られたもの
0. はじめに
みなさんこんにちは。今年もついにこの季節がやってきましたね！
この記事はLife is Tech ! #1 Advent Calendarの7日目の記事になります。
とうようです。
Life is Tech !の中では主にiOS開発を中心に中高生のメンターや、カリキュラム作成、メンターの研修講師などをやっています。また大学ではコミュニケーション支援のUIを研究していて、個人でもいくつか開発やデザインの仕事をもらってたりしています。
最近ではオンライン劇場zaのバックエンド・フロントエンドエンジニアを担当したのでよければ登録してみてください☺️
その他個人の活動についてはこちらのサイトにまとめてあるので興味があれば見てください。
=== 切り取り線 ===
今回投稿する題材を考えようとなったとき、最初は研究などで頻繁に利用しているNext.jsのことを書こうかなと思ったのですが、僕自身メンター最後の年ということで思い切って技術的なことではなくプログラミング教育についてこの5年間で感じてきたことを書いていくのもエモいのではないかと思い、今回のテーマを選びました。
僕自身教職はとってませんし、教育学などを学んでるわけではないのでそういった学問的知識に基づくものではなく、あくまで自分がプログラミングを学んできた過程・教えてきた経験などを踏まえた経験則であるということは留意して読んでもらえればと思います。
1. なにから考えるか
まずアプリ開発を教えるということを考えたときにさまざまな観点があげられると思います。簡単に列挙すると
- プログラミングの基本的な考え方
- フレームワークの知識
- デザイン関連
- 企画
このようにかなりマルチにスキルが要求されるのがアプリ開発の教育です。
では、この観点を踏まえた上でどのように教えていくのがもっとも効果的なのでしょうか？
結論から言ってしまえばここに確実な正解はないと思っています。ただそれぞれの観点において最適だと考えることができる教育や学習の仕方はあるはずなので今回はこの各観点に関して僕なりのベストプラクティスを語っていければと思います。
2. 「企画」の教え方
順番は前後しますが、まずは「企画」についてです。
なぜここからいくかというと、僕自身の感覚として企画が一番「型」が存在する部分かなと感じているからです。
つまり言い換えると、企画はよく世間で語られているような考え方の型を教えて、あとはその分野に慣れている人と壁打ちするというのが一番無難な学びになるということです。
こればっかりはあまり工夫のしようがないというふうに感じています。もちろんその「型」の部分をいろんなインプットをしながらブラッシュアップしていくというのは教育する側でコントロールできる部分かもしれませんが、純粋なアイデア力でいくとフレームワークで一気に伸びる人もいれば、フレームワークなどなくても湯水のように面白いことを考えつく人種も中にはいるわけでなかなかコントロールが難しい部分であると思います。
というわけでここは投げやり感もありますが、とにかくいろんな「型」をインプットしておこう、というのがベストプラクティスです。というか多分僕が語るより世間に広まってるアイデア本とかそういうのを読むほうがいいと思うのであとは割愛します。
3. 「デザイン」の教え方
つづいて「デザイン」についてです。
デザイン、と一言で言ってもその分野は多岐に渡るのでこの章ではビジュアルデザインに絞って説明します。UI/UXデザインに関してはフレームワークと共通する部分が多いので次の章を見てください。
ビジュアルデザインを教える、と言っても美大で教えられるような美術的センスを問われるものを教えるのは当然一般人にはできません。そのためここで言う「デザイン」で肝心なのはいかに**「それっぽさ」を身につけてもらうか**というところになります。
ではそれをいかに身につけてもらえばいいのでしょうか？
単純な表層のデザインに関して言えばこれはものすごく単純で
- デザインの四原則（整列・近接・反復・対比）
- いい感じの配色ルール
- 雰囲気を決めるためのトンマナ
の三点を意識してもらう、これにつきます。
まずデザインの四原則ですが、これは名著「ノンデザイナーズ・デザインブック」にも書かれているものです。詳細は記事の本筋と外れてしまうので省きますが、まずは**これを守れるようになるとレイアウトの質がぐっと上がります。**ぜひ最低限意識してもらえるようにしましょう。
また、いい感じの配色ルールはなにも自分でそれを作れるようになろうというわけではなく、これを使えばいい感じになるよというリファレンスを示してあげるのがいいと思います。たとえばMeterial UI Colorsといったサイトであれば、マテリアルカラーやフラットカラーなど有名所の色を一覧でき、カラーコードやrgb値などをワンクリックするだけでコピーできます。
Color Huntのようなサイトもベースカラーやメインカラーなどの組み合わせを探すことができるのでおすすめです。
最後のトンマナは考え方の部分で、雑に言い換えると最初にしっかりどういう雰囲気にしたいかを決めさせてあげましょうという意味です。
それによって色を配色リファレンスから選んでみたり、写真やイラスト素材なんかを選んだりというふうに進んでいけば自然といいデザインになると思います。
その意味では教える側はいいフリー素材のあるサイトもいくつか知っておくといいかもしれませんね。
以上まとめると表層のデザインを教えるベストプラクティスは最低限従うべきルールを教える、というところでしょうか。もちろんここにモチベーションが高い人にはイラレなどのデザインツールの使い方などを教えてあげるのもよいですが一般的には最低限でいいと思います。
4. 「フレームワーク」の教え方
次にフレームワークの知識について考えてみましょう。
これに関してはすべての詳細を覚えていられる、ということはないと思うのでいかに「こういうことならできそうだ」という感覚を増やして自分で調べながら書いていけるようになることが重要かなと思います。
この過程で実は先程後回しにしていたUI/UXデザインの力と同時に身につける方法があります。
それが学んでいるフレームワークでできる完成品をたくさん触ってみる、という方法です。
最近話題になったオブジェクト指向UI本にも書かれていますが、いいUI/UXの究極系はユーザーが椅子やテーブルなど現実のオブジェクトを扱うのと同じ温度感でデジタルプロダクトを自然に操作していけるというものです。この「自然に」という部分には「慣れ」が関わってきます。「こういうパーツを操作したらこうなる」「この時はこうすればいい」といったようなことをユーザーが説明なしに見ただけで分かるようになるのが理想系なわけです。
これも雑な言い換えにはなりますが、つまりいいUI/UXデザインをつくることにはフレームワークで提供されている機能を一般的かつ正しいかたちで利用できるという能力が必要になってきます。これはまさにフレームワークの知識ということになります。
ですのでそういった正しい使い方を学ぶためにもたくさん完成品をさわってあげる、さらに一歩進んで「ここではこういうものがこう使われているな」と自分なりに言語化できることがフレームワークやUI/UXの力を養う手っ取り早い方法なのです。だからぜひ教える側としてはその機会をつくってあげて、かつ「ここはどういうふうに作ってるの？」という疑問に対して本人が検索して詳細を知れる程度に答えられるということが重要かと思います。
5. 「プログラミング基礎」の教え方
最後に考えていくのはプログラミングの基本的な考え方をどう教えるのか、に関してです。
これを考えるためにざっくり自分のプログラミングを身につけた時のことを振り返ってみます。
僕自身がプログラミングを学んだ過程を整理すると以下のような段階に分けられます（挫折など詳細は一旦省いてます）
- 本を読みながら基本概念を自分の中でイメージする、理解しようとするフェーズ
- 実際に実行してみてなんとなくの役割を認識できたフェーズ
- 競技プログラミングに取り組むことでなんでこの文法が必要かなどを理解したフェーズ
- アプリ開発などを通してクラスやメソッドなどの抽象化の恩恵を感じたフェーズ
僕の場合はほとんどの過程を独学でやっていたのであまりこの部分に誰かから教えられてというようなところがないですし、特に最初のフェーズにはかなりの時間を費やしていますが、そのおかげでかなり自由にプログラミング的思考の部分は扱えるようになっています。
ここから**プログラミングを理解するのに必要な要素は「各文法のイメージと必要性の理解」**と分析できます。
ではこれをどのように教えるのがよいのでしょうか？
まずイメージに関してですが、これは**本人の思考に対する努力なしで教えるのはかなり困難だという感触があります。**もちろんこちらから自分なりに「こうイメージしてみると」と言ってみたり、教えられる側の属性を考えてそれに最適なイメージを構築するといったような工夫は可能ですが、単純にそれをインプットされただけでは定着せずに終わってしまうことが多いです。
そのためもちろん上のようなイメージのインプットはしつつ、本人の頭で本人なりのイメージを構築するというアウトプットが必要になってくると思います。
続いて必要性の理解ですが、これは小さいプログラムをたくさん書いていくというのが理解への近道かなと思います。その意味で競技プログラミングはかなり有用でしょう。また競技プログラミングだけだとどうしてもクラスなどの必要性が見えにくくなってしまうので実際にアプリをつくってみるというのも大事になってくると思います。
つまりまとめると、プログラミングの基本的な考え方を教えるためのベストプラクティスは、**「イメージをインプットしたあと、自分なりに言語化させながらそれにフィードバックも返しつつ、最適なレベル感の課題を投げ続けていく」**というものが考えられると思います。
これがある意味もっとも難しく、そして今後にとって大切なため最後に持ってきました。正しい考え方を教えるだけであれば有用な教材や、Web記事は世の中に山程あります。でもそういった記事を読んで真の意味で理解するには、本人が絶対学びたいというモチベーションが必要です。
そしてプログラミングのトレンドは凄まじいスピードで移り変わっていきます。
だからこそ、特にプログラミングにおいてはまず教える側がそのスピードに取り残されないぐらい強固な基礎力、基礎のイメージを持っておくことが大事になってくるのだと思います。
6. まとめ
以上、企画・デザイン・フレームワーク・プログラミングの四観点について個人的なベストプラクティスをまとめてみましたがいかがだったでしょうか？
自分が学ぶ際にも大事になってくる観点だと思うのでぜひ学習の参考にもしてみてください。
2022年からいよいよ中学・高校でもプログラミングの教育が本格化しますが、以上のことを踏まえると大事なことはいかに生徒に考える余地を残してあげるか、というところだと思います。
もちろん正しい考え方、のようなものはあるわけですが、それをひたすらインプットしても状況が変わった時に対応できず、ただ「そのフレームワーク/言語が使えるようになった」で終わってしまう可能性が高いという感覚があります。ですのでそれよりも本人が自分自身でプログラミングなど全般に関しての基本的な考え方のイメージが持てている、ということがより重要です。これこそが学習指導要領などに出てくる「プログラミング的思考」というワードの本質かなと思います。
この論は決して、じゃあ放任すればいい、ということを言っているのではありません。むしろもっと大変なことが必要になってくると考えていて、それはもし学習者が間違った考え方をしてしまっている時、適切なかたちで軌道修正してあげることです。
正しい考え方をそこで伝えるのは簡単ですが、その伝え方を誤ってしまった場合、学習者に*「プログラミングって難しいんだな、いやだな」*という印象を植え付けてしまいます。それは結果的にいままでの「数学嫌い」と同じような「プログラミング嫌い」を生み出してしまう可能性があります。
だからこそ教える側は今一度、自分が正しいプログラミング的思考を身につけているかを再確認し、学習者の間違ったイメージを学習者のモチベを保ったままさりげなく、そして本人の力で軌道修正させるようにヒントを出していくような、そういったスキルを身につけていく必要があると思います。
最後にかなり大変なことを書いてしまいましたが、ある意味そのぐらいプログラミング教育は難しいものだと思っています。ただ、直前に「正しい・間違った」というワードをつかってしまいましたが、一方で多様な認識の仕方、イメージの仕方があるのもプログラミングの良い点だと思っています。
ぜひ教育の仕方も含めて、みんなで試行錯誤を重ねながら、プログラミング、アプリ開発、ITでのものづくりを楽しんでいきましょう。
明日はマイクラメンターのマッ缶が企画に関して書いてくれるそうです。
ぜひあわせて読んでみてください☺️
illustrated by unDraw