Zenn
🗂

初学者4人でチーム開発をした振り返り【Rails/Next.js】

2024/02/23に公開
チーム開発
tech

はじめに

はじめまして！アプレンティス2期生のかじ(@cncnkitsune)です。

アプレンティスの詳細についてはこちら
https://apprentice.jp/

以前もチーム開発に関しての記事を投稿しました。
今回は前回に続き、二度目のチーム開発となります。
一度目の記事はこちらからご覧ください

開発の概要

アプレンティスからテーマがあたえられ、それに沿ったアプリを設計、開発、3分間でプレゼン　という流れです。
今回のテーマは、「ワクワクするもの」でした。
前回のチームと違うメンバーでチームを組み、開発を進めることになりました。

開発したプロダクトについて

私達は「List It Bro! for twitch」というライブストリーミングクリップのプレイリストを作れるアプリを開発しました。

クリップ:ライブストリーミング中の名シーンを切り取って保存できる機能
Twitch:ライブストリーミングサービスを提供するプラットフォーム

Twitchはクリップを作成する機能はあるものの、そのクリップをまとめて保管したり、ジャンルごとに分けたりできず単品で扱うことしかできないです。
そこに課題を感じた私達は、プレイリストを作る機能は潜在的な需要があると踏んで、開発が決定しました。
4人とも配信文化に馴染みがあり、解像度、熱意ともに高く開発できるのも大きな決め手でした。

コア機能

  • プレイリスト作成
    クリップを一つのリストにまとめて閲覧できる。またリストURLを発行し共有できる

  • プレイリスト表示
    最初は読書メーターのような自分用にプレイリストを作成して見返せる...といった設計でしたが後々に他のユーザーが作成したプレイリストを見れたほうがコンテンツが豊富になって面白い　となり、開発することになりました。

  • クリップ閲覧機能
    Twitchから取得したクリップをシームレスに閲覧できるようにしました。
    ここはユーザー体験にダイレクトに関わってくるため、マスト事項として真っ先にあがりました

    競合

    せっかく作るアプリケーションの上位互換が存在しては作る意義がありません。
    調べたところ、Twitchからクリップを取得してランキング形式にソートしているWebサイトは存在しましたが、プレイリストを作成、共有できるといった機能を持つサイトはなかったため、開発に踏み切ることが出来ました。
    ここらへんの需要の有無、競合の存在等をメンバーと調査するのは楽しかったです。

実際の画面


Top

その他の詳細をYoutubeにUPしているので気になる方はこちらから見ていただければ！
https://www.youtube.com/watch?v=-HYyB7Tq1-k

技術構成

  • フロントエンド : Next.js
  • バックエンド : Rails API mode
  • DB : MySQL
  • ソース管理 : Git/GitHub
  • 環境構築 : Docker
  • 外部API : TwitchAPI

担当分野

前回のチーム開発ではバックエンド部分を担当していたのもあり、今回はフロントを担当しました。
（header/sidebar/Playlist)
また同時並行していたアプレンティスの学習でReact,next.jsを学んでいたのでアウトプットして身につけたい！という思いもありました。

私はプレゼンの担当でもあったため、比較的軽めのタスクではあったんですが、next.jsの理解や、データの受け渡し（fetch）の理解が全く追いついていなく終始焦燥感に駆られていました...笑

前回のチーム開発の反省を活かせたか？

一回目で挙げた反省点がどのように改善できたのか確認してみます。

  • タスクの工数の見積もりの甘さ
    今回はページ単位でやるべきことをすべて洗い出し、notion上で管理することで改善できました。
    おおよその工数も全タスクに記載し、遅延があった場合はメンバーに報告する体制を作れました。

    実際のnotionの画面

  • 業務分担のやり方
    前回はエンドポイントの概念すら理解していなかったため、分担がめちゃくちゃでした笑

今回はバックエンドはエンドポイントにデータを用意　→　フロントでfetchして受取　としっかり分担できました。
またフロントエンド内での分担としても、ページ単位で切り分けて混乱することなく作業できたと思います。

  • ルール作り（Git、コーディング）
    前回はコンフリクト起こしまくり、インデントごちゃごちゃ、など散々でした。
    コーディングに関しては、反省を踏まえフォーマッター導入担当をチームに設けるところから改善しました。
    優秀なチームメイトが導入方法・コーディングルールをドキュメントにまとめ共有してくれました。
    おかげでコードの可読性が高まり、非常に良い開発体験になったと思います。

    ドキュメントの一部

    Gitに関してもチームメイトが運用ルールを制定してくれました。
    Branchの切り方、Branch名、Commitメッセージのルールをきめたおかげで見やすくなりました。

    Commitメッセージには絵文字を採用

またきちんとタスク分担が出来ていたのと、各々がコンフリクトを意識し作業ファイルを共有していたため、一度もコンフリクトを起こすことなく開発できたのはめちゃくちゃよかったです！

