再帰法とメモ化アルゴリズム

再帰を用いたフィボナッチ数列の計算と，メモ化による処理の最適化についての説明です．デモンストレーション付き．

フィボナッチ数列とは，f(n) = f(n-1) + f(n-2),  f(0) = 1,  f(1) = 1 で定義される数列です．その値を再帰的関数として定義します．ただし，単純な再帰的定義だと，同じ計算を何度も行うことになり，非効率です．そこで，メモ化という処理を加えます．デモンストレーションで，その効果を体験することができるでしょう．

新刊書籍の紹介（Webアプリケーション開発の教科書）

2021年4月に技術評論社から出版した「最短距離でしっかり身に付く！ Webアプリケーション開発の教科書 ～Ruby on Railsで作る本格Webアプリ～」は，Webアプリ開発のイロハを紹介する書籍です．

著者の自分が言うのもなんですが，この本の一番の面白さは，実際に手を動かしながら本を読み進めていくと，それなりのアプリをきちんと作り上げることができるところです．しかも，当時院生だった中村絵理子さんがきちんとデバッグしてくれて，記述のおかしなところ，間違っているところ，不足しているところなど，全て潰してくださったので，ほぼ迷うことなく最後まで演習を進めていくことができるようになっています．

2021年5月29日に，Open Source Conference 2021 Nagoya (Online) のオンラインイベントで入門セミナーを実施します．無料ですので，Webアプリ開発に興味のある皆さんは，ぜひ受講して，面白いなと思ったら，本書を読んでさらに学習を深めていただければ幸です．

【目次】

第1章　開発環境の導入

1.1　Webアプリの構造

1.2　開発フレームワークとは？

1.3　Ruby on Railsと開発ツール

1.4　Rails 環境の導入

1.5　第1章のまとめ

第2章　匿名電子掲示板を作ってみよう

2.1　Railsを学ぶ前に

2.2　Railsの第一歩

2.3　シンプルな電子掲示板

2.4　第2章のまとめ

第3章　簡易SNSを作ってみよう（基本編）

3.1　作成するシステムの概要

3.2　ユーザ管理の導入

3.3　ユーザ管理のカスタマイズ

3.4　マイページ機能

3.5　投稿機能

3.6　第3章のまとめ

第4章　簡易SNSを作ってみよう（発展編）

4.1　体裁（見た目）の修正

4.2　新着投稿への対応

4.3　便利な機能の追加

4.4　Herokuへ配備

4.5　第4章のまとめ

第5章　オンラインイベント支援システムを作ってみよう（基本編）

5.1　複雑なモデル

5.2　トラックやセッションの管理

5.3　ユーザ管理とマイページ

5.4 　「参加登録」機能

5.5　第5章のまとめ

第6章　オンラインイベント支援システムを作ってみよう（発展編）

6.1　レコメンデーション機能

6.2　管理者機能の追加（前半）：イベントとデイの管理

6.3　管理者機能の追加（後半）：トラックとセッションの管理

6.4　第6章のまとめ 

なぜ一周360度は2πなのか？

オンライン授業は成績の格差を助長する？

だいぶ前に「オンライン講義 vs 対面講義」と題して海外の記事がそれぞれのメリットとデメリットを指摘しているという記事を紹介した．この記事の指摘はしごくもっともだと思うし，今でもオンライン講義はオンライン講義の良さがあり，対面講義には対面講義の良さがあり，どちらに寄せるという議論には意味がないと考えているが，最近，どうにも気になることが出てきた．それは，オンライン講義は成績の下のほうの学生を救いにくいのではないか？という，教育としてはある意味で致命的ですらある懸念である．

具体的には，本人に学習意欲があるのに，理解が及ばず，それが積み重なって落ちこぼれてしまうというケースである．

対面の講義では，残念ながらあまり理解できていないけれども学習意欲は強く持っているというタイプの学生が，講義終了後に居残って，ほぼ毎回，質問に来るという状況がしばしば見られた．他方，今期，オンラインの講義（科目は1年生の数学）が半分近くまで進んだところで，やる気はあるもののどうにも理解が難しくなってきているという学生の悲鳴が目立つようになった．

提出された課題には「全て」フィードバックコメントを返しているので，そのような学生の「どうしたらよいでしょう？」という叫びが痛い．できる範囲でオンラインで詳しく説明を返しているものの，常々，私が指摘しているように，コミュニケーションのバンド幅という意味で，限界がある．

最後は「どうしても分からなかったら，いつでも質問に来なさい」と手を差し伸べている．実際，一昨年までは，研究室にちょいちょい学生が質問に来ていたし，昨年も完全オンラインだった前期はともかくとして，対面が再開した後期は何度か実際に学生が質問に来た．幸にして今は対面講義もまだ一部実施しているので，そのタイミングを合わせて質問に来てもらうぶんには，こちらは全く構わない．

仲のよい学生同士で相談しながら課題に対応している様子も伺うことができる．これも，一部，対面を実施して大学に登校させているからならではであろう．もちろん，完全オンラインだったとして，どこか別の場所に集まってということもあり得るが，頻度と可能性の観点から，やはりキャンパスで集まることの意義は大きい．

一方で，「先生に連絡をとりたくても取れない」という学生の悩みも耳にする（これはあくまで世間一般のケースとお断りしておく）．そんな状況ではどうしようもなく，やる気がある学生であってもポロポロと脱落してしまいかねない．勉強のやり方を熟知していて，自分で自律的に学習することができ，自分のペースで学ぶことができる優秀な学生にとって，オンライン学習はやりやすいのかもしれない．しかし，はたしてそれでよいのか？という懸念を払拭することは今の私にはできない．

学会はどうあるべきか

ずいぶんと昔の出来事ではあるが，2012年のFITでスペシャルなセッションがあった．私もその場に居たかったのだが，事情があり居合わせることができなかった．FIT2012には私も参加し発表もした．しかし，私の関与したセッションは当該セッションとは別の日であった．今から思うととても残念である．

