目次
最終更新日：2026年7月27日
システム開発の成功を左右するともいわれる重要な工程、「要件定義」。この記事では要件定義とはどのようなものなのか、具体的な流れと成果物（アウトプット）、機能要件と非機能要件の違い、要件定義をスムーズに行うコツを紹介します。
受注側だけではなく、発注側はどのようにすればスムーズに要件定義ができるのかもまとめました。あわせて、社内だけで要件定義を進めるのが難しい場合に外部の支援を受けるという選択肢についても触れています。この記事がお役に立ちましたら幸いです。
要件定義とは
要件定義とは、開発するシステムに求められる要件（機能要件・非機能要件）を定め、何を作り、何を作らないかを確定させる工程です。システムの完成イメージに大きくズレがないかを定義する、システム開発のスタート地点となる重要な工程です。ウォーターフォール型の開発では原則として前の工程に逆戻りしないため、特に重要な工程となります。
なお、一度にすべてを固めきるのが難しい場合は、優先度の高い範囲から段階的に確定させていく進め方もあります。どこまでを最初に決めるかは、案件の性質によって変わります。
通常は要件定義の内容に沿って見積もりを作成します。要件に定義されていない要求は実装されません。要件定義は、受注側（システム開発会社側）だけではなく、発注側の協力が必須のフェーズです。逆に言えば、発注側が要件を決めきれないとプロジェクト全体が止まります。この点については「要件定義が進まないのは誰の責任か」で詳しく書いています。
要件定義の具体的な流れ
要件定義はどのように進むのか、具体的な流れと、各段階で何がアウトプットとして出てくるのかを紹介します。
目標設定
要件定義ではまず、システム導入をした結果達成されるべき目標を設定していきます。達成されるべき内容は、システムの種別によって異なってきます。
業務システムの場合、多くはコスト削減や省力化が目的となるため、人件費や通信費の削減が目標として設定されることが多いです。ただし、売上の拡大、品質の安定、属人化の解消といった目的で導入されるケースもあります。
Webサービスの場合、大半の目的は売り上げアップであるため、コンバージョンの獲得やLTV（顧客生涯価値）、解約率、受注数、受注金額、利益率にフォーカスして目標が設定されることが多いです。
ヒアリング
システムを実装する際に、何が必要で何が必要ないかをヒアリングをして明確にしていきます。問題解決や事業促進のお手伝いができるように、システム開発依頼の背景も確認していきます。
業務システムの場合、課題解決の対象となる業務の流れを把握するところから始めることが多いです。Webサービスの場合、業務の流れに加えて競合調査や顧客の動向などの把握から始めることがあります。
いずれの場合でも、現在抱えている課題をシステムに関することだけではなく、人やモノに関する問題を含めてヒアリングを進めていきます。例えば以下のような課題を洗い出していきます。
- 現状のシステムで誰も見ていない情報が出力されている
- システムの情報は利用せずに、個人個人がExcelで情報を管理しており、またその情報が共有されていない
- 請求書をプリントアウトして封入して郵送する作業に2日かかっている……など
ドキュメントが残っていない既存システムを刷新する場合は、そもそも現状の業務がどう回っているのかを誰も把握できていない、ということも珍しくありません。近年はこうしたケースでも、ソースコードやデータベースの構造をAIで解析して現状の業務フローを起こすところから始められるようになりました。「資料がないから手が出せない」という前提は、以前より緩くなっています。
要件定義書の作成と合意
目標設定とヒアリングが終わったら、要件定義書を作成していきます。この段階で要件定義書、サーバー構成図、業務フロー図を作成することが多いです（詳細は次章）。
作成にあたっては、打ち合わせの議事録や各部門から出てきた要望メモをもとに、AIで要件のドラフトを起こしたり、要件同士の矛盾や抜け漏れを洗い出したりといった使い方もできるようになりました。ただし出てきた内容が業務として妥当かどうかを判断するのは人間の仕事です。ここを省略すると、もっともらしいが現場では使えない要件定義書ができあがります。
最後に、作成した要件定義書の内容について発注側と受注側で合意します。ここで確定した要件をもとに見積もりが作られ、以降の工程が始まります。
要件定義のアウトプット（成果物）
要件定義のフェーズで作られる代表的な成果物は次の3つです。
要件定義書
システム化する機能、システムを利用するアクター（＝ユーザーの種別）を定義し、アクターごとに求められる機能要件を記載します。
運用するドメイン、サポートブラウザ、外部システムとの連携有無、認証方式や権限設計、必要なライセンスなど決定できる事項は決定していきます。この時点で決定できない事項は次のフェーズに持ち越します。
サーバー構成図
システムを設置するサーバーの構成を記載していきます。要件定義のフェーズでは決定しないこともあります。
業務フロー図
システムを導入した後の業務の流れについて、人の動きとシステムの動きを含めて図式化していきます。
なお、これらの成果物は要件定義を通過するための書類ではありません。開発が終わったあと、改修や担当者の引き継ぎが発生したときに効いてきます。ここで作った資料が残っているかどうかで、後の保守のしやすさが変わります。詳しくは「システム開発でドキュメントがないとどうなる？」をご覧ください。
要件定義で何をどこまで決めるか
要件定義で決めていく代表的な項目は次のとおりです。
- システム化の背景・目的
- システムの概要
- システム化する範囲
- システム構成
- システムの全体像・概念図
- 開発スケジュール……など
一方で、「これは要件定義で決める／これは決めない」と一律に線を引くことはできません。運用・保守のレベル、品質管理の基準、インフラ要件の詳細などは、案件によって扱いが変わります。
たとえば運用のイメージが発注者側で明確にできている業務であれば、要件定義の時点で運用まで具体的に決めてしまえます。逆に、そこがイメージできていないからこそ要件定義の場で一緒に検討する、というパターンもあります。前者で無理に後工程へ送れば手戻りになりますし、後者で無理に決めさせようとすれば、根拠のない数字が要件として残るだけです。
原則は一つで、決めるべきことをあやふやにしたまま次の工程に進まないということです。決められないなら「今は決まっていない／いつまでに誰が決める」を明示して先に進む。この扱いが曖昧なまま設計・製造に入ったプロジェクトが、後で燃えます。
なお、運用・保守を「後で考えること」として要件定義の議題から外してしまう進め方は、あまりおすすめできません。システムの寿命とランニングコストを実質的に決めているのは、この段階の判断だからです。アクシアが要件定義の時点から運用・保守の話をする理由は、この記事の後半「アクシアでの考え」で触れています。
機能要件と非機能要件
重要となる機能要件と、非機能要件について詳しく説明していきます。
機能要件について
機能要件とは、要件定義のうち必ず搭載すべき機能のことを指します。発注側の要望の中で必ず機能化すべき要件のことで、要件定義書に詳しく記載していきます。
非機能要件について
ざっくりというと「機能化しない要件すべて」を指します。そのため、非機能要件は広範囲にわたります。
代表的なものとして、
- パフォーマンス
- 保守性
- 可用性
- 効果目標
- ユーザビリティ
などがあります。詳しく見ていきましょう。
パフォーマンス
システムに求められる性能要件を指します。例えば、予約照会ボタンを押してから結果が出るまで3秒以内にすること、同時接続数1000ユーザーでシステムのパフォーマンスが低下しないようにすること、などです。
保守性
保守に求められる要件を指します。例えば、メンテナンス時に許容される停止時間は夜間〜早朝で最大2時間にする、システムを自動監視し異常発生時に人が対応する/自動復旧する、データのバックアップを毎日取得し3年間保存する、セキュリティーアップデートを毎月実施する、などがあります。
可用性
システムを障害（機器やパーツの故障・災害・アクシデントなど）で停止させることなく、稼働し続けることを指します。システムを停止させることなく稼働し続ける時間の割合が高いことを「可用性が高い」、割合が低いことを「可用性が低い」といいます。
例えば、システムが1台のサーバーで運用されている場合に、そのサーバーが停止したらシステム全体が停止する状態は「可用性が低い」状態といえます。「可用性が高い」状態を具体的に説明すると、以下のようになります。
- システムが1台のサーバーで運用されているが、予備のサーバーが停止状態でスタンバイしている（コールドスタンバイ）
- システムが1台のサーバーで運用されているが、予備のサーバーが稼働状態でスタンバイしている（ホットスタンバイ）
- システムが常時2台以上のサーバーで分散処理されて稼働しており、どれかが停止しても即停止にならない
- システムが常時2台以上のサーバーで分散処理されて稼働しており、異常が発生した場合自動復旧する
1〜4に進むにつれて、より可用性の高い状態となります。可用性を上げるほど運用コストが高くなるため、要件としてどのレベルの可用性にするのかを決めておく必要があります。「止まったら困る」で最高レベルを選ぶのではなく、実際に止まった時にどれだけの損失が出るのかと見比べて決めるのが現実的です。
効果目標
システムを導入した結果、達成されるべき効果目標を指します。例えば、業務システムの場合、月末請求処理にかかっている人的コストが40％削減されていることや、Webサービスの場合、月間のコンバージョンが導入前の120％を達成していること、などです。
ユーザビリティ
システムの使い勝手のことを指します。他の非機能要件に比べて数値化しにくいため、ガイドラインを定めてシステム内の使い勝手の標準化を図ることで実現することが多いです。
非機能要件は発注側のニーズや背景を理解し、適切なものを盛り込んでいきます。発注側があらかじめ決めていることもあれば、受注側が必要なものを提案することもあります。非機能要件は機能要件に比べて抜けやすいのが実務上の悩みどころで、チェックリストとの突き合わせにAIを使うと漏れを減らせます。抜けたまま開発が進むと、稼働後に「思っていたより遅い」「止まった時に誰も気づけない」といった形で表面化します。
要件定義をスムーズに行うコツ
要件定義をスムーズに進めるにはどうしたらいいのか、受注側、発注側、アクシアの考えの3つに分けてご紹介します。
受注側
依頼者の業務や社内の事情、業界の商習慣などを深くヒアリングして理解を深め、問題を解決するためにはどのようなシステムが望ましいかを提案できる能力が求められます。
言われたとおりにやる、言われていないからやらないというスタンスではなく、表面化している事象の本質的な問題を見つけ、システムのプロとして依頼者だけでは発想できない提案をできるのがベストです。
発注側
受け身の姿勢ではなく、システム導入で解決したい問題について、はっきりとシステム会社に伝える必要があります。自社の関係部署を巻き込み、必要な情報の提供に協力を得る調整力が求められます。要件定義の場が社内調整の場になってしまうと、開発会社には手の打ちようがありません。部署間で要求が食い違っている場合は、先に社内で優先順位をつけておくとスムーズです。
アクシアでの考え
発注側、受注側でどうしても上下関係が発生しやすい中、課題解決に向けては両社ワンチームで、同じ目線で同じ目標をもって取り組んでいくことをお伝えしています。また、課題解決に向けてワンチームで行う雰囲気づくりをアクシアでは重視しています。
受託開発というビジネスの特性上、初期開発時の売り上げが大きくなるため、作って終わりになりがちです。その後の運用保守を敬遠する業者も多いと聞きます。
アクシアでは、お客様に接するメンバーには「本番稼働してからが本番」というスローガンを徹底してもらっています。要件定義時でもその後の運用負荷やシステムの継続性を意識した保守・運用の提案を行っています。お客様からの信頼だけでなく、システム導入効果を最大に引き出すことを重視しています。
要件定義を外部に支援してもらうという選択肢
ここまで「発注側の協力が必須」と書いてきましたが、社内にシステム開発の経験者がいない場合、そもそも何をどう決めればいいのかが分からない、というのが実情だと思います。その場合は、要件定義だけを切り出して外部の専門会社に支援してもらうという進め方があります。
ここで注意していただきたいのは、要件定義を外部に丸投げすることはできないということです。何を解決したいのかを知っているのは発注者自身であり、そこを代わりに決めてもらうことはできません。現実的なのは、システム会社の人間にプロジェクトメンバーの一員として加わってもらい、要件の整理・優先順位づけ・コスト感の提示を一緒にやってもらう形です。
この進め方の具体的な内容と、実際のお客様の事例（3ヶ月間のコンサルティング契約で週1回の要件定義ミーティングに参加し、結果として「今は開発しない」という判断に至ったケース）については「要件定義だけ先に発注するという進め方」で詳しくご紹介しています。
また、要件定義が始まっているのに議論が前に進まないという状態であれば、原因の切り分けが先です。「要件定義が進まないのは誰の責任か」に典型パターンと打ち手をまとめています。第三者の視点で進行や提案内容を診断するセカンドオピニオンや、月額制でITの相談相手を持てるIT顧問サービスという選択肢もあります。
要件定義のよくある疑問
要件定義にはどれくらいの期間がかかりますか？
システムの規模や、発注者側でどこまで整理ができているかによって大きく変わるため、一律に「何ヶ月」とは言えません。前提となる業務が整理されていれば短く済みますし、現状の業務フローを起こすところから始める場合はその分の時間が必要です。期間を先に決め打ちするより、何が決まったら要件定義が終わったと言えるのかを先に合意しておくほうが、結果的に早く終わります。
要件定義だけを依頼した場合も費用はかかりますか？
かかります。要件定義は専門家の工数を使う独立した仕事なので、開発の見積もりとは別に費用が発生します。ただし、要件が固まらないまま開発を見切り発車して全体が無駄になるリスクと比べれば、抑えられるコストです。要件定義のあとに続く開発本体の費用がどれくらいになるのかは「システム開発の費用相場は？見積書の見方」で解説しています。
要件定義には社内の誰が参加すべきですか？
実際にそのシステムを使う各部門の代表者と、意見が割れた時に決められる立場の人です。意見を集める人だけが出席していると、毎回「持ち帰って確認します」で終わってしまいます。
要求定義と要件定義は何が違いますか？
要求定義は発注者側が「こうしたい」を出す作業、要件定義はその要求を実現可能な形に整理して「何を作るか」を確定させる作業、と整理すると分かりやすいと思います。実務上は明確に分けず、要件定義の中でまとめて進めることも多いです。
要件定義が失敗するとどうなりますか？
後工程での手戻り、想定外の追加費用、納期遅延という形で表面化します。要件定義を含めたプロジェクト全体の失敗要因については「システム開発が失敗する原因と対策」で解説しています。どこまでを開発範囲とするかという「スコープ」の考え方は「プロジェクトのスコープとは？」もあわせてご覧ください。
要件定義とは？まとめ
- 要件定義とは、開発するシステムに求められる要件（機能要件・非機能要件）を定め、何を作り何を作らないかを確定させる工程
- 要件定義は目標設定、ヒアリングを経て、要件定義書・サーバー構成図・業務フロー図といった成果物が作られる
- 機能要件とは、要件定義のうち必ず搭載すべき機能のこと
- 非機能要件とは、パフォーマンスなど機能化しない要件すべて。機能要件より抜けやすい
- 何をどこまで要件定義で決めるかは案件によって変わる。原則は「決めるべきことをあやふやにしたまま次の工程に進まない」
- 要件定義をスムーズに行うには、受注側は深くヒアリングして理解を深め、問題解決するにはどのようなシステムがいいか提案できるのがベスト。発注側は解決したい問題を情報収集し、はっきり伝えられるような状態にするのがベスト
- 社内だけで進めるのが難しければ、要件定義だけを外部に支援してもらう選択肢もある（ただし丸投げはできない）
要件定義は、システム開発の完成イメージの大枠を作る重要な工程です。発注側は事前にシステム開発で解決したい課題を洗い出しておき、受注側は深くヒアリングを行うことで、スムーズに要件定義の工程が進みます。要件定義が終わった後の工程については「システム設計とは？設計を行う上で重要なポイントを解説」を、発注から運用開始までの全体の流れについては「システム開発依頼の流れは？」をご覧ください。
この記事によってシステム開発成功のお手伝いができましたら幸いです。最後までお読みいただき、ありがとうございました。