M1 Mac miniを迎えた

りん研究室が所有している情報端末は、ほとんどApple社製です。

CUIプラットフォームのMS-DOSではPC-9800シリーズを利用していましたが、そこからGUIプラットフォームに移行する際、単純素朴に「憧れ」を理由にMacintoshを選択して以来、そのまま続いているという感じです。

実際のところ仕事のほとんどはWindowsを使って対応する必要もあったので、職場に用意されているWindows端末を併用しながら、Macを使い続けていたことになります。異なるプラットフォームに対応するスキルは、そういう過程で培われたのだと思います。

やがてインターネットやクラウドといった技術の台頭のおかげで、異なるプラットフォーム間でのデータ交換は、ほとんど問題にならなくなりました。端末上での具体的な加工スキルが問題ですが、それもだいぶ枝葉のこととなりました。人は学ぶ努力を怠らなければ、なんだって対応できます。

そんなわけで、私はほとんどの作業をMacでこなし、必要に応じてWindowsを利用するものの、それらはGoogleなどのクラウドサービスを連携させているというのが日常的な利用環境です。

ところで、今年(2020年)は自宅での作業も増え、自宅の情報端末環境にもスポットライトが当たった年でした。

自宅には、古いChromebox(Chrome OSの小型デスクトップ端末)と古いMacBookが第二の人生的に備えられ、Web閲覧や動画視聴、動画配信などに利用されていました。

しかし、やり取りされる情報量や処理負荷の増加のせいでしょうか、処理速度が体感的にも遅くなり、端末の内蔵ファンが音を立てて動作し始めることも多くなりました。情報受信だけであればファンの動作音は無視することもできましたが、情報発信(ビデオ会議や動画録画・配信)を行なう場合には問題となります。自宅作業が多くなって、この問題も大きな課題となったのです。

自宅の情報端末環境の見直しが課題となったタイミングで発表されたのが、新しいApple社製チップ「M1」(Apple Silicon)を搭載した新型Macでした。

Apple社はずっとiPhoneやiPad向けにチップを設計し搭載し続けてきましたので、コンピュータの処理装置をつくる経験が豊富な会社といえます。その経験をようやく自社の原点ともいうべきパーソナルコンピュータ向けに搭載することとなり、11月にその概要が披露されたわけです。

その発表内容は、言葉通りに受け取るならば驚愕するものでした。

市場にあるノートパソコンと比較して、同じ消費電力なら「2倍の性能」、同等パフォーマンスなら「4分の1の消費電力」だといいます。

たぶん、世界中のユーザーが「はははは…」と最初笑っていたと思います。本当にそんな性能のチップができるの?と。

しかも、インテル製チップからの大引っ越しです。従来のソフトウェアとの互換性について問題ないという話も、ビジネス上の大げさな営業トークで、ソフトウェア側が新型に対応するのを待つ必要があるだろうと、誰もが考えていたのでした。

いくら引っ越し慣れしたAppleでもこれは誇大宣伝じゃないのか?とか、いや独自路線のAppleならやりかねない…とか。人々は憶測を楽しみ、とにかく発売されれば分かるだろうと迎えた発売日。続々と発信される新型Macの評判に再び人々は驚愕歓喜することに。

処理がキビキビしているという性能はもとより、バッテリ持続時間が長い、筐体が熱くならない、ファンがほとんど回らず静かだと。人によってはiOSアプリが動かせることに注目するかも知れません。

こうなると私たちの無い物ねだりは爆発して、あれが無い、これが動かない、対応しない、安定しないを論うオンパレード。久し振りにみんながパーソナルコンピュータを熱く語るのを楽しんでいました。

結果的に、個人が一般的に利用する分にはコストパフォーマンス抜群なパソコンだということだけはハッキリし、ハイアマチュアやプロシューマ、プロフェッショナルのユーザーは来年(2021年)発表されるハイエンド機を待った方がよく、理由もないのにWindowsを主体に利用しているユーザーが無理して乗り換える必要はないことが分かってきました。

いずれにしても、魅力的な選択肢が一つ増えたという点で、今回の新型Macの発売は歓迎すべき出来事でした。

私もM1 Macには魅力を感じた一人ですが、すぐに購入することは無いだろうと考えていました。

ところが、自宅の古いパソコンたちは、相変わらず作業をすると高熱を発し、ファンが唸り、なんだかこれまで以上にご機嫌斜めになってきたようにさえ思えてきました。

ああ、これは私の中で、置き換えの思いが芽生えた証拠。

そのときすでに、Apple直販サイトで注文すると数週間待たされる状況でした。かなり話題となり注文数も増加しているようです。

手持ちの機材や他の端末との兼ね合いなどをいろいろ吟味して、直販サイトではなく量販店サイトで在庫が用意されているモデル(人々はこういうのを「吊るし」のモデルと表現していました。今回初めて接した言葉です)を購入することにしました。