そのスペシャルなセッションについては，その場に居合わせた方が一連のツイートで状況報告してくださっていて，当時の状況を偲ぶことができる．しかし，他人のツイートでありいつ消えてしまうかわからないため，記録の意味で，連続するスクショを撮って残しておくことにする．

一連のツイートを残してくださった @reo_kashiwazaki 氏にはこの場を借りて御礼申し上げる．以下，あえての解説ヌキ，ツイートの紹介に留めておく．

イントロダクション

A-039セッション

A-040セッション

アクセスログからみる人間の社会活動

今回は少しいつもと毛色が違う社会情報学的な話題を提供する．次のグラフは，本ブログに関して設定されている，Google Search Consoleの検索パフォーマンス画面で表示されるグラフである．

昨年の4月からこまめにブログを書いてはアップするようにしたので，その成果が出ているのか検索結果として飛んでくるアクセスが緩やかな右肩上がりで増加している点は，まあ，有難い限りである．

ところで，このグラフを見ると，細かに振動していることに気づくだろう．これは，1週間のサイクルで増減が繰り返されていることを示している．週末は比較的アクセス数が少なくなる傾向がある．ブログの投稿は平日，週末，あまり気にしていないので，投稿のタイミングに差はない．これは，あくまで，情報の受け手側，検索してアクセスしてくる皆さんの都合が反映されたものだ．

このようなグラフ，最近ではよく目にするのではないか．そう，COVID-19の感染者に関するグラフである．毎日毎日，まあ，飽きもせずメディアは報道しているので，嫌でも目にすることがあろう．日次で集計されているあれも，このような周期性を示している．

これらは社会が1週間という単位で動いていることを明確に示すエビデンスである．様々なデータを，社会を読み解くカギとしてみると，いろいろなことが分かって面白い．

IT業界，温故知新（5）

しばらく間があいてしまったけれども温故知新シリーズの第5弾です．前回はこちら．

パソコン苦手組とIT（2000年7月4日）

技術が進化していないので高齢者にとって敷居が高いんじゃないか？という話．20年経って，技術のほうはだいぶ進化したようだが，人間の側が未だに対応できていないような状況だろう．

たとえば記事でも出ているタッチパネルの例．パソコンの画面は細かいからタッチ操作に向かないという事例だが，その後，iPadなどタッチ操作が中心のデバイスが普及したことによって，タッチ用に最適化されたインタフェースが提案されるようになってきた．

しかし，意外と知られていないのが，高齢者の指先は乾いていてそもそもタッチ操作をうまくできない問題があるということだ．この問題，指先をぺろりと舐めてから操作せよ，というわけにもいかない．画面が汚くなるし，スマートフォンやタブレットデバイスのタッチ画面はバイキンも多いらしい．不健康である．

今後，ますます進む社会の少子高齢化にあたっては，もう少し真剣に考えなければならない問題なのではないだろうか．

キオスク端末を作ってみよう（2000年9月19日）

この記事で紹介されているようなWindowsベースのキオスク端末だけでなく，世の中には汎用OSを活用したキオスク端末や情報端末が溢れるようになった．まあ，簡単だからね．しかし，厳密に管理するのは意外と難しかったりする．

とくにやはりWindowsベースで手軽に作ってしまうのはややリスクが大きい気がする．よく，巷でブルースクリーンになっている情報端末やサイネージを見ることがある．24時間365日の運用には向いていないOSなんだから，そのあたりはしっかりしてほしいと未だに思うところだ．

手の中の秘書〜エージェントシステム〜（2000年12月5日）

エージェントシステムは，秘書エージェントとはやや違う方向で進化を遂げて社会に普及した．皆さんおなじみSiriたんやAlexaなどだ．もちろん秘書的に使うこともできなくはないが，秘書というよりはどちらかというと友達や家族の一員という感じで認識されることが多いのではなかろうか．

進化の過程としては，そのあり方もアリであろう．かなり性能がよくなったとはいえ，未だに完璧な対話を実現できているわけではない．かつての人工無能に比べればはるかに人間らしいサービスを提供するが，ときとして素っ頓狂な，あるいは素っ気ない回答が戻ってきたりもする．

秘書としてはまだ頼りないが，友達や家族なら，まあ，というところか．デジタルネイティブの子供たちにとっては兄弟のような存在として認識している例もあると聞く．それはそれで，微笑ましい状況でもあろう．

OSI参照モデルの包容力

