システム開発の要件定義を進めていると、

「業務要件と機能要件は何が違うのか」

「どこまでが業務要件で、どこからが機能要件なのか」

「機能一覧を作れば業務要件も整理したことになるのか」

と迷うことがあります。

結論から整理すると、

業務要件は「業務として何を実現したいか」

機能要件は「その業務を実現するためにシステムで何ができる必要があるか」

です。

例えば現在、複数拠点の在庫をExcelで管理している会社があるとします。

業務要件は、

全拠点の在庫状況を
本社からリアルタイムに確認できるようにする

です。

これを実現するための機能要件として、

商品登録機能

拠点管理機能

入庫登録機能

出庫登録機能

在庫一覧機能

拠点別検索機能

などが必要になります。

つまり、

業務要件
↓
業務として実現したいこと

機能要件
↓
そのためにシステムが備える機能

という関係です。

この違いを理解しないまま要件定義を進めると、

必要な機能は作ったのに
業務が改善されない

というシステムになりかねません。

この記事では、業務要件と機能要件の違いを具体例を使って整理し、要件定義で混同しないための考え方や書き方まで解説します。

業務要件と機能要件の違い

まず、違いを一覧で整理します。

項目	業務要件	機能要件
主な視点	業務	システム
決めること	業務として何を実現するか	システムで何を実現するか
主な関係者	業務担当者・責任者	業務担当者・開発者
例	在庫を一元管理したい	在庫一覧機能
例	承認を電子化したい	承認・差戻し機能
例	顧客対応履歴を共有したい	対応履歴登録・検索機能
順番	先	後

重要なのは、

基本的には業務要件を整理してから機能要件へ落とし込む

ことです。

業務要件とは

業務要件とは、

システム導入後に
業務をどのような状態にしたいか

を定義したものです。

例えば現在、

営業担当者がExcelへ案件を入力

↓

毎週金曜日に管理者へ送付

↓

管理者が5人分のExcelを統合

↓

営業会議用の資料を作成

という業務があったとします。

この会社が実現したいことは、

毎週Excelを統合する作業をなくし、
営業案件の状況をいつでも確認できるようにしたい

かもしれません。

これが業務要件です。

業務要件では機能名ではなく「業務の状態」を考える

例えば、

ダッシュボード機能が必要

は基本的には機能要件側です。

一方、

営業管理者が、
担当者へ確認しなくても
最新の案件状況を把握できるようにする

なら業務要件として整理できます。

つまり、

ダッシュボードが欲しい

という話が出たときに、

なぜ必要なのか？

を掘り下げます。

すると、

担当者ごとにExcel管理

↓

管理者が案件状況を把握できない

↓

毎週Excelを集計している

↓

最新の案件状況を
いつでも確認したい

という業務要件が見えてきます。

業務要件の具体例

例えば顧客管理システムなら、

顧客情報を営業担当者間で共有できるようにする

同じ顧客へ複数の営業担当が連絡することを防ぐ

過去の対応内容を担当者変更後も確認できるようにする

営業案件の進捗を管理者が把握できるようにする

などが業務要件になります。

在庫管理なら、

複数拠点の在庫情報を一元管理する

在庫確認のための電話連絡をなくす

月末の在庫集計時間を削減する

商品ごとの入出庫履歴を確認できるようにする

などです。

業務要件はシステム以外でも実現できる場合がある

ここも重要です。

例えば、

申請漏れを減らしたい

という業務要件があったとします。

解決策は必ずしも、

新しいシステムを作る

とは限りません。

例えば、

既存フォームを改善

Slack通知を追加

業務ルールを変更

担当者への教育

でも解決できる可能性があります。

つまり、業務要件は、

システムを作る前の
業務課題・業務目的

に近い位置にあります。

機能要件とは

機能要件とは、

業務要件を実現するためにシステムが備えるべき機能

です。

例えば、

業務要件：

複数拠点の在庫状況を
本社から確認できるようにする

という要件があるとします。

そこから、

商品管理機能

拠点管理機能

在庫登録機能

在庫一覧機能

拠点別絞り込み機能