M1搭載のMac mini(8GBメモリ/512GB SSD)を迎え入れました。

自宅で使い続けていたApple Cinema HD Display 23inch(2006年製品)とHDMI接続しようと考えてセッティングを始めました。

ところが、ここでトラブル。

もともとApple Cinema HD DiaplayはDVI端子によって接続するディスプレイで、それを純正の変換アダプタでHDMI端子に変換して、最近までChromeboxに接続して利用してきました。それを新型Macに接続しようと思ったのですが、どうも最近のMac miniは映像信号フォーマットが変更になったり、いろいろ変わったらしく、新型に接続すると、表示はするけれども残像が強く残る不具合が発生したのです。

Mac miniのHDMIコネクタに接続するのではなく、Type-Cコネクタ経由での接続を試みたものの、いくつかの変換アダプタも症状が改善せず、これは新しいディスプレイを追加購入しなければならないのかと諦めかけました。

最後に試したHyperDrive Gen2 6ポートUSB-Cハブを試したところ、問題なく表示されるようになったので、しばらくこのハブを介して接続することにしました。

古いディスプレイを利用しようとしたために発生したトラブルで、新しいディスプレイを利用していたり購入する場合には滅多に発生しない問題と思います。

(追記)その後、Apple Cinema Displayとの接続は、BenfeiのUSB Type-C to DVIアダプタに変えて順調に動作しています。

同種のアダプタはいろいろありますが、1920 x 1200をサポートしているものは限られているので、条件に該当する人はこのアダプタを試してみることをお勧めします。

さて、実際に利用を始めると、macOS Big Surという基本ソフトの新しいバージョンによる変更点は新鮮ですが、それ以外は違和感もなく動作しています。そして確かに反応速度にストレスを感じる機会がほとんどありません。

さらに筐体は本当に熱くならず冷たいまま。静音動作は気にすることを忘れてしまうほど当たり前となっています。

最初は、M1チップに対応したソフトウェア(ネイティブ/ユニバーサル)のみ利用するよう環境を整えようとしました。従来タイプ(インテル)のソフトウェアを動かすためのRosetta2という変換機能を使わなければどこまでできるとやってみたかったからです。

現時点で、Apple社製ソフトはもちろん、 Google ChromeFirefoxMicrosoft Officeegword Universal2zoomTwitterSlackPDF ExpertiA WriterUlyssesNovaTransmitMagnetPixaveScreenFloatYoinkReeder5OmniGraffleOmniOutlineAudio HijackLoopBackMarsEditScrivnerScappleOnyx といったアプリが対応しており、開発系ツールも対応が進行中のようです。

まだ対応していないアプリの場合は、iOS版を利用することを検討します。

たとえばiOSアプリを検索する「iMobie M1 App Checker」というアプリは大変役立つユーティリティーです。

たとえば、時計表示アプリとして「NHKとけい」アプリがデザイン的にも気に入っていますが、これをmacで表示させることができます。

あと、「radiko」アプリも動作するので、ちょっとラジオが聴きたい時にコンパクトに利用することができます。

また、私が愛用しているメールアプリ「Spark」のmac版はM1未対応なので、iOS版Sparkアプリを利用してみたりできます。

DropboxもM1未対応のため、通常であればWebページから利用することになりますが、これもiOS版Dropboxアプリをダウンロードして利用してみることができます。

Googleドライブも後ほど書くようにアプリがM1未対応ですが、iOS版Googleドライブアプリを利用できます。Web版とアプリ版のどちらが便利なのかは人それぞれです。といっても回りくどいことには違いないですが。

iOS版アプリからmacへのファイルのやり取りは「共有」や「エクスポート」を使うことになりますが、このときYoinkアプリを購入して使うと、経由場所として便利です。

画面の縁にYoinkを配置することができます。

共有シートのYoink項目

iOSアプリ内で共有をすると「Yoink」の項目が出ているはずなので選択するとダウンロードされると思います。

逆にアップロードはアプリのウインドウにドラッグアンドドロップすれば可能です。

というわけで、M1ネイティブ縛りの真新しい環境でスタートする分には、本当にシステムや操作反応は引っかかり無くスムーズですし、少しばかりささやかれているBluetoothの不安定さも、私の環境ではありません。iOSアプリのいくつかはmac上の動作未対応であることに起因する起動失敗や落ちることもありましたが、あとは古いディスプレイの相性が悪かった以外、新型Macは快適そのものです。なにより静か。部屋のエアコンの方がうるさいくらいです。

そんなこんなで、M1ネイティブ縛りでどこまで揃えられるか挑戦するのも楽しいわけですが、これまでの資産を移行してこようとすると、やはり限界もあります。特にクラウドストレージ系の対応が遅れていることは困ります。

