― 情報担当がいない会社こそ覚えておくべき「要件定義・スコープ・見積・RFP」の基本 ―

1. はじめに

中小企業でシステム導入やWebシステム構築を行うとき、よくある失敗はこれです。

「業者に任せたら、思っていたものと違うものができた」
「見積は安かったのに、あとから追加費用だらけになった」
「社内の誰も仕様を説明できない」
「結局、何を発注したのか分からない」

これは業者だけの問題ではありません。
多くの場合、発注側の要件定義・スコープ整理・比較基準が曖昧なまま発注していることが原因です。

そこで役に立つのが、PMBOKの考え方です。

PMBOKは、PMIが公開しているプロジェクトマネジメントの標準的な知識体系です。2026年6月時点ではPMBOK Guide第8版が案内されており、PMIは第8版について、価値提供、適応、説明責任を重視し、ガバナンス、スコープ、スケジュール、財務、ステークホルダー、リソース、リスクなどの実務領域を扱うものと説明しています。

ただし、ここで大事なのは資格試験の勉強ではありません。

情報担当がいない会社でも、システム構築で失敗しないための共通言語としてPMBOK的に考えることです。

2. この講義で覚えるべき結論

システム構築は「作る前」が8割

システム構築で一番大切なのは、プログラムを書くことでも、サーバーを立てることでもありません。

一番大切なのは、

何を解決するために、何を作り、何を作らないのかを決めることです。

この「何を作るか」「どこまでやるか」「誰が判断するか」「どう検収するか」を整理するのが、要件定義・スコープ管理・調達管理です。

3. PMBOKを現場向けに言い換える

PMBOKを中小企業向けに言い換えると、こうです。

つまりPMBOKは、システム開発を業者任せにしないための管理の型です。

4. システム構築の基本フェーズ

システム構築は、次の流れで考えると分かりやすくなります。

フェーズ0：課題整理

最初にやることは、システム名を決めることではありません。
まず、困っていることを整理します。

例：

• 紙で管理していて探すのに時間がかかる
• Excelが担当者ごとにバラバラ
• 顧客対応履歴が残っていない
• 予約管理が属人化している
• メールやLINEでの連絡が混在している
• 退職者が出ると業務が分からなくなる

ここで重要なのは、いきなり「システムを作る」と決めないことです。

場合によっては、既存サービスで足りることもあります。
逆に、業務ルールを変えないと、どんなシステムを入れても失敗します。

フェーズ1：現状整理

次に、現在の業務を整理します。

見るべきものは以下です。

• 現在使っている帳票
• Excelファイル
• 紙の申請書
• メールの流れ
• 担当者の役割
• 承認フロー
• 顧客情報・社員情報・予約情報などのデータ
• 現在の不満点
• 絶対に変えたくない運用

ここで作るべき資料は、現状業務フローです。

難しい図である必要はありません。

受付 → 入力 → 確認 → 承認 → 通知 → 保管

この程度でも十分です。

フェーズ2：要件定義

要件定義とは、簡単に言えば、

このシステムに何を求めるのかを言語化する作業

です。

PMIの要求事項管理に関する資料でも、要求事項は収集・文書化・管理されるべきものであり、要求事項管理計画、要求事項文書、要求事項トレーサビリティ・マトリックスが重要な成果物として説明されています。

要件は大きく分けると、次の2種類です。

機能要件

「何ができるか」です。

例：

• ログインできる
• 顧客情報を登録できる
• 予約を登録できる
• CSVで出力できる
• 管理者がユーザーを追加できる
• メール通知できる
• スマホで閲覧できる

非機能要件

「どの品質で動くか」です。

例：

• 何人まで同時アクセスできるか
• 何秒以内に表示されるか
• バックアップはどうするか
• 障害時に何時間以内に復旧するか
• 権限管理はどうするか
• ログを何年保存するか
• 個人情報をどう守るか
• スマホ・タブレット対応はどこまで行うか

中小企業で特に漏れやすいのは、非機能要件です。

画面の見た目や機能ばかり話して、バックアップ、権限、ログ、セキュリティ、運用保守が後回しになります。
しかし、実際にトラブルになるのは非機能要件の方です。

