システム開発ヒアリングシート｜依頼前の作り方

システム開発のヒアリングシート（＝初回相談前に目的・業務・機能・制約を整理する資料）は、完成した仕様書である必要はありません。未確定事項も含めて共通条件を提示し、見積もりの前提と次に決めることを揃えるのが役割です。

• システム開発のヒアリングシートとは
  • RFP・要件定義書との違い
• ヒアリングシートに記載する必須項目
  • 1．開発の背景・目的・成果指標
  • 2．利用者と関係者
  • 3．現状業務と導入後の業務
  • 4．必要機能と優先順位
  • 5．データ・外部連携・移行
  • 6．品質・セキュリティ・運用条件
  • 7．予算・希望時期・契約条件
  • 8．社内の意思決定体制
• ヒアリングシートの作り方と費用・期間
  • ステップ1．目的と決定事項を1ページにまとめる
  • ステップ2．業務担当者へ聞き取る
  • ステップ3．機能を整理して優先順位を付ける
  • ステップ4．制約と資料を集める
  • ステップ5．社内確認後、版を固定して送付する
  • 作成支援を外注する場合の費用
• 見積もりと開発会社を比較するポイント
  • 見積書で確認する項目
  • 開発会社の回答で見るべき点
  • よくある失敗と回避策
• まとめ
• よくある質問
  • ヒアリングシートは何ページ必要ですか？
  • 開発予算が決まっていなくても相談できますか？
  • 機密情報を含む資料はいつ共有すべきですか？
  • ヒアリングシートや要件整理から外注できますか？

システム開発のヒアリングシートとは

ヒアリングシートで最も重要なのは、画面や機能の細部ではなく「何のために開発するのか」「誰のどの業務を変えるのか」を開発会社へ伝えることです。初回相談の段階ですべてを確定させる必要はなく、決定済み・仮説・未定を区別して書けば十分です。

システム開発の相談では、発注者が同じ説明をしているつもりでも、開発会社ごとに異なる前提で見積もられることがあります。例えば「顧客管理機能」という一言だけでは、顧客情報の登録だけなのか、商談管理、メール配信、権限管理、外部サービス連携まで含むのか判断できません。ヒアリングシートは、このような解釈の差を減らすための共通資料です。

要件定義（＝作るものと満たす条件を決める工程）の前に作成し、開発会社との対話を通じて内容を具体化していきます。完成度の高い仕様書を発注者だけで作ろうとするより、業務上の事実、希望、制約、分からないことを正直に整理する方が有用です。

RFP・要件定義書との違い

ヒアリングシート、RFP、要件定義書は、使う時期と目的が異なります。RFP（＝複数の候補会社へ提案を依頼する文書）は選定条件を揃える資料であり、要件定義書は発注後も含めて開発範囲を合意する資料です。

ヒアリングシートを作る主なメリットは次のとおりです。

• 社内で開発目的と優先順位を確認できる
• 複数の開発会社へ同じ前提を伝えられる
• 見積もりの範囲外や前提条件を発見しやすくなる
• 開発会社から具体的な質問や代替案を引き出せる
• 要件定義に入ってからの手戻りを減らせる
• 発注者側で決める人、確認する人を明らかにできる

発注のご相談を受ける立場から見ると、資料の見栄えよりも「現状は何に困っているか」「予算や期限に合わせて何を削れるか」が書かれている案件ほど、現実的な提案を組み立てやすくなります。

ヒアリングシートに記載する必須項目

ヒアリングシートには、目的、利用者、業務、機能、データ、品質条件、予算・時期、社内体制の8領域を記載します。分からない項目は空欄にせず、「未定」「開発会社から提案希望」と書くことがポイントです。

1．開発の背景・目的・成果指標

最初に、システムを作る理由と、導入後に実現したい変化を書きます。「業務を効率化したい」だけでは判断基準になりにくいため、現状の問題と目標をセットにしてください。

KPI（＝成果を確認するための数値指標）は、初回時点では仮置きでも構いません。

「スマホアプリを作りたい」「AIを導入したい」は手段であり、目的ではありません。目的が明確なら、開発会社からWebシステムや既製サービスなど、より適した方法を提案してもらえる可能性があります。

2．利用者と関係者

利用者の種類、人数、利用環境、権限を整理します。管理者と一般利用者だけでなく、取引先、承認者、問い合わせ対応者、システム運用担当者も確認してください。

• 誰が利用するか
• 利用者は社内だけか、顧客や取引先も含むか
• 現在と3年後で利用者数はどの程度か
• パソコン、スマートフォン、タブレットのどれを使うか
• 社外や海外から利用するか
• 閲覧・登録・承認・削除など、役割ごとに何ができるべきか
• 利用者のIT習熟度に差があるか
• 問い合わせやアカウント管理を誰が担当するか

