要件定義とは？作成手順や前後の流れをわかりやすく解説！

システム開発における要件定義とは、システム化計画や提案依頼書(以下RFP)に記載された要求事項をベースに、「機能要件」(どのような機能を作るか)や「非機能要件」(どのように動くシステムを作るか、および運用や保守に関する条件や作業内容など)を関係者間(特に発注側と開発側)で合意し、その内容を文書化する作業のことをいいます。

ウォータフォール型のシステム開発では、要件定義は下図に表したように、上流工程(プロジェクトの初期工程)の中心的作業で、その成果はプロジェクト全体の「品質(Q)、コスト(C)、納期(D)」を大きく左右します。ITシステム開発失敗原因の多くは要件定義に起因するともいわれています。

一方、アジャイル開発では、初期段階ではユーザーストーリーのような関係者の意識を合わせるためのカジュアルな形でまとめ、開発・検証・改良を繰り返しながら徐々に詳細化していく手法が取られます。

要件定義のクオリティを上げるコツとして、Testable(テストできる)を意識するということがあります。テスト技法を学ぶことは、要件定義のクオリティアップにもつながります。

要件は細かく分けると下の3つがあります。

基本的には左から右に進みますが、ソフトウェア要件定義の結果によって、業務要件(利害関係者要件)にもどり修正する必要がある場合もあります。
また、実際の案件では、業務要件(利害関係者要件)とシステム要件をまとめて整理する、システム要件とソフトウェア要件をまとめて整理するなど、さまざまな対応が行われます。

簡単にいうと、要件定義は何を作るかを決める作業であり、設計はどうやって作るかを決める作業です。
システム要件にもとづいて、手作業、サービス、ハードウェア、ソフトウェアの、どの要素で要件を実現するのかといった基本的な構成(機能分割)を考えるのがシステム設計です。

ソフトウェア設計では、ソフトウェアコンポーネントの構造や各コンポーネント内のソフトウェアユニットの構造を考え、段階的に分割して文書化します。
設計工程は、一般的に基本設計(外部設計)と詳細設計(内部設計)に分けられることもあります。

基本設計の成果物としては機能一覧、論理データモデル、外部インターフェース設計書、画面レイアウト図、システム構成図などがあります。
詳細設計は内部構造に関する設計で、コーディング(実装)のインプットになります。成果物としては、ソフトウェアモジュール(ユニット)構成図、クラス図、シーケンス図、物理データモデルなどがあります。

設計手法としては、構造化設計、データ中心アプローチ、オブジェクト指向アプローチ、ユースケース駆動開発、などさまざまなものがありますので、設計を担当するシステムアーキテクトは、対象システムの特性や開発条件などに合ったものを選んで使います。

要求と要件は基本的には同じものです。
国際規格(ISO29148(JISX0166)など)や海外の文献では”Requirements” (JISでは「要求」と翻訳)という言葉しかありませんので、日本以外の国では要求と要件を使い分ける習慣はあまりないと思います。

ところが日本では、要求を「ユーザー側(発注側)が提示したシステム化要求」、要件を「ユーザー側(発注側)と開発側(受注側)が合意した(システム開発契約の条件となる)システム化要求」と区別するのが一般的です。

これは海外ではシステム開発の内製率が高く、外部に発注する場合もTime and Material契約(日本の準委任契約に近い形態 )になるのに対して、日本では外注率が非常に高く、外注契約では金額やスケジュールを決めてから契約する一括請負型(開発手法はウォータフォール型)が多かったことに起因すると思われます。

要求と要件は内容的にはシステム化要求を明確に表すことを目的としており、詳細度・正確度・網羅度・曖昧度などに、差があってよいわけではありません。しかし、日本のシステム開発では上記の開発契約形態の関係から、要求は大まかな内容で、要件はより具体的で厳密な内容になっていることが多いのが実情です。

