| 項目 | 内容 |
|---|---|
| プロジェクト名 | <記入> |
記入ガイド: 本書中で使用する固有名詞・略語・業界用語を定義する。読み手が前提知識なしで読めることを目標とする。
| 用語 | 定義 |
|---|---|
| SPA | Single Page Application。初回ロード後はクライアントサイドで画面遷移を行う Web アプリケーション方式。 |
| SLA | Service Level Agreement。提供するサービス品質の合意指標(稼働率、応答時間 等)。 |
記入ガイド: なぜ本システムが必要になったのかを記述する。現状の課題、ビジネス上の要求、外部環境の変化(法改正、技術革新、競合動向 等)を含める。
例: 当社では従来、経費精算を Excel テンプレートと紙の領収書による申請で運用してきた。リモートワークの定着により紙の物理回付が困難となり、申請者・承認者・経理部門のいずれも対応工数が増大している。加えて、電子帳簿保存法の改正により領収書の電子保存要件への対応が必要となった。これらの背景から、申請から承認・経理連携までを Web 上で完結できる経費精算システムの構築が求められている。
<記入>
記入ガイド: 達成したい目的を箇条書きで列挙する。各目的は計測可能であることが望ましい(KPI と紐付けると良い)。
(1) <例: 既存の手作業/Excel 管理を Web 上で完結させ、入力品質と業務効率を改善する>
<内容説明>
(2) <例: スマートフォン/PC 双方からアクセス可能とし、ユーザの利用機会を拡大する>
<内容説明>
(3) <例: 蓄積データを可視化し、意思決定を高速化する>
<内容説明>
記入ガイド: 本プロジェクト全体としての優先順位を、4項目(スコープ / 予算 / 時間 / 品質)で順位付けする。第2章 7.1 の機能ごとの優先度(MoSCoW)とは別に、PJ全体としてのトレードオフ判断の最上位指針となる。トレードオフが発生したときの判断基準にする。
| 順位 | 項目 | 補足 |
|---|---|---|
<例: 1> |
<例: 時間(期日)> |
<例: 法対応のため X 月 X 日リリース必達> |
<例: 2> |
<例: 品質> |
<例: 経費・会計データを扱うため正確性は譲れない> |
<例: 3> |
<例: スコープ> |
<例: Phase 1 の Must 要件は実装、Should 以下は調整可> |
<例: 4> |
<例: 予算> |
<例: 期日と品質を優先するため、必要に応じて予算追加可> |
記入ガイド: 本要件定義書には含めないが、本プロジェクトを進めるうえで別途必要となる管理文書を明示する。各文書の存在を要件定義書側で宣言しておくことで、抜け漏れと役割分担を防ぐ。
| 文書名 | 概要 | 策定責任者 | 策定タイミング |
|---|---|---|---|
<例: マスタースケジュール> |
<例: 要件定義〜本番リリース・初期稼働支援までを週単位で示す> |
<例: PM> |
<例: 要件定義承認後 1 週間以内> |
<例: ランニングコスト試算> |
<例: クラウド利用料・SaaS 利用料・運用保守費用の月額/年額試算> |
<例: 開発リード> |
<例: 基本設計完了時> |
<例: プロジェクト計画書> |
<例: 体制図・会議体・コミュニケーション計画・課題/リスク管理方針> |
<例: PM> |
<例: 要件定義承認後 2 週間以内> |
記入ガイド: 案件開始時点で確定している前提と、要件確定の足かせとなる制約、外部要因への依存関係を明示する。後工程で「要件」と「前提の思い込み」が混ざるのを防ぐ。
- 前提条件: 「〜が成立することを前提に要件を定めている」事項
- 制約: 技術・予算・期限・組織・法令などにより選択肢が制限される事項
- 依存関係: 他システム・他部署・他案件など、本案件外の動きに本要件の達成が依存する事項
| 分類 | 内容 | 影響範囲 |
|---|---|---|
| 前提条件 | <例: 全社員は既存 SSO(IdP X) で認証する> |
<例: 認証機能 / 情報セキュリティ要件> |
| 制約 | <例: 会計システム(社内既存)側の API は改修不可。連携は SFTP ファイルのみ> |
<例: 外部インタフェース / 性能要件> |
| 制約 | <例: 法対応期限のため YYYY-MM-DD のリリース必達> |
<例: スケジュール / スコープ> |
| 依存関係 | <例: 勘定科目マスタは情シス部から月次で提供される CSV を取り込む> |
<例: マスタ管理機能 / 運用> |
記入ガイド: 本システムが対象とする業務の全体像を文章で記述する。誰が(利用者)、どんな状況で、何を行うための業務かを 2〜4 段落程度で示す。
例: 本システムは、社内ユーザが日々発生する経費を申請し、承認者が内容を審査・承認する経費精算業務を対象とする。従来は Excel と紙の領収書を用いた申請を行っていたが、申請差戻しの往復・承認状況の不透明性・経理部門の集計工数が課題となっており、本システムにより申請から承認・経理連携までを Web 上で一気通貫で行えるようにする。
<記入>
記入ガイド: 業務プロセスを図示する。As-Is(現行)/To-Be(次期)を分けて示すと差分が明確になる。
<業務フロー図を挿入>
<業務フローの補足説明>
記入ガイド: 本システムを利用する役割(ロール)と、各ロールが行う主な操作・想定人数を列挙する。
例(経費精算): 申請者 / 承認者 / 経理担当者 / システム管理者
| ロール | 主な操作 | 想定人数 | 備考 |
|---|---|---|---|
<例: 申請者> |
<例: 経費の申請、申請履歴の参照> |
<例: 全社員 約500名> |
|
<例: 承認者> |
<例: 申請内容の審査・承認・差戻し> |
<例: 部門長 約30名> |
|
<例: 経理担当者> |
<例: 承認済み申請の経理連携、月次集計> |
<例: 経理部 約5名> |
|
<例: システム管理者> |
<例: マスタ管理、ユーザ管理、ログ監査> |
<例: 情シス部 約2名> |
記入ガイド: ロールごとに発生する主なデータと、その発生頻度(件数/期間)を列挙する。性能・スケーラビリティ設計の入力となる。
| データ | 発生主体 | 主な項目 | 発生頻度(定常時) | 発生頻度(ピーク時) |
|---|---|---|---|---|
<例: 経費申請> |
申請者 | 申請日、金額、領収書画像、勘定科目 | <例: 5,000件/月> |
<例: 8,000件/月(月末締め前後)> |
<例: 承認/差戻し> |
承認者 | 承認結果、コメント | <例: 5,000件/月> |
<例: 8,000件/月> |
<例: 経理連携> |
システム | 仕訳データ(CSV) | <例: 1回/日> |
- |
| ロール | 想定人数 | アクティブ率(月次) |
|---|---|---|
<例: 申請者> |
<例: 500> |
<例: 70%> |
<例: 承認者> |
<例: 30> |
<例: 100%> |
| 項目 | 定常時 | ピーク時 | ピーク特性 |
|---|---|---|---|
<例: 申請件数> |
<例: 5,000件/月> |
<例: 8,000件/月> |
<例: 月末締め前後> |
<例: 同時アクセスユーザ数> |
<例: 50> |
<例: 200> |
<例: 月末締め日 17-19時> |
記入ガイド: プロジェクトの成否や運用品質を測る指標を定義する。各指標は計算式と目標値、計測方法をセットで定める。
| 指標の種類 | 指標名 | 計算式 | 目標値 | 計測方法 |
|---|---|---|---|---|
| プロジェクト成果目標 | <例: 申請完了率> |
<例: 完了申請数 / 総申請数> |
<例: 95%以上> |
<例: 月次集計> |
| サービス品質目標 | <例: 月次稼働率> |
<例: (稼働時間 / 全時間) × 100> |
<例: 99.9%> |
<例: 監視ツールで計測> |
| 運用効率目標 | <例: 経理締め所要時間> |
<例: 月次締め開始から完了までの時間> |
<例: 従来比 50%削減> |
<例: 経理部実績ヒアリング> |
記入ガイド: 本システムで実現する機能(対象)と、本システムでは扱わない範囲(対象外)を明示する。スコープクリープ防止が目的。
記入ガイド: 優先度は MoSCoW (
Must/Should/Could/Won't) で評価する。Won'tは「今回はやらない」の明示で、対象外と区別する。リリース区分はPhase 1/Phase 2/後続検討等、案件のリリース計画に沿った値を記入する。
| カテゴリ | 機能/業務 | 概要 | 優先度 | リリース区分 |
|---|---|---|---|---|
<例: 申請> |
<例: 経費申請、領収書アップロード> |
<例: Must> |
<例: Phase 1> |
|
<例: 承認> |
<例: 多段承認、差戻し、コメント> |
<例: Must> |
<例: Phase 1> |
|
<例: 連携> |
<例: 会計システムへの仕訳データ出力> |
<例: Should> |
<例: Phase 2> |
|
<例: 分析> |
<例: 部門別経費集計ダッシュボード> |
<例: Could> |
<例: 後続検討> |
<例: 出張旅費の旅程管理機能(別システムで管理)、税務申告書の自動生成>
記入ガイド: 本システムで扱う主な情報と機密性区分を整理する。具体的なセキュリティ対策は第4章 10. に記述する。
| 主な情報 | 個人情報の有無 | 機密性区分 |
|---|---|---|
<例: 申請データ(金額、領収書、申請者氏名)> |
あり | <例: 中> |
<例: 承認履歴> |
あり | <例: 中> |
<例: 仕訳データ> |
なし | <例: 中> |
記入ガイド: 機能を機能分類ごとに整理する。機能IDは命名規則を定めて一意に付番する(例: F-001 〜)。
<機能構成図を挿入>
記入ガイド: 各機能には「ユースケース」(
<ロール>が<目的>を達成できる)を1行で必ず記述する。機能名・機能概要だけでは曖昧になる仕様を、利用者視点で固定するため。機能ID 命名規則: 機能数が少ないうちは
F-001形式の連番でよい。機能数が増えてきたら<モジュール識別子>-<連番>(例:UC-A-001ユースケース・申請系、UC-R-001ユースケース・参照系)のような階層的命名に切り替える。
| 機能ID | 機能分類 | 機能名 | 機能概要 | ユースケース | 利用者 | 関連画面ID | 対応する業務処理 | 備考 |
|---|---|---|---|---|---|---|---|---|
<例: F-001> |
<例: 申請> |
<例: 経費申請登録> |
<例: 金額・勘定科目・領収書画像を入力し申請する> |
<例: 申請者が経費精算の承認を得るために経費申請を登録できる> |
<例: 申請者> |
<例: S-002> |
<例: 申請業務> |
|
<例: F-002> |
<例: 申請> |
<例: 申請履歴参照> |
<例: 自分の過去申請を一覧表示・検索する> |
<例: 申請者が自分の過去申請の状況を確認できる> |
<例: 申請者> |
<例: S-003> |
<例: 申請業務> |
|
<例: F-003> |
<例: 承認> |
<例: 申請審査> |
<例: 申請内容を確認し、承認/差戻しする> |
<例: 承認者が部下の申請を審査して承認または差戻しできる> |
<例: 承認者> |
<例: S-004> |
<例: 承認業務> |
|
<例: F-004> |
<例: 連携> |
<例: 仕訳データ出力> |
<例: 承認済み申請を会計システム連携用 CSV で出力する> |
<例: 経理担当者が承認済み申請を会計システムへ連携できる> |
<例: 経理担当者> |
<例: S-005> |
<例: 経理連携> |
<例: 日次バッチ> |
<例: F-005> |
<例: マスタ管理> |
<例: 勘定科目マスタ管理> |
<例: 勘定科目の登録・更新・削除> |
<例: 管理者が勘定科目マスタを管理できる> |
<例: システム管理者> |
<例: S-006> |
<例: マスタ管理> |
|
<例: F-006> |
<例: ユーザ管理> |
<例: ユーザ管理> |
<例: ユーザの登録・更新・削除・ロール付与> |
<例: 管理者がユーザのアカウントとロールを管理できる> |
<例: システム管理者> |
<例: S-007> |
<例: ユーザ管理> |
記入ガイド: 機能一覧表の各機能(F-NNN)について、本節に1ブロックずつ詳細を記載する。実装・テストの基準となる粒度まで落とすことを目的とする。機能数が多い場合は別添(機能詳細仕様書.md 等)に分割してもよい。
各ブロックには以下の項目を含める:
- 目的・ユーザーストーリ
- 前提条件
- 入力項目と制約
- 主要シナリオ(正常系)
- 例外系・エラー処理
- 状態遷移(該当する場合)
- 通知
- 権限制御
- 受入条件(Given/When/Then)
| 項目 | 内容 |
|---|---|
| 目的・ユーザーストーリ | <例: 申請者として、経費精算の承認を得るために、領収書付きで経費申請を登録したい> |
| 前提条件 | <例: ログイン済み / 申請者ロールを持つ> |
| 状態遷移 | <例: 下書き → 申請中 → 承認済み / 差戻し> |
| 通知 | <例: 申請完了時、承認者へメール通知。差戻し時、申請者へメール通知> |
| 権限制御 | <例: 申請者ロールのみ作成可。自分の申請のみ更新・取消可> |
入力項目と制約:
| 項目名 | 型 | 必須 | 制約・バリデーション | 例 |
|---|---|---|---|---|
<例: 申請日> |
日付 | 必須 | <例: 過去30日以内> |
<例: 2026-04-13> |
<例: 金額> |
数値 | 必須 | <例: 1〜1,000,000、整数> |
<例: 12500> |
<例: 勘定科目> |
選択 | 必須 | <例: 勘定科目マスタから選択> |
<例: 旅費交通費> |
<例: 領収書画像> |
ファイル | 必須 | <例: JPEG/PNG/PDF、5MB 以下> |
- |
<例: 摘要> |
文字列 | 任意 | <例: 200文字以内> |
- |
主要シナリオ(正常系):
<例: 申請者は経費申請画面を開く><例: 必須項目を入力し、領収書画像をアップロードする><例: 「申請」ボタンを押下する><例: 確認ダイアログで「OK」を選択する><例: 申請完了画面が表示され、承認者へ通知メールが送信される>
例外系・エラー処理:
| 発生条件 | 画面挙動 |
|---|---|
<例: 必須項目未入力> |
<例: 該当項目を赤枠で強調、エラーメッセージを表示> |
<例: 領収書サイズ超過> |
<例: アップロード前にエラーダイアログを表示、送信させない> |
<例: 通信エラー> |
<例: 入力内容を保持したまま再送ボタンを表示> |
受入条件(Acceptance Criteria):
<例: Given 申請者がログイン済 / When 必須項目をすべて入力し申請ボタンを押下 / Then 申請が「申請中」状態で保存され、承認者へ通知メールが送信される><例: Given 金額が0以下 / When 申請ボタンを押下 / Then 「金額は1以上で入力してください」のエラーが表示され、申請は保存されない>
記入ガイド: 行にロール、列に機能(機能 ID)を取り、セルに操作可否とデータ範囲を記入する。「自分のデータのみ」「自部門のデータまで」など、データ範囲の曖昧さを残さない。
セル値の凡例:
C/R/U/D: 作成 / 参照 / 更新 / 削除R(自): 自分の作成データのみ参照可R(部): 自部門のデータまで参照可R(全): 全件参照可−: 操作不可
| ロール \ 機能 | F-001 経費申請登録 | F-002 申請履歴参照 | F-003 申請審査 | F-004 仕訳データ出力 | F-005 勘定科目マスタ管理 | F-006 ユーザ管理 |
|---|---|---|---|---|---|---|
| 申請者 | C / R(自) / U(自・申請中のみ) / D(自・申請中のみ) | R(自) | − | − | − | − |
| 承認者 | − | R(部) | R(部) / U(承認・差戻し) | − | − | − |
| 経理担当者 | − | R(全) | − | C / R(全) | − | − |
| システム管理者 | − | R(全) | − | − | C / R / U / D | C / R / U / D |
| 画面ID | 画面名 | 画面概要 | 利用者 | 関連機能ID |
|---|---|---|---|---|
<例: S-001> |
<例: ログイン画面> |
<例: メールアドレスとパスワードでログインする> |
<例: 全ロール> |
- |
<例: S-002> |
<例: 経費申請画面> |
<例: 申請内容を入力・領収書をアップロードする> |
<例: 申請者> |
<例: F-001> |
<例: S-003> |
<例: 申請履歴一覧画面> |
<例: 自分の過去申請をステータス別に一覧表示する> |
<例: 申請者> |
<例: F-002> |
<例: S-004> |
<例: 申請審査画面> |
<例: 自分宛の申請を一覧表示し、承認/差戻しを行う> |
<例: 承認者> |
<例: F-003> |
<例: S-005> |
<例: 経理連携画面> |
<例: 承認済み申請を抽出し仕訳 CSV を出力する> |
<例: 経理担当者> |
<例: F-004> |
<例: S-006> |
<例: マスタ管理画面> |
<例: 勘定科目等のマスタを管理する> |
<例: システム管理者> |
<例: F-005> |
<例: S-007> |
<例: ユーザ管理画面> |
<例: ユーザの登録・更新・削除・ロール付与を行う> |
<例: システム管理者> |
<例: F-006> |
<画面遷移図を挿入>
| 帳票ID | 帳票名 | 帳票概要 | 出力形式 | 出力タイミング |
|---|---|---|---|---|
<例: R-001> |
<例: 経費申請書(本人控え)> |
<例: 申請内容と承認状況を1枚にまとめた控え> |
<例: PDF> |
<例: 申請確定時にダウンロード可> |
<例: R-002> |
<例: 月次経費集計レポート> |
<例: 部門別・勘定科目別の経費集計> |
<例: Excel> |
<例: 月次締め後に経理担当が出力> |
記入ガイド: 用紙サイズ、文字フォント、見出しの付与、項目の揃え方、日付表記(西暦/和暦)等の共通ルールを定義する。
<例: 用紙は JIS A4><例: 日付は西暦表記で統一><例: 数値は右揃え、文字列は左揃え>
<データモデル(ER 図)を挿入>
| データID | データ名 | 概要 | 主要項目 | データ区分(マスタ/トランザクション) |
|---|---|---|---|---|
<例: D-001> |
<例: ユーザ> |
<例: 利用者アカウント情報> |
<例: id, email, name, role, department_id> |
マスタ |
<例: D-002> |
<例: 経費申請> |
<例: 申請者が登録した経費申請> |
<例: id, applicant_id, applied_at, amount, account_code, status> |
トランザクション |
<例: D-003> |
<例: 勘定科目> |
<例: 申請で選択可能な勘定科目> |
<例: code, name, is_active> |
マスタ |
記入ガイド: データ件数が多い場合は別ファイル化を検討する。
| データID | 項目名 | 型 | 桁 | NULL 可否 | 主キー | 説明 |
|---|---|---|---|---|---|---|
<例: D-002> |
<例: id> |
<例: UUID> |
36 | 不可 | ○ | <例: 申請の一意識別子> |
<例: D-002> |
<例: applicant_id> |
<例: UUID> |
36 | 不可 | - | <例: 申請者(ユーザ)の外部キー> |
<例: D-002> |
<例: amount> |
<例: integer> |
10 | 不可 | - | <例: 申請金額(円)> |
<例: D-002> |
<例: status> |
<例: enum> |
- | 不可 | - | <例: 業務状態とコード値は1対1対応(下書き=draft / 申請中=applied / 承認済み=approved / 差戻し=returned)。「却下」を別概念とする運用なら rejected を別値として追加可。コード値の正は C-001 を参照> |
| コードID | コード名 | 概要 | 値の例 |
|---|---|---|---|
<例: C-001> |
<例: 申請ステータス> |
<例: 経費申請の状態を表す。業務状態と1対1対応(下書き=draft / 申請中=applied / 承認済み=approved / 差戻し=returned)> |
<例: draft/applied/approved/returned> |
<例: C-002> |
<例: ユーザロール> |
<例: 利用者の権限種別> |
<例: applicant/approver/accountant/admin> |
| 機能ID \ データID | D-001 ユーザ | D-002 経費申請 | D-003 勘定科目 |
|---|---|---|---|
<例: F-001 経費申請登録> |
R(自) | C(自) | R |
<例: F-003 申請審査> |
R(部) | R(部) / U(承認・差戻し) | R |
<例: F-004 仕訳データ出力> |
R | R | R |
<例: F-005 勘定科目マスタ管理> |
− | − | C / R / U / D |
<例: F-006 ユーザ管理> |
C / R / U / D | − | − |
| データID | データ名 | 概要 | 利用者 | 公開範囲 | 利用目的 | 公開形式 |
|---|---|---|---|---|---|---|
<例: 該当なし(社内システムのため公開データなし)> |
記入ガイド: 連携先システム、連携方向、連携データ、連携方式、連携頻度を列挙する。
| IF-ID | 連携先システム | 連携方向 | 連携データ | 連携方式(API/ファイル/DB等) | 連携頻度 | 認証方式 |
|---|---|---|---|---|---|---|
<例: IF-001> |
<例: 会計システム> |
出 | <例: 仕訳データ(CSV)> |
<例: SFTP ファイル連携> |
<例: 日次> |
<例: SSH 鍵> |
<例: IF-002> |
<例: SSO IdP> |
双方向 | <例: 認証トークン> |
<例: REST API> |
<例: ログイン都度> |
<例: OAuth 2.0> |
記入ガイド: 各 IF について、以下のテンプレを 1 IF = 1 ブロックで記入する。連携仕様の合意文書として運用するため、項目の必須/任意・型・エラー時挙動・冪等性まで明示する。詳細仕様が大きい場合は別添(IF 仕様書.md 等)に逃がしてもよい。
「送信項目」「応答・結果通知項目」は、同期 R/R(REST/SOAP 等)の場合はそれぞれリクエスト/レスポンスを記入する。SFTP 等の一方向ファイル連携やイベント駆動連携の場合は、応答が無い・後続で結果通知ファイルが返る・ACK のみ等のパターンを 1 行で明記する(例: 「応答なし」「結果通知: ファイル名 result_yyyymmdd.csv」「ACK のみ(処理結果は別途参照)」)。
| 項目 | 内容 |
|---|---|
| IF-ID / 連携先名 | <例: IF-001 / 会計システム X> |
| エンドポイント | <例: sftp://accounting.example.com/incoming/> |
| プロトコル / メソッド | <例: SFTP / PUT> |
| 認証方式 | <例: SSH 公開鍵認証> |
| タイムアウト | <例: 60秒> |
| リトライ方針 | <例: 失敗時 3回まで指数バックオフ(初回30秒、最大5分)、その後アラート通知> |
| 冪等性 | <例: ファイル名にユニーク ID(yyyymmdd-NNN)を含め、二重投入時は受信側で重複検知> |
| バージョン管理方針 | <例: ファイルレイアウト変更時は新バージョン番号をファイル名に含める。3ヶ月の並行稼働期間を設ける> |
| 責任分界 | <例: 当方は SFTP 投入完了まで。受信側のファイル取込以降は会計システム X 側> |
送信項目(送信ファイルレイアウト):
| 項目名 | 型 | 必須 | 制約 | 例 |
|---|---|---|---|---|
<例: 仕訳日付> |
日付 (YYYY-MM-DD) | 必須 | <例: 当月のみ> |
<例: 2026-04-30> |
<例: 借方勘定> |
文字列 | 必須 | <例: 勘定科目コード5桁> |
<例: 51001> |
<例: 金額> |
数値 | 必須 | <例: 1〜99,999,999> |
<例: 12500> |
応答・結果通知項目(同期応答 / 後続通知ファイル / ACK 等を区別して記入):
| 項目名 | 型 | 必須 | 制約 | 例 |
|---|---|---|---|---|
<例: 取込件数> |
数値 | 必須 | - | <例: 245> |
<例: エラー件数> |
数値 | 必須 | - | <例: 0> |
<例: エラー詳細> |
文字列 | 任意 | エラー時のみ | - |
エラーコード一覧:
| コード | 意味 | クライアント側挙動 |
|---|---|---|
<例: E001> |
<例: 認証失敗> |
<例: 即時アラート、リトライしない> |
<例: E002> |
<例: フォーマットエラー> |
<例: 当日分を保留、運用担当へ通知> |
<例: E003> |
<例: 一時的な接続不可> |
<例: リトライ方針に従う> |
記入ガイド: 各節とも、該当しない場合は「該当なし」と明記する。 参考: 独立行政法人情報処理推進機構(IPA)「非機能要求グレード」に整理を寄せると、抜け漏れを防ぎやすい。
| 利用者種類 | 役割 | 特性(IT リテラシー、利用デバイス、業務知識 等) |
|---|---|---|
<例: 申請者(全社員)> |
<例: 経費申請> |
<例: IT リテラシーは幅広い。PC・スマートフォン双方からの利用想定。業務知識は浅い場合あり> |
<例: 承認者(部門長)> |
<例: 申請の審査・承認> |
<例: PC 中心。承認業務は隙間時間に行われる傾向> |
<例: 経理担当者> |
<例: 経理処理・集計> |
<例: PC 中心。会計ルールに精通> |
<例: システム管理者> |
<例: マスタ管理・ユーザ管理> |
<例: IT リテラシー高い> |
| 要件分類 | 要件 |
|---|---|
| 画面構成 | <例: 統一感があり直感的に操作できる構成とする> |
| 操作方法 | <例: 最小限の操作で完了するよう、ショートカット等を提供する> |
| 指示・状態の表示 | <例: 必須/任意項目を視覚的に区別する> |
| エラー処理 | <例: エラー発生時は原因と対処方法を明示する> |
| ヘルプ | <例: マニュアル・FAQ を画面から参照可能とする> |
記入ガイド: 公的システムであれば JIS X 8341-3 適合レベル AA 等を参照する。社内システムの場合は適用範囲を明確にする。
<例: 文字サイズが変更可能であること><例: 色のみで情報伝達を行わないこと><例: 主要なブラウザ(Chrome / Edge / Safari)の最新版で動作すること>
| 分類 | 方針 |
|---|---|
| アーキテクチャ | <例: Web 三層アーキテクチャ / マイクロサービス / モノリス> |
| 開発方式 | <例: ノーコード/ローコード活用、フルスクラッチ> |
| アプリケーション設計 | <例: コンポーネント疎結合、再利用性確保> |
| 文字コード | <例: UTF-8、JIS X 0213 準拠> |
| データの記述形式 | <例: 日付は ISO 8601、API リクエスト/レスポンスは JSON、文字コードは UTF-8> |
| ソフトウェア製品方針 | <例: OSS 優先、ベンダロックイン回避> |
| インフラ方針 | <例: クラウド・バイ・デフォルト> |
<システム構成図を挿入>
| 項目 | 内容 |
|---|---|
| 開発手法 | <例: ウォーターフォール / アジャイル / 併用> |
| 開発言語 | <例: TypeScript(フロントエンド)、Node.js / Go(バックエンド)> |
| 主要フレームワーク | <例: Next.js、NestJS、Prisma> |
| 開発環境(本番/検証/開発) | <例: production / staging / development の3環境> |
| 機器区分 | 用途 | 機器数 | 設置場所 | 補足 |
|---|---|---|---|---|
<例: 該当なし(全構成をクラウド上に構築するため、専用機器なし)> |
| データ区分 | 初期データ量 | 増加見込み | 最大蓄積量(想定) | 保存期間 |
|---|---|---|---|---|
<例: 経費申請(DB)> |
<例: 0> |
<例: 60,000件/年> |
<例: 600,000件(10年保存)> |
<例: 10年> |
<例: 領収書画像(オブジェクトストレージ)> |
<例: 0> |
<例: 60GB/年> |
<例: 600GB> |
<例: 10年> |
<例: ログ> |
<例: 0> |
<例: 1GB/月> |
<例: 36GB> |
<例: 3年(直近1年はホット、それ以前はコールド保管)> |
第2章 5. 規模を参照、または該当箇所を本節に再掲する。
| 設定対象 | 指標 | 目標値(定常時) | 目標値(ピーク時) | 達成基準(平均/95%ile 等) |
|---|---|---|---|---|
| 画面遷移 | レスポンスタイム | <例: 1秒以内> |
<例: 3秒以内> |
平均 |
| 検索処理 | レスポンスタイム | |||
| データ更新 | レスポンスタイム | |||
| ファイルアップロード/ダウンロード | レスポンスタイム | |||
| バッチ処理 | 処理完了時間 | <例: 翌営業日開始までに完了> |
| 処理 | 目標スループット | 補足 |
|---|---|---|
<件/秒> |
| 設定対象 | 指標 | 目標値 | 補足 |
|---|---|---|---|
| サービス時間 | <例: 24時間365日> |
計画停止/定期保守を除く | |
| 計画停止予定通知 | <例: 5日前までに通知> |
||
| 稼働率 | <例: 99.8%> |
月間ベース | |
| ディザスタリカバリ | 有 / 無 |
<例: データの消失・破損を防止する><例: 異常入力を検出してデータ滅失/改変を防止する><例: 処理結果の検証用にログ等の証跡を保持する>
<例: 利用者数・データ量増加に対し、負荷分散・スケールアウトで対応可能とする>
<例: 機能・データ項目の追加が、最小コストで可能な構成とする><例: 系統だった命名ポリシーを定め、ID/項目名の重複を防ぐ>
<例: OS・ブラウザの将来バージョンアップに対応可能な実装とする><例: 特定バージョン依存の機能利用を最低限とする><例: サポート期限切れ製品を採用しない>
<例: 国際標準規格(ISO/IEC 等)に準拠した技術を優先する><例: データは標準形式(XML/CSV/JSON 等)で取り出せるようにする><例: 他事業者が運用保守・更改を引き継げる構成とする>
| 目標復旧時間(RTO) | 目標復旧時点(RPO) |
|---|---|
<例: 12時間以内> |
<例: 障害発生時点> |
| 要件分類 | 要件 |
|---|---|
| バックアップ取得方針 | <例: データベースは日次オンラインバックアップ、変更ログはリアルタイム> |
| 保持期間・世代管理 | <例: 日次2世代、月次12ヶ月> |
| 取得手段 | 自動取得を基本とし、手動取得も可能とする |
| 保管場所 | <例: 別リージョン保管> |
<例: 災害対策環境を地理的に離れた拠点に設置する><例: 復旧までの間は代替手段(マニュアル運用等)で業務を継続する>
記入ガイド: 組織の情報セキュリティポリシー・社内規程・業界基準を列挙する。 参考: 政府機関等の情報セキュリティ対策のための統一基準群、安全なウェブサイトの作り方(IPA)、TLS 暗号設定ガイドライン(NISC/CRYPTREC) 等。
<例: 当社情報セキュリティポリシー(2024年改訂版)><例: OWASP ASVS Level 2 を準拠目安とする><例: 安全なウェブサイトの作り方(IPA、第7版)に準拠><例: 個人情報保護法・GDPR(該当ユーザがいる場合)>
| 対策分類 | 要件 |
|---|---|
| 通信回線対策 | <例: 外部公開と内部の通信回線を分離、TLS1.2 以上で暗号化> |
| 不正プログラム対策 | <例: 添付ファイルにリアルタイムスキャン、週次フルスキャン> |
| 脆弱性対策 | <例: 第三者による脆弱性検査を実施し結果を報告> |
| ログ管理 | <例: 操作ログ・例外事象ログを1年以上保管> |
| 不正監視 | <例: 不正アクセス・不正侵入を検知し通知> |
| 主体認証 | <例: 多要素認証を利用、外部 ID 連携 等> |
| 機密性・完全性 | <例: 通信は TLS 1.3、保存データは AES-256 で暗号化> |
| 構成管理 | <例: 構成情報を文書化し、稼働後も最新化する> |
| インシデント対応 | <例: セキュリティ侵害時は速やかに関係者(プロダクトオーナー/運用責任者)へ報告> |
| 製品サポート期間 | <例: ライフサイクルにわたりサポートが継続する製品を採用> |
| アクセス制御・権限管理 | <例: 役割ごとに最小権限を付与> |
| その他(DDoS 対策 等) |
| 項目 | 内容 |
|---|---|
| 稼働環境(本番) | <例: パブリッククラウド(リージョン: 東京)> |
| 稼働環境(検証) | |
| 稼働環境(開発) | |
| クラウドサービス選定基準 | <例: AWS / GCP / Azure いずれかから選定> |
| マルチテナント | 利用する / しない |
| 冗長化方針 | <例: 業務影響のある構成要素は冗長化する> |
| サービス終了時のデータ取扱い | <例: 復元不可能な抹消を実施> |
| テストの種類 | 目的・内容 | テスト環境 | テストデータ | 実施主体 |
|---|---|---|---|---|
| 単体テスト | 開発環境 | 擬似データ | 開発事業者 | |
| 結合テスト | 結合環境 | 擬似データ | 開発事業者 | |
| 総合テスト | 検証環境 | 擬似データ | 開発事業者 | |
| 性能テスト | ||||
| セキュリティテスト | ||||
| 受入テスト | 本番相当環境 | 受入用データ | 発注者 |
<例: テスト項目数・密度・障害収束曲線を指標として設定する><例: スプリント/リリースごとに品質状況をステークホルダーへ報告する>
記入ガイド: 各テスト工程の開始条件・終了条件と、受入判定の判断者・Go/No-Go 条件を明示する。テンプレで欠落しがちだが、リリース可否判断時に最も参照される表。
| 項目 | 内容 |
|---|---|
| テスト開始条件 | <例: 設計レビュー完了、テスト環境構築完了、テストデータ準備完了、前工程テスト合格> |
| テスト終了条件 | <例: 全テストケース実施完了、計画指標(項目数・カバレッジ等)を満たす、未消化障害なし> |
| 重大度別 残存不具合許容(致命) | <例: 0 件(検出時は即時リリース不可)> |
| 重大度別 残存不具合許容(重大) | <例: 0 件> |
| 重大度別 残存不具合許容(中) | <例: 計画値以下、暫定対応とリリース後対応計画が合意済み> |
| 重大度別 残存不具合許容(軽微) | <例: 計画値以下、リリース後の修正計画があれば許容> |
| 受入判定者 | <例: プロダクトオーナー / 事業部門責任者> |
| Go/No-Go 判断条件 | <例: 全 Must 機能が正常動作 / 致命・重大の残存不具合 0 / SLA 目標値達成 / 受入判定者の承認> |
| 作業区分 | 作業概要 |
|---|---|
| データ移行 | 既存データを次期システムで利用可能な形に変換・投入する |
| 業務移行 | 利用者が次期システムで業務を実施可能とする(教育・周知含む) |
| システム移行(切替) | サーバ/NW/アプリを次期環境で稼働させる |
- 移行概要・移行対象
- スケジュール / 関係者(発注者・既存事業者・新事業者・連携先)
- 利用環境
- 移行方法・手順
- リスクと対応(コンティンジェンシー計画を含む)
<例: 本番を模した条件で移行リハーサルを実施する><例: リハーサル結果に基づき手順書・プログラムを修正する>
<例: リリース直後 X 週間はハイパーケア期間とし、トラブル対応体制を強化する>
<例: 運用計画書を作成し、関係者の承認を受ける><例: 監視項目・作業項目・作業体制・スケジュール・運用ドキュメントを定義する><例: 24時間365日対応の要否、対応体制を定める>
| 業務 | 実施時期 | 補足 |
|---|---|---|
| サービス提供 | <例: 24時間365日(計画停止を除く)> |
|
| 定期保守 | <例: 月次 第3土曜 0:00-6:00> |
- バックアップ・リカバリは「9. 継続性」を参照
- ジョブ管理:
<例: スケジュール登録による自動実行、失敗時のアラート通知>
| 情報解析分類 | 解析内容 |
|---|---|
| エラー・障害検知 | 死活監視、状態監視、ジョブ監視、リソース監視 |
| 原因解析 | 障害発生時の原因解析に使用 |
| リカバリ | 障害発生時のリカバリ作業に使用 |
| 監査・セキュリティ | 監査の証跡、セキュリティ違反検知 |
| 可用性管理 | 稼働率、障害回復時間の計算 |
| 性能管理 | 応答時間遵守率の計算 |
| 稼働統計 | CPU/メモリ/ディスク/DB/NW のリソース管理 |
| アクセス解析 | 利用率改善のためのユーザ行動分析 |
- 監視項目: 死活、性能、ネットワーク、リソース、バックアップ実行結果、ジョブ
- 通知: サービス停止につながる異常はリアルタイム通知
- 閾値の例: CPU/メモリ/ディスク 80% 以上で警報
<例: 保守計画書を作成し、関係者の承認を受ける><例: ライブラリ・ミドルウェアのサポート期限・バージョンアップ情報を関係者へ報告する><例: パッチ適用は定期保守時に実施し、緊急パッチは個別判断する>
| 保守項目 | 概要 |
|---|---|
| 障害対応 | 障害検知時の暫定対応・原因調査・恒久対応 |
| 作業依頼対応 | 関係者からの作業依頼の影響調査・実施 |
| バックログ対応 | 利用者からの改修要望対応 |
| 問合せ対応 | 利用者からの問合せ対応 |
| 項目 | サービスレベル | 計測方法 | 報告頻度 |
|---|---|---|---|
| 障害一次回答時間 | <例: 検知から30分以内> |
月次 | |
| 重大障害復旧時間 | <例: 4時間以内> |
月次 | |
| 月次稼働率 | <例: 99.8%以上> |
月次 |
記入ガイド: 本書本体に収まらないボリュームの一覧表は、別ファイルとして添付し、本節にリンクを記載する。
| 別添番号 | 名称 | 形式 | 配置 |
|---|---|---|---|
| 別添1 | 機能一覧(詳細版) | xlsx | <パス> |
| 別添2 | 画面イメージ集 | <パス> |
|
| 別添3 | データ定義(詳細版) | xlsx | <パス> |
| 別添4 | 業務フロー詳細 | <パス> |
|
| 別添5 | 移行対象データ一覧 | xlsx | <パス> |
以上