要件定義書テンプレート｜システム開発を成功に導く進め方

要件定義とは、プロジェクトやシステム開発において、顧客が求める機能や性能、仕様を明確にすることです。

要件定義を明確にすることで、開発チームが作るものを正確に理解し、成果物を提供するための基準にします。要件定義はプロジェクトの初期段階で行われ、プロジェクトの成功に欠かせない重要なステップです。

今回は、要件定義のテンプレートや進め方、サンプルなどを紹介します。

要件定義書テンプレート(サンプル付)

要件定義書のサンプルテンプレートを紹介します。要件定義書は進めるプロジェクトによって実際に記載する項目はことなるので、フォーマットのサンプルとして必要部分を参考にしてください。

エクセル版

エクセル版の要件定義書のサンプルテンプレートです。表紙と目次、各項目のフレームだけが使用できます。エクセルの場合、図や表を作成するのは容易ですが、目次を作成するのが大変なのでワードと併用するといいでしょう。

ワード版

ワードで作成した要件定義書のサンプルテンプレートです。表紙と目次、各項目のタイトルが記載されています。実際の書き方はないので、要件定義書のサンプルなどを参考にして作成する必要があります。

ワードでは、画面レイアウトや一覧表を書くのが難しいのでエクセルと併用するのが効率的でしょう。

要件定義に関連の深いシステム開発のテンプレートについても以下で紹介してます。

 

要件定義とは機能を確定していく作業

要件定義とは、システムを作成したい企業（ユーザー企業）からヒアリングしてシステム化すべき機能を確定していく作業です。

ユーザーは、システムの専門家ではないので、システムを作成したいけれど、どのように実現したらいいかはわかりません。

そのため、システムを開発会社のSEがユーザー企業の経営者や情報システムの担当者、実際に業務を行っている担当者などから、

といったシステムを作るために決めるべきことををまとめます。

業務を細分化して、システム化の要件が揃えば、完成までに「どのぐらいの期間がかかるのか」「どのぐらいの予算が必要なのか」「完成したシステムの全体像」といったことがわかるようになります。

要件定義書とは

要件定義書は、要件定義で確定させた内容を文書にしたものです。この段階では、まだ細かい設計は行いません。あくまでもユーザー企業の要件をまとめたものです。

要件定義書を作成することで、システムの全体図、システム化の目的や方針、方式、対象業務やシステムの役割などが明確になるという利点があります。

要件定義の成果物

要件定義を行って作成される成果物は、どのようなシステムを作成するかで変わってきます。しかし、一般的にどの要件定義でも記載される項目について紹介します。

要件定義で作成される成果物一覧

以上が要件定義に記載されることのある成果物ですが、これらをすべて要件定義に盛り込まなければいけないわけではありません。

最終的な目的は、希望した通りのシステムが完成することです。システムができる最低限のことを決めておけば、システム化は達成できるのです。

要件定義の進め方

要件定義の進め方は、まずシステムを導入するユーザー企業の導入計画から始まります。そこから、システム化で解決したい目標、現状の業務の洗い出しや整理というように具体的な要件定義の作成と進んでいきます。

1.システム化の検討(ユーザー)

要件定義を進めるために、最初に行うことはシステム化の検討からです。

そもそも、システム化をする意味があるのか？、予算、スケジュール、ユーザー側の担当はだれかといったことをベンダーを選定して要件定義を進めてもらう前に決めておかないといけません。

これを怠ってしまうと、実際にヒアリングの段階で決めることになり無駄な時間ばかり掛かるということになってしまいます。

ITに精通している企業ならRFPを作成しておいてある程度の概要を作成しておくと、先にRFPをベンダーに提出し、ヒアリングの際に大きく時間短縮ができて効率がよいです。

しかしRFPの作成は情報システム部やIT系企業でもないと難しい面もあるので通常はなくてもかまいません。

ベンダーの選定(ユーザー)

システムを外部に委託するか、社内で作成するかも含めてシステム化を実際に行うのは誰かを決めなけれなばなりません。ベンダーを選定するなら、自社か外部か、依頼する基準、何社から選ぶかを決めておくとスムーズでしょう。

特に付き合いのあるシステム開発企業がない場合、ベンダーの選定は難しいのですが時間があるなら、いくつかの企業から相見積をとって価格だけでないサービスや提供範囲などを比較します。

ヒアリング(開発者)

要件定義書を作成するためにユーザー企業にヒアリングを行います。

ユーザー企業がシステム化について、まったく何もわからないというのはよくあることなので、開発者は要件定義に必要な項目を先に提出しておいて、ヒアリングの段階で質問と詳細を確認するという流れの方が効率がいいです。

要件を定義(開発者)

ユーザー企業からヒアリングした内容を元に、要件を整理しながら要件定義書を作成します。

ユーザー企業がシステム化はしたいけど、ざっくりとしたイメージしかないという場合も多いので、ヒアリング時にいかに多くの要望や課題、問題を引き出せるかが開発者の力量にかかってきます。

要件定義書に盛り込む内容は、ヒアリングで引き出した内容を元に必要なものを整理します。また、やりたいことと予算や期限が合わないということも頻繁に起きるので、どこまでが必須なのか、どこを妥協するかといったすり合わせも大切になってきます。

要件を提出・承認(開発者・ユーザー)

要件定義が完成したら、ユーザー企業に提出して内容を確認してもらいます。ユーザー企業の担当者は、忙しかったりシステムについてよくわからないので、要件定義書をあまり精査せずに承認するということもあります。

その場合、高い確率で後で問題になることになりますので、要件定義書は文書をただ渡すだけでなく一緒に確認することが望ましいです。

要件定義と基本設計の違い

要件定義と基本設計は、システム開発プロセスの異なるフェーズで、それぞれ異なる目的と成果物を持っています。

要件定義
要件定義のフェーズでは、開発するシステムやソフトウェアが満たす要件や機能、性能、制約条件などを明確にします。この段階では、クライアントや利用者のニーズを詳細に収集し、それらを文書化してシステムが達成すべき目標を定義します。要件定義の主な成果物は要件定義書です。

基本設計
基本設計のフェーズでは、要件定義で明らかにされた要件を基にして、システムの全体構造やデータ構造、重要な機能の動作原理などを設計します。この段階での目的は、システムの枠組みを作り、各部分の関係やデータの流れを定義することです。

二つの違い

目的の違い
要件定義は「何を実現するか」に焦点を当て、基本設計は「どのように実現するか」に焦点を当てます。

成果物の違い
要件定義の成果物は要件定義書であり、システムの要件や目標を記述します。基本設計の成果物は基本設計書であり、システムの構造や設計に関する詳細を記述します。

対象の違い
要件定義はクライアントや利用者のニーズに基づくもので、基本設計は要件定義をもとにした技術的な解決策に関するものです。

要件定義と基本設計は、システム開発を成功に導くために不可欠な連続したステップであり、それぞれがシステム開発の異なる側面を担っています。

要件定義書の参考リンク

総務省のパッケージソフトを開発する際の要件定義書の必要項目を記載したPDF文書です。一般的な要件定義書の項目がすべて記載されているので特に官公庁向けに必要な項目がわかります。書き方のサンプルもあるので、学習用にもいいでしょう。
総務省：パッケージソフトに対する要件定義書のサンプル