利用者数は、インフラ費用やライセンス費用だけでなく、権限設計、性能、問い合わせ対応の見積もりにも影響します。

3．現状業務と導入後の業務

画面案を作る前に、情報がどこから入り、誰が処理し、何を出力するのかを整理します。通常の流れだけでなく、差し戻し、取消、再申請、担当者不在などの例外も重要です。

最低限、次の内容を記載してください。

• 業務の開始条件と終了条件
• 作業を行う部署・担当者
• 使用中の表計算ファイル、紙、メール、既存システム
• 承認や確認が必要な箇所
• 1日・1か月当たりの処理件数
• 繁忙期と通常期の差
• 現在、時間がかかっている作業
• ミスが発生しやすい作業
• システム化せず人が判断すべき作業

現状業務を無視して機能だけ決めると、完成後に「実際の承認手順に合わない」「例外処理だけ手作業のまま」といった問題が起こります。既に業務の流れを整理している場合は、ヒアリングシートへ業務フロー図を添付すると説明しやすくなります。

4．必要機能と優先順位

機能は「絶対に必要」「できれば必要」「将来対応」に分けます。すべてを必須にすると、予算超過時に削る基準がなくなります。

各機能には「誰が」「何のために」「何をするか」を書きます。例えば「CSV機能」ではなく、「管理者が月末に会計システムへ取り込むため、確定済みの請求データをCSV形式で出力する」と記載すると、対象データや利用目的が伝わります。

機能を体系的に整理したい場合は、機能一覧の作り方｜システム開発の依頼準備も参考にしてください。

5．データ・外部連携・移行

既存データや外部サービスとの接続は、見積もり差が出やすい領域です。単に「データ移行あり」と書くのではなく、可能な範囲で量、形式、品質、移行時期を伝えます。

• 移行元のシステムやファイル
• データの種類と項目数
• レコード件数、ファイル数、総容量のおおよその規模
• 重複、欠損、表記揺れの有無
• 過去何年分を移すか
• 添付ファイルや画像も対象か
• 移行中に現行システムを止められるか
• 連携する会計、決済、認証、メールなどのサービス
• 外部サービスの契約状況と技術資料の有無

実データを初回相談のメールへ添付する必要はありません。個人情報や営業秘密を除いた項目一覧、画面の一部、匿名化したサンプルがあれば、調査に必要な情報を伝えられます。

6．品質・セキュリティ・運用条件

非機能要件（＝機能以外に求める性能、安全性、安定性などの条件）は、後から追加すると構成や費用に大きく影響する場合があります。初回段階でも、事業上重要な条件は共有してください。

• 利用可能にしたい時間帯
• 障害時に許容できる停止時間
• 想定アクセス数や繁忙時間帯
• 保存する個人情報・機密情報の種類
• ログイン方法や多要素認証の必要性
• 操作履歴や監査ログの保存要件
• バックアップの頻度と保存期間
• 対応が必要な社内規程や業界ルール
• 公開後の監視、問い合わせ、障害対応の担当範囲
• 対応ブラウザ、端末、OS

「高度なセキュリティ」などの抽象的な表現ではなく、扱う情報と想定する利用方法を伝え、必要な対策を開発会社に提案してもらうのが現実的です。

7．予算・希望時期・契約条件

予算と期限は、提案の前提になる制約条件です。厳密に決まっていなくても、想定範囲と背景を共有してください。

• 初期開発費の上限または想定範囲
• 要件定義、デザイン、データ移行を予算に含むか
• 公開後の保守運用に使える月額予算
• 希望公開日と、その日である必要性
• 段階公開が可能か
• 社内の予算承認時期
• 支払い条件に社内ルールがあるか
• 希望する契約形態があるか

予算を伝えると見積金額を合わせられるのではないかと心配する発注者もいます。しかし、予算を伏せたままでは、500万円規模の提案と2,000万円規模の提案が混在し、比較できないことがあります。予算内の必須案と、効果を高める追加案を分けて提示してもらうと判断しやすくなります。

8．社内の意思決定体制

システム開発では、発注者側の確認待ちも納期へ影響します。誰が要望を集約し、誰が最終決定するかを明記してください。

• プロジェクト責任者
• 日常的な窓口担当者
• 業務要件を確認する担当者
• セキュリティ・法務・経理などの確認部門
• 最終決裁者
• 各担当者が会議や確認に使える時間
• 社内承認に必要な期間
• 成果物を確認し、受入判断をする担当者

