架空の卸会社では、営業が注文N064の数量を受注表へ入力し、出荷担当が別の表へ写します。数量が変わった際に出荷表が古く、営業が確認の電話を受けます。経営者は「入力画面を作る」より、同じ注文の最新数量を出荷担当が見られることを目標にします。

今回の対象は、注文番号で検索し、営業が数量を登録・変更し、出荷担当が参照する仕事です。価格の自動決定、配送の自動予約、顧客への返信は含めません。関係する仕事のすべてを1度に作らず、何が変われば社内確認を減らせるかを担当と確かめます。

IPAの要件定義の解説は、業務上の要求を利用者と開発者で整理し、合意する考え方を示しています。本稿の注文と操作例は独自の架空教材です。担当の実際の仕事に置き換え、解く問題と対象外を先に説明できるようにしてください。

この章の根拠：出典1

N064の数量を10ケースから12ケースへ変更する例で考えます。入力は注文番号N064と数量12、操作は営業担当による保存、結果は受注記録に12ケースが残り、出荷担当が同じ12ケースを見られることです。画面が開くことだけを完成の条件にしません。

受入条件とは、納品候補が約束した仕事を満たしているか、発注者が確認する条件です。この例なら、変更前10ケース、変更後12ケース、変更した担当と時刻も履歴に残ることを加えます。数字だけでなく、どの注文に対する変更かを確かめます。

条件には確認方法と、結果の証拠を残す場所も書きます。営業が架空注文を変更し、出荷担当が別の利用者として参照し、双方の表示と履歴を確認する例です。IPAのガイド概要が示す、機能とデータの整合やテストの要求という観点をここへ具体化します。

この章の根拠：出典2

数量欄へ空欄や「多め」と入れたとき、何をしてほしいかを決めます。この架空例は1〜500の整数ケースを受け付ける条件です。空欄なら「数量を入力してください」、文字なら「ケース数を整数で入力してください」と表示し、元の保存済み数量を変えないことを確かめます。

業務によっては小数、0、返品の負数を扱います。この例の1〜500という条件をすべての会社へ当てはめません。営業と出荷担当が実際に使う単位と範囲を確認し、別の仕事で使う値を、誤入力と混同しないよう条件を分けます。

W3Cの入力検証の指針は、誤りを知らせ、入力形式の違いを扱う参考になります。画面上だけの確認で安全が確定するものではありません。開発会社には、保存する側でも条件を確認すること、修正後に同じ注文を保存できることを尋ね、確認方法を残します。

この章の根拠：出典3

この例では営業が数量を変更でき、出荷担当は参照できます。出荷担当の画面に変更ボタンを出さないだけでは、許可が守られた証拠にはなりません。開発会社は保存する側でも権限を確認し、出荷担当が変更を試みた場合に記録が変わらないことを説明します。

担当の役割が変わる場合には、誰が変更を申請し、誰が設定を確認するかを残します。共有の利用者名を全員で使うと、誰が数量を直したか履歴で追いにくくなります。必要な利用者と操作範囲を、自社の管理者が実際の仕事に合わせて決めてください。

受入条件には、役割の異なる利用者で試す手順を含めます。架空注文N064を使い、営業の変更が反映されること、出荷担当の変更は受け付けないことを確認します。本物の顧客へ送信する操作や、実データを削除する試験を教材の前提にしません。

当初は数量だけを変える条件でも、後から納期変更が必要になる場合があります。追加の操作を受入条件へ黙って混ぜず、要求、費用や日程への影響、今回採用するかを整理します。経営者と開発会社が合意した条件を版として残します。

確認中の候補と採用した条件を分け、納品時には同じ版の入力例を使います。「打合せで話したはず」と言うだけでは、どこまで今回の範囲か分かりません。条件の一覧へ担当、確認日、未解決の質問を書けば、変更した理由も次の人へ渡せます。

納品候補が条件を満たさない場合は、実際の結果と期待結果の違いを記録します。重要な不足を残したまま「だいたい便利」と評価せず、修正・再確認・対象範囲の見直しを担当と決めます。受入条件への合致は業務導入の判断材料であり、売上成果の保証ではありません。

要件定義は、機能名を多く並べるだけでは終わりません。N064の架空例では、営業の数量変更が同じ注文へ保存され、出荷担当が参照できることを受入条件にしました。空欄や役割違いでも期待結果を決めると、発注者と開発者が同じ場面を確かめられます。

自社へ置き換えるときは、実際の単位、数量の範囲、操作する役割、履歴の必要性を確認してください。条件が変わる場合には版と合意を更新します。入力例と期待結果を残しておけば、納品候補で不足が出たときも、何を直して再確認するか説明できます。

次に、営業と出荷担当へ困る注文1件を依頼し、下のメモへ入力・結果・例外を書いてください。開発会社には、その例をどの方法で試すか尋ねます。役割や保存結果の不明点を解消してから、今回作る範囲と完成条件を合意しましょう。