メインコンテンツへスキップ

システム開発の要件定義の進め方|失敗しない手順と決めること

2026.06.09

システム開発で最も失敗が起きやすい工程はどこか——多くの現場で挙がるのが「要件定義」です。結論から言うと、要件定義の精度がプロジェクト全体の成否をほぼ決めます。ここがあいまいなまま進むと、後工程で手戻り・追加費用・納期遅延が連鎖します。本記事では、要件定義とは何かから、失敗しない進め方の手順、決めるべき項目、要件定義書の中身、期間・体制の目安、そして発注側がやるべきことまでを、そのまま使える形で解説します。なお、要件定義は発注プロセス全体の一部です。全体の流れはシステム開発の発注完全ガイドで解説しています。

要件定義とは?#

要件定義とは、「何を・なぜ・どこまで作るか」を具体化し、要件定義書としてまとめる工程です。大きく、業務要件(どんな業務をどう変えるか)、機能要件(そのために必要な機能)、非機能要件(性能・セキュリティ・可用性など)の3つに分けて整理します。設計・開発の前段にあたる「上流工程」で、ここで決めた内容が後工程すべての土台になります。

なぜ要件定義が重要なのか?#

システム開発のトラブルや手戻りの多くは、要件定義のあいまいさに起因します。要件が固まらないまま開発に進むと、「作ってから違うと分かる」ことになり、修正コストは後工程ほど大きくなります。一般に、上流での修正は文書の直しで済みますが、開発後の修正はプログラムの作り直しになり、はるかに高くつきます。だからこそ、最も時間をかけるべきは要件定義です。なお、独立行政法人情報処理推進機構(IPA)と経済産業省が公表する情報システム・モデル取引・契約書(第二版)|IPAは、工程ごとに個別契約を結ぶ構造を前提に作られており、要件定義も独立したフェーズとして扱われています。

要件定義の進め方(手順)#

要件定義は、次の順で進めると抜け漏れが減ります。

要件定義の進め方(現状・課題整理→業務フロー可視化→要件の洗い出し→優先度づけ→要件定義書)
要件定義の進め方(現状・課題整理→業務フロー可視化→要件の洗い出し→優先度づけ→要件定義書)
  1. 1現状・課題整理:今の業務の困りごとと、解決したい状態を洗い出す
  2. 2業務フロー可視化:誰が・いつ・何をしているかを図にして共有する
  3. 3要件の洗い出し:業務・機能・非機能の観点で必要なことを集める
  4. 4優先度づけ:Must/Wantに分け、予算と段階リリースを見据える
  5. 5要件定義書:合意した内容を文書にまとめ、関係者で確認する

最初に現状の業務フローを可視化すると、「今の困りごと」と「あるべき姿」の差が見え、必要な要件が具体化します。いきなり機能の話から入らないことがコツです。

要件定義で決めることは?#

具体的には、次の4つの観点で決めていきます。

要件定義で決めること(業務・機能/画面・データ/非機能/運用・権限)
要件定義で決めること(業務・機能/画面・データ/非機能/運用・権限)
  • 業務・機能:何を実現するか(対象業務と必要な機能)
  • 画面・データ:入力・出力する項目、帳票、画面の流れ
  • 非機能:性能・セキュリティ・可用性・運用などの品質要件
  • 運用・権限:誰がどの権限で使うか、運用ルール

特に非機能要件は見落とされがちですが、後から「遅い」「セキュリティが足りない」となると影響が大きいため、早めに決めます。

要件の洗い出しチェックリスト(そのまま使える)#

次の観点で洗い出すと、抜け漏れを防げます。ヒアリングや社内検討のチェックリストとしてそのまま使えます。

  • 業務要件:対象業務/現状の業務フロー/困っていること/変更後のあるべき流れ/関係する部署・人・例外業務
  • 機能要件:必要な画面・帳票/扱うデータ項目/処理(登録・検索・承認・出力・外部連携)/利用者の権限
  • 非機能要件:性能(同時利用者数・応答速度)/可用性(停止が許される時間)/セキュリティ(認証・権限・ログ)/運用・保守(バックアップ・監視)/データ移行(対象・量)

機能要件と非機能要件の違い(具体例)#

混同されやすいのが、機能要件と非機能要件です。

  • 機能要件は「何ができるか」。たとえば「在庫を登録・照会できる」「注文を承認できる」「月次の売上をCSVで出力できる」など、システムが行う動作です。
  • 非機能要件は「どのくらいの品質で動くか」。たとえば「100人が同時に使っても3秒以内に表示する」「個人情報を暗号化する」「平日9〜18時は止まらない」「データは毎日バックアップする」など、性能・セキュリティ・可用性・運用に関わる条件です。

機能要件ばかりに目が行き、非機能要件が後出しになると、「動くけれど遅い・不安」というシステムになりがちです。両方をセットで決めることが重要です。

要件定義書には何を書く?(目次の例)#

