見出し画像

enPiTから学んだこと

どうも、mastのミヤモトです。今回は授業のレポートもかねて、enPiTで開発した「つくとぴ」とその時の開発チーム「高みのリーゼント」の話をしようと思います。

こちらかプロダクトへのリンクです。

「つくとぴ」とは

つくとぴは
オンライン授業で初対面の人とグループを組んだ時に雑談するときの話題がない を解決したい
オンラインで初対面の人と話すのが苦手な筑波大学生向けのWebアプリ です。

成果発表会のスライドより引用

チームで困りごとを考えた時(実は2回目だがそれはまた後で)、オンラインでグループワークをする際、アイスブレイクするのが難しいと言う話になり、確かにそうだと共感したため、この困りごとをベースに開発をしました。

使い方

このサービスは筑波大学生向けのサービスです。学籍番号がないと登録できないです。(認証系は後日修正するかも…)
まず、一番下の登録ボタンを押してもらって、「名前」「学籍番号」「学類」を入力します。そして、「アニメ」「音楽」などでの自分の好みのジャンルを選んで、自分の好みの情報を登録します

登録画面

登録が終われば、自分と相手の学籍番号を入力します。自分と相手の好みが一目瞭然で、話が盛り上がること間違いなしです!

実は…

最初は全く違うプロダクトを開発していました。その名は ヘマッチアー です。

ヘマッチアーは 
「自分に似合う髪型が分からない」を解決したい 
筑波大学情報学群生向けの 
Webアプリでした。

しかし途中で、「AIStylist」という完璧な競合が見つかってしまい、お蔵入りになってしまいました。

お蔵入りになったとはいえ、ヘマッチアー時代の名残はつくとぴにも受け継がれています(チーム名とかPBLとか)

「高みのリーゼント」について

メンバーは以下の通りです

知野隼也:「つくとぴ」のプロダクトオーナー、リーダーシップでみんなを引っ張る
高松一鷹:よく開発中に歌う
真鍋匠:データベースに強い
小須田侑暉:なぜかパーカーをよく着てくるイメージがある

春学期のチームを解散させた僕は、enPiTのDiscordのサーバーやSlackなどで呼びかけ、チームメンバーを集めることに成功しました

ちなみに僕はスクラムマスターでした。といってもほとんどスクラムマスターらしいことは何もできませんでしたが…

プロダクト・チームの軌跡

成果発表会のスライドからの引用

チーム全体

最初に集まった時から活発的にプロダクトの方向性について話していて、毎回のレビューの際にも、どうやって価値が生まれるかについて話せていたと思います。

開発に関しても、モブプロや分担を分けて開発していき、お互いに助け合えていたと思います。

11月に「へマッチアー」から別の困りごとを探す際、困りごとベースに開発を進めるのは大前提として、その困りごとの解決策に、すでに競合がないのか慎重に調べました。

しかし、デプロイに時間がかかってしまい、思うようなレビューができませんでした。そんな中でも、チームメンバーでGoogle Formなどのアンケートによって、プロダクトの改善をやっていきました。

12月の終わりからは、実際にレビューの参加者に「つくとぴ」を体験してもらうなどのレビューが行えるようになり、チームの雰囲気も良くなっていきました。

成果発表では受賞を逃してしまいました。原因を追究し、その反省を込めて僕たちは授業期間外などでスクラムガイドの読み合わせなどをやったりなど、現在でもチームは活発に動いています。

チームの中での自分

私は「つくとぴ」のデプロイを担当していたのですが、まずどこにデプロイすればよいのかわからず、そこの調査に時間をかけてしまいました。さらに、デプロイ先でもエラーが発生して、毎回のレビューでもプロダクトを触ってもらうことができませんでした。

僕自身のチーム内での態度も最悪だったと思います。ほとんど人の話を聞かず、周りの人間が何をやっているのかを聴こうとしない姿勢は怠惰そのものだったと思います。

この約3か月間を振り返って


振り返りの最終版

これからもチーム開発を続けていくうえで、いくつか考えたことがあるので、書いていこうと思います。

遅刻をしない

本当に恥ずかしい話で、私は毎回10分程度対面の授業に遅刻していました。これはチームメンバーの信頼を失う行為ですし、何より自分のモチベーションが下がります。絶対やめたほうが良いと思いました。

知識の共有

僕がデプロイ作業を一人にやっていたせいで、周りの人たちの進捗がわからなくなり、逆にほかのメンバーも、僕が何に躓いているのかがよくわからない状況でした。
解決策としてはモブプロなどがありますが、せめて、仮想環境の立ち上げや、CI/CDの確立などの環境構築は、チームメンバー全員でやったほうがよかったのではないかと思います。

議事録をとる

知識の共有ともつながるんですが、スプリントプランニングやデイリースクラム、ロングレビューなどで話したり、聞いたことは忘れます。あの時何を言って、どういう反応をもらったのかを思い出したり整理するために、議事録は必要だと感じました。
個人的に、議事録役は設けておいて、自分でも簡単にメモを取ったほうが、話に集中できるかもと思いました。

人に聞く

デプロイで困っているときに、相手に知識がないかもしれないけど、とりあえず聞いてみたほうがよかったなと思いました。メンターさんがブログという形式でやんわりと指摘してきたと思いますが、デプロイってそんな難しいものではないらしいです。猶更聞けばよかったなと今になって思います。

GitHubのissue、pull requestの活用

これは対面だからあまり使わなかったというのはあるんですが、作業単位ごとに何を達成すればよいのかがわかるように、issueは活用すればよかったのではないかと思いました。また、commitの際のメッセージの書き方の統一など、ルールなどを設定して、作業進捗などを共有しやすくすればよかったと思いました。

ほかのチームのレビューを真剣に聞く

自分の作業に集中しすぎるのではなく、ほかのチームも見て、自分のチームの立ち位置をれ姿勢に俯瞰することが重要だと思いました。

最後に

「高みのリーゼント」はenPiTの授業期間の終了後も、ハッカソンなどで開発を続けていく予定です
3/20に名古屋で開催される、Agile PBL祭り2023にて、これまでの軌跡から気づいて、改善してきたことなどをまとめて発表する予定です。

「つくとぴ」も、これからチームで作っていく新しいプロダクトも、スプリントを回していって改善していく予定です。また気づきを得た際に、ここに投稿して知識を共有したいと思います。

関連

ほかのチームメンバーが書いた「つくとぴ」周りの話のブログです


この記事が気に入ったらサポートをしてみませんか?