日本学術会議の提言を読んでみる：学術情報流通の現在と未来 1/n

日本学術会議が急に世間で話題になっています。だからというわけではありません。話題になる前にでたこちらの提言

学術情報流通の大変革時代に向けた学術情報環境の再構築と国際競争力強化

をみんなで読む会をやってみたい、と、提言を見たときから思っていたのですが、

日本学術会議の第三部理工系学協会から学術情報流通の現在と今後についての提言が出ている。理工系だから関係ないと思ってしまいがちだが、今まで図書館にまわっていた費用と研究成果公開にかかる費用の流れが変わるという話で、結果として人文系が依拠してきた仕組みからhttps://t.co/kjqtAb9plu

— Kiyonori Nagasaki (@knagasaki) 2020年9月29日

なかなか時間がとれないうちに日本学術会議が急に注目を集めるようになり、しかも10/1から自分も連携会員になってしまいました。 ただし、第一部会なので、第三部会が出したこの提言は、部会も違う上に関係者になる前に作られたということで、 利害関係者ではないということで、この提言を私の主観から読ませていただきたいと思います。

なお、筆者は学術情報流通については専門ではありませんが実践者として少し関わっており、また、出身が人文学系であり、 人文学も学術情報流通の話と無縁ではないので、人文学の視点も加味しながら読んでみる、という風にしてみたいと思います。

それから、一度に全部読むには長すぎるので、少しずつ読んでいきたいと思います。今回のブログ記事は「あれっ？」というところで 終わってしまいますが、ご容赦ください。

それでは、以下、読みながら気がついた点についてメモしていきたいと思います。

執筆に関わった方々

最初の2頁ほどに、執筆に関わった方々のお名前がリストされています。14名から成る分科会が作られており、9名の 会員と5名の連携会員が属しておられたようです。この提言の場合、この14名以外に21名もの協力者がリストされている ことが目を引きます。研究者のみならず、図書館員や学術情報に関わる企業からも参加があるところも興味深いところです。 学術情報流通がどのような人々によって支えられているか、そして、この提言がいかに幅広く目を配って作成されたか、 ということがあらわれているのでしょう。

要旨

要旨に挙げられている項目をみれば、大体内容はわかりそうな気がしますが、個別の情報を知らないと よくわからなかったり実際には役に立たなかったりするので、要旨はざっと見るだけにして本文にいきましょう。

１提言作成の背景：我が国の学術情報発信力の向上に向けて

まずは理学工学系の話に限定しつつ、日本の研究の国際競争力が落ちてきているところから話が始まりますね。 論文数が減っていることを「学術情報発信力の衰退」という表現にすることで、今回のタイトルとつながってくるようです。 学術情報（＋データ）の流通と適切な管理・活用の重要性が熱く語られています。 「学術の基盤環境である学術情報流通のネットワークを通じた高度な学術情報のコミュニケーション」 ということで学術情報流通が、学術情報のコミュニケーション、という位置づけにされています。ただ、 学術情報流通という言葉はScholarly communicationの和訳らしくて、元々コミュニケーションを 含意する用語だったようにも思われます。昨年ノースカロライナ州で開催された2019 Scholarly Communications Institute | trianglesci.orgという イベントに参加した際には、Equity in Scholarly Communications.テーマの元で公募を通った5つくらいのグループが それぞれ持ち寄ったテーマで議論をしていました。（世界中から集まった40人くらいの参加者全員 にA. Mellon財団が旅費滞在費を出していたのはちょっとびっくりしました）。私が参加したグループは 要するにTEIガイドラインの国際化という話で、どちらかと言えばデータの話でしたが、他のグループは 学術情報をめぐる人のコミュニケーションが主なテーマになっているようでした。学術情報流通は門外漢なので あまりよくわからないのですが、Scholarly communication に学術情報流通という訳語を与えたことで議論の幅が結構変わったのかもしれないと思ったところでした。

また、学術情報環境（学術情報インフラ）の整備が必要であるにも関わらず経費高騰により 最低限必要なものさえ失われそうになっている、としていますが、これは人文学系でもまさに 同様で、わかりやすい例で言えば、大学図書館の人員と経費が削減されつつあるところがそれにあたるでしょう。 そして、「これまでの学術情報インフラの維持や管理については、理学工学系の科学者のほとんど が無関心であり、」としていますが、これは人文学系でも似たり寄ったりな面があると思います。 とはいえ、限られた人生の中の、しかも 年を取るほどに減っていく、研究のために費やせる時間の中で、自分の研究対象に向き合う 以外のことに時間を費やすのは、なかなか難しいことでもあります。ある種の役割分担のようなものも 必要なのかもしれません。ただ、近年は、競争的研究資金の審査や大学研究機関の認証評価など、 競争環境を作り出すために専門家が割かなければならない時間がどんどん増えてきてしまっている ようにも思えますので、その点についても何らかの効率化を図る必要があるのかもしれないとも 思っています。 いずれにせよ、本提言では、そこを巻き返して、いわば学術情報のエコシステム全体を再構築すべきときに来ている、ということが述べられているようです。

