要件定義の作り方について

システム開発（ソフトウェア開発）の上流工程である要件定義では、発注者が抱える課題に対して、業務の現状を把握し、課題や問題点について抽出しなければなりません。
要件定義で必要なのは、発注者との認識に齟齬がないかフローを確認し、要件を可視化し、優先順位を決めて整理することです。

システム発注者の要望や要求機能を明確にし、業務フローに落とし込みし、分析していくことが必要不可欠になっています。

この記事では、その要件定義をスムーズに進めていく上での手法や、最後に弊社サービス「要件定義代行」についてご紹介いたします。

要件定義を進めるための基礎を学ぶ

要件定義とは

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

要件定義とは何か、要件定義の進める上での注意点、重要なポイントについて以下のページよりご参照ください。

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

スムーズに行える要件定義の手法

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

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

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

要求定義書は、発注者が作成します。発注者が解決したいと考えている課題や、導入したいシステムについての要求をまとめた書類です。
要件定義書は、開発者が発注者の要求をもとに作成します。開発者の視点で要求や作業工程を決める要件定義に対して、要求定義は本来、発注者が作成するものです。発注者が書いた内容を参考に、開発者は要件定義に活かすことができます。
開発者は顧客からの要求を理解する上で、要求定義書を詳細に精査し要件定義を行っていきます。発注者が要求定義書を作成していない場合には、発注者に対し開発者がヒアリングを行い、要求を把握する必要があります。

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

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

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

要件定義の成果物

開発工程の成果物：要件定義書

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

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

概要で目的や目標を決める

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

業務要件で業務フローを作成

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

「業務フローの書き方ガイド」はダウンロードしましたか。
業務フローの書き方を参考にしたい方は無料でダウンロードが可能です。

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

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

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

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

業務要件

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

機能要件

システム要件でシステム化の方向性が決まると、システムに必要な機能について検討します。機能要件はシステム開発を通して最低限実現すべき機能です。
機能要件はヒアリングで発注者へ具体的に確認することができます。また、機能要件の成果物は、後述の非機能要件と合わせて、次工程の基本設計フェーズでの重要なインプットとなるでしょう。

画面要件
画面一覧：開発時の画面を一覧化したものです。

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

画面遷移図：画面の流れがわかります。
画面レイアウト：画面のイメージを共有するためのものです。

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

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

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

帳票概要：帳票の出力場所や、業務上の用途が分かります。

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

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

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

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

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

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

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

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

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

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

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

---

非機能要件

機能要件が発注者にとって必須の機能なのに対して、非機能要件は機能以外に「あればいいな」と考える要件です。非機能要件を実現していくことで発注者の満足を上げることができます。
例えば、システム画面の切り替え速度などの要件があげられます。非機能要件は予算や納期を意識しつつ、発注者と合意を図ることが重要です。

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

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

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

分かりやすい要件定義書には、実際にシステムを利用する発注者が理解しやすくなっている文章が記載されています。発注者はIT分野の専門知識に乏しいケースがほとんどです。
書面ではIT分野に関する専門用語や専門知識を極力使わないようにします。書面の内容を理解してもらえないと仕上がりイメージできず、発注者の不信感が高まってしまいます。
発注者の関係者が読んでも分かりやすい文章になっているか、気をつけて作成する必要があります。

課題にたいしての解決策

要件定義の最終目的は、発注者からの要求をまとめるだけではありません。
発注者が何を求めているかを見定めるのはもちろんのこと、その要求をどのようにして叶えるのかという「答え」にあたる文章を記載し、発注者に理解してもらうことです。

まとめ

要件定義をスムーズに進めていく上での手法や、わかりやすい要件定義書を作成するポイントをご紹介しました。
要件定義はシステム開発を始める段階で、発注者からヒアリングした必要な機能や要求をわかりやすくまとめていく作業が必要です。要求をもとに作成する要件定義書には、「システム開発に至った背景」や「システム開発の目的と目標」を記載します。
記載する目的は、システム開発によって、どのような効果や結果を求めているかどうかを明確化することです。

要件定義の成果物として、機能要件・非機能要件の違いを理解しておくことも必要です。機能要件は「発注者の目に触れる機能」であるのに対し、非機能要件は「システムの品質や性能」というシステムの裏側を決めるということです。分かりやすい要件定義書には、実際にシステムを利用する発注者や発注者側の関係者が理解しやすくなっている文章がほとんどです。

弊社は要件定義のスペシャリストとして、要件定義代行サービスを提供しています。

顧客の課題に沿ったヒアリング・調査から要件定義書作成します。QCDバランスを見ながらプロジェクトの要である要件定義を解決に導きます。（※お気軽にご相談ください）