日本でも採用が進んでいるアジャイル開発では、発注者と受注者は責任を共有して作業を進めますし、外注する場合の契約も海外のTime and Materialに近いものになることが多いと思いますので、要求と要件を使い分ける習慣は消えていくかもしれません。

(本稿では、規格では「要求」となっているものも便宜上「要件」に置き換えている場合がありますのでご了承ください)

ここからはウォータフォール型システム開発における、業務要件定義(利害関係者要件定義)を開発側(受注者側)の立場で行う場合を例に見ていきます。
作業の順番は、一般的なものです。案件によっては順番を変える、一部の手順を省略する、別の手順を追加する、こともありますのでご注意ください。

ユーザー側(発注側)の利害関係者は多岐にわたります。
だれかの要望を聞いていなかったり(要件の抜け、漏れ)、一部の声の大きな人の意見を過度に反映していたりすると後になって不満が噴出し、要件定義のやり直しや最悪は開発のやり直しが必要になります。
そのためまずはだれが利害関係者なのかを漏れなく洗い出すことが必要です。
その際は、各関係者の特性や影響度、関係者間の関係などについても調べておきます。

＜関係者と特性の例＞
・経営者：ビジネス改革に意欲的で、ビジネスの方向性も明確。ただしシステムに対する要件は具体的ではない。
・業務部門(実際にシステムを使う人たち)：具体的な要件はあるが、事務作業の効率化に関する内容に偏りがち。その内容は開発コスト度外視であったり、経営者の方針と一致していなかったりすることもある。
・情報システム部門：細かい機能改善要件を数多くかかえていることがある。経営者や業務部門と要件の優先順位が合っていないこともある。

ビジネス目標とは、そのシステムを導入すること(手段)で、ビジネスプロセスやビジネスをどう改革するか決めたものです。
現在は、ビジネス改革につながらないシステムや、経営に貢献しないシステムはそもそも開発が認められないことが多いので、ほとんどのシステム開発には本質的なビジネス目標があるはずです。

しかしビジネス目標は、ユーザー側(発注側)にとっては当たり前すぎる内容で開発側(受注側)に提示する資料には詳しく書かれていなかったり、書かれていてもビジネスドメインやユーザー側の個別事情に関する知識がないと理解できなかったりします。

開発プロジェクトが始まり現場部門の要件を聞く際に、システム化の目的を単なる自動化や手作業の削減などに矮小化して捉えたり、システムの導入そのものを目標(目的)だと錯覚したりすることがあります。しかし、それでは要件の本質を見誤ったり、要件を絞り込む際の優先順位を誤ったりする可能性がありますので注意が必要です。

開発側においても、システム機能要件中心指向からビジネス要求中心指向への変革が求められています。

RFPや関連ドキュメントがあれば、まずはその内容をしっかり確認します。
その上で、利害関係者からもあらためてシステムに対する期待や要望を聞きます。

その結果、利害関係者の間で要件の内容やレベル感が大きく異なることがあります。

その場合は各関係者と調整して要件をまとめる(落としどころを探る)必要がありますが、ソフトシステムズ方法論では、コンセンサス(完全な合意)ではなく、アコモデーション(異なる価値観を認めつつ、緩やかに合意する)を目指すという考え方を採用します。

非機能要件には幅広い内容が含まれます。

情報システム部門と詰めていく内容が多いと思いますが、使用性(ユーザビリティ)やサービス提供条件など、業務部門(ユーザー)など他の利害関係者と調整が必要な場合があります。

＜非機能要件の主な項目＞
・品質要件(機能性、信頼性、使用性、効率性、保守性、移植性)
・利用者視点の品質要件(有効性、効率性、満足性、リスク回避性、利用状況網羅性)
・技術要件(システムの実現方法、システム構成、システム開発方式、開発基準、標準、開発環境)
・運用／操作要件(システム運用手順、システム運用形態、運用スケジュール、システム監視方法、監視基準、サービス提供条件、災害対策、業務継続策(コンティンジェンシープラン)、データの保存周期・量、エンドユーザー操作方法)
・移行要件

