まず押さえたい3つの要件の違い
開発を外部の会社（ベンダー）に依頼しようとしたとき、「要件定義が大事」という話を耳にしたことがある方も多いのではないでしょうか。しかし、「要件定義では何を書けばよいのか」「業務要件と機能要件は何が違うのか」と戸惑うのは、決して珍しいことではありません。
これらは専門家でなくても整理できる内容です。自社の業務をよく理解している担当者だからこそ、最初に整理しておきたいポイントでもあります。まずは3つの要件がそれぞれ何を指すのかを、具体的なイメージとあわせて確認していきましょう。
それぞれが決める内容の役割
業務要件とは、「この仕組みを使って、業務をどのように変えたいか」を言葉にするものです。技術的な話ではなく、仕事の進め方や目的、解決したい課題、到達したい状態を整理します。たとえば、「今は紙の申請書を使っているが、デジタル化して承認までの時間を短縮したい」といった内容が該当します。
機能要件とは、その目的を実現するために「システムが実際にどのような動きをする必要があるか」を具体化するものです。「申請フォームに入力できる」「申請データが承認者にメールで通知される」「承認・却下を画面上で操作できる」といった、備えるべき機能を整理します。
非機能要件とは、「どのような条件で安定して安全に動かす必要があるか」を定めるものです。「1日に何人が同時にアクセスしても遅くならないこと」「障害が起きても4時間以内に復旧できること」「パスワードを暗号化して管理すること」などがこれにあたります。
大まかに整理すると、業務要件は「何を解決したいか」、機能要件は「どのような機能が必要か」、非機能要件は「どのような条件で動かす必要があるか」と理解するとわかりやすいでしょう。
3つの要件がどうつながるのか
3つの要件は、それぞれ別々に存在するものではなく、流れとしてつながっています。まず業務要件があり、その内容を実現するために機能要件が決まり、さらにその機能を支える条件として非機能要件が決まる、という順番です。
たとえば「月次の経費精算を紙からデジタルに移行して、処理時間を半分にしたい」という目的があれば、そこから「経費の申請フォーム・承認ワークフロー・CSV出力機能が必要」といった内容が具体化されます。そして「経理担当5名と全社員100名が月末に集中してアクセスするため、同時50件の処理に耐えられること」といった運用条件も見えてきます。
この流れが崩れると、「機能はそろっているのに業務課題が解決されない」「性能面の考慮が漏れて本番運用で障害が起きる」といった問題につながりやすくなります。順番どおりに考えることが、後のトラブルを防ぐ近道です。
中小企業のシステム導入で整理が必要な理由
大企業であれば、専任のITチームや社内SEが要件定義を担うことが多いものです。一方、中小企業では総務や経理の担当者が導入の窓口になることも少なくありません。そのため、「何をどこまで決めてからベンダーに相談すればよいかわからない」という状況になりがちです。
要件が曖昧なまま開発を進めると、途中で「思っていたものと違う」という認識のずれが生じ、追加費用や納期遅延につながることがあります。反対に、3つの要件をある程度整理してからベンダーと話すことで、認識のずれを抑えやすくなり、コストやスケジュールも守りやすくなります。
業務の進め方を明確にするためのまとめ方
業務要件で決める範囲
業務要件は、「解決すべき業務上の課題と目的」を定めるものです。ここで決めるのは、どの業務を対象とするか、誰が使うか、現状の何が問題か、導入後にどのような状態を目指すかといった内容です。
具体的には、対象となる業務の名称、現状の流れ、関係する部署や担当者、抱えている課題、導入後の目標などを整理します。この段階では、まだ「何をどう作るか」まで考える必要はありません。まずは「業務をどうしたいのか」を明確にすることに集中することが大切です。
現状業務と理想の業務を整理する書き方
まずは、現状の業務フローを書き出してみましょう。「誰が、何を、どうするか」という形で簡単に整理するだけでも十分です。次に、その流れの中で「時間がかかっている」「ミスが起きやすい」「同じ作業が重複している」といった問題点を洗い出します。
そのうえで、導入後に目指す理想の状態を整理します。このときは、できるだけ数値で目標を表現すると伝わりやすくなります。たとえば「処理時間を現在の3日から1日に短縮したい」「入力ミスをほぼなくしたい」といった書き方です。数値化が難しい場合でも、「担当者1人でも対応できるようにしたい」「月末の残業をなくしたい」など、具体的な状態として表現すると十分実用的です。
中小企業で使いやすい業務要件の記載例
以下は、経費精算業務のデジタル化を検討している中小企業の例です。
対象業務： 経費精算業務（月次）
現状の課題：
月末に紙の申請書を全員から集め、経理担当者が1枚ずつ確認し、承認印を依頼している。処理に3〜4日かかり、領収書の紛失や記入漏れも頻繁に発生している。
関係部署・利用者：
全社員（申請者）、部門長（承認者）、経理担当2名（最終確認・集計）
導入後の目標：
申請から最終承認までの時間を1営業日以内に短縮する。領収書はデータで保存し、紛失リスクをなくす。経理担当者の月末集計作業を半日以内に収める。
このように、「現状」「課題」「目標」の流れで整理すると、業務要件として必要な情報がまとめやすくなります。
システムに求める動きを具体化するまとめ方
機能要件で決める範囲
業務要件が「何を解決したいか」を整理するものであるのに対し、機能要件は「そのために何ができる必要があるか」を定めるものです。ここで明らかにするのは、必要な機能の一覧です。
たとえば、「申請できる」「承認できる」「データを検索できる」「帳票を印刷できる」といったように、利用者が実際に行う操作を一つずつ整理していきます。業務の流れに沿って、「この作業にはどの機能が必要か」という形で考えると、抜け漏れを防ぎやすくなります。
必要な機能を洗い出す書き方
業務フローを見直しながら、「この作業を行うには、どのような操作が必要か」を順に考えてみてください。申請、受取、確認、承認、集計という流れがあるなら、それぞれの段階に対応する操作を整理していきます。
また、必要な機能は利用者の立場によって変わります。申請者、承認者、管理者など、それぞれの立場から「何ができる必要があるか」を見直すことで、見落としを減らせます。
中小企業で使いやすい機能要件の記載例
先ほどの経費精算の例で考えると、機能要件は次のように整理できます。
申請者向け機能：
- 経費申請フォームへの入力（金額・日付・目的・勘定科目など）
- 領収書画像のアップロード
- 申請状況の確認（承認待ち・承認済み・差戻しの確認）
承認者向け機能：
- 申請一覧の確認
- 承認・差戻しの操作（コメント付き）
- 新規申請時のメール通知
経理担当向け機能：
- 承認済み申請データのCSV出力
- 申請履歴の検索（期間・部署・申請者での絞り込み）
- 月次集計レポートの表示
利用者の役割ごとに整理しておくと、ベンダーへの説明も進めやすくなります。
安定運用に欠かせない条件の整理方法
非機能要件で決める範囲
非機能要件は、「どのような状態で安定して使い続けられる必要があるか」を定めるものです。機能そのものではなく、品質、安定性、安全性、保守のしやすさに関わる条件を整理します。
中小企業の担当者が特に意識しておきたいのは、性能、可用性、セキュリティ、保守性の4つです。
性能・可用性・セキュリティ・保守性の考え方
性能とは、どのくらいの速さで、どのくらいの量を処理できるかという観点です。「多くの人が同時にアクセスしても3秒以内に画面が表示されること」といった形で表します。月末や繁忙期に利用が集中する場合は、そのピーク時を想定して条件を書くことが重要です。
可用性とは、どの程度まで使えない時間を許容できるかを示す考え方です。たとえば「平日9時〜18時は必ず使えること」「障害発生から4時間以内に復旧できること」といった条件です。業務への影響の大きさを踏まえて決める必要があります。
セキュリティとは、データ保護や不正アクセス対策に関する条件です。「個人情報や取引データを暗号化して保存する」「パスワードの複雑さを設定できる」「ログイン履歴を保存する」といった内容が含まれます。
保守性とは、管理、更新、トラブル対応のしやすさに関する観点です。「問い合わせ窓口がある」「定期的にバックアップが取得される」「バージョンアップの対応方針が明確である」といった点を確認しておきましょう。
中小企業で使いやすい非機能要件の記載例
性能：
月末の繁忙期に50名が同時にアクセスしても、画面表示が5秒以内であること。
可用性：
平日9:00〜18:00の時間帯は稼働率99%以上を保つこと。障害時は4時間以内に復旧対応ができること。
セキュリティ：
ログイン時の二段階認証に対応していること。社員の個人情報や経費データは暗号化して保存されること。
保守性：
毎日自動でバックアップが取得されること。問い合わせ対応窓口（メールまたはチャット）があること。
どこに書くべきか迷わないための判断基準
業務要件として書くべき内容
「なぜ導入が必要なのか」「導入後にどのような状態を実現したいのか」に答える内容は、業務要件として整理します。具体的には、業務の目的、対象範囲、関係する担当者、現状の課題、導入後の目標値などが該当します。
機能要件として書くべき内容
「何ができるか」「利用者がどのような操作をするか」に答える内容が機能要件です。入力、閲覧、操作、出力といった利用者の行動が具体的に書かれていれば、適切に記述できています。
非機能要件として書くべき内容
「どのくらい速く」「どのくらい安全に」「どのくらい安定して」動かす必要があるかに答える内容は、非機能要件として整理します。性能の数値、稼働時間の条件、セキュリティ基準、保守対応の範囲などがここに入ります。
よくある書き間違いとその直し方
よくある例として、「データを安全に管理してほしい」という記述を業務要件に入れてしまうケースがあります。これは非機能要件のうちセキュリティにあたるため、非機能要件の欄に整理するのが適切です。
また、「承認フローが必要」という表現をそのまま機能要件に書くこともありますが、これはやや抽象的です。機能要件では、「承認ボタンを押すと申請者に承認完了メールが自動送信される」といったように、具体的な動作として書き直すと伝わりやすくなります。
もし書く場所に迷った場合は、まず書き出すことを優先し、その後ベンダーと一緒に整理する進め方でも問題ありません。最初から完璧に分類しようとしなくても大丈夫です。
要件の抜け漏れを防ぐ確認ポイント
業務の流れに沿って確認する
要件をまとめたら、業務の最初から最後までを通して読み返してみましょう。「申請する」「承認される」「集計される」「支払われる」という一連の流れの中で、どこか抜けている作業がないかを確認します。途中で「この作業はどこに書かれているだろう」と感じた箇所があれば、要件の漏れが起きている可能性があります。
利用者・管理者・取引先の視点で確認する
使う人は一種類ではありません。申請者、承認者、管理者それぞれの立場から、「自分が行いたいことがきちんと整理されているか」を確認してみてください。取引先や顧客が関わる場面がある場合は、その視点も忘れずに見直すことが大切です。
障害時や繁忙時も含めて確認する
通常時の利用だけを前提にすると、「月末の集中アクセスで遅くなる」「止まったときの対応が決まっていない」といった問題が後から見つかることがあります。ピーク時の利用状況や、障害時のバックアップ、復旧の考え方についても、非機能要件として確認しておきましょう。
社内外で認識をそろえるレビューの進め方
担当者だけで決めないための準備
要件を担当者だけで作成すると、現場の実態とずれてしまうことがあります。実際に業務を担当している人へヒアリングを行い、「今困っていること」「あると助かる機能」「必須の機能」を事前に確認しておきましょう。あわせて、部門長や現場リーダーなど社内の関係者に、要件のたたき台を見てもらうことも重要です。
ベンダーへの伝え方で気をつけたい点
ベンダーに要件を伝える際は、「とにかく使いやすくしてほしい」「何でもできるようにしてほしい」といった曖昧な表現は避けたほうがよいでしょう。何を作るべきか判断しづらくなり、見積もりが大きくなったり、認識のずれが後から表面化したりするためです。業務要件、機能要件、非機能要件を分けて整理したうえで、文書として共有することをおすすめします。
また、優先順位も一緒に伝えると、やり取りが進めやすくなります。「必須」「できれば必要」「将来的に検討」の3段階に分けるだけでも、会話の精度が上がります。
合意形成を進めるための確認手順
要件書を共有したら、ベンダーと一緒に内容を確認する場を設けましょう。「この機能の目的は何か」「このケースにはどう対応するか」といった質問が出てくれば、認識をそろえるよい機会になります。最終的には、「何を作るか」とあわせて「何を対象外にするか」まで明記した合意文書を残しておくと、後のトラブル防止に役立ちます。
迷ったときに最初に取り組む整理の順番
まず業務の目的と課題を言葉にする
最初に明確にしたいのは、「何のために導入するのか」です。「ある業務のどの問題を解消し、どのような状態にしたいのか」という一文が書けると、その後の整理が進めやすくなります。この一文が業務要件の中心になります。
次に必要な機能を絞り込む
業務要件が固まったら、それを実現するために何ができる必要があるかを考えます。最初からすべての機能を網羅しようとする必要はありません。業務フローの各ステップに対応する機能を考える、という視点で整理すると進めやすくなります。機能の洗い出しは、ベンダーと相談しながら進めても問題ありません。
最後に運用条件とリスク対策を固める
機能が見えてきたら、最後に「どのような条件で使い続けるか」を整理します。特にセキュリティや可用性は後回しになりやすい項目ですが、運用開始後に問題が見つかると対策コストが大きくなります。障害や不正アクセスなどの最悪のケースを想定し、どこまで対応できれば業務を継続できるかを基準に考えると、整理しやすくなります。
よくある質問
Q1. 要件定義はベンダーが作ってくれるのではないですか？
ベンダーが要件定義を支援してくれることはありますが、業務の目的、課題、理想の状態は発注者側で主体的に整理する必要があります。ベンダーは自社の業務内容を最初から詳しく知っているわけではないため、特に業務要件は自社で考えることが基本です。機能要件や非機能要件は、ベンダーと協力しながら詰める進め方が一般的です。
Q2. すべての要件を最初に完全に決めないといけませんか？
必ずしも最初からすべてを完全に決める必要はありません。まずは業務要件を固め、そのうえでベンダーに相談しながら機能要件や非機能要件を詰めていく進め方も実務ではよく行われます。ただし、開発開始後の大きな変更は費用や期間に影響するため、重要な要件は早めに明確にしておくことが大切です。
Q3. 非機能要件はどのくらい詳しく書けばいいですか？
中小企業であれば、性能、可用性、セキュリティ、保守性の4項目について、それぞれ1〜3行程度でまとめるところから始めれば十分です。細かな数値や詳細条件はベンダーとの相談の中で調整できますので、まずは「なぜその条件が必要なのか」を添えて書くと伝わりやすくなります。
Q4. 要件書はどんな形式で作ればよいですか？
特定の形式にこだわる必要はありません。ExcelやWordで、業務要件、機能要件、非機能要件の3つに分けて整理するだけでも十分です。重要なのは、関係者全員が読んで同じ内容を理解できることです。
Q5. 小規模な導入でも要件定義は必要ですか？
規模が小さくても、要件を整理せずに進めると認識のずれや機能の過不足が起きやすくなります。小規模な導入であっても、業務要件だけでも1〜2ページにまとめておくと、ベンダーとのやり取りはかなり進めやすくなります。
まとめと行動喚起
業務要件、機能要件、非機能要件の3つは、それぞれ「業務の目的と課題」「必要な機能」「安定して運用するための条件」を整理するものです。この3つを分けて考えることで、ベンダーへ依頼する内容が明確になり、「思っていたものと違う」といったトラブルを防ぎやすくなります。
専門知識がなくても、自社の業務を最もよく知っているのは社内の担当者です。まずは、今の業務で何に困っているのか、導入後にどうなっていたいのかを言葉にするところから始めてみてください。そこが整理できれば、要件整理は大きく前進します。
もし、要件をどのように整理すればよいかわからない、あるいはベンダーに相談する前に内容を整理しておきたいとお考えであれば、ぜひ一度ご相談ください。初回のご相談は無料で承っており、要件定義の進め方や書き方の整理からご支援しています。まずはお問い合わせフォームよりお気軽にご連絡ください。
