申込とアカウント作成を同時に行う
典型パターン：申込フォームにパスワード欄
別タブで開く ↗
GET /events/:id/apply メールアドレス入力POST /events/:id/apply/send-link 認証リンク送信GET /events/:id/apply?token=xxx 申込フォーム（パスワード欄含む）POST /events/:id/apply 申込実行（アカウント作成 + 申込登録）GET /events/:id/apply/complete 完了画面
利用者の視点から
Section titled “利用者の視点から”- 設計上の矛盾を感じる - メールリンクで認証済みなのに、さらにパスワードを求められる。二重の手間に見える
- 目的と関係ない入力を求められる - イベントに申し込みたいだけなのに、パスワードを考えて設定しなければならない
- バリデーションで何度も止まる - 文字数不足、確認入力の不一致、強度不足など、エラーが起きやすい
- パスワード疲れが増す - 利用頻度が低いサービスなのに、また1つパスワードが増える
開発・運用の視点から
Section titled “開発・運用の視点から”- 関心事が混在している - 「申し込み」と「アカウント作成」が1つのフォームに混在し、責務が不明確
- バリデーションロジックが複雑になる - 申込項目のバリデーションとパスワードのバリデーションが混在する
- テストケースが増える - パスワードの各種バリデーションパターンがテスト対象に加わる
- パスワード忘れの問い合わせが増える - 利用頻度が低いとパスワードを忘れやすく、リセット対応が発生する
適用する原則: 登録はその場で行う、状態と操作を分離する
再設計パターン：パスワード不要で申込
別タブで開く ↗
GET /events/:id/apply メールアドレス入力POST /events/:id/apply/send-link 認証リンク送信GET /events/:id/apply?token=xxx 申込フォーム（トークン検証後）POST /events/:id/apply 申込実行GET /events/:id/apply/complete 完了画面
POST /account/set-password パスワード設定（任意・別導線）
設計のポイント
Section titled “設計のポイント”- 認証はメールリンク: 典型と同じ方式（ここまでは共通）
- パスワードを申込から分離: 認証済みなのにパスワードを求めない
- パスワードは任意:
password_hashが NULL でも利用可能 - 申込フォームがシンプルに: 本当に必要な項目だけ
| 観点 | 典型 | 再設計 |
|---|---|---|
| 認証方法 | メールリンク（共通） | メールリンク（共通） |
| フォーム項目 | 申込 + パスワード | 申込のみ |
| パスワード | 必須 | 任意（後から設定可） |
| バリデーションエラー | 起きやすい | 減る |
| 次回ログイン | パスワード入力 | メールリンク or パスワード |
| テストケース | 多い（パスワード検証含む） | 少ない（申込項目のみ） |
| 起きやすい不具合 | パスワード忘れ、強度エラー | 構造的に発生しない |
改修に向けて
Section titled “改修に向けて”再設計には主に1つの変更がある。
| 変更 | 内容 | 効果 |
|---|---|---|
| 1 | パスワード設定を申込フォームから分離 | フォームがシンプルになり、離脱が減る |
変更1: パスワード設定を分離する
Section titled “変更1: パスワード設定を分離する”- 申込フォームからパスワード欄を削除する
users.password_hashを NULL 許容にする- パスワード設定を別導線（マイページ等）に移動する
- 次回ログインはメールリンク認証をデフォルトにする
- 申込フォームの項目が減り、離脱率が下がる
- パスワード関連のバリデーションエラーが消える
- 「パスワード忘れ」の問い合わせが減る
懸念への対応
Section titled “懸念への対応”| 懸念 | 対応 |
|---|---|
| パスワードがないと不安 | パスワードは任意で後から設定可能と案内する |
| 次回ログインが面倒 | メールリンク認証は1クリックでログイン可能 |
| パスワードを求めるユーザーがいる | 完了画面やマイページで設定導線を用意する |
自社プロダクトの場合
Section titled “自社プロダクトの場合”- 影響を確認する: 既存ユーザーのパスワード設定状況を確認する
- 段階的に変える: 新規申込からパスワード欄を外し、既存ユーザーは従来通り
- 効果を測る: 申込完了率、問い合わせ数の変化を確認する
パスワードを完全に廃止するのではなく、「任意」にすることで段階的に進められる。
受託開発の場合
Section titled “受託開発の場合”- 懸念を先に聞く: 「パスワード認証についてどうお考えですか？」
- 選択肢を示す: パスワード必須/任意/なしの3パターンを提示する
- 推奨を添える: 「利用頻度が低いサービスでは、パスワードレスを推奨します」
セキュリティ要件や業界慣行を確認してから提案する。
パスワードレスの選択肢
Section titled “パスワードレスの選択肢”| 方式 | 特徴 |
|---|---|
| メールリンク | ログインリンクを送信 |
| SMS認証 | 認証コードを送信 |
| OAuth | Google等の既存アカウント |
| Passkey | 生体認証・デバイス認証 |
利用頻度が低いサービスほど、パスワードレスが有効。