一方、いわゆるガラパゴス化により、国内学協会の存在意義や持続可能性が問題になりつつあるとの見解も示されています。 私見では、この点は、特に日本語読者を意識する場合、ガラパゴス化をさけられない状況があり、むしろそれによる メリットをきちんと成果として評価されるような枠組みを用意していく必要があろうかと思っています。そして、 そのためには、話者人口規模の近い非英語圏先進国と手をとりあっていくことができるとよいのではないかとも思っています。 思っているだけで、実際に何ができているのかと言われるとなかなか難しいところではありますが…。周囲をみてみると、 J-Stageでは日本語論文誌も無料で公開してDOIも付与してくれるようになっており、さらに論文索引（サイテーションインデックス）も 搭載しているため、論文を掲載する学会側がきちんと論文索引を作成すれば、指標化はできるようになっているはずです。（実際には 論文索引があまりきちんとできていなくて集計もうまくできないということがあるようですが…）。あるいは、 筑波大学で試みている新たな評価指標もあります。一方、フランスでは、 人文社会科学向けのオープンアクセスプラットフォーム Open Edition が提供されているようです。 こういった取り組みについてはもっとよくご存じの人がいると思いますので、ご教示をいただけるとありがたいところです。

結果として、「過去 20 年間に起こった世界的な電子ジャーナル化の波に我が国は対応できずに周回遅れになった」 とのことですが、一方、それを「挽回する「最後の好機」でもある。」とのことです。関連する全ての構成員が 協働すべし、とのことですので、私も機会があれば、と思います。

本章の最後では、これまでに出されてきた学術情報流通に関連する提言を振り返ります。数年おきに、5件の 提言がでていたようです。以下にリンク付きでリストしてみましょう。

• 2007-06-28 対外報告「学協会の機能強化のために」

• 2008-05-22 新公益法人制度における学術団体のあり方

• 2010-08-02 学術誌問題の解決に向けて― 「包括的学術誌コンソーシアム」の創設 ―

• 2014-09-30 オープンデータに関する権利と義務ー本格的なデータジャーナルに向けてー

• 2016-07-06 オープンイノベーションに資するオープンサイエンスのあり方に関する提言

筆者もこれらはその都度拝読して、その都度感心して期待しておりましたが、実現した事柄はごくわずかだったそうです。 なお、ここでは紙数の関係で挙げなかったのかもしれませんが、学術情報・データの流通に関しては個別分野からも色々な 提言が出ていて、たとえば以下のようなものが見つかります。

• 2008-08-28 保健医療分野における政府統計・行政資料データの利活用について-国民の健康と安全確保のための基盤整備として

• 2014-05-30 社会調査基盤のリノベーションに向けた官民学連携研究拠点の構築

• 2014-06-24 文化財の次世代への確かな継承―災害を前提とした保護対策の構築をめざして―

• 2014-09-11 ビッグデータ時代に対応する人材の育成

• 2014-09-19 ユビキタス状況認識社会の構築と時空間データ基盤の整備について

• 2014-09-30 地理教育におけるオープンデータの利活用と地図力/GIS技能の育成－地域の課題を分析し地域づくリに参画する人材育成－

• 2017-08-31 持続的な文化財保護のために―特に埋蔵文化財における喫緊の課題―

• 2017-09-21 新たな情報化時代の人文学的アジア研究に向けて──対外発信の促進と持続可能な研究者養成──

• 2017-09-30 持続可能な最善の医療を実現する次世代型ヘルスケアプラットフォームの構築

• 2018-01-22 生物多様性条約及び名古屋議定書におけるデジタル配列情報の取扱いについて

• 2019-11-18 持続可能な生命科学のデータ基盤の整備に向けて

• 2020-05-28 オープンサイエンスの深化と推進に向けて

• 2020-06-18 科学的エビデンスを主体としたスポーツの在り方

• 2020-07-07 化学・情報科学の融合による新化学創成に向けて

• 2020-07-10 Web 調査の有効な学術的活用を目指して

• 2020-07-14 持続可能な人間社会の基盤としての我が国の地球衛星観測のあり方

• 2020-09-14 社会的モニタリングとアーカイブ―復興過程の検証と再帰的ガバナンス―

• 2020-09-15 感染症対策と社会変革に向けたICT 基盤強化とデジタル変革の推進

• 2020-09-18 災害レジリエンスの強化による持続可能な国際社会実現のための学術からの提言－知の統合を実践するためのオンライン・システムの構築とファシリテータの育成－

• 2020-099-18 行政記録情報の活用に向けて

（日付やリンクが間違っていたらご指摘ください！）

タイトルから推測して目次をみたくらいですので、まだかなり漏れがあるかもしれませんが、学術情報やデータの整備・拡充に言及している提言をざっと 探しただけでこれくらいあります。デジタル社会で学術をいかに展開していくかという話は多くの（おそらくはほとんどすべての）分野で重要になっている ようです。自分に関係のある分野の提言はぜひ押さえておきたいところですね。 なお、「科学的エビデンスを主体としたスポーツの在り方」には、柔道の山口香氏や日本サッカー協会会長の田嶋幸三氏も名前を連ねてらっしゃって、 なかなか興味深いところです。

