Unity等DCCツールを大人数に教えるときの罠

栗坂こなべ_C99参加未定 @kurisaka_konabe

20人を超える人数に教えていると、作業手詰まり率とそのフォロー時間が爆上がりしてハンズオン形式だとまともな授業進行にならないことがわかってきた。そして一般的な学校が何故板書するだけ、アレやコレや習っていない方法を許さないかもわかってきた。そうでもしないと40人とか物理的に不可能。

栗坂こなべ_C99参加未定 @kurisaka_konabe

教えている時間の9割くらいは作業が詰まった人間のエラー対処とフォローで、殆どの生徒の時間が手待ち時間になる。そりゃ40人超の授業じゃ一方的な垂れ流ししか出来ない。回答方法や作業方法の自由度なんて認めてられない。

栗坂こなべ_C99参加未定 @kurisaka_konabe

内容がPC作業だと、マシンが固まったりソフトが落ちてイチからやり直しになったり、日本語入力がCapsロックやらIsertボタンを押しただの、何故そのファイルで作業を進めていた？だのありとあらゆる想定外のトラブルが起きて卍解に時間が掛かる。加えて先週休んでいたり遅刻してきたりしたら死ぬ。

栗坂こなべ_C99参加未定 @kurisaka_konabe

「エラーで動かない」というので見に行くと、作ったスクリプト名が prayer.cs でクラス名 class NewBehaviourScript になっている率が異常(.CSファイルを作った後にリネームした上にスペルが)。初心者はその発想はなかった…っというミスをいっぱいするので、教える側には想像力と相手の視点が必要。

栗坂こなべ_C99参加未定 @kurisaka_konabe

時間を掛けようと思えば幾らでも凝って時間を掛けることが出来る作業を与えて手待ち時間に退屈させないようにしないとスマホが立ち上がる。

栗坂こなべ_C99参加未定 @kurisaka_konabe

うん、今日は特にダメだった。想定の1/10くらいしか進んでいない。そもそもエラーが発生する原因は作業手順が間違っているからで、（続く

栗坂こなべ_C99参加未定 @kurisaka_konabe

続き)コードをプロジェクタに映したままだとこっちがUnityエディタ上での作業ができない→エディタに画面を移すと写経中の人間が詰む→「さっきのコードを映して！」→「ちょｗエディタ上での作業を映して！」→ちょっとでも躓いた人間は詰む

栗坂こなべ_C99参加未定 @kurisaka_konabe

これに対する理想解は「それを読むだけで完全に理解できる資料」を事前に作っておくことだが、労力的に現実味がない。っとなると既にが完成済みのweb上の講座(ドキュメントor動画)をやって貰うしかない。3～4人に教えていた自由度の高い方法を20人に適用させると死ぬ。

栗坂こなべ_C99参加未定 @kurisaka_konabe

写経したからといって書けるようになるわけでもないし、書く行為は捨てて改造に専念させるべきか。

栗坂こなべ_C99参加未定 @kurisaka_konabe

プログラムの授業、以下の文の○を埋めよ。これだ！『Unity は、世界○○のリアルタイム開発プラットフォームであるだけでなく、○○の実現を目的として設計された強固な○○システムでもあります。ビジョンの実現に必要なものを活用できるように、クリエイターの○○なコミュニティに参加し…』

栗坂こなべ_C99参加未定 @kurisaka_konabe

ハンズオン形式って全員漏れなくフォローする前提だと、1番遅いひとに合わせて他の全員は待つマラソンっぽい。これは単純な走力の差だけではなく、躓いて転ぶ、コース外に進んだランナーを回収しに行く、スタートから走り直し(作業データ喪失)とかも含む。遅刻欠席分も挽回する前提だと更に死ぬ。

栗坂こなべ_C99参加未定 @kurisaka_konabe

嗚呼嗚呼嗚呼…今日も同じ轍を踏んでしまった。コードを打ち込ませたら駄目だ。生徒用画面が2画面あるなら別やが…。VSのコードとUnityエディタを同時に表示できないのにこの通りに作業して付いて来いは無理ゲー。前回死ぬほど思い知った筈なのに…エラーのフォローで1/10も進まんかった。

栗坂こなべ_C99参加未定 @kurisaka_konabe

