要件定義書とは？必要項目や書き方、発注企業が意識したいポイントを解説

システム開発を依頼する際は、開発に入る前に「要件定義書」という書類の作成が欠かせません。しかし、システム開発を外注した経験がない場合、要件定義書の意味や活用方法がイメージこともあると思います。

そこで今回は、要件定義書の必要項目や書き方、発注企業が意識したいポイントについて解説します。要件定義書の目的と併せて解説するので、どこに注意を払うべきかをイメージしつつ、ご確認ください。予備知識を持っておくことで、システム開発に向けた準備を進められるほか、予算・スケジュールをオーバーするリスクも回避しやすくなるでしょう。

要件定義書とは？

要件定義とは、システムを導入することで、叶えたい要望をまとめる作業です。そして、その内容を項目に落とし込んだものが「要件定義書」です。

要件定義書を作成する目的

要件定義書を作成する目的は、開発の概要や機能要件などの認識を、開発側・発注側で一致させることです。要求に対して異なる方向性の製品・サービスを開発しては、修正・仕様変更が重なり、時間・コストの無駄につながります。

効率的かつ正確なシステム開発を実現するために、要件定義書を作成しなければなりません。

提案依頼書（RFP）や要求仕様書との違い

システム開発を行う上で、要件定義書に似たような書類として、「提案依頼書（RFP）」や「要求仕様書」が挙げられます。それぞれ目的や内容が異なるため、その違いについて、項目別に解説します。

提案依頼書は、発注側がシステムやサービスの開発を依頼したい際に、候補となる開発会社に対して、提案を依頼するために課題や要望をまとめた書類です。その目的は、開発会社からの提案を集めることや、開発会社に対して公平に同じ要望を伝え、選定の基準を明確化することなどがあります。

主にプロジェクトの背景や目的、提案してほしい内容や提案条件などがまとめられており、開発会社に見積もりの依頼をする手前で作成することが多く、開発会社はその内容をもとに追加のヒアリングをしたり、内容を確認して提案を行います。

一方で要求仕様書は、提案依頼書で見えてきた「課題」「目的」から、「何をしたいか・何を求めているか」について、業務視点から整理し、システムやサービスに期待することをまとめた資料です。ビジネス・業務的な視点から、システムやサービスに対して求める（要求すること）を明確化し、認識齟齬を防ぐことを目的につくられます。発注側の要望を、よりシステム開発に近い部分に落とし込むために作成されるもので、「要求」をまとめたものになるため、主体となる作成者は発注側になりますが、発注側の担当者にシステム知見がない場合は、開発会社側が作成することもあります。

提案依頼書は、システム開発プロジェクトの「入口」になるドキュメントで、プロジェクト全体の方向性を示すのに対し、要求定義書は、より「システム開発」に近く、開発の基盤となるようなドキュメントの役割を持ちます。

要件定義書の目次

要件定義書への理解を深めるために、構成する項目を見てみましょう。必要な項目としては、次のようなものが挙げられます。

＜要件定義書の目次＞

• システムの概要：導入の目的と目標、導入背景など
• 業務要件：フロー図や開発規模、時期、場所など
• 機能要件：機能の一覧表や操作画面、扱う情報・データなど
• 非機能要件：システム方式やユーザビリティ、性能、拡張性など

要件定義書は、要求定義で導き出された要求を、システムで実現するにはどのようなことが必要かを具体的に記した書類です。システムの具体的な仕様や要件がまとまっており、実現するための方法が記載されています。

主に、システム・技術的な観点で作成されているため、開発会社側が、発注企業側と協力しながら作成することが多いです。システムに不慣れな発注側の担当者もいるため、システム開発会社側は、必要十分かつ理解しやすい内容で作成することが求められます。

【項目別】要件定義書の書き方

前述した項目別にしたがって、要件定義書の書き方を解説します。

①概要・目的

