「システム開発の要件定義って、結局なにを決める工程なの？」「要件定義書には何を書けばいいの？」「そもそも誰がやるもの？」と迷っていませんか。
要件定義とは、システム開発の最初に「何を作るか」を決め、発注者と開発者で合意する工程です。ここで固めた内容が後のシステム開発工程すべての前提になるため、要件定義の精度がプロジェクトの成否を大きく左右します。
この記事では、要件定義の意味と役割、業務要件・機能要件・非機能要件の3要素、基本設計や仕様書との違い、要件定義書に書く項目とサンプル・テンプレート、進め方、担当者、成果物、よくある失敗までをまとめて整理します。
＼ 無料相談・お見積り受付中！ ／
システム開発における要件定義とは
要件定義とは、システム開発で「何を作るか」を決める工程です。発注者の要望を整理し、これから開発するシステムが満たすべき条件を文書としてまとめます。
家を建てるときの設計図を描く前の打ち合わせをイメージするとわかりやすいでしょう。「何部屋ほしいか」「予算はいくらか」「いつまでに住みたいか」を先に決めなければ、設計も工事も始められません。システム開発でもこの最初の合意づくりが要件定義にあたります。
要件定義の目的と役割
要件定義の役割は、発注者と開発者の認識をそろえ、開発の土台を固めることにあります。果たす目的は大きく3つです。
- 発注者と開発者の合意形成（認識のズレを防ぐ）
- 開発範囲（スコープ）の確定
- 設計・開発・テストといった後工程の前提整理
たとえば「在庫を管理したい」とだけ伝えて開発を始めると、発注者は自動発注まで想定していたのに、できあがったのは在庫を入力するだけのシステムだった、というズレが起こりがちです。
より具体的に、「在庫を管理して自動的に発注数がわかる仕組み」といった、実現したい事への認識を揃えることで、「思っていたものと違う」といったことを防ぐことができます。
システム開発の要件定義書に書く項目と構成
要件定義の成果は、最終的に「要件定義書」という文書にまとめます。決まった様式があるわけではありませんが、一般的によく使われる構成があります。
| 章 | 記載する内容 |
|---|---|
| 1. 背景・目的 | プロジェクトの背景と達成したいゴール |
| 2. 業務要件 | 対象業務の範囲とあるべき姿（業務フロー） |
| 3. 機能要件 | 実装する機能の一覧と内容 |
| 4. 非機能要件 | 性能・可用性・セキュリティなどの基準 |
| 5. 制約条件 | 予算・期間・技術・法令などの制約 |
| 6. スケジュール・体制 | 開発全体の工程と関係者の役割分担 |
システム開発の要件定義で作る成果物
要件定義の工程では、要件定義書のほかにもいくつかの成果物が作られます。何が出てくるのかを知っておくと、開発会社とのやり取りがスムーズになります。
- 要件定義書（中心となる成果物）
- 業務フロー図（As-Is／To-Be）
- 機能一覧・画面一覧・帳票一覧
- システム化方針書
- 課題管理表・用語集
どこまで作るかはプロジェクトの規模によります。小規模なら要件定義書と機能一覧だけ、というケースもあるため、必要な成果物を事前にすり合わせておきましょう。
システム開発における要件定義の進め方とスケジュール
要件定義は、行き当たりばったりでは進みません。現状把握 → 課題整理 → 文書化と合意という流れを踏むのが基本です。代表的な3ステップを順に紹介します。
ステップ1：ヒアリングと現状把握
最初に、現場の担当者から業務の進め方や困りごとをヒアリングします。いまの業務フロー（As-Is）を正確につかむのがこのステップのゴールです。
実際のヒアリングは、次のように現状を掘り下げます。
開発担当いまの受注業務は、どんな流れで進めていますか？
発注者電話とFAXで注文を受けて、担当が一件ずつExcelに手入力しています。
その手入力で、ミスや時間がかかって困っている場面はありますか？
このように「手作業のどこに無駄やミスがあるか」まで引き出せると、後の要件漏れを防げます。
ステップ2：課題整理とTo-Be設計
次に、洗い出した課題を整理し、「あるべき姿（To-Be）」を描きます。現状のどこを、システムでどう良くするのかを具体化していく段階です。
改善案は、こんなやり取りで方針を固めていきます。
開発者その手入力をなくすなら、注文をWebフォームで受ける形が考えられます。
発注者いいですね。ただ、電話で注文する常連さんも多いので、すべては切り替えられません。
開発担当では今回はWebフォームを優先で入れて、電話分は手入力を残す形にしましょう。
すべての要望を盛り込むと予算も期間も膨らむため、こうして「今回やること・やらないこと」を線引きするのが大切です。
ステップ3：要件の文書化と合意形成
整理した内容を要件定義書としてまとめ、関係者でレビューして合意します。発注者・開発者の双方が「この内容で進める」と確認できれば、要件定義は完了です。
合意は、次のように最終確認しながら固めます。
開発者今回の範囲は「Webフォームでの受注」と「入力の自動データ化」まで、で合っていますか？
受注者はい。それに加えて、電話での注文に対して簡単にデータを入力・管理できるとありがたいです。
開発者かしこまりました。では要件定義書にそう明記してから作業を開始させます。
口頭の「言った・言わない」を避けるためにも、決めたことは必ず文書に残しておきましょう。
＼ 無料相談・お見積り受付中！ ／
システム開発の要件定義書サンプル・テンプレート
ゼロから要件定義書を作るのは大変です。そこで、IPA（情報処理推進機構）が無料公開する資料が参考になります。
業務流れ図やデータ項目定義書といった成果物のサンプルとフォームが収録されており、自社の要件定義書のひな形としてそのまま参考にできます。公的機関の資料なので、内容の信頼性が高いのも安心材料です。
形式別テンプレートの選び方（Excel・Word・PowerPoint・PDF）
要件定義書は、用途によって作りやすいファイル形式が変わります。「何で作るか」で迷ったら、次の使い分けを目安にしてください。
| 形式 | 向いている用途 |
|---|---|
| Excel | 機能一覧や項目表など、表形式で管理したいとき |
| Word | 文章中心の要件定義書の本体を作るとき |
| PowerPoint | 概要を説明し、関係者と合意を取る資料にするとき |
| 配布・承認用の確定版として共有するとき |
システム開発の要件定義は誰がやる？担当者と体制
要件定義は、発注者と開発会社（ベンダー）が協力して進めるものです。「開発会社に任せておけばいい」と思われがちですが、発注者側の関わりも欠かせません。
発注者側の役割（業務知識の提供・意思決定）
発注者の役割は、業務の中身を伝えることと、決断することです。実際の業務を知っているのは発注者自身なので、現場の流れや困りごとを正確に共有する必要があります。
「どの機能を優先するか」「予算内で何を諦めるか」といった意思決定も、発注者にしかできない大切な仕事です。
開発会社側の役割（ヒアリング・整理・文書化）
開発会社（ベンダー）は、発注者の話を引き出して要件として整理し、文書にまとめるのが役割です。要件定義書を実際に書くのは、上流を担当するSEやコンサルタントであることが多くなります。
たとえば「紙の申請をなくしたい」という要望に、「いま使っているチャットツールと連携すれば新しい画面を覚えずに済みます」と代替案を出すなど、専門的な観点からの提案も開発会社の腕の見せどころです。
システム開発の要件定義でよくある失敗と対策
要件定義はプロジェクトの土台だけに、ここでのつまずきが後々まで響きます。代表的な失敗パターンと、その対策を押さえておきましょう。
要件漏れによる工数増加
もっとも多いのが要件の漏れです。後から「あの機能も必要だった」と判明すると、追加開発の費用やスケジュールでもめる原因になります。
「要件定義書に書いてあったか」が責任分界の判断材料になるため、決めたことは曖昧にせず文書に残すのが対策です。発注者側も、内容をきちんと確認してから合意するようにしましょう。
細かすぎる要件定義による問題
要件は、細かすぎても粗すぎても問題になります。案件による話ではありますが、たとえばボタンの色や文言まで要件定義書で固めてしまうと、設計の段階で変えたくなるたびに書き直しが発生し、かえって時間を取られます。
逆に、開発会社へ丸投げして粗いまま進めると、現場に合わないシステムになりかねません。適切な粒度で要件を決め、発注者と開発者が一緒に詰めるバランスが大切です。
システム開発の要件定義を構成する3要素（業務要件・機能要件・非機能要件）
要件定義で固める要件は、大きく業務要件・機能要件・非機能要件の3つに分けられます。それぞれ「決めること」が異なるため、まずは全体像を表で押さえましょう。
| 要素 | 決めること | 具体例 |
|---|---|---|
| 業務要件 | 業務をどう改善したいか（あるべき姿） | 受注処理の時間を半分にする／二重入力をなくす |
| 機能要件 | システムに実装する機能 | 検索機能・帳票出力・承認ワークフロー |
| 非機能要件 | 性能・運用・セキュリティなどの品質 | 100人同時接続・夜間自動バックアップ・アクセス権限 |
業務要件（ビジネス側の要件）
業務要件は、「そもそも何の業務を、どう良くしたいのか」を定めるものです。システムの機能を考える前に、解決したい課題や達成したいゴールを言葉にします。
たとえば「紙の申請をなくして承認を早くしたい」「在庫の数え間違いを減らしたい」といった内容です。業務要件があいまいだと、後の機能要件もぶれてしまうため、ここが要件定義の土台になります。
機能要件（システムの機能仕様）
機能要件は、業務要件を実現するためにシステムへ実装する機能を具体的に決めるものです。画面・入力項目・検索・帳票出力・データ連携など、「システムがやること」を一覧化していきます。
「承認を早くしたい」という業務要件であれば、「申請フォーム」「承認ワークフロー」「承認状況の通知メール」といった機能に落とし込むイメージです。
非機能要件（性能・セキュリティ・運用）
非機能要件は、機能以外の「品質」や「使い勝手」を決めるものです。動作の速さ、止まりにくさ、セキュリティ、運用のしやすさなど、表に出にくいものの軽視できない条件が含まれます。
IPA（情報処理推進機構）が公開する「非機能要求グレード」では、非機能要件を可用性・性能拡張性・運用保守性・移行性・セキュリティ・システム環境の6つの大項目で整理しています。たとえば「月末に処理が集中しても画面は3秒以内に開く」「障害が起きても1時間以内に復旧する」といった条件が非機能要件にあたります。後回しにされやすい領域なので、要件定義の段階で意識して決めておきましょう。
システム開発の要件定義に関するよくある質問
システム開発の要件定義は誰がやるのですか？
発注者と開発会社が協力して進めます。要件定義書を書くのは開発会社の上流SEやコンサルタントが中心ですが、業務知識の提供と意思決定は発注者の役割です。どちらか一方では成り立たない工程といえます。
要件定義はどれくらいの期間がかかりますか？
規模によって変わります。小規模なシステムで数週間、中規模以上では1〜3か月ほどが目安です。対象業務の広さや関係者の人数が増えるほど、合意までに時間がかかります。
富山の有限会社シーズプランニングでは、WEBシステム開発やFileMakerを活用した業務システム開発を長年にわたり手がけています。
私たちが大切にしているのは、「超現場主義」の姿勢です。単にご依頼いただいたものを形にするだけの外部業者ではなく、お客様の業務や課題を深く理解し、要望の先にあるプラスアルファの解決策まで汲み取ることをモットーとしています。
また、圧倒的なフットワークの軽さと、柔軟な開発対応も私たちの強みです。「ちょっとした相談をすぐにしたい」「困ったときにすぐ駆けつけてほしい」といったご要望にも、地元・富山に根ざした企業だからこそのスピード感でお応えします。社内の行動規範として、メールへのレスポンスは基本15分以内を掲げています。
「今の業務をシステム化できるか相談したい」「やりたいことはあるが、まだ整理できていない」といった段階でのお問い合わせも歓迎しています。どうぞお気軽にご相談ください。
＼ 無料相談・お見積り受付中！ ／
