【Next.js × Rails】チーム開発 Twtichクリップのプレイリスト作成アプリ

目次

はじめに
作成したプロダクト
開発の流れ
自分の振り返り
まとめ

はじめに

私は現在、アプレンティスシップというエンジニア実習サービスに参加をしており、
WEBエンジニアに必要な技術を習得すべく日々勉強中です。

つい先日、第2回チーム開発が終了いたしました。
そこで私達のチームは、現役エンジニアの審査員の方々からBestAwardをいただくことができました！チームメンバーで頑張って作り上げたものが、こういった形で評価していただけたことを非常に嬉しく思っています。

今回は、作成したプロダクト紹介、チーム開発の振り返りをしていきたいと思います。

作成したプロダクト

List It Bro! for twitchとは

私達のチームは、Twithクリップのプレイリスト作成アプリ
「List It Bro! for twitch 」を作成いたしました。

Twichとは、ライブストリーミングサービスで、特にゲーム配信が人気コンテンツとなっています。その配信でのハイライトや面白い瞬間を視聴者は簡単に切り取ることができ、他のユーザーへ共有することができます。この切り取られた動画のことをクリップといいます。

現在のTwitchにはクリップのプレイリスト機能がなく、自分のお気に入りのクリップをまとめたり、クリップを人にまとめて共有するということが容易ではありません。

そこで、Twitchが大好きな私達のチームは、Twitchクリップのプレイリストを簡単に作成できるサービスを開発しようということになりました！

機能

プレイリスト機能

プレイリスト機能は、プロダクトのメイン機能です。
好きなクリップを簡単にプレイリストに保存することができ、いつでも好きなクリップを見返すことができます。また、公開されているプレイリストをお気入りすることで、マイページからいつでもお気に入りしたプレイリストを見返すことができます。
プレイリストに関する機能は以下のとおりです。

• プレイリスト作成
• プレイリスト内クリップの追加・削除・並び替え
• プレイリスト内クリップの再生
• 公開されているプレイリストのお気に入り登録
• プレイリストをXにて共有

Twitch APIによるアカウント作成の簡略化

TwitchアカウントのIDを基にユーザー管理を行っているため、本サービス内でのアカウント作成手続きを省略できます。マイプレイリストやお気に入り機能を使用する場合、ユーザーはTwitchアカウントを持っている必要があります。しかし、Twitchアカウントを持っていない場合でも、公開されているプレイリストやクリップランキングの閲覧は可能なため、Twitchのクリップのみを見たいユーザーもご利用いただける様になっています。

簡単クリップ視聴

プレイリスト内のクリップを１アクションでストレスなく再生することができます。
また、クリップ再生画面の右側のプレイリストから再生したいクリップをユーザーが選択して再生させることも可能です。

こちらが実際のサービス画面です!

開発の流れ

開発の流れは大きく分けて以下の通りです。

1. 課題定義
2. 要件定義
3. 設計
4. タスク出し
5. 環境構築
6. 実装

1. 課題定義

アイディア決め

今回のチーム開発は、「ワクワクするものを開発せよ」というテーマでした。
まず、私にとっての「ワクワクするもの」を以下の2つで定め、アイディア決めに取り組みました。

• 自分たちが作っていて楽しい
• 自分たちが使いたいと思える

私達のチームは、以下の流れでアイディア出しを行いました。

1. 「ワクワクするもの」というお題でブレスト
2. ブレストで意見が多かったジャンルを再度ブレスト
3. 「最近の悩み」というお題でブレスト
4. 「好きなこと」というお題でブレスト
5. 今まで出てきたアイディアを数個に絞り、深堀り

アイディア出しに苦戦していましたが、最後に実施した「今まで出てきたアイディアを数個に絞り、深堀り」をしたことで、それぞれのアイディアがより具体的になり、プロダクトのイメージが湧くようになりました。

その中でも、自分たちの好きが共通しているゲーム関連のお題が一番ワクワクするという意見でまとまり、「Twitchクリップのプレイリスト作成アプリ」を作成することにしました。
また、アイディアの深掘りと合わせて既存サービス調査もしましたが、Twitchクリップのプレイリストを作成するサービスがなかったことも大きな決め手の一つです。

