試作の目的と、確認する範囲

このレッスンの到達目標

短い対話で試しながら、確かめたい仮説に集中する。

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

BUSINESS STATE MACHINE · AUDIO & INTERACTIVE

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

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

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

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

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

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

試作は、操作、項目、業務フロー、利用者の理解を確かめるために使えます。たとえば値引きの入力単位を取引先別にするか、受注明細別にするかを試します。確認したい点を先に決めます。

架空データと検証環境を使い、完成品と誤解されないようにします。利用者の感想を集め、要望、問題、未確認の業務ルールへ整理します。

画面が表示されても、保存、権限、同時実行、監査、性能、復旧まで確認したとは限りません。実装済み、仮実装、未実装、未検証を区別します。

試作中の変更は小さく保ち、何を試したかと結果を記録します。顧客が望む操作でも、業務上の制約に反するならそのまま採用せず確認します。

試作の前に、確認したい仮説を二つ程度に絞ります。操作回数を減らせるか、必要な項目が足りているかなど、利用者が判断できる問いにして試してください。

感想と確定事項を分けて記録します。「便利そう」という反応だけで仕様を確定せず、実際の作業例や例外で使えるかを確認します。

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