「探究学習をやってみました：Q-Questの参加（後編）」の探究活動報告
皆さん、こんにちは。テラオカ電子です。これまで、前編（第35回ブログ記事）で、私が参加したQ-Questの概要を、次に、中編（第36回ブログ記事）で、制作した「クラス分け最適化アプリ」の技術概要を紹介してきました。
今回は、後編としてQ-Questでの活動中にあった「激論」を述べたいと思います。断っておきますが、チーム内で激論があったことは失敗ではなく、むしろこれがあったからこそ「FIXSTARS賞」を頂け、成果を生み出すことができたので、この中にこそ「良いチーム活動の秘訣」があると考えています。
以下に、【１ 事業創造プログラム活動のやり方】、【２ 私の取り組むスタンス】、【３ プロダクト制作の方向性での激論】、【４ DEMO DAY（最終成果発表会）での激論】そして【５ まとめ】の順で述べていきます。最後までお付き合いください。
【１ 事業創造プログラム活動のやり方】
事業創造プログラムでは、最初、参加者（50名程度）が集まる「アイディアソン」というイベント（土曜日午後の半日）がありました。ここでは、まず、事前に各自が量子コンピュータ技術を使ったビジネスアイディアを提出しました。そして、このイベントで全員が各自１分程度アイディアを発表して、全員が良いアイディアだと思うものを投票し、10程度の候補に絞りました。次に、その候補のアイディアの中から自分が参加したいものを申告しました。こうしてチームが組まれました。
私は、以下のような「生徒の探究講座配属先 最適化アプリ」というのを提案しました。
この案は、他のビジネスアイディアと比べて、ビジネス的ではないし、直ぐにでもできるものでしたので、候補には残りませんでした（４票ほどでした）。そこで、私は、「学校」に近いテーマである「クラス分け最適化アプリ」に参加することにしました。
この「クラス分け最適化アプリ」は、Ｍ氏の提案ですが、当初、私とＴ氏がジョインしました。その後、人数調整がありＨ氏が参加して、４名でチームが組まれました。Ｍ氏は、某製造業のエンジニア（ジェネラリストコース）、Ｔ氏は、某市の物理の研究者（エンジニアコース）、Ｈ氏は某社の方です（エンジニアコース）。Ｔ氏は若い方ですが、他は私を含めて年配です。チーム名は、「School Princes（学校の王子たち）」としました。「王子」にしては、メンバーは高齢ですが、アプリ名が「ホームルーム シンデレラ」の所からこのようになりました。
【「DEMO DAY（最終成果発表会）」に参加した10チームはこちらから】
活動は、DiscordというWebのコミュニケーションツールで行いました。Chat機能やオンライン会議機能などがあります。なので、最後までリアルで対面することもなく、お互いの詳しい経歴は最後まで不明でした。ただし私は、最初から勤務校を公開しておりました。
キックオフ会議から、合計９回のオンライン定例ミーティングを行いました。土曜日か日曜日に1時間程度行いました。回を重ねるごとにプロダクトを形にしていきました。その間、途中で主催者から講義と中間報告会（プロダクトタイピング）が提供されました。
活動環境の概要は上記になるのですが、主催者から与えられたのは、Discord環境とFIXSTARS社の量子コンピュータのアカウントと、活動を進めていく上でのサポートです。誤解されるといけないので書いておきますが、予算はありませんし、報酬もありません。完全な各自の自主的活動です。なので、企業で勤務するような雇用関係などもないので、他人に命令などはできません。むしろ、学校で行う「探究」活動に近いと言えます。
【２ 私の取り組むスタンス】
私は、この事業創造プログラムに参加が決まったとき、何を言っても、プロダクトを作ることが必要ですので、量子アニーリングマシンのプログラムを復習しておくことが必要だと考えました。そこで、FIXSTARS社が公開しているチュートリアルを一通り確認しておきました。このことは、プロダクトを制作していく際に、「この問題には、このチュートリアルのコードが使える」と迷わず判断でき役にたちました。
【「FIXSTARS社のチュートリアル」はこちらから】
様々な問題についてプログラムの事例が説明されています。
以下に、私のこのチーム活動での方針、決めごとをいくつか述べます。
一つは、コミュニケーションツールであるDiscordを最大限に活用することです。議論は、定例ミューティングでするわけですが、議題が、その場の雰囲気や、成り行きで決まってしまうことがよくあります。なので、ミューティングの前に、資料をDiscordにアップすることにしました。これは、９回全てのミーティングに対してコミットできました。テラオカは単に暇だからと言われますが・・・。また、考え方もできるだけ事前にDiscordに投稿して、ミーティングで初めて聞く話題はないようにしました。他のメンバーからは、最後まで「「うすぺらいやる気」を見せつける高齢者」と思われていました。
もう一つは、チーム活動で議論していくと、方向性などで、意見が対立することが当然予想されます。このようなとき、どのようなスタンスをとるのかを事前に決めておくことが必要と考えました。
そこで、それぞれの方がどのような目的で、このプログラムに参加しているのかをチームでシェアしておくことが大切だと考えました。各人それぞれの思いを持って参加しているので、一つにまとめる方向ではなく、差異を差異のまま残して進めるスタンスをとることにしました。そもそも、自主的参加ですので、誰も、誰に対しても命令はできないのですから。同調圧力も含めて。
私の参加目的は、以下のようなものですが、ミーティングでは、研究者のＴ氏は、自身の研究の幅を広げるためと答えてくれました。Ｈ氏は、とにかく様々なことを勉強したいからと答えてくれました。テーマの提案者で、リーダーにＭ氏は、知り合いの先生がクラス分けで困っていることを聞いたからと答えました。これは、答えになっていません。自身の目的ではないからです。それ以上聞いても、はっきりとした回答はありませんでした。私は、このことが、懸念でした。最後にこの懸念は、現実化するのですが、できるだけそうならないように、発言していこうと決めました。
【３ プロダクト制作の方向性での激論】
このプログラム活動の中間のところで、「プロトタイピング」という中間発表イベントがありました。それぞれ10チームが進捗状況を報告しました。
全てのチームの報告が終わった後、主催者、FIXSTARS社の方を交えて、「ブレイクアウトルーム」でミーティングがありました。「ブレイクアウトルーム」は、２チーム合同で行われました。私たちのチームの議論は、白熱しました。なので、同席したチームの方は、驚きだったかもしれません。その論点のいくつかを紹介します。
一つ目は、コンセプトの議論です。私たちのテーマは、「クラス分け最適化アプリ」ですが、そもそもなぜこのプロダクトを作るのか、そのコンセプトを定義しておく必要があります。
当初、私は、この「クラス分け最適化アプリ」ができれば、これまでの年1回というクラス分けという行事が、年間通していつでもできるようになると考えました。このことは、「いじめ」解決の有効な一手段になりうることを提案しました。このコンセプトは、当初メンバーから無視されましたが、Ｔ氏は、終盤、賛同してくれました。
また、私の主張の一部を載せます。相手の発言は割愛しますが、議論の白熱具合を感じてもらえればと思います。
最終的に、以下のように整理しました。しかしながら、結局、DEMO DAYでは、使われませんでした。これより良いものであれば納得できますが・・・。
別の白熱した論点です。これは、固定生徒のリストをどのようなインターフェースで入力するかの問題です。固定生徒というのは、誰と誰を同じクラスにするか、誰と誰を同じクラスにしないかの人間関係の配慮の問題です。
この問題をＭ氏は、「パズルの組み合わせ」と表現し、この部分を自動化すべきと主張したのですが、これは、浅い理解だと判断したので反論しました。こここそが、本来の教員の真の仕事だからです。最終的に、ヘーゲルの「弁証法」ではありませんが、Ｍ氏が主張するテーゼ：「固定生徒のリストを自動化する」を私がアンチテーゼ：「こここそが本来の教員の仕事」、そして、ジンテーゼ：「インターネット校のような大規模な場合には固定生徒リストの自動化は有効」となりました。でも、このジンテーゼは、私が無理やりこじつけたものです。そしてこれを実装したものが、第36回ブログ記事で紹介した「アドバンスモデル」になります。以下は、その時の私の主張の一部です。
【４ DEMO DAY（最終成果発表会）での激論】
DEMO DAY（最終成果発表会）は、東京で行われました。午前中に、簡単なデモンストレーションがあり、午後プレゼン発表がありました。
発表は、リーダーであるＭ氏がやることなので、Ｍ氏のみが東京へ行き、残りの３名は、午後のプレゼンのみをZOOMで観戦しました。
Ｍ氏のプレゼン資料は、当日になっても完成していませんでした。資料は、Ｍ氏が新幹線の中で作成しているのですが、その進捗がDiscordで示されました。書き方は悪いのですが「演技」のように思えるのでした。
実は、どのような内容をプレゼンするかについては、この日の前の定例ミーティングで議論されました。まとめを私がDiscordで投稿しています。以下その一部を掲載します。また、この内容については、私が、資料の大半を事前に作りその定例ミーティングで報告しているのです。
新幹線の中でＭ氏は私の資料を取り入れつつ40数枚の発表資料を作りました。しかし発表は5分です。私の懸念は、Ｍ氏が自分の作った部分しか発表しないのではないかというものです。私は、
と牽制しました。
と返答がありました。
実際プレゼンでは、全てのスライドはめくられましたが、後半の資料は、各スライド1秒以下でした。さらにいけないのは、以下のように嘘をつくのです。ロスは、アーカイブでも確認しましたが、5秒ほどで、また、終了時間を15秒程伸ばしてもらったので、ロスは関係ありません。（この後、反省ミューティングでは、「40秒のロス」と報告するのです。このように宣言すれば事実が変わると考えているのでしょうか）
Ｍ氏におかれましては、わざわざ東京まで行き、代表として発表して頂いたので、自分の思うようにやって当然かもしれませんが、釈然としない気持ちが残るのです。
【５ まとめ】
以上、【１ 事業創造プログラム活動のやり方】、【２ 私の取り組むスタンス】、【３ プロダクト制作の方向性での激論】、【４ DEMO DAY（最終成果発表会）での激論】を述べてきました。ここで取り上げた議論は、分かり易い例を紹介しました。実際には、複雑な議論が繰り広げられました。
このQ-questを体験してどのようなことが嬉しいのかを振り返ると、やはり自分のやったことが評価されることだと感じました。なので、生徒の皆さんが行う「探究」においても、この「評価」をきちんとしてあげることが大切です。仕事の場合のようにきちんと報酬があれば別なのですが、各人の自主的参加であればなおさらだと思います。一方で、この「評価」を求めすぎると、他人のアイディアをコーピーして、ほんの一部を変えて、自分のオリジナルと主張することになりかねませんので、そのあたりはしっかり評価する必要があります。
余談ですが、現在、工業科目である『生産技術』を教えているのですが、そこにトランジスタの発明の記述があります。トランジスタの発明に対しては、ウイリアム・ショックレイ、ジョン・バーディーン、ウォルター・ブラッテンの３人にノーベル賞が贈られているのですが、なぜかこの教科書では、ショックレイの写真のみ掲載されています。この発明の経緯については詳しくありませんが、この教科書の掲載のやり方（一人だけ掲載すること）には大変違和感を持っています。
【「トランジスタの発明」はこちらから】
話を戻して、この「事業創造プログラム」では、コミュニケーションツールとしてDiscordが使われました。一番いい点は、記録が残ることです。もちろん、テキストでのコミュニケーションなので、意思疎通を完璧にこなすことはできませんが、あとで、冷静になって振り返りができます。今回のように定例ミューティングと組み合わせるとより有効であることがわかりました。また、チームのDiscordには、主催者も入っています。主催者の方が全てを読んでいるとは思いませんが、「監視」の役割は果たしていると思います。なので、安心して発言できます。「探究」の場合であれば、Teamsなどが同様に使えると思いました。教員としては、「評価」と「監視」の両方の側面から使っていくとよいと考えます。
また、チーム活動というとよく「まとめる」ということをやるのですが、一つにまとめる方向ではなく、差異を差異のまま残して進めることもありではないかと思います。今回の場合、アプリ開発なので、他人がどのようなことを言おうと、自分がこれぞと思ったならば、自分でプログラムを書いて作ればよいわけですから。今回の場合、Ｔ氏は、ローカルアプリを調べて作っています。なので、制作するプロダクトにもよりますが、絶対一つにまとめなければならないという捕らわれは必要ないと考えます。
最後に、今回、チーム活動を前提に取り組みましたが、生徒の「探究」の場合、個人での「探究」もよい面が多いと感じています。チームでは、人間関係に捕らわれすぎて、肝心の「探究」に集中できないのではないか。個人の方が「探究」そのものに集中できるのではないか。そんな風にも感じました。
今回はここまでです。ここまで読んでくれて、ありがとうございます。ご意見・ご感想等ありましたらご連絡ください。
テラオカ電子
【イチオシのYouTube動画】
このコーナでは、記事に関連する（関連しないかもしれません）気になるYouTube動画を紹介しています。今回は、シャ乱Qの『シングルベッド』（1994）を紹介します。昔、つんく氏がモーニング娘に関するインタビューの中で、「バンドならば、役割がきちんと決まっているので問題ないが、（モーニング娘。のような）グループでの運営は難しい」のようなことを言っていたことを思い出しました。
「シャ乱Q「シングルベッド」(MV)」
【2024/05/07投稿】