即興コーディング形式、実際の躓きとエラー対策が披露できてとてもいいんだけど、これを大人数向けハンズオンでやっちゃ駄目だ。特にここをやっぱこう書き直す！ってやったら完璧に付いて来ている人間以外全員死ぬ。やるなら観ているだけか少人数で。3,4人に教えるスタイルに慣れすぎた。

ザバイオーネ @z_zabaglione

トレーナー業を10年以上やっているけど、まさに20人ぐらいが品質を保てる限界です(事前にPCのセットアップをして準備万端で待ち構えていて、さらに予備PCで用意して)。それ以上になると面倒を見きれない人が出てきますね。 twitter.com/kurisaka_konab…

栗坂こなべ_C99参加未定 @kurisaka_konabe

@z_zabaglione もう、ホント9割くらいエラーのフォロー時間で、10分で済むような作業内容に数時間(1日分の授業)掛かって徒労感ハンパないです、他のプログラムの先生方はどうやって回してんでしょう…

ザバイオーネ @z_zabaglione

@kurisaka_konabe 人にもよるかもしれないですが自分の場合は、エラーが起きやすいところは事前にエラーをわざと起こす、原因の説明、対処方法の説明と実演を行う。 で、実作業で似たようなトラブルにハマっていたらその時の資料を見ながら一緒にやる。殆どの人はそれを2〜3回やると自力で直せるようになる

ザバイオーネ @z_zabaglione

@kurisaka_konabe 従って事前の準備が超大事。あと、短い時間にたくさんのことを教えたくなるけど、本質的なことをいくつか紹介したらあとは応用となる様なカリキュラムにしておく(新しい事ではなく、あくまでも応用)。なので、やはり準備が大事

ザバイオーネ @z_zabaglione

@kurisaka_konabe あとはリカバリー手段を沢山用意しておく。ようは1つの授業の中でいくつかのチェックポイントを用意しておいて、仮に行き詰まったり、訳が分からなくなった人が出ても、「これを開けば大丈夫」と言うものを用意しておく

栗坂こなべ_C99参加未定 @kurisaka_konabe

@z_zabaglione 貴重な知見をありがとございます。やはり事前準備と資料が大事ですよね…。中々用意できていなくて申し訳無さでいっぱいです。応用時間…なるほどです。

ザバイオーネ @z_zabaglione

@kurisaka_konabe コードに関しては分からなくならない程度に可能な限り入力文字数を減らすようにしていますね。あと一つのソースコードを書き換え続けるようなのは混乱の元なので、基本的にバラバラのクラスを作らせています。もし書き換えをさせるならコードの断片だけでは無く、常に全体が分かる様な物も用意してます

ザバイオーネ @z_zabaglione

@kurisaka_konabe 個人的には穴埋めって分かった気にさせる事は出来ますが、一瞬で忘れてしまうので、しつこいぐらい1から作らせてますね。それを何度もやる事で、どこを書き換えると良いかと言うのが分かってきます。その頃合いを見てから部分書き換えを支持でもいいかも

ザバイオーネ @z_zabaglione

@kurisaka_konabe 何の開発環境でもツールでも、初めて触る物って何をどうするとどう言う影響があるのかが全く分からないと思います。例に挙げていたNewMonoBehavior.csファイルにしても、それで何が悪いのか分かるように、一文字もコードを書かせずに具体的なエラーケースの例を示して受講生に試す時間を設けますね

栗坂こなべ_C99参加未定 @kurisaka_konabe

@z_zabaglione うっ…もうコードはこっちで打ち込み済のものを用意して、アタッチだけさせようかと思っていましたけど、悪手でしょうかやっぱ…。書くに越したことはないのですが…

ザバイオーネ @z_zabaglione

@kurisaka_konabe アタッチだけさせる場合は、 ・プログラムを覚えることがメインでは無く、インスペクターとの関係性を理解するのが主の場合 ・時間的に無理な場合 にやりますね。最初から最後まで貼り付けだと……

栗坂こなべ_C99参加未定 @kurisaka_konabe

@z_zabaglione 大半のエラーが結局単純な大文字小文字のスペルミス、未アタッチ、括弧数の不一致、書いているブロックが違う…とかなのがわかってきたので、2週目はもうちょい上手く立ち回れそうですが、1週目に不味い体験をさせてしまった彼らには申し訳ないです。