勤怠管理 KinTime 要件定義書
1. 目的・背景
勤怠管理システム「KinTime」は、従業員の出退勤記録、休暇申請、承認プロセスを効率化するために開発される。現状、多くの企業では紙ベースや古いシステムを用いた勤怠管理が行われており、これによりデータの不整合や承認プロセスの遅延が発生している。本アプリケーションは、これらの課題を解決し、業務効率を向上させることを目的としている。特に、SSO連携によるセキュアなログイン、リアルタイムな打刻機能、迅速な申請・承認フローを提供することで、従業員と管理者の負担を軽減し、正確な勤怠データの管理を実現する。
2. スコープ
2.1 対象範囲（In-Scope）
| # | 項目 | 概要 |
|---|---|---|
| 1 | ログイン機能 | SSOを利用したセキュアなログイン |
| 2 | 打刻機能 | 出退勤のリアルタイム記録 |
| 3 | 申請・承認機能 | 休暇や残業の申請と承認プロセス |
| 4 | レポート機能 | 勤怠データの集計と分析 |
2.2 対象外（Out-of-Scope）
| # | 対象外項目 | 理由 / 別フェーズで対応か |
|---|---|---|
| 1 | 給与計算機能 | 別システムで対応 |
| 2 | 外部勤怠データのインポート | 次フェーズで検討 |
| 3 | モバイルアプリ対応 | 将来的な拡張として検討 |
2.3 前提条件
- 前提 1: ユーザ数は中規模企業を想定し、MAU 1 万として算定
- 前提 2: SSO連携は既存のIDプロバイダを利用
- 前提 3: データベースはPostgreSQLを使用し、既存インフラに統合
3. 業務概要
3.1 利用者（アクター）
| アクター | 役割 | 想定人数 |
|---|---|---|
| 一般ユーザー | 勤怠の打刻、申請 | 5000 |
| 管理者 | 申請の承認、レポートの確認 | 500 |
3.2 業務量（推定）
| 項目 | 想定値 | 根拠 |
|---|---|---|
| 月間処理件数 | 100,000 件 | 中規模企業の平均勤怠処理数 |
| ピーク時間帯 | 9:00-10:00 | 出勤時の打刻集中 |
| データ保持期間 | 3 年 | 法令遵守のため |
3.3 業務フロー
4. 機能要件
4.1 画面機能
| 機能ID | 画面名 | 概要 | 主な操作 |
|---|---|---|---|
| F-S-001 | ログイン画面 | SSOによる認証 | ユーザーID入力 |
| F-S-002 | ダッシュボード | 勤怠状況の確認 | 勤怠データ表示 |
| F-S-003 | 打刻画面 | 出退勤の記録 | 打刻ボタン押下 |
| F-S-004 | 申請画面 | 休暇・残業の申請 | 申請フォーム入力 |
| F-S-005 | 承認画面 | 申請の承認・却下 | 承認ボタン押下 |
4.2 API 機能
| 機能ID | エンドポイント役割 | 概要 | 利用元 |
|---|---|---|---|
| F-A-001 | 認証API | ユーザー認証 | ログイン画面 |
| F-A-002 | 打刻API | 出退勤記録 | 打刻画面 |
| F-A-003 | 申請API | 申請データ送信 | 申請画面 |
| F-A-004 | 承認API | 承認結果送信 | 承認画面 |
| F-A-005 | レポートAPI | 勤怠データ取得 | ダッシュボード |
4.3 バッチ機能
| 機能ID | バッチ名 | 起動契機 | 概要 |
|---|---|---|---|
| F-B-001 | 日次集計バッチ | 毎日深夜 | 勤怠データの集計 |
| F-B-002 | 月次レポートバッチ | 月初 | 月次レポート生成 |
4.4 外部連携
| 機能ID | 連携先 | 概要 | 方式 |
|---|---|---|---|
| F-E-001 | SSOプロバイダ | ユーザー認証 | OAuth 2.0 |
| F-E-002 | 人事システム | 勤怠データ連携 | REST API |
4.5 画面遷移
5. 非機能要件
5.1 可用性
| 項目 | 要件 |
|---|---|
| SLA | 99.9% |
| RTO | 1 時間 |
| RPO | 15 分 |
| 稼働時間 | 24/7 |
5.2 性能・拡張性
| 項目 | 要件 |
|---|---|
| 同時接続数 | 1000 |
| 応答時間 (p95) | 200ms 以下 |
| スループット | 100 TPS |
5.3 運用・保守性
| 項目 | 要件 |
|---|---|
| 監視 | 24/7 監視体制 |
| バックアップ | 毎日 |
| ログ保管期間 | 90 日 |
5.4 移行性
| 項目 | 要件 |
|---|---|
| 移行戦略 | 段階的移行 |
| データ移行範囲 | 全勤怠データ |
5.5 セキュリティ
| 項目 | 要件 |
|---|---|
| 認証方式 | SSO |
| 認可 | ロールベース |
| データ保護 | 暗号化ストレージ |
| 通信暗号化 | TLS 1.2 以上 |
5.6 障害対応
| 項目 | 要件 |
|---|---|
| 重大障害の応答時間 | 30 分以内 |
| 復旧目標時間 | 2 時間以内 |
5.7 システム環境
| 項目 | 要件 |
|---|---|
| 対応ブラウザ | 最新のChrome, Firefox, Edge |
| 対応デバイス | PC, タブレット |
6. 移行・運用・教育要件
6.1 データ移行
| 項目 | 内容 |
|---|---|
| 移行範囲 | 全勤怠データ |
| 移行方式 | 段階的移行 |
| リハーサル | 2 回実施 |
6.2 切替方式
段階切替を採用し、旧システムとの並行運用を行う。
6.3 運用体制
| 項目 | 内容 |
|---|---|
| 運用時間 | 24/7 |
| 一次対応窓口 | IT サポートデスク |
| エスカレーション | 障害発生時に即時対応 |
| 障害レベル定義 | P1（停止）/P2（縮退）/P3（限定影響）等 |
6.4 教育・引継ぎ
| 項目 | 内容 |
|---|---|
| 対象者 | 全従業員 |
| 研修方式 | オンライン研修 |
| マニュアル提供範囲 | 全機能 |
7. 制約事項
7.1 技術制約
| 領域 | 採用技術 |
|---|---|
| フロントエンド | Next.js |
| バックエンド | Node.js |
| データベース | PostgreSQL |
7.2 その他の制約
- 制約 1: 既存のSSOプロバイダを利用すること
- 制約 2: データベースは既存のPostgreSQL環境を使用
8. 用語集
| 用語 | 定義 |
|---|---|
| SSO | シングルサインオン |
| TPS | トランザクション毎秒 |
9. 未決事項・課題管理
| # | 項目 | 内容 | 確認先 | 期限 |
|---|---|---|---|---|
| TBD-001 | 給与計算連携 | 給与システムとの連携要否 | 発注側 | yyyy-mm-dd |
| TBD-002 | モバイル対応 | モバイルアプリの必要性 | 発注側 | yyyy-mm-dd |
| TBD-003 | 外部API連携 | 他システムとのAPI連携範囲 | 発注側 | yyyy-mm-dd |
| TBD-004 | データ保持期間 | 法令に基づく保持期間の確認 | 発注側 | yyyy-mm-dd |
| TBD-005 | 監査ログ | 監査ログの詳細要件 | 発注側 | yyyy-mm-dd |
Generated by DocChain — 設計書連鎖生成 AI / 2026-05-05