フルリモートチーム開発を授業で体験したレポート！

##何をしたの？

大学の授業で１週間に４時間ほど開発の時間がありました。これを１年間行なっていました。
メインツールはdiscordを使っていて、実際に開発をするときは、vscodeの拡張機能であるlive shareを使用しました。

こちらが実際に作成したサービスです！
https://hobeeeeee.netlify.app/

![スクリーンショット 2021-02-10 21.10.17.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/273734/56cdcd4f-d3be-37ac-bba2-8c41acb831c8.png)


## 開発したシステムの内容 

想定する顧客は、趣味を探したい人・見つけたい人です。
解決したい問題として、新しい趣味を探したいときに、興味のある趣味の繋がりから探すことができたら嬉しいと思いました。

そこで僕たちが作成したアプリでは、趣味の同士の繋がりをパッと一覧で見れるという独自の価値を提案します。

具体的なソリューションとしては下記の画像のように、赤い趣味に関連した趣味が緑色の円となってわかりやすい可視化をしました。

![スクリーンショット 2021-02-10 21.09.54.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/273734/bdd0af47-9628-7c31-a756-c3daf309580e.png)



## 開発したシステムの使い方概要

僕たちが作成したのは **「Hobeeeeee」** というwebアプリケーションです。
トップページに趣味を探す/趣味を書くの２つのボタンがあります。

![スクリーンショット 2021-02-10 21.10.17.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/273734/894197bd-f2fe-7505-5130-a22d5b89dee1.png)


趣味を探したい人は、趣味を探すボタンをクリックします。
すると、ランダムな趣味が中心に赤色として表示されます。


![スクリーンショット 2021-02-10 21.10.28.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/273734/324927f4-fe7c-b2f4-d617-e863e6bd7562.png)


その赤色の趣味をクリックすると、その趣味に関する記事一覧がみることができます。


![スクリーンショット 2021-02-10 21.10.40.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/273734/78e316dc-426b-b954-064f-7474bad10961.png)


その記事を読んで気に入ったらいいねボタンならぬ、沼に入信したことを表す「ずぶずぶボタン」を押すこともできます！


![スクリーンショット 2021-02-10 21.11.24.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/273734/21a5ef6e-1554-24bc-60e6-1ff7f35fe8aa.png)


## 期間中の自分の主な役割

自分たちのチームは明確な実装担当はありませんでした。
基本的に毎回バックエンドとフロントエンドの２モブに別れて、作業をしていました。

また、僕はプロダクトオーナーを努めていましたが、名ばかりで、特にこの役職として何かをしたことはなかったです。
チーム全員でプロダクトの方向性について、納得のいくまで話し合った結果とも言えますが、そのぶん話し合いに時間がかかってしまった。これはこれで、チームの雰囲気が良いから成り立ったことだと思うし、プロダクトオーナーとして何かできていたら、この話し合いの時間を少し短縮できたかもしれないというところが反省点です。


## 秋学期の各スプリントの個人的ふりかえり
各スプリントについて（チーム&自分）やったこと、起きたこと、学んだこと

### 開始 ~ 10/28までのスプリント

この辺りまでほとんどの時間をプロダクトの方針決定のため、話し合いをしていました。
話し合いは無限に時間が溶けてしまう可能性があるということを学びました。
同時にリモートで顔が見えないからこそ、忌憚なき意見が言える環境だったとも思いました。
これは大事なポイントだと思います。
ただこれは僕たちが夏休みの間自主的に学習を行なって、仲が深まっていたことが大きいと思います。音声でのリアルタイムのコミュニケーションが得意でないチームもあると思ったので、匿名性を担保したテキストベース（音声との併用）話し合いをするチームもあっていいと思いました。

miroの付箋ベースや、マシュマロ,peingなど..?

### ~ 11/13

**この辺りから、開発が間に合わないとなり、チームで集まる時間は極力その時しかできないこと、主にタスクの分解を行い、スプリントバックロ）（TODOのようなもの）を作成した。**
１つのスプリングバックログとgithubの1issueを対応づけることで、非同期での開発ができるようにしました。
これにより後からものすごい開発スピードで進むことができ、重要な学びとなりました。リモートチーム開発の場合のスタンダードかな？と思いました。


### ~12/2

