注記

本記事は、筑波大学enPiTのレポートです。

はじめに

課題をギリギリまでため込む愚かな大学生のなんと多いことか。彼らはゲームに夢中だ。うどん県のようなルールを大学にも導入するべきか・・・いやもっとエレガントな解決方法があるはず！
というわけで彼らゲーマー大学生がよく使うコミュニケーションツールのDiscordに着目し、大学生の課題消化をサポートするBotアプリケーションをチームを組んで開発しました。本記事では、アプリケーションの概要や、開発の進め方について紹介します。

「Study Crew」大学生のケツを叩くDiscord Bot

↑ Microsoft Copilotに描かせました。便利ですね。

一言で

課題への取り組み状況を友達と共有・記録できるDiscord Botです。

ターゲット

Discordを日常的に使用する、ゲームのしすぎで課題をギリギリまでため込んでしまう大学生

特徴・差別化

リアルタイム性：競合する勉強サポートアプリのStudy plusと比較すると、友達の課題取り組み状況が即時に通知されるという点で、リアルタイム性に長けています。
記録・視覚化機能：取り組んだ課題を記録し、視覚化することができます。これにより、達成感を感じることができます。

Study Crewが大学生に課題をやるよう促す仕組み

友達が課題を始めると即座に通知が飛んできます。ゲーム中の大学生の多くはDiscordをバックグラウンドで起動しており（PCなら）、友達が課題をやっていることに気づき自分もやらなきゃと焦るようになります。

ざっくりとした使い方

課題に一緒に取り組みたい友達が参加するサーバーにBotを追加します。

Botがいくつかのボタンを送信してくるので、以降はこのボタンを使って操作します（簡単でしょ）。
最初に新規登録ボタンを押し、履修している授業を授業登録ボタンから登録します。
課題を始めるときは開始ボタン、終わったら終了ボタンを押します。
友達の課題取り組み状況をBotが逐次送信してきます。

こんな感じに通知が飛んできます。

送信ボタンを押せば、取り組んだ課題の記録が視覚化されます。

チーム体制

Rくん：プロダクトオーナーとして、成果物（Gitリポジトリ）の管理、重要な開発方針の決定などを行ってくれました。チームでの議論では積極的に意見を出していました。
Mくん：スクラムマスターとして、時間管理、スプリントにおける作業の確認・修正などを行ってくれました。enPiT2回目のベテランとしてアジャイル開発を円滑に進行させるために尽力してくれました。
Kくん：開発者として、プログラムの実装を主体的に行ってくれました。レビュー担当も積極的にやってくれました。
私：開発者その2でした。技術力はKくんが圧倒的に上だったので、細々としたコードのリファクタや簡単な機能実装など、脇役的にチームの隙間を埋めるような働きを意識しました。

開発軌跡

開発期間は夏合宿+スプリントx4でした。

夏合宿～スプリント2

実は、この時期は「Study Crew」ではなく「マネスマ」という別のプロダクトを開発していました。これは、課題に取り組んでいる間にスマホをいじってしまうことを防止するスマホアプリで、事前に設定した時間を超えてスマホを操作すると無限に通知を送るなどの妨害を行う機能がありました。

しかし、アプリの実装が非常に困難で、実現できた機能は限定的で、レビューの受けは非常に悪かったです。また、「スマホを使いすぎてしまうような人はこんなアプリをインストールしない」という辛辣な意見も出ました。

方針転換

「実装が簡単」で「使い続けてくれそう」なプロダクトはどんなものだろうかとチームで考えて、浮かび上がったのがDiscord Botでした。まず、Discord Botは割と実装が楽で、情報もインターネット上にたくさんあります。そして、他人とのコミュニケーションを行うツールなので、他人との関わりから課題へのモチベーションを発生させることができます。他人がいるのですぐに使われなくなるということもなさそうです。そこで、課題の取り組みを他人と共有できるDiscord Botの開発に方針を転換しました。

スプリント2～3