などの機能要件を導きます。

機能要件の具体例

顧客管理システムなら、

顧客登録

顧客編集

顧客検索

担当者設定

案件登録

案件ステータス変更

対応履歴登録

CSV出力

などです。

予約システムなら、

イベント一覧

予約フォーム

定員管理

予約登録

キャンセル

満席時受付停止

確認メール

予約一覧

CSV出力

などが機能要件になります。

業務要件から機能要件へ落とす具体例

一番分かりやすいのは、業務要件と機能要件を対応させる方法です。

例えば在庫管理システムです。

業務要件1

商品ごとの現在庫を
全拠点で共有できるようにする

機能要件

・商品管理
・拠点管理
・在庫一覧
・拠点別在庫表示

業務要件2

商品の入庫・出庫状況を
後から確認できるようにする

機能要件

・入庫登録
・出庫登録
・入出庫履歴
・期間検索

業務要件3

管理者以外が
過去の在庫データを勝手に修正できないようにする

機能要件

・ユーザー権限
・在庫修正権限
・操作ログ

このように、

業務要件
↓
機能要件

の対応関係を作ると整理しやすくなります。

顧客管理システムで比較すると分かりやすい

もう一つ例を見てみます。

現在の課題

営業担当者が
それぞれExcelで顧客管理している

その結果、

誰がどの顧客へ連絡しているか分からない

過去の対応履歴が分からない

退職すると情報が失われる

という問題があります。

業務要件

ここから、

営業部内で顧客情報を共有する

顧客ごとの担当者を明確にする

過去の営業対応を確認できるようにする

という業務要件を定義します。

機能要件

さらに、

顧客登録機能

顧客検索機能

担当者設定機能

対応履歴登録機能

対応履歴検索機能

へ落とします。

関係としては、

課題

↓

業務要件

↓

機能要件

となります。

「課題」「業務要件」「機能要件」を分ける

要件定義では、この3つを分けると非常に整理しやすくなります。

例えば、

種類	内容
課題	Excelを毎週3時間かけて集計
業務要件	集計作業なしで全拠点在庫を確認したい
機能要件	拠点別在庫一覧を表示する

別の例なら、

種類	内容
課題	顧客対応が担当者に属人化
業務要件	対応履歴を営業部内で共有したい
機能要件	顧客別対応履歴を登録・閲覧できる

この構造を意識すると、

その機能は
何のために必要なのか？

を説明できます。

業務要件と機能要件が混同される原因

実際の要件定義では両者が混ざりやすくなります。

主な原因を見ていきます。

原因1｜最初から欲しい機能を聞く

例えばヒアリングで、

どのような機能が必要ですか？

と聞きます。

すると利用者は、

ダッシュボード

CSV

検索

通知

と回答します。

しかし、これでは、

なぜ必要なのか

が分かりません。

そのため、

何に困っていますか？

現在はどうしていますか？

どういう状態にしたいですか？

を先に確認します。

原因2｜「要件」という言葉を広く使っている

現場では、

顧客の要望

業務ルール

システム機能

非機能要件

をまとめて、

要件

と呼ぶことがあります。

そのため資料上では、

業務要件

機能要件

非機能要件

など、分類して管理すると分かりやすくなります。

原因3｜業務担当者と開発者で視点が違う

業務担当者は、

在庫を確認したい

と考えます。

開発者は、

在庫一覧画面

検索API

在庫テーブル

と考えます。

どちらも間違いではありませんが、粒度が違います。

そこで、

業務の言葉

↓

システムの言葉

へ段階的に変換します。

業務要件を整理するときの質問

業務要件を考える場合は、

現在どのような業務をしていますか？

どこに時間がかかっていますか？

どこでミスが起きていますか？

担当者に依存している業務はありますか？

システム導入後に何が変われば成功ですか？

現在の作業でなくしたいものはありますか？

情報を誰と共有したいですか？

どのような状態になれば業務が楽になりますか？

などを確認します。

重要なのは、

システムの質問

ではなく、

業務の質問

をすることです。

機能要件を整理するときの質問

業務要件が分かったら、機能へ落としていきます。

