🌊

ビジネスアナリストの視点で考える「要件定義はどこまで書くか」

2025/01/22に公開

はじめに 🎉

システム開発において、「要件定義はどこまで書くべきか?」という問いは常に存在します。特に**ビジネスアナリスト(BA)**としては、ビジネスサイドとITサイドの橋渡し役として、必要十分な情報を適切な粒度でまとめることが求められます。

本記事では、タイムシート管理システムを例に、業務要件機能要件画面要件データ要件の4つの要件をどの程度まで詳細に記載すべきかを解説します。特に、機能要件におけるINとOUTの間のビジネスロジックの明示や、データ要件との紐付けに焦点を当てています。🚀


1. タイムシート管理システムの概要 ⏰✨

背景と課題 🕒📉

  • 紙やエクセルで作業時間を管理しており、集計や承認に多大な工数がかかっている。📄➡️📈
  • プロジェクトごとの稼働状況をリアルタイムに可視化できず、コスト管理が不透明。💸🔍

目標 🎯

  1. 作業時間入力の効率化(エクセル→システム)
  2. 週次・月次レポートによるプロジェクト別コストの可視化
  3. 承認フローのオンライン化で差し戻しを迅速化

想定ステークホルダー 🤝

  • 経営層:ROI重視でコスト削減や生産性向上を狙う。📈💼
  • 管理者(リーダー):チームメンバーの勤怠や作業時間を承認・分析。📊👥
  • 一般ユーザー(従業員):日々の作業時間を記録。🕰️✍️
  • IT部門(開発チーム):システム設計・実装・運用保守。💻🔧
  • ビジネスアナリスト(BA):要件定義・スコープマネジメントを主導。🧩📚

2. 業務要件:アクターとシステムのプロセス 📝📊

業務要件の役割 🏷️

  • **アクター(ユーザーや管理者など)**とシステムがどのような業務フローを回すのかを定義。
  • 現行フローと理想フローを比較し、システム導入後のビジネスプロセスを明確化。🔄✨

例:業務フロー 📈

(1) [ユーザー] -> 日次の作業時間を入力 -> [システムに保存]
(2) [管理者] -> 週次/月次レポートを確認 -> [承認 or 差し戻し]
(3) [ユーザー] <- 差し戻しがあれば修正 -> [再登録]

業務要件のまとめ例 📋

No. 業務名 アクター 目的 フロー概要 次の業務
1 日次作業記録の入力 一般ユーザー 毎日の稼働内容を正確にシステムへ登録し、後続の集計を効率化。 1. ユーザーが日次入力画面で時間を入力
2. システムが保存・バリデーション
3. 結果をユーザーに通知
週次・月次レポートの確認
2 週次・月次レポートの確認 管理者 チームの合計作業時間やコストを把握し、承認へ繋げる。 1. 管理者が期間指定
2. システムが集計しレポートを表示
3. 承認 or 差し戻し
作業時間の承認・修正
3 作業時間の承認・修正 管理者、一般ユーザー オンライン承認フローで差し戻しや二次チェックを効率化する。 1. 管理者がレポートを確認
2. 必要に応じユーザーへ差し戻し
3. 承認完了時にステータス更新
業務完了(今回はスコープ外)

💡BA視点のコツ

  • 変化が多い業務(例:承認フロー)は、段階的に詳細化していく。
  • ビジネスインパクトの高い箇所(コスト計算など)を優先的に確認。

3. 機能要件:IN/OUTとビジネスロジックを明記 ⚙️🔗

機能要件の役割 🛠️

  • システムが提供する機能を、**「In(入力)」「ビジネスロジック」「Out(出力)」**の観点で整理。
  • 特に、ビジネスロジックに「INのエンティティと項目名を使った計算式・処理」を書き、**データ要件(エンティティ.項目名)**と紐づける。🔍

例:機能要件(IN⇔ビジネスロジック⇔OUTの形式) 📑

機能名 目的 In(入力) ビジネスロジック Out(出力) 関連データ
日次作業記録保存機能 ユーザーの入力をDBに保存し、後続の集計に備える 作業記録.日付
作業記録.作業時間
1. 作業時間が0以上かチェック
2. 作業記録.プロジェクトIDの有効性を検証
メッセージ.保存結果 作業記録.記録ID
作業記録.プロジェクトID
週次レポート生成機能 指定期間の作業時間を合算し、コストを計算して表示 作業記録.作業時間
プロジェクト.時給
1. レポート.合計時間 = Σ(作業記録.作業時間)
2. レポート.コスト = レポート.合計時間 × プロジェクト.時給
レポート.合計時間
レポート.コスト
作業記録.作業時間
プロジェクト.時給
承認フロー管理機能 レポートを承認 or 差し戻し可能にする レポート.承認フラグ
レポート.コメント
1. 承認権限が管理者ロールであることを確認
2. 差し戻し時コメント必須
レポート.承認ステータス レポート.承認フラグ
レポート.コメント

