交流要素があるアプリの開発において欠かせない機能の代表格、「いいね！」ボタン。シンプルな機能に見えますが、クライアント側・サーバー側の状態管理など、作り始めると案外奥深いことに気付かされます。
特に設計段階において「Twitterみたいないいね機能がいいな！」みたいな安易な絵を描くことは危険です。大手サービスのいいね機能は非常にリッチであり、そのすべてを実現するには相応の手間がかかります。あなたがいいねを搭載するアプリの全体像から重要性を鑑みたうえで、ボタンが持つ機能をブレークダウンしてどこまで実装するのか？をきちんと考えることが肝心と言えます。
本記事では、「いいね！」ボタンをこれから作る人に向けて設計に関する助けになるよう共有します。
◇目次
作業前に「どのレベルまで実装するか」を見極める
TwitterやFacebookでなじみ深い「いいね！」ボタン。これらサービスでは「いいね！」機能こそがサービスの核心ということもあり、機能的には非常にリッチです。
— 大手サービスのいいね！ボタン単体が備える機能概要（基本→高度な機能、の順）
- いいねを押すといいね表示数が増える（バックエンド連動）
- 自身が過去にいいね！を押したデータが識別できる
- もう一度押すといいね表示数が減る（バックエンド連動）
- 誰がいいね！を押したか識別できる
- 誰かがいいね！を押すと関係するアカウントに通知される
- ユーザーが明示的にリロードしなくても、リアルタイムでいいね数が更新される
ボタン単体でざっと列挙するだけでもこれらの機能を備えています。もちろん全て実装するのがベターですが、上記リスト内で下にいくほど実装難易度が上がりソースコードも複雑化します。
「いいね！」機能の重要性もサービスによって様々です。どこまで必要だろう？と予算や工数を考慮して判断する必要があります。以下、個別項目について解説していきます。
いいね！ボタンを押すといいね表示数がふえる（バックエンド連動）
基礎的な機能ですが、スマホならWeb API連携、WebならJavascriptによるバックエンド連携（画面、データの非同期更新）が欠かせません。
サーバー側では、コメントテーブル上にある該当データのlike列にアップデートlike=like+1をかける程度の実装で実現できます。「誰がいついいねを押したか」の情報を保持しないのであれば、別にいいね履歴テーブルを準備するよりも実装としてはシンプルでしょう。
クライアント側においては、いいねが押されたタイミングで、いいね数初期値のいいね数から+1増やして更新します。宣言型UI（Flutterなど）であれば、このとき画面全体を読み込まずいいねボタンのみ再描写される形にするとベターです。
必要な実装：コメントデータテーブルに「いいね数」を持たせる。クライアント側の非同期更新（初期数から1増やす、2度押し禁止）
自身が過去にいいね！を押したデータが識別できる
バックエンド側で「誰がいいねを押したか」を履歴テーブルを作って保持しているのであれば、タイムラインロード時にフラグを立てるのが一番シンプルです。
他方、履歴テーブルを用意しないか、タイムラインを一定時間キャッシュして再描写する等の処理を検討する場合は、データベース以外の方法（セッションや端末ストレージなど）などクライアント側で情報を処理できる仕組みが必要です。
いずれの実装とするにせよ、過去のいいね履歴を全て保管すると、徐々に処理負荷が上昇することが予測されます。いいね履歴を、コメントIdの他にいいねした時間も保持して、一定時間経過したデータについては除去する仕組みを検討しましょう。
必要な実装：自分が過去に「どのコメントを」「いつ」いいねしたかを追える情報（クライアント側での保持、またはサーバー側での履歴テーブル）
もう一度押すといいね表示数が減る（バックエンド連動）
もう一度押した時にいいね数を減らします。この辺りから、状態管理が複雑化してきます。特にタイムラインをキャッシュしている場合などは、バックエンドとキチンと連動するよう注意が必要です。
いいね数を減らすには、前提としてユーザーが過去にどのコメントをいいねしたのかを保持しておく必要があります。個々のコメントに対するいいね状態が把握できていれば、押した時に増やす処理をするか、減らす処理をするか分岐することができます。
必要な実装：ボタンを押したときにいいね数を減算する仕組み（クライアント側でタイムラインをキャッシュする場合は、バックエンドとの連動が複雑化してくるため注意）
誰がいいねを押したか識別できる
ここまでの実装は、「誰が」の実装は必須ではありません。単純に、コメントデータテーブルにいいね数の列を持たせて、ボタン操作されるたびにその数値を更新していく実装でも実現可能でした。
他方、「誰が押したか」を記録してユーザーに提供するとなると、コメントデータテーブルとは別にいいね履歴テーブル（誰が・いつ・どのコメントをいいねしたかを保持）の設置が必須となります。いいね履歴はユーザー数が増加すると雪だるま式にデータ量が増えていき、タイムラインロード処理等の時間的ボトルネックになりかねません。
適切な列にインデックスを貼って検索効率を上げるのはもちろんのこと、定期的に古いデータを破棄する仕組みについても検討するべきでしょう。
必要な実装：いいね履歴テーブルの実装（データ量が大きくなりがちのため、ボトルネックにならないような工夫が必要）
誰かがいいねを押すと関係するアカウントに通知される
いいねを押したときにリアルタイムで通知する機能は、ウェブブラウザーまたはスマートフォンアプリでの実装を前提とします。
クライアント側で通知状況をサブスクライブする必要があるので、ここでまた実装難易度が上がります。また、自前でリッスン機能を実装するとサーバー側で受け取るリクエスト数が跳ね上がります。
これ以前のステップに比べると実装難易度も一段高く、ここまでの機能を備えるかどうかはアプリの要件定義の段階でよく考える必要があるでしょう。
ユーザーが明示的にリロードしなくても、リアルタイムでいいね数が更新される
上記、「誰かがいいねを押すと関係するアカウントに通知される」まで実装できれいれば、この実装についてはさほど難しくはないでしょう。
サブスクライブしているいいね情報をリッスンしたタイミングで画面を非同期更新すれば実現することが出来ます。
おまけ：キャッシュによる負荷軽減か、シンプル化か。
タイムラインをキャッシュする仕組みは、タイムラインロードをサーバーにリクエストする回数を削減できるため、データベース負荷低減効果が期待できます。
他方、いいね機能を搭載していると、キャッシュをロードした際にそれ以前のいいねボタン押下履歴を反映しないと違和感があり、状態管理処理が複雑化しがちです。
負荷軽減か、シンプルな実装か。これについてもアプリケーションの要件や機能の重要性を考慮する必要があると言えます。
記事筆者へのお問い合わせ、仕事のご依頼
当社では、IT活用をはじめ、業務効率化やM&A、管理会計など幅広い分野でコンサルティング事業・IT開発事業を行っております。
この記事をご覧になり、もし相談してみたい点などがあれば、ぜひ問い合わせフォームまでご連絡ください。
皆様のご投稿をお待ちしております。
