取消の電話が来たのに、倉庫は出荷の準備中。開発の相談前に書き出す要件

たとえば、出荷指示を出した後に、取引先から取消の電話が入る。受注画面を「取消済み」に変えても、倉庫で箱を積み込んでいる人には伝わっていないかもしれません。開発相談では、通常の流れに加え、こうした例外で誰が判断するかまで伝えます。

工具卸の受注から出荷までを例に、相談用の要件メモを作ります（想定例）。目的と通常の流れから書き、出荷指示後の取消のように判断が分かれる箇所を加えると、必要な画面と担当者の動きが具体的になります。

完成した記入見本を先に見たい場合は、要件メモ兼RFPのPDFを開けます。分からない欄には、聞く相手と質問を残した見本です。

まず、受注から出荷までを対象にする

この会社の目的は、「注文がいまどこまで進んでいるか、事務所の誰でも答えられるようにする」ことです。まず、電話やメールで注文を受け付け、在庫を見て、受注を確定して出荷するまでを対象にします。請求と入金は、当面いまの会計ソフトで続けます。

目的は、最初に解決したい困りごとへ絞ります。「何を減らしたいか」「何を早く知りたいか」「誰の手間を減らしたいか」と聞くと、機能名より具体的に話せます。まだ対象業務を選べない場合は、システム化の相談前に使える業務棚卸し表で、仕事の流れと困りごとを並べるところから始めてください。

次に、入力・点検・承認をする人を分けます。この例では受注担当が注文を入力し、倉庫担当が在庫と出荷を見て、管理者が担当者の判断で進められない変更を決めます。値引きも扱うなら、誰がどこまで判断できるかを書き添えます。担当者によって答えが違う部分は、未決事項として残します。

ここでいう要件は、業務で実現したいことと、そのために必要な条件です。画面や通知の希望も材料になりますが、「誰が何を判断するために必要か」まで説明すると、開発会社と話し合う出発点ができます。

通常の処理を順番に書く

普段の仕事にも、作業の順番や担当ごとの違いがあります。受注担当と倉庫担当に、最近の注文を一つ思い出してもらい、受け取った情報、判断、次へ渡した情報をたどります。うまく進む場合の流れが見えると、例外がどこで起きるかも説明できます。

工具卸の例なら、次のように書きます。

1. 受注担当が、取引先・商品・数量・希望納期を受け付け、注文番号を付けます。
2. 倉庫担当が、既存の在庫台帳で数量を見て、結果と日時を注文に記録します。
3. 在庫を見た注文を受注担当が確定し、倉庫担当へ出荷指示を渡します。この例では、出荷指示を確定する時点を「締め」とします。
4. 倉庫担当が商品と数量を照合して出荷し、出荷日と出荷済みの状態を記録します。

初回は在庫台帳との自動連携を行わず、人が結果を記入します。そのため、画面上の情報が「在庫確認時点の記録」だと分かるようにします。常に最新の在庫数が自動表示されると受け取られる書き方は避けます。

図1　通常の流れと、途中で判断が必要になる場面。締めは出荷指示の確定を指します。

同じ注文番号で、受付内容、在庫確認、出荷を追えるように記入すると、必要なデータも見えてきます。いま使っている注文書、在庫台帳、出荷指示書を並べ、同じ意味なのに名前が違う項目や、何度も書き写している情報も確認します。

IPAの要件定義ガイド関連資料（PDF）では、業務フローやデータなどの成果物を、前後の工程や利用目的に合わせて選ぶ考え方が示されています。本記事の表は、その考え方を参考にした相談準備用の記入例です。

例外と初回の優先順位を決める

通常の流れに、欠品、訂正、取消、締め後の変更を重ねます。「例外に対応する」とだけ書かず、起きる場面、判断する人、戻る場所、残す記録を一組にすると、具体的な相談ができます。

この例では、欠品は受注を保留し、受注担当が納期や数量を取引先と相談します。内容が決まったら在庫確認へ戻ります。締め前の商品・数量の訂正も、理由と変更前後を残して在庫を確認し直します。

