良い要件定義書を書くには？重要ポイント・コツを伝授

システム開発（ソフトウェア開発）の上流工程でおこなう「要件定義」。
この工程では、発注者の抱える業務課題について開発者が現状を正しく把握し、課題や問題点をもれなく抽出できていなければなりません。
では、具体的にどのような要件定義書を作れば、要件定義を成功させることができるのでしょうか？

本記事では、要件定義をスムーズに進めるためのコツから、「良い要件定義書」を書くための重要ポイントまで徹底解説いたします。

要件定義をおさらい

要件定義とは

要件定義とは、システム開発の初期段階で、必要な機能や業務要件をわかりやすくまとめていく作業です。
プロジェクトの進行とともに要件定義を見返すことも多く、プロジェクトの脱線を防止する役割も果たします。

「要件定義」とはどんなものか？基本的な解説については、以下エントリを参照ください。

プロジェクトの要である要件定義とは

要件定義をスムーズに進める３つのコツ

「要件定義は難易度が高い」と言われる理由として、成果物となる「要件定義書」に書くべき内容がはっきりと定義されておらず、プロジェクトによって差異がある、というのがあります。（「要件定義書」については後項で解説します。）

QualityCubeではこれまでのご支援経験から、以下の３つを「要件定義をスムーズに進めるためのコツ」と考えました。

• 既存の業務フローとシステムについて知る
• 要求定義書と要件定義書のすり合わせをする
• 開発担当者を明確にしておく

既存の業務フローとシステムについて知る

発注者の要望は実に様々ですが、システムや業務フローに課題があり、直面している問題を解決したいという要求は少なくありません。
したがって要件定義段階でまず必要になるのは、現在用いられているフローや既に使われているシステムを正しく理解することです。そのうえでどこに課題があり、どのように解決するべきかを明確にします。
なかには、現行システムの設計書通りに業務を行っていないケースもあるので特に注意が必要です。

要求定義書と要件定義書のすり合わせをする

システム開発において、発注者が作成するドキュメント書類を「要求定義書」、この発注者の要求をもとに開発者が作成する書類を「要件定義書」と呼びます。
要求定義書では、発注者が解決したいと考えている課題や、導入したいシステムについての要求をまとめるのに対して、要件定義書では開発者の視点で要件や作業工程を決めていきます。
発注者の描いた夢をもとに、開発者が理想となるシステムの姿を整理していくのです。

しかしながら、プロジェクトによっては発注者が要求定義書を作成していないケースもあり、その場合、発注者に対して開発者がヒアリングを行うことで要求を把握する必要があるので、注意が必要です。

こうして要件定義書が完成したら、漏れがないか発注者と開発担当者とで認識合わせをすることが重要です。
一般的なウォーターフォール型開発では、手戻りが重大なタイムロスになりますから、要件定義の段階でしっかりと作り込みを行うことで手戻りを防いでいきます。

開発担当者を明確にしておく

プロジェクトの開発担当者を明確に決めておくことも重要です。
他のプロジェクトと兼務の開発者は、当プロジェクトにどのくらいの工数を割けるか、明確にしておきます。曖昧なままにしておくと、後々コミュニケーションのすれ違いが増えていく可能性があります。ムダな調整が増えると、本来するべき業務の進行に支障が出る可能性があります。
したがってこの段階で役割分担を明確にしておき、開発担当者が不明確なままの業務をなくします。
開発固定のタスクに関して開発担当者と責任分担が適切に決まっていれば、不要な業務で工数を圧迫する恐れもなくなります。
そのためには、WBS（Work Breakdown Structure：作業分解構成図）を作成し、誰がいつまでに、何を完成させるかを明確にしましょう。

上記の３つをしっかりと守れているかどうかが、要件定義の成否を分けると言っても過言ではありません。
貴社の要件定義はどうでしょうか？照らし合わせてみてください。

要件定義の成果物：「要件定義書」

ここでは、前項で触れた「要件定義書」について解説していきます。
冒頭でご紹介した別エントリでも述べていますが、改めて「要件定義書」とは、要件定義において成果物とされるドキュメント書類の名称です。
前項で「書くべき内容がはっきりと定義されておらず、プロジェクトによって差異がある」ことが難しいと言われる理由と述べましたが、QualityCubeが「要件定義書に書くことが望ましい項目（中身）」として挙げているのは、主に以下の通りです。