多少、速度的なブレーキやシステムの不安定を招くだろうことを覚悟して、従来のソフトを動かす「Rosetta2」の導入へ進むことにしました。

まずはDropboxです。

現在、DropboxはM1対応の作業中で、アプリの開発中バージョンを随時公開しています。動作保障を求める場合は数週間後に予定されている正式対応版を待った方がよいですが、試してみたい場合はこちらに最新ビルド(開発中の最新状態を公開したもの)がアップされています。

次にGoogleドライブ。

Googleドライブに関しては、利用されているタイプによって「同期とバックアップ」と「ドライブ ファイル ストリーム」という2つのアプリが存在しますが、どちらも正式対応はまだです。

いくつかの情報によると「同期とバックアップ」が内々には対応したので動作したということのようですが、その場合でもインストール後すんなりというわけにはいかず、何度も動かしているうちにどこかで動作開始できる条件が揃う感じのようです。(セキュリティ設定を許可したら動作したという情報も流れてきました。私はまだ様子見をしています。)

(追記)その後、「同期とバックアップ」はM1対応したようです。

動画収録などで音声加工するため利用していたiZotope社RX7Wave社Vocal Riderといった音楽プラグインもRosetta2前提でインストールしました。インストーラーも問題なく動作し、ライセンス認証も成功。Audio Hijack内で利用してみました。

RX7はオリジナルのインターフェスイス画面の表示がうまくいかず、Audio Hijackでは「Use Generic Audio Unit Interface」で調整することになりました。Vocal RiderはUIも問題なく表示されたので調整できました。両方とも音声加工の部分に関しては問題なく動作していました。

あと、Blackmagic Design社のATEM Mini Proを利用して配信作業をすることがありますが、ATEM Software Controlも問題なく動作しています。

いまのところ、これらが動けば自宅環境はほぼ完成。

コンピュータ内部の劇的な変化に比して、利用する側の使い方が劇的に変わるわけでもなければ、メリットを感じる部分も「ストレスがない」というだけのすぐにでも忘れて気付かなくなる類いのもの。それでも、今回の新しい端末導入は良い決断だったと思います。

あとは、周辺のアプリやサービスがM1対応していくのをのんびり待てば、より快適な環境になるかなと思います。

パソリッチとナンバーバンク

パソリッチとナンバーバンクというのは、Scratch3.0拡張機能のことです。

グラフィカルプログラミング環境のScratch3.0用拡張機能について、このブログで幾度か書いてきました。

小学校家庭科[消費生活・環境]とプログラミング教育
スマートカードとScratch 3.0と教育と
PaSoRich – ICカードリーダーをScratch3.0で

プログラミング体験やら教育やらの話題を見れば、算数や理科における単元内の例示に始まって、シングルボードコンピュータと呼ばれるmicro:bitなどの利用、各種ロボット教材の導入、双方向ネットワークを扱う教材や注目を集める機械学習やAI技術をモチーフにした取組みなど、実に賑やかです。

それぞれに良さがあるのは承知していますが、それらに加えて、家庭科教育で消費生活システム(たとえば電子決済システム)を学ぶ視点から深堀りしていったほうが面白いのではないか、と投げ掛けたのが最初の記事でした。

そして、Scratch3.0でICカード(スマートカード)リーダーが読めたら面白いよね、という発想からでき上がったのが「PaSoRich」でした。

スマートカードをScratch3.0で
https://con3.com/sc2scratch/

カードを識別することで、それぞれに紐付いた情報を処理するプログラムを書くことが出来るようになります。最近話題のAI・機械学習系だと、画像を識別するのに応じた処理をするプログラムを組むことになりますが、いわば、その前段レベルが可能というわけです。

PaSoRichのおかげでリーダーをつなげた端末でカードを読み取れるようになりました。それをもとに電子決済シミュレーションのプロジェクト(プログラム)も作成しました。

けれど、あくまで1台の端末の範囲内。

識別情報を読み取れるようになったけれど、情報を書き込めるようになったわけではないし、また、情報がネットで共有されているわけでもありませんでした。

たとえば、模擬店での決済を例に考えると、あるお店の端末で決済処理をしたあと、別のお店の端末で新たな決済処理をしても、前の決済処理の結果が伝わらないので、現在残高が分からず減らせないし、ポイントも継続的に増やせません。

見かけだけ電子マネーの真似はできても、実際のところ電子決済システムを再現できていたわけではないということです。

そこで、今回新たに開発したのが「NumberBank」です。

NumberBank
https://con3.com/numberbank/

Scratchの中上級者であれば「クラウド変数」と呼ばれるものに近いと思っていただければと思います。

本家Scratch3.0の変数作成画面

