YouTubeを使ってシャドーイングを行い学習記録を作るアプリをリリースしました
はじめに
こんにちは。所属するフィヨルドブートキャンプ(以下FBC)の最終課題である自作サービスにて、Shadone(しゃどーん)というWebアプリを作成しリリースしました。 このアプリについて紹介させていただくとともに、作る過程で学んだこと、苦労したことなどを共有できればと思います。
目次
自己紹介
2020年10月からFBCで学習を続けてきたトミーと申します。
趣味は語学の勉強で、DuolingoのStreakは1205(2022年9月12日時点)です。
英語をもっと流暢に喋れるようになりたいと思っているので、語学学習のモチベーションを保ち続けるために自分が欲しいと思っていたシャドーイングのためのWebアプリを作成しました。
サービス概要
YouTubeの動画を使ってシャドーイング学習を行うためのアプリです。 フォームからURL、ループ開始・終了時間、ループ回数、再生速度を指定して動画を再生させ、その間シャドーイング学習を行うことができます。 学習が完了(=設定したループが終了)すると学習記録が作られ、学習に使ったYouTubeのURLと学習時間を集計し記録することができます。
サービス名の「Shadone」は「Shadowing」と「Done」を掛け合わせたものです。シャドーイング学習後にDONEのスタンプがカレンダーに付くというアプリの特徴を表しています。 サービスの名前が思いつかずFBCのDiscord上で募集した際、友人のudaさんが「しゃどーん」という名前を考えてくれて、最初はダサすぎて絶対イヤだと思っていたのですが、どうしてもキャッチーさが耳から離れずいつの間にか採用していました。
使い方デモ動画
野菜についている「私が作りましたマーク」的な動画です。 がんばって英語でサービスの使い方を説明しているので、良かったら見てみてください！(日本語字幕もあります)
使用技術
- Ruby 3.0.3
- Ruby on Rails 6.1.5.1
- Vue.js 2.6.14
- TailwindCSS
- RSpec
Vue.jsの2系を選択した理由は、使いたいと思っていたvue-youtubeというライブラリが2系にしか対応していなかったためです。 近い将来、Vue3系へのアップデートは必須で行わなければいけなくなってしまったので、2→3へのアップデートの練習素材としてこれからもメンテしていこうと思っています。
サービスを作った理由
私は毎日シャドーイングの学習を30分行っているのですが、やり方はわりと特殊なんじゃないかと思っています。
- 1分弱の音声教材を用意
- その音声教材を30回ループ
- 実際にかかった学習時間と学習したコンテンツを記録
この際ネックになるのが、まず「1分弱の音声教材」がなかなか見つからないことです。以前は知人に作ってもらったMP-3の音声教材を使っていたのですが、毎日学習しているためストックはすぐに切れてしまいました。 この問題はYouTubeを使うということで解決しました。
YouTubeのABループが行えるChrome拡張機能を入れて学習していたものの、モチベーションはどんどん下がってしまい、学習しない日が増えてしまいました。 理由を考えてみると、以下が思いつきました。
- 一旦YouTubeを開くと別の動画に気を取られて学習に集中できない
- 学習記録を作るアナログな作業に億劫さを感じ、やりっぱなしになってしまう
思えば私は収集癖があるためか、DuolingoのStreak、GitHubの草、FBCの学習カレンダーなど、過去に作った記録を見返すことで「こんなにがんばったんだな」とモチベーションを保てていると思い当たりました。
そのため、シャドーイング学習のモチベーションを保つことに特化したアプリケーションを自分のために作りたいと考え、YouTubeでシャドーイングを行なって、そのまま学習記録が勝手に作られるという機能を持つShadoneを作成しました。
こんな人に使ってほしい
- 語学学習のモチベーションを維持したい方
- 自分のレベルに合ったシャドーイング用教材を探している方
- 英語以外の言語を勉強している方
私はYouTubeのループは外国語学習にしか使う予定はなかったのですが、機能を説明すると楽器やダンスを練習している方に「使ってみたい」と言ってもらえることがあったのは意外でした。あともっと意外だったのは「落語の練習にもよさそう」と言ってくれた方がいたことです。落語もシャドーイングして練習するものなんでしょうか？
なのでYouTubeの一部を繰り返して技術を習得したいと思っている人全てに使ってもらえたら嬉しいです！
技術面で苦労したこと
Vue.jsが難しい
Vue.jsにもJavaScriptにも苦手意識があったのに、アプリの大部分をVueで書く必要があったのは大変でした。 チーム開発のプラクティスでは、Rails側のデータをjbuilderを介してVue側で受け取り使用するというコードは何度も見かけましたが、自分のアプリではVue側で作成したデータをRails側のDBに送るという逆の操作を行う必要があり、データの受け渡し処理の流れを理解できていなかったためコードを修正するたびにリクエストを送り、ネットワークタブでステータスコードやペイロードを確認しながら理解を進めていきました。
またVueのコンポーネント間のデータの受け渡しが必要で、以前チーム開発で使ったVuex(Pinia)を使って非・親子間のデータ受け渡しを行うつもりでしたが、Piniaのドキュメントを読み進めたところ「同一ページ内での処理の場合は使うべきではない」と記載されていたため、コンポーネントの設計を考え直す必要があったのも大変でした。 ブートキャンプのチーム開発だと、すでに大部分ができているところに機能を追加するため技術的にある程度の制約があり、その分考えなくていい面もあるのかなと思います。一方いちからアプリを作るとなると、全てが自由である分、設計からよりよいものを考え選択する必要があるという難しさがあることも学びました。結局クラシックなVueのコンポーネント間データ受け渡し手法である親子間でのバケツリレーを選択しました。
Vue.jsにはとにかく苦しめられましたが、その分力もついたかなと自負しています。機能の実装が完了し、デザインを入れるタイミングで学習記録の編集画面は消し、編集フォームを付与したSPAにしたいと思った時、その場でさほど苦労せずに編集フォームのコンポーネントを作れている自分がいて、ちょっとびっくりしました。
timezoneが難しい
コードレビューを受けている途中で、Railsでtimezoneの設定を行なっていなかったためアプリ内の時間がUTCになっており、日本時間午前0時〜8時59分(8月時点)の間に学習記録を作ると前日の日付で学習記録が作られてしまうというバグを発見しました。
このサービスは日本に限らずいろんな国の方に使ってもらえたら嬉しいな〜と思って開発したので、ユーザーに合わせてtimezoneを変更する必要があると判断したのですが、Railsアプリのtimezoneを動的に変更する方法に関する資料がなかなか見つからず苦労しました。
結局、アプリ内のtimezoneはUTCに統一し、学習記録のレコードが作成されるタイミングでブラウザから受け取ったユーザー固有のtimezoneを反映させることで解決しました。
timezoneに関しては実装についてもテストについても知らないことばかりだったので、近いうちに自分が調べたことを別記事でまとめたいと思っています。
開発を続けるために役に立ったもの
人と比べたり将来が不安で落ち込むことは多かったんですが、その度に具体的なアクションに結びつけることは気をつけていました。 私がやっていた珍しい取り組みとしては、フィードバックのためのペアプロを週1ペースでお願いしていたのと、ポイント付け会とYouTubeでの進捗報告くらいでしょうか。
週1のペアプロ
メインとなるYouTubeのループ機能が完成したあと、バグっている部分がどうしても解決できずペアプロで見てもらった際、自分では壊れていると思っていなかったRailsの基礎的な部分がガタガタで壊れているという事実を指摘され、とても自信を失い落ち込みました。
というのも、私はチーム開発のプラクティスでは色んな方にペアプロしてもらってIssueをこなしたため、その分自作サービスでは自分で調べ勉強しながら作っていきたいと思い、(そのときのペアプロまで)ほぼ人に頼らずに好きなように書いて、動くものを自分で作れるのはなんて楽しいんだろ〜！と思っていたためです。
このペアプロのあとは、頭が真っ白になってしばらく呆然としてしまうくらいには落ち込んだのですが、でも冷静になると全て言われた通りでした。とりあえず私に分かっていたのは、現時点の自分はRailsにもVueにも知識の穴がたくさんあること、卒業までになんとか目につく穴は埋める必要があること、そのために今の自分にできることをするしかないということでした。
落ち込んでいる中で思いついたのが、とにかくフィードバックループを早く回し、傷の浅いうちに修正していくという方法でした。そのため、メンターさんのご厚意に甘え、少しでもコードが書けたらペアプロをお願いしていました。6月末からほぼ週1ペースでペアプロしてもらったので、少なくとも5〜6回はしてもらったと思います。
プロのエンジニアの問題解決の姿勢を学べたので、本当にペアプロしてもらってよかったと思っています。1行ずつコードやドキュメントを読み、HTTPリクエストの中身を確認し、適宜byebugやdebuggerを使ってデバッグし、変数の名前ひとつ取っても磨き抜かれた最適な言葉を選ぶ、みたいな基本の作業を何度も根気強く教えていただき、教えていただいたことはひとりでコードを書くときも気をつけるようにしているので、まあ当社比ではあるものの少しはすごいエンジニアの定石・哲学・思想に近づけたんじゃないかな〜と思っています。
進捗YouTube
後半になるにつれあまりアップロードしなくなってしまったのですが、YouTubeでの進捗報告も続けていました。 珍しい試みだったので、メンターさんや受講生の方がたまに見て感想をくれるのがとても嬉しかったです。
少しずつアプリが作られていく様子に興味がある方は、↓の再生リストからぜひ動画を見てみてください〜！音が小さいらしいので大きめにしてもらえるといいかもです。
ポイント付け会
同じ時期に自作サービスに取り組んでいたFBC受講生4人で、週1回各々のGitHubのかんばんを使って今週取り組むIssueについて説明し、自分以外の3人にポイントをつけてもらうという会を行っていました。
これは以下の点でとてもよい取り組みだったと自負しています。
- 情報交換の場になる
- 自分のIssueについて他人に説明するため、やるべきことがよりクリアになる
- 励まし合える
- 他の人のよいやり方を学ぶことができる
自作サービスのプラクティスではどうしても孤独に陥りやすいという話をFBCを卒業した先輩方から聞いていましたが、私はこの会があったためか、孤独を感じることはほとんどなかったです。
「何もわからないし何もやりたくない」みたいなただの愚痴を聞いてもらったり、同じ技術を使った経験のある方からアドバイスをいただけるような面でありがたかったのはもちろん、自分の無知に直面し自信を失っていたとき、(すでに乗り越えた課題について)自分の経験をシェアしたことで他の方の役に立つことができ自信を取り戻すことができたのが何よりも心の支えとなりました。
『アジャイルサムライ』輪読会
開発を始めた途中で開催された輪読会に参加していたのですが、自分がちょうど個人開発を行っているタイミングで読んだため、机上の空論としてではなくより具体的な「今日から使えるTips集」として読むことができたと感じています。
私のサービスは開発当初想定していたよりも1ヶ月完成が伸びてしまい、最初の締切を過ぎた時点でもやるべきことが山のようにあり、途方にくれていました。
このままどんどん後ろ倒しになって、いつまでも卒業できないのかもしれないと絶望していたのですが、ちょうど輪読会で8章(「アジャイルな計画づくり: 現実と向きあう」)を読み、計画が予定通りにいかないのは当たり前で、ままならない現実のなかでいかにやるべきことを成すかがアジャイル開発だと学びました。
そうじゃなくて、抱えている悩みが、とにかく早く成果をあげることなんだとしたら、今のプロジェクト計画を捨てよう。そして新しい計画を、信じることのできる計画を立て直すんだ。あたかもゼロからアジャイルな計画を立てるかのように進めよう。マスターストーリーリストを作って、リストの規模を見極め、そこに載せているフィーチャに優先順位をつける。そうしたら、最小限の機能でいいから、とにかくお客さんのところへフィーチャを届けよう。全体から見れば一部であってもいい。とにかく仕事を完了させるんだ。
Jonathan Rasmusson『アジャイルサムライ――達人開発者への道』西村直人・角谷信太郎 監訳／近藤修平・角掛拓未 訳、オーム社、2011年、170頁
↑を読んで、自作アプリの完成に必要なのは能力や予算ではなくて「締切」そのものだったのか、締切をいつまでも伸ばしていいものだと心のどこかで思ってるから優先順位もつけられないし完成しないんだ…！と目から鱗が落ちた気持ちになりました。
それからは再設定した締切は動かせないものとみなして、タスクの優先順位を見直したり、不安のある分野は積極的に質問するように意識を変えたことで、締切までにサービスをレビュー依頼できる状態まで作り込むことができました。
このように週1回のこの輪読会は、自分の行っている開発プロセスや開発者としての姿勢を、本の文章や輪読会での会話を通じて反省し、改善していくためのまたとない機会だったなと思います。
本に書いてあることの一部については「こんなこと自分が出来るようになるとは思えない」という気持ちになることもありましたが、頻繁なペアプロでフィードバックループを素早く回す、他人にIssueのポイントをつけてもらうみたいなアイディアは、この本を通じて得た知見を自分の開発に取り入れる過程で生まれたものだと思っています。
余談: Discord Botを作った経験
自分が使いたいからという理由で1年前にDiscord Botを作ってリリースした経験には、作った当時には予想もできなかった形で勇気づけられたなと思います。
Railsアプリを0から作るのは今回が初めてだったので、取り組み始めた時点で全体像は想像できなかったし、作る中でも自分の知識・能力に大いに疑問が湧きましたが、「でも1年前はあんなに何も分かってなかったのに、いろんな人の助けを借りながらDiscord APIやdiscordrbのドキュメントを読んでデプロイまでできたんだから何とかなる」と思えたので完成まで至れたのだと思っています。
だから今回作ったShadoneも、ごく小さなサービスではありますが、これから先困難な問題を前にして暗中模索状態になったとしても、「あのときもなんとか作れたんだから大丈夫」と思える北極星のような存在になるんじゃないかなと期待しています。
さいごに
こうやって振り返ってみると、自作サービスのプラクティスは、チーム開発のときに初めて触れたアジャイル開発の手法を学び直し、自分なりの解釈で実践してみた期間だったという印象が強いです。 コードを書いて動くものを作ることはもちろん面白かったのですが、それ以上に自分で自分のモチベーションや生産性を上げるための具体的な工夫をすることがとても楽しく、やりがいを感じました。
FBCで2年近く学習する中で、ずーーっと「私はエンジニアに向いているんだろうか？」という疑問を持ち続けてきたのですが、チーム開発を終えても自作サービスを作り終えても、自分がエンジニアに向いてるのかはぜ〜んぜん分かりませんでした笑。
むしろ自作サービスを作る中で、自分が何も分かっていなかったということを思い知ったり、すごいエンジニアの人の考え方を目の当たりにし、自分が向いてない理由は100個くらい思いつくようになってしまいました。Web開発は楽しいけど厳しい世界だ！
でも仮に私がエンジニアに向いてないというのが客観的事実だとしたら、そんな人でも0からWebアプリを作り切れるような開発の方法論があるということはすごいことだと思います。
なので例え私がエンジニアにならなくても、どんな職種でどんな働き方をしても、アジャイル開発手法を含めエンジニアリングについて学んだことは無駄にならないと思っています。 むしろ就活を含む、この先の人生の問題解決の場で最善の選択をするための道具を手に入れることができたので、これから先どうなるか全然分からないしめちゃくちゃ怖いけど、持ち前の蛮勇で自分にとってより良いと思える道を進んでいこうと思っています！
最後に、コードレビューを担当してくださり日報や質問タイムでたくさん疑問に答えてくださった駒形さん、アイディア出しの時点からたくさん励ましてくださりデザインについては何時間もペアプロしてくださった町田さん、根気強く毎週のペアプロに付き合ってくださった梅本さん、なぜか私の作ったTシャツを買ってくださった赤塚さん、ポイント付け会でお世話になったParuさん、ガラムマサラさん、Sakiさん、『アジャイルサムライ』輪読会を主催してくださったいっしーさん、サービス名を考えてくださったudaさん、その他長い間私や私のサービス開発に関わってくれたフィヨルドブートキャンプの皆さんに感謝です！
ShadoneTシャツ良かったら買ってねッ
