WEB開発やシステム開発は、「要求」を分析する要件定義から始まります。
その情報を書類にまとめたのが、要件定義書となります。
英語では、Requirement（要件）Definition（定義） Document（書）となり、RDDと呼ばれます。
要件定義書の作成を方法を解説します。
要件定義書の役割
要件定義書の役割は、依頼元と制作側の「認識のズレ」を無くすことです。
そしてシステム要件を確定することです。
要件定義書の内容に基づいて、システムやWEBの設計へと進みます。
間違いや不足情報が存在すると、開発段階で様々なトラブルの原因となります。
開発が遅延する理由の５０％以上が、要件定義事項に不具合があると言われています。
https://www.ipa.go.jp/files/000079352.pdf
（２３ページあたり）
次にどのような事項をまとめるべきか解説します。
要件定義書に必要な事項
WEB開発の場合についてまとめました。
概要・方針
- プロジェクトの背景
- プロジェクトの目的
- 業務フロー（ビジネスフロー）
- システムの概念図
プロジェクト要件
- 作業範囲
- プロジェクトの体制
- 納品物・納品方法・場所
- スケジュール
- 運用
サイトの要件
- ターゲットユーザー
- ターゲットデバイス
- サイトマップ
システム要件
- 機能一覧
- 非機能要件(可用性、性能・拡張性、運用・保守性、移行性、セキュリティ、システム環境・エコロジー)
- インフラ要件 （ドメイン、SSLサーバー証明書、ネットワーク、サーバー環境）
技術的要件
- 開発言語
- ミドルウェア
- フレームワーク
- 使用オープンソースソフトウェア
- バージョン管理
依頼側と制作側の双方が、ドキュメントの内容を理解しやすい形にするのが大切です。
進め方
ヒヤリング
先ずは依頼側の要求をヒヤリングし、聞き出した情報を整理します。
聞き出す時に以下の事を注意したいです。
- 説明された内容を鵜呑みにせず、会話の中で真の問題を理解する事。
- 難易度が高く現実的でない場合、「別の方法を提示」するか「実装不可能である事をはっきり伝える」事が大切。
- 顧客が要求しているより、新しいトレンドの対策があれば提案する。
目的を整理する
本質的な目的を明確にするために、以下のステップで依頼側と制作側が合意をしながら情報を定義していきます。
1.ビジネスゴールの確認
「経営的なゴール」はできるだけ具体的に文章化します。
「何で」売り上げや集客数の増加などについて期限や数値を「具体的」にかつ、「現実的に可能」な数値で定めます。
２.ターゲットを考える
１で定めた「何で」について、商品やサービスを求める顧客の中から、コアが顧客の属性を絞り込みます。
既存のサービスなら、実績ベースでどんな客層（年齢、性別、地域、関心事、収入など）の分類を行い。
サイトの内容と顧客のニーズがマッチした、サイトに集まりやすく行動を起こしてくれそうな客層をリサーチします。
競合のサービスや商品などからでも、どのような客層がどんなニーズを持っているか見えてくると思います。
３.ペルソナを作成
２で定めた客層に合致する人物像を設計（ペルソナ）します。
ターゲットに合致した人からインタービュしたり、アンケートをとり、共通する性質を持った人物像を設計していきます。
4.カスタマージャーニーマップの作成
ペルソナに合致した人物が一般的が、どのような感情でどのような行動をするか検討します。
カスタマージャーニーマップ作成し、情報をまとめることで一連の行動が視覚化しやすくなります。
ペルソナやカスタマージャーニマップの作成については、UXについて学習すると良いです。
5.Webサイトやシステムの目的を定義する。
ユーザーの行動が理解できたら、ユーザー層が求めている事項を洗い出し、WEBサイトやシステムの役割と目的が見えてきます。
以上のように、「サイトの目的」が定まると、その目的に向かってプロジェクトを進行すれば、ビジネスゴール達成しやすくなるという事です。
要件定義書の作成
依頼側と制作側で合意を得ながら、「要件定義書に必要な事項」で示した情報を文章や図表をまとめて作成していきます。
参考になるサイト
無料テンプレートダインロード
記入例
https://www.env.go.jp/press/files/jp/116100.pdf
ユーザのための要件定義ガイド
システム再構築を成功に導くユーザガイド
システム構築の上流工程強化（非機能要求グレード）
まとめ
- 要件定義書の役割は、依頼元と制作側の「認識のズレ」を無くすことです。
- 要件定義書に必要な事項を漏れなく書類に記載する。
- サイトの目的を正確に見つける（ターゲットをどのように導くか行動させるか）
