koheitakahashiのブログ

2020.07.01にプログラマーとして生を受けた私が学んだことや、日常について徒然に書いていきます。

音楽をシェアしやすくするアプリ SoundLinks をリリースしました

f:id:NMP300:20211205194826p:plain

はじめに

koheitakahashi と申します。2019年からFJORD BOOT CAMPに入会し、2020年7月からWEBエンジニアとして受託開発会社に務めています。

今回、FJORD BOOT CAMPに在学していた頃から開発を続けていたWebアプリをリリースしました。

SoundLinksという、音楽をシェアしやすくするWebアプリです。この記事は、そのWebアプリの紹介と開発過程のまとめです。

SoundLinksの紹介

SoundLinksとは

SoundLinksは、楽曲を共有したい時に、音楽プラットフォームごとに楽曲のリンクを探すのが面倒という問題を解決したい、楽曲を共有したい人向けの音楽プラットフォーム横断検索サービスです。

ユーザーは、楽曲のタイトルを入力すると各音楽プラットフォーム毎の楽曲リンクを取得することができます。

これは、自分でそれぞれの音楽プラットフォーム内を検索してリンクを取得する場合とは違って、一度に複数の音楽プラットフォームのリンクを取得できることが特徴です。

リポジトリのURL: https://github.com/koheitakahashi/sound_links

アプリのURL: https://sound-links.com

解決したかった問題

Spotify、AppleMusic、KKBOX、YouTubeMusic...など、音楽プラットフォームが多様化しています。そのため、仲間内のSlackやDiscordで「この曲を共有したい」ときに気軽に楽曲を共有できない問題があると思いました。

例えば、自分はSpotifyを使っているが、楽曲を共有したい相手はAppleMusicを使っている場合です。Spotifyの楽曲リンクだけ共有しても、共有された側のAppleMusicユーザーは自分が使っているプラットフォームで共有された曲を聞くことができません。

この問題を回避しようと思ったら、相手が使っているプラットフォーム内で共有したい楽曲を検索しなければいけませんが、これでは気軽に楽曲を共有することができません。

そのような楽曲をシェアしづらい問題を解決するために、SoundLinksをリリースしました。

SoundLinksでできること

以下のキャプチャのように、音楽プラットフォームを横断検索できます。

そして、各プラットフォームごとの楽曲リンクをワンクリックでクリップボードにコピーすることができます。

SoundLinksの検索フォームに「リライト」を入力して、検索結果画面に遷移しているgif

クリップボードにコピーされる内容の具体例は以下です。楽曲名・アーティスト名・各プラットフォームのリンクがコピーされます。

リライト(ASIAN KUNG-FU GENERATION)
Spotify
https://open.spotify.com/track/3txqYlzoDZGLoW8MGll9tQ
Apple Music
https://music.apple.com/jp/album/%E3%83%AA%E3%83%A9%E3%82%A4%E3%83%88/1536394883?i=1536394888
KKBOX
https://www.kkbox.com/jp/ja/song/FcqGD-90I.n6HlVI7lVI70P4-index.html

後は、お使いのチャットツールなどにこの内容を投稿すれば、相手が使っているプラットフォームを気にすることなく楽曲をシェアできます。

2021/11/27現在、Spotify・AppleMusic・KKBOXの3つの音楽プラットフォームに対応しています。

開発過程

SoundLinksはリリースに至るまで、大きく分けて以下の過程がありました。

  1. バージョン0.1.0 開発・公開
  2. バージョン0.1.0で見つかった改善点を踏まえてバージョン1.0.0の開発・リリース

実際にどのようなことをしたのかを以下に書きます。

1. バージョン0.1.0開発〜リリース

1-1. エレベーターピッチを作る

エレベーターピッチとは、自分が作りたいサービスを30秒で伝えられるように明確化した文章です。

上記の SoundLinksとは の段落で書いている文章を作りました。

エレベーターピッチを作ることで、自分がこれから作りたいサービスの本質は何なのかということが明確になりました。それが文章化されていることで、実装したい機能を思いついた時に、実装するかどうかの判断がしやすくなりました。

具体的には「ユーザーログイン機能」「楽曲をお気に入り登録する機能」を思いつきましたが、このサービスは「シェアしやすくすることが目的」だと立ち戻ることができ、これらの機能は実装しない判断ができました。

1-2. ペーパープロトタイプを作る

ペーパープロトタイプとは、アプリの画面・UIを紙などに起こしたものです。実際に以下のようなものを作成しました。

SoundLinksのトップページのペーパープロトタイプ
SoundLinksのペーパープロトタイプ(トップページ)

