# ソフトウェア開発の成功に欠かせない！要件定義書とは？
一般的には要件定義書とは、**発注者の要望とその要望を叶える具体的なプロセスを「文書」の形式でまとめたもの** です。 私たちがソフトウェアやシステム開発を行う目的は、クライアントや社内での要望・課題をソフトウェアやシステム開発を通して実現・解決することです。そのシステム開発の前段で「要件定義」をし、その内容を記した「要件定義書」を作成します。大規模開発においては特に必須のドキュメントです。

開発手法によってはいわゆる「要件定義書」を作成しない場合もあると思います。しかし、どんなプロジェクトでもそれに匹敵するようなアウトプットを作成する場合がほとんどだと思います。発注者にこれからどんな開発をしていくのか、要件定義段階で認識を合わせ、お互いの解像度を高める本質的な目的には変わりありません。 そこで、Jiteraがこのフェーズで提供する文書の例もご紹介します。

Jiteraが提供する要件定義フェーズのアウトプット 株式会社Jiteraでは、要件定義書に以下のファイルを含めることが大半です。

* 業務フロー図（要求整理に含まれる倍もあります）
* ユースケース
* デザインファイル（画面設計）
* 画面一覧
* 画面遷移図

!["ユースケース一覧"](https://corpsite-backend-staging-retool.s3.ap-northeast-1.amazonaws.com/%E3%83%A6%E3%83%BC%E3%82%B9%E3%82%B1%E3%83%BC%E3%82%B9.png "ユースケース一覧")

その他には、設計工程に近くなりますが、

* 辞書（用語定義）
* データ定義
* コーディングガイドライン
* セキュリティガイドライン
などを含めることもあります。 この場合は、設計フェーズなどで
* ER図作成
* 外部インターフェイス設計（API定義書）
* テストケース作成
* インフラ構成図
を作成しています。

## 要件定義書の目的
要件定義書の目的は、発注側の課題解決のためにそのプロジェクトの目的、それを踏まえて何のために何をどのように開発するのかを明確にすることです。これが、最終的な成果物への道標となります。加えて、このプロジェクトに関わるすべての人が読むことになります。したがって、非エンジニアの方でも理解できるよう、専門用語は多用せず、わかり易い言葉選びもポイントになります。

また、開発中に「仕様変更・機能追加」をよく耳にしますよね。 そんな時、お互いの合意のもとに作成された要件定義書があれば、プロジェクトに関わる全ての人が同じ方向を向くことができるため、方向性の大きく異なる仕様変更・機能追加を未然に防ぐこともできます。

「要件定義書」と似て非なるドキュメントもありますので、簡単に違いを記載します。

## 要件定義書と提案依頼書（RFP）、要求定義書、要求仕様書の違い
システム開発では、主に以下のような文書が発注側と開発側で交わされ、お互いの認識のすり合わせに使われます。

||作成者|目的・役割|
|:-|:-|:-|
|提案依頼書（RFP）|発注側|外部業者からの提案を求めるために作成する文書|
|要求仕様書 |発注側<br>（自社開発の場合・開発側が作成する場合も）|発注側の要望をシステムベースの要件や機能としてまとめた文書|
|要件定義書|開発側<br>（開発者自信が作成するの��一般的）|発注側と開発側の認識を合わせるための文書|
|要求定義書|発注側|発注者のシステムに組み込んで欲しい具体的な仕様や機能について記載する文書|

# 要件定義書の要件とは？
要件定義書の「要件」とは、発注側からの要求を実現するために、どのような仕様のどのような機能を開発すればいいかを技術的な視点で捉え直したもののことを言います。 発注者からの「要求」だけでは開発に進むことはできません。では、この「要求」をどのようにして「要件」に落とし込み、「要件定義書」としてアウトプットするのでしょうか？次は要件定義書作成の流れをみていきます。

# 要件定義書作成の基本的な流れと書き方
要件定義書作成の流れを紹介いたします。どんなプロジェクトでも同じような流れになります。

## 1. 要求のヒアリング（要求定義）
まずは、クライアントや社内のシステム発注者から要望を聞き出すためのヒアリングを行います。開発側は、発注者の抱える課題の潜在的なニーズも汲み取り、確認できるとベストです。以下を中心にヒアリングを進めましょう

* 現状と抱えている課題の確認
* システム開発の目的
* ソフトウェア・システム開発でどのように課題を解決したいのか
* 開発後のイメージ

わからないことは都度発注者に確認することで、認識の齟齬を最小限に抑えることができます。 初期段階の齟齬は、工程が進むにつれどんどん大きくなっていくものです。十分に注意が必要です。

## 2. ヒアリング内容を要件に落とし込む
1.で行ったヒアリングの内容を整理し、システム全体の構造から要件まで決めていきます。
* 現状と開発後の変化
* どのような課題をどのような機能で解決するのか

などにフォーカスして以下の要件をまとめてみましょう。

### 2-1. 業務要件をまとめる
業務要件では、今回のプロジェクトの目的・背景・狙いを記載したり、ビジネスプロセス図や業務プロセス（フロー）図などをフローチャートを用いて全体の構造を表現します。 発注者と認識のズレなどが生じないよう、しっかりと確認していきましょう。

Jiteraでは、ほとんどのお客様にはこの時点でワイヤーフレームの作成も行い、ソフトウェアの全体像がわかりやすいアウトプットを行っております。また、このフェーズでデザインを作成する場合もあります。

### 2-2. 機能要件をまとめる
機能要件とは、課題解決にあたって、どのような機能（開発）が必要になるのかを記載します。 一覧を作成したら、それらに必須要件と希望要件を分けたりするなど優先順位をつけていきます。この優先順位も発注側との認識のズレがないようにしっかりと合意を取りながら進めたい部分です。

### 2-3. 非機能要件をまとめる
非機能要件とは、先述の機能要件以外の内容を記載する項目です。例えば、性能・拡張性、運用・保守性、セキュリティ、システム環境・エコロジーの観点での要件をまとめたものです。

### 2-4. 工数見積・スケジュールを出す
これまでの要件を通して、成果物を納品するまでの工数・スケジュールを立てます。

## 3. 要件定義書を書く
ここで初めて「要件定義書」の材料を揃えることができました。この材料を章立てでまとめます。記事の最後にご紹介するサンプルもご参考ください。

## 要件定義書作成を終えたら
要件定義書を書き終えたら、発注者らと齟齬がないか綿密にチェックを行います。要件の抜け漏れや、認識の齟齬をなくすように、お互いに疑問に思ったことはその場で解決しましょう。時間の制約などもありますが、できる限りお互いの認識を合わせて、気持ちよく開発に入りましょう。

# より良い要件定義書のために気をつけたいポイント

## 要件定義書の構成
構成に関しては、ポイントをカテゴリごとにまとめて、章立てで記載するのが一般的です。章立てで作成することによって、どこに何の情報が書いてあるのかがわかります。目次も忘れずに作成しましょう。 記事の最後にサンプルがあるので、こちらもご参考になさってください。

## 非エンジニアもいる！平易な文章を心がけて
プロジェクトに参加しているメンバーは、開発に明るい方ばかりではありません。そういった方でも、要件定義書を読んで今後のプロジェクトの展開を意識してもらえるようにしましょう。

## わかりやすさが一番！図を適切に使用する
様々な要件を文章で表現することも大切ですが限界があります。そんなときは、図解することも検討してみましょう。文章よりも図の方が把握し易い場合もあります。 例えば、画面内の機能を要件定義で文字で記述することが一般的です。しかし、そういったものは図を添えられると発注者もイメージがつきやすいでしょう。

!["業務フロー図"](https://corpsite-backend-staging-retool.s3.ap-northeast-1.amazonaws.com/%E6%A5%AD%E5%8B%99%E3%83%95%E3%83%AD%E3%83%BC.png "業務フロー図")

## 打合せには適宜ステークホルダーにも参加してもらう
システム、ソフトウェア開発において、時間の制約がないプロジェクトは殆どありません。重要な意思決定を都度持ち帰って承認を…となると、時間が余計にかかってしまいます。 意思決定が必要になりそうな打合せには、予め意思決定者に同席してもらいましょう。 Jitera では、週に2-3回、1回1-2時間でお客様とお話しする機会を設けています。ほとんどがオンラインでの開催になりますが、たまにオフラインで開催するとお客さまとの距離も一段と縮まり、その後の顧客関係にも良い影響があります。

# 要件定義書の必要項目は？Jiteraの要件定義書サンプル
先述の要件定義書作成の基本的な流れでご紹介した内容をこちらのテンプレートにまとめてみました。ぜひご活用ください。
[Jiteraの要件定義書構成サンプル{: .btn .btn--primary}](https://iruuzainc.notion.site/a97f7c14589c4e999fae112c2b78bf2b?pvs=4)

## 要件定義書は誰が作るのか？
要件定義書は概ね開発側が作成することが多いです。理由は、発注者は必ずしも開発に十分明るいわけではないからです。
開発側でも、開発自体に深い理解のある人が対応することがほとんどです。例えば、エンジニア経験があったり、開発の理解があるPMやシステムエンジニアが要件定義書を作成します。

## 要件定義を適切に行うために必要なスキル

### コミュニケーション能力
発注者から要件を引き出し、またシステム開発観点で潜在的な問題やニーズを引き出すことも時には求められます。また、非エンジニアの方に、わかりやすく技術的な話をする機会も多くなります。不明点をなるべく少なく、解像度の高い要件定義書を作成・合意形成するためにはコミュニケーション能力は不可欠です。

### システムの全体像や成果物をイメージできる能力
要件定義書を作成していく上で、システム全体のイメージができていると、「できる・できない」「時間がかかる・かからない」の判断も迅速に行うことが出来ます。それによって、合意の形成も時間をかけずに済みますし、理由も説明できるので発注者側の理解も同時に得られます。

### 納品までの工数・スケジュール算出能力
各要件を洗い出し、それらに必要な工数とリソースの見積もりが必要になってきます。この見積もりの集大成がスケジュールとなり、納期を決定できますし、費用や予算も算出できます。これらの見積もり能力も重要になってきます。

## システムエンジニアの役割
先述したように、システムエンジニアは発注者とプログラマーとのパイプ役となっていることがわかります。これは非常に重要な役割です。また、開発全体のスケジュール管理も担うことも多いと思いますので、常にプロジェクト全体を見渡しつつ、実装作業の進捗にも気を配る必要があります。

# 要件定義書はソフトウエア開発の大きな道標
要件定義書は、発注者と開発側の合意文書です。なにかあった時には、要件定義書に立ち返って検討します。要件定義をしっかり行って、システム・ソフトウェア開発を成功に導きましょう！

サムネイル画像: [Image by pikisuperstar](https://www.freepik.com/free-vector/flat-hand-drawn-web-developers-illustration_12296222.htm#query=illustrate%20software%20development&position=10&from_view=search&track=ais) on Freepik