計算ロジックのテストケース例 🧪🔍

計算ロジックが含まれる機能では、事前にテストケースを作成し、ステークホルダーと答え合わせをしておくことで、誤解や不具合を防ぎやすくなります。

No. テストケース名 前提・入力条件 期待する出力
1 週次合計40hチェック ユーザーAが月~金で各8h入力(合計40h)、土日は入力なし レポート.合計時間=40h
コスト=40h×プロジェクト.時給
2 端数処理チェック(4週+2日) 4週(各40h)+最終2日あり。端数部分をどう扱うかは事前合意が必要 レポート.合計時間=160h+α
ステークホルダーと合意した計算式を反映
3 差し戻しコメント必須 管理者がレポート.承認フラグを差し戻しに設定、コメント空欄の場合 差し戻しエラーを返す。
コメントありで差し戻し可
4 プロジェクト別時給計算確認 プロジェクトA=2000円/h、プロジェクトB=2500円/hをユーザーが同日に作業したケース レポート.コスト=Σ(作業記録.作業時間×プロジェクト.時給)

🎯BA視点のヒント:

  • テストケースは主要なパターンに絞ることで、運用コストを抑える。
  • 曖昧なルール(端数処理など)はテストケースで明確化し、ステークホルダーと早期に合意。

4. 画面要件:画面構成と機能をリンク 🖥️🔗

画面要件の役割 🎨📱

  • ユーザーがどの画面で何を入力/表示し、どの機能を呼び出すかを定義。
  • 画面→機能→データ」の流れを可視化することで、ユーザー体験を具体的にイメージしやすくなる。

例:画面要件 📑

画面名 構成要素 入力項目 出力内容 利用機能
ログイン画面 ユーザーID・パスワード、ログインボタン ユーザーID、パスワード ログイン成功 or エラーメッセージ 認証機能(既存想定)
日次記録画面 日付入力欄、作業時間入力欄、保存ボタンなど 作業記録.日付、作業記録.作業時間 保存成功 or バリデーションエラー 日次作業記録保存機能
週次・月次レポート画面 期間指定欄、集計ボタン、承認ボタンなど レポート.対象期間、レポート.承認フラグ レポート結果(合計時間、コスト、承認状態) 週次レポート生成機能、承認フロー管理機能

画面要件のポイント 🗝️

  • 画面間の遷移を示すと、ユーザーの操作フローが一目で理解できる。
  • 機能要件との紐付けを明確にすることで、仕様の抜け漏れを防ぐ
  • ワイヤーフレーム簡易的なUIイメージを補足すると、更に具体的にイメージしやすくなる。🎨

5. データ要件:エンティティと項目を論理的に整理 💾📊

データ要件の役割 🏷️

  • システムで扱うデータ(エンティティや項目)を論理的に定義し、ビジネスルール(制約)を明示。
  • 機能要件で使用するエンティティ.項目名と整合を保つ。🔗

例:データ要件 📁

データ名 用途 主な項目(論理名) 保存先(論理) ビジネスルール・制約
ユーザー情報 従業員の基本情報を管理 ユーザーID、氏名、役割(一般 or 管理者) ユーザー情報ストレージ 役割=管理者のみ承認フロー管理が可能。パスワード暗号化必須。
作業記録 日々の作業時間を記録 記録ID、日付、作業時間、プロジェクトID 作業記録ストレージ 作業時間≥0、プロジェクトID必須。
プロジェクト プロジェクトと時給を保持 プロジェクトID、プロジェクト名、時給 プロジェクトストレージ 時給≥0、PJ終了後も参照可能なルール設定。
レポートデータ 週次・月次の集計結果や承認状態を管理 レポートID、対象期間、合計時間、コスト、承認フラグ レポートストレージ コスト=合計時間×時給。承認フラグ=trueで承認済み。

データ要件の整理ポイント 🗂️

  • エンティティ名はビジネス用語を用い、論理名でわかりやすく命名。
  • 関連機能を明記することで、どの機能がどのデータを操作するかが一目で分かる。
  • ビジネスルール(例:作業時間は0以上、承認後は修正不可)を明示して、データの整合性を保つ。

6. 計算ロジックをテストするサンプルケース 🧪🔍

計算ロジックビジネスルールが含まれる機能では、事前にテストケースを作成し、ステークホルダーと答え合わせをしておくことが重要です。これにより、誤解や不具合を防ぎ、スムーズな開発と品質の高いシステムを実現できます。