データベースから取ってきたデータを可視化する作業に注力しました。
ここまですごく完成するか不安でしたが、、コア機能である可視化が完成したためチームの士気が一気に上がったのを感じました。

コア機能であることも士気が上がった要因だと思いますが、**フロントエンド（見た目）を優先して開発するということも、進んでいる感じを味わうため重要なポイントであるようにも感じました。**

###  ~12/16

同じく非同期開発がすごく効果を発揮しました。
トップページのデザインロゴなどもなんと非同期で完成して、一気に見栄えが良くなりました。



## チームメンバーについて
各メンバーのチームでの役回りと貢献を個人的解釈で書きます！

### かいほつくん
プロダクト方針の疑問点が残らないよう議論を始めてくれていました。
言いづらいこと、例えば「今このしていることは本当に役に立つのか？」「技術的にこれでいいのか？」と言った議論を初めてくれて、結果工数が大幅に削減されていたと振り返って思います。そもそも論の話し合いがこれほど重要なのかと気付けました。
また、使用した技術全てに精通していて、詰まった場面で何度も助けてもらいました、ありがとう！！！！

### かつやさん

圧倒的統率力なつよつよかつやさんです!!
自然とみんながリーダーとしてみていました。
さらに技術的な面でも頼れるというつよつよ...
チーム名の名付け親でもある敏腕コピーライターです！！

### ちゃんなな


>実はチームの中で一番頭のネジが外れてるんじゃないかと思うときがよくある。

と内部告発され笑ってます笑

人生で一番言われる言葉は、「職務質問されなそう」&「最初は普通だと思った」なので、頭おかしいと言われるくらい,自分が素を出せるチームの一因になれてよかったです。
そんなチームの雰囲気作りの中心メンバーです！
敏腕デザイナーとしての役割もこなすフルスタック！

### ばっしー
みんな口をそろえるSeeeeee:Dの癒しです！
使用したことのない技術が多い中で、辛かっただろう状況でも無欠席ですごいなと尊敬しました。(僕なら絶対に休みます）
また、タイムキーパーの役割やプロダクトの方針を決めるときにすごく貢献していました。

### めいてつさん

技術力が凄すぎて2年後自分がこうなれているのかと考えると、不可能だという結論に至りました！
開発は全てオンラインであるため、技術的な難しい話も、身振り手振りなしでほとんど音声のみで完結できていたのは、改めてとんでもない偉業だと思いました。そしてそれができたのもめいてつさんがいたおかげだと思います、ありがとうございます！！
また、チームで授業外での活動を積極的に提案してくれたのもめいてつさんです、ありがとうございます！


## 学んだことと,次に何に生かすか

### オンラインならでは！
リモートだからオフラインに近づけよう！ではなく、オンラインだからこその良いところ！を体感できたような気がします。
自分は新しい人間関係を築くのに時間がかかる方なのですが、それがdiscordをつなぎながらのリモート同期開発だからこそ、ゆるくて心地よい強制力で、自分にとっては最適な距離感から始めることができて、学びになりました。

オンラインかオフラインかのゼロかイチかではなく、もっとグラデーションのある開発形態・チーム形態が今後増えていったらいいなぁと思いました。

### プロトタイプ作成の重要性
２週間に１度くらいに教員や他の学生からフィードバックをもらうという機会がありました。
そのため、**何か見せられる進捗がないと恥ずかしいVSプロダクト方針があやふやなまま進んでいいのか**という葛藤に悩まされました。
すると、**「実際に開発は無理にしなくていい、パワポとかのスライドでいいから、完成イメージを見せほうが建設的な意見をもらえる」**と教わりました。
([プロトタイプのオズの魔法使い](https://uxdaystokyo.com/articles/glossary/wizard-of-oz/)というらしく、伝統にも裏打ちされたアドバイスなのだと学びました。)
これはすごく衝撃的で、**僕たちの労力はユーザーにとっては重要でなく、価値に重きを置きなさい**、というenpitに一貫しているテーマを身をもって体感することができました。
同様の理由から、先生方からのフィードバックで、**「Lorem Ipsum のようなテストデータは出来るだけやめたほうが、完成イメージに近くなって良いフィードバックをもらえると思う」**という指摘もためになりました。

このプロトタイプの重要性は、研究などあらゆるものに転用できる！と思いました。

##最後に
教員・メンターの方から貴重なフィードバックをたくさんいただきました、本当にありがとうございました！