締め前の取消は、受注担当が理由を記録して注文を取消済みにし、出荷へ進めません。締め後に訂正や取消を頼まれた場合は、まず倉庫担当へ出荷停止を依頼します。返答がない間は、止まったかどうかは未確認です。取引先へも、取消が済んだとは案内できません。

倉庫で止められたと分かってから、管理者が対応を判断します。未出荷の訂正なら在庫確認へ、取消なら取消済みへ進めます。すでに出荷していた場合は返品の扱いを相談します。取消のボタン一つで処理を終えない、この順序を要件に含めます。

返品では、元の注文を残し、返品した商品と数量を別の記録で追う方針にします。この例の初回対象は受注から出荷までなので、返品受付と売上の調整は既存の手順で行い、注文に問い合わせ状況を残します。返品処理までシステムで完結させたい場合は、請求との関係を含めて対象範囲を見直します。

初回に必要なのは、出荷してよいかが分かり、変更を見落とさないことです。たとえば、欠品・訂正・取消の記録と出荷停止の連絡を初回対象にし、自動通知や集計帳票は後から検討できます。発生頻度が低くても、誤出荷や金額の食い違いにつながるものは、手作業で続ける場合の担当と手順を決めておきます。

「同意を記録する」を、変更後の条件まで書いてみる

要件を具体化する練習として、店頭預かり修理の操作例を開けます。「試す」を押すと、棚のラジオTG-1001が選ばれています。2026年11月1日に、見積り4,800円への同意を記録すると「修理開始待ち」になり、「修理」の画面へ進みます。そこで見積り金額を6,000円へ直して確定すると、「同意待ち」へ戻ることを確認しました。架空の修理を使った画面の見本です。

「見積りを編集できる」「同意を記録できる」という二つの機能名だけでは、変更後に前の同意を使ってよいかが決まりません。要件メモには、次のように前後の条件を書きます。

要件にすること	書き方の例
変更前	TG-1001は4,800円の修理内容へ同意済み。修理は未着手
変更操作	見積り額を6,000円へ変え、変更内容を確定する
変更後	新しい金額は同意待ちに戻る。変更前後と、どの内容へ同意したかを残す
再開する条件	新しい金額・修理内容への同意を確認してから作業へ進む

工具卸の取消にも、同じ書き方を使えます。「取消の電話を記録した」と「倉庫が出荷を止めた」を別にし、停止の返答を待つ間に許す操作、返答後に進める操作を決めます。画面の操作例で流れをつかんだ後、提案先には、実際に保存する見積り版や停止記録まで含めて再現してもらってください。

品質と完成条件を具体化する

同じ「注文を一覧で見たい」でも、使う人数や待てる時間によって必要な作り方が変わります。品質の希望は、実際に使う場面と一緒に書きます。

この例の希望条件は、事務所と倉庫から合計5人が同時に使い、保存した出荷状況が別の端末で5秒以内に見られることです。試すときの通信環境と扱う注文件数は未決にして、相談でそろえます。

停止についても、「止まらないこと」で済ませず、いつ、どれくらいなら待てるかを考えます。例では、営業時間外の計画停止は30分までを希望し、営業中に使えなくなったら紙へ控え、復旧後に注文番号で重複を確認して入力する案にします。障害時に復旧を待てる時間と、データをどこまで戻す必要があるかは未決です。事務所の管理者と倉庫責任者で確認します。

完成条件には、使えると判断するための試し方を書きます。たとえば、受注担当と倉庫担当が通常・欠品・訂正・取消・締め後変更の見本を一緒に操作し、注文番号、数量、状態が用意した確認用資料と一致するかを確かめます。最後に管理者が結果と残る課題を確認します。使いやすさを開発前に確かめたいなら、画面の試作を使った利用者テストも候補です（画面試作と利用者テストの進め方）。

要件メモを相談と提案依頼に使う

ここまでを一枚にまとめると、次のようになります。通常の流れと、倉庫への停止依頼、初回に含めない請求業務を同じ表で照合できます。

表1　工具卸の要件メモ（想定例）　数値は希望条件です。

