はじめに

　アクセスいただきありがとうございます。この記事は、大学で受講したアジャイルPBLの最終レポート課題になります。アジャイル開発初心者からの視点で、取り組んだ軌跡を書いていきます。「初心者だけどアジャイル開発やってみたい！」 という方の参考になればと思います。(より正確には、私が経験したのは「スクラム開発」に当たりますが、ここでは省略します。)

プロダクト

紹介

　最終的に作成したプロダクトは 「Study Crew」 というDiscordボットです。授業課題を余裕をもってこなしたいという気持ちを持ちつつ、ゲームをして時間を持て余してしまう大学生に着目しています。私もこういう節がある人間の一人です。

~~(Copilot君すごい)~~
いただいたレビューを元に課題への取り組みを友達と共有・記録の機を備えています。また、類似する既存サービスである 「Study Plus」 とは違って、リアルタイムに友達の取り組み状況を把握できる機能とゲーム好きに馴染みのあるプラットフォームであるDiscord上で完結するという強みがあります。

ユースケースとしては、以下のような場合があると想定しています。

友達が課題を始めたことの通知
友達の課題進捗状況をリアルタイムに確認
進捗のまとめを最後に確認

使い方

　Study Crewは複数人が所属するサーバー内に招待する必要があります。

全体
全体に向けたメッセージを管理するテキストチャンネルです。
ボタン
ボットとやりとりをするためのボタンを管理するテキストチャンネルです。
授業チャンネル(画像では「線形代数学i」、「微分積分学i」)
授業ごとに友達の課題の進捗状況を確認できるテキストチャンネルです。

　メインとなるのはボタンチャンネルです。画面は下の画像のようになります。

新規登録
　ボットの利用のために利用者は必ずこのボタンを押す必要があります。このボタンを押さないと、授業課題の登録ができません。

登録に成功すると、ダイレクトメッセージにてボットから登録完了のメッセージが届きます。
授業登録
　授業課題ごとに課題の進捗を管理しています。あらかじめ使用する授業をここで選択しておく必要があります。
開始
　このボタンから、始める課題を設定します。「線形代数学iの第一回レポート始めたい！」となったら、まず「線形代数学i」を選択します。

授業を選択するとタスク名を入力する画面が表示され、ここで「第一回レポート」と記入し、送信ボタンを押します。

開始に成功すると、以下のようにボットからボタンチャンネルにて返信が確認できます。
終了
　このボタンから、終了する課題を設定します。

終了に成功すると、以下のようにボットからボタンチャンネルにて返信が確認できます。
送信
　このボタンを押すと、全体チャンネルにてサーバー内にいる全員に自分の課題の進捗を報告できます。

　また、課題開始直後から課題終了にかけてボットから定期的に、進捗度について質問を受けます。

ここで報告した内容が、授業チャンネルにて共有されます。

通知
　Discordの通知を切らなければ、定期的に友達の進捗を通知付きで確認できます。通知ON推奨！

チーム運営

全体

　最終的なチームAMFは以下のようになりました。青いメモが「良かった点」、赤いメモが「良くなかった点」、それ以外の奇抜な色は「注目すべき点」として書いています。 色が濃いほど重要度が高い です。

一部抜粋してまとめます。

良かった点

あえて分担しない
　分担前にはマージ作業の負担が大きく、お互いの作業の進捗度合が分からないという問題がありました。そこで、VSCodeの拡張機能である 「Live Share」 を使用しました。これは、一つの作業環境をURLを通して共有して作業できるようにする拡張機能です。これを使用することでマージ作業することなく、お互いの歩幅を合わせて作業することができました。また、あえて分担しないことで、メンバー全員がプロダクトの仕組みを理解し、誰でも常に発表できる状態を維持するようにしました。

時には分担することも
　全員がやることをはっきりと理解しているときや開発と違う作業を並行したいときなどには、臨機応変に担当を分けるようにしていました。逆に分担したほうが責任が誰にあるのか明確なので、話し合いやすそう？

残業なし
　チーム内で共通して「残業はしたくないね」と意見が一致しました。ToDoのタスクに対して時間制限を設け、 タイムマネジメント を徹底しました。時間制限に達した際には別のタスクの優先順位を上げ、元のタスクは残った時間で解決するようにしました。このようなタイムマネジメントから残業することなく、最後まで時間内に作業を進めることができました。
レビュー担当を作る
　開発時間が短い中レビューに対する準備不足が多々発生したため、レビュー開始30分前を目安にレビュー担当を置くようにしました。レビュー担当がメインとなって内容を考え、レビュー時間になったらその内容をレビュワーに共有するようにしていました。レビュー担当を作ってからは準備不足になる機会が十分に減りました。

