基本情報技術者 2011年 秋期 午前(科目A) 問28
問題文
次のような注文データが入力されたとき、注文日が入力日以前の営業日かどうかを検査するために行うチェックはどれか。

選択肢
ア:シーケンスチェック
イ:重複チェック
ウ:フォーマットチェック
エ:論理チェック(正解)
注文日が入力日以前の営業日かどうかを検査するチェックはどれか【午前2 解説】
要点まとめ
- 結論: 注文日が入力日以前かつ営業日であるかを判定するのは業務ルールの整合性検査であり、論理チェックに該当します。
- 根拠: 日付の前後関係と営業日(カレンダー情報や休日判定)という複数の条件を組み合わせて判断するため、書式や重複の単純検査では対応できません。
- 差がつくポイント: 営業日判定(休日・祝日や土日考慮)と日付比較を正確に設計し、例外や境界(同日、季節休業など)をテストすることが重要です。
正解の理由
正解: エ
「注文日が入力日以前の営業日かどうか」を検査するには、単に文字列形式や一意性を確認するだけでなく、日付同士の前後関係と営業日かどうかという業務ルールを満たしているかを確認する必要があります。これらは業務上の意味(ビジネスルール)の整合性を検証する「論理チェック」に分類されます。論理チェックは複数フィールドや外部のカレンダー情報を参照して判定する点で他のチェックと異なります。
「注文日が入力日以前の営業日かどうか」を検査するには、単に文字列形式や一意性を確認するだけでなく、日付同士の前後関係と営業日かどうかという業務ルールを満たしているかを確認する必要があります。これらは業務上の意味(ビジネスルール)の整合性を検証する「論理チェック」に分類されます。論理チェックは複数フィールドや外部のカレンダー情報を参照して判定する点で他のチェックと異なります。
よくある誤解
- 「日付が正しい形式ならOK」としてフォーマットチェック(ウ)で済ませる誤り。形式が合っていても営業日や入力日以前かは別問題です。
- 「伝票番号や日付の重複チェック(イ)で検出できる」と考える誤り。重複チェックは同一データの存在確認であり、日付の前後関係や営業日判定は行いません。
- 「シーケンスチェック(ア)は日付順のチェックだ」と混同する誤り。シーケンスチェックは通常連番や時系列の順序(欠番や順序ズレ)を見ますが、営業日判定や入力日との比較までは含みません。
解法ステップ
- 要件の整理:判定対象は「注文日が(入力日以前の)営業日であること」。営業日は土日・祝日などを除く。
- 必要情報の列挙:注文日、入力日、営業日判定用カレンダー(祝日リスト等)。
- 前処理:日付文字列を日付型に変換し、パースエラーはフォーマットチェックで弾く。
- ロジック実装:注文日 <= 入力日 かつ 注文日が営業日であることを判定する。
- テスト設計:同日、前日、週末・祝日、未来日、カレンダー境界(年跨ぎ)などを網羅して検証する。
サンプル(簡易)実装例(Python):
from datetime import datetime, date
holidays = {date(2026,1,1), date(2026,1,2)} # 例:祝日リスト
def is_business_day(d: date) -> bool:
return d.weekday() < 5 and d not in holidays # 月=0 ... 日=6
order_date = datetime.strptime(order_date_str, "%Y%m%d").date()
input_date = datetime.strptime(input_date_str, "%Y%m%d").date()
if order_date <= input_date and is_business_day(order_date):
valid = True
else:
valid = False
選択肢別の誤答解説
- ア: シーケンスチェック
シーケンスチェックは連番や処理順序の整合性(欠番や順序ズレ)を調べるものであり、日付が営業日かや入力日以前かの判定は対象外です。 - イ: 重複チェック
重複チェックは同一キー(伝票番号など)の重複存在を検出する検査で、日付の前後関係や休日判定は行いません。 - ウ: フォーマットチェック
フォーマットチェックは文字列形式やデータ型が規定に合致しているかを確認するのみで、業務ルール(営業日かどうか/前後関係)は判定できません。 - エ: 論理チェック(正解)
複数の条件(注文日と入力日の比較、営業日判定)を組み合わせて業務上の整合性を確認するため、論理チェックが該当します。
補足コラム
論理チェックは業務ルールの集合体を正しく表現しているかを検証するもので、システムテストや受入テストでも重点的に確認されます。特に日付や金額、状態遷移など業務意図に関わる項目は、単体の技術的チェックだけでなく業務想定を踏まえたシナリオで検証することが品質向上に直結します。祝日や地域差、営業時間など外部要因をどう管理するかが実務上のポイントです。
FAQ
Q1: 営業日判定はどう扱えばよいですか?
A1: 標準的には祝日カレンダーと週末判定を組み合わせます。法定休日や会社独自の休業日は別途管理し、更新可能なカレンダーデータとして運用します。
A1: 標準的には祝日カレンダーと週末判定を組み合わせます。法定休日や会社独自の休業日は別途管理し、更新可能なカレンダーデータとして運用します。
Q2: 注文日が入力日と同日なら許容されますか?
A2: 問題文は「入力日以前」とあるため、同日は許容されます。要件に「以前(strictly before)」とある場合は除外になります。要件定義を確認してください。
A2: 問題文は「入力日以前」とあるため、同日は許容されます。要件に「以前(strictly before)」とある場合は除外になります。要件定義を確認してください。
Q3: フォーマットチェックは不要ですか?
A3: フォーマットチェックは前提条件として必須です。論理チェック実行前に日付パースが成功していることが前提となります。
A3: フォーマットチェックは前提条件として必須です。論理チェック実行前に日付パースが成功していることが前提となります。
関連キーワード: データ検査、入力検証、論理チェック、フォーマットチェック、重複チェック、シーケンスチェック、営業日判定、日付バリデーション、業務ルール、テスト設計

\ せっかくなら /
基本情報技術者を
クイズ形式で学習しませんか?
クイズ画面へ遷移する→
すぐに利用可能!

