ウェブサービスを作る時に気をつけた方が良いこと

これまでいくつかウェブサービスを作って公開しましたが、運用をしてみてこれはヤバいと発覚した事などをまとめてみようと思いました。ひとまず思いついたことを書いておこうと思うので、何か追加すべきことがあれば追記していきます。

ユーザ

ユーザIDの予約語問題

twitterのようにユーザページを https://twitter.com/ユーザID/ と言う形式にする場合以下のようなアドレスを取られると困るわけです。

• https://twitter.com/admin/
• https://twitter.com/settings/
• https://twitter.com/users/
• https://twitter.com/common/
• https://twitter.com/assets/

管理画面のアドレスや追加機能で使いたいURLと被ってしまったりして…。 Railsの場合はActiveStorageが使うURLがあったりするわけですが、ライブラリやフレームワークが利用しそうなURLや自分で新しい機能を実装する時に使いそうなURLを予め取得できないようにバリデーションチェックしましょう。使えないようにした方が良いリストも後日作って公開してみようと思います。

他の方法としては http://twitter.com/members/ユーザID/ と言ったアドレスにする事も有効かもしれませんが、その場合も使えるユーザIDには注意した方が良いのは変わらないです。

ユーザIDの大文字小文字の判断

ユーザIDの大文字小文字を別と判断してしまっていると結構わかりにくい設計になってしまいそうです。できれば大文字小文字は別のものと判断せず同じものであると判断した方が良いと思います

ユーザIDに連番のダミーIDをつけない方が良い

ユーザがまだIDをしっかり作っていない時に連番のIDを勝手につけてくれるようにしたことがあります。例えばuser_idが 10だった場合 profile10 などとつけたのです。あるユーザが profile11 と言うIDに自分で変更してしまい次に登録した profile11 で登録されようとしたユーザは被ってしまいエラーになってしまいました。twitterなどのようにランダムな文字列にするか被ったら次の番号を利用するなどの工夫が必要です。

ユーザの退会ができるようにした方が良い

作った時はユーザは使わなくなったらアカウントを放置するかと思っていたのですが思っていた意外に退会したいと言う声は多いようです。1週間に1-2回は来るのでユーザが自分で退会できるようにするか管理画面から1ボタンで退会できるようにしておいた方が運営が楽そうです。

DBを直接いじって退会させるのも手間なので素直に退会させるフローを用意しましょう。

お問い合わせフォームはあった方が良い

メールフォームを用意した方が良いと思います。twitterからなどでも良いですが致命的な問題をリプライでやりとりするのはよくないと思いますので詳しく説明も報告してもらうためにメールフォームは用意した方が良いかもしれません。

投稿

非公開機能はあった方が良い

ユーザが予期せぬNGワードが入った投稿などをするかもしれません。広告を掲載していたりするとアウトになる可能性があるので隠したいですが、勝手に完全削除してしまうわけにもいかない場合は非表示にできるようにしておいた方が管理画面から投稿を簡単に非公開にできるようにしましょう。

ユーザのアクション数はカウンターキャッシュすると良い

カウンターキャッシュもどこまで設定すれば良いか正直なんとも言えないですが、アクティブなユーザを把握する場合や何かアクションしてくれているユーザのみに新しい機能を表示するなどしたい場合はカウンターキャッシュされている数字を元に表示を変えるとDBへの負担が少なくできるので使う可能性があるカウンターキャッシュは設定しておいた方が良さそうです。

例えば、お気に入り数、投稿数、タグがつけられている数などですね。

最後に

サービスを運営していると設計する時に盛り込んでおくべきことは結構あるのでノウハウとして共有できればと思っています。今後もこちらの投稿を更新していこうと思います。