要件定義とは？進め方と決める項目、発注者が担う役割をわかりやすく解説

要件定義とは、システムで何を実現するかを、発注者と開発会社のあいだで具体的に決めて合意する工程です。

専門知識が要るため開発会社に任せる工程と思われがちですが、業務の目的や優先順位を決められるのは、そのシステムを使う発注者自身です。この記事では、要件定義で決める項目と進め方、要件定義書をどこまで書くか、発注者と開発会社の役割分担を解説します。

⇒　900件以上の構築実績から生まれた『型』でリスクを抑える。AI駆動セルフ開発ツール『S-MASE』の詳細を見る

要件定義とは？システムで実現することを発注者と開発会社で決める工程

要件定義は、システム開発の最初に「何を、どこまで作るか」を決める工程です。家づくりにたとえると、間取りや設備、予算を決めて施主と工務店が合意する段階にあたります。ここで決めた内容が、その後の設計・開発・テストの基準になります。

要件定義で決める3つの要件

要件定義で決める内容は、業務要件・機能要件・非機能要件の3つに分けられます。業務要件は「システムを使って業務をどう変えるか」、機能要件は「システムに何ができればよいか」、非機能要件は「速さ・安全性・使える時間など、機能以外に求める水準」です。

見落とされやすいのは非機能要件です。画面や機能は打ち合わせで話題になりやすい一方、「同時に何人が使うか」「止まってよい時間はあるか」は聞かれるまで決めていないことがあります。あとから決めると構成の作り直しにつながるため、要件定義の段階で話し合っておくことが重要です。

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

要求定義は「こうしたい」という希望を集めて整理する工程、要件定義はその希望のうち何をシステムで実現するかを決める工程です。基本設計は、決めた要件を画面や機能の形に落とし込む工程で、主に開発会社が担います。

ただし、要求定義と要件定義をまとめて「要件定義」と呼ぶ会社も少なくありません。打ち合わせの前に、相手がどの範囲を指しているかを確かめておくと、認識のずれを防げます。

要件定義が重要な理由

要件定義が重要なのは、ここで決めた内容が、費用・期間・出来上がりのすべての基準になるからです。開発が進んでから要件を変えると、すでに作った部分の作り直しが必要になり、変更が遅いほど影響は大きくなります。

IPA（独立行政法人 情報処理推進機構）の「ユーザのための要件定義ガイド 第2版」も、「システム開発の遅延の過半は要件定義の失敗にあると言われる」と述べ、要件定義の難しさを指摘しています。

要件定義の位置づけがわかると、次に気になるのは「自分たちは何をすればよいのか」という点です。

要件定義は誰がやる？発注者と開発会社の役割分担

要件定義は開発会社に任せきりにする工程ではなく、業務の要件は発注者が決め、実現の方法は開発会社と一緒に詰める工程です。

業務の要件と優先順位は発注者が決める

前述のIPAのガイドは、「システムの要件を定義する責任は、構築されたシステムを利用してビジネスに貢献する役目を負うユーザにあると言われています」と述べています。そのうえで、ITベンダーやシステム部門が中心になって進める形から、「業務部門のユーザが主体的に関与するスタイルへの変革の必要性が増しています」としています。

開発会社は、システムの作り方には詳しくても、発注者の業務の事情や、何を優先したいかまではわかりません。目的・業務の流れ・優先順位は、発注者でなければ決められない項目です。

システムでの実現方法は開発会社と一緒に詰める

一方で、機能をどう実現するか、どの技術を使うかは、開発会社の知見が欠かせません。発注者が決めた業務の要件をもとに、開発会社が実現方法と費用の見通しを出し、両者で調整して決めていきます。

項目ごとの分担の目安は次のとおりです。

決める項目	主に決める人	発注者が用意するもの
システム化の目的・ゴール	発注者	解決したい課題、効果の測り方
対象の範囲（今回やること・やらないこと）	発注者	対象の業務・部署・利用者
業務の流れ	発注者	現在の流れと、変えたい点
機能要件	一緒に	業務で必要な操作の一覧
非機能要件	一緒に	利用人数、止まってよい時間、扱う情報の重要度
優先順位	発注者	必須・あれば良い・今回はやらないの区分
実現方法・技術・構成	開発会社	社内で使っているシステムや制約の情報
受け入れの条件（何ができれば完成か）	一緒に	確かめたい業務の場面

社内に詳しい人がいないときの進め方