さて、今回の提言に戻ると、今回は、これまでの提言を踏まえて、以下の4点について議論するとのことで、 「その多くは日本の学術全体に共通する課題に対しても有効であると認識している。」としてこの章が締めくくられますが、 まったく同感です。

1. ジャーナル購読・学術情報の流通・受信
2. ジャーナル発行・学術情報の発信
3. 理学工学系におけるオープンデータ/オープンサイエンスの課題
4. 我が国の学協会の学術情報機能の強化

始まったばかりですが、今日はこの辺でひとまず終わりにします。また機会をみつけて続きを読んでいきたいと思います。

KHコーダで 「#大学生の日常も大事だ 」を分析してみた（ちょっと追記）

#大学生の日常も大事だ　というハッシュタグがツィッターを席巻したことがありました。そこで、しばらくこのハッシュタグのついたツィートや、そのツィートをしたアカウントのツィートをツィッタAPIで収集しておりました。 7/10から7/29までに取得した173GBのツィートのデータから、当該ハッシュタグのついた88,082件ツィートを、Pythonであれこれ整形して、さらにKHコーダを使ってちょこちょこいじってみて、なるほど、こういう感じかな、と思ったのが以下の図です。

コーディング：MDS

「今後」と「辛さ」、「施設」と「費用」がそれぞれ近いということ、それから、「横の人間関係」が「勉強・研究」と比較的近いことが興味深いところです。

なお、今回の分析の仕方だと、否定表現も肯定表現も区別できていません。「辛くない」というツィートがあったとしたら「辛い」として カウントされてますので、上の図はそういうものだと思って見てください。

ただ、そうだとしても、やはり、今後のことを心配しているであろう人が多そうであること、施設が十分に使えないのに費用がかかることについて色々な意見が出ているで あろうこと、友人やサークル、人との出会いなどが大学生のなかでは勉強・研究とならんで重要であること、など、ツィートをじっと読めばわかることではありますが、このようにして 見やすい形で確認することができました。

感情表現もとってみたいと思ってAmazonのそういうAPIなども試してみたのですが、あまりよい結果にならなかったので今回はここまでとしておきました。

なお、今回使ったデータの頻出語リストは以下のような感じでした。

頻出語リスト

HSH_1 というのはハッシュタグの置き換え、RT_PATI1 というのは、「大学生は、いつまで我慢をすればいいのでしょうか。」というリツィートを置き換えたものです。なぜこのような 置き換えをしているのか、というのは下の方で説明します。これが次のURLとほぼ同数なのは、 このURLが示す画像（マンガ的なもの）と一緒にリツィートされたものが多かった、ということです。このツィートのツィッタ画面上でのリツィート数はもっと多いのですが（11万くらい？）、APIでツィート収集をすると アクセス制限をかけているツィートを取得できないため、このような数字になっています。ということは、この件に関心を持っているユーザのうちアクセス制限をしている割合が相当数に なる、ということでもあります。アクセス制限下で、表に出せない本音を共有している人達がかなりの数いるかもしれないと思うと、この点もちょっと気になるところです。

ここまでのやり方

以下、どんな風にしてここまでたどり着いたか、逆にたどっていってみますので、同じようなことをしてみたい人のご参考になればと思います。

KHコーダをある程度使ったことがある人ならご存じかと思いますが、「コーディング」機能を使って人力クラスタリングを行なった上で、さらに多次元尺度法のデフォルト設定であるKruskal/Jaccardを使って みました。他の方法も一通り試してみましたが、これが一番しっくりくるような感じでした。

コーディング

「コーディング」は以下のようにしてみました。KHコーダでは、このようにして、自分で 出現単語を分類して、分類単位での分析を行なうことができます。

＊大学生
大学生 or 若者 or 学生 or 新入生

＊大学・教員
大人 or 先生 or 教授 or 教員 or 大学

＊横の人間関係
友達 or サークル or 会える or 先輩 or 交流 or 出会い or 部活

＊辛さ
辛い or 限界 or 我慢 or 孤独 or 不満 or リスク or 不安 or 鬱 or 嫌

＊勉強・研究
レポート or 課題 or 勉強 or 研究

＊施設
図書館 or 施設 or キャンパス or 学校

＊今後
後期 or 今年 or 秋 or 来年

＊コロナ感染症
コロナ or 感染 or 対策

＊授業形態
オンライン or パソコン or 対面 or 授業 or 単位 or 実習 or ゼミ or 実験 or 講義

＊費用
学費 or お金 or 支援

＊日常生活
日常 or バイト

大量のリツィートの扱い

普通にツィートを集めると、大量のリツィートが入ってきてしまいます。これを丸ごとKHコーダにかけると、大量にリツィートされた文章に含まれる単語に分析結果が大きく引きずられてしまいます。それはそれで良いということもあるかもしれませんが、今回の場合、単なるリツィートだと、書いた人の事情を表しているというよりは単に賛同しているに過ぎない場合が多いかもしれないということで、リツィートはなるべく外して、自ら書いたものを分析対象とすることにしました。

