要件定義の目的とは？省くと後工程で何が起きるかと防ぎ方

当サイトの記事は編集部がIPAなど公的機関の公開資料と読者の声を調べて独自に執筆しています。

要件定義の目的は何？ひとことで言うと

要件定義そのものの意味から知りたい方は、要件定義とはを先に読んでみてください。ここでは「なぜやるのか」に絞ってお話しします。

要件定義の目的を分けて考えると、次の4つになります。どれか一つだけではなく、4つがつながっているんです。

「合意」がいちばん大事な理由

要件定義書を作ること自体が目的だと思われがちですよね。でも、実は文書は合意を残すための手段なんです。

どれだけ立派な要件定義書でも、関係者が中身を確かめていなければ、後から「そんなつもりではなかった」が起きます。目的はあくまで合意で、文書はその証拠だと考えてみてください。

発注側と開発側、それぞれにとっての目的

要件定義の目的は、立場によって少し見え方が変わります。どちらか一方のための作業ではなく、両方にとって意味があるんです。

『開発会社のための書類でしょう』と思われることもありますが、そうではありません。IPAが2019年に公開した「ユーザのための要件定義ガイド 第2版」も、業務に責任を持つ発注側に向けて書かれています。

発注側が要件定義に深く関わるほど、出来上がるシステムは業務に合ったものになりやすいんです。

要件定義を省くと後工程で何が起きる？原因と防ぎ方の一覧

ここが、この記事でいちばん伝えたいところです。要件定義の目的は、省いた時に何が起きるかを見るとよくわかります。

『小さいシステムだし、話しながら作ればいいのでは』と思う方もいるかもしれません。ただ、規模が小さくても、決めていないことは後工程で問題になって返ってくるんです。

手戻りは後になるほど大きくなる

工程が進むほど、作ったものが積み重なっていきます。要件の変更が後になるほど、直す場所が増えて手間がかかるんです。

例えば要件定義の段階なら、文書の一行を書き換えるだけで済みます。ところが完成後に気づくと、設計、プログラム、テストのすべてを見直すことになりますよね。

だからこそ、迷いがある部分ほど要件定義の段階で口に出しておくのが得策です。「たぶん大丈夫」と思って黙っていた点が、後から大きな手戻りになることも。

要件定義でつまずきやすい場面は、要件定義の全体像の記事でも家づくりにたとえて紹介しています。

受入テストの物差しがなくなる

開発の最後には、発注側が「頼んだとおりにできているか」を確かめる受入テストがあります。この時に基準になるのが、要件定義で決めた内容です。

要件定義を省くと、何をもって完成とするかが決まりません。その結果、テストの場で要望が出続け、いつまでも終わらない状態になりがちです。

非機能要件を決めないと本番で困る

機能の話は盛り上がりやすい一方で、性能や安全性の話は後回しになりがちですよね。でも、本番で困るのはこちらのほうが多いんです。

IPAの「非機能要求グレード」では、可用性、性能・拡張性、運用・保守性、移行性、セキュリティ、システム環境・エコロジーの6つの大項目で非機能要件を考えます。各項目のレベルを0から5の段階で選ぶ方式なので、何を決めればいいか迷った時の手がかりになります。

例えば「月末の締め日にアクセスが集中しても止まらない」と決めておけば、開発側はそれに耐える作りを最初から考えられます。決めていなければ、本番で初めて遅さに気づくことになりかねません。

データ移行は要件定義の段階で話しておく

古いシステムから新しいシステムに入れ替える時は、データの移行も大きな作業になります。どのデータを、どんなルールで変換して、いつ切り替えるかを決めておかないと、切り替えの直前で慌てることになるんです。

開発側「旧システムの過去分のデータは、何年分を移しますか」
発注側「そこはまだ決めていませんでした。部署に確認して、次回までにお伝えします」

こうした確認を要件定義の段階でしておくだけで、移行の作業量が早めに見えるようになります。

範囲が決まらないと費用と期間も読めない

開発の費用は、関わる人数と期間で見積もられることが多いです。作る範囲が決まっていなければ、何人でどれだけかかるかも決められませんよね。

『とりあえず概算で』と頼まれた開発側は、決まっていない部分を広めに見込むしかありません。範囲をはっきりさせることは、発注側にとっても見積もりの根拠を確かめる手段になるんです。

要件定義の目的を見失わないための確かめ方

要件定義を進めていると、細かい機能の話に夢中になって、何のためのシステムかを忘れてしまうことがあります。そんな時に役立つのが、目的を最初に書き出しておくことです。

記入例：目的の書き方

架空の題材で、目的の書き方の例を作ってみました。社内の経費精算を紙から入れ替える場合の例です。

このように目的を先に書いておくと、要件を追加するか迷った時の判断基準になります。

利用部門「交通費の自動計算も入れられませんか」
開発側「今回の目的は手続きを画面上で完結させることでしたね。自動計算は次の段階の候補に入れておきましょうか」

記入例：要件と目的のつながりを書く

経費精算の例で、要件ごとにどの目的につながるかを書いてみました。架空の題材での例です。

このように一行ずつ並べると、どの要件が目的に効いているかが一目でわかります。追加の要望が出た時も、この表に足して判断すれば話が早く進みますよ。

要件定義の進め方を最初から順に知りたい方は要件定義の進め方・手順を、どこで行き詰まりやすいかは要件定義が難しい理由も参考にしてみてください。

よくある相談に答えます

要件定義の目的について、よく寄せられる相談を要約してお答えします。

中途半端にしか決めないなら、要件定義は意味がないのでは？

「どうせ途中で変わるなら、要件定義をする意味はあるのか」という相談があります。結論から言うと、途中で変わるからこそ、元の約束を残しておく意味があるんです。

最初の合意が残っていれば、何が変わったのかを比べて、費用や期間への影響を話し合えます。決めきれないことは「未決」として一覧に残すだけでも、後のもめごとはぐっと減りますよ。

要件定義書の「背景」「目的」には何を書けばいい？

「機能要件や非機能要件は書けたが、背景や目的に何を書けばよいかわからない」という相談もあります。ここは、システムを作る理由を、読んだ人が納得できるように書く欄です。

背景には今の業務で困っていること、目的にはシステムで実現したい姿を書きます。上の記入例のように一文ずつ短く書くと、関係者の誰が読んでも同じ意味で受け取れます。

「要件」って、そもそも何のこと？

「要件という言葉の意味がよくわからない」という素朴な相談も多いです。要件とは、システムが満たすべき条件のことです。

利用者や発注者の「こうしたい」という要求のうち、予算や期間、技術を踏まえて「実現する」と合意したものが要件になります。願いを約束に変える作業が要件定義、と考えるとわかりやすいですよ。

要件定義書全体の項目は要件定義書とはで紹介しています。

よくある質問

まとめ

あわせて読みたい

要件定義とは？意味をわかりやすく解説｜家づくりで見る全体像

要件定義の進め方とやり方｜6つの手順と週ごとのスケジュール例

要件定義が難しい理由とつまずきポイント｜人・情報・時間で見る打ち手