前回の記事「WWWブラウザになってプロトコルスタックを理解する」をSNSで紹介したところ，「せっかくならOSI参照モデルで、ちゃんと7層しっかり教えて～(笑)／トランスポート層からアプリケーション層は端折りすぎ(^_^;」というコメントをいただいた．たしかに上の3つをざっくりとまとめてしまっているわけだが，この問題，昔から長いこと違和感を覚えている部分であった．せっかくなので少し真面目に考えてみることにするか．

OSI参照モデルに感じる違和感の正体

これまで長いこと，OSI参照モデルの上のほうには疑問を持っていた．TCP/IPのモデル，インターネットの4階層モデルはいたってシンプルで，パケットをヘッダ（と，トレイラ）でくるりんと包み込んでいくイメージを考えれば，上の層は下の層を必ず使っていることがわかる．それゆえに上下関係が明白であるというメリットがある．SNSでどなたかが「マトリョーシカのイメージで説明すれば？」とアドバイスされていたが，そんな考えでもよいかもしれない．

図はWebサイトとのやりとりを具体的に考えてみたものだ．アプリケーション層ではHTTPで通信が行われる．HTTPで送受信されるメッセージ（リソース）は多くの場合巨大なので，パケットに分割され，そこから下はTCP→IP→物理層，というようにそれぞれのレイヤで付加情報が付けられて送信される．

一方，OSIの7層モデルを改めて考えてみよう．次の表はアイティーエム株式会社が提供するITコラム「OSI参照モデルとは？TCP/IPとの違いを図解で解説」に記載されていたものである．

ここで，アプリケーション層からセッション層までのプロトコルをぐっと眺めてみると，あることに気付かないだろうか？

このあたり，階層の上下関係が極めて曖昧なのだ．そもそも，SMTPやFTPに至っては6層と7層の両方に出てきてしまっている．なにそれ．せっかく階層で表現してるのに．

OSI参照モデルの「余裕」

いったん，先に紹介したHTTPの例に戻ろう．昨今，セキュリティ最優先の時代なので，HTTPはもはや推奨されない．HTTPSでやらねば，ね．

というわけでTLSのレイヤーをどこかに入れなければならないわけだが，はて，4層モデルで，どこに入れればよいのだろう？層が足りないぞ？

ここでOSIのモデル（表）を再度みてみると，TCP，トランスポート層の上にTLSの層があるじゃない．セッション層でTLSを入れてやろう．アプリケーション層はHTTPSのままでよかろう．プレゼンテーション層が抜けてしまうが，これで表現できる．

そして表の右端にあるカラム「利用例」のところをみてみると……えええ？セッション層にHTTPSが並べられているやんけ！おいおい．HTTPはアプリ層なのに，Sが付くといきなりセッション層になっちゃうの？その上にHTMLが来てる．プレゼンテーション層としてHTMLというのはわからなくもない．表現形式だからね．プレゼンテーションだ．そしてその上のアプリケーション層に「www, メール」？それってプロトコルなの？

結論めいたもの

さて結論（めいたもの）を述べる．OSIの7層モデル，上の方は無理くり階層として考える必要はないのではないか．5〜7層のあたりは，場合によっていろいろと対応する．上下関係が生じることもある，そんな緩い扱いで捉えておけばよさそうだ．

冒頭のコメントをくださった方に確認してみたところ「まぁ，標準化の為に考えられたモノだから無理矢理感，無駄はあると思う(笑)」だってさ．そんなもんだよね．

M1 Mac がやってきた（ソフトウェア設定編（5））

これまでの手順はこちら（開封編，設定編1，設定編2，設定編3，設定編4，Rails導入編）．

brew install --cask でインストールできるThunderbirdがまだM1ネイティブに対応していない件については設定編1で報告した．しかし，現在の最新版，version 87b2 の時点でM1対応はしているはずなのだ．まあ，焦らず待っていればよいのだが，何気なく homebrew のウェブサイト見てたら，thunderbird-beta とコンフリクトするでぇ？って書いてあるじゃないの．

というわけで，次の手順で thunderbird-beta を入れてみた．

mac5:~ iiojun$ brew tap homebrew/cask-versions

(略)

mac5:~ iiojun$ brew install --cask thunderbird-beta

(略)

mac5:~ iiojun$ 

これでThunderbirdの新しいやつをインストールできる．動かしてみた．ちゃんとM1対応している．めでたし，めでたし．

なお，正式バージョンがM1対応したときは，いったんデータを退避したあとでいったん brew uninstall thunderbird-beta し，untap homebrew/cask-versions してから再度 brew install thunderbird とすればよいのだろうな．

IPAフォントのインストール

IPAフォントを使う機会があるので，下記からIPAfont00303.zipとIPAexfont000401.zipなるファイルをダウンロードして，インストールした．

IPAフォント Ver.003.03

IPAEXフォント VER.004.01IPAEx Font Ver.004.01

展開して，フォントのファイルを開くと「フォントをインストールする」というボタンが出てくるので，それを押せばOK.

WWWブラウザになってプロトコルスタックを理解する

大学1年生向け「情報」の授業で，通信プロトコルの解説をしていて，そのなかで，階層的になっていることでわかりやすくなっていること，相互運用性を確保していることなどを説明している．この考え方，ひとたびわかってしまえば「なるほどよく考えられているなあ」と，すっと納得できる概念なのだが，初見では，分かりづらいのかもしれない（OSIに文句を付けるつもりはないが，7階層モデルがさらに話をややこしくしているように思う）．

TCP/IPのモデルによる説明

身近な通信を題材にするのが少しでもわかりやすく説明する秘訣らしい．というわけで，ウェブサイトへのアクセス，HyperText Transfer Protocol（HTTP）を例にとって，HTTP以下の階層を具体的に説明している（図）．

とくにピンと来ないのは，それぞれの階層の関係性がよくわからないせいらしい（上位と下位を入れ替えたらどうなりますか？などという質問すら出る）．実際にはアプリケーションやミドルウェアがそれぞれの関数を呼び出して，下の階層のサービスを利用しているのだということがわかれば，あとはすんなり理解できるはずなのだが，経験に裏打ちされていないので，そこが理解しづらいと感じるようだ．

「WWWブラウザになる」デモ

そこで，ウェブサーバに「手で」アクセスするデモを行う．HTTPによるWebサーバとの通信を理解させるのにtelnetを用い，「telnet servername.serverdomain 80」と実演するわけだ．このデモンストレーションは確かに効果がある．このデモを行うと，面白かったとか，感動したとか，前向きな反応が多く得られる．

時間があれば，そこで何が行われているのか？を事細かに説明するとよかろう．すなわち，次の図で，通常は左側のように，WebブラウザにURLを入力すると，ソフトウェアの内部でHTTPのコマンドが発行され，プロトコルスタックを辿ってデータが通信される．一方，telnetによるデモンストレーションは，ブラウザ部分をtelnetが肩代わりしてTCPを直接話せるようになるので，人間がHTTPのコマンドを「手で」入力して発行しているのだよ，という説明である．

このように丁寧に説明すると，学生の理解も早い．学生が提出した課題とそれに対するフィードバックメッセージの例を紹介する．彼はきちんと理解できたことを確認できるだろう．

学生のコメント：
TCPとはHTTPと似たようなもので　メッセージ等を送ったり受けっとたりするための　”通路”　のようなものを生み出すプロトコルと捉えてよろしいでしょうか？

教員のフィードバック：
そうです．TCPは汎用的な　”通路”　を作りだします．WebブラウザとWebサーバはその通路を使って，「GET / HTTP/1.1」（サーバはん，あんじょう頼んまっせ）→「HTTP/1.1 200 OK ... 」（まかしとき！レスポンスはこうやで！）というようなやりとりをするわけですね．そのやりとりの取り決めがHTTPというプロトコルというわけです．

このあたりの教育に携わっている皆さんがいらっしゃたら，ぜひ，お試しください．

M1 Mac がやってきた（ソフトウェア設定編（4））

TeX環境もM1ネイティブ対応しているらしいと聞いた．さっそくインストールしよう．「M1 MacへのTex導入方法【2021年版】」などを参考にした．なお，これまでの手順はこちら（開封編，設定編1，設定編2，設定編3，Rails導入編）．

brewでMacTexをインストールする．サイズがでかいのでダウンロードにかなり時間がかかる．

mac5:~ iiojun$ brew install --cask mactex

(略)

mac5:~ iiojun$ 

何事もなく無事にインストールできる．tlmgr（TeX Live Manager）でパッケージを更新する．

mac5:~ iiojun$ sudo tlmgr update --self --all

sudo: tlmgr: command not found

mac5:~ iiojun$ 

ところが，エラーになる．前述のネットの情報や，他の情報をみると，パスを通せと書いてある．まあ，現象は全くそのとおりなんだけれど，スクロールしてbrew install の出力を振り返ってみてると……

You must restart your terminal window for the installation of MacTex CLI tools to take effect.

Alternatively, Bash and Zsh users can run the command:

  eval "$(/usr/libexec/path_helper)"

ちゃんと書いたあるがな．

MacTexのCLIツールのインストールを有効にするにはターミナルのウィンドウをリスタートせにゃならんで？BashやZshつこてたらこのコマンド叩くんでもええで？
eval "$(/usr/libexec/path_helper)" やで！（超訳）．

そんな難しい英語でもないし，きちんと読めや！（苦笑）

というわけで，正しく指示通りの作業をする．173パッケージもあるので，tlmgrによるアップデートはかなり時間がかかった．

mac5:~ iiojun$ eval "$(/usr/libexec/path_helper)"

mac5:~ iiojun$ sudo tlmgr update --self --all

(略)

mac5:~ iiojun$ 

アップデート作業で一箇所だけ実行できなかった箇所があったらしく，最後，エラーが出てきてちょいとドッキリしたが，まあ，ログをみると Restoring old package state succeeded とか出てるから，ヨシとしよう．再度アップデート作業をして確認したら，とくに問題なく終了した．

とりあえず，次もやっておく．

mac5:~ iiojun$ sudo tlmgr paper a4

(略)

mac5:~ iiojun$ 

platex も dvipdfmx も，M1ネイティブでちゃんと動くよ．

300ページ超える文書のコンパイル作業したら，速いなー！さすがに画像貼りまくりの書類なのでdvipdfmxはそこそこ時間がかかったが，それでもだいぶ速い．M1すごいぞ．

M1 Mac（2020 MBP13'' memory 16GB）でのコンパイルからPDF作成まで．1分切った．

Intel Mac（2018 MBP13'' memory 8GB）でのコンパイルからPDF作成まで．1分38秒．コーヒー飲んでゆっくり待とうかw

今日はここまで．

オンライン会議ツールが備えるべき気の利いた機能とは

いつもZoomのほうがWebexより使いやすいかなあなどと呟いているが，WebexにはWebexの良さもある．たまにはそんな機能も紹介してみよう．ZoomではないがGoogle Meetをお使いの先生が，画面共有してそちらを操作してると参加者の様子がわからないとボヤいてらして，それWebexならできるよと．

この図は，Webexを利用中にKeynoteの画面を共有している状況である．この状態では，配信先の学生たちが見ている画面の様子は，わからない．

そこで，上のオレンジ色のタブにマウスポインタを乗せると，Webexの操作画面が出てくる．

さらに，この状態でタブの下にある「v」をクリックすると，相手に届いているはずの画面がサムネイル形式で，出てくる．これ，これなんだよ欲しかった情報は．

たとえば，この状況だとKeynoteの画面が片隅に小さくしか表示されていないことがわかる．そこでこの状態でプレゼンテーションモードに切り替える．

これが望ましい画面ということになる．これで安心してオンライン授業を続けることができるだろう．

他にも，Webexだと相手が画面共有しているときに，共有画面を対象にしてタッチパッド等でピンチイン・ピンチアウト操作をすると，ズームイン・ズームアウトできるのもありがたい．細かい文字が書かれた資料を共有されたときに，老眼が進行中の私にはたいへん助かる機能である．Zoomにもモバイル版だと同様の機能があるが，PC版だとできないみたい．Zoomなのにね……

査読制度の穴

昨日書いた「論文の査読制度」と題するエッセイのなかで，査読制度も完全ではないという話題についてちょっとだけ触れた．今日はその補足というか，こんなこともある，ということを記しておきたい．

これは2020年3月26日に私がFacebookに投稿したコメントである．とある国際会議のTPC（Technical Program Committee）を拝命し，投稿された論文を査読していたときの出来事を紹介したものだ．見て分かるように，これは「剽窃」の典型例である．

コピペはばれる

「他にもこんなんがてんこ盛りで残念…… 内容はそれほど悪くないのに」とコメントを付けたところ，「まあ，その通りだとは思うけど，SNAPの本家がそういう説明をしているので，それに近い説明になってしまうのは致し方ない，というのは甘いでしょうか？」との指摘をいただいた．しかし，これ，語順を微妙に変えていて，ずるい．本人にも悪気があり，故意にやっていることは明らかであろう．

他にも，次のような，微妙に表現を変えているけれども，ほぼ同じ，という表現がてんこ盛りになっていた．これはもう，クロと判定せざるを得ない．

（当該論文からの抜粋）
Igraph is a suite of network analysis tools focused on performance, portability & user-friendliness. Igraph is a free and open-source package. Igraph can be programmed in R, Python, Mathematica and C / C++.
（元ネタと思しき記述からの抜粋）
igraph is a collection of network analysis tools with the emphasis on efficiency, portability and ease of use. igraph is open sourcfe and free. igraph can be programmed in R, Python, Mathematica and C / C++.

この論文，各種のツールを比較して云々というもので，それらのツールの紹介がほぼウェブサイトからの剽窃というものであった．こういうのは分かってしまうのだ．文の匂いというのだろうか．論文の文章らしくないなーと感じるので，ググるとだいたい発見できる．

査読にも限界が

しかし，査読にも限界はある．アマアマな査読者，あるいは，これを見抜けない査読者は居るのである．もっとも，彼らの目をフシ穴と言うなかれ．前稿で紹介したように，本来は自らの研究で，そして大学の研究者であれば研究と両輪とされる教育に時間を取られていて，査読者も多忙なのだ．

先に紹介したFacebookへの投稿には「リジェクトされても，別の論文誌に出すんでしょうね．貴重な査読者の時間を無駄にするので，このような行為はどうにかしないといけませんよね」というコメントも付いた．その通りである．

この論文をクロと判断した私は当然ながらリジェクト，それもお灸を据えた理由書を添えて突っ返したが，案の定，別の国際会議の予稿集に同じ原稿を発見した！（正確には同じ原稿と思しきものを発見した）…… 通してしまった査読者がいた，ということである．どうも全く修正せずに投稿しているらしい．いやはや舐められたもんだな，という気持ちがないこともないが，とりあえず名前だけはメモしておくことにしよう．

論文の査読制度

論文や学会発表において第三者がレビューをして採否を審査する「査読」という制度がある．アカデミアにおいてはごく一般的な慣習だが，馴染みのない方も多いかと思われる．

なんのために査読があるのか，結論を先に述べると，それは論文や発表の質を担保するためである．

次の図は，拙書（飯尾, 2019）の「2.5 客観的な情報であるべき『論文』」から引用したものである．論文誌に原稿が投稿されてから出版に至るまでのプロセスを示している．

実際に出版に至るまでには，通常，複数回の査読が行われる．このプロセスにより，内容に問題がないか，この原稿は学術的に価値のあるものかどうかをチェックしており，そのチェックをクリアしたものだけが（建前上は）科学に貢献するという建て付けになっている．

研究者の努力に支えられた査読制度

質の保証という意味で査読制度がそれなりに有効に働いているのはこれは紛れもない事実で，それを研究者のボランティアが支えている．査読という作業に対して謝金が出る場合が「ごく稀に」あるが，実際には，ほぼ，無償奉仕の作業である．私自身，記述言語の日本語・英語を問わず，年に少なくない数の論文を査読しており，それなりに貴重な時間を費やして協力している．

なぜ，私はボランティアで査読に協力するのだろうか．それは，若かりし頃にどうしようもない論文を何報も投稿しては不採録または条件付き採録を繰り返してきた私，未熟な若輩者であった私を厳しい査読の過程で指導してくださった，良識ある査読者からなる科学コミュニティの皆様への恩返しの気持ちがあるからである．

いまでも，不採録通知に記された「このテーマに関して論じるのであれば，この論文を読みなさい」などの丁寧な指導は記憶に残っている．当時，不誠実な査読者にあまり当たらなかったのは，ラッキーだったといえよう．酷い査読者のレビューは意図的に忘れてしまったのかもしれないが．

問われる査読者の力量

ところが，この査読という制度，残念ながら品質の担保という面でも完璧なものではなく，査読者にそれなりの力量が求められるのも確かではある．以前，「あんた標本化定理（※1）って知ってるか？」というレベルの，理論的な信頼性が欠如している論文を査読したことがある．その論文はリジェクトして戻したが，1年後ぐらいだったか，別の学会の某トランザクション（※2）にその論文が掲載されていたのに気付いたのには唖然とした．そういう例もある．

査読で有用性や新規性を的確にチェックするのは難しいという指摘（鳥海, 2021）もある，新規性は，通常，関連研究を引いて「いままではこうだったけど，僕らのはこの点で違うからエラい」とやって示す．しかし，サーベイには限界があるので，査読者の知見をもってしても漏れは生じうるものであり，ある程度は致し方ないところがある．

もっとも研究者側も研究倫理というかきちんとしたルールは守っていただきたいところはある．ある学会に投稿された原稿が私のところに回ってきたが，査読の結果，掲載の基準には達していないと判断し，リジェクトした．ところがその数週間後，全く同じ論文に関する査読依頼が再び別の学会から回ってきた．不採録理由として私が示した改善点は，一切，更新されておらず，全く同じものである（※3）．

こういうのは「即，却下」である．不採録理由は一言「某学会で指摘された改善点が更新されていない」で十分．しょせんニッチな研究テーマなので，複数の経路で同じ査読者にたどり着くことは蓋然性が高い．そのくらいの想像力は研究者の常識として持っていていただきたいものである．

考え方や査読方針の差異

落とすこと，あるいは文句つけることが権威だと勘違いしてる査読者をたまにみかけるが，そのような査読者の存在が査読制度の落とし穴になっていることにも留意したい．また，自分の専門知識や慣習に固執する査読者が散見されることも事実．たとえば関連研究のセクションを置く位置について，こんな話がある．

私は，Simon P. Jones がHow to write a great research paper（Jones, 2018）で言及している「読者の興味は『あなたの主張』にあるのであって，関連研究になんてほとんどの読者は興味ないんだから，後でいいでしょ？」という考え方に強く共感する．それ故に，通常，論文の最後に置く「まとめと将来展望」のひとつ前に，関連研究への言及を置くスタイルを好む．

しかし，石頭の査読者にあたると「関連研究は序章の次に置くべきだ云々」と古臭い指摘をされることがある．驚くべきことにというか残念ながらというか，私は，けっこうな頻度でこの指摘を経験している．まあ，条件付き採録（※4）を頂戴したときは投稿者は弱い立場であり，査読者に喧嘩を吹っかけるのは得策ではないので，（はいはい守旧派ごくろうさん）と思いつつも自我を押し殺して査読者様の仰るとおりに修正する．ただし，回答書（※5）には「Simon P. Jones の意見が正しいと思うけれども今回は査読者の指摘に従います」というコメントを忘れずに入れる．私もまだまだ青いなと思う次第である．

なお，小さな学会では甘めに査読することも多いだろう．私が論文誌の編集委員をやっている人間中心設計推進機構の場合，投稿者や発表者のなかに，そもそも論文投稿に慣れていない人も多くいる．そこで，査読者には，教育的な意味も含めて「甘めに査読して条件付きでも論文投稿自体を鼓舞するような指摘をしてください」とお願いしている．また，ぶっちゃけ話をすると，小規模学会では論文を投稿する可能性を持つ母集団の小ささに比例して投稿数も少なく，厳しく査読すると論文数が足りなくなってしまう，という台所事情もあろう．

その他，査読制度が抱える現在の問題点と対策については，同志社大学の佐藤が詳しく論じている（佐藤, 2014,  2016）．参考にされたい．

査読のない論文

前項まで査読論文に焦点を当てて論じてきたが，世の中には「紀要」と呼ばれる論文集も存在する．紀要とは，大学等が勝手に出している論文集で，査読なしのものが多い．査読のプロセスがないので，論文の体裁さえ整っていれば掲載してもらえる．したがって，研究業績としての価値はあまり高くないものとされる．

ところで，もし，学術論文誌も含めて世の中に査読制度が全く存在しなかったらどうなるだろうか．まず，品質の伴わない論文が世の中に多数出回ることになる．そのような論文を読まされるのはしんどく，非効率であるという問題が生じる．また，読む人の時間がもったいないだけでなく，社会に悪影響が及ぶケースもある．

こんな例が実際にあった．

中部地方某県にある国立大学の紀要に掲載されていた論文のなかに明らかに間違った主張があり，ところがそれを引用してSNSで「大学の先生が論文で主張しているんだから間違いない」のような権威付けがなされて，間違った事実が流布されてしまったというケースである．私の関連分野でもあり，困ったなーと苦々しく感じていただけでなく，「それは紀要だから誰もチェックしておらず，間違っている情報が記載されているのだよ」と叫ぼうにも，誰も聞く耳を持たず，という状況が生じた．そういうのはダメだろう．

プレプリントや紀要の意義

ところで，最近はプレプリントサーバー（※6）なるものが流行ってきているらしい（尾城, 2020，林, 2020）．プレプリントは速報性が担保されるというメリットはあるが，プレプリントが広まると，流通する論文の質が一気に低下することを懸念している．その結果として，情報検索時のノイズが増えるのではないかとちょっと危惧する．プレプリントというのは査読を経てない書きっぱなしの論文なので，質が担保されない．まあ，これは紀要を弾く手順と同様にすればいいのか…… やや面倒ではあるな．

紀要といえば，鹿児島大学の菅野による「紀要なるものを『知った』」という記事（菅野, 2017）が興味深い．紀要委員という立場で，大学の紀要にどのような意義があるかを冷静に論じている．「日本では，業績は論文の “数” こそがものを言う場面が多いので，査読付き論文はないのに紀要ばかり書いて数を稼ぐ研究者もいると，よく研究者界隈では揶揄されている」という指摘は耳が痛い．私が紀要論文を何本か書いているのは，けして，論文数を稼ぐため，ではないけれど（※7）．

自由奔放な論文が収録されていることを逆手にとって，紀要をエンターテイメント的に楽しむ人もいる．「ヘンな論文」（サンキュータツオ, 2015）およびその続編などは，楽しく読むことができる．そこで紹介されている研究をけして蔑むものではないが，「研究」というものへの間口を広げるためのツールとして，それなりに意義のある書籍ではあろう．

私の印象にとても残っているユニークな研究は，文教大学の福島によるものである．福島は，「観光英語」と銘打って，日本国内の観光地にある英語の案内を分析して回るという研究をずっと行われていた（福島, 2020, 他）ようで，同大学の紀要で私はそれを知った（※8）．その汎用性の高さに私は舌を巻き，いいもの見つけられましたな，いや，ライフワークなんだろうなあと感心した．観光英語の続きが気になるところだが，残念ながら2019年に定年でご退職なさったようだ．

まとめ

最後はなんとなくとりとめもない話になってしまったが，かように，科学技術分野における知見の蓄積は研究を推進する研究者本人だけでなく，それを取り巻く様々な人々に支えられているのだということを知っていただきたい．その中に査読者や編集委員なども含まれる．彼ら彼女らは自組織に戻れば自分の研究を進める研究者であることがほとんどである．このような互助努力で科学コミュニティは支えられてきたし，おそらくは，これからも支えられていくのだ．

（短い補足ですが続きもあるのでそちらもどうぞ → 次へ）

参考文献

• 飯尾 淳 (2019) 情報を集める技術・伝える技術 情報社会の一員として備えておくべき基礎知識，近代科学社Digital
• 鳥海 不二夫 (2021) 私の論文が採録されないのはどう考えても編集委員会が悪い！，人工知能, 36巻, 3号, p. 312
• Jones, S. P. (2018) How  to Write a Great Research Paper, 2017 Imperial College Computing Student Workshop (ICCSW 2017), OpenAccess Series in Informatics (OASIcs), Vol. 60, DOI:10.4230/OASIcs.ICCSW.2017.1
• 佐藤 翔 (2014) 査読をめぐる新たな問題, カレントアウェアネス, (321), CA1829, pp. 9-13.
• 佐藤 翔 (2016) 査読の抱える問題とその対応策, 情報の科学と技術, Vol. 66, No. 3, pp. 115-121.
• 尾城 孝一 (2020) 進化するプレプリントの風景, 情報の科学と技術, 70巻, 2号, pp. 83-86
• 林 和弘 (2020) ほらいずん MedRxiv, ChemRxivにみるプレプリントファーストへの変化の兆しとオープンサイエンス時代の研究論文, STI horizon = STIホライズン : イノベーションの新地平を拓く, Vol. 6, No. 1, pp. 26-31
• 菅野 康太 (2017) 紀要なるものを「知った」, Synapse the world, https://can-no.com/archives/802, (accessed at 9th May, 2021).
• サンキュータツオ (2015) ヘンな論文，角川学芸出版
• 福島 一人 (2020)  観光英語（17）：長崎県、島根県、山口県に見られる歴史的キリスト教関連遺産の総合案内板の英語, 情報研究, Vol. 62, pp. 31-53

注

1. 信号処理を扱う分野（情報系も含む）であれば大学のわりと早い時期に習うはずの定理．
2. この論文誌も歴とした査読付き論文誌のはずなんだがなあ．
3. 通常，不採録として返却した論文は破棄することになっているので，記憶を辿って同一性を判断したが，一字一句同じだったかはともかく，論旨や骨格は記憶のそれと全く同じであった．
4. 条件付き採録でもゆめゆめ油断するべからず．図に示したように，突きつけられた条件を満足にクリアできないと不採録を喰らうことがある．経験者は語る．
5. 条件付き採録あるいは条件付き再審査等のステータスを受けたときには，各条件をクリアすべく修正した論文を再提出する．一般的には，その際に「ここをこう直しました」と，詳細な説明を回答書と呼ばれる書類に記し，それも提出することになっている．
6. プレプリントとは，査読を経ていない書いたままの論文である．第三者の目が入っていないので質が担保されないが，速報性という点では意義がある．
7. いろいろとオトナの事情があるのだ．
8. まあ，実際には検索してたまたま見つけて，たどり着いたのだが．

M1 Mac がやってきた（ソフトウェア設定編（3））

brewでecho-sdをインストールする．これ，地味によく使うんだよなあ．

mac5:~ iiojun$ brew tap fumiyas/echo-sd

mac5:~ iiojun$ brew install echo-sd

mac5:~ iiojun$ echo-sd

＿人人人人人人＿

＞　突然の死　＜

￣Y^Y^Y^Y^Y^Y^￣

mac5:~ iiojun$ 

やったー．あとは，大学ライセンスのMS-Officeを入れた．これは，まあ，仕方がない．

続いて，brewでRをインストールする．

mac5:~ iiojun$ brew install R

(略)

mac5:~ iiojun$ R --version

R version 4.0.5 (2021-03-31) -- "Shake and Throw"

Copyright (C) 2021 The R Foundation for Statistical Computing

Platform: aarch64-apple-darwin20.3.0 (64-bit)

R is free software and comes with ABSOLUTELY NO WARRANTY.

You are welcome to redistribute it under the terms of the

GNU General Public License versions 2 or 3.

For more information about these matters see

https://www.gnu.org/licenses/.

mac5:~ iiojun$ 

よきよき．

ところで，当初brewでRをインストールしようとしたら，途中でインストーラがRosetta 2を要求し，結果としてエラーになった．どうもbrew install --cask Rとやったのがいかんかったらしい．

Rstudioをインストールしようとしてその原因が判明（次図）．Rstudioを使えるようにするためには，もう少し時間が必要そうだということか．

おまけ

ついでに，brewでImageMagickをインストールする．依存関係のせいでいろんなもんが大量にインスコされた．

mac5:~ iiojun$ brew install imagemagick

(略)

mac5:~ iiojun$ convert --version

Version: ImageMagick 7.0.11-12 Q16 arm 2021-05-09 https://imagemagick.org

Copyright: (C) 1999-2021 ImageMagick Studio LLC

License: https://imagemagick.org/script/license.php

Features: Cipher DPC HDRI Modules OpenMP(5.0) 

Delegates (built-in): bzlib freetype gslib heic jng jp2 jpeg lcms lqr ltdl lzma openexr png ps tiff webp xml zlib

mac5:~ iiojun$

OK．今日はここまで！

ITを学ぶ楽しさ

総研研究員から大学教員に身を転じて今年で9年目，非常勤で教えていた頃から数えればもう10年以上，大学でIT関係のあれやこれやを教え続けてきたことになる．ITの世界はとにかくスピードが速いから，いまだに新しいことを学びながら教えているという自転車操業感も否めないものの，それでも学生時代からかれこれ30年ほど培ってきた知識と経験を拠り所に，なんとか情報系の大学教員としては問題のない教育・研究を提供できてきているのではないかと自負する．なにより，ITを学ぶ楽しさを学生に伝えたいという熱意は未だ途絶えていない．

Webアプリ開発を例に

さて，ITを学ぶ楽しさってなんだろう？と大上段から振りかぶってみたものの，なかなか難しい問いではある．先月刊行した本（飯尾2021）を例に挙げて，考えてみよう．

まあ，宣伝と受け取っていただいて構わないが，この本のよいところは，Webアプリの根本的なところを基礎知識として解説しておきながら，実際に手を動かしてひとつひとつ確かめつつ理解していくことができるという点にある．

正直，Railsを触り出してまだ数年しか経っていない私が，なんだか偉そうにRailsの教科書などと書籍を出版したのは，これは「Railsの教科書ではないから」なのだ．いや，まあプラットフォームとしてRuby on Railsを使っているので，正味な話，Railsの教科書でもある．なんか哲学めいた話だな．しかし，あくまでこれは「Webアプリケーションの教科書」だから．

台所事情を話すとDjangoで？っていう案もあった．しかし，私はRailsのほうがまだよく分かっているということと，えー？Python？という好き嫌いの面もあり，RailsでWebアプリ構築の教科書を作ろうということになったのである．

ものづくりの楽しさ

本書の一番のポイントは，大学院ゼミの講義録をもとに作られている点にある．世の中には大学の講義録に基づく書籍は数多あれども，IT系の，このような技術解説書籍でそのような出自の書籍はあまりみないような気がするが，どうだろうか（以前，私が編著者で出したプロジェクトマネジメント入門（飯尾2009）の書籍も農工大での講義録を編み直したものなので，実は私の得意技ではある）．

そして講義録ベースだと何が嬉しいかというと，受講者の厳しいチェックが入っていることである．読者の皆様にも嬉しいはずだ．今回，ゼミ実施時に院生だった中村恵理子さんが入念なチェックをしてくださった．ゼミでいちど体験しているので勝手が分かっていたとはいえ，原稿を渡して，再度，通しで試してみて，厳しいダメ出しをしてくれた．そんなわけなので，めぼしいバグは全て潰されている．やはり，ソフトウェアだけでなく書籍でもテスト工程は大切だということだろう．

本書を読むときは，パソコンを脇に置いて手を動かしながら読んでいただきたいと願っている．1ステップずつ，しっかりと動作を確認しながら試していくことができるので，学ぶ楽しさ，ものづくりの楽しさも味わうことができるはずである．そしてまさに私が主張したかったITを学ぶ楽しさとは，ここにあるのではなかろうかと考える次第なのだ．

さらに知識を得る楽しさ

そしてある程度の知識を得ることができたら，さらに高度な書籍に手を出すことで，知識を深めていくことができる．まあ，これはITに限ったことではないが……．

本書で解説している範囲で十分にWebアプリを作って試してみることはできるとはいえ，著者である私にしても，実はまだよくわかっていないRailsの機能は多数残されている．あるいは，本書のターゲットはとりあえずそこそこちゃんとしたWebアプリを作れるようになれればよい，というところにある．それは，我々の用途としては小規模のアプリを作って小さなコミュニティで運用できれば十分だというニーズが多いためであり，大規模システムを構築する必要がないからである．

しかし，世間で実際にシステムを構築して運用するというケースでは，いろいろとシビアな条件を課されることもあろう．システムを止めないノウハウや，安定運用の手順も学ぶ必要があるだろう．そのようなニーズに対しては，次のステップで学んでいけばよいのである．ひととおり読み終えた時点で，次に進むだけの力はついているはずだ．

結論

こう考えてみると，やはり，ITを学ぶ楽しさというものは，不可能を可能にする楽しさというところにあるという結論に落ち着く．今回はたまたまWebアプリケーションというものを題材にしたが，べつに組み込みシステムだっていい．RaspberryPIとかArduinoとかハードウェアに近いところは，もっと「ものつくりの楽しさ」を体感できるかも．

あるいはAIや機械学習も，最近ではパッケージ化されて簡単に魔法のような情報処理を実現できるようになっているので，そのようなものも楽しそうだ．もっとも，ITを教えている教育者の立場としては，ブラックボックスを利用するばかりではなくて，内部へ踏み込む気概のある若者も育てていきたいと考えているが．

参考文献

飯尾淳, 最短距離でしっかり身に付く！Webアプリケーション開発の教科書 Ruby on Railsで作る本格Webアプリ, 技術評論社, 2021.

飯尾淳 編著, 中川正樹 監修, 演習と実例で学ぶ プロジェクトマネジメント入門, ソフトバンク クリエイティブ, 2009.

M1 Mac がやってきた（ソフトウェア設定編（2））

brewでPostgreSQLをインストールする．PostgreSQLもM1対応済みらしい．素晴らしい．

mac5:~ iiojun$ brew install postgresql

(略)

mac5:~ iiojun$ brew services start postgresql

(略)

mac5:~ iiojun$ createdb iiojun

mac5:~ iiojun$ psql

psql (13.2)

Type "help" for help.

iiojun=# \q

mac5:~ iiojun$

これでよい．

せっかくなので，Railsの新しいプロジェクトをPostgreSQLベースで作れるかやってみた．手順は「Rails導入篇」に示したものとほぼ同じだが，最初にbundle exec rails newするときに，-d postgresql を付けて実行する．あとは同じ．

ついでにscaffoldでオモチャ作ってみた．

mac5:RailsTest iiojun$ bin/rails g scaffold memo title:string body:text

Running via Spring preloader in process 24670

      invoke  active_record

      create    db/migrate/20210505033816_create_memos.rb

      create    app/models/memo.rb

      invoke    test_unit

      create      test/models/memo_test.rb

      create      test/fixtures/memos.yml

      invoke  resource_route

       route    resources :memos

      invoke  scaffold_controller

      create    app/controllers/memos_controller.rb

      invoke    erb

      create      app/views/memos

      create      app/views/memos/index.html.erb

      create      app/views/memos/edit.html.erb

      create      app/views/memos/show.html.erb

データベースを作成，マイグレーションも実施し……

mac5:RailsTest iiojun$ bin/rails db:create

Created database 'RailsTest_development'

Created database 'RailsTest_test'

mac5:RailsTest iiojun$ bin/rails db:migrate

== 20210505033816 CreateMemos: migrating ======================================

-- create_table(:memos)

   -> 0.0054s

== 20210505033816 CreateMemos: migrated (0.0054s) =============================

mac5:RailsTest iiojun$ bin/rails s

サーバ起動．動いた\( ˆoˆ )/