まず明確にしておきたいのが、システム導入の目的と目標です。システム設計の詳細を決めていくうえで迷いが生じたときに、道標の役割を担ってくれるため、システム開発の成功確率を高められます。また、現状の課題やシステムの構成、用語定義など、開発内容をイメージできる概要の記載も必要です。詳細は書類内で後述されるため、内容は簡潔にします。

②業務要件

業務要件では、システム導入後の業務がどのような形になるのか、システム導入すべき業務・しない業務の区分けなどを記載します。具体例から、業務要件の記載内容を見ていきましょう。

＜業務要件の記載例＞

• 業務フロー：業務の流れをフロー図でまとめる
• 一覧：システム導入する業務や担当者を記載
• 導入範囲：システムが導入される業務の範囲、対象外の範囲
• 時間や場所：システムが導入された場合の業務時間、導入場所

業務の流れは、テキストよりもフロー図のほうが視覚的にわかりやすく、システムが導入される範囲も把握しやすくなります。

③機能要件

機能要件では、概要と業務要件を踏まえたうえで、業務に必要な機能を落とし込みます。記載内容の一例を見ていきましょう。

＜機能要件の記載内容＞

• 一覧：システムに必要な機能の一覧
• 操作画面イメージ：画面ごとのイメージ画像、役割
• ファイルの種類：システム上で入出力されるファイルの種類
• データ：システム上でやりとりされるデータの種類、処理方法
• 外部連携：外部インターフェースとの連携方法

発注側が機能要件の確認を行う場合は、「どのようにシステムを利用するのか」という完成形をイメージしつつ、わかりにくい内容がないかを確認しましょう。不明点があればそのままにせず、システム開発会社と協議して進めることが大切です。

④非機能要件

非機能要件は、発注側の目に触れない、システムの裏側について記載します。具体例をいくつか見ていきましょう。

＜非機能要件の記載内容＞

• システム規模：同時利用者数やトランザクション数
• システム性能：処理速度や処理の応答時間
• 信頼性：復旧時間やバックアップタイミングの目安など
• ユーザビリティ：利用者にとっての使い勝手、誰が使うかなど
• 拡張性：将来的な利用者数、扱うデータ・情報量の増加に伴う設計方針
• セキュリティ：求められるセキュリティレベルや適した稼働環境など
• 運用・保守：利用者の運用方法や保守体制

上記のとおり、非機能要件はシステムの性能面にフォーカスした内容が記載されます。発注側は、普段の業務では意識していないことも多く、確認しづらいこともあるかもしれませんが、システムをストレスなく、快適に、安全に使用するために大事な項目です。具体的にどのくらいの人数が、どのような頻度で、バックアップはどのくらいあれば問題ないかなどイメージしながら確認しましょう。もし、システムの納品以降、社内のシステム担当者が本システムの保守を担当することになるのであれば、社内のシステム担当者にも確認を取りながら、問題ないか確認して進めましょう。

要件定義書の作成ステップ

要件定義書の作成ステップについて、順を追って解説します。

①現状の把握・課題の特定

まずはヒアリングが行われ、現状の業務に対する課題の洗い出しが行われます。ヒアリングでは、発注側である依頼者が想定する課題以外にも、根本的な原因・問題が隠れているケースもあります。

根本原因を解明するため、発注側は現状を包み隠さず提示し、開発会社から適切な提案をしてもらえるよう配慮することが大切です。ヒアリング内容を分析し、根本的な経営課題は何か、どのような機能であればクリアできるのかを検討してもらいましょう。

②目的の明確化

ヒアリングの次は、システム導入に向けた目的の明確化です。システム導入のゴールが定まることで、必要な機能の洗い出しにつながります。

「何のために」「どんな機能がほしいのか」を開発側に伝えることで、導入するシステムの輪郭が見えてくるでしょう。ただし、発注側が具体的なニーズを明確に提示できるとは限らないため、開発側からのヒアリングで潜在ニーズを探ってもらうことも大切です。

③要件の優先順位の設定

次は、搭載する機能・性能の優先順位を設定します。優先順位を決めるポイントは、次のとおりです。

＜優先順位を決めるポイント＞

