要件定義の進め方と成果物の解説

要件定義では企画プロセスの内容をインプットして、「何を作るのか」を決めるフェーズです。
また、関係者からヒアリングをして求められる条件（要件）を整理して、目的や機能や性能の要件を整理します。
本書は要件定義の進め方、要件を整理して成果物にまとめる方法を説明します。

要件定義の目的

要件定義は、クライアント（ユーザ）の要望に対して、どのように実現するのかを決めることです。

システム開発のスタート時点では、何もかもがぼんやりしていることが多いです。
要件定義でシステムやプロジェクトの目的、範囲、機能、性能などを明確にし、関係者間で共通の理解を持つことです。

要件定義は、家のオーダーメイドは IT システム開発の要件定義と似ています。
「どんな家にしたい？」というぼんやりした話を、要件にまで落とし込む流れです。

要件定義のゴール

要件定義フェーズでは、次のことが満たされ、次工程である設計に進むことができる状態になれば、ゴールにたどり着いたと言えます。

必要な機能（非機能も含む）が明確になっている。
関係者全員(ステークホルダー)との合意を得ている。

要件定義の進め方

要件定義の進め方は、会社ごとに違ったり、何を開発するかによって異なるので、決まった手順というのがありません。
本書はIPAから出ている要件定義の進め方や共通フレームを参考に、以下の４ステップで説明します。

ステークホルダーの把握
目的とステークホルダーの可視化
ビジネス(業務)要件定義
システム要件定義

① ステークホルダーの把握

ステークホルダー（開発するシステムに関わる人）を把握します。
本作業の目的は、要件定義をするにあたり、ヒアリング先、要件定義書などのレビュー先を把握するためです。
ステークホルダーは、システムに影響を与える他の部署、さらにシステムを使用する外部の顧客や関係者も含まれます。

ステークホルダとの課題抽出や合意形成などを効率的に実施していくために、担当者レベルまで整理した、ステークホルダー一覧の作成も必要です。

②目的とステークホルダーの可視化：システムコンテキストモデル

システムコンテキストモデルは、システムの目的、ステークホルダー、システムの外部との関係を可視化するモデルです。
システムがどのような環境で機能するのかが一目で理解できるため、後の要件定義や設計、テストに役立つので、作成しておいたほうが良いです。

※本モデルは、神崎善司さんが考案した要件定義手法です。

③ ビジネス(業務)要件定義

ビジネス要件定義は現状把握からスタートします。
今、何が問題になっていて、どうあるべきなのかを整理します。
さらにそこから要求内容・目標レベルにします。

問題(ニーズ)の抽出
経営層や業務担当者から、現在の業務で問題になっている点やニーズをヒアリング
問題(ニーズ)から課題を抽出
問題(ニーズ)をもとに、何をすべきかを導く
目的(要求)と目標を導く
「～したい」と具体的な数値を導く

■「家計の問題」を例にした「問題(ニーズ)→課題→目的(要求)」を導く例

これらの整理の仕方については、いくつかやり方がありますが、いくつか紹介をします。

ビジネス要件定義は、最後に目標を導き、業務のあるべき姿(To-Be)を完成させますが、最初に出た問題や課題と紐づけできるようにします。
これをしないと、後で目標やTo-Beの形について「あれ？これってなんで必要なんだっけ？」や「ここの業務フローは何でこうなっているんだっけ？」となり、本来の課題解決の要素が失われてしまう可能性があります。

ビジネス要件定義：リッチピクチャによる整理

ヒアリングで集めた意見はリッチピクチャというモデルで整理して、関連や対立意見が見えるようにすると、今後のシステム開発のヒントになります。

ヒアリングした結果や既存の資料などを用いてフロー図を作成します。

ビジネス要件定義：業務フロー(As-Is)の作成、要求や課題を整理

現在の業務の内容を業務フローとして作成します。
もともと業務フローの資料がある場合もありますが、無い場合は業務担当者からヒアリングしながら作成します。
業務内容をヒアリングしていると、現在の課題やシステム化したい点などの要望が発言される場合もあるので、業務フロー作成時にメモとして残すのが良いです。

現行業務やシステムを理解する際、システムの仕様書や設計書が無かったり、知っている人がいなかったりして、正確な現状把握ができない場合があります。
その場合は現行システムの資料をかき集めたり、プログラムからリバースエンジニアリングしたり、関係者(業務担当者や過去に携わっていた人など)、社内規程から導くしかありません。
これには多くの時間を要します。

フローに書き表せない条件は「業務処理定義」を用意

条件によって業務内容が違う場合には業務処理定義書を作成して整理しておくと良いです。
業務フローを作成する際、条件が複雑で書ききれない場合にも有効です。

ビジネス要件定義：業務フロー(To-Be)の作成（あるべき姿の作成）

あるべき姿（理想）の業務フローを作成します。
まずは案という内容で作成し、関係する業務部門に説明しながらブラッシュアップしていきます。

業務フローを作成するとき、ゴール（時系列の最後）から逆算して書くのがポイントです。
こうすることで、「この成果物を作るには何が必要？」、「そのためにはどんな入力が必要？」と自然に階層的に分解できます。

④ システム要件定義

前の章ビジネス要件定義は、業務部門が主体で進めていましたが、ここから説明するシステム要件定義は、システムの担当者（社内のシステムエンジニアや外部のコンサル業者など）が主体で進めるのが一般的です。

システム要件定義：システム化する業務の一覧（機能一覧）

要件に対する必要な機能を一覧にします。

機能一覧は、前の工程で出た要望や要求に対する手段や機能が書かれているかを確認し、漏れの無いように書きます。
ここで漏れがあると、要件定義後の設計、システム開発へとそのまま進んでしまい、テストや運用開始後に気が付くとなるれば大変なことになります。

システム要件定義：システム化業務フロー(To-Be)

新しい業務プロセスとそれを実現するために必要になるシステム機能を対応付けます。
ここでどの範囲をシステムが担うのかを明確にします。

業務フローを描く際は、アクティビティ図を活用するのもよいです。
アクティビティ図は、業務フローを記述する際に使用する処理の分岐や並行処理、処理の同期などを表現でき、実体の制御の流れを描写します。

システム要件定義：データの概念モデル

エンティティを洗い出し、エンティティ間の関係を表現します。

システム要件定義：必要なUIやUI標準

要件定義ではUI（画面や帳票）についての細かい話はしませんが、次の内容を決めておく必要があります。

共通ルール
必要な画面や帳票
画面や帳票の利用者

システム要件：非機能要件

非機能要件は、可用性、性能・拡張性、運用・保守性、移行性、セキュリティ、システム環境・エコロジー、ユーザビリティの6 領域について決めていきます。
IPA が公開している非機能要求グレードの活用を検討するとよいです。

項目	説明（主な内容や例）
可用性	・稼働率（年や月あたり99.9%など）
性能・拡張性	・利用者数やデータ量と、それに対する画面やバッチ処理のレスポンス・拡張性の例：10年後のデータ量増加を見越し、容量と性能を拡張できること
運用・保守性	・障害発生に備えたシステム監視や運用・サポート体制（例：24時間365日の運用体制など）
移行性	・既存のシステムからどのデータ移行が必要か
セキュリティ	・アクセス権・データの保護（暗号化要否など）
システム環境・エコロジー	・システム環境、設備規格
ユーザビリティ	・例：マニュアルを見れば誰でも操作できるようにする