5. スコープとは何か

スコープとは、プロジェクトの範囲です。

つまり、今回やること・やらないことの線引きです。

システム構築で揉める原因の多くは、このスコープが曖昧なことです。

悪い例

顧客管理システムを作ってください。

これでは範囲が分かりません。

良い例

顧客情報の登録、検索、編集、削除、CSV出力、担当者メモ、対応履歴管理までを対象とする。
請求書発行、会計ソフト連携、LINE連携、在庫管理は今回の対象外とする。

このように、対象外を書くことが重要です。

6. スコープ定義で必ず決めること

特に重要なのは、対象外・成果物・検収条件です。

この3つが曖昧だと、後で必ず揉めます。

7. RFI・RFP・RFQの違い

システム構築では、業者にいきなり「いくらですか？」と聞くのは危険です。
目的に応じて、RFI、RFP、RFQを使い分けます。

RFIは、見込み業者の能力やサービス内容を確認するための情報収集に使われ、RFQは価格条件を確認するもの、RFPは会社概要やサービス内容、実施方法などを包括的に求めるものとして整理されています。

また、RFPはプロジェクト内容、スコープ、評価基準、契約条件などを示して提案を求める文書であり、単に最安値を選ぶためだけのものではありません。

8. 一番簡単な覚え方

RFI：まだ分からないから教えてください

例：

顧客管理システムを検討しています。
クラウド型、スクラッチ開発、WordPress連携、既存SaaSなど、どのような選択肢がありますか？

RFP：こういう課題があるので提案してください

例：

当社は予約管理と顧客管理を一元化したいです。
現状、Excelと電話で管理しており、二重予約や対応漏れが発生しています。
解決方法、構成、費用、スケジュール、保守体制を提案してください。

RFQ：この仕様でいくらですか

例：

添付仕様書の内容で、初期費用、月額費用、保守費用、追加開発単価を提示してください。

9. 三社見積もりの正しいやり方

三社見積もりは、単に「3社から金額を取ること」ではありません。

本来の目的は、

同じ条件で比較し、価格・提案・リスク・保守体制を見極めること

です。

悪い三社見積もり

• A社には口頭で説明
• B社にはメールだけ送る
• C社には資料を渡す
• 各社に違う内容を伝える
• 金額だけ比較する
• 安い会社を自動的に選ぶ

これでは比較になりません。

良い三社見積もり

• 同じRFPを渡す
• 同じ質問受付期間を設ける
• 回答内容のフォーマットを揃える
• 評価基準を事前に決める
• 金額だけでなく、保守・実績・リスク説明も見る

10. 見積比較表の例

費用の配点を100点中10点程度にしているのがポイントです。

なぜなら、システム構築では、安いけど要件が抜けている見積が一番危険だからです。

11. RFPに書くべき項目

RFPには、最低限これを書きます。

1. 会社概要

• 業種
• 拠点数
• 従業員数
• 利用予定人数
• 現在のシステム環境

2. 背景・課題

• なぜ導入するのか
• 現在何に困っているのか
• 放置すると何が問題か

3. 目的

• 業務時間を削減したい
• 二重入力をなくしたい
• 情報共有したい
• 属人化を防ぎたい
• セキュリティを高めたい

4. 対象範囲

• 対象業務
• 対象ユーザー
• 対象拠点
• 対象端末
• 対象データ

5. 対象外

• 今回やらないこと
• 将来的に検討すること
• 別契約にすること

6. 機能要件

• ログイン
• ユーザー管理
• 登録
• 検索
• 編集
• 承認
• 通知
• CSV出力
• 帳票出力

7. 非機能要件

• セキュリティ
• バックアップ
• ログ保存
• 権限管理
• 障害対応
• スマホ対応
• 保守体制
• データ移行
• 操作マニュアル

8. 納品物

• システム本体
• 設計書
• 管理者マニュアル
• 利用者マニュアル
• テスト結果
• 保守資料
• アカウント一覧
• バックアップ手順

9. スケジュール