APIで取得したツィッターの構造化データにはリツィートであるという情報も含まれているのですが、どういう構造になっているのかをきちんと検討する時間が惜しかったので、Pythonで「同じテキストが5つ以上あったらリツィートとみなす」という風に処理するプログラムを書いて処理しました。ただし、リツィートしつつ何か自分で付け足している場合も考えられるため、リツィートの文は記号＋連番に置き換え、未知語としてKHコーダの分析対象にできるようにしました。

データの整形

KHコーダに読み込ませるデータはCSV形式である必要があります。そこで、Pythonのプログラムをちょろっと書いて、集めたツィートを「日付, ID, ScreenName, TweetText」というCSV形式に変換しました。最初は、全データをCSVにしてみたり、「当該ハッシュタグのついたタグ＋その後5件まで」というようなことをやってみたのですが、KHコーダに読み込ませたら2日経っても読み込みが終わらない、という状況になってしまったので、それは諦めて当該ハッシュタグ付きのみとしました。

ツィッタの収集

ツィッタの収集は、ツィッタAPIの利用申込をすると、無償で225回／15分のツィート検索＆取得ができます。利用制限回数はこちらにまとめられています。前述のようにJSON形式の非常に詳細な構造化データが落ちてきます。どれくらい詳細かというと、試しに一つ数えてみたら7322文字ありました。140字ツィートするだけでこれだけのデータが保存され、やりとりされるのだと思うとなかなか圧倒されますね。

取得用プログラムは、API認証を行なわなければならないのですが、Python3では oauth2 というライブラリがあって、それを使ったら割と簡単に書けました。

さらに、「ツィートした人のその後のツィート」も収集したかったのですが、これは900回/15分取得できますので、大量取得となってもこの規模だとまあなんとかなりました。取得したタグ付きツィートからuser IDを取り出してリストしておいて、そのリストを読み込んで定期的に収集…という形になりました。15分…ぴったりだとちょっと短いかもしれないので、time.sleep(1000) という風にして、一定時間ごとに勝手に取りに行くようにしました。

おわりに

ツィッタの文章は短い割にコントロールされていないので分析に使うには良し悪しがあると思いますが、テキスト分析やWebでのデータ取得の練習をするには良い教材になると思います。大学生の皆さんは、誰でも基本的な技能として身につけておいて損はないと思います。オンライン・オンデマンドの授業に参加できるようなパソコンと通信回線があれば、あとは無料でいくらでも勉強できます。ツィッタに限らず、電子テキストはあちこちに大量にありますので、うまく一定の基準で取得してそれを分析してみるようなことができれば、将来的にも色々役立つことがあると思います。興味がわいたら、KHコーダを作っておられる樋口耕一先生に感謝しつつ、今からでもぜひお試しください。

なお、KHコーダを本格的に使おうと思ったら、樋口先生の御著書を一度読まれることを強くおすすめします。チュートリアルの題材は漱石の『こころ』で、それ以外にも新聞記事を分析する事例など、色々興味深い内容です。コンピュータを使って日本語の文章をどういう風に処理し、理解の助けとするか、という実例として読んでみても、とても面白いです。

また、プログラミングも、今の大学生のみなさんはぜひ習得しておくとよいと思います。私は、インド哲学を勉強していたド文系の学生でしたが、大学4年生で卒論のためにパソコンを買って、その後大学院にあがってから、23歳くらいで初めてプログラミングを始めましたが、それでもそこそこできるようになりました。当時はWeb検索システムとかWeb掲示板を作ったりといったことが主でしたが、今の皆さんは、人工知能技術を簡単に使えるようになるプログラミング言語を無償で習得することもできます。正直、とてもうらやましいです。「Python 入門」で検索すれば色々な入門サイトがヒットします。ある程度Pythonを使いこなせるようになったら、最終的にはDeep Learningというキーワードで勉強すべきことを学んでいただくとよいと思います。

ツィートを分析しながら生のツィートをたくさん読ませていただいて、これもみなさんの多くの嘆きのうちのほんの一部に過ぎないと思いつつ、その大変さを改めて痛感しました。なかでも、人に会えないし新しい出会いもなかなか作れないというのは、特に新入生のみなさんには本当にきついことだと思います。課題が多過ぎる等の具体的な問題はある程度解決される部分があると思いますが、大学という場で人に会うことがもたらしてくれるかもしれないセレンディピティへの期待を代替するのはなかなか難しいことだと思います。私自身は大学では非常勤講師に過ぎないので何の権限もないのですが、そのための対応も、組織としての大学や個々の教員が、それぞれに真剣に考えてくれていると期待しています。

一方で、この状況だからこそできることもあるかもしれません。たとえば、ここでみなさんがテキスト分析やプログラミングを勉強してくだされば、社会に出てから割と直接的に役立つことも多いですし、そういう人がこの時期から劇的に増えたとしたら、IT後進国日本も、ようやく遅れを挽回できる時がくるかもしれません。もちろん、そこまで肩肘張らずとも、他にも色々なことができると思いますし、その中には、やってみたら実は面白かった、ということもあるかもしれません。この希有な体験を少しでもプラスに持っていくにはどうしたらいいか、夏休みの間に色々考えてみていただくとよいかもしれません。

