完成した要件定義書がなくても、システム開発は相談できます。必要なのは、画面一覧や機能一覧を書き切ることではありません。いま何に困り、現場がどう動き、どの条件なら変えられるかを開発会社と確かめられる材料です。
たとえば、17時に届いたFAX注文を営業事務がExcelへ転記し、商品コードを販売管理システムで検索しているとします。担当者は「FAXを自動で読める画面」を思い浮かべるかもしれません。しかし実際に詰まりやすいのは、得意先ごとに違う品番、判読できない手書き、在庫不足時の確認、締め時間を過ぎた注文の扱いです。相談前に集めるのは、完成画面の絵ではなく、この手順と例外です。
要件書がなくても、システム開発を相談できるか？
相談できます。完成資料の代わりに、現行業務と変えられない条件を開発会社と確認できる状態にします。
IPAのユーザのための要件定義ガイドは、要件を定義する責任は、構築したシステムを利用して事業に貢献するユーザ側にあると説明しています。これは「発注前に自社だけで仕様書を書き上げる」という意味ではありません。業務部門が、何を実現したいかを判断する役割から降りない、ということです。
相談前に要らないものと、代わりに持っていくものを分けると、準備の重さが見えます。
| 相談前に完成していなくてよいもの | 代わりに持っていくもの |
|---|---|
| 画面遷移図 | 現在使っている画面や帳票の例 |
| 全機能の一覧 | なくしたい作業と発生頻度 |
| 新しい業務フロー | 現在の手順と例外 |
| 詳細なデータ設計 | 入力データと必要な出力 |
| 確定した開発スケジュール | 止められない時間帯と希望期限 |
| 1円単位の確定予算 | 予算の上限・下限、後回しにできる範囲 |
反対に、「使いにくいので何とかしたい」だけでは、相談を受けた会社も何を見に行けばよいか決められません。次の7項目は、社内で集めてから打ち合わせへ持っていきます。
発注前に決める7項目は、どう集めればよいか？
会議室で理想像を書くより、現場で一つの処理を追い、実物と判断者をそろえるほうが先です。
1. なくしたい作業
「受注業務を変えたい」ではなく、誰のどの動作をなくしたいかを書きます。「営業事務2人が、平日の16時から17時にFAX約30枚をExcelへ転記する」のように、担当、時間帯、回数が見える形です。
件数をすぐに出せない場合は、まず5営業日だけ数えれば構いません。月間の推計値を作るより、「月曜は40枚、金曜は15枚」と揺れが見える記録のほうが、処理能力を考える材料になります。
2. 現在の手順と例外
通常の流れだけでなく、担当者が手を止める場面を集めます。FAXを受け取る、得意先を特定する、商品コードへ読み替える、在庫を確認する、基幹へ登録する。その横に「品番が旧形式なら営業へ電話」「数量が箱と個で混在したら換算」と例外を足します。
例外を漏れなく列挙する必要はありません。直近1週間で担当者が誰かに確認した場面を拾えば、最初に検討すべき分岐が見えてきます。
3. 入力データと必要な出力
空の帳票ではなく、実際に記入されたFAX、PDF、Excel、メールを数件用意します。個人名、住所、取引価格などは伏せても、欄外の書き込み、複数ページ、空欄、表記揺れは残してください。そこが読み取りやデータ変換の難しさを決めます。
出力は「システムに登録する」だけでは足りません。誰が確認する一覧、基幹システムへ渡すCSV、取引先へ返す受注確認書など、処理後に必要なものを並べます。
4. 利用者と利用頻度
利用者の人数だけでなく、役割と頻度を分けます。毎日入力する5人、週1回承認する課長、月末だけ集計を見る経営者では、必要な画面も権限も異なります。繁忙日に同時に使う最大人数も確認してください。
社外の取引先や委託先が触る場合は、その人たちを利用者から外さないでください。アカウントの持たせ方と見せてよいデータの範囲が変わります。
5. 止められない時間帯
「24時間止められない」と広く置く前に、実際の締め時間を確認します。毎日15時までは出荷指示が必要、月末最終営業日の18時から請求を確定する、朝8時までに店舗へ在庫を配信する、と場面で書きます。
IPAの非機能要求グレードは、画面や機能とは別に、安定して使うための要求を受発注者で段階的に確認する考え方を示しています。止められない時間帯が分かると、切り替え、バックアップ、障害時の戻し方を相談できます。
6. 社内で決める人
現場の説明役と、最終判断者を分けて書きます。営業事務が手順を説明し、事業責任者が「自動登録するか、人の確認を残すか」を決める、といった形です。開発会社は業務の選択肢を示せますが、誤りをどこまで許容するかは社内で決めます。
判断者が打ち合わせへ毎回出られない場合は、決める期限と確認方法を決めます。「金曜までに部長がチャットで承認する」まで置くと、質問が宙に浮きません。
7. 予算・期限・後回しにできる範囲
希望額を隠して各社の反応を見るより、使える幅を伝えます。予算300万円以内なら対象を1部署に絞る、10月の繁忙期までに必要なら自動登録を後回しにして確認画面までにする、というように、金額と期限を削れる範囲につなげます。
期限には理由も付けます。「年度内」だけではなく、契約更新が11月、倉庫移転が1月、補助金の事業完了期限が3月、と背景が分かれば、変更できる日とできない日を分けられます。
画面や機能だけを先に決めると、何が抜けるのか？
データ移行、運用、総合テスト、停止時間が抜け、使い始める直前に追加作業として現れます。
要件は、ボタンや入力欄だけではありません。IPAの要件定義ガイドは、データ構造、業務プロセス、非機能要求に加えて、運用、移行、総合テストの要求も定義対象に挙げています。
たとえば受注画面が完成しても、旧システムの得意先コードと新しいコードが対応していなければ登録できません。月末に旧データを誰が締め、新旧の数字を誰が突き合わせ、差が出たらどちらへ戻すのか。ここまで決めて初めて、基幹システムを止めずに切り替える段取りが見えます。
初回相談でこれらをすべて決める必要はありません。7項目のどこが未確認かを明示し、調査や要件整理の期間を見積もりへ含めてもらいます。
初回相談で、見積もりはどこまで決まるのか？
最初は規模感を測る超概算です。要件と制約が固まるにつれ、概算、詳細見積もりへ進みます。
JUASの2025年度 システム開発・保守QCDs研究会成果物は、見積もりを超概算、概算、詳細の3段階に分けています。超概算は初期判断と予算枠、概算は予算確保と提案比較、詳細見積もりは契約と実行計画の基準に使う、という整理です。
同資料の確認シートでは、精度の目安を超概算でマイナス50%からプラス100%、概算でマイナス25%からプラス75%、詳細でマイナス5%からプラス15%としています。これは個別案件の金額を保証する数値ではなく、研究会が見積段階の違いを示すために置いた目安です。
初回相談で金額に幅があるのは、開発会社が答えを避けているからとは限りません。ただし、幅の根拠を説明しない会社には注意が必要です。見積書には、対象範囲、対象外、仮定した件数、連携先、調査後に再見積もりする条件を記載してもらいます。
7項目を、相談先にはどう渡せばよいか？
1冊の要件書にせず、1ページのメモと実物サンプル、未決事項の一覧に分けて渡せば十分です。
最初の連絡には、次の形で書けます。
FAX注文の転記を減らしたく、相談したいです。営業事務2人が平日30〜40枚を処理し、得意先品番を基幹の商品コードへ読み替えています。15時までの出荷分は止められません。帳票3社分を匿名化して共有できます。予算は300万〜500万円、10月までに確認画面を使い始めたいです。自動登録は第2段階へ回せます。業務判断は営業部長が行います。
この文章なら、相談先は帳票の種類、品番マスタ、基幹との接続方法、確認を残す場所から質問を始められます。分からない項目には「未確認」と書いてください。空欄を埋めるために推測すると、その推測が見積もりの前提として残ります。
開発を採用、準委任、受託、継続型の外部チームのどれに頼むか迷っている場合は、エンジニア採用・SES・受託開発の違いは？外部開発チームを含む4つを比較で、契約の対象と責任を比較できます。
7項目を自社だけで整理しきれない場合は、お問い合わせからご相談ください。FAXやPDF、現在の画面を見ながら、最初に調べる範囲と、社内で決める範囲を切り分けます。