数字をサーバーに保存するという点では同じですが、NumberBankは、変数というよりも連想配列(Key-Value)と呼ばれるものに近い入れ物です。

もとはPaSoRichで読み込まれたカード識別番号をキーにして数字を紐付け保存することを目的としていたことから、そのような形式になっています。この連想配列(または辞書型配列とも呼ばれています)によって、たくさんのデータを効率的に扱えるのです。

これによって、ようやく電子決済システムをScratch上で再現することが可能になります。

さらにNumberBankは、2つのキーを組み合わせて数字と紐付けるように設計しました。たとえば、私たちの日常では同じおサイフケータイを使うにしても支払い方式を選ぶ場面があります。それと同じで、同じカード識別番号でも違う扱いをしたい場合のために、もう一つキーを組み合わせる造りにしました。

たとえば決済システム、場合によってはポイントシステム、場面が変われば出欠確認にも使うでしょうし、電子スタンプラリーをする場合もあるかも知れない。それら複数の目的にも同じカードが使えるようにできます。

というわけで、Scratch3.0拡張機能であるパソリッチとナンバーバンクが揃いました。これを使った新たなプロジェクトをいろいろ作ってみたいと思います。

ご関心ある方々や、ご協力いただける皆さんへの情報提供の準備もしなければなりませんし、まだまだ改善改良が必要なシステムのため、ご意見やフィードバックを得て修正しなければなりません。

いろいろ教えていただけると幸いです。

何で書くか

読むものが膨大に増えて、読まなければならないものより読まなくていいものを読んでいる時間ばかり過ぎて、書く機会はすっかり押されぎみだ。

このまま書く気力も薄らいでしまっては困るが、気がつけば、何で書くかという状況が激変していたことも、放ったらかしにしていた。

何で書くかという問いは、どんな形で書いたものを残すのかという問いでもある。その組み合わせも多様で、今の自分を落ち着かせられる選択肢はどれかは大問題だ。

昔の自分は、「何で書くか」問題をそれなりに落ち着かせていたように思うが、ここ長いことその問題への対応は崩れて乱れて瓦解していたかもしれない。

昨今はFacebookなどのSNS経由で情報が行き交うことも多く、それらを追いかけることも有意義なのではあるが、そこはどうしても情報の重複や余分が入り込み、途切れもないまま膨らんだかと思えば雲散霧消が繰り返されている。

しかも、ある時期からは「いいね」などのフィードバックや関わり合いの程度にもとづいてタイムラインが積極的に編集されるようになってきた。それがポジティブに働いている面もあれば、ネガティブな効果を生むこともあり、総じて私たちは振り回されている傾向にある。

それはこちらが読む情報に限らず、書く情報の伝わり方にも関わっており、要するに、書いたからといって方々の人々に届いているとは限らないということが当たり前に起こっているのである。

皆がFacebookタイムラインだけに頼っている状態だと、アルゴリズム的な村八分が展開していることに気付かないこともありうるわけだ。

一時期は、書いたものが友達のもとに届き、「いいね」等の反応が得られるという点で何かを書くのにうってつけだと思われたFacebookも、いまやすっかり書いても埋もれるだけの場所になりつつある。

にもかかわらず、Facebookはいまだに多くの時間を奪っていくし、そうしてうつつを抜かしているうちに「何で書くか」問題が混沌としてしまった。

こうした駄文を書く場所として、かつてよりずっと維持しているこのブログは、今でも稼働を続けて、今後も継続していくことになるが、もう少し括りを伴った形で書く手段も欲しいところ。

そうしたニーズに、私たちは何を使って対応しているのだろうか。

日本語ワードプロセッサを使って文書ファイルを作成する方法はかなり古典的だが、仕事ではいまでも当たり前の手段だ。

今では、クラウドサービスと組み合わせたノートツールをつかうことが多いだろうか。以前はEvernoteが絶大な人気を博した時期もあったが、様々なツールの登場によってユーザーも分散していったように見える。

電子メールをメモ代わりに使う(自分宛のメール)というビジネスマン・ティップスも、今ではメッセージサービスがそれにとって替わっている。

また、テキストファイルベースで情報を記録するという人々も少なくない。プログラマ界隈ではマークダウン記法と呼ばれる記録ルールも使われている。

具体的なツールや情報の記録形式を列挙するのは別の機会にしたいが、「何で書くか」問題は、それら細かな選択肢に対する人々の好みも絡むため、実に厄介な問題でもある。

それで、私自身の「何で書くか」問題について、自分自身の対応を再構築しなければならないと考えて、ちょっとした試みをすることにした。

「漸次書籍」という名前の電子書籍プロジェクト。ちょっとずつ書き足す形式の電子書籍である。