MLAのウチとソト

MLA、と言われて、「文系」の人が思いつくものにはおそらく2種類あります。一つは、Museum, Libraries, and Archivesの略であり、博物館・美術館・図書館・文書館等のことを 総称し、そういった文化的なことがらに関わる機関が連携して活動することを志向して使われ始めたものではないかと想像しています。もう一つは、 Modern Language Association の略語であり、Wikipediaでも紹介されていますが、 19世紀からある割と古い学会であり、どちらかと言えば比較文学的な方向性が強いと聞いたことがありますが、いずれにしても、米国の文学系学会の中ではかなり大きなものの一つのようです。 2014年に開催されたものは日本語でイベントレポートが読めます。（なんと、今や各方面で有名な北村紗衣先生が訳してくださっています。）参考文献のスタイルで「MLA形式」というのを 聞いたことがある人もいると思いますが、そのようなものを作って公表し、世界的に使われるようになってしまうような程度の力を持っている学会でもあります。とりあえず、前者をMLA (J)、後者をMLA (U) としておきましょうか。

このようにしてみてみると、重なるところもあるものの、なんとなく棲み分けできそうな気がしないでもないです。ただ、これが、デジタルが前面に出てきたことで少々ややこしいことになりつつあります。

「MLAでは、デジタル研究やデジタルメディアにおける制作物を評価するためのガイドラインを策定しています。」

さて、どちらでしょうか？MLA (J) も、今や デジタルアーカイブの世界では非常によく出てくる言葉になっており、そういうものを作っていてもおかしくないのでは、関係諸機関も頑張っているのですね、という 気持ちになりそうです。しかしながら、よく考えてみると、MLA (J)は、それ自体で ガイドラインを策定するような主体ではない（おそらく）ということで、MLA (U) であることがわかります。

ただ、MLA (J) が、そのようであることを知っている人はどれくらいいるでしょうか？　と考えると、デジタルがそれほど前面に出てきてなかったころに比べると、混乱度がやや高まるのではないか という気もします。

ちなみに、MLA (U) は、2000年にそういうガイドラインを策定・公表し、改訂もしてきている ようです。2000年から、ということはつまり、Digital Humanitiesという言葉ができる以前のことであり、すなわち、2004年頃に始まる国際的なDigital Humanitiesの潮流を形成する主力を成したコミュニティの一つでもありました。 上にリンクしたイベントレポートでもその一端がうかがえると思います。日本で言うところのデジタルアーカイブの構築や利活用に文学研究の観点から本格的に取り組んで既に20年以上経っている学会、ということでもあります。 （取り組み始めたのはおそらくかなり前だと思います）

もう一ついってみましょう。

「MLAでは、文化研究のためのオープンアクセスの研究や教材を共有し、分野横断的な研究を支援するWebサイトを運営しています」 これも、上記のようなMLA (J) の状況を知っていれば、MLA (U) であることがわかりますね。MLA (U) は そのようなサイトとして、Humanities Commonsを運営しています。

さらにもう一つ。

「MLA コモンズというオンラインコミュニティサイトがあって文学研究のためのオープンな研究や教材を共有したり議論したりしてますが会員限定です」

というのを聞いて、もし私がMLA (J) の実際の状況をよく知らなければ、「どこにいけばMLA (J) の会員になれるのだろう」と一瞬思ってしまいそうです。 その後に MLA Commonsでググればすぐに事情がわかるとは思いますが。

では、MLA (U) の世界でMLA (J) のようなものがどう呼ばれて共存しているのかというと、LAMとか、GLAMなどと呼ばれるようです。順番が違っていたり、ギャラリー（G)がついていたりする ようですね。

一方、MLA (J) の世界でも、最近は、SaveMLAKにおいて公民館のK がついてMLAK（むらっく）という略称が使われるようになったり、また別の発想として、 大学と産業界を含めてMALUIという呼び方もされることがあるようです。いずれもその背景や使っている人達の想いをよく表現していて 素敵だと思います。MALUIの方は、耳で聞くとデパートの丸井との区別が少し難しいかもしれませんが、表記は異なっていますね。 文脈的にはデパートと間違えることはあまりなさそうな気がしますが・・・（どうでしょうか？）あるいはまた、Open GLAM Japan や GLAMtechなど、GLAMをそのまま使うこともあるようです。

しかしながら、MLA (U) を知っている編集者がたくさんいそうな出版社でも MLA (J) をタイトルにつけた本を刊行したりしているので、 むしろ、敢えて重ねている人達もおられるのかもしれないとも思うのですが、このまま行って大丈夫かな・・・と、ちょっと気になったりも しています。とりあえず、授業でこういう話をするときは、上記のような混乱のしやすさがあるので聞く時も話す時も注意するようにと伝えるようにしていますが、 みなさん、このあたりはどういう風に意識しておられるでしょうか？

