研究室Wikiの導入

小司優陸 / Shoji, Yutaka

2022年1月2日 18:31

1年以上前のことですが、所属研究室にナレッジベースとしてのWikiを導入したのでその決定プロセスをメモ。

研究室Wikiの必要性

「あの資料どこやったっけ...」
「またTA/RA/短期支援員の手続きか...」
「これ前に説明しなかったっけ」「聞いてないです」「それ多分僕です」

同じことを繰り返し説明するのって嫌すぎませんか。僕は嫌です。
A君には説明したけどB君には言ってないとか、これ毎年同じこと言うの面倒だなあとか、

世間にはWikiというものを使っている研究室・企業があります。
社内Wikiは基本的にクローズなのでどんなものか見れないですが、研究室Wikiはその研究室の対外用ウェブサイトを兼ねている場合も多いので見られました。こんなのです。

言われてみればこういう研究室HP見たことあります。
研究室でよく使う言語や実験器具、ゼミの予定なんかもまとめてあって情報共有の道具としてとても良さそう。

ということで研究室にWikiを導入するべく、Wikiシステムにどんなものがあるのか調べてみました。

Wikiシステムの選択肢

まずWikiシステムは提供形態で大きく2種類に分けられます。

オンプレミス型
クラウド型

オンプレミス

そのサービスを提供するサーバーPCを自分たちで立てて管理・運用するタイプ
("Service"を提供するコンピューターだから"Server")
セキュリティやバックアップとその復元など、保守を誰かがやらなきゃいけないが機能の拡張などもできる。
外部に情報を保存できない厳しい会社とかはこっちを使っている？

クラウド

クラウドっていう言葉は市民権を得て久しいので簡単に言いますが、サーバー管理をそのサービスを提供する組織が代わりにやってくれるもの。ユーザーはインターネット越しにそのサービスを受けられる。

世間で使われているWikiシステム

最近使われているWikiシステムはだいたいこんな感じらしい。

オンプレミス

無料：Pukiwiki, MediaWiki, GitLab Wiki, Crowi, GROWI, DokuWiki
有料：Confluence

クラウド

無料：GitHub Wiki, GitLab Wiki
有料：Confluence, Qiita:Team, GROWI, esa.io, Scrapbox, DocBase

参考

まず有料のものは敬遠しました。お金をかけずに済むなら越したことないので。(OSS大好き)

ということで検討したのは以下

PukiWiki

言わずと知れたOSSの国産Wiki。研究室のWikiを調べてみると一番出てくる。良くも悪くも昔ながらの研究室っぽい。PHPで動き裏でデータベースなどが動かないためバックアップなどが容易。

ただ古くからあるOSSのため開発があまり活発でなく、いつ止まるかわからない。
OSSは好きだし大学"らしさ"も好印象だが長く使うことを考えると...却下。

MediaWiki

言わずと知れたWikipediaのシステムである。OSS
Wikipediaのような大規模かつオープンなWikiのために作られているため、小規模クローズWikiには適さない。却下。

GitLab Wiki

GitLabはオンプレミスでも使えるOSSであり、クラウドサービスもある。
GitLab自体はGitリポジトリのホスティングサービスだけど、リポジトリの説明のためのWikiページを作れる。

これを使っても良いかと思ったが、多機能すぎて繁雑感があった。
クラウドサービスは無料でも使えるが、1リポジトリ10GBまでの制限があり微妙。
オンプレミスのサーバーはそんな制限もないので(PCの容量次第だが)一度立ててみた。

インストール自体はdockerを使えばわりと楽だったけど、裏でデータベースが動くため定期バックアップとリストアが少し面倒になる。機能/UIの良さと労働コストが釣り合ってないなあと思ったのでWiki用途としては却下。

GitHub Wiki

GitリポジトリホスティングサービスとしてはGitLabよりこっちの方が有名。
OSSではない。
Wikiとしての使用感はGitLabと似たような感じだが、無料で使うには公開リポジトリにしないといけない。
全部オープンにするのは研究室Wikiとしてうまくないので却下。

Crowi

Crowiはヤフーに吸収合併されたクロコスという会社で自家製の社内Wikiとして使われていたもの。吸収のタイミングでOSSとして公開された。
その後メルカリの社内Wikiとして導入され、全社的にナレッジはCrowiにまとめられているとか。

モダンかつシンプルなUIで良かったけど、OSSらしくマニュアルはほとんどなし。コミュニティの情報を見るしかない。そこまで後任に綿々とITリテラシーを継承できる気がしなかったので泣く泣く却下。

GROWI

OSSとして公開されているCrowiをフォークして開発されたのがGROWI。
OSSだけどマニュアルも結構整備されている。環境構築もdockerイメージがありワンライナーでいけた。
ただCrowiに比べ機能が盛り盛りでUIも多少繁雑になっている。
あと個人的にカスタムサイドバーがないのが惜しい(実装中らしいが)。
高機能が故にレスポンスも若干遅いなと感じたので惜しくも却下。