例えば、

何を登録する必要がありますか？

何を検索する必要がありますか？

誰が閲覧できますか？

誰が編集できますか？

削除は必要ですか？

通知は必要ですか？

CSVやPDFは必要ですか？

承認処理はありますか？

履歴は必要ですか？

どのタイミングで処理しますか？

などです。

例えば業務要件が、

申請状況を
申請者自身が確認できるようにする

なら、

申請一覧

申請詳細

申請ステータス表示

などの機能を検討します。

業務要件を書くときのテンプレート

例えば次の形式です。

業務要件ID：
BR-001

業務名：
在庫確認

現状：
各拠点のExcelを本社担当者が毎週統合している。

課題：
最新の全拠点在庫をすぐ確認できない。

業務要件：
全拠点の最新在庫を
本社担当者が随時確認できるようにする。

対象者：
本社管理者、拠点管理者

目的：
在庫集計作業の削減

IDを、

BR
=
Business Requirement

などで管理する方法もあります。

機能要件を書くときのテンプレート

例えば、

機能要件ID：
FR-001

機能名：
在庫一覧

関連業務要件：
BR-001

概要：
全拠点の商品在庫を一覧表示する。

利用者：
本社管理者

入力：
商品名
商品コード
拠点

出力：
商品コード
商品名
拠点
現在庫数

優先度：
Must

とします。

ポイントは、

関連業務要件：
BR-001

のように紐付けることです。

要件トレーサビリティを意識する

少し専門的になりますが、

なぜこの機能が存在するのか

を追跡できる状態にすると管理しやすくなります。

例えば、

課題
P-001

↓

業務要件
BR-001

↓

機能要件
FR-001
FR-002
FR-003

という関係です。

具体的には、

課題：
Excel集計に毎週3時間

↓

業務要件：
全拠点在庫を一元管理

↓

機能要件：
在庫一覧
拠点管理
入出庫登録

となります。

こうすると機能追加を要求されたときに、

この機能は
どの業務課題を解決しますか？

と確認できます。

不要な機能を減らす効果もある

例えば、

AIで需要予測したい

という要望が出たとします。

しかし今回の開発目的が、

Excelでの在庫集計をなくす

なのであれば、AI需要予測は必須ではない可能性があります。

課題

↓

業務要件

↓

機能要件

の関係が整理されていると、

初回リリースでは対象外

という判断もしやすくなります。

機能要件と非機能要件の違い

業務要件と合わせて混同されやすいのが、

非機能要件

です。

簡単に整理すると、

業務要件
=
業務として何を実現するか

機能要件
=
システムで何ができるか

非機能要件
=
どの程度の品質で実現するか

です。

例えば、

業務要件

営業担当者が
外出先から顧客情報を確認できる

機能要件

顧客検索機能

顧客詳細表示

非機能要件

スマートフォン対応

HTTPS通信

主要画面3秒以内

となります。

システム要件との違い

「システム要件」という言葉もあります。

プロジェクトによって使い方は異なりますが、一般的には、

システムとして満たすべき条件

を広く指し、

機能要件

非機能要件

外部連携

データ

運用

などを含めて整理する場合があります。

そのため、

業務要件
↓
システム要件
├─ 機能要件
└─ 非機能要件

と整理すると分かりやすいでしょう。

ただし組織・開発会社によって用語の定義は異なるため、プロジェクト開始時に言葉の使い方を合わせておくことが重要です。

在庫管理システムを例に整理する

業務要件と機能要件をまとめて見てみます。

課題

3拠点がそれぞれExcelで在庫管理している。

本社が毎週Excelを統合している。

他拠点の最新在庫が分からない。

業務要件

BR-001

全拠点の在庫情報を
一元管理する。

BR-002

本社担当者が
最新の全拠点在庫を随時確認できる。

BR-003

商品の入出庫履歴を
後から確認できる。

機能要件

FR-001
商品管理

FR-002
拠点管理

FR-003
入庫登録

FR-004
出庫登録

FR-005
在庫一覧

FR-006
拠点別在庫検索

FR-007
入出庫履歴