Zoomのミーティング×10を自宅でモニタできるように

今回、とあるお仕事で、表題のような設定をしたので忘れないうちにメモっておきます。

状況としては、Zoomミーティング10件を同時運用するオンライン会議の運営者複数名が、各地の自宅環境において、 Zoomミーティング10件をモニタしたい、というものでした。

Zoomは、もしかしたら高級な契約をするとできるのかもしれませんが、私のできる限りでは、 パソコン1台では1度に1つのミーティングしか出入りできません。パソコン10台を並べれば 10件のミーティングの状況をモニタリングできますが、しかし、運営者が各地に 散らばっている場合、各地にそれぞれ10台パソコンを配備するのは費用的に難しいですし、 そもそも自宅接続だとスペース的にも無理だという人が多いでしょう。

そうすると、どこかでパソコン10台ならべて10ミーティングを集約してYouTubeにライブ配信してしまえば、 運営者の方々はパソコン1台しかなくても自分のZoomミーティングをしながらYouTubeの配信を見れば よいということになります。

パソコン10台並べて集約してYouTubeに…というのも大変そうですが、1箇所でよければ なんとか見つけられそうです。

パソコン10台持ってるのか、、、というのは、かき集めれば実はあった、という人も 結構おられると思いますが、インターフェイスやスペックがそろってないとこういう 時は大変です。そこでレンタルPC屋さんです。これが以外と安く、たとえば パソコンレンタル全国即納 ｜ e-タマヤ を何度か利用したことがありますが、4日前に 見積もりを始めて、往復含めて4日間で、HDMIポート付き（ここ確認大事！）／メモリ16GB／SSD256GB／Win10で、7万円切りました。 個人で出すのは大変ですが、参加者100人だと一人あたり700円、学会参加費のようなものの一部として考えると それほど高額でもないかもしれません。

さて、これらをどう接続するか、ですが、ビデオミキサーなどと呼ばれる類いの 商品がありますので、それを見てみると…ありますね。たとえば、Rolandの以下のものだとHDMI接続で 8台いけます。この機械は大変優れモノなので、このままモニタにつなぎこんで色んなことができちゃいます。 proav.roland.com

ちょっとお高くありませんか…と、やっぱりこういうものはレンタルしちゃいたいですね。

rental.pandastudio.tv

これにざくざくと8本のHDMIケーブルを挿してPCとつなげば8台のPCは一緒に表示できる ようになります。V8-HDで8画面を一覧表示すると圧巻です。

ただ、今回は10ミーティング、ということになっています。このままだと2台分足りません。 さて…ということで、以前から持っていたVR1-HDに登場していただきました。

proav.roland.com

ただ、不思議なことに、この機械は、せっかく3系統の入力を持っているのに、同時に2系統しか表示することが できません。しかも、私は少し前に買ったのでファームウェアが古く、「画面を二つ横に並べる」という機能を 使うことができず、ファームウェアアップデートをする必要がありました。この点、ちょっと注意が必要なようです。 が、VR1-HDユーザのみなさまにおかれましては、アップデートするとその機能が使えるようになりますので 大変おすすめです。

さて、VR1-HDは、合成した映像をUSB3でパソコンに直接流し込める賢い奴ですが、V8-DHもそれができるかと 思っていたらどうもできないようだ！ということがわかって、慌てて秋葉原に駆け込んでしまったのですが、 さすがの秋葉ヨドバシ…と言いたいところ、HDMI出力をパソコンに取り込める機器はほぼ品切れで、 1080pでUSB2.0に取り込む、というやや低スペックなものしか在庫がなく、しかし、YouTubeでは 十分かとも思い、とりあえずそれを入手したのでした。

というわけで、1台のパソコンに、USB接続にてV8-HDのHDMI出力と、VR1-HDの出力、あわせて10台のPCのHDMI出力を取り込めるようになりました。

PC8台　⇒　V8-HD　⇒　HDMIキャプチャ　⇒　ホストPC

PC2台　⇒　VR1-HD ⇒　ホストPC

という構成です。

さて、これをまとめてYouTubeに流し込みたい・・・ということで出てくるのが最近注目を集めているフリーソフト、 OBS Studio です。

obsproject.com

このソフトは、YouTubeにライブ配信する時に使われることも多いようですが、「映像キャプチャデバイス」を複数指定することに より、今回のような複数のソースもまとめて取り込むことができます。

（画面の下の方の「ソース」の左下の＋アイコンをクリックして「映像キャプチャデバイス」を選んでから…）

（いくつかデフォルトのままでクリックしていくとこのダイアログに来ますので、ここで「デバイス」からV8-HDやVR1-HDにあたるものを 選べばそれが表示されるようになります。このPCは別のPCなので表示されてませんが、上記のようにそれぞれをUSB接続しておくと、 それらが自動的に「デバイス」に表示されるようです。大変優秀ですね。）

複数ソースを表示させると、最初は重なっているのでよくわからないと思いますが、パワーポイントの図形のように、 個々の動画ソースのサイズをドラッグで変更できるようになっています。そして、右クリックして「順序」を選ぶと重なり具合を変える こともできます。