というわけで、Discord Botの「大学生シッター」の開発が始まりました。あれ、「Study Crew」と名前が違いますね。実は、機能はかなり似通っているのですが、このころは想定する使われ方が違いました。大学生の課題の取り組みが両親に通知されることにより、大学生は両親に監視されているという圧力から課題をやるようになる、というようなことを期待していました。これ自体はそれほど悪くなかったのですが、「親世代はDiscordをあまり使わない」といった意見が多く出ました。

スプリント4

「両親と大学生」という関係から、「大学生の友達同士」という関係に変更しました。友達同士で課題の取り組みを監視しあう仕組みです。やっと「Study Crew」という名前になりました。

レビューのもらい方

一日の作業の終わりには、他チームとレビューを行いあい、プロダクトの改善に必要な情報を集めていました。
レビューのもらい方ですが、最初は一方的にプロダクトについて説明した後、「何か意見があればお願いします。」というようなアバウトな投げかけをしていました。全然レビューもらえませんでした。
そこで、途中からGoogle Formを使ったアンケートを行うようにしました。Yes/Noや選択式の答えやすい設問をメインにしていたため、回答は結構多くもらえました。しかしながら、結局設問でこちらが想定した内容のレビューしか得られませんでした。
最後の方では、実際に隣で使ってもらいながら、会話ベースでレビューをもらうようにしました。使いながら、会話しながらもらえるレビューは、それまで盲点だったような有益なものも多く含まれていました。
結局、会話ベースでレビューをもらうのが最も良かったように思います。一方Google Formも、とりあえず回答率を確保するには有益だと思うので、適所では活用するのもアリだと思います。

共同作業のやり方

プログラムの共同作業の定番といえば、GitHubにリポジトリを作成し、各自のPCにクローンしてそれぞれ作業、プッシュしてプルリクエストだと思います。ただ、チームメンバー全員が使い方を覚えていなければなりません。また、下手なことをするとマージに苦労します。
そこで、私たちのチームではVisual Studio CodeのLive Shareを使用して、同じファイルを複数人で編集するという方法で共同作業を行いました。良かったところは、マージで困ることがほぼなく、余計な時間の浪費がなかったところです。一方不便だったところは、Undo/Redoが他人と共有され、予期しないところでコードが消えたりすることがたまにありました（他人のUndoで自分の直近の編集が消えてしまう）。
Live Shareはお手軽なので私たちのチームには合っていたように思います。でもプロはやっぱりGitをうまく使う方が良いと思います。

残業なし！

他チームは結構残業して作業を進めていましたが、私たちのチームは残業は一度もしませんでした。ホワイト！決められた時間内に計画を立てて、集中して作業を進めることは社会に出た後も大切だと思います。
チームメンバーの全員のやる気が十分で、だらだらしないように計画をしっかり決めて残業をやるならまあ良いんじゃないでしょうか。とはいえ、本当は残業したくないけど周りに流されてNoと言えない可哀そうなメンバーもいそう・・・

ふりかえり

開発期間がシビアな中で、調査から企画、実装まで行うのはめちゃくちゃ大変でした。特に、調査・企画の段階でどのような「価値」をユーザに提供し、それによってユーザに何を「体験」させるかはっきりさせておかないと、せっかく実装してもほとんどウケず誰にも使われなくなってしまいます。また、価値を検証するためのプロトタイピングでは、できるだけ実装コストを下げるように工夫することも重要です。私たちはここに時間をかけすぎてしまい、結果的にギリギリのタイミングで方針転換することになってしまいました。
今後このようなチーム開発に取り組むときは、「調査・企画→プロトタイピング→レビュー」の流れを短期間で繰り返して、自分たちのプロダクトがどのような価値を提供できるかを早い段階ではっきりさせることを意識したいと思います。

↑一日の作業の終わりにチームでふりかえりを行い、大事だと思ったことを記録していったものです。レビューのもらい方に苦心していたことや、プロダクトの方向性に右往左往していたことが分かりますね笑

おわりに

Study Crewの開発を通して初めてアジャイル開発を体験しました。人に使ってもらえるプロダクトを開発するのは本当に大変ですね。今後社会人として商品を開発するときも、開発者側の独りよがりにならずユーザ第一を絶対に意識しようと思います。
メンバーの皆、約半年間ありがとう！