要件定義の成果物	成果物の中身	概要
要件定義書	システム概要	どのようなシステムを開発するか？
	全体図	ソフトウェア・ハードウェアで構成させる全体の構成図
	業務要件	要求一覧、As-Is（現状）To-Be（新規）業務フロー/業務一覧
	システム要件・納品対象	システム化対象を明文化した文書、納品書一覧など
	機能要件	画面・帳票・バッチ・データ・外部インターフェース要件など
	非機能要件	可用性、性能・拡張性、運用・保守性、移行性、セキュリティなど
	総合・受け入れテスト設計図	テスト計画書・仕様書・設計書など
	WBS	システム開発プロジェクトの開発工程構成図

要件定義書に記載すべき必須項目

またその中でも、とりわけ必ず記載すべき「必須項目」と言えるものは次の4項目です。

• システム概要：目的や目標を決める
• 業務要件：業務フローを作成する
• 機能要件：必要となる機能を決める
• 非機能要件：システムの裏側を決める

システム概要：目的や目標を決める

システム概要には、「システム開発に至った背景」や「システム開発の目的と目標」の記載が必須です。
目的は、「システム開発によってどのような効果や結果を求めるか」という内容。
目標は、それが「どのような結果になったとき達成されたといえるか」を定義する指標です。
定量的なゴールを定めておくことで、発注者とシステム開発者、また関係者全員の認識に齟齬が発生しないようにしておくことが大事です。

業務要件：業務フローを作成する

システム開発の目的と目標を達成するには、実際の業務はどうあるべきかを考えます。
業務の流れを文書で書くと非常に分かりづらいため、ここでは「業務フロー」を作るのがよいでしょう。
まずは「現状の業務フロー（As-Is）」を作成してから、「システム稼働後の業務フロー（To-Be）」を作れば、システム稼働前・稼働後のフローが明確になります。

機能要件：必要な機能を決める

業務要件で決めた「何をどのように使うのか」ということに対して、「システムがどのような情報を管理したり処理したりすればよいか」を規定するのが機能要件です。
機能要件でありがちな失敗として、「開発者だけで決める方式をとってしまうこと」が挙げられます。
忘れてはいけないのが、発注者の要求こそが開発の大前提であるという点です。
システム課題はもちろん重要ですが、それだけを優先するのではなく、「発注者が実際にどう使うのか」を確認しながら、使いやすさ、必要な機能が備わっているか、を十分検討してください。

非機能要件：システムの裏側を決める

機能要件が「発注者の目に触れる機能」であるのに対し、非機能要件はシステムの品質や性能という「システムの裏側を決めること」です。
どのシステム開発でも、非機能要件で検討すべき内容は同じである場合が多いです。
ここはすでにあるフォーマットを使うことで、資料作成や事項の抽出にかかるコストを削減しましょう。

では、この必須項目のうち「業務要件」「機能要件」「非機能要件」の具体的な洗い出し方法について、さらに詳しく見ていきましょう。

業務要件

業務要件は、要件定義の初期に分析します。
システム化に先立ち、現状の業務がどのように流れているかを分析し問題を抽出した上で、新たに何を実現すべきかを決めていきます。この段階ではシステムはあまり意識せず、あくまで「業務そのもの」に焦点を当てます。
業務要件では、業務に詳しい発注側の関係者に参加してもらい、高いコミュニケーションを図ることが必要です。ここで発注者と開発者間で目的が噛み合わないままスタートしてしまうと、大幅な手戻りが発生して時間とコストの浪費につながるため、丁寧なヒアリングを行うことが肝となります。

業務フローの作成には、弊社がお役立ち資料として無料公開している「業務フローの書き方ガイド」を、ぜひ参考にしてください。

機能要件

システム要件でシステム化の方向性が決まると、システムに必要な機能について検討します。
機能要件とは、システム開発を通して最低限実現すべき機能のことを指し、発注者へのヒアリングを実施することで具体的に固めていきます。
機能要件で洗い出した成果物は、後述の非機能要件と合わせて、次工程の基本設計フェーズでの重要なインプットとなります。
機能要件の主な内容としては以下の5つがあります。（ちなみにこれは、基本設計の際に必要な情報となってきます。）

①画面要件

・画面一覧：開発時の画面を一覧化したもの

出典：IPA機能要件の合意形成ガイド画面編　P17 　

・画面遷移図：画面の流れをあらわしたもの
・画面レイアウト：画面のイメージを共有するためのもの

出典：IPA　工程成果物間の関連　P15

②帳票

・帳票一覧：開発する帳票を一覧化したもの

出典：IPA　工程成果物間の関連　P15 　

・帳票概要：帳票の出力場所や、業務上の用途を記したもの