というわけで、あとは、二つの映像ソースのレイアウトを適宜変更した上で、YouTubeでライブ配信開始して、関係者の方々に 閲覧用URLをお届けすればOKです。

なお、YouTubeでライブ配信をしたことがない人は、ライブ配信のための登録手続きに24時間くらいかかりますので、その点は よくご注意ください。

ということで、今回は、OBS Studioの便利さに圧倒されたのでした。こういうものまでオープンソースで使えるのは素晴らしいことですね。

40代後半人文系で未だにWeb開発をしている理由

もう50歳がすぐそこにきていますが、未だにWebシステムの開発をしています。開発は若手や企業に任せて、自分は開発資金をとったり発注をしたりする側に まわるべきだ、ということもよく言われます。確かにそのとおりです。

ただ、現状のWeb技術のなかで「自分（達）」は何を求めているのか、それを明確にできないと依頼も発注もうまくできないのですが、 それを明確にするには、現在のWeb技術で何をどこまでできるのか、どこまでやるのにコストはどれくらいかかるのか、ということを 把握しておかないとうまくいきません。そもそも我々（この場合人文学者）は、どういうことをしたいのか、どういうものがほしいのか、 ということを、開発する人に正確に伝えるための言葉を、おそらくまだ持っていません。私自身も、そうです。そうすると、 作ってほしいものを無駄なコストをあまりかけずに作ってもらうということは非常に難しい、というか、成功率の低い話に なってしまいます。

このような状況だと、とにかく技術的なことがわかる比較的若い人を連れてきて、人文学の素養を身につけてもらうということが まず思い浮かびますが、人文系の金銭感覚だと、技術的なことがわかる良い人に巡り会える機会は極めて稀です。 極めて稀な、おそらくは十数人くらいの方々がこの業界で活躍してくださっていますが、はっきりいって全然人数が足りません。 一方、人文系でも時々技術的なことがわかる人やわかるようになろうとする人が出てきてくださいまして、 その場合、「我々がほしいもの」は割とわかっていますし、それをわかろうとする動機付けは非常に 強いので、そういう方々はとてもありがたいことですが、こちらも同様に極めて稀です。

成果がある程度見えるようなことであれば若い人達にお願いしてしまってもよいのですが、 「これから使えるようになるかもしれない技術を試してもらう」のは、本人は面白がって やってくれる可能性は高いのですが、実はうまく使えなかった場合、キャリア形成にとってあまりよくありません。 技術系の方々であればリカバリはある程度効きそうですが、人文系だと、コンピュータ関係のことで大きな回り道をして しまうのは本当に単なる無駄になってしまう可能性が高く、それが遠因となって（本業に割く時間が減ってしまう のに達成感が得られないということになるので）研究自体を諦めてしまうこともあるので、 個人的な経験からも、それは極力避けた方がよいことだと思っています。私の場合、 周囲の人や指導者に恵まれたため、正規の計算機科学のカリキュラムは受けなかったにもかかわらず、 初期の学習段階から、Web技術、Unix技術、SQL、標準規格、といった今でも通用する事柄を 学ぶことに時間を割くことができ、情報技術習得に関して回り道をしたという感覚を持つことは ほとんどなかったので、その点はありがたいことでした。（しかし、研究を 諦めるということが人生にとって不幸であるとは限らず、当人にとってはむしろ幸福に つながる場合も少なくないので、これはあくまでも、研究を広めたいという立場からの 話です。）

また、たとえば、直近の大きなものでは IIIF がありましたが、自分がIIIFを試し始めた頃は、まだ欧米でも 人文学者はほとんど参画していなかったので、何にどこまでどう使えるのか、ということを 仕様を見ながらオープンソースソフトを試しつつ確認して、実際にシステムを構築してみる、 ということをする必要がありました。IIIFに関しては、いけそうだという確信はありましたが、 1度目に試した時はあまりうまく使えず、1年ほど後に、その時の課題が解決されたようである のを見て2度目に試してみて、ようやく、 他の人にもすすめられると確信できたということがありました。 そういうことを若い人に頼んでみて、「やっぱり使えないみたいだ」ということになって しまうと被害甚大なので、まずは自分で試してみたのでした。IIIFに関しては、まあまあ良い感じになった のを確認できた後にブログや論文書籍等で 一通りみなさんと情報共有を行ったというのは、このブログの読者の方々もご存じかと思います。

もちろん、かなりお金があるのなら、まずはコンサル会社に頼んでみるという手もあるのかもしれないのですが、 コンサル会社も、良い担当者にあたればいいのかもしれませんが、こちらのニーズを把握して 対応する技術も調査して…というところまで、満足にやっていただくには相当なお金がかかりそうです。

というわけで、とりあえず我々のニーズと現在のコモディティ化したWeb技術のせめぎ合う ギリギリのところを探るには、自分でやってみるのが早道であり、その成果をみなさんと共有するのがよいの だろうかと思って、結局、未だに自分で開発をしてしまっているところです。