社内にシステム開発の経験者がいない場合でも、業務の要件を決める役割は発注者に残ります。足りないのは「業務の要望をシステムの言葉に置き換える」部分のため、その部分を外部の支援で補う形が現実的です。

開発会社に発注したあとの進み具合や変更の管理まで含めた発注側の役割は、ベンダーコントロールとは？丸投げにしない進め方と発注側の役割で解説しています。

分担がはっきりしたら、あとは決める順番です。

要件定義の進め方6ステップ

要件定義は、目的と範囲を決めることから始め、合意と変更のルールを決めて終わります。全体の流れは次のとおりです。

①目的と範囲を決める

最初に、システムで解決したい課題と、今回の対象にする業務の範囲を決めます。目的があいまいなままだと、あとの工程で要望の取捨選択ができません。現状の業務と目指す姿を整理する方法は、As-Is/To-Beフレームワークによる要件定義と業務フローで詳しく紹介しています。

②関係者から要求を集める

実際にシステムを使う部署や、承認する立場の人から要望を集めます。現場の担当者だけでなく、管理する側や経理など、業務の前後に関わる部署にも聞いておくと、あとからの追加を減らせます。

③要求に優先順位をつける

集めた要望は、「必須」「あれば良い」「今回はやらない」に分けます。すべてを必須にすると、費用と期間が膨らみ、何から作るかも決められなくなります。予算と時期の制約を先に示しておくと、関係者の合意をとりやすくなります。

④要求を要件に落とし込む

優先順位をつけた要望を、開発会社と一緒に、システムで実現する機能や水準に置き換えます。「使いやすく」「速く」のような言葉は、「3回の操作で申請できる」のように、確かめられる形に言い換えるのがポイントです。

⑤要件定義書にまとめ、画面で確かめる

決めた内容を要件定義書にまとめ、関係者で読み合わせます。ただし、文書だけでは出来上がりの姿を思い浮かべにくいため、画面のイメージや試作品を見ながら確かめると、認識のずれを早く見つけられます。

⑥合意し、変更のルールを決める

内容を確定したら、発注者と開発会社で正式に合意します。あわせて、あとから要件を変えたいときに、誰が判断し、費用や期間をどう見直すかを決めておきます。変更そのものを防ぐことより、変更を扱う手順を決めておくことが現実的です。

要件定義書に書く項目と、どこまで書けばよいか

要件定義書は、開発会社が見積もりと設計を進められ、完成したときに確かめられる粒度で書くのが目安です。

要件定義書の主な項目

要件定義書に書く主な項目は次のとおりです。会社やプロジェクトによって項目名は異なりますが、おおむねこの範囲をカバーします。

項目	書く内容
概要・目的	システム化の背景、解決したい課題、ゴール
対象の範囲	対象の業務・利用者、今回の対象外
業務要件	新しい業務の流れ、関係する部署
機能要件	必要な機能の一覧、画面・帳票・データ
非機能要件	性能、安全性、稼働時間、保守の条件
制約・前提	予算、時期、連携する既存システム
受け入れの条件	何が確かめられれば完成とするか
未決事項	まだ決まっていないことと、決める期限・担当

どこまで書くかの目安

どこまで書くかの判断には、次の3つの問いが役立ちます。1つ目は「開発会社がこの内容で見積もれるか」、2つ目は「完成したときに、書いたとおりかを確かめられるか」、3つ目は「決まっていないことが、決まっていないと書かれているか」です。

特に3つ目は見落とされがちです。未決のまま空欄にしたり、あいまいな表現で埋めたりすると、開発会社は都合のよい解釈で進めるしかありません。決まっていないことは、決める期限と担当者を添えて明記しておくほうが、あとの食い違いを防げます。

RFP（提案依頼書）との違い

RFP（提案依頼書）は、開発会社を選ぶ前に「こういうシステムを作りたいので提案してください」と依頼するための文書です。要件定義書は、開発会社が決まったあとに、作るものを詳しく決めて合意するための文書です。

RFPには目的や機能の概要を書き、詳細は要件定義で詰める、という順番になります。RFPの書き方は、0から分かる！RFP（提案依頼書）の書き方解説をご覧ください。

項目と書き方がわかっても、実際の要件定義ではいくつかの場面でつまずきやすくなります。

要件定義でつまずきやすい3つのポイント

要件定義のつまずきは、文書だけで合意する・一度に決めきろうとする・決める人があいまい、の3つに起きやすい傾向があります。