SoundLinksの検索結果ページのペーパープロトタイプ
SoundLinksのペーパープロトタイプ(検索結果ページ)

これを作成したおかげで、どのような画面が必要なのか、どのようなUIが適しているのかなどの検討ができました。また、画面のゴールがイメージできたことで実装の見通しが立ち、リリースまでに実装しなければいけない機能・画面が洗い出しやすくなりました。

1-3. 実現可能かの調査 + 技術選定

このアプリが実現できるかどうかを判断するために、以下のことを調査・検討しました。

  • どのような音楽プラットフォームがあるのかを調査
  • 音楽プラットフォームから、どのようにして楽曲情報を取得するかの検討
    • スクレイピングでデータを取得するか、APIからデータを取得するか
    • スクレイピング可能かどうかを判断するために各プラットフォームの利用規約を読み込む
    • 各プラットフォームのAPI公開状況を調査

上記を調べた結果、スクレイピングは避けた方が無難という結論にいきつきました。そして、Spotify・AppleMusic・KKBOX・YouTubeがAPIを公開していたため、それらの4つのサービスに対応することとしました。しかし、YouTubeは後述の理由によりサポートを断念します。

技術選定について、Railsを採用・Herokuにデプロイすることを当初は考えていました。それまでRailsを勉強していたということと、フロントエンド側では複雑な処理をしないことから、JavaScriptのフレームワークを導入する必要はないという判断をしたためです。

しかし、開発を進めていく中でVue.jsを勉強したくなり、途中でVue.jsを導入しました。

1-4. 開発

タスク管理について

開発上のタスクの管理は、GitHub Projects でカンバン方式で管理しました。

その中で、大事だと思ったことが2点あります。

1点目が、やりたいと思ったこと、アイディアをすぐにissueに立てるということです。私が忘れっぽいため、アイディアを思いついたものの issue 化しておらず、結果で取りこぼしてしまったものがあると思います。そのようなアイディアを取りこぼさないためにも、すぐに issue 化してやるかどうかの判断は後でするということを実践できていればよかったです。

2点目が、調査や検討系のタスクもissueに切り出して、調査・検討のログを残しておくことです。APIの調査やアーキテクチャの検討などは開発の初期段階でやっていました。しかし、その内容をまとめていませんでした。今回は開発期間が大分長くなってしまったので、調査内容や意思判断の過程を忘れてしまって、再度調べ直すということがありました。

そのため、調査・検討のタスクをissueに切り出して、ログに残すことが大事だと思いました。

開発中の出来事

様々ありますが、大きな出来事は以下の2点でした。

1点目が、YouTube Data API から取得した楽曲と、他のAPIから取得した楽曲が同一のものだと判断できない問題に直面したことです。 そもそも YouTube Music 専用の API は公開されていなかったため、YouTube Data API v3 から楽曲情報を取得しようと考えました。しかし、その API から ISRC というレコーディングに対して付与される識別子(書籍の ISBN のようなもの)が取れませんでした。

各 API から取得される楽曲が同一かどうかの判断に ISRC を使用していたため、YouTube 対応を諦めざるを得ませんでした。

2021/11/28 現在、よい解決策が思いつかず YouTube は未対応となっています。しかし、自分で SoundLinks を利用していて YouTube のURLが取得できないとなると、楽曲をシェアできる相手が限られてしまうので解決策を考えています。

2点目が、Vue.js の導入です。 これは、自分が Vue.js を勉強したくなったという理由からです。最初はVue 2 で実装を進めていましたが、途中で Vue 3 を勉強したくなったため、Vue 3 を導入しました。Composition API の書き方については手探りで、これで良いのかという懸念がありますが、動くものができました。

1-5. 身近な方々へ公開

Herokuにデプロイして、身近な方々へ告知して実際に使っていただきました。フィードバックをいただき、実際に自分でも継続して使ってみて、デザインが大きな課題だと分かりました。

当初のデザインは以下のスクショです。

f:id:NMP300:20211128171644p:plain
SoundLinks バージョン0.1.0 のトップページ

f:id:NMP300:20211128171642p:plain
SoundLinks バージョン0.1.0 の検索結果ページ

デザイン面の課題を細分化すると以下の2つだと捉えました。

  • SoundLinks で何ができるかが分かりづらい
  • ユーザーが使ってみようと思えるデザインではない

そのため、バージョン1.0.0では上記の課題が解決できるように対応していきました。

2. バージョン1.0.0開発〜リリース

バージョン1.0.0の開発でやったことは大きく分けて以下の2点です。

  1. バージョン0.1.0の課題を改善
  2. アプリ構成の変更

