今回はタイトルの通り、大学に認められず、サービスをリリースできなかった話をしていこうと思います。

:::message info
サービスをリリースできなかった とありますが、サービス自体は公開しているが機能をなくしているという状態です。
:::

サービス開発の経緯

課題

大学の授業が Zoom での開催になった際に、各講義への参加リンクがダウンロード不可の Excel にて公開されていて、学生は全講義の中から自分の参加する講義の情報を探し出して、Zoom に参加しなくてはいけなく、とても不便でした。

解決した課題

そこで、YCU スケジュールというサービスを開発し、リリースしました。このサービスは Excel のデータを DB に格納してあり、よくある時間割アプリの UI で講義を探すことができ、登録した講義にはワンクリックで参加できるようにするというものでした。
つまり、

1. 探しにくいから探しやすく
2. 参加しにくいから参加しやすく

という目的で開発しました。

サービス停止までの経緯

Twitter で公開

サービスを公開した後に Twitter にてサービスの宣伝をしました。

:::message info
リリース当時は独自ドメインもなく、heroku でのデプロイで UI も今よりひどかったです
:::

すると、予想以上に反響があり、多くの方に認識してもらい 200 名以上の方に登録してもらい、何人かの方は画像付きでツイートしてもらい、さらに多くの方へと広めてくれました。

大学にサービスのことが知られる

すると、多くの方がツイートしてくれた中に講義の参加 URL をモザイクなしで公開してしまった方がいたようで、それを目にした教員経由で大学に YCU スケジュールの存在が知られることとなりました。
その後、学部の教授からサービスについて聞かれて、停止するように求められました。そこでは大学のデータを２次利用したことについても問われ、かなり怒られてしまいました。ただ、多くの学生が使っていたということもあり、実際に停止したのは夏休みの少し前だったと思います。

サービスが停止されてから

サービスを停止してからは、サービスを再開するためにはというテーマで大学の職員の方と何度もメールのやりとりをしたり、実際に会って面談をしたりしてきました。
話し合いの中でサービスを開始するためにいくつか壁があることがわかりました。主に指摘されたのは以下の内容でした。

1. １学生が学生の情報を管理することについて
2. 個人情報の取り扱い
3. 継続的で安定的なサービスの提供
4. 問題発生時の対応・責任の所在

これらの問題に対してそれぞれ解決策を提案しました

学生が学生の情報を管理することについて

一学生が他の学生の情報を管理することに関しては、プログラミングサークルを設立し、サークルとして顧問の先生の管理の元運用していくという案を提案しました。
実際に僕は Engine というサークルを立ち上げ、公認サークルとして現在も活動しています。

個人情報の取り扱い

個人情報の取り扱いに関しては一番難しい問題でした。そこで僕は以下の解決策を提案しました。

1. 認証は独自の認証ではなく Microsoft の認証を利用する（大学が全学生に対して発行しているアカウントで、Excel を見ることのできる権限と同じ権限を保証できる）
2. Microsoft のユーザー ID 以外の個人情報は保存しない。（メールアドレスを含め個人を特定できる情報は一切保存しない）
3. 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 スケジュールは以下のレポジトリにあります。

ycu-engine/ycu-schedule

いくつか開発途中の機能もあるので細部はみないでいただきたいですが、serverless frameworkの初心者であれば何か参考になることがあるかもしれません。
もしソースコードに関して質問があれば、こちらのディスカッションか Github の Issue などに投稿してもらえれば可能な限りお答えします。
特にserverless framework + s3 + croudfront + 独自ドメインの構成は参考になる記事が少なかったので、似たような構成にする場合は参考になるかも知れません。