要件定義とは？要求定義との違い、要件定義書の項目と、外注する発注者が決めること

社内の業務システムを作り直すことになり、開発会社から「まず要件定義から始めましょう」「要件定義書の確認をお願いします」と言われたものの、何を準備し、どこまで自分たちで決めればよいのか分からない、という声をよく聞きます。要件定義という言葉は知っていても、開発会社に任せる仕事なのか、自社でやる仕事なのかがはっきりしないまま進むことも少なくありません。

ところが、システム開発の遅れや作り直しの多くは、この最初の工程でつまずいたことから始まります。決めきれないまま作り始めると、あとから要件の追加や変更が続き、費用も納期も膨らんでいきます。

要件定義は、作るシステムが「何をするか」を、使う側と作る側が同じ言葉で確かめて文書にする工程で、その中身を決める責任は発注者の側にあります。この記事では、要件定義の意味と要求定義・基本設計との違い、要件定義書に書く項目、発注者が自分で決めることと開発会社に任せてよいこと、進め方の5つの手順と失敗しやすい所を、外注する側の目線で順に説明します。

要件定義とは｜システムが「何をするか」を決める工程

要件定義は、システム開発の最初の段階で、これから作るシステムが満たすべき条件を決めて文書にする工程です。どの業務で、誰が、何のために使い、どんな機能と性能が必要かを、発注者と開発会社が合意できる形でまとめます。

ここで決めた内容が、そのあとの設計・開発・テストのすべての基準になります。テストで「できている」と言えるかどうかも、要件定義書に何が書かれているかで決まるため、要件定義は開発全体の物差しを作る工程だと言えます。

なぜ要件定義が大事なのか

情報処理推進機構（IPA）の「ユーザのための要件定義ガイド 第2版」（2019年）の紹介では、システム開発の遅延の過半は要件定義の失敗が原因と言われていることに触れ、要件を定義する責任はシステムを使ってビジネスに貢献するユーザにある、と述べています。従来は開発会社や情報システム部門が中心になって進めることが多かったものの、業務部門が主体的に関わる形への転換が求められている、という整理です。

発注者から見ると、要件定義は「開発会社の作業」ではなく「自社のやりたいことを、作る人に渡せる形にする作業」です。ここを任せきりにすると、できあがったものが業務に合わず、使われないシステムになりやすくなります。

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

要件定義と並んでよく出てくる言葉に、要求定義と基本設計があります。どれもシステム開発の上流の工程ですが、決めるものが違います。

要求定義との違い

要求定義は、「受注の入力に毎日2時間かかっている」「営業所ごとに在庫の数え方が違う」といった業務の困りごとから、システムで実現したいことを洗い出す段階です。発注者の側の言葉で、やりたいことを並べたものだと考えると分かりやすいでしょう。

要件定義は、その要求の中から、予算・期間・技術の制約を踏まえて今回作るものを選び、作る側が設計に使える粒度まで具体的にしたものです。すべての要求がそのまま要件になるわけではなく、今回は見送るもの、手作業のまま残すもの、別の道具で済ませるものを決めるのも要件定義の仕事になります。

基本設計との違い

基本設計は、決まった要件を画面の構成やデータの持ち方といった作り方の大枠に落とし込む工程で、主に開発会社が担います。要件定義が「何をするか」なら、基本設計は「どう見せ、どう動かすか」です。

発注者は基本設計を自分で書く必要はありませんが、画面のイメージや帳票の形は業務に直結するので、確認の場には業務を知っている人を出すことが大切です。

要件定義書に書く項目

要件定義書の書き方は会社によって違いますが、中身は大きく業務要件・機能要件・非機能要件の3つに分けられます。冒頭には、システムを作る背景と目的、対象の範囲を置きます。

業務要件｜業務の流れと使う人

業務要件は、システムが入る業務そのものを書く部分です。今の業務の流れ（As-Is）と、システムを入れたあとの流れ（To-Be）を並べると、どこが変わるのかが関係者の間で見えやすくなります。業務の流れを一番よく知っているのは発注者なので、ここは発注者が書くか、少なくとも中身を決める部分です。

機能要件｜システムがする仕事

機能要件は、システムが何をするかを並べたものです。「受注を入力すると在庫が引き当てられる」「月末に得意先別の請求書を出力する」のように、誰が、何をすると、何が起きるかの形で書くと、あとで抜けや食い違いを見つけやすくなります。

非機能要件｜速さ・安全・運用

非機能要件は、機能以外の品質の条件です。IPA は非機能要件を整理するための「非機能要求グレード2018」を公開しており、可用性、性能・拡張性、運用・保守性、移行性、セキュリティ、システム環境・エコロジーの6つの大項目で整理しています。発注者にとって分かりにくい部分ですが、「朝の始業時に全員が同時に使っても遅くならない」「夜間は止まってもよい」のように業務の言葉で伝えれば、開発会社が数値に置き換えられます。

非機能要件は、書き漏れても作っている途中には気づきにくく、稼働したあとで遅い・止まる・直せないという形で表に出ます。保守を誰が担うか、作った会社がいなくなったときに引き継げる資料を残すかも、この段階で決めておくと安心です。資料が残っていないシステムを引き継ぐ苦労は、「他社が作ったシステムの引き継ぎ｜作った人がいない・保守を断られたときの進め方」で詳しく書いています。

発注者が決めること・開発会社に任せてよいこと

外注するときに迷いやすいのが、要件定義のどこまでを自社でやるかです。役割を3つに分けて考えると整理しやすくなります。

自社で決める人を1人置く