文書だけで合意し、出来上がりが想定と違う

要件定義書を読んで合意しても、完成したシステムを見て「思っていたものと違う」と感じることがあります。文字で書かれた機能を、発注者と開発会社がそれぞれ別の姿で思い浮かべているためです。

対策は、要件定義の段階で画面や試作品を見ながら確かめることです。試作品で認識をそろえる進め方は、プロトタイプ開発とはで詳しく解説しています。

一度に決めきろうとして進まない

新しい事業のシステムでは、使う人の反応を見ないと決められない要件も少なくありません。そのような場合は、最初からすべてを決めきろうとせず、まず小さな範囲で試し、その結果をもとに要件を固める方法があります。試しに作って確かめる進め方は、PoC開発の進め方でも紹介しています。

導入事例：三菱電機「ビルサポβ版」

小さく始めて確かめた例として、ビルオーナーとメンテナンス会社をつなぐプラットフォームがあります。カスタメディアの導入事例では、三菱電機株式会社が「ビルサポβ版」を構築しました。

三菱電機は、不動産テック事業として、紙で行われていたビルオーナーとメンテナンス会社のやりとりをデジタル化する仕組みの概念実証を行いました。

ビルサポβ版では、ビルオーナーが依頼を案件として登録してメンテナンス会社と出会えるほか、図面や設備管理台帳を電子化して情報を共有できます。詳しくは三菱電機株式会社「ビルサポβ版」の導入事例をご覧ください。

決める人があいまいで、要件が増え続ける

関係者の要望をすべて受け入れていると、要件は増え続けます。原因の多くは、優先順位を最終的に決める人が決まっていないことです。要件定義を始める前に、発注者側で最終判断をする人を1人決めておくと、議論がまとまりやすくなります。

AIを使った要件定義の進め方

生成AIは、要望の整理や要件定義書の下書きなど、要件定義の作業の一部を効率化する手段として使われ始めています。たとえば、打ち合わせのメモから要望の一覧を作る、抜けている観点を挙げさせる、といった使い方です。

ただし、何を優先するか、どこまで作るかの判断は、AIではなく発注者が行います。AIが出した内容は、業務を知る人が確かめてから使うことが前提です。

作業ごとにAIに任せる範囲や、プロンプトの例は「AIで要件定義はどこまでできる？作業別の使い方と、発注者が決めること」で解説しています。

最後に、要件定義を始める前に発注者側で確かめておきたいことを整理します。

要件定義を始める前のチェックリスト

次の項目に答えられれば、開発会社との要件定義をスムーズに始められます。答えられない項目は、打ち合わせの前に社内で話し合っておきましょう。

確認すること	答えの例
システムで解決したい課題は何か	申請の処理に時間がかかり、月末に作業が集中する
何ができれば成功か	申請から承認までを当日中に終えられる
対象の業務・利用者は誰か	営業部の申請と、管理部の承認
今回やらないことは何か	他部署への展開、スマートフォン対応
予算と、使い始めたい時期はいつか	予算の上限、使い始めたい月
最終的に判断する人は誰か	営業部長
関係する部署・既存システムはどこか	経理部、会計システム

よくある質問

まとめ｜要件定義は「何を作るか」を発注者が主導して決める工程

要件定義は、システムで実現することを発注者と開発会社で決めて合意する工程です。業務要件・機能要件・非機能要件の3つを決め、目的と範囲の決定から、合意と変更のルールづくりまでの6ステップで進めます。

業務の目的と優先順位は発注者でなければ決められないため、開発会社に任せきりにせず、主体的に関わることが重要です。また、文書だけでなく画面や試作品で確かめながら進めると、出来上がってからの「想定と違う」を減らせます。

画面を見ながら要件を固めたい方へ

カスタメディアは、900件以上の構築実績をもとに、新規事業のシステムづくりを支援しています。カスタメディアプラットフォームの中核ツールであるAI駆動セルフ開発ツール『S-MASE』は、プロンプトからインフラ・データベース・画面を自動生成でき、カスタメディアが伴走しながらお客様自身で開発を進められます。

要件定義の段階から画面を見ながら確かめたい、自社で作るものを主導して決めたい、といったご相談をお受けしています。詳しくはカスタメディアプラットフォームをご覧ください。

⇒　900件以上の構築実績から生まれた『型』でリスクを抑える。AI駆動セルフ開発ツール『S-MASE』の詳細を見る