ユーザー管理機能の要件定義と見積
～設計・工数まで徹底解説～
目次
安達 奨（Susumu Adachi）
ITコンサルタント／Knowledge marketing合同会社 代表
IT業界で15年以上の経験を持ち、システム開発の上流工程から下流工程に至るまで幅広く精通。（企画、要件定義、設計、プログラミング、テスト）
現在ではシステム開発のみならず、ツール選定、ベンダー選定など、大手～中小企業向けのIT支援を多数手がける。
本サービスでは、特に事業会社時代から "システム開発会社の見積"
に疑問を感じており、これを是正すべきと考え監修を行っている。
はじめに
Webシステムや業務システムにおいて、ほぼ必須といえるのが「ユーザー管理機能」です。会員登録やログイン、権限管理などを含むこの機能は、見積もりや設計の際に軽視されがちですが、実は複数の工程や考慮点があり、見積の精度がプロジェクト全体の成功を左右することもあります。
本記事では、フロント画面が完成している前提で、ユーザー管理機能の見積に必要な要素を、以下の観点から解説していくものとします。
- ユーザー管理機能の一覧と概要
- 機能ごとの要件定義
- 大まかな設計方針
- 各機能ごとの工数見積
これは非常に良くある見積・設計手法の流れではあるものの、近年ではデザイン思考による要件定義に加え、サービスとして必要な観点（セキュリティなど）を足していくスタイルもあります。事業会社の社員やコンサルタント、自社プロダクトの開発などで要件定義をしてきた私としては、そちらの方が間違いなく正確に要件を伝えることが出来るため、最後に少し触れていきたいと思います。
1. ユーザー管理機能の一覧と概要
ユーザー管理とは、システム内でユーザーを一元管理するための機能群のことです。一般的な構成は以下の通りです。
| 機能名 | 概要 | ユーザー画面 | 管理画面 |
|---|---|---|---|
| ユーザー一覧表示 | 管理画面上で登録済みユーザーを一覧表示 | × | 〇 |
| ユーザー詳細表示 | 個別ユーザーのプロフィールや権限などを確認 | △（一部機能としては管理画面側で必要な部分と被る。主にマイページの機能） | 〇 |
| ユーザー登録 | 新規ユーザーを手動で登録 | 〇（ログイン画面の機能） | 〇（個別の登録に加え、CSVによる一括登録などの機能もあると良い） |
| ユーザー情報編集 | 名前・メールアドレス・所属などの情報を編集 | 〇（主にマイページの機能） | 〇 |
| パスワードリセット | ユーザー自身または管理者によるパスワード変更 | 〇（ログイン画面の機能） | △（ユーザー画面につけておけば不要なケースも多い） |
| 権限設定・変更 | 一般ユーザー／管理者などのロールを変更 | △（一般ユーザー以外にも、月額課金モデルでは課金額に応じた制御などもあり得ます。） | 〇 |
| アカウントロック／解除 | セキュリティ上の理由でログイン停止措置を行う | 〇 | △（アカウントロックを管理画面から強制することは少ないのですが、ブラックリストなどの作成を行う場合もあります。） |
| ユーザー削除（論理削除） | ユーザーを無効化し、データベース上には残す（ユーザー情報は、実績集計などの観点から完全な物理削除はあまり行わない。ただし、個人情報に相当する、名前、住所、電話番号などは適当な文字列に置換するケースも多い。） | △（退会時の操作で行う場合もある） | 〇 |
上記はアクター（登場人物）が、ユーザーと管理者の2人しかいないケースを想定して記載しています。
例えば、協力者を挟むようなサービス（弊社が運営しているコミュニティサイトであれば、コミュニティ加入者・コミュニティオーナー・管理者がいます）が必要になるため、特にユーザーの権限周りは複雑さを増します。
そういった場合には、セキュリティ上の観点からそもそもサーバーやDBを分離するなどの対策がインフラレイヤーに求められることもあるため注意をしましょう。
2. 機能ごとに詳細な要件定義を行う
それぞれの機能は、プログラムで書くためにより具体的な要件にする必要があります。主な例を以下に示します。
2-1. ユーザー一覧表示
<検索フォーム>
- 検索項目（名前・メールアドレス・ステータスなど）
- バリデーションチェック
- 未入力時は全件表示
<検索中>
- ローディング画面を表示
<検索結果>
- 表示項目（名前・メールアドレス・ステータスなど）
- ソート（登録日時順など）
- ページネーション
- 検索結果のCSV出力（オプション）
2-2. ユーザー詳細表示
- 基本情報（名前、メールアドレス、ステータス、登録日など）
- 詳細情報（サービスによって保存する内容は様々ですが、ECなどで言えば購入履歴や興味のあるもの、流入経路などもこれに含めてもいいでしょう）
- 権限、最終ログイン日時
- ログイン履歴（オプション）
2-3. ユーザー登録
- 入力チェック（必須項目、形式、重複など）
- 仮登録 → メール通知 → 本登録フローも選択肢（「管理者から追加する場合には仮登録のフローを取らない」などの要件も可能）
- 初期パスワード設定と通知（初期パスワードをユーザーに初めから入力させる形式などももちろんあります。）
2-4. ユーザー編集
- 編集可能範囲の制御（管理者／本人）
- バリデーションチェック
- 更新履歴の保持（ユーザー情報に限った話ではないのですが、DB上に変更前の情報も全て保存するような設計をした場合には必要。）
2-5. パスワードリセット
- 本人申請時：メール認証リンクを送付
- 管理者操作時：自動生成パスワード通知
- トークンの有効期限設定
2-6. 権限管理
- ロール制御（先ほどのコミュニティの例以外にも、例えばWordPressの様なブログサイトを自前で作る際には、管理者権限に対し「管理者・編集者・閲覧者」などのロールが必要になります。）
- 権限ごとの画面表示／操作制限
- ロール定義のDB管理
2-7. アカウントロック／解除
- ログイン失敗回数による自動ロック
- 管理者による手動ロック
- ログ記録との連携（監査ログ）
2-8. ユーザー削除
- 論理削除（フラグで無効化）
- 物理削除の抑制
- 関連データへの影響確認（例えば、ユーザー情報を削除した場合に、「過去購入した情報を全て削除してもよろしいでしょうか？」などのメッセージを出して消すタイプの機能）
3. 大まかな設計方針
3-1. バックエンド技術スタックの例
- 言語：PHP／Node.js／Ruby on Rails など
- フレームワーク：Laravel／Express／Rails
- DB構成：ユーザーテーブル＋ロールテーブル＋ログテーブル
3-2. エンティティ設計（例）
users
├─ id
├─ name
├─ email
├─ password_hash
├─ role_id
├─ is_active
├─ created_at
├─ updated_at
roles
roles
├─ id
├─ name (admin/editor/viewer)
├─ description
3-3. API設計（例）
| メソッド | エンドポイント | 概要 |
|---|---|---|
| GET | /api/users | ユーザー一覧取得 |
| GET | /api/users/{id} | 詳細取得 |
| POST | /api/users | 登録 |
| PUT | /api/users/{id} | 編集 |
| DELETE | /api/users/{id} | 論理削除 |
4. 工数見積の考え方
フロントは既に完成しているのを前提としたため、API実装＋バックエンド設計の工数見積は以下の通りです。
| 機能 | 工数（人日） | 備考 |
|---|---|---|
| ユーザー一覧 | 1.5日 | DB検索＋ページング |
| 詳細表示 | 1日 | シンプル |
| 登録 | 2日 | バリデーション・通知あり |
| 編集 | 1.5日 | 権限制御あり |
| パスワードリセット | 2日 | トークン管理あり |
| 権限変更 | 1日 | ロール管理が前提 |
| ロック／解除 | 1日 | ログ連携次第で増加 |
| 削除処理 | 0.5日 | 論理削除のみの場合。関連データを削除する必要がある場合には、関連データ分の試験も必要になることから注意。 |
| テスト・コードレビュー | 2日 | 一通りの検証を含む |
合計：約12〜13人日（1人で開発した場合、約2.5〜3週間）
5. コスト換算（相場ベース）
工数を元にしたコスト感は以下の通りです。
- フリーランス単価：6〜8万円／日
- 企業案件単価：8〜12万円／日
概算費用：72万円～156万円程度（フロント画面がある前提）
6. 注意点と見積時の落とし穴
- ユーザー管理は軽く見られがちだが、セキュリティ対応・通知設計・エラーハンドリングを丁寧に行う必要あり
- 権限・ロールが複雑化すると、設計全体に影響が及ぶため、要件定義の段階でのロール設計は重要
- APIのみの実装であっても、メール通知や監査ログの対応が必要な場合、工数が大きく変わる
まとめ
ユーザー管理機能は一見シンプルに見えても、実装・セキュリティ・拡張性の観点から工数・コストともに侮れない要素です。正確な見積を行うためには、以下の3点が重要です。
- 機能要件を明文化し、対象範囲を明確にすること
- ロール設計とセキュリティポリシーを早期に決定すること
- 実装＋テストまで含めた開発体制と予算の検討を行うこと