言ってしまえば、電子書籍の形をしたブログのようなもの。一冊まるまる書き切らなければならないハードルの高さがない分、取っつきやすいかなという感じである。リハビリがてら始めてみようと思う。

最近の国立国会図書館

この御時世に…とは思うものの,たまたま出張のお仕事を多くいただく年と重なったため,今月も東京出張をしていました。

その一環で,久し振りに国立国会図書館に立ち寄ることになったのです。

国立国会図書館は永田町の国会議事堂の隣に立地した施設。18歳以上であれば利用者登録のうえ誰でも利用することができます。

ただし現在は,感染症拡大予防のため入館制限を行い,事前予約をする方式をとっています。申し込み多数の場合は抽選となります。利用したい週の前週水曜日正午までにインターネットから申し込みが必要です。

申し込み日は複数可能で,私も複数の候補日を申し込みました。めでたく一日分当選しましたので,入館できた次第です。

普段は本館と新館の2つの入口があるのですが,現在は本館の入口のみ。

まず指先消毒を行ない,エントランスに設置されたカメラ式検温センサーをクリアした後,仮設受付で予約当選確認を行なう段取りとなっていました。

午後から利用したので,朝の開館待ち状態がどうなっていたのか分かりませんが,おそらく間隔を空けて列に並び,開館と同時に順番に上記の段取りで入館していたのだろうと思います。

マスク着用が必須とはいえ,入館後の利用方法に特別な変化はありません。全体的な座席の減数やカウンターの飛沫防止カーテン設置などは行われています。

入館制限により,館内の雰囲気はゆったりしていますし,貸出や即日複写の受付も集中するタイミングはあるもののスムーズに処理されていました。

思いついたときにふらっと立ち寄れる利便性が制限されているのは残念ですが,今回もあれこれ調べものができてよかった訪問でした。

私の遠隔授業裏舞台

私の職場は、今年度4月下旬から遠隔授業がスタートしていた。

幸い、何年も前から大学のメールシステムはGmailシステムに切り替えられ、その流れでなんとなくGoogle Appsも使えるようにはなっていた。最初は私のような物好きと語学担当の先生方数人が利用しているにすぎなかったが、GSuiteに名称変更されたあたりから少しずつ学内認知度も高まってきた。

ICT活用がとりたてて得意という職場ではないものの、こうした素地のようなものがあって、新型コロナ禍に伴う遠隔授業の実施方針もGoogle Classroomベースで行うというミニマムな方法を基準として打ち出すことができた。

他大学はGW(ステイホームウィーク)明け以降に遠隔授業を開始するというところが多いにもかかわらず、私の職場が早々に4月下旬から始められた理由は、徳島県が全国的にみても感染者判明数がほぼゼロに近く、感染拡大といった事態と無縁だったことはもちろん大きい。

遠隔授業の取り組みそのものに対しても、先に書いたように、なんとなくそういうものがあると意識が広まっていたおかげで抵抗感が少なかったのもあるが、実際のところどれだけ大変なのか訳が分かっていなかった人たちが多かったこともプラスに働いていたのかもしれない。

情報センター等の関係部署の方々は、突貫作業とはいえマニュアル作りや緊急研修の準備など取り組まれて、そうした努力にも支えられてスタートできたのだろうと思う。

私自身も従来までGoogle Classroomを授業の補助ツールとして使用し続けてきたので、そこでの経験を踏まえて遠隔授業の環境準備を行うこととなった。

実のところ私は、対面による授業で、典型的な口頭伝達的講義と、典型的な実技演習授業を行なってきた、極めて旧来型のステレオタイプな授業手法採用者である。

アクティブ・ラーニングの重要性は承知しているし、試みていないわけではないものの、担当している部分が知識習得を担うタイプの科目であり、その先の知識活用を担う授業科目へ学生達を引き渡すという位置づけを期待される度に、派手な取り組みはお任せした方がうまくいくことを感じている。

そのため、Zoom等のリアルタイムコミュニケーションツールによる同期型の授業はほとんど行なっていない。大学院の担当科目で文献購読を行なう際、Google Meetを使ってマンツーマンで議論している程度である。

講義授業については「毎時課題+オーディオ講義+教科書・講義資料」というオンデマンド型オンライン授業を採用している。

演習授業については、本来であれば対面による授業が解禁されるまで休講にしてもよかったのであるが、「情報処理」という名のパソコン基礎操作演習なので、「実演動画+毎時課題」によるオンデマンド型オンライン授業で進めてしまうことにした。

講義授業

教科書があるので、基本的にはそれに沿って授業を行なうが、毎回は、学習部分に対応した「調べ課題」を毎時課題として用意し自学予習の機会を作ってからオーディオ講義を聴いてもらう段取りにしている。