KPTで振り返る

KPTとは
「Keep・Problem・Try」の頭文字をとったKPT（ケプト）は、アジャイル開発における振り返りの手法として多くの組織で活用されています。仕事やプロジェクトなどを対象に3つの要素に分け、チームで現状分析と改善策を話し合い、業務の改善を続けていきます。

K：keep ＝ 成果が出ているので継続すること
P：problem＝ 問題があり改善が必要なこと
T：try ＝ 新しく取り組むべきこと

keep

朝会の実施

今回のチームはメンバー全員が無職ということもあり、リズムを整えて取り組むという目標を掲げ朝会を実施しました。
朝の10-12時にほぼ毎日集まるようにし、それぞれが黙々作業、たまに雑談する会です。
単純に顔を合わせる頻度が増えたおかげでコミュニケーションのハードルが下がり、チーム開発においても気兼ねなく意見を言い合える関係性が構築できたと思います。

会議にタイムキーパーを設ける

前半はタイムキーパーを設けず、会議を行っていたのですが話が脱線したり、決断を延長したり、と間延びしてしまうことがありました。

タイムキーパーを設け、どんな話題でも、「一旦この時間内だけ話し合う」と決めるようにしてからは
コンパクトで効率の良い会議にしていくことができました。

会議の事前準備（個人）

今回のチーム開発はPMを週ごとに変更して行う持ち回り制でした。

このPM持ち回り制度がシステム的にとても良かったです！司会進行役はできる人に自然と任してしまう...みたいな部分があると思うのですが、役割を与えられるとやらざるを得ないため責任を持って取り組めるという。
”この会議は自分がコントロールしなくては...！”という意識を持つことってあんまりなくないですか？

そして自分のターンがあるからこそ、他の人がPMの週も積極的、協力的にサポートしようと前のめりの姿勢を持つことができるわけです。

話が逸れましたが、そのシステムのおかげもあり、会議の事前準備をイメージして臨むことでコンパクトに進行することが出来ました。
チームメンバーからも進め方に関して褒めてもらえて嬉しかったです。

problem

詳細な情報共有

根幹に関わるような情報共有はしっかり出来ていたのですが、詳細部分の情報共有に不足がありました。

具体的に言うと、フォーマッターの設定に関して、「微妙に要らないかな〜」と思うルールがあったのですが、特段共有しなくてもいいか。で済ましていたところ、チームメンバーも実は同じことを思っていた　と後から発覚することが...笑

アイデア出しについて

前半部はタイムキーパーを設けていなかったのもあり、アイデア出しに時間をかけすぎてしまいました。
また一度、決定したアイデアがあったのですが、深堀っていくうちに実現が難しいと考えて没になったものもありました。この際、かなりの時間ロスになりました。

ヘルプ出しについて（個人）

今回の実際の実装期間は一週間で、4日目くらいに手が回らないな...と思い、メンバーにタスクの巻取りをお願いしました。残り日数的にもこのタイミングでヘルプをだせたのは良かったと思います。

ただもっと前段階でラフに実装に関するヘルプをだせたらもっと良かったと思っています。
個人の課題として、人を頼るのが苦手な部分があり、どうしても「時間を奪っちゃうな〜」、「質問が纏まってないから」と考えてしまい、腰が重くなってしまうことが多々あります。

評価

このチーム開発では、同じアプレンティス生徒からの投票が最も多いチームにBest Student Award, メンターからの投票が最も多いチームにBest Awardが贈られます。
私達はメンター賞であるBest Awardを受賞することができました。

評価ポイントとしては下記の言葉をいただきました。

  • ニッチな部分を攻めていて、ターゲットをしっかり定められている
  • UIが整理されている
  • ユーザー認証で登録の簡易化
  • 本番環境でもユーザーが見込めそう

まとめ

これがチーム開発なんだ！と開発期間後に余韻に浸っていました。
一回目は良くも悪くも分からないことだらけで役割分担も設計も何も無いといった状態でしたが、今回はその反省を活かし、ちゃんとした開発体験を積めたと思います。振り返るとガバガバだと思いますが...笑

そしてその中で自分の得手不得手に気づける機会も多かったです。
私は他のメンバーに比べると技術力が遥かに足りていないと思いましたし、技術そのものに対する興味も薄いと思いました。
どちらかというと、技術を使ってその先に何が作れるか、の興味が強く、そのニーズがあるか、コストと見合うか、といったビジネス的な視点で見るのが得意な方なのかなと思っています。
これは過去にプロゲーマーとして発信活動をしていた際に付いた能力というか癖のようなものな気がします。

こういった自分の特性を把握して、苦手な部分は積極的にヘルプをだし、得意な部分は自分が責任を持って巻き取るといったコミュニケーションを大切にしていきたいなと改めて思いました。

アプレンティス期間も残り少なくなってきましたが、頑張っていきたいと思います。

Discussion