▼ ブレストの一部

課題定義

アイディアを決定後、チーム全体の向いている方向を揃えるため、
ターゲット・背景・目的を明文化し、チームで話し合いました。

また、このアイディアに対する不安点・疑問点をみんなで出し合い、
早めから調査及び確認をできる体制を整えました。

• ターゲット
  • Twitchを見ている人
    • お気に入りのクリップを簡単にまとめたい
    • 面白いクリップを人（友達・視聴者・配信者）に共有したい
• 背景・理由
  • Twitchにプレイリストの機能がないから
• 目的
  • Twitchクリップのプレイリストを簡単に作成できるようにすること

2. 要件定義

以下の流れで要件定義を実施いたしました。

1. 実装機能の書き出し
2. カテゴリー分け
3. 重要度付け

「必須」「重要」「推奨」「やらない」の４項目で重要度付けをしたことで、
どの機能を優先的に実装すべきかが明確になり、実装フェーズで優先度を意識した開発が行えました。

▼ 要件定義の一部

3. 設計

スライド作成

スライドを先に作成することで、背景・課題・目的を再度明確化をしました。
また、デモで紹介する箇所を決めておくことで、見せる箇所に重点をおいて開発ができます。
以下は、発表スライドの一部です。

画面遷移図・ワイヤーフレーム

画面遷移図及びワイヤーフレーム二関しては、Figmaを用いて作成しました。
MiroよりFigmaのほうが矢印の使い勝手が非常に良く、画面遷移図作成に向いていると思ったため、チームメンバーに提案しFigmaで作成いたしました。

▼ Figmaで作成した画面遷移図・ワイヤーフレーム

テーブル構築

テーブル構築はチームメンバーの一人が代表して取り組んでくれました。
私も自分事化をし、テーブルに間違えている箇所はないか、足らない箇所がないかを探すよう意識をし、テーブルの完成度をより高めるように取り組みました。

▼ テーブルのER図

4. タスク出し

タスク出し

フロントエンドのタスクが完了した後、それに紐づけてバックエンドのタスクを割り当てる流れを検討していました。しかし、バックエンドでの処理が重複するタスクや、バックエンド専用のタスクがあり、紐づけが困難な状況に直面しました。
このような問題に直面したため、私はバックエンドのタスクも独立して管理する方が効率的だと考え、この提案をチームメンバーに行いました。その結果、バックエンドのタスクはバックエンド専用で割り当てるように変更しました。
また、バックエンドのみのタスク出しにしたことで、API設計も併せて取り組むことができました。

▼ バックエンドのタスク出し 一部

ガントチャート

タスク出しで出したタスクをガントチャートに落とし込みました。
また、実装フェーズに出たバグやタスクも書き足して、ガントチャートで期限管理をしました。

▼ ガントチャートの一部

5. 環境構築

フォーマッター・リンター構築

私は、フォーマッター・リンターの構築を担当しました。
導入したフォーマッター・リンターは以下のとおりです。

• 全般　　　　　：VSCode, EditorConfig
• フロントエンド：ESLint, Prettier
• バックエンド　：Rubocop, Solargraph

チームメンバーが導入しやすいように、Notionに内容をまとめ共有しました。
また、それぞれどのような設定が入っているのかも明確に記載し、開発を進める中でいらない機能及び変更してほしい機能をすぐに対応できるようにしました。

Git運用ルール

GitHubを用いてのバージョン管理を実施するにあたり、Git運用ルール決めを行いました。
チームメンバーで話し合い、branch名の命名規則、commitメッセージのテンプレ化などを決めました。

Postman

API開発において、環境設定やAPIリクエストの共有が作業効率を向上させると考え、Postmanのワークスペースを設立し、私はそれをチームメンバーと共有しました。無料プランでは最大3人までの制限があるため、チーム全員を追加することはできませんでしたが、バックエンド開発を担当する2人で情報を共有し、同じデータを確認し合うことができました。

6. 実装

自分の担当機能