教員による解説講義を聴く前に自学しておくことによって、内容に見当をつけることができるし、解説をピンポイントで聴くことにも役立つ。二度三度と同じ内容に触れることで反復学習の効果も期待されるだろう。

実際の準備は…

・Googleドキュメントによる「毎時課題」配布テンプレートの作成
・毎時課題を紹介するオーディオ説明ファイルの収録
・教科書や講義資料の準備
・毎時課題に即した学習内容のオーディオ解説ファイルの収録
・これらのマテリアルをGoogle Classroomに予約投稿する設定

以上のようなことをしている。

毎時課題はGoogleドキュメントで調べ課題シートを作成して、「生徒にコピーを配布」モードでGoogle Classroomの課題に追加する。基本的には毎時課題の成果が日常的な学習進捗把握の材料となる。

オーディオファイルの作成には、パソコンにオーディオインターフェイスを使ってマイクを接続して音声収録している。

オーディオ収録環境
【パソコン】iMac (Mid 2011) - macOS High Sierra
【オーディオインターフェイス】EDIROL FA-101
【マイク】Shure BETA 58A
【収録用ソフト】Hindenburg Journalist Pro

収録したオーディオは、mp3形式でGoogleドライブに直接書き出し保存をしている。あとはGoogle Classroom上から呼び出し簡単に添付できる。今のところ受講生数が少ないのでGoogleドライブ共有でもアクセス数制限等の問題に直面していない。

Google Classroom上の投稿構成は、授業トピックを講義単位で括るために使用し、ちょっとしたコースウェア的になるようにしているが、一講義分にたくさんの投稿が並ぶと、リストが長くなるし、投稿の手間がかかるため、「出席確認(質問)/毎時課題(課題)/講義解説(資料)」の3投稿に絞っている。

利用者の増加のせいか、Google Classroomの投稿予約機能は設定した時刻にプラス5〜10分くらいの投稿タイムラグが発生するようになっている。そのため、3つの投稿予定は時間差で設定しているが、それぞれ5分程度の遅れを見込んだ時刻設定にしてある。

提出物は、Googleドキュメントで配布している調べ課題だが、学生達は他の授業で様々なやり方に触れているせいか、Googleドキュメント以外にも、手書きノートを写真撮影したものを提出したり、それぞれ利用しているアプリで課題に取り組んだものをPDF化して提出するものもあったり、千差万別である。その辺は私が対応できる範囲でOKにしているため、学生側から課題の取り組み方法について不満が出てくることはほとんどない。

授業時間中は、出席確認から始まり、調べ課題や解説講義に取り組んでいる最中に書き込まれる質問に返答したり、コメントを読みながらやりとりを行う。出席確認投稿に対する学生のコメントで受講生同士が受講していることの相互確認を行ない、オーディオ講義では前回までの取り組みや受講生からのフィードバックを全体に共有などして、講義授業の一体感や活動雰囲気を確保している。

ちなみにオーディオ収録のタイミングは,収録作業に慣れてしまったこともあり,当日の朝になっていることが多い。日付レベルでリアルタイムであることは同期感が高まるメリットはあるものの,収録を失敗した場合のリカバリー作業に時間的余裕がないことにもなるため,収録は前日に済ませるのが良いかと思う。

演習授業

パソコンの基礎操作に関する演習授業は、対面による授業であれば、大学のパソコン教室に配備されたWindowsパソコンを実際に操作して練習する形で進められてきた。

担当者は、パソコン教室の前方に用意された教員機を使い、実際の機器操作をデモンストレーションしながら受講生達を操作練習に誘ってきた。

遠隔授業となれば、パソコン教室のような統一的な機器環境が見込めない。学生達が自宅で扱える情報機器は、主にスマートフォンであり、一部の学生がパソコンを所有しているに過ぎない。

こうなると、受講生自身による演習部分の制約を受け入れて、教員からのデモンストレーションに重きを置いて進行する他ない。その上で、操作練習する演習部分について、可能な範囲で取り組んでもらうスタンスを取ることにした。

授業は、「実演動画」を視聴してもらうことが中心となっている。内容に応じてスライド資料があったり、演習課題が用意される。

実際の準備は…

・操作画面を中心とした実演動画の収録
・スライド資料の作成
・演習課題の素材、配布ファイル等の作成
・これらのマテリアルをGoogle Classroomに予約投稿する設定

実演動画は、担当者のカメラ映像と機器の操作画面映像とをスイッチャーで切り替えて収録できるようになっている。一つの動画は内容によって時間の長さが異なるが、10分〜15分程度を目安に作成している。

実演は、Windowsでの操作だけでなく、スマートフォン(iOS, Android)およびmacOSでの操作についても扱い、同じ課題を行なう際に各基本ソフトでどんな操作をするのか、可能な範囲で個別の動画を作成し実演している。