要件定義でよく起きるのは、部署ごとに言うことが違い、開発会社がどれを採ればよいか分からなくなることです。最終的に決める人を社内で1人決め、その人が部署の意見をまとめて開発会社に伝える形にすると、打合せのたびに話が戻ることが減ります。

優先順位を付ける

要求を全部入れると、予算も期間も足りなくなります。「これが無いと業務が回らない」「あると楽になる」「なくてもよい」の3段階で優先順位を付けておくと、予算に合わせて削る場面で判断が速くなります。

「書けない」ことは動くもので確かめる

画面の使い勝手や業務の細かい例外は、文章だけでは決めきれないことがあります。その場合は、要件定義の途中で画面の試作や簡単に動くものを作り、触りながら決める方法が向いています。当社のMVP開発も、2週間で動く試作と要件定義書をあわせて納める形で、動くものを見ながら要件を固める進め方を取っています。

要件定義の進め方 5つの手順

発注者の側から見た要件定義の進め方を、5つの手順に分けて説明します。開発会社によって呼び方や順番は違いますが、押さえる所は共通しています。

1. 目的と範囲を社内で決める

開発会社に会う前に、なぜ作るのか、何がどう良くなれば成功か、どの業務と部署が対象かを社内で決めておきます。ここが曖昧なまま話し始めると、開発会社は聞いた要望をすべて拾うしかなく、範囲が広がり続けます。

2. 今の業務と困りごとを洗い出す

対象の業務を実際に担当している人から、今の流れ、使っている帳票や Excel、例外の処理、困っていることを聞き取ります。手順書に書かれていない判断や例外こそ、システムで抜けやすい所です。担当者の頭の中にある判断を言葉にする方法は「暗黙知とは？形式知との違いとSECIモデルを分かりやすく解説｜言葉にする聞き方まで」が参考になります。

3. 要求を整理して優先順位を付ける

洗い出した要求を、業務ごとにまとめ、重複をなくし、優先順位を付けます。予算と稼働の時期を踏まえて、今回作るもの、次の段階に回すもの、作らないものに分けます。

4. 要件定義書にまとめ、関係者で確かめる

整理した内容を、上の表の項目に沿って要件定義書にまとめます。開発会社が書く場合でも、発注者は業務要件と優先順位が正しく書かれているかを確かめ、分からない言葉はその場で聞きます。曖昧な所を残したまま合意すると、あとで「言った・言わない」の食い違いになります。

5. 合意して、変更のルールを決める

要件定義書に双方が合意したら、そのあと要件を変えるときの手続き（誰が判断し、費用と納期への影響をどう確かめるか）を決めておきます。開発の途中で変更が出ること自体は珍しくありませんが、ルールが無いまま変更を重ねると、費用と納期の見通しが立たなくなります。

要件定義で失敗しやすい所

最後に、発注者の側で起きやすい失敗を4つ挙げます。どれも、要件定義の段階で手当てができるものです。

たとえば、こういう場面を考えてみます。ある会社が受発注のシステムを外注し、要件定義書は開発会社がまとめたものを、中身を十分に読まずに承認しました。テストの段階で現場の担当者が触ってみると、営業所ごとに違っていた値引きの扱いが入っておらず、そこから追加の開発と納期の延長が続きました。これは想定の例ですが、業務の例外を聞き取る手順と、要件定義書を業務の担当者が読む手順があれば防げた失敗です。

すでに要件が固まらないまま開発が進み、遅れや作り直しが続いている場合は、「炎上プロジェクトの立て直し方｜発注者が最初にやる火消しの4つと、外に頼むときの判断」や「システム開発の納期遅れ・頓挫で困ったら｜解約を決める前に確かめる3つのことと、途中から引き継ぐ進め方」も参考にしてください。

要件が固まらない開発や、止まった開発の立て直しについて相談する

ホームページや EC サイトの要件定義は

ホームページや EC サイトの制作でも考え方は同じですが、決める項目はページ構成や決済など Web 特有のものが中心になります。Web サイトの場合は「【初心者向け】ホームページ（Webサイト）の要件定義の作り方｜13個の必要項目と進め方を解説」、EC サイトの場合は「ECサイトの要件定義書の作り方｜無料テンプレートやより良い制作方法を紹介します」で、項目と進め方をまとめています。開発会社に提案を求める前の準備は「【テンプレート】WEBサイト制作のRFP（提案依頼書）の書き方｜書く項目と提案の比べ方」も参考になります。

まとめ｜要件定義は、発注者が「何をするか」を決める工程

要件定義は、作るシステムが何をするかを、発注者と開発会社が同じ言葉で確かめて文書にする工程で、その中身を決める責任は発注者の側にあります。目的と範囲、業務の流れ、優先順位を自社で決め、機能と非機能要件の水準は開発会社と一緒に決め、変更のルールまで合意しておくと、開発の途中で迷うことが減ります。

• 要求定義は「やりたいこと」、要件定義は「今回作ること」、基本設計は「作り方の大枠」
• 要件定義書は、背景と目的・範囲のあとに、業務要件・機能要件・非機能要件を書く
• 目的・範囲・業務の流れ・優先順位は発注者が決め、社内で決める人を1人置く
• 文章で決めきれない所は、動く試作を触りながら決める
• 合意したあとの変更の手続きを、要件定義の段階で決めておく

デイワンでは、要件が固まらないまま進んだ開発や、途中で止まった開発の引き継ぎ・立て直しを、今あるコードと資料を読み解き、分かっていることと分かっていないことを分けて報告するところからお受けしています。要件定義のやり直しが必要かどうかの見極めからでも、お気軽にご相談ください。

あわせて読みたい：運用保守とは？、DX推進とは？

システム開発の要件定義や立て直しについて相談する