初期要件を抽出し終えたら、要件の絞り込みを行います。
判断基準には次のようにさまざまなものがあります。

＜要件を絞り込む際の判断基準例＞
・ビジネス価値
・法令対応
・コスト
・リスク
・依存性
・安定性など

要件の絞り込みはこれらを総合的に勘案して行いますが、たとえばビジネス価値が低い要件については思い切って削減を提案することも必要です。
残った要件については、ビジネス価値や経営貢献度などを総合的に評価して、優先度をつけておきます。

制約条件とは予算、納期、契約事項などです。最終的にはこの制約によって取り込める要件の範囲や内容が決まります。
最初からこれを持ち出して要件の絞り込みを行う場合もありますが、私たちが個人的な買い物をする場合でも、予算などにはある程度柔軟性がありますので、まずはやりたいこと、やるべきことを整理して、最終局面で制約条件との整合性を考えるのがよいと思います。

前提条件とは、開発作業を行ううえで、開発側(受注側)がユーザー側などから提供を受けられることを前提にしている内容です。
たとえばユーザー側の関係者が成果物のレビューにどの程度の時間を割けるか、受入テストは何名でおこなってくれるかなどの内容です。
逆に、ユーザー側が考えている前提条件(開発側はこのように作業を進めてくれるはず、など)もあります。

一般的に前提条件は、自分に都合のよい内容になりますので、その前提が満たされるかどうかも要件定義の段階で確認しておく必要があります。その内容は、制約条件の一部となり要件の内容や範囲を制約します。

要件定義書は、ユーザー側の利害関係者にレビューしてもらい承認してもらう必要がありますので、利害関係者にとって必要な情報を網羅するとともに、ユーザー側も開発側も理解しやすい形で文書化します。

開発側が理解しやすくすることに関して、ひとつ重要なポイントがあります。
それは現行システムと同じ仕様だとしても、その内容も漏らさず書いておくということです。「現行仕様通り」などという表現は一切使わないようにしましょう。

文章表現が中心になりますが、文章だけでは説明しにくい(わかりにくい)ところは、モデル化技法や図表表現も使います。

＜よく使われるモデル化技法や図表＞
・業務フロー図(BPMNなど)
・データモデル図(ER図)
・エンティティ機能関連マトリックス(CRUD図)

利害関係者のレビューで、修正が必要な個所が見つかれば要件定義書を修正して再度ユーザーレビューをしてもらい承認を取ります。

要件定義の問題としてよく出てくるものに、「抜け」、「漏れ」、「あいまい」があります。
これらをなくすコツは、テストができるように要件を書くことです。 

たとえば料金計算の要件で、「学生には学割を適用する」とだけ書かれていた場合、学生以外はどうなるのかがわからないとテストができませんので、それも要件として明文化しておく必要があります。テスト技法を学ぶと、その勘所がわかります。

アジャイル開発のユーザーストーリーでは、注意することの頭文字をとってINVESTを意識して書くというのがあります。最後のTはTestable(テストできる)を表します。

＜ユーザーストーリーを書くときのINVEST＞
　I：Independent(独立して優先順位が付けられる)
　N：Negotiable(何をつくるのかの案が調整可能である)
　V：Valuable(価値がある)
　E：Estimable(見積もり可能である)
　S：Small(チームで扱いやすい手ごろなサイズである)
　T：Testable(テストできる)

最後に要件定義の重要ポイントをおさらいしておきます。

・現在の要件定義は、ビジネス要求中心指向で行う必要がある
・要件定義書はユーザー側、開発側双方が理解しやすい形で作成する
・「抜け、漏れ、あいまい」を回避するには、テスト技法の活用が有効

ヒン大ではこれに関連した講座を実施しております。
興味をもっていただけましたら、ぜひご参加をご検討ください。