大学に却下されてサービスをリリースできなかった話
今回はタイトルの通り、大学に認められず、サービスをリリースできなかった話をしていこうと思います。
:::message info
サービスをリリースできなかった とありますが、サービス自体は公開しているが機能をなくしているという状態です。
:::
サービス開発の経緯
課題
大学の授業が Zoom での開催になった際に、各講義への参加リンクがダウンロード不可の Excel にて公開されていて、学生は全講義の中から自分の参加する講義の情報を探し出して、Zoom に参加しなくてはいけなく、とても不便でした。
解決した課題
そこで、YCU スケジュールというサービスを開発し、リリースしました。このサービスは Excel のデータを DB に格納してあり、よくある時間割アプリの UI で講義を探すことができ、登録した講義にはワンクリックで参加できるようにするというものでした。
つまり、
- 探しにくいから探しやすく
- 参加しにくいから参加しやすく
という目的で開発しました。
サービス停止までの経緯
Twitter で公開
サービスを公開した後に Twitter にてサービスの宣伝をしました。
:::message info
リリース当時は独自ドメインもなく、heroku でのデプロイで UI も今よりひどかったです
:::
すると、予想以上に反響があり、多くの方に認識してもらい 200 名以上の方に登録してもらい、何人かの方は画像付きでツイートしてもらい、さらに多くの方へと広めてくれました。
大学にサービスのことが知られる
すると、多くの方がツイートしてくれた中に講義の参加 URL をモザイクなしで公開してしまった方がいたようで、それを目にした教員経由で大学に YCU スケジュールの存在が知られることとなりました。
その後、学部の教授からサービスについて聞かれて、停止するように求められました。そこでは大学のデータを２次利用したことについても問われ、かなり怒られてしまいました。ただ、多くの学生が使っていたということもあり、実際に停止したのは夏休みの少し前だったと思います。
サービスが停止されてから
サービスを停止してからは、サービスを再開するためにはというテーマで大学の職員の方と何度もメールのやりとりをしたり、実際に会って面談をしたりしてきました。
話し合いの中でサービスを開始するためにいくつか壁があることがわかりました。主に指摘されたのは以下の内容でした。
- １学生が学生の情報を管理することについて
- 個人情報の取り扱い
- 継続的で安定的なサービスの提供
- 問題発生時の対応・責任の所在
これらの問題に対してそれぞれ解決策を提案しました
学生が学生の情報を管理することについて
一学生が他の学生の情報を管理することに関しては、プログラミングサークルを設立し、サークルとして顧問の先生の管理の元運用していくという案を提案しました。
実際に僕は Engine というサークルを立ち上げ、公認サークルとして現在も活動しています。
個人情報の取り扱い
個人情報の取り扱いに関しては一番難しい問題でした。そこで僕は以下の解決策を提案しました。
- 認証は独自の認証ではなく Microsoft の認証を利用する（大学が全学生に対して発行しているアカウントで、Excel を見ることのできる権限と同じ権限を保証できる）
- Microsoft のユーザー ID 以外の個人情報は保存しない。（メールアドレスを含め個人を特定できる情報は一切保存しない）
- Microsoft のユーザー ID が万が一漏れてしまい、情報漏洩した場合に備えて、保存する前に暗号化をする。
これに関してはやりすぎだと思っているのですが、万が一の万が一でも許されない空気だったので、厳重にデータを保管するようにしました。
万が一データが漏洩したとしても、暗号化されたユーザー ID からは学生を特定することはできない。仮に暗号を復号できたとしても、そのユーザー ID を元に Microsoft からデータを抜き取る必要があり現実的ではない。
継続的で安定的なサービスの提供
サービスは AWS 上で提供し、全学生が一度にアクセスする負荷にも対応できるように、低レンテンシーな NoSQL の DynamoDB と、Lambda をバックエンドにして、Web サイトは CDN から高速に提供できるように S ３に CloudFront を経由させて提供することで、スケーラブルで高アクセスに耐えうる構成を提案させていただきました。
また、serverless framework を用いて Github のプッシュをトリガーとした継続的なデリバリーによって今後も安定したサービスの継続を保証しています。
問題発生時の対応・責任の所在
サイト上でエラーが発生した際はレポートを収集し、Slack で適宜通知する状態にしました。２４時間体制でサポートすることはできないものの、最大限保守していく体制にはなっていました。
また、サービスの特性上、講義のある時間帯以外は利用の頻度は少なく、エラーが発生しても最悪 Excel から講義を検索し Zoom に参加することは可能なので、保守についてそこまで万全を期す必要があるのかについては議論していました。
また、責任の所在について、今回管理するデータには個人情報が一切含まれていないということもあり、何に責任が生じるのか・責任の重さはどの程度なのかについて僕の考えでは決められないことから、大学に責任を持っていただくことをお願いしました。
それでも許可されませんでした
ここまで対面での話し合い・リモートでの話し合い・メールでのやりとり等たくさんの時間をかけて煮詰めていったのですが、最終的には許可できないとの結論になりました。僕としてはやれることはやって、これ以上ない案を提案したのにもかかわらずダメだったのだから仕方がないと思たのですが、もっとこうだったらなと思うことを書いていきたいなと思います。
大変だったこと・改善していきたいこと
-
サービスを認める・認めないの線引きが曖昧
個人情報に関しても責任に関しても、大学側からは具体的な線引きを提示してもらえませんでした。そもそもこういった活動を想定していなかったからだとは理解していますが、もっと明確に線を引いてもらえるように議論を進めていくべきでした。 -
データの 2 次的活用について
今回サービスを運用する上で大学の講義の情報を利用することが大前提です。大学の講義情報を下手に公開してしまうと、第三者によって妨害されてしまう可能性があり不用意に公開することは避けたいということで、データの 2 次利用は禁止されてしまいました。もちろん大学の考えも理解できるのですが、パスワードやアカウント認証を必須化したりすれば防げることなのではないかと思います。
学生に対し見やすく、使いやすい状態で講義情報を公開できないのならせめて、僕みたいな学生の開発者向けにデータの利用に関して別途規定して欲しかったです。 -
個人情報の保護に関して
今回のケースでは最終的に保存する個人情報は暗号化した Microsoft のアカウント ID となっていて、このデータは漏洩したところで「ある学生の受講している講義」しか知ることができず、それが誰なのかわからない＋受講している講義から個人を特定するのは困難なことから個人情報と言えないのでは？と僕は思います。個人情報を甘く考えてはいけないと思いますが、もっと個人情報やセキュリティなどについて適切な知識が必要なのかなと思いました。
この件を通じて学んだこと
ハードスキルとして
今回の件を通じて、
- サーバーレスアーキテクチャについて
-
Infrastructure as Codeを行う方法 - Github Actions を用いた、CICD の作成
などを学べました。特にserverless frameworkを使ったInfrastructure as Codeの実現はかなり勉強になることが多かったです。開発をしていると、既存のライブラリでは達成できないこともあり、それをもとにライブラリを自作して公開するなどかなり踏み込んで勉強できたなと思います。
ソフトスキルとして
- メールのやりとりについて
- 組織を説得することの難しさを知れた
- 周りを巻き込む力
上 2 つはそのままなのですが、周りを巻き込む力 については、開発の過程でサイトのアイコンを作成してくれたり、サイトのデザインを考えてくれたりしてくれたボランティアの方に協力してもらいました。他にもサークルの顧問になっていただいた先生も、サービスについて共感してもらいいろいろ協力していただきました。
これらは、それだけ魅力のあるサービスを企画・開発をしたということの裏付けにもなっているのかなと思い、今更ながら嬉しくなりました。
最後に
Facebook なんかは大学内での閉鎖的な SNS がもととなり、今では世界中で利用される SNS へと変化しました。世界的な大企業となっている企業も大学時代の何かから生まれたものは少なくありません。
日本に GAFA と戦えるだけの企業が現れないのは、学生の創造力・情熱といったものを狭い世界に閉じ込めてしまうからなのかなと思ったりしました。
これからも、色々なサービスを開発したいと思ってます。YCU スケジュールはリリースできなかったですが、しつこく大学内外にアピールしていきたいと思います。いいねやファローで応援してもらえると励みになります！
ソースコードについて
今回開発した YCU スケジュールは以下のレポジトリにあります。
いくつか開発途中の機能もあるので細部はみないでいただきたいですが、serverless frameworkの初心者であれば何か参考になることがあるかもしれません。
もしソースコードに関して質問があれば、こちらのディスカッションか Github の Issue などに投稿してもらえれば可能な限りお答えします。
特にserverless framework + s3 + croudfront + 独自ドメインの構成は参考になる記事が少なかったので、似たような構成にする場合は参考になるかも知れません。
Discussion
まず停止の経緯からして、大学当局側の温度感が「無許可で大学の情報をスクレイピングして（クローズドであっても）提供しているけしからんサービスがある」だったのかなと思います。
「実はこんな便利なものを作っていて、セキュリティも担保するので公開してもいいですか？」から始まっていれば話は変わっていたのかなと思います。
また
継続的で安定的なサービスの提供で負荷対策や継続的デリバリーに関する取り組みについて書かれていますが、おそらく大学当局側は「開発・保守・運用体制は最低でも数年は維持されるのか？」という意味で懸念されていたのかと思います。今は開発者であるあなたやサービスについて知っているサークルメンバーの方々が在学していますが、コロナによるリモート講義がいつまで続くのか・恒久的なものになるか分からない中、卒業や不慮の事態が発生した際「誰がこのサービスの面倒を見るのか？」「最悪の場合、大学の情報部門で引き継ぐことが技術的/人的に可能であるか？」という問題は考慮されなければなりません。
（良し悪しは別として、多分結構な数の大学はこういうのを自分たちで抱え込むのが面倒なので
〇〇フィールディングみたいなところと書面を交わしてお金を払って、キャンパス内インフラを保守してもらったり 若干イケてない 講義管理システムを導入しているわけです）5年くらい前、在学していた大学の情報部門でアルバイトをしていて、ログ整理のためにRubyで集計スクリプトを書いたりして「似たような話上長としたなぁ」と思い出しました。
結果的にクローズされたとはいえ、日常における不便を技術によって解決し、形にする姿勢は素晴らしいと思います。
ご自身でも書かれていますが、今回の経験と反省を今後に活かしていただけたらと思います。
読んでいただきありがとうございます。
これに関してはまさにその通りだと思ってます。どうせ誰も使わないだろとかと思って軽く考えていたのがそもそもの失敗だったなと思いました。少なくとも大学のデータを利用する以上勝手にやるべきではなかったなと後悔しております...
実はサービスの運用するとしたらということで「サークルのような形で大学の中で課外活動として運用する」と「法人として大学側と取引を提案する」の２種類があるんではないかと、大学の方と話をしていました。
大学の方もおっしゃっていたのですが、やはり法人であることのメリットには @844196 さんのコメントにある通り
などがありますよね。
今回は技術的なことよりも社会的な勉強ができたなと思います。良くも悪くも日本社会について知ることができたなと思うので、次こそは大学が応援してくれるようなサービスにしてみせます！
サービスの構成や，それを形にする技術力は素晴らしいと思いました．
ただ，何点か気になったのでコメントさせてください．
まず，この辺りですが，大学当局としては明確な基準を定めることが非常に難しいという事情があると思います．
前提として，大学というのは数多の学生を背負い，また公費が投入されていることも少なからずある機関であり，その社会的責任は重いです．そういった機関が何らかの，特に個人情報などに関わるガイドラインを出す場合，被害・損害が発生しないように厳密にすべての場合を網羅したガイドラインを作成することが必須となります．
このようなしっかりしたガイドラインの策定には複数の専門家の協力の下，協議を重ねて…といったプロセスが必要となるため，"何かを許可する"ための規定を定めるのには非常なコストがかかり，なんやかんやで原則不許可にしたいというのがあると考えられます．(もしかしたら，このプロセス自体非効率に思われるかもしれませんが，絶対にミスできないという状況下ではこうせざるを得ないのです)
よしんばガイドラインができたしたら，次は様々上がってくる申請がガイドラインに違反していないか見るための人員も必要になり，そのコストもかかります．
また，対応してくださった現場の方も，あなたが直面したように，意見を上に上げてもすぐに反映されることは無いという立場にいるということもあるでしょう．現場レベルで許可できることは無く，また意見を上にあげるのも難しいという状況の板挟みになれば，曖昧な拒否基準を提示する以外できることが無いのです…
この辺り全ては，844916さんがおっしゃったことに加えて，そもそも学生個人・大学当局レベルと企業での信用/対応能力の低さがあります．例えば，
・個人情報や講義情報流出時の法務的対応や金銭的保証(理論上大丈夫でも世の中に絶対は無いためこれを考えなくてはいけません)
・障害発生時のコールセンター的業務(多くの人が使うシステムでは全員にリテラシーを求めることができません．Excelを見る前に繋がりませんと連絡してくる人は絶対に多数発生します)
などなどを処理することが必要になりますが，そのあたりも難しいでしょう．
企業は法的な拘束，取引実績，資本金，人材でこのあたりをカバーしています．
この辺りについても，一応…
Facebookが生まれた当時(2004年頃)は今ほど個人情報保護についての意識や規制が強くなかったと思います．
(例えば日本で個人情報保護法の成立は2003年，施行は2005年です)
また，Facebookは大学と関わりがありません(大学が収集した個人情報が渡されるわけではありません)
その辺りに大きな違いがあります．．
また，米国とかなら今回の件が許されていたかと言うと怪しいと思います．米国エアプなので想像を多分に含みますが，向こうの方が契約や賠償周りにはシビアであり，講義情報の2次配布をした時点で何らかの処罰を受けていてもおかしくないと思います．
ところで，日本も現在は各大学でオープンイノベーションを図るプロジェクトは始まっていますので，意外となんとかしようとはしてると思いますよ．(そういったプロジェクトも完全に自由では当然ありませんが，変化は始まっていると思います)
ちゃんと定まってる分野では定まってます．例えば外部から人を呼んで行う心理学実験のような実験では個人情報，匿名化された個人情報，その対応表などそれぞれ扱い(どこに保存/いつまで保存)が明確に規定されたりしています．
今回の件は，先に述べましたが，許可するルールを作るのが大変なので，まるごと不許可(A∈BでBを不許可にする)判定をとるのが安全上選択されたのだと思います．
さいごにですが，
今回の件は大学当局としては普通にインシデントです．
社会人になってからやったら普通に始末書かなんか書かないと行けない案件だと思うので気をつけてください…
最も，大学から取得する情報から完全に独立して行動する分には(よほど品性を損ねなければ)特に何も言われないと思いますので，次にまた素晴らしいサービスを作るんだろうなぁと期待しております．
大学側もいっていたことになるのですが、横浜市が管轄している(?)大学になるので個人情報の取扱については大学だけでなく、横浜市からも承認を得なければならないようです。それでもどうにかすれば...と試行錯誤したのですが、やはりなかなか難しいですよね。
話し合いに至る前段階ではかなり怒られてしまいました...。いろいろな大人を前になんで怒られなくてはいけないんだと思っていたときもあったのですが、冷静に話し合う過程で段々と色々なことに気付かされました。。。
記事を公開してから色々な方がリアクションをしていただくのをみていて、たくさん勉強させていただいています。正直なところ応援してもらえる反面、かなり叩かれるのでと思っていたのですが厳しくも暖かい意見が多く大変ありがたいです。本当にありがとうございます。個々にお返事することは難しいので代表として mosamosa さんへのお礼とさせてください。
使用された技術だけでなく経緯についても非常に興味深い記事で参考になります。引用されたTweetで大学名が表示されておりますが、大学側はこの記事についてご存じでしょうか?
大学がこの記事を認知しているか把握しておりませんが、大学から連絡があれば内容の変更等を行う所存です。
中国の大学も安全のため、学生の授業のデータAPIを提供しない