では、こういうことをしているのは世界に自分だけなのか、というと全然そんなことはなくて、 特に、Text Encoding Initiative Consortium（TEI協会）では、30年前からまさにそれにコミュニティとして 取り組んできていて、最近は日本語も含め各言語文化圏の事情にあわせた対応をしていこう という流れが強まっているので、そこでの蓄積をうまくこちらにも持ってこれれば だいぶん楽ができると思います。人文学としてもエンジニアリングとしても、彼我の文化の 違いは大きく、そのまま持ってきても通用しないことが多いかもしれませんが、 その点も含めた「翻訳」を行っていくことで、なんとかなればと思っているところです。

という風にして、自分を納得させながら（というのは、書いてみてうまくいかないのでデバッグをする… ということを延々と繰り返すのはこの年になると精神的に結構来るものがありまして…）、ここのところ、日々、vue.jsというWebの 「ユーザーインターフェイスを構築するためのプログレッシブフレームワーク」に 取り組んでいるところなのです。それまで使っていたjQueryという仕組みからの 移行を検討していたタイミングだったのですが、出張がほとんどなくなったために、一つの作業に 長時間集中して、バグ修正や動作確認も少し細々できるようになったので、 これを機会にとじっくり時間をかけて取り組んでいます。vue.jsは、もう「新しい」と言える ものではないのですが、元々私は、ある程度「枯れた」技術にならないと手を出さない ことにしているので（Webに手を出した95年は、すでにWebが始まってから4～5年経って おり、TEIは開始後15年くらい、IIIFに手を出した時も開始後4年経っていて、いずれも、一般にはそれほど広まって なくても、コアな層にはすでに広まっていました）、Webエンジニアの世界では 非常に広まってきていてそろそろ良いタイミングではないかと 思ったところだったのでした。

いくつか書かねばならない原稿もあるので、こればかりやっているわけにもいかないのですが、 ブログの方は、もうしばらく、vue.jsや現在勉強していることに関する意味不明な メモが連なっていくかもしれませんが、いずれ、今作っているものを公開できたら、 ある程度わかりやすい解説記事のような形にしていこうと思っておりますので、しばし ご容赦いただけますと幸いです。

今日のハマりどころと抜け出しどころ：jQuery ⇒ vue.jsな日々

今日も、あんまり vue.js は関係ないのですが、OpenSeadragonを組み込むのは割と簡単でした。

vue-openseadragonっていうのもあって、それだとreactiveに扱えそうなのですが、 組み込まれているOpenSeadragonのバージョンが一つ前なので、やめて、オリジナルを そのまま組み込みました。 src/App.vueに

import OpenSeadragon from 'openseadragon/build/openseadragon/openseadragon.min.js';

っていう風にすれば組み込めました。あとは普通にmethods:以下のどこかに書いていけば いいようです。

複数画像を読み込ませる時は tileSources: に複数のタイルソースを書いていけばよく、 たとえば、info.jsonファイルのURLを配列で列挙していくことになります。これも reactiveにできるのかもしれませんが、今のところあまりメリットを想像できなかった ので、とりあえずtileSources:の中身はmethodsの中で完結させています。

それから、OpenSeadragon、ローカルファイルでも、ファイル名を指定するだけで読み込める んですね。本日、主に試していたのはその機能に関することでした。 ユーザ側が混乱しないか注意する必要がありそうですが、これはこれで活用したい ところです。

jQueryをやめてvue.jsに取り組んでいてハマったところ

詳しくはまた別途書くとして、とりあえず、10年以上jQueryを使ってきて、とうとうvue.jsに切り替えることにして一からサイトを作り直している際に色々なところにハマったので、忘れないようにメモ。vue.jsでハマったというより、jQueryをやめたことでハマったということとか、単に忘れていたこととかですが。（しかも断片的すぎて読者の皆様にはあまりよくわからないかもしれませんがご容赦ください）

• v-showはDOMをそのまま残してdisplay:none的なことをするようだがv-ifはいちいちDOMを書き換える模様。

• v-* エレメントやvueのアプリとして組み込んだものは実際に表示される際にはエレメント名が変更される （多くはdiv等の一般的なものになる）ので、普通のJavascript関数からDOM操作しようとするとそのまま 指定することはできないので要注意。

• 仮想DOMの値の中に直書きしたエレメントを普通のJavascriptでDOM操作する場合、 仮想DOM設定後、すぐには操作できないので注意が必要。

• event.preventDefault() はJavascriptのメソッドなので普通に使える。

• element.setAttribute() は、つけたelementに直接作用する。左辺で受けるとうまくいかない。

• OpenSeadragonの表示用divエレメントは縦サイズを決め打ちする必要あり。相対サイズ（%）も許容しない模様？。

• Right-to-Left pagingのために OpenSeadragonのページ遷移ボタンの左右を入れ替える場合は

if(r){this.paging=new m.ButtonGroup({buttons:[this.nextButton,this.previousButton] のあたりでButtonGroupの順番を入れ替えて画像も左右を入れ替えればOK。

まだまだ続きます…