このようになります。

予約管理システムの場合

もう一つ具体例です。

課題

Googleフォームで予約受付。

担当者が残席をExcelで計算。

満席になったら手動で受付を停止している。

業務要件

予約者自身が
空きのあるイベントだけ予約できる。

定員到達後は
新しい予約を受け付けない。

運営担当者が
予約状況を一覧確認できる。

機能要件

イベント一覧

残席表示

予約フォーム

予約登録

定員判定

満席時受付停止

予約一覧

予約キャンセル

業務要件から考えることで、必要な機能が自然に導かれます。

顧客管理システムの場合

課題

顧客情報を営業担当者ごとのExcelで管理。

担当者が休むと
過去の対応状況が分からない。

業務要件

顧客情報を営業部全体で共有する。

担当者以外でも
過去の対応内容を確認できる。

顧客ごとの案件状況を
管理者が把握できる。

機能要件

顧客登録

顧客検索

担当者設定

対応履歴登録

対応履歴一覧

案件登録

案件ステータス管理

となります。

業務要件と機能要件を整理する5ステップ

実際の要件定義では、次の順番で整理すると混線しにくくなります。

STEP1｜現在の業務を整理する

まず機能ではなく、

誰が

何を

どの順番で

どのツールを使って

処理しているか

を整理します。

STEP2｜業務課題を洗い出す

例えば、

転記に時間がかかる

最新情報が分からない

担当者に属人化

ミスが多い

承認が遅い

などです。

STEP3｜業務要件を定義する

課題から、

業務をどう変えるのか

を決めます。

例えば、

転記作業をなくす

情報を一元管理する

担当者以外でも状況確認できる

承認状況を可視化する

などです。

STEP4｜機能要件へ落とす

業務要件を実現するため、

登録

検索

一覧

更新

通知

承認

出力

など必要なシステム機能を整理します。

STEP5｜対応関係をレビューする

最後に、

すべての機能に
必要な理由があるか

を確認します。

逆に、

業務要件を実現するための
機能が不足していないか

も確認します。

業務要件と機能要件を一覧表で管理する

例えば次のような表がおすすめです。

業務要件ID	業務要件	機能要件
BR-001	在庫情報を一元化	商品管理・拠点管理・在庫管理
BR-002	最新在庫を確認	在庫一覧・検索
BR-003	入出庫を追跡	入庫・出庫・履歴
BR-004	権限制御	ロール・権限管理

これだけでも、

業務
↓
システム

の関係が見えやすくなります。

業務要件と機能要件でよくある失敗

失敗1｜業務要件を作らず機能一覧から始める

例えば、

ログイン

検索

CSV

通知

ダッシュボード

だけ並べても、システムの目的が分かりません。

先に業務課題・業務要件を整理します。

失敗2｜業務要件が抽象的すぎる

例えば、

業務効率を上げる

だけでは具体性がありません。

できれば、

毎週3時間かかる在庫集計をなくし、
随時在庫確認できるようにする

などにします。

失敗3｜業務要件に画面仕様を書く

例えば、

右上に青色の検索ボタンを配置

は業務要件ではありません。

詳細なUI仕様は後工程へ分けます。

失敗4｜一つの機能だけで業務要件が実現すると考える

例えば、

業務要件：
在庫を一元管理

に対して、

在庫一覧

だけでは足りない場合があります。

商品管理、入出庫、拠点管理など複数機能が必要です。

失敗5｜機能追加の理由を確認しない

利用者から、

チャット機能も欲しい

と言われたら、

どの業務課題を解決するためですか？

と確認します。

理由が明確でなければ、優先順位を下げられるかもしれません。

要件定義では業務担当者と開発者の両方が必要

業務要件を整理するには、

実際の業務を知っている人

が必要です。

一方、機能要件へ落とすには、

システム設計を理解している人

が必要です。

そのため、

業務担当者
+
開発担当者

が一緒に要件定義を進めることが重要です。

例えば、

業務担当：

毎月このExcelを統合するのが大変です


開発担当：

では、各担当者が同じDBへ入力すれば
統合作業自体をなくせないでしょうか？