要件定義書に決まった様式はありませんが、迷ったら次の構成をベースにすると過不足が出にくくなります。そのままコピーしてひな形として使えます。

  1. 1背景・目的(なぜ作るのか、解決したい課題)
  2. 2対象業務と現状の業務フロー
  3. 3機能要件(機能の一覧と概要、優先度)
  4. 4画面・帳票・データ項目
  5. 5非機能要件(性能・セキュリティ・可用性・運用)
  6. 6運用・権限(利用者と権限、運用ルール)
  7. 7前提・制約(既存システム、データ、社内ルール)
  8. 8用語の定義

大切なのは、関係者が読んで「同じ理解」を持てることです。専門用語には定義をつけ、図や表で補うと、認識のずれを防げます。

MustとWantを分ける#

すべてを必須にすると、予算も期間も膨らみます。要件には優先度をつけ、Must(必須)から段階的に作るのが基本です。Wantは次フェーズに回す、という判断ができると、初期費用を抑えつつ早く使い始められます。優先度をつけるときは、「それがないと業務が回らないか」を基準にすると、MustとWantを切り分けやすくなります。費用との関係はシステム開発費用の相場もあわせてご覧ください。

要件定義にかける期間・体制の目安#

要件定義の期間は規模によりますが、小規模で数週間、中〜大規模で1〜数か月が一つの目安です。ここを焦って短くすると、後工程の手戻りで結局時間がかかります。体制としては、発注側の担当者に加えて、実際にシステムを使う現場のキーマン、意思決定できる責任者を巻き込むことが重要です。現場が入らないまま決めた要件は、「実際の業務に合わない」という失敗につながりやすくなります。

要件定義は誰がやる?(発注側が主導する)#

要件定義は、発注側が主導するほど精度が上がります。現場のキーマンを巻き込み、実際の業務に即した要件にすることが重要です。とはいえ、自社だけで進めるのが難しい場合は、開発会社の要件定義力を借りる方法があります。その際は、要件が固まっていない段階を準委任契約で密に進め、固まってから本開発を請負契約で、と分けると進めやすくなります(請負契約と準委任契約の違い)。社内に技術が分かる人がいない場合は、外部の技術責任者(スポットCTO)に発注側の立場でレビューしてもらう方法もあります。

要件定義でよくある失敗#

  • 現場を巻き込まず、一部の人だけで決めてしまう
  • すべてを「Must」にして、優先度がつかない
  • 非機能要件(性能・セキュリティ)を後回しにする
  • 口頭の合意だけで文書化せず、認識のずれが残る
  • 例外業務・繁忙期の運用を考慮せず、後で破綻する

より詳しい失敗パターンと回避策はシステム開発が失敗する理由で整理しています。

弊社(株式会社TryWith)の要件定義支援について#

弊社では、システムの受託開発に加えて、要件定義や業務整理の段階からご支援しています。現場へのヒアリングと業務フローの可視化を通じて、「何を作るか」を発注側の立場で一緒に固めます。要件定義だけのご依頼や、固めた要件をもとにした開発まで、状況に合わせて対応します。社内に技術が分かる人がいない場合も、スポットCTO的な関与で要件・見積もりを発注側の視点で補えます。

よくある質問(FAQ)#

Q. 要件定義にはどれくらい期間がかかりますか?

A. 規模によりますが、小規模で数週間、中〜大規模で1〜数か月が目安です。ここに十分な時間をかけるほど、後工程の手戻りが減ります。

Q. 機能要件と非機能要件の違いは何ですか?

A. 機能要件は「何ができるか」(在庫を登録できる、など)、非機能要件は「どのくらいの品質で動くか」(同時100人でも3秒以内、など)です。両方をセットで決めることが大切です。

Q. 要件定義だけを依頼できますか?

A. できます。要件定義のみを準委任契約で依頼し、固まった要件をもとに開発会社を選ぶ、という進め方も可能です。開発会社の選び方は失敗しないシステム開発会社の選び方もご覧ください。

Q. 要件定義書には何を書きますか?

A. 背景・目的、業務フロー、機能要件、画面・データ、非機能要件、運用・権限、前提・制約などをまとめます。関係者が同じ理解を持てることが目的です。本記事の目次例をひな形にできます。

Q. 要件がどうしても固まらない場合は?

A. 最初から完璧を目指さず、Mustを中心に固めて段階的に作る方法があります。動くものを見ながら要件を詰めるアジャイル型のアプローチも有効です。

まとめ#

要件定義は、システム開発で最も成否を左右する工程です。現状整理 → 業務フロー可視化 → 要件の洗い出し → 優先度づけ → 要件定義書、の順で、業務・機能・画面・データ・非機能・運用まで、発注側が主導して固めます。本記事の洗い出しチェックリストと要件定義書の目次例を、そのままお使いください。機能要件と非機能要件をセットで決め、関係者が同じ理解を持てる要件定義書にまとめることが、後工程の手戻りを防ぐ鍵です。要件をRFPにまとめる方法はRFPの書き方、発注全体の流れはシステム開発の発注完全ガイドで解説しています。

(出典:情報システム・モデル取引・契約書(第二版)|IPA・経済産業省(2020年12月22日公表))

要件定義でお困りの場合は、現状の課題整理からご相談いただけます。まずはお問い合わせはこちらからお気軽にご相談ください。

タグ

#要件定義#システム開発#発注#上流工程#業務要件#非機能要件