• 提案締切
• 業者選定日
• 要件定義期間
• 設計期間
• 構築期間
• テスト期間
• 本番公開日

10. 評価基準

• 金額
• 実績
• 提案内容
• 保守体制
• セキュリティ
• 担当者の説明力
• 将来拡張性

12. 要件定義で必ず確認する質問

情報担当がいない会社は、最低限これだけ聞ければ十分です。

業務面

• 誰が使うのか
• 何人が使うのか
• いつ使うのか
• どの業務を楽にしたいのか
• 今の運用で残したいものは何か
• 絶対に変えたくないルールは何か

データ面

• どんな情報を扱うのか
• 個人情報はあるか
• データは何年保存するか
• CSV出力は必要か
• 既存データの移行は必要か

権限面

• 管理者は誰か
• 一般ユーザーは何ができるか
• 閲覧だけの人はいるか
• 退職者アカウントをどう止めるか

セキュリティ面

• 二要素認証は必要か
• ログは残るか
• バックアップはあるか
• 管理画面のアクセス制限はあるか
• 障害時の連絡先はどこか

契約面

• 初期費用はいくらか
• 月額費用はいくらか
• 保守範囲はどこまでか
• 追加作業の単価はいくらか
• 解約時にデータを取り出せるか
• ドメイン、サーバー、ソースコードの権利はどうなるか

13. システム構築で失敗する典型例

失敗1：目的が曖昧

「便利にしたい」だけでは作れません。

正しくは、

予約管理の二重入力をなくし、受付業務を1日30分削減する

のように、目的を具体化します。

失敗2：スコープが曖昧

「顧客管理もできますよね？」
「請求書も出せますよね？」
「LINE通知もできますよね？」

このように後から増えると、費用も納期も変わります。

だから最初に、

• 今回やること
• 今回やらないこと
• 将来やること

を分けます。

失敗3：見積の前提が違う

A社はデータ移行込み。
B社はデータ移行なし。
C社は保守別料金。

この状態で金額だけ比べても意味がありません。

見積比較では、必ず前提条件を確認します。

失敗4：検収条件がない

検収条件がないと、完成の判断ができません。

例：

• 指定した機能が動作する
• テスト項目をすべて通過する
• 管理者マニュアルが納品される
• 本番環境でログイン確認できる
• 既存データが正しく移行されている

ここまで決めて、初めて「納品」と言えます。

14. 情報担当がいない会社向けの最低限チェックリスト

発注前チェック

• 目的は明確か
• 現状業務は整理したか
• 対象範囲は決めたか
• 対象外は書いたか
• 予算上限はあるか
• 社内の決裁者は誰か
• 利用者の意見を聞いたか
• RFI、RFP、RFQを使い分けたか
• 三社に同じ条件を渡したか
• 評価基準を決めたか

契約前チェック

• 見積の範囲は明確か
• 保守範囲は明確か
• 追加費用の条件は明確か
• 納品物は明確か
• 検収条件は明確か
• データの所有権は明確か
• 解約時の扱いは明確か
• 障害時の連絡方法は明確か

構築中チェック

• 定例会はあるか
• 議事録は残しているか
• 変更要望を記録しているか
• 追加費用の有無を確認しているか
• テスト項目を作っているか
• 利用者に事前確認させているか

15. まとめ

システム構築は、ITの専門知識がない会社ほど、最初の整理が重要です。

覚えるべきことは多くありません。

最低限、この5つだけ覚える

1. 要件定義
   何を実現したいのかを言語化する。
2. スコープ
   やること・やらないことを決める。
3. RFI
   まだ分からない段階で情報を集める。
4. RFP
   課題と条件を示して提案を受ける。
5. RFQ・三社見積もり
   同じ条件で金額と内容を比較する。

情報担当がいない会社でも、PMBOKの細かい用語を全部覚える必要はありません。

しかし、

目的、要件、スコープ、見積条件、検収条件

この5つを押さえるだけで、システム構築の失敗確率は大きく下がります。

業者に丸投げするのではなく、発注者側も最低限の言葉を持つ。

それが、システム構築で損をしないための第一歩です。