良くなかった点

プロダクト軸が定まらず右往左往
　これはチームとして 最も反省すべき点 だと思います。軸がブレたことで様々なプラットフォームでのアプリ開発を行うことになってしまいました。結果、色々なアプリを開発できた機会となりましたが、一つのアプリに対して十分な時間を割けなかったのは残念に思います。
煩雑なコード
　常に意識していたつもりが、結局煩雑なコードとなり読みづらくなってしまうことが多々ありました。保守性の高いプログラムの記述を常に意識することが重要そうです。

個人

　メンバーは「私」、「MR」、「KI」、「KN」と表現します(MR、KI、KNはそれぞれ名前から取っています)。

私(プロダクトオーナー)
　プロダクトオーナーとしての意識を常に持つことができていなかったと今になって反省していますが、いただいたレビューからメンバーに対して提案を行うことは毎スプリント心掛けていました。また、レビューフォームやスライド、議事録・メモなどの資料の作成に率先して取り組みました。他チームのレビュー・デモの際には、なるべく思ったことを棘のないように共有することを心掛けました。開発に対してはあまり貢献できませんでしたが、それは他のメンバーが補ってくれたとつくづく感じています...
MR(スクラムマスター)
　アジャイルPBL経験者としてスクラムマスターに就き、タイムマネジメントやチームの意思決定に対して積極的に行動してくれました。このチームが残業なく終了できたのはMRのおかげだと思います。また、レビュー時間のタイムマネジメントや指揮を執っていたのが印象的です。デベロッパーとしても改善案を自身の環境で実装し、メンバーに提案していました。
KI(デベロッパー)
　私と同じく、アジャイルPBL初参加であるにも関わらず、豊富な技術力と知識から様々な技術案の掲示と実装を担ってくれました。色々なプラットフォームでの開発を行うことになってしまっても、チームでゴールを達成するために尽力してくれたと思います。
KN(デベロッパー)
　私と同じく、アジャイルPBL初参加でしたが、デベロッパーとしての開発作業だけでなく、レビュー・スライド準備、メモ作成などチームの補足的な作業もしてくれていました。メモやTodoリストの整理など本当に細かいところで大きく支えてくれたと感じます。

チーム名
　このチームは「やる気がないときになんとなくスマホを見て時間を浪費してしまうのを防ぎたい」というテーマのもとに集まったメンバーでした。チーム名は 「スマホ中毒」 です。

開発の軌跡

　各ロングレビュー前のスプリントを一つのスプリント期間としてまとめて書きます。

夏休み期間 (1か月目)

　期間中に行ったインタビューから「スマホで時間を浪費してしまうのは、想定していた計画とのズレを認識できていないことにある」と考え、はじめはタスク管理アプリに取り組もうとしていました。しかし、サービスに盛り込むべき機能についてアイデアが出ず、従来サービスとの差別化が難しいと考え、この案はボツになりました。
　新たに「スマホを使ってしまった時間に応じて通知を発行し、使い過ぎに気づくことができる集中サポートアプリ」の作成に方向転換しました。下がそのエレベーターピッチになります。

　Reactを使用しWebサービスとして開発を始めました。ここでは各々の環境で開発をし、のちにマージするようにしていました。下が当初作成していたサービスになります。

第一スプリント期間 (2か月目)

　スマホのスリープモードが解除したことの検知や、スクリーンタイムの活用をしたいという案があり、React Nativeに環境を移行しました。ネイティブアプリの機能を活用して操作性の改善に努めました。最終的にボタン一つでスマホの使いすぎを教えてくれるアプリになりました。使いすぎた際には通知が大量に発行されるなどペナルティをつけて価値検証をしました。
　このスプリント期間中からLive Shareを活用するようになり、メンバーの開発の歩幅を統一しました。

第二スプリント期間 (3か月目)

　バックグラウンド処理の複雑化や、レビューにて「アプリを使うほど強みが感じられない」といただいたことから、プロダクトの方向性を見直すことにしました。実際、操作性でしか従来サービスと差別化できておらず、機能性は他サービスのほうに利がありました。そこで、「スマホ使用時間」から「タスクに取り組んだ時間」に対象を狭めつつ、他サービスとの差別化を図るために、「家族にタスク進捗を監視してもらうサービス」に方向転換しました。下がそのエレベーターピッチになります。

