試作を、要件と設計へ変換する

このレッスンの到達目標

使う・一部使う・作り直すを根拠付きで選ぶ。

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

BUSINESS STATE MACHINE · AUDIO & INTERACTIVE

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

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

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

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

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

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

試作で得た結果を、利用者、操作、入力、業務ルール、例外、受入条件に整理します。誰が確認し、何が保留かも記録します。AIの会話履歴をそのまま要件書とは扱いません。

画面の裏側で必要なデータ更新、連携、履歴、運用を設計につなげます。試作時に省略した項目を、後続作業から落とさないようにします。

既存構成、依存関係、規約、テスト、保守性を確認します。継続利用、一部利用、作り直しの候補を比較し、費用とリスクを説明します。

「せっかく作ったから」も「AIが作ったから全部捨てる」も採用理由にはしません。別の担当者が理解・検証・変更できる状態にできるかを確認します。

試作から正式開発へ渡す際は、確認した画面操作、決まった業務条件、未確認の非機能要件を分けて整理します。試作で使った仮の認証や保存方法も明示してください。

継続利用を選ぶ場合は、整理・テスト・標準適合に必要な作業を見積もります。作り直す案との比較を残すことで、後の担当者も判断理由を理解できます。

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