複数部門が関わる場合、「営業部の希望」と「経理部の必須条件」が衝突することもあります。開発会社との打ち合わせ前に、最終的な優先順位を決める責任者を置くことが大切です。

ヒアリングシートの作り方と費用・期間

小規模な案件なら、社内で3営業日〜2週間程度をかけて初版を作れます。複数部門への聞き取りや現行業務の調査が必要な場合は、3〜8週間程度を見込むことがあります。重要なのは、一度で完成させることではなく、初版を作って関係者と更新することです。

ステップ1．目的と決定事項を1ページにまとめる

最初に、背景、目的、対象利用者、予算、希望時期を1ページにまとめます。詳細を読む前に案件全体が分かる要約として使います。

この時点で、次の3種類に分けて表示してください。

• 決定済み：社内で変更予定がない条件
• 仮説：現時点の案であり、提案によって変更できる内容
• 未定：調査や協議が必要な内容

未定事項を隠すと、開発会社が任意の前提で見積もることになります。「未定なので、要件定義で比較検討したい」と明記した方が安全です。

ステップ2．業務担当者へ聞き取る

現場担当者には、欲しい機能だけでなく、日々の作業を時系列で聞きます。「どの画面が欲しいですか」ではなく、次のような質問が有効です。

• 作業のきっかけは何ですか
• どの情報を、誰から受け取りますか
• 何を確認して次の担当者へ渡しますか
• 判断できない場合は誰に確認しますか
• 月末や繁忙期だけ発生する作業はありますか
• 入力を間違えた場合はどう直しますか
• 現在の方法で困っていない点は何ですか

現在うまく機能している業務まで無理に変える必要はありません。システム化の対象外を明確にすることも、開発範囲を抑える有効な判断です。

ステップ3．機能を整理して優先順位を付ける

聞き取った要望をそのまま並べるのではなく、重複をまとめ、目的との関係を確認します。各機能に「解決する課題」「対象利用者」「優先度」を付けてください。

初回リリースに必要最小限の範囲を定めると、予算に応じた段階開発を相談できます。ただし、単に機能数を減らすだけではなく、利用開始から業務完了まで一連の流れが成立するかを確認する必要があります。

ステップ4．制約と資料を集める

次に、既存システム、データ、外部サービス、社内規程、希望納期などの制約を集めます。添付できる資料には次のようなものがあります。

• 現行の業務フロー図
• 帳票や表計算ファイルの見本
• 既存システムの画面一覧
• 匿名化したデータ項目一覧
• 社内セキュリティチェックシート
• ブランドガイドライン
• 外部サービスの仕様資料
• 類似サービスの参考URL

参考サービスを示す場合は、「どこを参考にしたいか」も書きます。サービス全体を同等に作る前提と誤解されないよう、例えば「検索条件の選び方のみ参考」「デザインではなく予約手順を参考」と限定してください。

ステップ5．社内確認後、版を固定して送付する

候補会社へ送る前に、責任者、現場担当者、情報システム部門などが確認します。複数社へ見積もりを依頼する場合は、同じ版の資料を配布してください。

送付前のチェックリストは次のとおりです。

• 開発目的と利用者が記載されている
• 現状の課題が具体的に説明されている
• 必須機能と追加候補が区別されている
• 対象外の業務や機能が記載されている
• データ移行と外部連携の有無が分かる
• 予算と希望時期が記載されている
• 未確定事項が明示されている
• 社内の決定者と窓口が決まっている
• 個人情報や不要な機密情報を削除している
• 資料に作成日と版番号が付いている

作成支援を外注する場合の費用

発注者だけで整理できない場合は、要件整理の支援を外注できます。一般的な目安は次のとおりですが、対象部門数、現行資料の状態、業務の複雑さによって変動します。

初回相談や概算見積もりを無料とする会社もありますが、無料相談で行われるのは案件概要の確認が中心です。現場への聞き取り、業務分析、詳細な文書作成まで求めるなら、有償の要件整理として範囲と成果物を合意する方が双方にとって明確です。

外注時には、次の項目を確認してください。

• ヒアリングの回数と参加対象者
• 業務フローや機能一覧も成果物に含むか
• 課題の整理だけか、解決方法の提案も含むか
• 概算見積もりまで行うか
• 作成した資料を他社への見積もり依頼にも使えるか
• 納品形式と編集可能な元データの有無
• 追加ヒアリングが発生した場合の費用

見積もりと開発会社を比較するポイント

ヒアリングシートを送付した後は、金額だけでなく「どの前提で見積もったか」を比較します。同じ資料を渡しても、要件の解釈、開発範囲、リスクの見込み方によって見積額は変わるからです。

見積書で確認する項目

見積書には、少なくとも次の区分があるか確認してください。