2-1. バージョン0.1.0の課題を改善

前述したように「何ができるかが分かりづらい」「ユーザーが使ってみようと思えないデザインではない」ことが課題でした。そのため、「何ができるかのメッセージを強調する」「ユーザーが触ってみようと思える最低限のデザインレベルをクリアする」ということを目標にデザインを再度練り直しました。

デザインについては、これまで体系的に勉強したことがありませんでした。そのため、この際簡単な本を読んで基本を抑えようと思い、以下の本を読みました。

ページのデザインを再度練り上げるために使ったツールは Figma です。

f:id:NMP300:20211205185826p:plain
Figma でデザインを練り上げていたときの図

また、ファビコン・ロゴ・アイコンの作成は Canva を使いました。

f:id:NMP300:20211205190037p:plain
Canva でロゴを練り上げていたときのイメージ

そして、最終的には以下のようなデザインに落ち着きました。

f:id:NMP300:20211205190806p:plain
トップページ

f:id:NMP300:20211205190840p:plain
検索結果ページ

より詳しくデザインの変更を見たい場合は以下をご覧ください。

https://github.com/koheitakahashi/sound_links/releases/tag/v1.0.0

2-2. アプリ構成の変更

ユーザーの使い勝手を向上させるという目的ではなくて、自分の勉強を目的として以下のことに取り組みました。

  • 完全SPA化
  • AWSの利用

上記のどちらも経験が少なかったため、今回ある程度学んでみて「SPAとAWSの触りは知っている」という状態になりたかったという動機です。

合わせて Docker の基本も勉強したいと思い、以下のようなインプットをしました。

そして、Docker を使うなら ECR・ECS の構成が便利だと聞き、その構成を採用しました。こちらは体系的に学んだというわけではありませんが、以下の記事を参考にさせていただきました。その中で、分からないところは公式リファレンスを見て解決していきました。

最終的には以下の構成となりました。

f:id:NMP300:20211128171943p:plain
SoundLinksの構成図

工夫した点

Spotify・AppleMusic・KKBOX のAPIを使っているため、各 API で定められているリクエストの上限を超えないように、少しでもAPI へのリクエストを抑えようとしました。

具体的には、外部 API から取得した楽曲情報を一時的に DB に保存しています(有効期限は1日)。有効期限内にユーザーが同じ条件で楽曲を検索した場合は SoundLinks の API サーバーは外部 API にリクエストを投げません。代わりに、DB に保存された楽曲情報をブラウザに返します。

このような仕組みで、外部 API へのリクエストを少しでも抑えています。

開発の進め方の改善点

開発を進めるにあたって「開発期間が長くなった」という反省点があります。最初のコミットが2020年4月だったため、開発に1年8ヶ月かかっています(途中、半年ほど開発できていない期間がありましたが)。

実際にこの要因を考えてみると技術選定の段階で、「どのうような構成にするか」「どの技術を採用するのか」を詰めきれていなかったことが挙げられます。詰めきれていないせいで、採用する技術や構成を大きく変更してしまい、それが手戻りにつながったと考えます。

そのため、技術選定の段階で「どのような構成が一般的に採用されるのか」についてのインプットを増やさなければならなかったと思います。その上で「自分は何を勉強したいのか」をはっきり決めて、開発を進めていけると手戻りが少なく開発できたように考えます。

そもそも、使ってもらえるアプリを開発するためには、自分が思い描いた課題が本当にあるのかの検証を早めにしなければならなかったと思います。個人開発でリソースも限られているので、その検証をして課題があると分かってからてリソースを割くという戦略をとってもよかったかもしれません。

この経験を今後のアプリ開発に生かしていきたいと思います。

リリースしてみての感想

フィヨルドブートキャンプのメンターの方々、SoundLinks v0.1.0を公開した時に使ってくださった方々、意見をくださった方々に大変感謝しております。色々な方々の助けをお借りしながらも、開発するアプリを考えるところから始めてリリースするというフローを経験できたことで、勉強になることが多かったです。

また、開発を通してデザイン・Docker・AWS・Vue 3 などについて「あまり分からない状態」から「触りを知っている状態」になれました。

対応サービスが少ないこと、検索結果の表示速度など気になるところは多々ありますが、今後の課題としたいと思います。

0からアプリを開発することは非常に学びが多く、今後に活かしたい課題や改善点も見つかったため、これからのアプリ開発に生かしていきたいと思います。

SoundLinksの不具合・要望などがありましたら、SoundLinks のリポジトリの Issuesか、TwitterのDMでお知らせください。