DokuWiki

PukiWikiによく似た昔ながらっぽい、PHPで動くデータベース不要のOSSWiki。
研究室WikiでもPukiWikiの次に見かける？
PHPだけで動くため動作も軽快。海外ではDokuWikiの方が有名らしくコミュニティも大きいので継続的に更新がありそう。マニュアルも結構整備されていたので必要十分かなと思った。

これで良いかと思っていよいよサーバー構築を進めました。しかし...

オンプレミスはコロナの時代に適さない？

DokuWikiのサーバー構築自体はできました。
大学で固定IPを申請して、そのPCにApache(Webサーバシステム)とDokuWiki環境をインストールして、そのIPアドレスにブラウザからアクセスすればDokuWikiページが開きます。

しかしここで、
「学外からアクセスできないと厳しくないか？」
という問題が。

北大のネットワークセキュリティ

北大のネットワークは以前セキュリティインシデントを起こして以来、学外からのアクセスを制限しています。

セキュリティ面を考えればこの制限は当然なのですが、テレワーク全盛のこのコロナ禍の中、学外からWikiにアクセスできないというのはいかにも不便です。なんとかならないものか

情報セキュリティ対策室にインバウンド通信制限解除申請をすればアクセスできるようにはなります。これをすれば良いか？と思いましたが、また問題が。

数あるネットワークの通信プロトコルですが、Wikiを含むWebサイトの通信といえばhttpとhttpsです。httpは暗号化されていない通信なので、セキュリティ面から今はほとんどのウェブサイトがhttpsになっているんじゃないでしょうか。情報セキュリティ対策室も「新規の申請に関してはhttpsの通信のみ受け付ける」としています。

ここで問題になってくるのがどうやって通信をhttps化するかということです。

https通信というのは暗号化されているだけでなく、そのWebサイトを提供しているサーバーが本当にその機関のものであるという証明がされています。この証明のために公的な認証機関がSSLサーバー証明書という電子証明書をサーバー管理者に対して発行します。サーバー管理者はこれを自分のWebサーバ内に置くことで自分のサーバーであることを証明できるようになっています。

このSSL証明書ですが、北大のサーバーなら国立情報学研究所に申請すれば無料で発行できます。

ただしこのSSL証明書ですが、基本的にドメインを取得していないようなサーバーには発行してもらえません。hokudai.ac.jpのドメインを持っているサーバーに対して、確かに北大のサーバーですねという証明書を発行するということです。なのでIPアドレスでアクセスするような運用を考えていた今回のWikiサーバーはhttps化できません。

hokudai.ac.jpドメインを取得することも考えましたが、学生がアクセスできるサイトからはどうしてもドメイン取得に関する情報が出てきませんでした。
(この辺で、ここまでのことを後任のサーバー管理者たちに背負わせるのか？ということにもようやく思い至りました。)

学外からのアクセスは諦めるか...？と思っていたその時

アカデミックプランの存在

今の時代、北大でやるにはオンプレミスは不都合もあるしサーバー管理も避けられるなら避けた方がいい(本文は研究…)と思いクラウドサービスを調べ直していたところ、

esa.io (欧州宇宙機関じゃないよ！)
Scrapbox

の二つが、非営利の教育機関用途であれば無償のプランを提供してくれていました。

当初は「大学の研究室ならITリテラシーを鍛える意味でもサーバー管理業務はあってもいいかな」みたいなことも思っていた僕ですが、ここまでの流れでクラウドサービスがいかに楽か思い知りました。
一気にクラウドに舵を切ります。

esa.ioはちょっとファンシーなUIですがそれ以外は必要十分なモダンWikiという感じ。
一方Scrapboxは「情報を整理しない」として、ページの階層構造を排除した一風変わった使用感。

Scrapboxのページ作成への敷居を下げるシステムもとてもいいと思いましたが、階層構造はあった方がいいと思い最終的にesa.ioが良いということに。

長くなってしまいましたが、以上がesa.io導入の経緯です。
長く使っていけるWikiになれば良いなあと思います。

補足 Gakunin RDM

国立情報学研究所が開発しているGakunin RDMという

プロジェクト管理
ファイルサーバー
バージョン管理
Wiki

などが全部入りになった"研究データ管理基盤"が2020年9月末まで実証実験をしていたみたいです。正式稼働は2021年1月と言っていて、サービスインから1年間は無料で提供するということです。その後の料金形態は現在策定中のようなので、その値段によっては移行もアリかもしれない？

2022.1.2現在、まだ普通に無料で使えるみたいです。

Gakunin RDMの派生元になった"Open Science Framework"もあるが、これはオープンサイエンスの普及支援としてやっているようで全て完全公開のよう。さすがに時代を先取りすぎか、日本では使っている人をあまり見つけられなかった。

この記事が気に入ったらサポートをしてみませんか？