• 要件定義
• 設計
• デザイン
• 開発・設定
• テスト
• データ移行
• 外部サービス連携
• プロジェクト管理
• インフラ構築
• リリース作業
• 操作説明やマニュアル
• 公開後の保守運用
• 外部サービスの利用料

一式見積もりが直ちに問題というわけではありませんが、範囲と前提が読み取れない場合は比較ができません。次の点を質問しましょう。

• 見積もりに含まれない作業は何か
• 発注者が用意する資料やデータは何か
• 未確定要件はどのように仮定したか
• 修正回数や打ち合わせ回数に上限があるか
• 要件変更時に追加費用を算出する方法は何か
• テスト対象の端末やブラウザは何か
• データ移行の試行回数は何回か
• 公開後の不具合対応期間はどの程度か

概算見積もり（＝詳細決定前の大まかな金額）と確定見積もりは分けて考える必要があります。ヒアリングシートだけで出る金額は、通常、一定の仮定を置いた概算です。どの工程で要件を確定し、いつ金額を見直すかを確認してください。

開発会社の回答で見るべき点

信頼できる提案かどうかは、質問の内容にも表れます。発注者の要望をそのまま見積もるだけでなく、目的や業務へ立ち返って確認する会社の方が、認識違いを早期に発見しやすい傾向があります。

比較時は、次の観点を確認してください。

• 開発目的を自社の言葉で説明し直せるか
• 不明点と見積もり上の仮定を明示しているか
• 必須機能と後回しにできる機能を提案できるか
• 既製サービスの利用など、開発しない選択肢も示すか
• 業務の例外や運用体制まで質問するか
• 技術的な内容を非エンジニアにも説明できるか
• 発注者側に必要な作業と期限を示しているか
• 要件変更時の手続きが明確か
• 作成する文書と確認方法が示されているか

安い見積もりが、必ずしも効率的な提案とは限りません。要件定義、移行、テスト、保守などが含まれていないために安く見える場合もあります。一方、高い見積もりにも過剰な品質条件や不要な機能が含まれる可能性があります。総額だけでなく、範囲、前提、体制、公開後の費用を同じ表へ並べて比較してください。

よくある失敗と回避策

ヒアリングシートの作成段階で判断に迷う場合は、仕様を無理に確定させず、課題と制約を整理した状態で専門家へ相談する方法もあります。開発のご相談はこちらから、要件整理を含めてご相談いただけます。

まとめ

• ヒアリングシートは、初回相談前に目的、業務、機能、制約を伝えるための資料です
• 完成した仕様書にする必要はなく、決定済み・仮説・未定を区別することが重要です
• 目的、利用者、現状業務、機能、データ、品質条件、予算、社内体制の8領域を整理します
• 機能には優先順位を付け、予算に応じて初回範囲と将来範囲を分けます
• 自社作成なら数日〜2週間程度、複数部門の調査を伴う場合は3〜8週間程度が一般的な目安です
• 作成支援の外注費は、レビューのみで5万〜20万円程度、ヒアリングと資料作成で10万〜50万円程度が一つの目安です
• 複数社へ依頼する場合は、同じ版の資料を渡し、金額だけでなく範囲と見積もり前提を比較します
• 個人情報や機密情報は匿名化し、詳細資料は必要に応じて秘密保持契約後に共有します

よくある質問

ヒアリングシートは何ページ必要ですか？

一般的には2〜10ページ程度でも初回相談に必要な情報を整理できます。ページ数よりも、目的、利用者、対象業務、必要機能、予算、希望時期、未確定事項が読み取れることが重要です。資料が多い場合は、最初に1〜2ページの要約を付けると伝わりやすくなります。

開発予算が決まっていなくても相談できますか？

相談は可能ですが、完全に非公開にするより「初期費用は500万円以内を想定」「複数年度で予算化を検討」など、現時点の上限や想定範囲を共有する方が現実的な提案を受けやすくなります。予算が未定なら、予算別に実現範囲を提示してもらう方法もあります。

機密情報を含む資料はいつ共有すべきですか？

初回相談では匿名化した業務例や項目名だけを提示し、詳細な顧客情報、個人情報、営業秘密は秘密保持契約の締結後に共有するのが基本です。見積もりに実データが必要な場合も、件数や形式が分かるサンプルデータを作成し、不要な機密情報を除いてください。

ヒアリングシートや要件整理から外注できますか？

外注できます。一般的な目安として、初期ヒアリングと資料整理は10万〜50万円程度、業務分析や複数部門の調整を含む場合は30万〜150万円以上になることがあります。成果物、実施回数、対象部門、開発見積もりまで含むかを確認して契約してください。