はじめに
この度、Rails7とHotwireを使用した自作サービス Subs.mine をリリースしました。
この記事ではサービスの説明、工夫したことや苦労したことについて書きたいと思います。
自己紹介
サービスの説明に入る前に簡単に自己紹介になります。
2022年4月からFjordBootCampのRailsプログラマコースで学習をしているまいむと申します。
Webサービスのプロダクトマネジメントを経て、自身でWebサービスの開発に取り組みたいという思いからエンジニアへのキャリアチェンジを目指しています。
Subsc.mineについて
Subsc.mineは複数のサブスクリプションサービスを契約している人向けの、利用サブスク一覧ツールです。
利用しているサブスクと更新日を一覧画面で確認することができ、自動でカレンダーアプリに更新日を連携することが可能です。
特徴
- 以下の項目を登録し、一覧画面で確認が可能です
- サービス名
- お支払基準日
- 次回お支払日
- 金額
- ステータス(継続中か停止中か)
- 周期
- お支払基準日から次回お支払日を 本日 を起点に自動で計算します
- iCalendar形式でカレンダーアプリと連携が可能です
- 一時的にサブスクの利用を止める場合、ステータスを「停止」に変更し、カレンダー連携から除外できます
- 停止から再開する場合、新しいお支払基準日を設定すると改めて次回お支払日を算出しカレンダーと連携できます
使い方
1. Googleアカウントでログインする
2. 新規登録画面から必要情報を入力して保存する
3. 一覧画面にデータが反映される
マイアカウントURLをクリックすると別タブで該当のリンクに飛ぶことができます。
4. カレンダーと連携する
カレンダー連携ボタンをクリックします。
連携の説明が表示されるため、「カレンダーと連携する」をクリックします。
連携用のURLが発行されるため「照会」をクリックします。
連携用の名前や更新間隔を設定して保存します。
Googleカレンダーと連携する場合は連携用のURLをコピーして、「他のカレンダー > + マーク > URLで追加」から連携が可能です。 ※Googleカレンダーとの連携はPCからのみ操作ができます。
このカレンダー連携操作は一度URLをカレンダーと連携するのみで、それ以降は新規データの登録をSubsc.mine上で行っていただくと自動で次回お支払日が連携されます。
なぜこのサービスを開発したのか
私は普段から複数のサブスクリプションを利用しています。
また、公共料金の毎月の支払いもクレジットカードに集約して管理をしています。
そうすると各支払いが次はいつなのかが管理できず、例えば一時的にサブスクをお休みしたかったり、解約やサービスプランの変更をしたい場合にお支払日がすぎてしまうということがよくありました。
また、クレジットカードを更新し、サブスクや公共料金の支払いに登録しているクレジットカードも全て変更が必要となった際に、変更が漏れてしまいサービスの更新が止まってしまったこともありました。
自らカレンダーにお支払日を登録すればいいのですが、忙しいと後回しにして結局登録せず、なんとなくそろそろお支払日だよな?と思い出し、マイアカウントにログインして確認をしていました。
この経験から自作サービスでは「次回お支払日」を自動でカレンダーと連携して、自分が利用中のサブスクリプションサービスを一覧管理できるサービスを作ろうと決めました。
技術スタック
- Ruby 3.1.2
- Ruby on Rails 7.0.4
- Hotwire
- PostgreSQL
- slim-rails
- TailwindCSS
- RSpec
- Github Actions
- Fly.io
- jsbundling-rails
- webpack
開発について
1ヶ月で実装するために1週間単位で開発スケジュールを引いた
自作サービスの開発にあたっては1ヶ月という期間を決めて、取り組みました。
なぜ期間を決めたのかというと実際の開発現場では納期があり、その中で最善のサービスを開発してリリースできるように取り組むためです。
自分の場合は、1週間単位で取り組むタスクをissueとしてカンバンに登録し、日単位でどこまでできたかを管理して調整をかけていきました。
1週間のゴールはその週に取り組んだ機能が動く状態になっていることです。
週末には1週間の振り返りを行い、順調か遅れているかを確認し、次週のスケジュールを調整していきました。
この取り組みは自分にとってモチベーション維持にもつながり非常に良かったです。
順調に実装ができたかというと、詰まってしまう場面も多々あり、issueの優先度を変更しながら最低限週末までにここまで動くようにするということを常に意識しながら開発に取り組みました。
結果的には1ヶ月以内で実装が完了し、テストもPassする状態にでき、レビュー依頼に出すことができました。
不安な部分は抱え込まず相談する
実装を進めていると、当初の想定ではうまくいかないのでは?という不安に襲われることや、技術的要素を詰め込まなければという思い込みから必要のない技術選定をして開発を進めようとしてしまう場面がありました。
FjordBootCampでは毎週水曜日に自作サービス進捗報告会があり、そこで作業状況の報告や質問が可能です。
しかし、参加人数や時間の関係から質問したかったことを聞かずに終わってしまうこともあり、進捗報告会とは別時間で開催されている質問・雑談タイムにも参加して、少しでも不安を感じた部分は相談をするようにしていました。
相談をすることで、不安や焦りを感じて冷静に考えられていなかった部分を整理でき、質問・雑談タイム終了後に改めてコードを書き始めるとちゃんと解決できることが何度もありました。
テストコードを書くことの大切さを実感した
私はプロダクトマネジメントで複数のサービス開発に関わってきましたが、自動テストではなくブラウザからの手動テストを実行してリリース前の合否判定を行なっていました。
FjordBootCampのチーム開発でも自動テストのコードは書いていましたが、自作サービスで0ベースでモデルやシステムテストを書いたことで、テストコードを書くことの大切さを改めて実感することができました。
テストコードがあることで
- ブラウザからの操作では見落としがちな小さなバグにも早めに気がつくことができる
- 他機能には影響がないと思っていた修正が、実は影響があり、テストが落ちることで気がつくことができる
- テストコードを書きながら、関連する機能のコードのリファクタリングができる
など、自分にとっては良いことづくめでした。
技術選定について
技術選定については、反省点が多々あります。 先にも書いた通り、技術的要素を詰め込まなければという思い込みから、実装着手前の技術選定が不十分な状態で開発に入ってしまい、途中でフレームワークを変更したり、実装方法の再検討が発生しました。
一例を挙げると、当初はVue.jsを使用してフロントの開発をしようと考えていました。
しかし、実装を進める中でどの部分をVue.jsで実装する予定だったかなどを整理し見直した結果、Railsで統一したほうが実装も管理もやりやすいと考えHotwireを使用することにしました。
途中までVue.jsで実装を進めていて、Hotwireでの実装に切り替えた際にファイル数もコード量も抑えて自分が実装したかった機能が開発でき、これは開発体験としては驚きでした。
サービス規模に応じて、どんなフレームワークを利用することが最適かをきちんと意識する必要があることを改めて考えさせられた経験でもあります。
実装で苦労したこと
HotwireとTailwindCSSの組み合わせ
RailsのviewはslimとTailwindCSSの組み合わせで行くことにしました。
slimはFjordBootCampのチーム開発である程度書けるようになっていて書きやすさを感じていたこと、CSSも自分である程度書けるため柔軟性があってモバイルファーストであるTailwindCSSを選びました。
単純にviewを実装するのみならば、この組み合わせで問題なかったのですが、Hotwireの導入で少し苦戦しました。
なぜかというと、Hotwireの参考記事やチュートリアルはerbとBootstrapで紹介されているものが多く、TailwindCSSで同じことを再現しようとする場合には自分で書かなければいけない部分が多いというためです。
モーダルの実装部分でスマホ画面の表示がうまくいかず苦戦しましたが、HotwireとTailwindCSSのドキュメント、参考になりそうな記事やコードを探して実装しました。
カレンダー連携
自作サービスとカレンダーを連携させるにあたって、iCalendar形式での連携を採用しました。
当初はAPI連携も考えていたのですが、自作サービス進捗報告会でiCalendarでの連携が可能か調べた方が良いと助言をいただき、APIを叩かずとも次回お支払日の連携が可能であることが確認できたため、採用しました。
が・・・実はここでの確認が甘かったことで、落ち込み事件が発生しました。
カレンダー連携機能の実装が完了し、連携テストをしていた際に自分以外のサブスクリプションのデータまでカレンダーに連携されているかなりまずい問題に気がつきました。
検証時は自分一人のデータで確認していたため気がつけず、一通り実装が終わって気がつくという猛反省案件です。
ここで動揺してしまい冷静に考えられていなかったこともあり、どうすればログインユーザーのみのデータをiCalendarで連携させるかが解決できず3日ほど不安な状態が続きました。
FjordBootCampの質問・雑談タイムで自分が考えたことやどこがうまくいっていないかなどを話して、その後改めてコードを見返しデバッグしながら実装を進めていき意図した連携用のURLを発行することができました。
この、できなかったことができた瞬間はとても嬉しい体験でした。
URLが発行できた後は、iCalendarのデータを取得するために使用しているwebcalのリクエストが認証で弾かれる問題に詰まりました。
認証はスキップしているはずなのになぜだろうと詰まりつつ、ここでも細かくデバッグをして意図したコントローラに処理が入っていないことに気が付き、解決できました。
自作サービスを通じて、かなりデバッグ力も鍛えられたと思います。
終わりに
自作サービスの開発では自分のスキル不足、検証の甘さなどに度々落ち込み開発完了できるのかなと不安になることがありました。
その不安を乗り越えることができたのは、駒形さん、町田さん、メンター陣の方々、受講生の励ましがあってこそでした。
本当にありがとうございます。
不安になることは何度もあったものの自作サービスを開発することでプログラミングの奥深さ、何を解決したいのかを見誤らないこと、限られた時間で最善を尽くすには何を選択すれば良いのかを常に考えることなどたくさんの気づきがあり、非常にやりがいを感じている自分を発見しました。
今回の経験で得た気づき、不安・焦り・喜び・驚きなどたくさんの感情はこの先もサービス開発に関わる上で忘れてはいけないことだと感じています。
自作サービスの開発はゴールではなく、ようやくスタートラインに立って次のステップに進むための切符を手にした状況と考えています。
ここで学んで得てきたことを大切に、この先も歩んでいけたらと思います。
改めてこの場を借りて、お礼をお伝えいたします。
ありがとうございました!!!!!