大学院で教育工学を専攻していた時の名残で、今でも Learning & Engineering というメーリングリストに登録しているのだが、先日コミュニティでこんな論文が話題になっていた。
https://dl.acm.org/doi/10.1145/3706468.3706478
タイトルは「MORF: A Post Mortem」。著者はペンシルベニア大学の Ryan Baker 氏と Denver 大学の Stephen Hutt 氏だ。自分の研究分野では有名な LAK（Learning Analytics and Knowledge）というカンファレンスで発表された論文。公開が 3 月 3 日と書いてあるからかなり最近の論文だ。
まず目を引くのはタイトルにつけられている "A Post Motem" というフレーズである。ポストモーテムといえば、何がしかのインシデント（トラブル）への検証や分析を指すが、自分が知る限りでは、あまり論文で好んで使われる単語ではないように思う。
というのも、あるプロジェクトのポストモーテムを書くということは、暗にそのプロジェクトが失敗だったと認めることになり、これは公的な資金を投入して行われた研究プロジェクトにとっては、あまり好ましいことではない。
なんでわざわざポストモーテムというタイトルとつけたのか気になって、自分の仕事とは関係ないのだがせっかくなのでちょっと読んでみることにした。
MORF とは
MORF とは The MOOC Replication Framework の略で、直訳すると MOOC のレプリケーションを行うためのフレームワークということになる。
MOOC のレプリケーションってなんぞやと思うかもしれないが、このフレームワークが生まれた背景には、Coursera や edX をはじめとする、大規模で無料のオンラインコース（Massive Open Online Course）が急速に普及し、多くのユーザーを獲得した経緯があった。
こうした大規模なオンラインコースには、多くの学習者によって蓄積された大量のデータがあり、これは学習者の行動や学習成果に関する貴重な情報源となる一方で、個人のプライバシーにも関わるセンシティブな情報である。
この問題を解決すべく生まれたのが MORF であり、要するに学習者のプライバシーを守ることを最優先におき、研究者が安全に大規模なデータセットを分析できるような MOOC のレプリカを提供するためのフレームワークということになる。
MORF の詳細については2018 年に発表された論文があるので、興味がある方はそちらを参照してほしい。GitHub に公式のレポジトリも公開されている。
なぜ失敗したのか
MORF の失敗要因はいくつか挙げられているが、自分が興味を持ったポイントについてかいつまんで説明してみる。
まずは Docker コンテナの問題。MORF はユーザーがどの言語を用いて分析しても問題ないように、ユーザーに自身の解析スクリプトを Docker コンテナとしてアップロードさせる仕組みを採用していたのだが、どうもこれが研究者にとっては技術的なハードルが高すぎたらしい。
これは自分も経験があるのだが、研究者の中にもいろいろなタイプがあり、Python や R で分析用の高度なスクリプトを書ける人が必ずしも Docker の基礎的な技術を身につけているかというとそうではない。特に Web 系の技術に疎い研究者にとっては Docker という言葉自体がなんなのかわからないという人も多い。そんな中で、分析用のスクリプトを Docker コンテナに詰め込むというのは MORF のユーザーである分析系の研究者にとってはかなりハードルが高い作業と言える。筆者らもこの点について、言語を問わないという意味で間口を広げたつもりが帰ってユーザーを限定する結果になってしまったと述べている。
次にデバッグと出力の問題。MORF では学習者のプライバシーを守るため、デバッグ用のエラーメッセージにも最小限の情報しか返さないようにしていたという。また分析結果についてもあらかじめ MORF 側で定義されたフォーマット以外の出力は表示されないようになっていたらしく、これも分析者の自由度を狭める結果となった。前者については上述した Docker の問題とも相まって、慣れない Docker を使うにあたってかなり MORF を使用するハードルを上げてしまっていたのではないかと思われる。
ポストモーテムの意義
このようにこの論文では MORF という分析フレームワークが広まらなかった要因として幾つかの課題が挙げられているが、そもそもなぜこのポストモーテムが必要だったのだろうか。
私はおそらく MORF のような課題は、教育工学分野の内外を問わず、多くの研究者が抱えている課題なのではないか、と思う。今回の件をより一般化していうと、フレームワークや研究の理念を優先させすぎると、ユーザー体験を損ない、結果として誰も使わないプロジェクトになってしまうということだ。
いくら崇高な理念に基づいたプロジェクトであっても、誰からも必要とされないものができてしまっては本末転倒である。
今回の論文でもネクストアクションとして、ユーザービリティテストの強化やコミュニティの育成が挙げられていた。プロジェクト（研究）の本質ではない部分で、よりユーザーに近いウェットな部分にも焦点を当てることが重要であるということだ。
近年プロダクト開発における PM (プロダクトマネージャー) という役割が注目されているが、技術や理念だけではない部分の重要性をこの論文からあらためて学べた気がする。
