要件定義とは、システムを開発するにあたって「何をどのように作るのか」をまとめる工程です。そのために現状の調査、クライアントからの要望の吸い上げ、課題の発見と検討等を行います。
今回は要件定義の成果物やポイントについて解説します。
要件定義書に記載する主な項目一覧
要件定義書の記載事項は開発するシステムの特性、新規プロジェクトか改修プロジェクトか等により異なります。以下では多くのプロジェクトを進める上で必要になるであろう要件定義書の記載項目を一覧にしています。
開発の背景
システムを開発するに至った背景を説明する項です。
システムを導入する目的、期待する成果、導入する環境や制約条件などをまとめ、開発の方向性がぶれないようにします。
課題とその解決策
現状の業務が具体的にどんな課題を抱えているのか、分析した結果をまとめます。さらに課題の解決策と、その内容を反映した新しい業務の仕組みを定義します。
システム要件
策定した課題の解決策をシステムでどのように実現するのか、その具体的な内容を説明します。システム要件は業務要件、機能要件、非機能要件に細分されます。業務要件はシステム化の対象となる業務の定義です。この段階ではシステムの言葉は使わず、ユーザー目線で説明します。たとえば航空券を予約するWebサイトであれば、空席照会・予約・購入・座席指定といった表現になります。
機能要件はシステムが必ず備えるべき機能です。具体的には業務フロー、データフロー図、画面一覧、帳票一覧等を作成し、システムが実現する処理・インプット・アウトプットを明確にします。また、サーバーやネットワークといったハードウェアの構成、OSやミドルウェア等のソフトウェアの構成も機能要件に含まれます。
非機能要件は「機能以外」、すなわち機能要件で定義されていない要件です。
セキュリティ面、性能要件（パフォーマンス、可用性、スケーラビリティ）、運用、移行等が該当します。
実行計画
この後の開発を進めるための計画を立てます。リリースまでに必要な作業とかかる工数を洗い出し、開発体制（人員・作業場所・使用する機器）、スケジュール、予算等を定義します。
要件定義書に決まったフォーマットはありません。
組織内で使われているテンプレートがない場合は、IPAで公開されている「超上流から攻めるIT化の事例集」のドキュメントサンプル等を参考にすると良いでしょう。
もちろんサンプルにあるドキュメントをすべて作成する必要はなく、プロジェクトの特性に合わせ取捨選択します。
要件定義完了までのステップ
続いてシステムを新規で開発するプロジェクトにおいて、要件を決定し要件定義書にまとめるまでの手順を簡単に解説いたします。
（1）方針と要件定義実施計画をたてる
前述の要件定義書における「開発の背景」に記載する内容を決定するステップです。
まずは「なぜシステム開発が必要なのか？」すなわちシステムを開発するに至った現状（経営状況、業務の現状、社会をとりまく状況、市場のニーズ等）をヒアリングしてまとめます。そして「システムを導入することで現状をどう変えたいのか」も整理します。
また現状稼働しているシステムや環境、予算や体制、リリースの期日といった制約も確認しておきます。ここで整理した内容がこの後の要件定義及びシステム開発を進める土台となります。
さらに要件定義の体制・スケジュールをたて、この後のステップでの検討事項と成果物（要件定義書に記載する内容）も整理します。
（2）現状の業務を洗い出す
現状の業務の内容を洗い出し、整理します。調査した結果は業務フロー図、データフロー図といった図にまとめましょう。ここで業務の全体像を把握し、業務同士の関係も整理しておくことでシステム化の対象範囲を切り分けます。また調査結果は課題とその解決方法を検討する際のインプットとなります。
（3）解決すべき課題とその解決方法を設定する
続いて現状の業務で発生している問題や、（１）で設定した方針を実現するための要望をヒアリングします。そしてその中で特に重要性が高いものを解決すべき課題として設定します。
ここで課題を設定する際には（１）で確認した制約を踏まえたうえで「システム化によって解決が可能か？」という観点からも取捨選択します。
解決すべき課題を決めた後は、解決策の検討に移ります。検討は「ルール（制度や業務のプロセスなど）」「ツール（職場の環境、機器、マニュアル、システムなど）」「ロール（組織の体制など）」というようにいくつかの視点を意識的に切り替えながら行うと案が出やすくなります。
案を出し切った後に、今回の開発で採用する解決策を決定します。その後は解決策の内容を反映した新しい業務を設計します。
（4）新しい業務をシステムに落とし込む
（3）で設計した新しい業務のうち、システム化の対象となる範囲を切り分けてシステム要件を整理します。ここで整理した内容が、要件定義書に記載するシステム要件となります。
（5）開発の計画をたてる
ここではシステム開発の全体計画と今後の作業の洗い出しを行います。全体計画では開発の工程やスケジュールの大枠を決め、マスタースケジュール等のドキュメントを作成します。
また開発の体制（プロジェクトマネージャー・リーダー・メンバー等や連絡体制、会議体など）や作業場所、使用する機器や検証環境等も整理します。
今後の作業を洗い出した結果は、WBSの形でまとめます。この作業のブレークダウンにより作業工数、詳細なスケジュールや各工程で必要な人員も整理します。
上記は新規開発の場合のステップです。既存のシステムを改修する場合は、先に（４）のシステム要件が要望としてあがってくるパターンもあります。その場合はシステム要件から（３）の現状の課題を引き出し、検討します。
要件定義書作成のポイント
要件定義書を作成する際には、特に以下に気を付けるとよいでしょう。
専門知識に乏しくても理解できるように書く
要件定義書はシステム開発に関わるエンジニアと開発依頼したクライアントがともに読むものです。そしてクライアントはIT関連の専門知識に乏しい場合もあります。
双方がシステムの完成イメージを齟齬なく共有して次のフェーズに進むために、極力一般的な言葉で書く、専門用語には注釈を加えるなどして多くの人に理解しやすい要件定義書としましょう。
5W2Hを明確にする
5W2HはWhen（いつ）、Where（どこで）、Who（誰が）、What（何を）Why（なぜ）、How（どのように）、How much（いくらで）の頭文字です。
要件定義においてはこの5W2Hの観点から要望・課題を掘り下げることで抜け漏れを防ぐことができます。要件定義書にも5W2Hを明確に書くことで、記述漏れによる後続工程でのトラブルを防ぎましょう。
まとめ
要件定義はシステム開発の方向性を決定する重要な工程です。要件定義に漏れや曖昧さがあると大きな手戻りの原因になります。クライアントの要求を深く掘り下げ、かつ方針を実現できる要件を漏れなくあげて検討することが出来れば、その後の工程で急な変更や追加が発生することも防げるでしょう。また、要件定義書は要件定義で検討した内容が齟齬なく伝わるよう心がけて記入することが大切です。
要件定義の品質を高めることでプロジェクトを成功に導きましょう。
