はじめに
大学で 初心者 と経験者を対象にしたアプリ開発勉強会を行いました。プログラミングに抵抗を持つ人も対象として「挫折しないこと」を目標の一つにして行いましたので、工夫したところなどを共有したいと思います。
勉強会の内容は今後、 Qiita で記事化していく予定ですので、もしよければご覧ください。
概要
全体の方針 ：魔法のかかったプロジェクトを利用して高速開発
学びの入り口：「こんなの作ってみたくない？」
経験者向け ：答えブランチと発展的内容
学びの継続 ：まずは改良から
プレゼン資料：パラパラ漫画方式でPDF事前配布
全体の方針
実際にアプリを開発しながら Swift を使えるようになってもらえたらなと思っています。なので、勉強会は毎回何かしらのアプリを開発していることになります。
ここで大きな壁になるのが、 モチベーションの維持 です。ある程度プログラミング経験がある人にとって Hello world を表示するだけでは楽しいと思ってもらえない可能性があります。だからといって、高性能なアプリは難易度が高すぎて初心者がついてこれません。
そこで、 魔法のかかったプロジェクト というものを準備しました。
勉強会で初めて作成するアプリの完成版がこちらになります。
キャラクターと一緒に記念撮影ができるアプリです。原理的には、撮影とともにキャラクターを合成するというもので、 **アニメ好きな学生が多いだろう** という考えによるものです。
そこそこ実用的なこのアプリ、気になるのはコーディング量でしょう。
こちらが実際にコーディングが必要となる部分です。
行数としては **2行追加するだけで完結** するようになっています。 Storyboard 側では `UIButton` を1つ配置し、コードと紐付けるだけです。
仕組みとしては、カメラ撮影機能を記述した独自の ViewController を継承した ViewController からカメラの機能を呼び出すという単純なものです。簡単に言うと、汎用性の低いライブラリを使わせているような感じです。これが **魔法のかかったプロジェクト** と呼んでいたものです。
ちなみに、何もコーディングせずに起動させると上記画像のように、真っ白な画面が表示されるだけで、新規でアプリを作ったときと同じような挙動をするようになっています。
勉強会では、「カメラ機能を持った関数を呼び出しています」程度の説明をしながらも よく分からなくても「ふ〜ん」って思ってね！ と呼びかけました。解説しながら参加者の様子を見て回るとき、経験者に、2行追加で完成するカラクリと裏側を教えてあげると、まだ知らない実装方法に興味を持って調べ始める学生や独自の改良を施し始める学生もいました。
学ぶ内容は回数を重ねる毎に難しくなっていきますが、上記と同様の方法を繰り返します。
学びの入り口
次の課題に 自発的学習 をする習慣を作るというものがあります。
勉強会に参加して真似るだけではなく、学んだことを発展的なことにも活かしてほしいのですが、 勉強会に参加した ということだけに満足して行動に移せない人もいます。そこで、 興味を持ってもらう というところもこだわってみました。
先程のカメラアプリ完成後の発表スライドです。
好きなアニメキャラに変更するなど **どんな工夫をしてみたいか** を参加者に尋ねて **自分で考えて作り出す** きっかけを作ります。実際の発表スライドでは、上記スライドの前に「どんな工夫したい？」とだけ書かれたスライドがあります。初めから例を示さずに **考えさせる** ことも大切かもしれません。
想定していた改良案に関しては、スライドまで作成していました。上記スライドは、複数のキャラクターに対応させるためにボタンを3つに増やす方法を解説しているものです。
先程までは関数を呼ぶだけでしたが、ここでは Storyboard を使った制約の付け方を勉強します。このように、徐々に必要となってくることを学ぶという流れが **実際の開発** に近くていいのではないかと個人的に思っています。
経験者向け
魔法のかかったプロジェクト
これが、先程から紹介しているカメラアプリのリポジトリです。
（答えと問題のブランチ管理に納得ができていません…）
答えと問題を同時に公開して、経験者が授業スピードに満足できずに 離脱することを防止 しています。
その他にも、ソースコードをZIPなどで配布せずにGitHubで公開しているため、Gitの練習として利用してくれる学生もいました。
これは6回目の勉強会スライドの一部です。 Protocol について説明を行った後に、関連付けてクラスと構造体の違いを説明しています。
勉強会では「*こんな感じの違いがあります。また後で詳しく説明しますね*」と詳しく口頭では説明していません。
プレゼン資料の項目で説明しますが、プレゼン資料は事前に配布しています。なので、勉強会前・勉強会中でも経験者が暇だと感じてしまわないように多少難しめの内容を含めるようにしています。学校の教科書に コラム 、 発展 として紹介されているアレみたいな感じです。
学びの継続
勉強会では基本的に 宿題を出しません 。
宿題に追われるようなやり方では身につかないどころか、プログラミングを嫌いだと感じるきっかけにもなりかねないと考えたからです。
なので、 自発的学習 が必要になってくるのですが、ある程度慣れてきた段階であれば任意課題のような形式で問題を準備するといいと思います。大学の授業などでも取り入れている教授がいるかもしれませんね。
これは、初歩的内容ですが Refactoring に該当する問題の例です（答えのコードが表示されているスライド）。
途中まで、わざと（多少）非効率なコーディング例を示して解説を行い、実装が一段落した段階で改良案を提示するという方針です。賛否両論あるとは思いますが、 **Refactoring の本当の意味**を知ってもらうには非効率なコードを書くという経験も必要だという考えでこのような方針を選びました。
プレゼン資料
- 勉強会前日までに PDF でスライド資料を配布
- プレゼンソフトのアニメーションは使わない
- できるだけ文字は少なく
- 大きな画像でわかりやすく
上記がスライドを作る上で気をつけている点になります。
PDFで配布することを前提としているため、アニメーションを一切使わず、 パラパラ漫画方式 で作成しています。
これは、Xcode（IDE）を操作する方法を順に説明しているスライドの一部です。
画像だとわかりにくいので、文字で書くと以下のような構造になっています。
[ 番号表記による全体の手順 ]
[ 1つ目の手順詳細 ]
[ 番号表記による全体の手順 ]
[ 2つ目の手順詳細 ]
[ 番号表記による全体の手順 ]
[ 3つ目の手順詳細 ]
...
Xcodeの一部を拡大された画像をいきなり見せられても、初心者にはそれがどこにあるか分かりません。
そこで、最初のスライドで「ステップ1はここらへんを触るよ！」「ステップ2は...」...と表記しておくことで、今からどこらへんを操作するのかが一目瞭然になります。ちなみに、上記画像の次のスライドではステップ1の詳細説明を行います。最初のスライドでだいたいの場所が分かるので思う存分 拡大した画像や図 で説明ができます。
その他には、 セクションごとに背景の色を変化 させることで見返した時にまとまりがわかりやすくなります。
この方法で作成していると1回の勉強会で50ページを超えるということもあり、作る側の負担はかなり大きいように感じます。 こんな作り方する人もいるんだ〜 くらいの気持ちで考えていただければと思います。
最後に
様々な勉強会や、日頃の学校の授業など、様々なことを参考に試行錯誤しながら行っている勉強会になります。
勉強会の方法や考え方は様々だと思いますので、参考程度に考えていただければと思います。
最後まで読んでいただき、ありがとうございました。