出典：IPA　工程成果物間の関連P15

・帳票レイアウト：帳票の具体的なイメージを明確にするもの

出典：IPA　工程成果物間の関連　P15 　

③バッチ

・バッチ処理一覧：プロジェクトで開発するバッチ機能を一覧にまとめたもの

出典：IPA　工程成果物間の関連　P15

④データ

・外部システム関連図：関連システムとのデータ連携を図解したもの
　（システム開発の対象となる部分を色分けし、どのシステムに影響を及ぼす可能性があるのか整理する）

出典：IPA　工程成果物間の関連　P15 　

⑤外部インターフェース要件

・外部インターフェース一覧：関連システムとのデータ連携を一覧にまとめたもの

出典：IPA　工程成果物間の関連　P15

外部インターフェース定義書：関連システムとのデータのやりとりについて、主要なデータ項目を一覧にまとめたもの

出典：IPA　工程成果物間の関連　P15

---

非機能要件

機能要件が発注者にとって必須の機能であることに対して、非機能要件は、機能以外に「あればいいな」と考える要件です。一見必要ではないように見えますが、非機能要件を実現していくことで、発注者の満足を上げることができます。システム画面の切り替え速度などは、よくある例です。

非機能要件の決定は、予算や納期を意識しつつ、発注者と合意を図ることが重要となってきます。発注者の要望を文字通りに捉えるのではなく、ヒアリングによって「なぜそれを要求するのか？」までを引き出すことで、潜在的な要求に気づくことができ、より質の高い成果物のアウトプットにつながります。
IPAの非機能要求グレードに示された６つの特性をもとに、運用方法を検討しましょう。

出典：IPA　非機能要求グレードご紹介　P6

良い要件定義書の必須条件

ここまで、要件定義書に記載すべき項目について具体的に見てきました。
最後に、「良い要件定義書」とはどういうものを指すのか？要件定義を行うにあたって、QualityCubeが考える大事な条件は以下の2つです。
作成した要件定義書が以下の条件に当てはまるかどうか、ぜひ照らし合わせてください。

条件①専門知識がなくても内容が分かる

発注者はIT分野の専門知識に乏しいケースがほとんどです。
そのため、実際にシステムを利用する発注者が理解できる文章で記載されていることは非常に重要です。
書面では、IT分野に関する専門用語や専門知識を極力使わないことを心がけましょう。いくら素晴らしい内容であっても、書面の内容を理解してもらえないことには発注者側で仕上がりがイメージできず、かえって不信感を招いてしまうこともあります。
発注者のみならず、発注者の関係者が読んでも分かりやすい文章になっているか？までを意識するようにしましょう。

条件②課題に対する解決策になっている

要件定義の最終目的は、発注者からの要求をまとめるだけではありません。
発注者が何を求めているかを見定めるのはもちろんのこと、その要求をどのようにして叶えるのかという「答え」＝「課題解決策」にあたる文章を記載し、発注者に理解してもらうことが重要です。
発注者の課題を解決できていない開発は成功とはいえません。
検収時のクレームやムダなコスト増を防ぐため、この「答え」を提案することこそが求められます。

まとめ

本記事では、要件定義をスムーズに進めるための手法や、要件定義書を作成する上でのポイントをご紹介しました。まとめると以下の通りです。

要件定義をスムーズに進めるには？
発注者からヒアリングした内容をもとに、業務フロー・システムフローを把握した上で、必要な機能や非機能をわかりやすくまとめ、発注者・開発者間で認識に齟齬がないかしっかりすり合わせをしましょう。

要件定義書を作成する上でのポイントは？
発注者の要求をもとに「システム開発に至った背景」や「システム開発の目的と目標」を明確化し、そこから業務要件、機能要件、非機能要件を洗い出していきます。
要件定義書を作成する際には、実際にシステムを利用する発注者や発注者の関係者が理解しやすい文章で書くこと、発注者の要求を満たし、課題を解決するための要件定義であることを忘れないようにしましょう。

「要件定義代行サービス」のご紹介

要件定義をうまく進め、良い要件定義書を作成するためにおさえておくべき事項は多岐にわたります。
弊社、株式会社QualityCubeでは、要件定義のスペシャリストとして「要件定義代行サービス」を提供しています。

多くの企業様をご支援してきたプロのコンサルタントが、顧客の課題に沿ったヒアリング・調査から要件定義書の作成を代行させていただくことで、QCDバランスを見ながら、プロジェクトの要である要件定義を解決に導きます。ぜひお気軽にお問い合わせください。