システム開発の要件定義書の書き方｜発注前に整理する項目と記入例
目次
システム開発の要件定義書は、業務で実現したいことを、開発側と確認できる条件にまとめる文書です。発注前の担当者が最初から技術設計まで完成させる必要はありません。現状の課題、対象業務、使う人、入力と出力、例外、完成の判断方法を揃えるところから始めます。
この記事では、初めて開発を依頼する担当者向けに、要件定義のたたき台を作る項目と記入例を紹介します。例は架空の「社内備品の貸出申請システム」です。金額や納期を保証するためのひな形ではなく、見積もりや開発の相談で認識を合わせるために使います。
要件定義書を書く前に集める資料
現状の申請書、管理台帳、作業手順、よく起きる問い合わせを集めます。機密情報や個人情報を開発会社へ共有する際は、社内の共有ルールに従い、相談に必要な範囲へ絞ってください。最初の説明では、実データを匿名化した見本や架空サンプルも使えます。
実際に操作する担当者だけでなく、承認者、運用管理者、問い合わせを受ける人にも話を聞きます。申請が正常に通る手順に加え、差し戻し、取り消し、担当者不在、重複入力が起きたときの扱いを確認します。
IPAの「ユーザのための要件定義ガイド」は、利用する業務部門が主体的に関与することや、ビジネス要求、システム化要求、要件定義の管理を扱っています。技術用語を埋める前に、業務側の目的を明確にする参考になります。IPAの要件定義ガイド
項目1 目的と今回の対象範囲
困りごとを観察できる状態で書く
「業務を効率化する」だけでは、完成後に効果を判断しにくくなります。誰がどこで困り、どの状態になれば改善したと判断できるかを書きます。
記入例は「備品の貸出申請がメールに分散し、申請者が承認状況を問い合わせている。申請者が自分の申請の状態と次の担当者を確認できるようにする」です。問い合わせ件数や確認時間を測っているなら、対象期間と計測方法も添えます。未計測の削減率は、実績として書かないでください。
初回に含める機能と対象外を分ける
備品貸出の例なら、申請、承認・差し戻し、貸出、返却、履歴閲覧を初回の対象にします。備品の購入申請、会計上の資産管理、他拠点との配送管理は対象外とする、といった線引きが考えられます。
将来追加したい機能は別欄に残します。初回から必須の機能、追加できれば便利な機能、今回見送る機能を分けると、予算や期限に応じた相談がしやすくなります。すべてを「必須」とする場合は、その理由と業務上の代替手段も確認します。
項目2 業務の流れと利用者の権限
現在の流れと、システム導入後の流れを順番に書きます。たとえば「社員が申請、上長が承認、管理担当が貸出、管理担当が返却確認」という順序です。各工程に入力、判断、次の担当者を添えると、画面だけでは見えない役割が分かります。
権限は、役職名だけでなくできる操作で表します。
申請者：自分の申請を作成し、承認前の内容を修正する
承認者：担当する申請を承認・差し戻しし、理由を記録する
備品管理担当：貸出・返却を記録し、備品の利用可能状態を管理する
システム管理者：利用者と役割を管理する。業務上の承認権限とは分けて検討する
「見られる」「登録できる」「修正できる」「削除できる」「承認できる」を区別します。異動した人の過去の申請、退職者の記録、代理承認の扱いも未決事項として確認します。管理者だからすべての業務判断をできる、という前提を置かないようにします。
項目3 入力データと出力の定義
入力項目には、名称だけでなく、型、必須か任意か、選べる値、入力チェック、更新できる人を書きます。例として、備品IDは文字列、貸出希望日は日付、返却予定日は貸出希望日以降、用途は所定の長さ以内といった条件を検討します。実際の長さや制約は利用者と確認して決めます。
同じ「日付」でも、時刻まで必要か、表示と保存のタイムゾーンは何かで仕様が変わります。番号は先頭の0が必要か、メールアドレスは連絡用か本人識別用かなど、用途も添えましょう。
出力は「CSV出力」とだけ書かず、項目、並び順、対象期間、抽出条件、ファイル形式、利用先を記載します。空欄や改行を含むデータをどう出すか、ダウンロード権限が必要かも確認します。原本データと画面・帳票で意味が変わらないように、用語の定義を揃えます。
項目4 機能と例外を一つの単位で書く
要件IDを付けて追跡できるようにする
機能ごとに識別子を付けると、見積もり、設計、テストで同じ内容を指し示せます。たとえば次のように記入します。
要件ID：R-03
機能名：備品の返却記録
目的：返却済みの備品を、次の貸出候補として扱えるようにする
利用者：備品管理担当
前提：対象の貸出記録が「貸出中」である
入力：貸出記録ID、返却日時、点検結果
処理：返却を記録し、点検結果に応じて備品の状態を更新する
出力：貸出記録の状態、備品の状態、更新者と更新日時
例外：既に返却済みの場合は重複して記録せず、状態を知らせる
未決事項：故障が見つかったときの状態名と通知先
受入条件：正常な返却と、二重操作、権限外操作を試験する点検結果によっては修理待ちにする必要があります。「返却したら常に貸出可能」と決めつけると、実際の運用と合わない場合があります。こうした分岐を先に書き出しておくと、確認漏れを見つけやすくなります。
エラー時に残る状態まで決める
二人が同時に同じ備品を貸し出そうとする、送信後に通信が切れる、同じボタンを二回押すなどのケースも考えます。「エラーを表示する」だけでなく、記録が作成されたか、再実行してよいか、利用者はどの画面で状態を確認できるかを書きます。
例外はすべてを自動解決する必要はありません。管理担当へ回す場合は、誰がどの情報を見て修正し、その記録を残すかを定義します。
項目5 性能・停止・保護などの非機能要件
機能が揃っていても、月末に動かない、復旧できない、必要な権限管理がない状態では業務に使えません。速度、利用時間、停止時の対応、バックアップ、アクセス管理、記録の保持などを整理します。
IPAの非機能要求グレードは、非機能要求を分類し、重要な項目から要求レベルを確認するための資料です。項目をそのまま全部要求するのではなく、自社の業務への影響を考えて使います。IPAの非機能要求グレード
「快適な速度」などの曖昧な表現は、測定条件を含む形へ変えます。たとえば「履歴1万件、同時利用20人の試験で、一覧表示操作の95%以上が3秒以内」は具体化の例です。ただし、この数値は推奨基準でも達成保証でもありません。操作の開始・終了、端末、ネットワーク、試験回数まで開発側と確認して決めます。
停止対策では「何時間止まると困るか」「どの時点のデータまで復旧できればよいか」「停止中の申請を何で受け付けるか」を業務側が説明します。これに対する構成や費用は、技術担当と相談して選びます。
項目6 移行と運用の担当者
旧Excel台帳から移行する場合、対象期間、件数、項目対応、重複や空欄の扱いを決めます。移行後の件数だけでなく、貸出中の備品と利用者の対応が一致するかなど、業務上の整合性も確認します。
切り替え日時、旧台帳を更新しなくなる時点、移行後に不整合が見つかった場合の戻し方も必要です。過去データをすべて移すのか、旧台帳を参照用として残すのかで作業が変わります。
運用開始後の問い合わせ、利用者追加、権限変更、障害連絡、備品マスタ更新の担当を決めます。要件定義の時点で、移行・運用・テストを含めて検討する観点はIPAのガイドでも扱われています。IPAのガイド書籍概要
項目7 受入条件を具体的な操作で書く
「問題なく動く」では確認する人によって判断が変わります。前提、操作、期待結果を一組にして、業務担当者が判断できる形にします。
R-03の返却記録なら、次のケースを準備します。
正常時：貸出中の備品を正常な点検結果で返却すると、貸出記録は返却済みとなり、備品は貸出可能になる
故障時：点検で故障が見つかった場合、合意した修理待ち状態となり、貸出候補に表示されない
重複時：同じ返却をもう一度操作しても、返却記録が二重に作られない
権限外：申請者のアカウントで管理担当の返却操作を実行できない
合否判定者、使うデータ、証跡の残し方、未修正の問題があった場合の判断も決めます。要件IDから試験項目をたどれるようにすると、書いたのに試していない要件を見つけやすくなります。
未決事項と変更履歴を残して相談する
初稿に不明点が残るのは自然です。空欄にせず、「確認すること／担当者／決める期限／決まらない場合の影響」を記録します。期限は実際の関係者と合意してから入れてください。
変更が出たら、変更理由、対象の要件ID、影響する機能・費用・日程・試験、判断者を残します。文書に書いたことが契約や見積もりへどう反映されるかは、個別の資料で確認する必要があります。要件定義書だけで発注条件が自動的に確定するわけではありません。
最初の相談前には、目的、初回範囲、現状の資料、代表的な入力と出力、例外、未決事項を一式にします。現場担当、承認者、運用担当が同じ例を読んで説明できれば、具体的な見積もりと設計の相談へ進みやすくなります。
業務の整理や開発範囲の切り分けから相談したい場合は、Miyabeeのシステム開発支援をご覧ください。