これまでパソコン教室や教員機がWindowsパソコンに限定されていたために、特定プラットフォームの実演提示に限られていたが、実演に使用できる機器が教室環境に縛られずに済むようになったため、マルチプラットフォームを踏まえた実演提示が可能となったことは遠隔授業のメリットとなった。

受講生達は、身近な端末の操作方法について学べるようになり、高額な出費で手にしたスマートフォンが日常使っていること以外にも活用できることを発見して、それが授業への関心や意欲にもプラスに働いている様子が感想やコメントからも窺える。

さて、動画収録には、少々トリッキーな環境を構築してある。

動画収録環境
〈デモンストレーションマシン環境〉
【パソコン】Mac mini Server (Late 2012) - macOS Mojave
【仮想環境】Parallels Desktop 15 for Mac - Windows 10 Home
【iOSデバイス】iPhone 6iPhone 6s
【Androidデバイス】Pixel3
【画面転送ソフト】Reflector TeacherAirParrot

〈映像収録マシン環境〉
【パソコン】Mac mini (2018) - macOS Mojave
【オーディオインターフェイス】Audient EVO4
【ビデオキャプチャ・スイッチャー】Blackmagic Design ATEM Mini
【画像転送受信ドングル】EZCast 4K
【マイク】Shure SM7B
【カメラ】SONY RX0
【カメラ】SONY HDR-MV1
【映像収録ソフト】Wirecast Pro
【音声キャプチャソフト】Audio Hijack
【動画編集ソフト】Vrew

実演提示するための機器と映像収録するための機器は別々にしてある。通常、これらが一緒であると、操作画面を収録する際に便利であることも多く、利用できる機材が限られている場合にも都合がよいが、マルチプラットフォームで実演をする負荷を考えると分けた方がフリーズ対策にもなる。

デモンストレーションは、mac OS上で動作する仮想環境上のWindows 10を中心に行ない、スマートフォンはiOSとAndroidの画面転送機能(AirPlay等)を使って、仮想環境と同じマシンの画面に集約表示できるようにした。そのデモンストレーションマシンの操作画面をさらに画面転送アプリ(AirParrot)から受信ドングル(EZCast 4K)に送って画面収録できるようにしている。この辺がトリッキーである。

映像収録マシンは、接続されている映像キャプチャ・スイッチャーATEM Miniで切り替えられた映像を録画する。録画に使っているWirecastは、本来は配信用ソフトウェアであり、もっと安価な時に購入してずっと使い続けているが、いまでは高額なソフトとなってしまった。代替ソフトとしてはOBS Studioがある。

撮影は、カメラ映像で動画の内容を説明したあと、操作画面の映像に切り替えて実演提示を行う。基本的に一発撮りで、多少のミスがあっても撮影中にリカバリーして、編集をせずにYouTubeにアップロードする。

一部の参考動画では収録時間が40分〜60分程度になってしまい、言い間違いなどの修正が必要になるものもある。その場合は動画編集ソフトVrewに読み込ませて編集作業を行なっている。

Vrewを使うと機械学習を活かした字幕生成を行なってくれる。さらに認識した音声テキストを編集することができるが、これは字幕テキストとは別であり、音声テキストの編集が動画の編集と連動するようになっている。そのため削除したいセリフ部分を文字で削除すれば、映像の方もその部分が削除されて便利である。その他にも沈黙部分を短めに詰める機能など使う。

オンラインによる遠隔授業においては、学生側の通信料金コスト負担の問題が取り沙汰され、なるべく授業に関わる通信データ量を下げるように呼びかけが行われている。YouTubeを実演映像の保存先にしているのは、YouTubeが備えている動画の圧縮や配信に関しての技術的なメリットを享受できるからである。

こうしてYouTubeに限定公開された動画は、Google Classroom上の投稿でリンクされて受講生が視聴できるようになる。この際、演習授業では一講義分を「出席確認(質問)/実演動画(資料)/毎時課題(課題)」という3投稿で構成し、それらを投稿予約機能を使って時間差で公開していく。

授業時間中は、動画視聴がひと段落して実際の操作練習のタイミングになる頃にたくさんの質問や様子の報告が限定公開コメントに上がってくるので、個別に返信を行なう。

パソコンやデバイスのトラブルを文字だけで遠隔サポートすることが如何に大変かは、経験された方ならお分かりになると思う。

もちろん、それを見越した解説や実演を動画に盛り込むことは必須だが、それでも想定していないパターンのトラブルや説明が不足している事柄は残るもので、授業時間中に飛んでくる受講生からのコメントはなかなか興味深い。

Google Classroomはコメントに画像を貼り込めないため、こちらからは基本的に文字ベースで確認事項や手順を伝えるほかない。学生からは、場合によって課題添付の形でスクーリーンショットを送ってくれることもあるので、それを頼りに問題を把握して返答することもある。