• 実現可能な機能・性能か
• 予算・スケジュールにマッチしているか
• 技術的なハードルがないか
• 各要求が矛盾していないか

発注側の要望をすべて叶えるのは現実的ではありません。そのため、上記のようなポイントを軸に優先順位を決め、実装する機能・性能を検討する必要があります。

④システム構成・全体像の定義

ヒアリング内容を整理した後は、開発側・発注側でシステムの方向性を共有するため、システム構成・全体像を定義します。「抜けている要素はないか」「要求通りのシステムに仕上がるか」などを把握できるよう、全体像は構成図として作成されます。

⑤業務要件・機能要件・非機能要件の定義

これまでの内容を要件定義書として落とし込むため、業務要件・機能要件・非機能要件を定義します。この時点で開発側・発注側の認識にズレが生じた場合、仕様変更や修正など余計な工程を発生させるリスクがあります。

納期・予算に合わせて開発を進めるためにも、開発側・発注側で確認しつつ、各要素を明確化しなければなりません。

⑥予算・スケジュールの策定

最後は、予算・スケジュールの策定です。ヒアリングの時点で、希望予算・スケジュールを開発側に伝えますが、必ずしも希望通りに進むとは限りません。業務要件や機能要件など、これまで定義してきた要素をもとに決定されるため、開発規模や技術的制約、追加要求の有無などによってスケジュールは変動します。予算については、開発費だけでなく、サーバー費や保守・運用費なども含めて算出されます。

双方で打ち合わせを行い、無理のない予算・スケジュールの落としどころを探りましょう。

要件定義書の作成において重要なポイント

要件定義書の作成における重要なポイントを4つ解説します。

発注側も積極的に参加し、すり合わせながら進める

発注側も積極的に開発へ参加し、双方の認識をすり合わせながら進めましょう。認識の齟齬があるまま開発を進めた場合、発注側の期待するシステムに仕上がらないリスクがあります。事前に打ち合わせも含めたスケジュールを組み、要件定義の認識を共有させることが重要です。

また、打ち合わせには、意思決定層が同席してください。追加要求や仕様変更などの意見が後から出た場合、開発現場を混乱させる恐れがあるためです。

やること・やらないことを明確にする

システム開発にあたっては、各ポジションの役割（やること・やらないこと）を明確にして、開発プロセスに支障をきたさないよう配慮する必要があります。発注側が開発側にすべてを任せてしまっては、開発側がコア業務に注力できません。

発注側は業務プロセスや課題の洗い出し、開発側はシステムへの落とし込みなど、明確な役割分担を行い、開発をスムーズに進める協力体制を築きましょう。

課題をくまなく解決できているかを確認する

要件定義書に記載の機能・性能で課題を解決できるかを確認し、スケジュール・予算の変更リスクを抑えましょう。要件定義書は、システム開発の方向性を示すものです。

要件の抜け・漏れがあれば、仕様変更や修正などの作業が追加され、スケジュール・予算が変更される可能性があります。双方で要件定義書のすり合わせを行い、問題のある箇所がないか十分に確認してください。

専門知識がなくても理解できる内容にする

専門知識がない人でも理解できる要件定義書でなければ、認識のすり合わせが難しく、要件定義書の役割を完全に果たすことができるとは言いかねます。要件定義書は、エンジニアのみが目をとおす書類ではありません。

開発プロジェクトに携わる人すべてが確認する書類なので、理解できない箇所があれば、共通認識を持てない恐れがあります。理解できない箇所があれば、開発側にその旨を必ず伝えましょう。

まとめ

要件定義書は、システム開発の方向性を示し、発注側の要望に応えたシステム開発へとつなげる重要な書類です。ヒアリングをもとに作成されるため、協力的な姿勢で取り組む必要があります。

内容を確認する際は、こちらの要望が盛り込まれているかを確認し、開発途中の仕様変更・修正のリスクを抑えられるよう注意しましょう。トラブルなく開発を進めるためにも、確度の高い要件定義書を作成してもらうことが大切です。