例:計算ロジックのテストケース 📊

No. テストケース名 前提・入力条件 期待する出力
1 週次合計40hチェック ユーザーAが月~金で各8h入力(合計40h)、土日は入力なし レポート.合計時間=40h
コスト=40h×プロジェクト.時給
2 端数処理チェック(4週+2日) 4週(各40h)+最終2日あり。端数部分をどう扱うかは事前合意が必要 レポート.合計時間=160h+α
ステークホルダーと合意した計算式を反映
3 差し戻しコメント必須 管理者がレポート.承認フラグを差し戻しに設定、コメント空欄の場合 差し戻しエラーを返す。
コメントありで差し戻し可
4 プロジェクト別時給計算確認 プロジェクトA=2000円/h、プロジェクトB=2500円/hをユーザーが同日に作業したケース レポート.コスト=Σ(作業記録.作業時間×プロジェクト.時給)

💡BA視点のヒント

  • テストケースは主要なパターンに絞ることで、運用コストを抑える。
  • 曖昧なルール(端数処理など)はテストケースで明確化し、ステークホルダーと早期に合意。

7. スコープマネジメント:どこまで書くかを決める5つの視点 🎯

スコープマネジメントの視点 🔍

  1. ビジネスインパクト

    • コスト計算や承認フローなど、ビジネス的価値が高い部分を最優先で詳細化。
  2. ステークホルダーの多様さ

    • 経営層、管理者、ユーザー、IT部門…それぞれが求める情報の粒度が違う。バランスを取る。⚖️
  3. 計算ロジックやビジネスルールの変化リスク

    • 週次・月次の端数処理やコスト計算のアルゴリズムは、変更リスクが高い。最低限のルールを明示し、テストケースで早期に確認。
  4. リソースとスケジュール

    • 短期プロジェクトやアジャイル手法では、MVP的にコア要件を優先し、追加要件は後続フェーズで詳細化。
  5. 外部連携・既存システムとの統合

    • 勤怠システムや給与計算システムとの連携範囲を事前に定めてスコープ外を明確化

🔥ポイント

  • ビジネスインパクトの高い部分を優先的に詳細化。
  • ステークホルダーの多様なニーズを理解し、バランスを取る。
  • 計算ロジックビジネスルールの変化リスクに備え、最低限のルールを明示しテストケースを準備。

8. まとめ 🏁✨

本記事では、タイムシート管理システムを例に、ビジネスアナリストとして以下の要件をどこまで詳細に書くべきかを解説しました。

  1. 業務要件

    • アクターとシステムの業務フローを整理し、ビジネスインパクトの大きい箇所を詳述。
    • 業務フロー図表形式でわかりやすくまとめる。
  2. 機能要件

    • システムが提供する機能を**IN(入力)、ビジネスロジック、OUT(出力)**の観点で定義。
    • ビジネスロジックには、エンティティ.項目名を使った計算式や処理を明示。
    • テストケースを作成し、ステークホルダーと事前にすり合わせる。
  3. 画面要件

    • 各画面の構成要素入力項目出力内容を定義し、機能との紐付けを明確に。
    • 画面遷移図ワイヤーフレームを用いてユーザー体験を具体化。
  4. データ要件

    • エンティティと項目を論理的に定義し、ビジネスルールを明示。
    • 機能要件との整合を保ち、どの機能がどのデータを操作するかを明確にする。
  5. スコープマネジメント

    • ビジネスインパクトステークホルダーの多様さ計算ロジックの変化リスクリソース・スケジュール外部連携の5つの視点でスコープを管理。

💡要点

  • INとOUTの間にビジネスロジックを明記することで、計算やルールが透明化。
  • 機能要件とデータ要件をエンティティ.項目名で紐付けることで、要件の整合性と一貫性を高める。
  • 画面要件を明確にすることで、ユーザー体験と機能の連携をスムーズに。
  • テストケースを用意し、計算ロジックの答え合わせを行うことで、誤解や不具合を防ぐ。

**「どこまで書くか」**はプロジェクトの特性やステークホルダーのニーズによって異なりますが、ビジネスアナリストの役割として、ビジネス価値を最大化するために必要十分な要件を、最適な粒度でまとめることが成功への鍵です。

ぜひ、今回のサンプルを参考に、要件定義をブラッシュアップし、スコープマネジメントを円滑に進めてください!🎉✨


以上が、絵文字をさらに増やし、画面要件を含む形でブラッシュアップしたZenn記事サンプルです。読み手であるビジネスアナリストが、要件定義の重要ポイントを理解しやすいように構成しています。ぜひ、Zennで公開してみてください!🚀😊

Discussion