当サイトの記事は編集部がIPAなど公的機関の公開資料と読者の声を調べて独自に執筆しています。
業務システムやアプリの導入プロジェクトを任されて、『要件定義って、結局どこまで決めればいいの？』と迷っていませんか。
結論から言うと、プロジェクトの要件定義は「何のために、どの業務を、どこまでシステムに任せるか」を、発注側と開発側で合意して書き残す工程です。
この記事では、システム導入・構築の要件定義で決めることを、システムの種類ごとの詰めどころと記入例でつかめるようにしています。
プロジェクトの要件定義とは？システム導入で最初に決めること
システム導入プロジェクトの要件定義では、目的、対象の業務、システムに任せる範囲、求める品質、移行と運用の条件を決めます。ここで合意した内容が、その後の設計・開発・テストすべての物差しになります。
要件定義（RD：Requirements Definition）は、システム開発の最初のほうで行う工程です。
利用者の「こうしたい」という要求のうち、予算や期間、技術を踏まえて「システムで実現する」と合意したことを要件と呼びます。
新しいシステムを入れる時、つい『どの製品にするか』『どんな画面にするか』から考えたくなりますよね。
ただ、その前に「何に困っていて、どうなれば成功か」を決めておかないと、選ぶ基準も作る基準もぶれてしまうんです。
要件定義そのものの意味から確かめたい方は、要件定義とは？意味をわかりやすく解説を先に読んでみてください。
システム導入の要件定義で決める項目
システム導入の要件定義で決める項目を、ざっと一覧にすると次のようになります。
| 決める項目 | 中身 | 決め手になる人 |
|---|---|---|
| 背景・目的 | なぜ導入するのか、何がどう良くなれば成功か | 発注側の責任者 |
| 対象範囲 | どの業務・部署・拠点までをシステムに乗せるか | 発注側の責任者と業務部門 |
| 業務要件 | 導入後に誰が・いつ・何を・どの基準でするか | 業務部門 |
| 機能要件 | 画面・帳票・データ・処理・外部連携 | 業務部門と開発側 |
| 非機能要件 | 性能・可用性・セキュリティ・運用・移行 | 情報システム部門と開発側 |
| 制約・前提 | 予算、使い始めたい時期、使える機器や環境 | 発注側の責任者 |
会社ごとに様式は違いますが、この6つがそろっていれば、大きな抜けは防げます。
「システム構築」と「システム導入」で変わるところ
システム構築の要件定義と、システム導入の要件定義は、ほとんど同じ意味で使われます。
違いが出るとしたら、ゼロから作るのか、すでにある製品を入れて合わせるのか、という点です。
- 業務に合わせて機能を決められる
- 機能要件を細かく書く量が増える
- 画面や帳票の要件を自分たちで描く
- 製品の標準機能に業務を合わせる場面が多い
- 「製品でできないこと」の洗い出しが中心
- 足りない部分を足すか、業務を変えるかを決める
既製の製品を入れる時も、要件定義が要らなくなるわけではありません。
むしろ「この業務は製品の標準に合わせる」「ここだけは合わせられない」を決める作業が、要件定義の大事な中身になります。
システム企画から要件定義までの流れ
要件定義は、システム企画で決めた目的と予算の枠の中で進めます。企画の段階で目的がぼんやりしたままだと、要件定義で話がふくらみ続けてしまいます。
システム企画と要件定義は、セットで語られることが多いですよね。
企画は「何のためにシステムを入れるか、どのくらいの予算と時期で進めるか」を決める段階です。
要件定義は、その枠の中で「具体的に何をシステムで実現するか」を決める段階になります。
- 困りごとと目的を書き出し、システム企画としてまとめる
- 対象の業務と部署を決め、今の業務の流れを書き出す
- 導入後の業務の流れを描き、システムに任せる部分を決める
- 機能要件と非機能要件を一覧にし、関係者とすり合わせる
- 決まらなかったことを課題一覧に残し、承認をもらう
- 要件定義書をもとに、製品選びや開発会社への提案依頼に進む
外部の会社に頼む場合は、要件定義の前に提案依頼書（RFP）を出すこともあります。
提案依頼書や要求仕様書と、要件定義書の違いは要求仕様書と要件定義書の違いで詳しく扱っています。
企画の段階で書いておきたい3行
『企画書なんて大げさなものは作っていない…』という方も多いはずです。
それでも、次の3行だけは要件定義に入る前に書いておくのがおすすめです。
- 今、何に困っているか（例：在庫の数を確かめるのに電話で問い合わせている）
- 導入後、どうなっていれば成功か（例：どの拠点からも在庫が見られる）
- いつまでに、どのくらいの予算の枠で進めるか
この3行があるだけで、要件定義の会議で「それは今回やりますか？」と聞かれた時に、判断の軸ができます。
システムの種類ごとに、要件定義で詰めておくポイント
業務システムは種類ごとに「後から揉めやすいところ」が違います。基幹、会計、勤怠管理、スマホアプリ、外部連携の5つは、要件定義のうちに詰めておくべき論点を先に知っておくと安心です。
要件定義の進め方は、どのシステムでも大きくは変わりません。
ただ、実際のプロジェクトでつまずく場所は、システムの種類によってかなり違うんです。
| システムの種類 | 要件定義で詰めておくポイント | 後回しにすると起きやすいこと |
|---|---|---|
| 基幹システム（販売・在庫・生産など） | 部署をまたぐデータの流れ、締めのタイミング、例外の扱い | 部署ごとの言い分が食い違い、仕様が固まらない |
| 会計システム | 勘定科目や部門の持ち方、締め処理、他のシステムからの取り込み | 決算や月次の締めの時期に手作業が残る |
| 勤怠管理システム | 就業規則のパターン、例外の勤務、承認の流れ、給与への連携 | 一部の勤務形態だけ手計算が残る |
| スマホアプリ・利用者向けサービス | 想定する利用者、使う場面、端末の範囲、問い合わせの受け方 | 作ってから「使われない」と分かる |
| 外部連携（外部インターフェース） | 相手先、やり取りするデータ、頻度、失敗した時の扱い | 結合のテストで初めて食い違いが見つかる |
基幹システムの要件定義：部署をまたぐ流れを先に描く
基幹システムは、販売、在庫、生産、購買など、会社の中心の業務を支えるシステムです。
基幹システムの要件定義でつまずきやすいのは、一つのデータを複数の部署が使う点です。
例えば「出荷した」という記録は、倉庫にとっては在庫が減った合図で、営業にとっては請求の準備の合図ですよね。
部署ごとに個別に聞くと、それぞれの言い分は正しいのに、つなげると食い違う、ということが起きます。
部署をまたぐ業務の流れを一枚の業務フロー図に描いてから、各部署と話すのがおすすめです。
会計システムの要件定義：締めのタイミングから逆算する
会計システムの要件定義では、日々の入力よりも「締め」の流れから考えると漏れが減ります。
月次の締め、決算の締めで、どのデータがいつまでにそろっていればいいかを先に決めておきましょう。
『会計は製品の標準どおりでいいのでは？』と思うかもしれません。
ただ、勘定科目や部門の持ち方、他のシステムからの取り込み方は会社ごとに違います。ここを決めずに進むと、締めの時期に手作業が残ってしまいます。
勤怠管理システムの要件定義：例外の勤務を全部出す
勤怠管理システムの要件定義では、標準の勤務よりも「例外の勤務」が肝になります。
シフト勤務、時差出勤、休日出勤の振り替えなど、就業規則のパターンを一通り書き出してみてください。
「ほとんどの人は定時なので、例外は後で考えましょう」と進めると、例外の人だけ手計算が残る、ということになりがちです。
承認の流れと、給与計算への渡し方もあわせて決めておくと、使い始めてからの手戻りが減ります。
スマホアプリ・サービスの要件定義：使う場面から決める
スマホアプリの要件定義では、機能の一覧より先に「誰が、どんな場面で開くか」を決めます。
社外の利用者向けのサービスなら、サービスの要件定義書に、想定する利用者と使う場面を最初に書いておきましょう。
例えば「倉庫の作業者が、手袋をしたまま片手で在庫を数える」という場面が分かれば、ボタンの大きさや入力の仕方が自然に決まります。
対応する端末の範囲や、問い合わせをどこで受けるかも、要件定義のうちに決めておきたいところです。
外部インターフェースの要件定義：相手先ごとに表で決める
外部インターフェースとは、他のシステムや社外のサービスとデータをやり取りする仕組みのことです。
外部インターフェースの要件定義は、相手先ごとに同じ項目で表にしておくと漏れが防げます。
| 項目 | 記入例（在庫管理システムと会計システムの連携・例） |
|---|---|
| 相手先 | 社内の会計システム |
| やり取りするデータ | 仕入れた品物の金額と仕入れ先 |
| 向き | 在庫管理システムから会計システムへ渡す |
| 頻度とタイミング | 毎日の業務終了後にまとめて渡す |
| 失敗した時の扱い | 担当者に知らせ、翌朝に手動で渡し直せるようにする |
| 相手先の窓口 | 経理部門の担当者 |
『連携は開発側がうまくやってくれるのでは？』と思う方もいますよね。
ただ、相手先のシステムの事情は、発注側にしか分からないことも多いです。窓口の担当者まで要件定義の段階で決めておきましょう。
画面（UI）やプログラムの要件はどこまで書く？
要件定義で決めるのは「何ができればいいか」までです。画面の細かい配置やプログラムの作りは、次の基本設計や詳細設計で決めます。ただ、使い勝手に関わる条件は要件として書いておきましょう。
要件定義の会議で、画面の色やボタンの位置の話が延々と続くこと、ありますよね。
要件定義のUIの扱いは、「どんな画面が要るか」と「使い勝手の条件」までにとどめるのが目安です。
| 書くもの | 要件定義で書く例 | 設計で決める例 |
|---|---|---|
| 画面（UI） | 在庫を検索する画面が要る。品番の一部でも探せる | 検索欄の位置、一覧の並び順、色 |
| 帳票 | 拠点別の在庫一覧を月末に出せる | 帳票の配置、文字の大きさ |
| 処理 | 出荷を登録したら在庫数が減る | 減らす処理の順番、使う仕組み |
| プログラム | 夜間にまとめて会計システムへ渡す | プログラムの分け方、内部の作り |
プログラムの要件定義という言い方もありますが、要件定義の段階ではプログラムの内部の作りまでは決めません。
「どの処理が、いつ、どんな結果を出せばいいか」を書いておけば、設計の担当者がプログラムに落とし込めます。
画面の話が細かくなりすぎた時の戻し方
画面の話が細かくなってきたら、こんなふうに戻してみてください。
「色や配置は設計の段階で画面の案をお見せします。今日は、この画面で何ができればいいかを決めさせてください」と開発側が伝えます。
「それなら、品番の一部で探せることと、拠点ごとに絞れることが要ります」と利用部門が答えます。
こうすると、要件として残すべき中身だけが議事録に残ります。
使い勝手が業務の成否を左右するシステムでは、要件定義の段階で画面のイメージを簡単に描いて見せることもあります。その場合も、決めるのは「できること」で、見た目は仮のものだと伝えておくと話がぶれません。
記入例：在庫管理システムを新しく導入する場合
要件定義書は、項目ごとに「要件」と「確かめ方」をセットで書くと、受入テストまでつながります。下の記入例は架空の題材です。
ここでは架空の題材として、「複数の倉庫の在庫を、本社と営業担当がいつでも見られる在庫管理システムを新しく導入する場合」で書いてみます。
『実際の要件定義書って、どんな粒度で書くの？』と気になりますよね。
| 区分 | 要件（在庫管理システム・例） | 確かめ方（例） |
|---|---|---|
| 目的 | 在庫の問い合わせの電話をなくし、営業担当がその場で在庫を答えられる | 導入後に問い合わせの件数の変化を見る |
| 対象範囲 | 全倉庫の入庫・出庫・棚卸し。仕入れの発注は今回の対象外 | 対象外の業務を一覧に書き、承認をもらう |
| 業務要件 | 倉庫の作業者は、入庫と出庫をその場でスマホから登録する | 倉庫で実際に登録してもらって確かめる |
| 機能要件 | 品番の一部で在庫を検索でき、倉庫ごとに絞り込める | 受入テストで検索の動きを確かめる |
| 外部連携 | 仕入れた品物の金額を、毎日会計システムに渡す | 会計システム側で取り込めることを確かめる |
| 非機能要件 | 外出先からは会社が認めた端末だけが使える | 認めていない端末で使えないことを確かめる |
| 移行 | 表計算ソフトで管理している今の在庫数を、切替日の時点で移す | 移したあとの在庫数を棚卸しと照らし合わせる |
確かめ方まで書いておくと、要件定義の内容がそのまま受入テストの観点になります。
決まらなかったことは課題一覧に残す
要件定義の会議では、その場で決まらないことも出てきます。
決まらなかったことは、要件定義書の本文に混ぜずに、課題一覧に分けて残しておきましょう。
| 課題（例） | 決める人（例） | 期限の目安（例） |
|---|---|---|
| 棚卸しの差が出た時に、誰の承認で数を直すか | 倉庫の責任者 | 基本設計に入る前 |
| 返品された品物を、在庫に戻すか別に管理するか | 営業部門と倉庫 | 基本設計に入る前 |
「決まらなかったけれど、とりあえずこうしておきましょう」と仮で書いたまま、誰も見直さない。仮で書いた内容が、いつの間にか正式な要件として扱われてしまいます。仮の内容には「仮」と書き、課題一覧にも残しておきましょう。
要件定義ガイド
まずは型をそろえよう｜要件定義書のテンプレートと記入例
章立て・各章に書くこと・1行の記入例をひとつの表にまとめました。白紙から書き始める前に、型を手元に置いておきましょう。
無料要件定義書のテンプレートを見る当サイトの記事ページに移動します。
要件定義の費用や、入れ替えの場合も見ておく
要件定義をどのくらいの体制で進めるかは、プロジェクトの規模と予算にも関わってきます。
見積もりの読み方は要件定義の費用相場で、今あるシステムを入れ替える場合の進め方はシステム移行・リプレースの要件定義で解説しています。
RPAや小さく試すPoCから始める場合は、RPA・DX・PoCの要件定義もあわせて読んでみてください。
よくある相談に答えます
- 要件定義の経験は、実際のプロジェクト以外で積めないのか
- 世の中のアプリの要件定義は、誰がどうやって決めているのか
- 工場など現場へのシステム導入で、要件定義を初めて任された
要件定義の経験は、実際のプロジェクトでしか積めない？
プログラミングは独学できても、要件定義や基本設計は経験を積む方法が分からない、という相談はよくあります。
結論から言うと、本番のプロジェクトでなくても、練習できることはたくさんあります。
例えば、身の回りの業務を一つ選んで、今の流れを業務フロー図に描き、困りごとと目的を3行で書いてみてください。
そこから「システムに任せること」を一覧にすれば、小さな要件定義書の形になります。
職場で機会があるなら、要件定義の会議の議事録を書く役を引き受けるのも近道です。何が決まり、何が決まらなかったかを書き分けるうちに、要件定義の勘どころが見えてきます。
アプリの要件定義は、誰がどう決めている？
世の中のアプリは、依頼主と作る会社がどうやって中身を決めているのか、という疑問も見かけます。
受託で作る場合は、依頼主が「こうしたい」を伝え、作る側がそれを要件に整えて、両者で合意するのが一般的です。
自社のサービスとして作る場合は、企画の担当者や事業の責任者が、利用者の使う場面をもとに決めていきます。
どちらの場合も、「誰が、どんな場面で使うか」を先に決める点は同じなんです。
工場へのシステム導入で、要件定義を初めて任された
これまで設計や開発の管理が中心で、現場へのシステム導入の要件定義は初めて、という相談もあります。
現場への導入では、会議室で話を聞くだけでは見えないことが多いです。
『現場の人は忙しそうで、時間を取ってもらいにくい…』と感じるかもしれません。
それでも、一度は作業の場に立って、実際の手順と、手袋やほこりなど作業の条件を見せてもらうのがおすすめです。
その上で、上の表の「業務要件」と「非機能要件」の行を、現場の言葉で書き直してみてください。
よくある質問
プロジェクトの要件定義では何を決めますか？
目的、対象範囲、業務要件、機能要件、非機能要件、制約や前提を決めます。決まらなかったことは課題一覧に残し、承認をもらってから設計に進みます。
システム導入とシステム構築の要件定義は違いますか？
ほぼ同じ意味で使われます。既製の製品を入れる場合は、製品の標準に合わせる業務と、合わせられない業務を決める作業が中心になります。
要件定義でUIの細かいデザインまで決めますか？
多くの場合、決めるのは「どんな画面が要るか」と「使い勝手の条件」までです。配置や色などは、基本設計で画面の案を見ながら決めます。
外部インターフェースの要件定義で決めることは？
相手先、やり取りするデータ、向き、頻度とタイミング、失敗した時の扱い、相手先の窓口を決めます。相手先ごとに同じ項目で表にすると漏れが防げます。
要件定義を外部の支援サービスに頼んでもいいですか？
頼むことはできます。ただ、目的や業務の判断は発注側にしかできないので、業務部門の担当者が会議に出て決める体制は残しておきましょう。
まとめ
- プロジェクトの要件定義は、目的と範囲、システムに任せることを合意して書き残す工程
- システム企画で決めた目的と予算の枠の中で、要件定義を進める
- 基幹、会計、勤怠管理、スマホアプリ、外部連携は、種類ごとに詰めどころが違う
- UIやプログラムは「何ができればいいか」まで書き、見た目や作りは設計で決める
- 要件には確かめ方をセットで書き、決まらなかったことは課題一覧に残す
コメント