項目	記入例
目的	注文がいまどこまで進んでいるか、事務所の誰でも答えられるようにする。
対象範囲	電話・メールでの注文受付から、在庫確認、受注確定、出荷状況の記録まで。
利用者	受注担当が入力・確定し、倉庫担当が在庫と出荷を見る。管理者が締め後の変更を判断する。
通常フロー	注文受付 → 在庫確認 → 受注確定 → 出荷。出荷指示の確定を締めとする。在庫は既存台帳を人が見る。
例外	欠品は保留して納期等を相談。締め前の訂正は在庫確認へ、取消は取消済みへ。締め後は出荷停止を依頼し、管理者が訂正・取消・返品相談を判断する。
データ	注文番号、取引先、商品、数量、希望納期、在庫確認結果・日時、出荷日、状態、変更前後と理由。元の注文は残す。
品質	希望条件の想定例：同時利用5人、保存後5秒以内に別端末で表示。営業時間外の計画停止は30分まで。試すときの通信環境・注文件数は未決。停止時は紙へ控え、復旧後に重複を照合して入力する。
対象外	請求・入金、在庫台帳との自動連携、返品受付・売上調整。返品は既存手順で対応し、注文に問い合わせ状況を残す。
未決	管理者と倉庫責任者に、試験用の注文件数・通信環境、障害時に待てる時間、データを戻す範囲を聞く。希望時期・予算は管理者に聞く。
確認者	受注担当と倉庫担当が業務の流れと動作を試し、管理者が結果と残る課題を判断する。
完成条件	通常・欠品・訂正・取消・締め後変更の見本を操作し、注文番号・数量・状態を照合用資料と照合する。品質条件も合意した環境で試す。

記入済みの例と空欄は、編集できる要件メモ兼RFP（Excel）と印刷して使う要件メモ兼RFP（PDF）から利用できます。

要件メモを、開発会社に提案を求める資料として渡すときは、希望時期、予算の考え方、用意できる資料、回答してほしいことを添えます。このような提案依頼をRFPと呼びます。

たとえば「初回は受注から出荷まで。請求と入金は会計ソフトを継続する。在庫の自動連携は今回含めない」と書いたうえで、「提案する範囲、進め方、期間、初期費用、継続費用、当社が準備することを回答してほしい」と依頼します。希望時期が決まっていれば、その理由も添えます。予算が未定なら、対象を分けた場合の費用を知りたいと伝えます。

比較する開発会社には、同じ版の要件メモを渡します。質問への回答で条件が変わったら、その変更も共有します。提案が届いたら、システム開発の相見積り｜条件をそろえる比較表を使い、含まれる作業と残る条件を確かめます。提案にある納期が、作る時間だけなのか、試す時間や移行まで含むのかも見比べます（システム開発の納期の決まり方）。

実際の契約では、作業範囲や双方が行うことを決めます。IPAの情報システム・モデル取引・契約書の公開案内は、その検討に使える参考資料です。相談用メモで決めたことも、提案や契約でどのように扱うかを開発会社と確かめてください。

利用後の改善を引き継ぐ

初回に含めなかった改善も、相談先と決める人を残します。この例では受注担当が要望を集め、管理者と倉庫担当が優先順位を決めます。変更する範囲と費用・期間への影響は、着手前に開発会社と確認します。

次の打ち合わせに持っていくもの

要件メモ、普段使う帳票、未決事項の質問をそろえれば、何から話すかが見えてきます。資料の実名や取引情報は必要に応じて伏せ、通常の流れと判断の違いが分かる見本を用意してください。

業務システム開発を相談する

参考出典

• IPAセミナー資料「事例3：要件定義ドキュメントの漏れや曖昧性の低減」（2019年2月26日）。第4章「要件定義成果物の品質向上」。PDF 6〜8ページの成果物の目的・関連性・選び方、16〜17ページの役割分担を参照。確認日：2026年9月15日。
• IPA「情報システム・モデル取引・契約書（第二版）」公開案内。公開：2020年12月22日、案内ページ更新：2026年9月11日、第二版資料更新：2025年4月8日。背景・概要・利用時の注意事項・更新履歴を参照。確認日：2026年9月15日。