新型コロナウィルスのせいで本業(人工知能系)が暇になったので、4月末くらいから小学6年生を対象にZoomでボランティア授業をするようになりました。しかしZoomのミーティング連絡をLINEだけでやろうとすると問題点がいろいろあり、それを解決するために家庭学習マッチングサービスを作りました。
利用したのはAWSのCloudfrontでサーバレスで、「苦労した」と書いていますが私が経験ゼロだったからかも？どちらかというと話題はコロナ禍での小学校の現状やサービスの要件、そしてサービスデザインや設計にどう落とし込んだか？などがメインとなります。
追記：おかげさまで作成したサービス「ZMLINK」はZoom公式アプリとなり、Zoomのマーケットプレイスの教育カテゴリで公開されています。
サマリー
・学校閉鎖下の子供たちの現状
・Zoomを家庭学習で使う上での問題点
・問題の解決とサービスのデザイン
・これってヤフオクじゃん
・Webサービス立ち上げに必要な作業
・苦労した点と今後の課題
学校閉鎖下の子供たちの現状
子供たちは4月の入学式から学校に行けてないです。塾もお休みです(東京は6月1日から再開可能になりました)。
先進的な塾や私学はGoogleのClassroomやZoomでの双方向授業を取り入れたり、あるいは公立小学校でも宿題を配布するためのポータルサイト利用が始まったところもありますが、5月は夏休みも同然でした。
特に休みになった小学生にモチベーションがあるわけでもなく、話を聞くと「ずっとゲームしている」「昼まで寝ている」という子供が多いようです。本来なら新学年の新しい友達と楽しいことしているはずなのに、可哀そうだなーと思ってました。
そこで見かねた私の奥さんとママ友が、まずZoomを使ってボランティア授業を始めました。LINEでグループ作って、ミーティングIDをやり取りしたり、スケジュールを決めたり。そうしているうちに教職免許(小学校・中学数学)を大学時代に取った私に話が来て、週に2回くらい算数を教えることになりました。
自分で教えてみた分かったのが、子供たちの学力格差です。塾に通ってる・通ってない、親が生活を管理している(勉強させている)・させてない(ゲーム三昧)、自分に危機感がある(中学受験予定)・ない(普通の6年生)で、ものすごい差がついてました。
私が教えているのは同じ公立の小学校に通う子供たちですが、幸いにもその小学校は割と早くから「まなびポケット」というプラットフォームサービスで宿題をガンガン出してましたが、自治体によってはIT利用なしの放置状態もあるようです。同じ日本と思えないくらい格差凄すぎ！
なお6月からの学校再開は自治体によっても違うようですが、ウチでは2グループにわけた分散登校になります。6月の2週目からは給食も再開されるみたいだけど、週の半分は不登校になるし小学校でクラスターが発生したらまた登校禁止になるかもしれないです。学校再開＝授業の正常化ではない、ということですね。
Zoomを家庭学習で使う上での問題点
Zoomは一時セキュリティの甘さで有名になった無料でも使えるリモート会議アプリです。便利ですよね。私も仕事の打ち合わせに使ったことはありますが、メールアドレスを知らない人たち10人以上を相手にZoom会議したのはこれが初めてでした。それで早速ですが、問題点は以下の通りです。
・事前にミーティングIDとパスワードをやり取りする必要がある
・Zoom荒らしが怖いので、ミーティングIDとパスワードは内密にやり取りしたい
・(先生側)誰が何人参加するか事前に分からない
・(生徒側)どんな授業か事前に分からない
・(先生側)急な用事でZoomミーティングを中止・時間変更したいときに連絡が大変
・(生徒側)Zoomミーティングのスケジュール管理ができない
最初にZoomのシステムをざっと説明しますと、まず主催者(先生役)がZoom上でミーティングをスケジュールして、開催日時とミーティングID・パスワードを決めます。それらを生徒に連絡して、ミーティングの時間になったらミーティングIDとパスワードを入力して参加するわけです。ミーティング主催者は参加者を一人一人許可しますが、人数が多いと「全員を許可」とかになります。
いっとき話題になった「Zoom荒らし」というのは、ミーティングIDが数字11桁なのでランダムに打ち込んで、パスワード設定していないミーティングに乱入し、暴言を吐きまくったりエロ画像を出したりする…という嫌なヤツですね。参加者は匿名なので身バレもしません。ただ最近はパスワードが必須になったので、ランダム突撃のZoom荒らしもなくなったかも？
話を戻すと安全なミーティングのためには、開催日時とミーティングID・パスワードは関係者だけで内密にやり取りする必要があります。参加希望者を増やしたいからと言って、ツイッターとかで公開するとZoom荒らしを呼び込んでしまいます。ウチではLINEでグループ作って、その中でやり取りしてます。ただ「え、そんなことやってるの？」「うちの子にも授業受けさせたい」と言われた場合に、まずLINEのIDをやり取りしてグループに入ってもらい、「Zoomとは？」を毎回教えて…と、SNS興味ない派の私にはハードルが高いです(実際には奥さんにお任せ)。
実際、私の算数の授業では10人くらいが参加していますが（登録者はもっと多い）、息子が通う小学校では6年生は2クラスあるので60人くらい。参加率は20%以下ですが、これ以上増やすとLINEで管理するのには限界がありそうです。
次は運用系の問題になります。
・(先生側)誰が何人参加するか事前に分からない
Zoomは無料アカウントでも100人まで同時接続できますが、普通はボランティア先生に100名のZoom生徒の対応なんて難しいですよね。個人的には「知っている子供で15人」「知らない子供相手なら10人」「子供のレベル差がひどいと5人」くらいが同時に相手できる限界かな？と思います。
よって参加人数をある程度開催者側でコントロールしたいのですが、Zoomでは「ミーティングIDとパスワード送る相手を制限してコントロールしてね」という感じなので、「このミーティングは何人」と規定することはできません。特に不特定多数相手に「1対1の個人授業でみっちり教えます」という募集はできないわけです。
・(生徒側)どんな授業か事前に分からない
基本的には「誰がどんな授業をするか」は生徒側には分かりません。Zoomにはタイトルは登録できますが、それだけです。授業のレベルや事前に準備するもの・宿題のあるなしなどは、LINEなどで別途展開する必要があります。面倒ですね。
また子供たちにとっては「どんな先生か？」がとても重要です。小学校6年生は知らない人には基本的にシャイです。私は子供たちが地元の保育園から公立の小学校にそのまま進んだので、保育園時代から薄ーく続けてきたお迎えや行事参加などで「あの人はよっしーパパだ」という認識が子供たちや保護者にあるため、子供たちにとっては全く知らない人ではないですが、それでも子供たちにとっては「ちょっと知ってる大人」くらいの扱いでハードルが高いです。
・(先生側)急な用事でZoomミーティングを中止・時間変更したいときに連絡が大変
これは大変です。授業を予定していたのに急に呼び出しがあったり、自分の子供が体調不良になることもあるからです。開催時間が近いほど修羅場になり、とりあえず中止の連絡をLINEで入れて、メッセージを読んでくれない保護者の人から「今日の授業はどうなってるの？」という質問に対応したり、振替日を設定したり。
ミーティングに紐づけて、中止した場合のメッセージ表示くらいはやりたいところです。
・(生徒側)Zoomミーティングのスケジュール管理ができない
生徒は基本的には直接LINEには参加していないので、親から「明日は9時からよっしーパパの算数よ」とか教えてもらうだけです。そしてすぐに予定を忘れるので、手書きでカレンダーにメモしたりして大変です。
この問題は受講者である生徒自身がLINEには参加していないため、直接予定の管理ができないことです。小学生にはLINE使わせたくないので仕方ないですよね。しかも親からもらったミーティングIDやパスワードのメモを忘れてしまったり、別のミーティングIDを間違えて入力して「誰も来ない！始まらない！」とかのパニックメッセージがLINEを駆け回ることになります。3人も間違えちゃうと、対応が大変です。
これらの問題をサクッと解決する必要があるな、と思ってWEBサービス「ZMLINK」というのを作りました。不慣れなので「サクッと」はいかず、1か月くらいかかったけど。どのようにWEBサービスをデザインしてこれらの問題を解決したか、次項で述べます。
問題点の解決とサービスのデザイン
問題を解決するために、最低限必要な要件は以下の通りです。
・サインインが必要なサービスとする。
・授業の内容を事前に確認できる。
・どんな先生が授業をするか確認できる。
・その先生がどんな授業をするか、一覧を見ることができる。
・小学生が自分で登録されている授業を検索して予約できる
・予約した授業は利用者がキャンセルできる
・自分が予約した授業の一覧がみれる。
・特に本日開催される授業や開催間近な授業は分かりやすく表示する。
・簡単にZoomを起動してミーティングに参加できる。
またボランティアの先生側にとっては
・自己紹介やどんな授業をするかアピールできるページを作る
・簡単に授業(ここではレクチャーと呼びます)を登録できる。その際、対象学年や教科を設定できる。
・レクチャーごとに定員を設定できる。予約した人が定員に達すると、それ以上予約できない
・予約した生徒にだけミーティングIDとパスワードを知らせる
・登録したレクチャーは中止にできる。その際、中止メッセージを記載して予約者に連絡できる。
・中止したレクチャーを別日で再開できる。
などですね。ちなみに私の中学3年生の娘は、「これなら私もできるかも？」と小学6年生相手に何度が授業してくれました。また他のママさんが「よっしーパパはどんな授業をするの？」と見学で参加することもあります。つまり
・生徒と先生を厳密に分けず、レクチャーを予約したり(生徒側)登録出来たり(先生側)できるようにする。
も必要になります。要件が結構複雑ですね。
自分の経験から、こういうサービスは「すでにある使いやすいサービス」を参考にすることが重要です。
そして思いつきました。「これってヤフオクじゃん」と。
これってヤフオクじゃん
ヤフオク、つまりヤフーオークションではサインインした利用者がモノを売ったり買ったりできます。私も好きでよく利用します。最近はアプリも使いやすくなりましたね。
ヤフオクでは商品は1つしかないレアものや不用品がほとんどですが、私は次のように考えて今回のZoom授業の要件を既存サービスであるヤフオクに落とし込み、使いやすいサービスデザインをパクれる、参考にできると思いました。
イメージとしてはヤフオクにコンサートチケットを10枚、価格0円の即決で出品するようなものですね。ヤフオク知らない人は、売ったり買ったりのフリマサイトの一種だと思ってください。
商品＝Zooｍミーティングの参加情報(開催日時、ミーティングID・パスワード)
商品数＝定員
商品価格＝0円
出品者＝授業をする人
買う人＝授業を受ける人
商品の検索＝レクチャーの検索
出品者のその他のオークション＝先生が登録している他のレクチャー
即決で購入＝レクチャーを予約する
ウォッチリストに登録＝レクチャーを予約する
ウォッチリスト＝やることリスト
商品が届く＝レクチャーに参加する
返品＝生徒が予約したレクチャーをキャンセルする
出品の中止＝先生がレクチャーをキャンセルする
となります。
今回は時間と予算がなかったため購入前の質問や出品者の評価、取引メッセージなどは実装しませんでした。またヤフオクに例えてますが、無料サービスのため予約そのものや月額会費とかのシステムもありません。でもまあ、やろうと思えばすぐできますね。レクチャーの有料化とか。
すでにサービス「ZMLINK」は立ち上げており、どなたでも無料で利用できますのでご興味があれば使ってみてください。システムの流れが分かります。ボランティア授業も登録しており、少なくとも6月中はボランティア授業を続ける予定なので見学も歓迎です。
生徒側UIデザイン
ユーザーは小学生を想定しているので機能はシンプルに、分かりやすく・使いやすくなるようUIをデザインしました。機能も多くないので、どんなふうにUIをデザインしたか簡単に説明します。
・モードを分ける
「生徒モード」「先生モード」に分けました。モードの切り替えは画面上部のタブで行います。生徒モードではレクチャーの検索と予約ができて、先生モードではレクチャーの登録と管理(中止や変更)ができるようにしました。
・最初の画面は「やることリスト」
サインイン直後のメイン画面には生徒モードでは予約済のレクチャーのリストを出して、先生モードでは開催予定のレクチャーのリストを出しています。ようするに「やることリスト」ですね(ヤフオクで例えると、ウォッチリスト)。
レクチャーは「本日開催」とか「もうすぐ」とか、開催時刻が迫ると表示を変更します。また先生がキャンセルしたレクチャーは「中止」と表示されます。
・レクチャーの検索
レクチャーは学年・教科・開催日・先生の名前で検索できます。
時間帯で検索したいとか、先生名は部分検索したいとか実装できていない機能もあるので、それは今後の課題ですね。
特に時間帯については、学校の部分再開や子供の生活習慣という観点で、「月水金の9時がいい」「火木土の16時がいい」みたいな要望があるかもしれない。あと定期開催のレクチャーにも対応していないですね。
・レクチャーの説明
検索したレクチャーには対象学年や教科のほか、タイトル・概要・内容・開催日時が書いてあります。
先生のプロフィールページへのリンクもあり、誰が教えてくれるか分かります。
また他に予約した生徒の人数やニックネームが並んでいて、誰が参加するかも分かります。
これを見て、生徒は「このレクチャーを予約する」ボタンを押すわけです。
なおレクチャーには定員が設定されており、予約数が定員に達するとそれ以上予約できません。
・予約したレクチャーとZoomミーティングの参加
予約したレクチャーには同じ画面にZoomミーティングの情報(リンクやミーティングID・パスワード)が表示されます。「サインインして予約した人だけにZoomミーティングのID・PW」を教える、ということでZoom荒らしを防いでいるわけです。
レクチャーの開催時刻になったら、Zoomリンクをタップすればミーティングの待機室につながります。先生がZoomに入ってくれば、レクチャー開始となります。ミーティングIDとパスワードは、Zoomリンクをタップできる生徒は使いません。ZMLINKを使っていない別の端末でやることになった時などに対応できるよう表示しています。
先生側UIデザイン
授業開催予定
最初のページは生徒側と同じく一種の「やることリスト」で、授業(レクチャー)の開催予定を表示します。割り切って、過去に実施されたレクチャーは表示されません。当日のレクチャーも開催時刻を過ぎると表示されなくなります。これはZoomのミーティングでは人数が多くなると参加許可を出すのが面倒になるため、ZMLINKでは「遅刻厳禁」としているからです。
マイページ
生徒側と共通ですが自己紹介を記載したりと映像リンクを貼り付けたりします。
自己紹介は「どんな先生か？」を説明するもので、生徒が見ることができます。映像リンクは過去のZoomでの授業をムービーにして、YouTubeにアップしたURLなどを貼り付けます。Zoomにはレコーディングという機能があり、ミーティングを開催者が録画できます。便利ですね。
レクチャーの登録
レクチャーを登録する際、開催日時のほか学年・教科を設定できます。また生徒の定員を1,5,10 (デフォルト値),20,50,100で設定できます。Zoomは無料のアカウントで40分・100人まで、有料だと時間制限なし・1000人までミーティングを開催できますが、ここでは無料アカウントに合わせています。
個人的な感覚では、小学6年生では10人くらいを30分のレクチャー2コマが適切かな？と思っています。前半30分で説明して最後に宿題を出し、15分休憩で宿題をやってもらい後半30分で答え合わせと解説--というのが私(よっしーパパ)のスタイルです。
レクチャーの登録ではZoomの情報(ミーティングIDやパスワード)も登録します。現状はZoomで登録したものをコピペして貼り付ける原始的な方法ですが、そのうちZoomAPIを使ってこのサービス(ZMLINK)からミーティングのスケジュールができるようになる予定です。
レクチャーの管理
登録したレクチャーは「レクチャーの詳細」ページから内容を一部変更したり、やむを得ない時は中止することもできます。中止する際はメッセージを登録できるので、「体調不良のため15日にやります」などを生徒に連絡することができます。また予約してくれた生徒の自己紹介一覧が表示できるので、どんな生徒が何人参加するか事前に知ることができます。ただし小学6年生男子の自己紹介に何かを期待してはいけません(笑)。
Zoomでの授業
授業(レクチャー)の開始は、メインページの「授業開催予定」から「もうすぐ」になっている登録レクチャーのページを開き、Zoomリンクをタップして始めます。ZoomはPC版とスマホ版がありますが、PC版の方がダントツに使いやすいので先生はできたらPC版を使ってほしいです。特に板書とかする場合は。
私(ZMLINKでのニックネームは『よっしーパパ』）は、WindowsのノートパソコンにWEBカメラを1台つないで使っています。自分の顔はノートパソコン付属のカメラで、板書はWEBカメラをWindows標準アプリの「カメラ」で映し、「カメラ」をZoomの画面共有で生徒たちに見せています。授業の様子はこんな感じです。
Webサービス立ち上げに必要な作業
WEBサービスを新しく立ち上げるには、やらなきゃいけない作業が色々あります。
私はディープラーニングではいろいろ慣れているつもりでしたが、WEBサービスの立ち上げは全くやったことがなかったので、大変ストレスを感じました。
最初にやったのは、以下の項目です。
・ドメイン取得
・サーバの契約
・サイトのhttps化
・取得ドメインでのメールの送受信
・認証(サインイン)とパスワード忘れたときの自動対応
ドメイン取得
ドメインはJPドメインを取りました。欲しいドメインがそれしか空いてなかったからです。
昔と違って、短いドメインや分かりやすいドメインは「プレミアムドメイン」とかいって、取得に数十万円かかるんですな。ビックリです。今回は安かったので、ムームードメインを利用しました。JPドメインが2253円(税込)でした。お名前.comは2800円＋税なので、迷わずムームードメインで取得。AWSでサービス始めること考えるとRoute 53でドメイン取った方がちょっと楽だったかもしれない。
サーバの契約
「サーバの契約」と書くだけで不慣れさ爆発ですが、要するにどこのサービスを使うか？ということですね。私は実質的にこの種の開発能力がないので、外部の人にプランにングをお願いして、最終的にAWSのCloudFrontとS3を使うことになりました。「サーバレスでインスタンス不要」「静的なHTMLでサービス展開できる」というのが主な理由ですが、クラウドと言えばインスタンス借りてsmallだと月額5000円でmediumだと8000円＋ロードバランサー代かなぁ？とかの知識しかなかったので、「インスタンス立てなくて本当にサービスできるの？」「S3ってアクセスが遅いストレージサービスじゃないの？大量データ置くときにしか使わないのでは？」「ロードバランサーはどうするの？」とか分からないことだらけでした。
具体的にはAWSのS3で新しくバケットを作って、静的ウェブサイトホスティングとして外部公開しました。ムームードメインで取ったドメインはRoute 53で設定し、以下のページを参考にしました。幸いにして自分が今やろうとしていることは珍しいことではないらしく、参考ページが複数あるので助かりました。
ムームードメインで取得した独自ドメインをAmazon S3に適用する手順
サイトのhttps化
普通に公開したサイトはhttp～となり、今どきのブラウザでは「なりすましサイト」扱いです。超面倒ですが、やるしかありません。前はSSLの証明書を取るのに何万円もかかってましたが、今はSSL証明書だけなら無料でできます。
今回はAWS Certificate Manager(ACM)を使いました。参考にしたのはこの記事です。
AWSでhttps化
AWS：無料でSSL証明書を取得する方法
なお証明書の申し込みをすると「本当にこのドメイン持ってるの？」という確認をする必要があります。対応はDNS情報の変更(Route 53なら便利？)か、サイト宛メール(admin@～, webmaster@～とか管理者が使いそうなメアド宛)に書いてあるリンクを踏む--の2通り。DNS情報が編集できるなら簡単(Route 53なら便利？）らしいけど、設定間違えて解決に何日もかかったような記事を見ちゃって断念。メールで受信することにしたけど、ここで大きな問題が。実はドメイン登録しただけで、メール受信のサービスはまだ申し込んでいなかったのです。
ムームードメインは有料のメールサービスがあるけど、DNSがムームー管理でないとダメらしい。
そこで独自ドメインでメール受信できるよう泣く泣くSESを設定したのですが、なんと記事をよく見るとWhois情報に登録されたメアドにも送ってくれてます。変なメールが届いていたのでようやく気付きましたが後の祭り。
取得ドメインでのメールの送受信
これが一番大変でした。そもそもムームードメインで取得したドメインメールサービスやホスティングサービス(無料httpsもあり)が追加できます(もちろん有料ですが)。
「もうメールはムームーメールでサーバはロリポップの安い共用使ってhttpsして、AWSにリダイレクトさせれば一番楽なのでは？」というダークサイドな考えが頭をよぎりますが、「いやいや安くても月額費かかるし、万が一人気が出て共用サーバにアクセス集中したらブロックされて終わりだし…」と踏みとどまって、AWSだけでサービスを完結することにしました。
AWSで独自ドメインのメールを送受信するにはこちらの記事を参考にしました。
aws で独自ドメインのメール送受信サーバーが欲しいと思った時
この記事によるとAWSでメールを送受信するのは3パターンあり、至れり尽くせりだが値段がお高いWorkMail、postfixとかインスタンスに無料サーバー立てる方法(インスタンス代が毎月かかる)、値段は安いが設定が面倒なSESとなります。今回はインスタンス使わないので、いろいろ考えた結果SES(Simple Email Service)を使う事にしました。
でSESって何かというと、私の理解では以下の通りです。
・当初はメール送信しかできないサービスでちょっと前に受信もできるようになった。
・大量のメアドに機械的にメールを送信するような用途が得意で、迷惑メール業者とかに向いてそう。
・建前上、バウンスメール(配信不能メール)の管理に厳しい
・受信したメールは自分で転送用のスクリプトを組むか、S3に保存してダウンロードしていちいち開く必要がある。
・docomoやauなどのキャリアメールへの送信は難しい？
厄介なのはバウンスメール。迷惑メール業者対策なのか、バウンスが一定割合を超えるとSESが停止されるらしい。キャリアメールに送信しようとしたら、1日でアウトになりそう。
通知はAWS SNSとかLambdaとかに連携させるのが普通なようで、間違っても設定一発でメールクライアントで簡単に送受信できるようなシロモノではないようだ。メール送受信APIに近いのかな？
S3からファイルを複数ダウンロードもできない私にとってはハードル高すぎですが、SNSやLambdaとか連携して使うと何とかなるらしい？
ちなみに私はRoute53で生成されたTXTとCNAMEレコードをムームードメイン側の情報に登録する必要がある、ということに気づくのに半日くらい無駄にしました。トホホ。
携帯キャリアメールはSESと相性が悪いらしいので（たぶん迷惑メールの大半がSES経由だから？)、非公開の対策が進んでいて(docomoとかauが厳しい。SoftBankはザルという噂？)難しいようです。以下の記事を見つけましたが2年近く前だから今はどうなのだろう？バウンス管理も面倒なので、とりあえずサービス開始時は携帯キャリアメールは利用禁止にすることにしました。弱腰でごめん。
認証(サインイン)とパスワード忘れたときの自動対応
今回のサービスではメールアドレスによる会員登録を行うようにしました。
メールアドレスを登録すると、検証キーが記載されたメールが返ってきて、正しい検証キーと英数字8文字以上のパスワードを入力すると登録が完了する。
まあどこのサイトでも使われている、手垢がついた流れですね。
あとパスワード忘れたときの対応も、対応する暇が惜しいので自動化したかった。流れとしては登録メールを送るとそこに検証キーが送信されて、正しい検証キーとパスワードを入力すると、変更が完了する。
これも一般的な方式と考えていたので、GitHubにナイスなコードがあってそれを再利用すればサクッと認証できる…と思ってましたが、そうもいかずフルスクラッチになりました。単体テストではこれが一番時間かかったかも？3日くらい。
結局、サーバレスということもありAWSのCognitoを使うことにして、なんとかなりました。
苦労した点と今後の課題
・Zoomのミーティング情報を不特定多数とやり取りする方法で悩んだ
・そもそもWebサービスを自分で立ち上げたことがなかった。
・ムームードメインよりRoute 53でドメイン登録した方が楽だった。
・https化、DNSの設定、SESによるメールの送受信で苦労した。
・マイクロソフトのEDGEだけ挙動が変。更にPC版とスマホ版で見え方が違うので匙投げそう…。
・バウンス管理はまだ道半ば。はやく携帯キャリアメールにも対応したい。
・ZoomAPI使って、簡単に登録できるようにしたい。
ちなみに私はボランティア授業を始めるようになって、ママ友に「Zoom授業ありがとうございます。子供が朝起きるようになりました」と感謝されたことがあり、軽いショックを受けました。それは「このママ何さぼってるんだ？」という怒りではなく、「子供の学習機会が奪われているんだなー」という悲しみからです。
中学受験を目指している偏差値60以上の子供ならともかく、普通の6年生はまだ5年生の気持ちを引きずっていて目標設定とか学習管理とか自分でやったことがない子供がほとんど。「親がもっとちゃんと勉強させろ」とか言っても限界があるます。親も仕事に出ちゃって、家には子供だけになるしね。
やっぱり毎日決まった時間に登校させて集団生活させて、予定通りの学習をさせる--という学校というシステムは偉大なんだなーと思いました。
最後までお読みいただき、ありがとうございました！
ZMLINKでは子供たちに教えるボランティア先生も募集中です～。