ギターの指板図をさっと作れるサービスGuitar Scale Sketchをリリースしました
ギターの指板図作成ツール「Guitar Scale Sketch」をリリースしました。
自己紹介
フィヨルドブートキャンプ(以下FBC)でプログラミングを学習しているsadanoraです。 前職ではWeb制作会社でWebディレクターをしていましたが、「面白そう&業務に役立つ」という動機でプログラミングの学習をしているうちにプログラマを目指すようになりました。
好きな楽器はベースとピアノです。
Guitar Scale Sketchとは
Guitar Scale Sketchは、ギターの指板図を人に渡したり自分用に保存したい、ギターを弾く人向けの指板図作成ツールです。
指板の幅をきめてドットを打つだけで指板図を素早く作成できて、作った指板図はブラウザから印刷したり、URLをシェアして共有できます。
解決したい問題
- デザインツールなどで綺麗な指板図を作るのが手間
- Guitar Scale Sketchを使うことによって、指板の図を書き、抑えるポジションに印を付け、色を選択し、作った指板図を印刷用にレイアウトする、といった手間がなくなります。
- ネットや書籍にある指板図で練習をしているけど、実は情報が多すぎる/少なすぎると感じている
- 自分がいま練習したい情報に絞った指板図を簡単に作れます。
ギターの先生が「次までにこれを練習してきてね」と指板図を生徒に渡したいケースのような、「指板図をさっと書いて誰かに渡したい」という人には特に便利に使ってもらえるんじゃないかと思って開発しています。
使い方
- Googleアカウントでログイン
- ログインしなくても使えます。ただしログインしないと指板図の保存ができません。
- 「指板図をつくる」画面で指板図を作成、保存
- 練習🎸
- 自分で使う場合はそのままギターの練習をしましょう。
- 誰かに渡したい、シェアしたい方はURLを相手に伝えましょう。紙で手渡したければブラウザから印刷もできます。
技術スタック
canvasの描画
ソーシャルログイン
テスティングフレームワーク
Linter/Formatter
CI / CD
インフラ
フロントエンドにHotwireを使ったRailsアプリです。指板図の描画はKonvaというライブラリを使ってcanvasで描画しています。
開発経緯
なぜこのサービスを作ることにしたか
FBCでは自作サービスを作るにあたり「自分で考えたサービスを作る」or「FBCで用意したサービス案から選んで作る」どちらかを選択できます。 自分の場合は後者で、FBCが用意したサービス案のリストから「ギターの指板図が簡単に作れるサービス」を選びました。
最初は何か自分で考えたサービスを作ろうかといくつかアイディアを出したりしたものの、FBCのサービス案でみかけた「ギターの指板図が簡単に作れるサービス」について、ふとした時に考えていることが多いことに気づき、「自分は結構このサービス作りたいのかもしれない」ということでこのサービスを開発することを決めました。
もうすこし細かく説明すると、自分はギターはあまり弾いたことがないのですがピアノやベースといった楽器には学生時代に下手くそなりに触れていて、今も気晴らし程度にたまに触ります。 自作サービスのプラクティスに入った時期は、「スケールを覚えてジャズのアドリブとか自分で弾けるようになりたいな」と思っていた時期だったので、ギターのスケール練習のためのツールであるこのサービスが余計に気になったという感じです。
この「ギターの指板図が簡単に作れるサービス」はFBCのメンターのmachidaさんが欲しいサービスということで、ユーザーであるmachidaさんに色々とヒアリングしながら開発を進めていきました。
エレベーターピッチ
FBCのサービス案は最初から仮のエレベーターピッチが用意されているため、ゼロからエレベーターピッチを考える必要はありませんでした。
ただ、ギターの練習をしたことがない自分にはこのサービスによって何がどう便利になるのかいまひとつピンときていなかったので、ユーザーであるmachidaさんに色々とヒアリングし、それを踏まえてエレベーターピッチを練り直しました。 Web上には指板図作成サービスが色々とあるので、それらでは何が不満なのか、今回作るツールと何が違うのかを聞きました。
自分の理解が足りなくて同じような質問を何度かしてしまうこともありましたが、ユーザーが解決したい問題についてしっかり聞いておかないとブレたものを作ってしまいそうだったので、わからないことは繰り返し聞きました。
元々用意されていたエレベーターピッチ
[指板図ジェネレーター] というサービスは、 [ギターの指板図を書くのにお絵かきツールを使い自分でデザインをしなくてはいけない問題] を解決したい [ギターを練習している人] 向けの、 [指板図作成ツール]です。 ユーザーは [用意されたブランクの指板上のポジションにドットを打つだけでスケールの指板図画像を作成、ダウンロードすること] ができ、 [イラレで作成するの] とは違って、 [自分でデザインする必要なく綺麗で見やすい指板図になる機能] が備わっている事が特徴です。
ヒアリング後
[指板図ジェネレーター] というサービスは、 [練習したい運指に最適化された指板図の画像を作成する際に、指板の図を書き、その指板の抑えるべきポジションに印を付け、色を選択、作った指板図を印刷用にレイアウトするという作業が発生する問題] を解決したい [ギターの指板図を人に渡したり自分用に保存したい人] 向けの、 [指板図作成ツール]です。 ユーザーは [用意されたブランクの指板上のポジションにドットを打つだけで指板図画像を作成、ダウンロードすること] ができ、 [書籍やネット上にある指板図を参照したり、自分でデザインツールで作成したりするの] とは違って、 [いま反復練習したいスケール、運指に最適化された綺麗で見やすい指板図を素早く作成できる機能] が備わっている事が特徴です。
大変だったこと・工夫したこと
指板図の描画機能
指板図の描画機能はKonva、Hotwireなどを使って実装しました。初めて扱う技術ということもあってこれが難しく、開発時間の大半は指板図の描画機能に費やされました。
特にクリックイベントに応じて指板図にドットを追加、削除する処理は最初どう実装していいかわかりませんでしたが、処理の流れがイメージできない状態からタスクの粒度を細かくする（タスクバラシ）ことで少しずつ前に進んで行くことができました。開発を進めるにつれ、一度に複数の要件を扱って混乱するのを段々と避けるようになっていったと思います。
自作サービス以前のFBCの学習の進め方が「スクール側が用意したプラクティスの終了条件を達成して進めていく」ものだとすると、自作サービスは「自分で終了条件を考えてプラクティスを作って進めていく」ようなものかもなと開発中はよく思っていました。
フロントエンドの技術を途中で変える
フロントエンドの実装はHotwireを使っていますが、実は当初はTypeScriptとReactを使って進めていました。 TypeScriptとReactはいつか学習してみたいと思っていた興味がある技術だったため、自作サービスの機会に使ってみることに決め、自分で学習をすすめました。(当時これらはFBC内のプラクティスでは学ばない技術だった)*1
実際にモックなども作って技術検証を進めていたのですが、ちょっとしたことの実装でもかなり時間がかかってしてしまっていて、使いこなせるまでにはまだまだ時間がかかりそうなことがわかってきたところで色々と不安が押し寄せてきました。
- このままだと息切れしてしまって自作サービスを作り切れないのではという不安
- TypeScriptやReactの学習に想定以上に時間が取られてしまっている
- どうしたら便利に使ってもらえるかとか、サービスにとってより重要な問題に割く時間を圧迫している
- 想定していた自作サービスの開発期間を超えてきてしまっている
- 開発の初期の時点で、当初考えていたスケジュールの期限がすでに迫ってきていた
- 想定通りに進めるのは難しいとしても今後も同じペースで進んでいくなら厳しい
- 無職なので、いつまでも開発しているわけにもいかない
- 開発の初期の時点で、当初考えていたスケジュールの期限がすでに迫ってきていた
こんな風に思っていたところで松本で開催されたRubyKaigi 2023に参加したのですが、そこで自作サービスでHotwireを選択したFBCの卒業生の話を聞く機会がありました。 これ以上TypeScriptとReactでつまづいているくらいならHotwireに切り替えるのもありかもしれないと思いいくつかチュートリアルなどをこなした結果、Hotwireがとても使いやすかったので移行することに決めました。
Hotwireと言っていますが、Rails7でデフォルトで有効なTurbo Driveこそそのまま有効にしているもののTurbo FramesやTurbo Streams*2を意識して使っている箇所はなく、実際はJavaScriptフレームワークをStimulusに乗り換えたという感覚が近いです。
サーバーに画像を保存しないようにした
ユーザーが作成した指板図の情報(指板の数、幅、ドットの座標、色など)はDBにJSON形式で保存しており、詳細画面や編集画面ではそのJSONを元にKonvaで指板図を描画しています。
詳細画面では単にDBに保存しておいた画像を表示することも検討しましたが、JSONの方がストレージに保存する容量を節約できるメリットがあるためこのような構成をとっています。
画像を扱うのであれば学習する必要があったであろうActive Storageなどについて考える必要がなくなったこともよかったです。
名づけの難しさ
指板図はRailsのモデル名を当初Scoreとしましたが、最終的にはFingeringに変更しました。 Scoreというと楽譜のことですが、開発を進めるにつれ楽譜と言い切ってしまうには違和感がある名づけであることに無理が生じてきたためです。
英語のギターの教本でどんな表現がされているか調べたり、ギターの指板図に関連するライブラリをGitHubで検索したりとしましたが、自分のケースでそのまま使えそうな英語が見つけられなくてモデリングの仕方がおかしいんじゃないかと不安になりつつも、質問雑談タイム*3で何度か質問しつつ、今の形に落ち着きました。
質問雑談タイムは、チーム開発のプラクティス*4に入る前くらいまではラジオ参加（聞いてるだけ）が多かったのですが、自作サービスの開発中は生煮えの状態でも気になることがあったらなるべく質問や相談をするようにしていました。
とにかくやることが多い
当たり前ですがインフラからCSSまで全部自分で実装するのでやることの範囲が広く、こんなに色々やるのかと思いました。
- 調べる
- 試す
- 決める
- 実装する
- 検証する
些細なことでも上記を自分で考えながら繰り返していくので、わからないことへの耐性が上がったと思います。
サービス名の決め方
自分で考えたり、Chat GPTに壁打ち相手になってもらったりして決めました。 ポイントとしては、あえてサービス名にScaleという単語を入れてギターのスケールに関係したツールっぽさを出したことです。
指板図作成ツールなのでスケールに限らずコードを書いて使うことも出来なくはないのですが、メインのターゲットとしてはスケールの練習をする人のためのツールなので、「スケールの練習のためのツールです」という雰囲気を出しました。
機能の検討
解決したい問題に対してユーザーが使えるものを提供できるのであれば、余計な機能をファーストリリースに盛り込まないようにしました。 指板図の並び替えやコピー、ユーザー名の編集など欲しい機能がいくつかありましたが、ファーストリリース前に開発する意味があるのか考えて不要と判断したものはどんどん削り、とにかくファーストリリースまで辿り着くことに集中しました。
Gitのコミットメッセージ
semanticコミットメッセージとgitmojiを試してみました。
Semantic Commit Messages · GitHub
gitmoji | An emoji guide for your commit messages
コミットログがemojiで賑やかなのは良いのですが、typeやemojiの使い分けが統一できていない、オレオレルールでしかないなど、自分には使いこなせなかったなあと思っています。 経験として一度試せたことはよかったです。
最後に
開発初期から中盤はなかなか進捗が出せず、本当にリリースできるのか...？と不安な時もありましたが、後半になるにつれ開発している時間がだんだんと楽しくなっていったと思います。 理由として思いつくものを挙げてみます。
- やることが明確になり、かつ初見の技術の検証のような見積もりが難しいタスクが少なくなっていった
- 「これから作るもの」より「作ったもの」の割合が増えてきてサービスの形がみえてきた
- 開発開始当初は全く知らなかった技術も、知っていることが少しずつ増えてきた
- 「知らないこと」「わからないこと」との付き合いに慣れてきた
FBCのメンターさんや受講生、卒業生のみなさんなど、色々なところでアドバイスいただいたり話を聞いてもらえたこともとても大きかったです。 一人でやっていたらリリースまで辿り着けたかわかりません。
ギターを弾く人の中でも割とニッチな要望に応えるツールだと思いますが、ピンときた方は是非使ってみてもらえると嬉しいです。
