要件定義書の書き方とは？記載項目や作成のポイントを解説

この記事では、ITシステムを開発する際に作成する要件定義書の書き方、作成作業の流れを紹介します。要件定義書を作成することになったが難しそう、という方もこの記事から概要を学んでいきましょう。

要件定義書とは？

要件定義書とは、ITシステムの開発において、システムを開発する理由や必要な機能、画面構成の使い勝手など、あらゆる仕様を取りまとめて文書化したものです。 また、システム開発プロジェクトの予算やスケジュール、体制なども要件定義書の中で明示します。
システム開発プロジェクトの工程・作業は、すべて要件定義書に基づいて実行されます。その意味で、要件定義書は、プロジェクトの成否を左右するきわめて重要な文書です。

要件定義書を作成する際には、まず発注者 (ユーザー) が主導して原案を企画書として取りまとめ、その企画書に沿ってシステム開発会社 (ベンダー) に提案を募ります。 これをRFP (Request for proposal) と言います。各社のRFPを審査し、最も良い提案をした会社と契約します。

要件定義書を書く目的

要件定義書は、ユーザーとベンダーの間で取り交わされる契約文書のひとつです。 ユーザーは要件定義書に記載したことがすべて実現されることを期待し、ベンダーは要件定義書に沿って開発やプロジェクト管理を実行します。 もちろん実際の開発作業では、事前に想定していなかったトラブルなどで設計や実装、スケジュールが変更されることも多いですが、要件定義書という土台がしっかりしていれば、こういった影響を最小限に抑えることができます。

要件定義書の記載項目

ここでは、要件定義書に記載する項目について紹介します。要件定義書について、必ずこう書くべきという標準は存在しないため、会社ごとにフォーマットや構成は変わりますが、共通して含まれるべき内容を以下に列挙します。

• ビジネスコンセプト: 現状の課題、システムを開発する目的など
• ステークホルダー: 関係部門、意思決定権者の一覧
• 要求分析: ユーザーの期待、現状、あるべき姿の整理
• データモデル: システムで扱うデータの構造定義
• ビジネスプロセスモデル: システムを用いて行う業務全体の流れ
• コミュニケーション定義: プロジェクトで使用する用語などの整理
• 予算、スケジュール、プロジェクト体制: プロジェクトを推進する上で必要な情報

詳細は、IPAによる、「ユーザのための要件定義ガイド 第2版」を参照してください。

要件定義書の書き方

ここからは、要件定義書に含まれる各項目について、具体的な記載内容をご紹介します。要件定義書をもとにあらゆる意思決定、作業が行われますので、ヌケモレのない記述が求められます。

既存業務・システムの課題を洗い出す

はじめに、システムを開発する目的を明確にします。新規開発にせよ既存システムの更新 (リプレース) にせよ、何か現状に課題があるからこそプロジェクトが立ち上がったはずです。

• 手作業が多く効率が悪い
• 情報を集約し作業ミスや遅延をなくしたい
• 既存システムの性能が低く、処理に時間がかかる
• 業務プロセスの変更に伴い、既存システムで不足する機能が出てきた

上記のような課題について、関係者へのヒアリングやデータ収集、ロジックツリー (なぜなぜ分析) などを用いて根本原因を分析します。 そのうえで、すべての課題を一度に解決することは難しいので、優先順位を付け、今回はどのような課題をシステム化によって解決するかを決めます。

クライアントの要求を明確化する

解決すべき課題が特定されたら、どのようなシステムがあれば解決されるか、クライアント (ユーザー) の期待 (要求) をヒアリングし、整理します。 自社内の開発案件であっても、実際にシステムを利用する現場部門がユーザーになるため、要求をもれなく聞き出し、システムに求められる機能や使い勝手を抽出します。 ○円以内で、といった予算も要求の一部となります。

なお、ユーザーはITの専門家ではなく、またビジネスプロセスをすべて把握しているわけでもないので、単に話を鵜呑みにするのではなく、ベンダーからも質問を投げかけて真の要求を明確化していく作業が必要です。

機能要件を定義する

要求が明確になったら、それをシステムの具体的な機能として実現するために、機能要件として定義します。 ユーザーにヒアリングし、機能のヌケモレがないようにリストアップします。 合わせて、機能に紐づくデータの定義、機能間のデータ受け渡しのフローなどを、E-R図を作成し具体化します。

E-R図の例 出典: IPA 「ユーザのための要件定義ガイド」
https://www.ipa.go.jp/archive/publish/tn20191220.html

非機能要件を定義する

次に、非機能要件を定義します。 非機能要件は、システムが安定して動き続ける度合いである可用性や信頼性、エンジニアではない販売担当者でも簡単に操作できるユーザビリティなど、そのものが目的ではないですが、あると望ましいものです。 実際に現場でシステムを使うことになる利用者の声をもとに定義することが重要です。作成するシステムの画面 (UI) も基本仕様を定義します。

画面レイアウトの例 出典: IPA 「ユーザのための要件定義ガイド」
https://www.ipa.go.jp/archive/publish/tn20191220.html

予算・スケジュールを設定する

要件をもとに、システムの規模を見積もり、予算とスケジュールを検討します。ベンダーが主導し、ユーザーの要望を踏まえて策定します。 無理なスケジュールや不十分な予算は、プロジェクトの失敗と直結しています。ベンダーの経験や体系化された見積手法をもとに、適切に策定する必要があります。 他にも、ユーザーとベンダーの間のコミュニケーション (会議など) 方法や、考えられるリスクについての対処も検討しておきましょう。

要件定義書作成時のポイント

最後に、要件定義書を作成する際のポイントをまとめしょう。

発注側と開発側で認識をすり合わせる

プロジェクトは要件定義書をもとに進むと前述しました。 そのため、要件定義の段階でユーザーとベンダーの間に認識の齟齬があると、そのギャップを埋められないまま開発が進み、結果としてユーザーの期待に沿わないシステムができあがってしまいます。 そうならないように、要件定義のプロセスでは徹底的に議論し、双方がしっかりと納得した結果を要件定義書に記述する必要があります。

要件を順位づけする

要求・要件としてリストアップされたものについて、すべてに100%のリソースを割いて対応できないことも多くあります。 そこで、優先順位をつけて、優先度が高いものと低いものを整理することも重要です。 開発プロセスにおいて、どこまで要求・要件を実現するかを判断するために、あらかじめ優先度を検討しておきましょう。

専門用語の使用を控える

要件定義書は、ユーザー部門の非IT従業員や、経営層も参照することがあります。 要件定義書の内容が正しく伝わらないと、開発するシステムについての誤解を招き、そのギャップがリリース後も影響する場合があります。 そのため、IT業界あるいは特定のベンダーとの間でしか伝わらないような専門用語・業界用語の使用はできるだけ避け、平易な表現を心がけましょう。

まとめ

この記事では、ITシステムを開発する際に作成する要件定義書の書き方、作成作業の流れを紹介しました。
要件定義書とは、開発において、必要な機能、画面構成の使い勝手など、あらゆる仕様を取りまとめて文書化したもので、 想定していなかったトラブルを抑えスケジュール通りに進行するために重要な役割を持っています。 これからはじめて要件定義書の作成に取り組むという方はぜひ参考にしてください。

Share