発注前準備は何から始める？
最初にすべきことは「現状の業務フロー整理」です。ベンダへの説明材料を作る前に、自社内で「誰が・何を・どの順番でやっているか」を文字と図に落とし込みます。
この順序を守ることが、発注後の「思っていたものと違う」を防ぐ最大の手立てです。要件定義書やRFP（提案依頼書）の作成はその後の工程であり、業務フローの整理なしにベンダへの相談を始めると、前提が共有されないまま見積もりや提案が進んでしまいます。
IPAは2019年に「ストーリーで学ぶ要件定義実践入門」を公開し、経営課題を整理してから機能要件に落とし込む手順を、中小企業の担当者でも追えるよう解説しています（出典: IPA「ITを経営に活かしたい中小企業向け ストーリーで学ぶ要件定義実践入門」2019年3月）。この資料が示す通り、「経営課題の言語化」が要件定義のスタート地点であり、ツールの話は後回しで構いません。
業務フロー整理で拾うべき5つの情報
業務フローを整理する目的は、システムに何をさせるかを明確にするためです。以下の5つを埋めると、ベンダとの初回打ち合わせで話が格段にかみ合いやすくなります。
| # | 拾うべき情報 | 具体的に書く内容の例 |
|---|---|---|
| 1 | 登場人物（誰が） | 営業担当、経理、店長、パート従業員など役割ごとに列挙する |
| 2 | 作業内容（何を） | 受注入力、在庫確認、請求書発行など1タスクずつ分解する |
| 3 | 順序と条件（どの順番で） | 「Aが完了したらBへ進む」「例外はCで処理」など分岐も記載する |
| 4 | 使用中のツールとデータ（何で） | Excel、紙の台帳、既存の会計ソフト、スプレッドシートなど |
| 5 | 課題・ムダ・ボトルネック（何が問題か） | 二重入力が発生している、担当者不在で処理が止まるなど具体的に |
つまずきやすい点は「5番の課題記述」です。「不便」「遅い」といった感覚的な表現で止まらず、「月に何件・何時間・どの担当者に」という形で定量化すると、後の優先順位付けがしやすくなります。
整理にかかる時間の目安と担当者の決め方
業務フロー整理の所要時間は、業務の種類と関係者の数によって変わります。目安として、業務の種類が3〜5種類・関係者が5名以下の規模であれば、2〜3週間程度を見込むと現実的です。
進め方のポイントを以下にまとめます。
メインの取りまとめ役を1名決める（所要時間の目安: 0.5日） DX担当者がいない場合は、最も業務全体を把握している人を選びます。経営者が兼務しても構いませんが、現場ヒアリングに同席できる立場であることが条件です。
現場担当者へのヒアリングを部門ごとに行う（所要時間の目安: 1〜2日/部門） 会議形式ではなく1対1の短時間インタビューが本音を引き出しやすいです。「今の作業で一番面倒なことは何ですか」という問いから始めると話が広がります。
A4一枚の業務フロー図を手書きで書いてみる（所要時間の目安: 1日） ツールにこだわらず、付箋や手書きで構いません。後でベンダと共有できる形に清書する前に、まず「書いてみる」ことが重要です。
関係者に確認して認識のズレを修正する（所要時間の目安: 0.5〜1日） 取りまとめ役が一人で作ったフロー図は必ず抜けや誤りがあります。現場担当者に見せて「これで合っていますか」と確認する工程を省かないでください。
整理した内容を文書として保存する（所要時間の目安: 0.5日） ファイル名と更新日を明記し、後から誰が見ても同じ業務フローが読み取れる状態にします。この文書が、次のステップである要件定義の土台になります。
実装者として多くの発注前相談に立ち会ってきた経験から言うと、業務フロー整理を省いてシステムの話から入ったプロジェクトは、要件の後出しが頻発して工期と費用の両方が膨らむケースが非常に多いです。「急がば回れ」の工程です。
要件定義とRFPの具体的な内容と違いについては、次のセクションで詳しく解説します。
要件定義とは何か？RFPとの違いは？
要件定義とは「システムに何をさせるか」を言語化した仕様の土台で、RFP（提案依頼書）はその内容をベンダに提示して提案を求める文書です。両者は別物ですが、要件定義が固まっていないとRFPは書けません。
要件定義の定義と構成要素
要件定義とは、自社の業務課題を解決するためにシステムが持つべき機能と条件を、発注者とベンダが共同で言語化するプロセスです。
IPAは2019年に「ストーリーで学ぶ要件定義実践入門」を公開しました（出典: IPA「ITを経営に活かしたい中小企業向け ストーリーで学ぶ要件定義実践入門」）。同資料では、要件定義を「発注者と受注者が共同で行うべき上流工程」と位置づけ、経営課題の整理から機能要件への落とし込みまでの手順を中小企業の担当者でも追えるよう解説しています。
要件定義の成果物である「要件定義書」は、おおむね以下の構成要素で成り立ちます。
| 構成要素 | 内容の例 |
|---|---|
| 業務要件 | 解決したい課題、業務フローの変更点 |
| 機能要件 | システムが実行すべき具体的な機能（例: 在庫の自動更新） |
| 非機能要件 | 応答速度、同時接続数、セキュリティ基準など |
| 制約条件 | 既存システムとの連携、利用端末の種類 |
| 用語定義 | 社内独自の用語をベンダと共通認識化するための定義集 |
要件定義書はベンダ選定の後、発注者とベンダが協議しながら詳細化していく文書です。「選定前に渡すもの」ではなく、「選定後に一緒に作り込むもの」と理解すると、位置づけが明確になります。
RFPの定義と盛り込む項目一覧
RFP（Request for Proposal）とは、発注者が複数のベンダに対して同一条件で提案を求めるための文書です（出典: システム幹事）。要件定義書と混同されやすいですが、作成タイミングと目的が異なります。
- RFP: ベンダ選定の前に作成し、「何を実現したいか」の概要をベンダに伝える
- 要件定義書: ベンダ選定の後に、発注者とベンダが協議しながら詳細化する
この順序を逆にする、あるいは混同したまま進めると「ベンダごとに提案の前提が異なり、費用・納期・機能のいずれでも比較検討ができなくなる」という事態が起きます。
RFPに盛り込む項目の最低限の骨格は以下の7点です（出典: freshet）。各項目の具体的な書き方は、後述の「RFPの書き方：中小企業向け7項目テンプレート」で詳しく説明します。
- 背景・目的: なぜこのシステムが必要か
- 現状の業務フローと課題: 前セクションで整理した業務フローをここに転記する
- 実現したい機能の概要: 機能要件の洗い出し段階のもので構わない
- 非機能要件: 応答速度やセキュリティの大まかな要求水準
- スケジュール・予算感: 目安で構わないが、記載することに意味がある（理由は後述）
- 選定基準: 何を重視してベンダを選ぶか
- 提案書の提出形式・期限: ベンダが動ける締め切りと書式
RFPを整備せず口頭や断片的なメールだけで発注を進めると、ベンダ間の比較軸がそろわず、最終的に「一番安かったから」という理由だけで選定する状況に陥りがちです。RFPは御社がベンダを「正しく比較するための道具」として機能します。
中小企業が陥りやすい要件定義の失敗パターンは？
最も多いのは「現場担当者が要件定義に関与せず、経営者だけで決めてしまう」ケースです。実際に操作するメンバーの声が抜け落ちると、完成後に仕様変更が多発して追加費用が発生します。
失敗パターン3類型と根本原因
要件定義の不備が原因となるプロジェクトのトラブルは、大きく3つのパターンに分類できます。
| # | 失敗パターン | 根本原因 | 発生しやすいタイミング |
|---|---|---|---|
| 1 | 現場不在の要件決定 | 経営者・DX担当者のみで仕様を確定し、実務担当者の確認を省略する | 要件定義フェーズ |
| 2 | 要件の後出し | 業務フローが整理されないまま発注し、開発中に「この機能も必要だった」が続出する | 開発着手後 |
| 3 | 用語・認識のズレ | 発注者とベンダが同じ言葉を異なる意味で使い、完成物が想定と乖離する | 受入検証フェーズ |
パターン1：現場不在の要件決定
経営者や管理職が要件を決めると、「誰がどの画面を操作するか」という現場の視点が欠けます。結果として、画面設計が実務の流れと合わず、リリース後に「使いにくい」という声が上がります。要件定義には、実際にシステムを使う担当者を必ず1名以上関与させます。
パターン2：要件の後出し
セクション1で解説した業務フロー整理が不十分なまま発注すると、このパターンに陥りやすくなります。開発が進んだ段階での仕様変更は、工数の組み直しが必要になるため、追加費用の交渉が難しくなります。「業務フローを先に固める」ことが、このリスクを防ぐ根本的な対策です。
パターン3：用語・認識のズレ
たとえば「承認機能」という言葉一つをとっても、「上長が内容を確認してボタンを押す」なのか「メールで通知が届いて返信する」なのかで、実装の工数はまったく異なります。要件定義書には機能名だけでなく、「誰が・何を・どう操作するか」を一文で書き添える習慣をつけます。
「要件の曖昧さ」がコスト増につながる仕組み
要件の曖昧さが追加費用に結びつく経路は、次の流れで起きます。
- 要件定義書に「〜など」「適宜対応」等の曖昧な表現が残る つまずきやすい点：「後で細かく決めればいい」と判断されがちだが、この段階の曖昧さが最も高くつく。
- ベンダが自社に都合のよい解釈で実装を進める 開発者は要件書に書かれた内容をそのまま仕様と見なします。悪意はなくとも、解釈の幅が広ければ最もコストのかからない実装を選ぶことがあります。
- 検収時に「イメージと違う」と気づく この時点で修正を求めると、多くの場合は契約範囲外の追加作業として別途費用が発生します。
- 変更管理ルールがないまま修正対応が積み上がる 「少し直すだけ」という認識の積み重ねが、当初見積もりを大きく超える最終費用につながります。
ベンダ側に悪意がなくても、曖昧な要件はトラブルの温床になります。発注者が「これくらい伝わるだろう」と思っている内容こそ、一文で明文化する必要があります。
実装者からの注意点 当社がシステム開発の相談を受ける際、「前のベンダとトラブルになった」という案件を振り返ると、ほぼ共通して要件定義書に「〜等」「〜に準ずる」という表現が複数個所に残っています。RFPや要件定義書のレビューでは、この種の表現を全て洗い出して具体的な記述に置き換えることを徹底しています。
失敗パターンを把握したうえで、次のセクションでは要件定義を5つのステップで体系的に進める方法を解説します。
要件定義の進め方：5つのステップ
要件定義は「課題の言語化→機能要件の列挙→優先順位付け→非機能要件の確認→関係者承認」の5ステップで進めると、抜け漏れが防げます。各ステップを順番通りに進めることで、ベンダとの認識ズレの原因となる曖昧さを事前に潰せます。
ステップ1〜2：課題の言語化と機能要件の列挙
ステップ1：課題を言語化する（目安：1〜2週間）
「システムを導入したい」という出発点を、「誰のどの作業が・何分かかっていて・なぜ問題なのか」まで掘り下げます。
書き方の型は次のとおりです。
「〔誰〕が〔何の作業〕を行うとき、〔現状の課題〕が発生しており、〔業務への影響〕が生じている」
この型を埋められれば、ベンダに口頭で説明しなくても課題が伝わります。
つまずきやすい点として、「作業が大変」「効率が悪い」といった形容詞だけで止まるケースが多くあります。「月末に在庫照合に4時間かかる」のように、数値で現状を表現してください。
ステップ2：機能要件を列挙する（目安：1〜2週間）
機能要件とは、「システムが行うべき動作・処理」のことです。課題ごとに「この課題を解決するためにシステムに何をさせるか」を1対1で対応づけながら列挙します。
| 課題 | 必要な機能 |
|---|---|
| 在庫数の手入力ミスが多い | バーコードスキャンによる在庫登録機能 |
| 勤怠データの集計に時間がかかる | 勤怠データの自動集計・CSV出力機能 |
| 承認フローが属人化している | ワークフロー機能（申請・差し戻し・承認） |
この段階では「できるかどうか」を考える必要はありません。実現可否の判断はベンダが行います。発注者がすべきことは「何が必要か」を漏れなく書き出すことです。
ステップ3〜4：優先順位付けと非機能要件の確認
ステップ3：機能に優先順位をつける（目安：3〜5営業日）
機能要件の列挙が終わったら、各機能を3段階に仕分けします。
| 優先度 | 定義 | 判断の目安 |
|---|---|---|
| Must（必須） | これがなければシステムを導入する意味がない | 現状の課題を直接解決する機能 |
| Want（あると良い） | あれば業務改善になるが、なくても運用できる | 利便性向上・将来拡張の候補 |
| Out（今回は対象外） | 今回のスコープには含めない | 他システムで代替可能・優先度低 |
Mustに絞ることが、予算超過を防ぐ最も効果的な方法です。「せっかくだから」でWantを積み上げると、開発規模が膨らみます。
参考値として、IPA「ソフトウェア開発データ白書2018-2019 情報通信業編」（238件の小規模プロジェクト、100FP未満を集計）によると、小規模システムの平均工期は約3.9か月、平均工数は約6.2人月です。機能を10%追加するだけで工期・工数が比例して伸びることを念頭に置き、Mustの絞り込みを徹底してください。
ステップ4：非機能要件を確認する（目安：3〜5営業日）
非機能要件とは、「何をするか（機能）」ではなく「どのくらいの品質でするか（性能・セキュリティ・可用性等）」を定めるものです。中小企業の要件定義でよく抜け落ちる項目を以下にまとめます。
| 非機能要件の種類 | 確認すべき問い | 記載例 |
|---|---|---|
| 同時利用人数 | 最大何人が同時にアクセスするか | 社内20名が業務時間内に常時使用 |
| レスポンス | 画面表示に許容できる待ち時間は何秒か | 検索結果は3秒以内に表示 |
| 稼働時間 | 何時から何時まで稼働が必要か | 平日8:00〜20:00（土日は不要） |
| データ保管期間 | 記録をどのくらいの期間保持する必要があるか | 取引データを7年間保管 |
| セキュリティ | 個人情報・機密情報を扱うか | 顧客の氏名・連絡先を含む |
| 外部連携 | 既存ツールとのデータ連携が必要か | 既存の会計ソフトとCSV連携 |
なお、総務省「令和6年通信利用動向調査報告書（企業編）」によると、国内企業全体のクラウドサービス利用率は2024年時点で77.0%に達しています。スクラッチ（ゼロから）開発ではなく、既存クラウドサービスと組み合わせる構成を選ぶ場合でも、この非機能要件の確認は省略できません。ベンダが提案するシステム構成が自社の要件を満たすかを評価する基準になるためです。
つまずきやすい点として、非機能要件は「考えていなかった」ではなく「後から思い出す」パターンが多くあります。ステップ4の段階で一覧を埋めておくことで、RFP作成時にそのまま流用できます。
ステップ5：社内承認と記録の残し方
ステップ5：関係者への承認と記録（目安：1〜2週間）
完成した要件定義書を、実際にシステムを使う現場担当者・予算を決める経営者・運用を担うIT担当者（または総務担当者）の三者が確認し、内容に合意した状態を作ります。
承認の手順は次のとおりです。
- 要件定義書の最終版を共有フォルダまたはメールで配布する
- 各関係者から「内容に異議ない」旨を書面またはメールで受け取る
- 承認日・承認者名・バージョン番号を要件定義書の表紙に記載する
- 変更が生じた場合は差分を明示した上で再承認を取る
この承認記録は、発注後に「言った・言わない」が発生したときの根拠になります。また、ベンダへのRFP添付資料としてそのまま使えます。
記録の形式は問いません。Wordでもスプレッドシートでも構いませんが、日付とバージョン管理ができるファイル名（例：要件定義書_v1.2_20250701.xlsx）にしておくと、後の追跡が容易になります。
実装者の視点 当社がAIチャットボット構築や業務システム開発の案件に入るとき、要件定義書が「最終版」と称しながら承認者不在のまま共有されているケースに頻繁に遭遇します。ベンダ側から見ると、承認者が不明な文書は「内容が変わる可能性がある」とみなされ、見積もりにバッファが上乗せされることがあります。社内承認の完了を明示するだけで、ベンダとの交渉が格段にスムーズになります。
RFPの書き方：中小企業向け7項目テンプレート
中小企業がゼロからRFPを作る場合、「①背景・目的、②現状の業務フロー、③システムへの要求機能、④非機能要件、⑤スケジュール・予算感、⑥選定基準、⑦提案書の提出形式」の7項目が最低限の骨格になります。この骨格があれば、IT専任担当者がいない企業でも複数ベンダへの比較検討が可能になります。
各項目の記載例と注意点
7項目それぞれに「何を書くか」と「よくある失敗」を示します。前のセクションで整理した要件定義の内容を、この順序に当てはめていくイメージです。
| 項目 | 記載する内容 | よくある失敗 |
|---|---|---|
| ①背景・目的 | なぜこのシステムが必要か。現状の課題と導入後に期待する変化 | 「効率化したい」だけで終わり、定量的なゴールがない |
| ②現状の業務フロー | 誰が・何を・どの順番で行っているか。セクション1で整理した内容をそのまま転記 | フローが省略されており、ベンダが現状を正確に把握できない |
| ③要求機能 | Must／Want／Outに仕分けした機能一覧。セクション4のステップ3の出力を使う | 全項目をMustにしてしまい、見積金額が跳ね上がる |
| ④非機能要件 | 想定ユーザ数、レスポンス目標、セキュリティ基準、可用性の要求水準 | 記載がなく、ベンダごとに異なる前提で提案が届く |
| ⑤スケジュール・予算感 | 稼働目標月、予算の上限または目安の金額帯 | 両方とも「未定」にすると提案内容がバラバラになる |
| ⑥選定基準 | 何を重視するか（機能適合度、保守体制、価格、実績など）と、その重み付け | 選定基準が非公開だとベンダ側が提案の方向性を絞れない |
| ⑦提出形式 | 提案書の構成指定、提出期限、担当窓口、Q&Aの受付方法 | 記載なしで各社バラバラな形式の提案が届き、比較が困難になる |
記載例として、①背景・目的は次のように書くと具体的です。
現在、受注管理をExcelで行っており、入力ミスと担当者間の転記作業に月あたり推定○時間を費やしている。2026年10月までに受注から請求までの一元管理を実現し、転記作業をゼロにすることを目的とする。
数値と期限を明示するだけで、ベンダが提案の優先度を判断しやすくなります。
なお、②現状の業務フローはセクション1で整理した内容をほぼそのまま転記できます。重複して作業する必要はありません。
予算感の書き方：金額を明示すべき理由
予算感は「書きたくない」と感じる発注者が多い項目ですが、明示することがベンダと発注者の双方にとって合理的です。
理由は2つあります。
- ベンダは予算帯によってアーキテクチャの選択肢を変えます。同じ機能でもスクラッチ開発とパッケージ導入では費用が数倍異なるため、予算が不明だと提案の前提が揃いません。
- 予算を非公開にすると、ベンダは「最大限盛った提案」を出す傾向があります。結果として、発注者が必要としない機能への費用が提案書に含まれ、比較が難しくなります。
社内システムの外注費用の詳細な相場については、社内システム開発の外注費用相場｜中小企業向け3つの選択肢を参照してください。本記事では費用相場には踏み込みません。
予算感の記載フォーマット例
初期開発費用の上限: ○○万円（税込）
月次保守費用の想定: ○万円以内
※予算を超える場合は、機能の優先順位を協議のうえ調整可能
金額を「上限」として明示したうえで「調整可能」と添えると、ベンダが提案をスコープ調整しやすくなります。金額ではなく「○○万円台」「○○万円〜○○万円」という帯での記載も許容されます。
一点、注意が必要です。予算感を明示しても、それがそのまま見積金額の上限交渉材料になるわけではありません。提案書の比較と選定基準の適用は、金額だけでなくセクション6で述べる3つの軸で行います。
RFPの7項目を埋めた時点で、御社はベンダとの対等な対話が可能な状態になります。次のセクションでは、届いた提案書をどの軸で比較し、何社から相見積もりを取るべきかを解説します。
発注前の最終チェックリスト
発注書にサインする前に「要件定義書と提案書の内容が一致しているか」「変更管理のルールが契約書に明記されているか」を確認することが、発注後トラブルを防ぐ最後の砦になります。
ここまでのステップで要件定義とRFPを整備し、ベンダの提案書を受け取った状態を前提に、署名前に通すべきチェック項目を整理します。
確認カテゴリと各チェック項目
以下の4カテゴリ、計16項目を順番に確認してください。「×」が1つでも残る場合は、ベンダに書面で回答を求めてから次のステップへ進みます。
| カテゴリ | チェック項目 | 確認方法 |
|---|---|---|
| ①要件と提案の整合 | 要件定義書の機能要件リスト（Must）がすべて提案書に含まれている | 機能要件リストと提案書を並べて1行ずつ照合する |
| 非機能要件（性能・セキュリティ・可用性）の数値目標が提案書に明記されている | 提案書の仕様欄に具体的な数値があるか確認する | |
| Outと定義した機能が提案範囲に含まれていない | 提案書の「対象外」欄または口頭確認で明確にする | |
| 業務フローの各ステップに対応する画面・機能が特定できる | 提案書の画面一覧や機能一覧と業務フロー図を突き合わせる | |
| ②費用と見積もり | 見積書の合計金額がRFPに記載した予算上限の範囲内である | 見積書の「合計」欄と自社のRFP記載額を比較する |
| 追加費用が発生する条件（仕様変更・工数超過など）が明記されている | 見積書または契約書の「追加費用の定義」欄を確認する | |
| 保守・運用フェーズの月額費用が別途提示されている | 見積書に「開発費」と「保守費」が分離して記載されているか確認する | |
| ③契約内容 | 変更管理プロセス（仕様変更の申請・承認フロー）が契約書に記載されている | 契約書の「変更管理」または「仕様変更」の条項を探す |
| 検収基準（どの状態を「完成」とするか）が数値または状態として定義されている | 契約書の「検収」条項に具体的な基準があるか確認する | |
| 瑕疵担保責任の期間と対象範囲が明記されている | 契約書の「瑕疵担保」または「保証」条項を確認する | |
| 知的財産権（ソースコード・データ）の帰属が明確になっている | 契約書の「権利の帰属」条項を確認する | |
| 個人情報・機密情報の取り扱いに関するNDAが締結されている | NDA文書または契約書内の秘密保持条項を確認する | |
| ④体制とスケジュール | プロジェクトマネージャの担当者名と連絡先が提示されている | 提案書または別途提示された体制図で確認する |
| 自社側の窓口担当者（発注者側PM）が確定している | 社内で担当者を指名し、ベンダに書面で通知する | |
| マイルストーン（中間納品・テスト・本番リリース）の日程が契約書またはWBSに記載されている | 契約書またはプロジェクト計画書のスケジュール欄を確認する | |
| 連絡手段・報告頻度（週次報告など）が合意されている | キックオフ前に書面またはメールで合意内容を残す |
チェック時によくある引っかかり箇所
実際の発注直前フェーズで見落とされやすい点を3つ挙げます。
検収基準の曖昧さ 「正常に動作すること」という表現は検収基準として機能しません。「指定した10件のテストケースがすべてパスすること」のように、検証可能な状態で定義します。ベンダが草案を用意していない場合は、自社から条件を提示してください。
ソースコードの権利帰属 受託開発では成果物の権利がデフォルトでベンダ側に帰属する契約もあります。将来の改修や別ベンダへの乗り換えを想定するなら、「発注者に権利が譲渡される」と契約書に明記することが必要です。
保守費用の分離確認 開発費のみを比較して安価なベンダを選んだ結果、運用開始後の保守費が高額になるケースがあります。比較段階から「開発費＋初年度保守費」の合計で判断することを習慣にしてください。
16項目すべてに「○」が揃った状態で初めて、発注書への署名と正式発注に進んでください。チェック中にベンダへの確認が必要な項目が出た場合は、回答を必ずメールで残します。口頭での確認は後から証拠として使えないためです。