という対話から要件を整理していきます。

要件定義で「現行業務をそのままシステム化」しない

システム開発で注意したいのが、

現在のExcel業務
↓
そのままWebシステムへ移植

することです。

例えば現在、

Excelへ入力

↓

CSV出力

↓

別Excelへ転記

↓

メール送信

しているからといって、

Webシステム
↓
CSV出力
↓
別システムへ手入力

にする必要はありません。

業務要件から考え直せば、

Webシステム
↓
API
↓
別システム

と自動連携できる可能性があります。

つまり、

業務要件を整理することは、単なるシステム化ではなく業務そのものを見直す機会

でもあります。

業務要件と機能要件に関するよくある質問

業務要件と機能要件はどちらを先に決めますか？

基本的には業務要件を先に整理します。

業務課題
↓
業務要件
↓
機能要件

という順番です。

ただし実際の要件定義では、機能を検討しながら業務要件へ戻って見直すこともあります。

業務要件は誰が決めますか？

業務責任者・現場担当者など、実際の業務を理解している人が中心になります。

開発会社はヒアリング・整理・システム化案の提案を支援します。

機能要件は誰が決めますか？

発注者と開発会社が一緒に整理します。

利用者が必要とする業務をもとに、技術的な実現方法を開発者側が検討します。

業務要件と要求の違いは？

要求は、

利用者がこうしたい

というニーズを広く指すことがあります。

業務要件は、その要求を整理して、

業務として満たすべき条件

へ具体化したものとして扱うと理解しやすいでしょう。

実際の用語定義は組織によって異なるため、プロジェクト内で合わせることが重要です。

機能要件と非機能要件の違いは？

機能要件は、

何ができるか

です。

非機能要件は、

どの程度の性能・品質で実現するか

です。

例えば、

商品検索

は機能要件、

検索結果を3秒以内に表示

は非機能要件です。

小規模システムでも業務要件は必要ですか？

必要です。

大規模な要件定義書を作る必要はありませんが、

何を改善したいのか

を整理しないまま機能を作ると、不要な開発が増える可能性があります。

hiro-dev-labの要件定義・業務システム開発支援

hiro-dev-labでは、Webシステム・業務システムについて、機能実装だけでなく業務整理・要件定義から対応しています。

例えば、

• 現状業務のヒアリング
• 業務フロー整理
• 業務課題の洗い出し
• 業務要件整理
• 機能要件整理
• 非機能要件整理
• システム化対象範囲の整理
• 画面・ワイヤーフレーム整理
• データ・権限設計
• 外部システム連携の検討
• Java・Python・TypeScriptによるWebシステム開発

などを検討できます。

例えば現在、

Excel

↓

担当者が集計

↓

メール共有

↓

別担当者が転記

という業務がある場合、いきなり、

Excelの代わりになる
Web画面を作る

とは考えません。

まず、

現在の業務

↓

課題

↓

本来実現したい業務

↓

業務要件

↓

機能要件

↓

システム設計

という順番で整理します。

業務要件と機能要件を分ける目的は「必要なシステムを作る」ため

業務要件と機能要件を分けること自体が目的ではありません。

重要なのは、

なぜこの機能を作るのか

を説明できる状態にすることです。

例えば、

CSV出力

ダッシュボード

通知

AI

検索

といった機能も、それだけでは必要性を判断できません。

その機能によって、

どの業務課題が解決されるのか

を確認します。

要件定義では、

1．現在の業務を整理する

2．業務課題を洗い出す

3．業務として実現したい状態を決める

4．業務要件として整理する

5．必要な機能へ落とし込む

6．機能要件と業務要件を紐付ける

7．不要な機能・不足している機能を確認する

という流れで考えると、業務要件と機能要件が混線しにくくなります。

「業務要件と機能要件の整理方法が分からない」

「現在の業務をどうシステム化すればよいか分からない」

「機能一覧はあるが、本当に必要な機能か確認したい」

「要件定義から設計・開発まで相談したい」

といった段階からでも、業務整理から進めることができます。

要件定義・業務システム開発について相談する