曖昧さを、答えられる質問にする

このレッスンの到達目標

未確認事項を、確認相手と判断につながる形にする。

音声とインタラクティブ図解で学ぶ音声を再生すると、下のインタラクティブ図解と本文の段落ハイライトが連動して動きます。

BUSINESS STATE MACHINE · AUDIO & INTERACTIVE

販売管理の取引状態マシンと「締め後・例外」の境界シミュレーター

受注→出荷→売上→請求締め→入金の流れで、いつ・どのデータ（受注日／計上日／締め日）が確定し、どこから直接変更が禁止されるかを動かして確かめます。

状態・日付・数量の変化受注確定（受注日 10/12 ／受注 3個）

取引先の優良区分は受注時点のマスターを採用するか、請求時に再評価するかを合意して保持します。

直接変更の可否と監査履歴元伝票の直接変更：条件付き可（出荷前）

試作画面で金額を書き換えられても、業務システムでは「受注日・売上計上日・締め日」と「変更履歴・承認権限」を分けて設計します。

「値引きはどうしますか」だけでは答えにくい質問です。対象、困っている点、案ごとの影響、確認したい事項を示します。選択肢を挙げても、その中に必ず正解があるとは扱いません。

たとえば「締め済み分を再計算する場合、発行済み請求との差額処理が必要です。対象外にするか、訂正伝票を作るか、別の運用があるかを確認したい」と整理します。

回答者に決定権があるかを確認し、回答日、適用範囲、根拠、保留事項を記録します。部門で回答が違えば、開発担当者が勝手に片方を採用せず、責任者の判断を求めます。

合意した内容は、要件と受入条件へ反映します。顧客との会話やAIのチャット履歴だけに残さず、チームが参照できる場所に整理します。

質問は「確認した事実」「わからない点」「判断が必要な理由」「候補と影響」に分けると整理できます。顧客が技術的な実現方法を答えなくても、業務上の目的と制約を確認できる形にします。

回答を受けたら具体的な取引例で認識を合わせます。たとえば締め日の前後や返品を含む例を提示し、例外も同じルールで扱えるかを確かめます。

読了記録と習熟度の確認は別です。