私は主にバックエンドの機能を担当しました。
担当した機能は以下のとおりです。

1. バックエンドのTwtichAPI処理
2. ダミーデータ(seeds.rb)の作成
3. ユーザー管理をするusersコントローラー
4. ホーム画面の情報を表示するHomeコントローラー
5. (ヘルプ) プレイリスト画面のデザイン

実装内容・工夫点

1. バックエンドのTwtichAPI処理

Twitch APIとの通信を行い、必要な情報を取得する処理を実装しました。
HTTPリクエストには、こちらの記事を参考にさせていただき、メモリ使用料が一番効率的であったhttp.rbライブラリを採用しました。
Twitch APIと通信を行った処理は以下の通りです。

• アクセストークン
  • Authorization code grant flow（ユーザーアクセストークン）
  • Client credentials grant flow（アプリアクセストークン）
• データ
  • Get Users（ユーザー及びチャンネル情報）
  • Get Clips（クリップ情報）
  • Get Followed Channels（ユーザーのフォローチャンネル情報）
  • Get Games（ゲーム情報）

2. ダミーデータ(seeds.rb)の作成

発表で使用するダミーデータの作成をいたしました。
ダミーデータがあることで。デザインの検証やテストがよりスムーズに進むため、私はこの作業を最優先事項として扱いました。バックエンドでのTwitch API処理と並行して、実装期間開始後3日でダミーデータの作成を完了しチームメンバーへ連携いたしました。

3. ユーザー管理をするusersコントローラー

usersコントローラーでは以下2つのメソッドを実装いたしました。
こちらもhttp.rbライブラリを使用して、HTTPリクエストを実装いたしました。

• users#create

  • Twitch APIを利用して、クライアントのアクセストークンを用いてユーザー情報を取得後、MySQLに登録する処理

• users#show

  • TwitchAPIを利用して、ユーザーがフォローしているチャンネルを取得し、ユーザー情報と合わせてクライアントへ返す処理

4. ホーム画面の情報を表示するHomeコントローラー
homeコントローラーでは以下のメソッドを実装いたしました。
3つのテーブルから情報を取得する際に、includesメソッドを使用してN+1問題を防ぐことに注力しました。

• home#index
  • ホーム画面の人気プレイリスト一覧情報を返す処理

5. (ヘルプ) プレイリスト画面のデザイン
プレイリスト画面のデザインを実装いたしました。
画面実装にあたって、以下の点を工夫して実装いたしました。

• 保存しているクリップが増えた場合でも、プレイリスト情報が常に見られるようにサイドバーを固定しました
• サイドバーのサムネイルからもクリップ画面に遷移できるようにしました
• アイコンを多用することで、視覚的に情報が入ってくることを意識しました

自分の振り返り

KPT

Keep

○ 自分の意見を積極的に発言する
　間違いを恐れず自分の意見や疑問点を積極的に発言することで、チームメンバーと歩幅をあわせてチーム開発を進めることができました。また、実装期間は自分の進捗度を毎日報告することを意識し、いつまでに自分のタスクが終了するかを常に情報共有できていました。

○ 大切な情報を共有するときは文章やイラストでまとめる
　フォーマッターやダミーデータの詳細はNotionに記載し、ユーザー登録周りの処理はFigmaに図示をして共有しました。チームメンバーからも理解しやすいため助かるという意見をいただけました。

▼ Figmaで共有したイラスト

○ チームメンバーのタスク巻取り
　ガントチャートを用いたスケジュール管理により、計画通りにタスクを進行することができました。その結果、予備として確保していた時間を、チームメンバーのタスクのフォローに充てることができました。

Probrem

△ 優先度の低い話を広げてしまう
　自分の意見を積極的に発言することに意識を取られており、優先度の低い機能の話を掘り下げてしまい、チーム会の進捗スピードを落としてしまいました。

【実施内容】
　チーム開発の半分が終了時点で、反省会の実施をチームに提案し、自分も含め再度プレゼンファーストの開発を意識するようにチーム全体で話し合いました。

△ 時間意識ができていない
　チーム会をする際にタイムキーパーを設けずに会議を進めていたため、会議時間が毎回２時間を超える長時間になることが多々ありました。