問題所在を確認するために、使用しているデバイスは何かといった初歩的な確認から始まり、視聴した動画の何本目の、何分何秒あたりが説明と実際とで異なるのかを確認するなど、遠隔サポートのノウハウを駆使しながらやりとりは続いていく。

確かに対面による授業の方が、直接画面や状況を把握して、問題解決のためのアドバイスを提示しやすい。しかし、今回の遠隔による演習授業の試みを通して、こちらからは動画による実演提示でマルチプラットフォームに対応した丁寧な解説が届けられ、対する受講生は自分の馴染みのデバイスを利用して、実際の操作を練習したり、アドバイスを得るにしてもトラブルを自己解決しなければならないという状況に直面することで、かなり積極的な授業(アクティブとまでは言わないが…)を展開できているのではないかと思われる。

ただし、どうしても学習課題の設定時には環境制約が伴うため、課題目標を低めに設定しなければならないことも起こる。「トラブルを自己解決する経験」は聞こえはよさそうであるが、そもそも解決できないトラブルが起こらない程度にはハードルを低くする必要もある。

遠隔授業準備は、やはり授業や課題の内容吟味も大事になってくる。

収録環境

作業をする研究室が、必ずしも静粛な環境ではなく音声収録に向いていない。

映像や音声のメディアを利用する場合、やはり音響部分の聴取品質が高くないと、満足感も高まらないし、逆に視聴している際の疲労感が高まってしまう。オンライン授業やビデオ会議が疲れる一因には、音の良し悪しが少なからず関係しているとも考えられる。

そのためオーディオ関連は、これまでもマイクの種類を変えたり、音質調整するソフトウェアを変えたりといろいろ工夫を重ねてきた。

マイクに関しては、一般的に「コンデンサ」型マイクが集音感度に優れているとして勧められることが多く、そのような事例報告が多いことも手伝って、USB接続できるコンデンサ・マイクが選ばれやすい。しかし、もともとの収録環境が静けさを確保できない場所である場合、感度の良いコンデンサ・マイクよりも、感度の低い「ダイナミック」型マイクを利用した方が都合が良いこともある。

利用するシチュエーションに応じて適したマイクを選択していくことになるが、その際、USB接続タイプのマイクでなければ、オーディオインターフェイスと呼ばれる周辺機器を併せて購入しなければならない。このオーディオインターフェイスも、本来であれば使用するマイクに必要なパワーや仕様を持っているかどうかを確認する必要があり、安価なものを一つ買えば済むといった簡単な話にはなっていない。問題なく使えても、音質を良くする観点からパワー不足である可能性は少なくない。

私が導入したShure SM7Bは、ダイナミック・マイクの中でも最も集音感度が低いマイクとして知られている。そのおかげで余計な環境ノイズ等を拾わないメリットはあるが、パワーのないオーディオインターフェイスと組み合わせると、本来収録したい音声も小さく集音されてしまう。入力つまみを最大限に上げても小さいわけだが、このつまみを最大限に上げていることが機器からのノイズを大きくしてしまう別の問題を生む。ダイナミック・マイクを使用する場合、パワーに余裕のないオーディオインターフェイスは気をつけなければならない。

なお、映像収録に関しては、固定カメラを用意することと画面映像を収録できるように機材設定している以外に特別な配慮はしていない。強いて書くなら撮影用ライトが確保してある。

クロマキー処理をして、合成による映像づくりが行えるように道具立てはしているものの、実際に運用するには面倒が多そうなので、現時点では活用していない。グリーンバックを背に画造りをしても楽しそうだが、普段の研究室を背景にしても(散らかっている恥ずかしさを除けば)特段困らない。

新型コロナ禍による遠隔授業提供の試みより以前から、音声収録やネット配信等の試みを続けてきた経緯もあり、こうした細々としたこだわりのようなものが積み重なって、現在のような裏舞台が出来上がっている。(機材も手持ちのものを新旧組み合わせている。)

ただ、結局は「授業」や目的の活動になるべく取り組みやすい環境・条件を作りたいということを目指して来たのであり、継続的に目的の活動が行えるよう利用環境をシンプルに維持することが大事だ。

収録がパッと取り組めて、結果をザクッと放り込んで、提供する側も視聴する側もある程度の予測が可能なルーチンに基づいて進行させながら、その中に面白みを割り込ませるような構造。奇をてらったものは何もないが、持続的に取り組めることを重視すると、そうした方が内容吟味の方にエネルギーを割ける。

おかげで毎回の準備において機材や収録環境で手を煩わされることは滅多にない。毎回の授業で扱う内容に関連する準備に手こずることはあっても、これは純粋に授業内容準備であるから省きようがない。

こうした調子で、遠隔授業に取り組んでいる真っ最中である。