数量上限を100個から200個に変えるとき、何を確認する？画面・取込・保存先の調べ方

注文できる数量を、1回100個までから200個までに増やしたい。画面の数字を変えれば終わるように見えますが、注文の受け取り方は画面だけとは限りません。

たとえば150個を画面に入力できても、注文を保存する入口やCSVを取り込む仕組みが100個までのままなら、保存できない条件が残ることがあります。外部倉庫の受け入れ上限が分からなければ、先方も200個に対応できるとは決められません。

この記事では、数量を1〜100個から1〜200個に変える架空の部品卸を例に、画面・取込・保存・案内・外部先をどうたどるかを説明します。受注担当とシステムの発注窓口を兼ねる方が、開発会社に確認してもらう場所と、資料が足りずに保留する場所を分けるための内容です。この例は変更前の調査であり、実装や試験が完了した話ではありません。

最初に何を変える？数量の上限と、変えない条件を分ける

まず、変更する約束を一文で書きます。この例では、1注文の数量上限を100個から200個にすることに、責任者と開発会社が合意しています。

PC用図を原寸で開く / スマートフォン用図を原寸で開く

図：架空の数量条件。上限を変える案で、修正や試験はまだ行っていません。

表の各行で条件を比べます。

変えるのは上限です。下限や単位、既存の注文との対応まで変えると決めたわけではありません。ここでの数量や会社はすべて架空です。実際の仕事では、変更前の仕様書や設定資料の名前・版・確認箇所を残します。

変更内容が決まっていない場合は、先に開発会社と合意します。変更案に合意したことと、実装して確かめたことは別です。

画面だけで大丈夫？注文の入口から保存先までたどる

画面の数量入力を確認したら、その入力がどこへ渡るかをたどります。ここでいうAPIは、画面などから注文を受け取る保存の入口です。画面で200個まで入力できても、保存の入口が100個までのままなら、150個を保存できない条件が残ります。

CSVも別の入口です。CSVは表のデータをファイルにした形式です。この架空例では列の順番や意味を変えませんが、取り込むときの数量チェックが100個までなら、変更案と食い違います。画面・CSV取込・保存側をそれぞれ確認しましょう。

PC用図を原寸で開く / スマートフォン用図を原寸で開く

図：架空例で、同じ数量条件を使う資料をたどります。

PC用図を原寸で開く / スマートフォン用図を原寸で開く

図：画面と保存入口の条件が異なると、150個の注文を保存できない例。実際のシステムの結果ではありません。

数字の「100」を検索することは手掛かりになります。ただし、見つかった100が注文数量の上限とは限りません。反対に、検索で見つからなかっただけで条件が存在しないとも言えません。設定や別の入力経路、古い資料、外部先の仕様も確認します。

9箇所をどう分ける？変更候補・不要・未確認の例

次の表は、架空資料を読んで判断した例です。「変更候補」は、資料の条件と変更案が食い違うため、修正対象として確認する候補を意味します。修正が終わったことを示す言葉ではありません。

この例では変更候補6箇所、根拠上は不要2箇所、未確認1箇所です。実際に調べる場所が9箇所で足りるとは限りません。

PC用図を原寸で開く / スマートフォン用図を原寸で開く

図：9箇所の判断は、架空資料をもとにした調査結果の例です。

外部倉庫に数量を送る場合は、連携窓口から「1注文あたり200個を受け取れるか」「どの資料や版で確認できるか」「確認できる時期と担当は誰か」を尋ねます。返答がまだなければ、対応できるとも変更が必要とも決めず「未確認」とします。回答を得てから、必要な変更と双方で試す範囲を決めましょう。

保存済みの正常な数量も、新しい上限に合わせて200へ書き換える必要はありません。ただし、別の用途で数量を使っていないか、異常な値がないかは確認が必要です。

案内文と試験の期待結果はどう変わる？

入力後の案内が「1〜100の整数個で入力」のままなら、新しい条件と一致しません。画面だけでなく、CSV取込のエラーでも同じ文言を使っていないか確認します。

PC用図を原寸で開く / スマートフォン用図を原寸で開く

数量以外の入力条件がそろっている前提では、期待する数量判定は次のように変わります。

表の各行で条件を比べます。

この表は数量条件から考えた期待結果の案です。実際に試した結果や、納品の合否ではありません。資料に「変更が必要」と書いた時点では、修正も試験も終わっていません。調査、修正、変更後の確認を分けて残すと、進み具合を関係者が同じ言葉で把握できます。

開発会社に何を渡す？根拠と未確認を一緒に伝える

まずは、画面の数量入力と保存の入口の2箇所から始めます。それぞれについて、資料名と版、現在の条件、変更案、判断とその理由、確認する担当を並べます。読めない資料や、相手が分からない箇所も、無理に埋めず「未確認」とします。

PC用図を原寸で開く / スマートフォン用図を原寸で開く

図：開発会社へ伝える架空例。外部倉庫の上限は未確認で、修正や試験はまだ行っていません。

現場だけで修正範囲を決める必要はありません。画面のほかにCSVなどの入口があるか、外部倉庫への連携はどう扱うかを開発会社と確認し、変更後にどこまで試すかを決めます。費用・期間・実際に対応する担当は、調査の結果に応じて個別に確認します。

変更後の受入判断は、発注者の受入テスト確認表も参考にしてください。入力・連携・担当の整理で迷う場合は、相談窓口へ変更前後の条件と未確認の資料を用意して相談できます。支援の範囲と進め方は個別に確認します。

まとめ：変える上限を、別の入口と保存先まで追う

画面で150個を入力できても、保存の入口が100個までなら、注文を保存できない条件が残ります。画面からCSV取込、保存先、案内文、外部倉庫へと、同じ数量条件を使う場所を一つずつたどりましょう。

PC用図を原寸で開く / スマートフォン用図を原寸で開く

図：架空例です。修正と試験は未実施です。

資料の根拠がある箇所は変更候補と不要を分け、分からない箇所は未確認のまま担当につなぎます。最初の一歩は、画面の条件と保存の入口の条件を、同じ変更前後の値で比べることです。

参考資料

参考資料は、変更の影響を調べるときの考え方を知るために使います。自社の数量上限や、変更後にどの入力が保存されたかは、対象システムの仕様書・設定・試験の記録で別に確認してください。資料や試験結果がまだなければ「未確認」として、開発会社へ尋ねます。

図：一般的な参考資料と、自社の仕様・試験の記録は役割が異なります。

• IPA「変更管理」§3.4：変更の記録・評価・関係者による判断、承認後の開発と試験の考え方。本文の数値と分類は架空例。
• ISTQB テスト基礎シラバス v4.0.1 §1.4.4・§2.2.3・§2.3：仕様と試験の対応、変更影響の把握、変更後の確認に関連する考え方。数量、資料、分類は架空例。