【実施内容】
　これに関しても上記同様、反省会にてチーム内で話し合い、どんな議題でも時間を図ることでより効率的に会議を進められるようになりました。

△ サーバーのタスク出し
　フロントエンドのタスクをベースにバックエンドのタスク出しを行ったため、バックエンドでの処理が重複するタスクや、バックエンド専用のタスクがあり、効率が悪く感じました。
【実施内容】
　バックエンドで独立したタスク出しを実施したほうが良いと感じたため、チームメンバーに早急に提案し、バックエンドのみのタスク出しを行いました。その結果、バックエンドのタスク管理が容易となり、タスクの役割分担もやりやすくなりました。

△ アイディア決めに時間がかかった
　アイディア出しだけで4,5回会議をしており、予想以上に時間をかけてしまいました。
【実施内容】
　今までに出てきたアイディアの種を深堀りすることによって、よりアイディアが具体的になり多くの意見が出るようになりました。

Try

• 優先度を意識して話し合いに価値があるのか判断する
• 会議にはタイムキーパーを必ず設けることで時間意識を忘れない
• フロントタスクとサーバータスクは別々でタスク出しを実施し、互いに確認で漏れを防止する
• アイディア出しはアイディアの深堀りを意識する

チームメンバーからのフィードバック

チーム開発を終えた際に、チームメンバーから自分への「良かった点」と「もっと良くなる点」についてのフィードバックを受け取りました。

良かった点

• 目の前にタスクだけにとらわれず、より広い視野での考え方も合わせてできていたと感じた。特に開発専念週のときに自身のタスク外の色々なことに気づけていた印象がある。
• 自分自身が落とし込めていないところ、もやもやする部分にしっかり向き合うところ。まあやっていくうちになんとかなるやろ精神で進まない
• 気が利く。誰がやってもいいタスクが生じたときにスッと率先してやってくれたり 見えないところをやっておいてくれてたりで助かった。
• 物事の進め方が丁寧ですごいと思いました。曖昧な部分をそのままにせず、一度図に纏め共有する、フォーマッターの設定では相手の疑問点に対する回答を予め意識してドキュメントを作成したりと頼りになった！

もっと良くなる点

• 後半は全然感じなかったが、前半は少し細かいところの話題に逸れてしまうことがあった気がする。でも、タイムキーパー制度をしっかり目に実装して、今話すことと後で話すこととかをちゃんと整理できてからは、自分も含めて全員、そういった問題はなくなったと思うので、あまり気にすることでもないかも。
• 卒なく何事にも対応するイメージで、弱点が見えづらいためラフに声をかけづらい部分があったかも！
• 意識的に弱みを見せることでコミュニケーションが円滑に進む部分があるかもな～と思いました！
• 逆に言えば厳密性を求めすぎて進行しづらい状態があった印象です。割り切れるラインがもっとこちらに伝わっていればスムーズに進行出来た気がします！

メンバーからの意見をいただいた感想

メンバーから客観的なフィードバックを受けることで、自分自身では気づいていなかった長所や短所を明らかにすることができ、大変感謝しています。チームメンバーからいただいた言葉を今後も忘れないため、自分自身の言葉で置き換え、さらなる成長の糧にしていきたいです。

継続

• 不確かな箇所や自分自身が理解できていない箇所としっかりと向き合う
• 常に周りの状況に気を配り、リスクヘッジを行う

改善

• 物事の優先順位を見極め、どこに注力すべきかを判断して行動する
• もっと自分をオープンにし、無理に力を入れすぎないよう心がける

まとめ

２回のチーム開発を通して、チームで１つのプロダクトを作成する楽しさ、そして難しさを少しは知れたのではないかと思っています。現役エンジニアは、これよりも大規模なプロジェクトを進めていることを考えると少し不安になりますが、出来ることから一歩ずつ前進していきたいです。

改めて、Best Award賞を一緒に掴み取れたメンバーに感謝したいです。
今後もエンジニアとして互いに高め合える関係でいたいなと心から思いました。

最後まで読んでくださり、ありがとうございます。