　技術的な問題や費用的な問題からDiscordボットで実装することで価値検証をすることにしました。Discordボットとしてタスク進捗を家族に共有する機能やタスクにかかった時間を取得するような主要機能を備えました。
　この期間中からレビュー担当がGoogleフォームでレビューフォームを作ったり、ほかにレビュー準備をすることでレビューの質の向上に取り組みました。

第三スプリント期間 (4か月目)

　操作性の向上や進捗状況の可視化のため、ボタンの実装や進捗状況のグラフ作成機能を作りました。可能な限り見やすいUIになるようにボタンチャンネルなどの工夫をしました。
　Googleフォームでのレビューの質より、従来の話でレビューをいただくタイプのほうが質がよいと判断し、レビュー方法を見直しました。レビュー形態に合わせてレビュー方法を変えるべきという意見も出ました。
　レビュー時にプロダクトが動かない、もしくは正しく動かず途中で停止する、などのトラブルが多発し、リファクタリングの作業もここで挟みました。
　「このプロダクトによる家族からの監視はモチベーションにつながらない」、「家族がDiscordを使わない」、「Study Plusと類似点が多い」などのレビューをいただき、このスプリント期間で作成したプロダクトにも強みが見いだせないという結論に達しました。

第四スプリント期間 (5か月目)

　最終スプリント期間に入り、一つのプロダクトとして強みと一貫性のあるものにする必要があると考え、再度プロダクトの方向性を見直しました。開発期限が迫っているため、すでに作成しているプロダクトに変更を加える形で実現することを目指し、最終的に「大学生シッター」から「Study Crew」を作成しました。下がそのエレベーターピッチになります。

　最終発表に向けてスライドの作成も並行して始め、アジャイル開発にならってスプリントごとにより質の高いものになるようにしました。
　開発中はバグも散見されていたので、ChatGPTを活用して全体的な修正を行いました。最近のAIはすごいですね...

振り返り

技術力

　技術力がないと レビュー内容をアプリに反映できないことを痛感 しました。今回のプロダクト方針が右往左往してしまったのは、技術力の不足によることが多かったです。モバイルアプリ開発におけるバックグランド処理の実装や、Discord上におけるUIの実装で困難を極めました。最終的なプロダクトがデプロイにいたらなかった一因もここにあると思います。
　チームが持ち合わせる技術スタックを初めに把握しておくと、開発プラットフォームの選定には困らなかったかもしれません。

チーム運営

　 チームにあったやり方を模索するのが必要 と理解しました。今回のチームは残業をしない・ホワイトに終わらせる、なるべく全員で分担せずに取り組むという方針で、争いなく終わらせることができました。残業をする場合や細かい役割分担を行う際には、時間制限のルールや分担の責任範囲をあらかじめ設定する必要があるかもしれません。これらのチーム運営の方法はメンバーとよくコミュニケーションをとることが必須に感じます。

開発補助サービス

　今回のプロダクト開発で以下のようなサービスに初めて触れることができました。

Git
　コードのバージョン管理で使用しました。今回しっかり触れたのは楽しかったです。

Github
　複数人でコードを共有するのに使用しました。

Docker
　開発環境を統一する際に使用を試みました。結局うまくいかなかった...

React
　Webアプリ作成の際に使用しました。

React Native
　ネイティブアプリへ移行する際に使用しました。Reactから移行はすごい簡単です。

Expo Go
　ネイティブアプリのデモを行う際に使用しました。

Miro
　チームの作業議事録として使用しました。プロダクトバックログやToDoリストもここで管理しました。

Live Share
　チームでコードを共有して作業するのに使用しました。開発環境も一人のパソコンでできてしまうので、チームでの開発がしやすいです。

Color Hunt
　いい具合の色の組み合わせを提案してくれるサイトです。発表スライド作成で使用しました。私にはデザインセンスがないのでかなり感動してます。

ソコスト
　商用利用可能なイラストを提供するサイトです。発表スライド作成で使用しました。イラストの色を調整できるところが便利ポイントだと思います。

他サービス

VSCode
ChatGPT
Googleドキュメント
Googleスライド
Googleフォーム
Vercel
Figma
いらすとや
などなど...

おわりに

　最後まで読んでくださりありがとうございます。私としては、このアジャイルPBLは「自分のための開発」ではなく、 「自分以外のための開発」 という今までにしたことのなかった開発アプローチができた、非常に学びの多い貴重な機会となりました。初めてのチーム開発で、個人ではできなかった経験がたくさんできました。もしまたこのような機会があれば、ぜひ挑戦してみたいと思います。
　