名前のど忘れ対策メモアプリ「ど忘れノート」をリリースしました

ど忘れノート

dowasure-note.com

github.com

はじめに

フィヨルドブートキャンプ(以下FBC)で学習中のshucreamと申します。

このたび、名前のど忘れ対策メモアプリ「ど忘れノート」というサービスをリリースしました。 本記事ではサービスの説明や、開発中に苦労したこと、学んだことを書きたいと思います。

ど忘れノートとは

ど忘れしやすい名前を関連ワードと一緒に登録できる、ど忘れ対策メモアプリです。

名前を思い出せなくても、一緒に登録しておいた関連ワードを入力することで、インクリメンタルサーチによる素早い検索が可能になります。

使い方

使い方はとてもシンプルです。

名前の登録

名前登録画面

登録画面で名前を登録する際、キーワードタグ欄に名前に関連するワードを入力します。 一緒に名前に関するメモも登録することができます。

名前の検索

インクリメンタルサーチ

検索フォームに名前と一緒に登録したキーワードタグを入力すると、名前がインクリメンタルサーチで表示されます。 （名前であいまい検索も可能です。）

技術スタック

なぜこのサービスを作ったのか？

皆さんは友人と会話をしている時や、なにか調べ物をしたい時など名前が思い出せないことってありませんか？

私はアニメや漫画が好きなのですが、いろんな作品を見たりしていると登場人物の名前が思い出せず、「えっと、名前が出てこないけど、あのアニメの赤い髪のキャラ何だっけ？」というような、もどかしい経験が多々あります。 アニメ以外にも「久しぶりにあのアーティストの曲聴きたいけど、名前が思い出せない」と音楽アプリのアーティスト欄を上下に行ったり来たりして時間がかかることがあります。

この他にも、人によっていろんなケースで名前が思い出せなくて困るシーンがあるのではないかと考え、このような時、頭に思い浮かぶワードで名前をすぐに検索できたら便利だなと思い、今回のサービスを作ることにしました。

工夫したところ

検索数をカウントしてど忘れが多い順に表示する

サービスを開いた際、一覧はど忘れが多い順、つまり検索回数が多い順に表示するために、モデルに検索回数のカラムを持たせて検索するたびにカウントしていくようにしました。 よく検索する名前は、サービスを開いて検索せずとも目につくようにしたかったからです。

登録したてのものをすぐに見たい場合も考慮して、更新順に切り替えるソート機能も用意してあります。

一覧画面はできるだけシンプルに

ど忘れした名前を素早く確認できるようにするため、名前以外の情報をできるだけ減らし、一覧画面をシンプルに作るように意識しました。

編集、削除のリンクは通常時は隠しスワイプで表示、名前に関するメモは、隣にあるコメントアイコンをクリックするとモーダルで表示できます。

その他にも、ペーパープロトタイプの段階では、タグ一覧からタグを選択して名前を表示する機能を実装予定でしたが、タグがどんどん増えていくほど、一覧からお目当てのタグを探すのが困難になり使わなくなると判断して、あえて実装しませんでした。

このことで見た目がさらにスッキリし、用途もシンプルになったと思います。

苦労したこと

使用するライブラリの調査

今回のサービスのコア機能にはいくつか外部ライブラリを使用しています。

タグ付け機能 acts-as-taggable-on

タグ入力UI Tagify

スワイプ処理 Swiper

ライブラリを使用する際、日本語の技術ブログもいくつか参考になるものがありましたが、当然自作サービス独自の実装も必要になるため、公式ドキュメントや、ライブラリのコードを読んで思い通りに実装するのに時間がかかりました。 しかし、理解をした上でコードが動いたときは達成感があり、自作サービス作成以前よりドキュメントを読むことに対して自信がついていい経験になりました。

非同期処理を含んだテスト

自作サービスを開発するまでは、テスティングフレームワークはminitestにしか触れたことがなかったのですが、実際の現場ではRSpecが使われることが多いとお聞きしていたのでそちらを採用しました。 minitestとは違ったRspec独自の記法があり、最初は困惑しましたが、基礎を学びいくつかテストを書いていくうちにだんだんと慣れていくことができました。 そんな中でも非同期処理を含んだテストを書くのには時間を費やしました。 具体的にいうとRails7からデフォルトで搭載されている Hotwireの機能であるTurbo Framesを使った部分のテストです。

Turbo Framesとはすごく簡単にいうと、<turbo-frame>タグで囲ってある部分を非同期で置換してくれる機能です。 今回の自作サービスではインクメンタルサーチやソート機能などにTurbo Framesを使っています。 そして問題はTurbo Framesの処理が完了する前に次のコードの処理が行われてしまい、テストが通らないことでした。 sleepを使うことも考えましたが、sleepを多用するとテストの実行が遅くなってしまいます。今回のような小規模のサービスであればたいして問題にならないと思いつつも、今後実際の現場で開発することを考えて、できるだけ使用は避けたいと思っていました。 最終的には公式ハンドブックを読んで、turbo-frame[complete]という要素を発見次第、次のコードの処理に移るようにして解決できました。

Hotwire Turbo

やって良かったこと

サンプルアプリの作成

実際にサービスを作り始める前の技術検証にてサンプルアプリを作成し、使えそうなgemやnpmライブラリを試し、自分が考えていることが実際に実現できそうか不安をなるべく潰しました。 その結果、大きな手戻りもなく開発を進めることができました。

Hotwireの使用

苦労したところでも少し書きましたが、今回のサービスではHotwireを使用しています。自作サービスの開発に入る前までは、フロントエンドはFBCのプラクティスで学んだVueを使うことになるのかなとなんとなく考えていましたが、猫でもわかるHotwire入門 Turbo編を見て、Railsでapiを用意せず、そしてJavascriptもあまり書かずにSPA風の動きを実装できることを知り、今回のサービスの仕様であればHotwireで十分実装可能ということでこちらを採用しました。 もちろん初めて触れる技術だったので、TurboやStimulusの使い方に慣れるのにはある程度時間がかかりましたが、それでも開発コスト短縮に繋がったと思うので良かったです。 そして、今回の開発を通してHotwireの便利さを知れたので今後ももっと学んでみたいと思っています。

自作サービス進捗報告会参加

こちらは自発的にやったというわけではないのですが、とても開発の助けになりました。

FBCでは一週間に一度、担当のメンターさんと自作サービス開発に取り組んでいる受講生が集まって進捗を報告するミーティングが開かれます。 その場で実際にサービスの進捗を画面共有でデモしたり、うまくいってないことや、不安に思っていることを聞いてもらうことができます。 私の場合は、毎回のデモでデザインに関してアドバイスをもらい、ブラッシュアップできたことがとても良かったです。 最終的なチェックでもいくつか改良する点がありましたが、開発中にアドバイスをもらえたことで安心して開発を進めることができました。

他にも開発中は孤独な作業なため、ミーティングに参加することで、自分と同じく自作サービスの開発を頑張っている仲間がいることを確認できることが、大きな励みとなりました。

さいごに

開発中うまくいかないこともたくさんあり、不安になることもありましたが、なんとかサービスをリリースすることができました。 進捗報告会で相談にのってくださったkomagataさん、machidaさん、レビューをしてくださったメンターの皆さん、そして共に学習をしてきた受講生の皆さんのおかげです。

本当にありがとうございました！

そして、このサービスが少しでも誰かの生活の助けになれれば嬉しいです。