# 後編 模擬プロジェクト：販売管理の値引き改修

この資料の会社・取引・コード・ログは架空です。既存の顧客システムへ適用しないでください。コード抜粋には演習用の不足・矛盾があり、正解の実装ではありません。実装する場合は手元の検証環境と架空データを使います。

## 1. 最初の依頼と体制

営業から「優良取引先へ10%値引きしたい。過去分も含め、来月から使いたい」と依頼された。
実装担当2人、技術担当1人、業務SEは週2日、PM1人。経理責任者が締め・請求訂正を決定する。運用担当と会計連携先への確認が必要。

最初の依頼は正式な確定要件ではない。対象・適用日・計算・例外を確認し、未確定の範囲を記録する。

## 2. 現行資料の抜粋と矛盾

| 情報源 | 記述 | 確認が必要な点 |
| --- | --- | --- |
| 旧基本設計v1 | 金額は四捨五入する | どの金額をどの時点で丸めるか不明 |
| 受注画面コード | 値引き額を切り捨てる | 対象取引先の判定がない |
| 夜間バッチ | 全取引先を10%値引きする | 画面と異なる。現行の正しさは未確認 |
| 営業の説明 | 優良区分が変われば過去分も変えたい | 請求・締めとの整合が未合意 |
| 経理の説明 | 締め済み伝票は直接変更しない | 訂正伝票の承認・連携方法を確認する |
| 運用メモ | 失敗時は翌朝再実行する | 部分成功・二重実行の扱いが不明 |

調査では根拠の版・箇所、事実、推測、未確認を区別する。コード検索だけでなくジョブ設定・運用手順・担当者へ確認する。

## 3. 調査用のデータモデル（抜粋）

```text
customer(id, preferred)
orders(id, customer_id, status, closing_date, total_amount, version)
order_lines(id, order_id, unit_price, quantity, discount_amount, net_amount)
accounting_delivery(delivery_id, order_id, status, attempted_at)
```

受注時点の優良区分、計算ルール版、訂正履歴、送信結果の管理などは未設計。必要性と構造を要件から判断する。

## 4. 調査用のコード（不足を含む）

```ts
// 画面側：取引先判定・入力条件・保存整合は省略されている。
function screenNet(unitPrice: number, quantity: number) {
  const gross = unitPrice * quantity;
  return gross - Math.floor(gross * 0.10);
}

// バッチ側：丸め方と適用条件が画面側と違う。
function batchNet(gross: number) {
  return Math.round(gross * 0.90);
}

// 保存処理：途中失敗と競合の扱いが不明。
await updateLines(orderId, changedLines);
await updateHeader(orderId, total);
await sendAccounting(orderId);
```

これは採用すべき設計ではない。計算順序・対象・更新のまとまり・同時更新・再実行・外部送信を調査し、必要な制御と確認を提案する。

## 5. 演習用の合意条件 v2

以下は演習のために業務責任者が確定したと仮定する条件。実案件の一般ルールではない。

- 初回の対象は新規・未締めの受注。過去分・締め済み分は対象外。
- 優良区分と適用した計算ルールを受注時点で確定し、後のマスター変更では無断で再計算しない。
- 明細金額は単価×数量、値引き額は明細金額の10%。値引き額の小数は切り捨てる。
- 税はこの演習の計算対象外。実案件では税と端数処理を別に確認する。
- 対象外の取引先は値引きしない。受注合計は明細の差引額合計と一致する。
- 締め済み請求を直接変更しない。訂正の方式は追加の業務確認が必要。
- 権限のない利用者は更新できない。変更者・時点・理由を記録する。
- 途中失敗・同時更新・再送で不整合や二重登録を起こさない方針を設計し、検証する。
- 性能演習の仮条件は夜間100万件を30分以内。環境、偏り、併走処理、測定方法は別に定める。

### 独立した計算例

| 入力 | 値引き額 | 差引額 |
| --- | ---: | ---: |
| 優良、1,001円×3 | 300円 | 2,703円 |
| 優良、99円×1 | 9円 | 90円 |
| 非対象、1,001円×3 | 0円 | 3,003円 |
| 優良、0円×1 | 0円 | 0円 |

負数、桁数、未入力、上限、取消等の扱いが不足している。確認事項と受入条件を追加する。

## 6. 技術選定・PoC

候補A：現行フレームワーク・DB・ジョブ基盤を継続し、計算と再送を改善。
候補B：新しいジョブ・連携基盤を導入する。再開・監視の機能はあるが、対応版・契約・運用体制は未確認。

新規導入を必須としない。必須条件と比較項目を分け、公式資料の版・確認日、技術検証、運用・教育・保守費を記録する。100件の試作成功だけで本番性能を保証しない。

## 7. 連携の障害ログ（架空）

```text
09:00:00 delivery=D100 order=O100 DB_COMMIT_OK
09:00:01 delivery=D100 SEND_START
09:00:31 delivery=D100 RESPONSE_TIMEOUT
09:01:00 delivery=D101 order=O100 RETRY_WITH_NEW_ID
09:01:01 delivery=D101 ACCOUNTING_ACCEPTED
```

初回D100も相手先が処理済みの可能性がある。送信記録と相手先の結果を照会・照合する方法を確認する。タイムアウトを未処理と断定せず、同じ連携識別子での再送、重複判定、部分成功、承認された訂正を検討する。

## 8. 変更・障害の追加課題

1. 業務責任者から値引き額の端数を切り上げる変更 v3 が来た。適用日と既存未締め取引への適用は未確定。
2. 連携応答不明の状態で再送され、二重請求が疑われる。
3. レビュー担当者が途中交代。引き継ぎ先にAIチャットの履歴はない。

v3で3,003円の値引きは301円、差引額は2,702円。5,005円の値引きは501円、差引額は4,504円。変更の合意と期待値更新を対応させる。

## 9. 移行・リリース・運用

新項目への変換規則、件数・金額・状態の照合、バックアップ、権限、途中失敗、再実行を計画する。旧コードと新データの互換性、外部送信済み取引の扱いも確認する。

リリース可否・中止条件・判断者を定める。監視にはジョブ稼働だけでなく対象・完了・失敗・保留・連携滞留を含める。運用者が検証環境で手順を試し、確認・連絡・承認・照合ができるか確かめる。

## 10. 役割別の提出範囲

| 役割 | 主な成果物 |
| --- | --- |
| 実装担当 | タスク依頼、実装差分、独立した期待値、実行結果、レビュー対応 |
| 技術担当 | 技術選定・PoC、データ・連携・競合・回復設計、統合検証 |
| 業務・SE担当 | ルール・例外・質問・合意、受入条件、訂正・照合、業務再開 |
| リーダー・PM | 配置・支援、進行条件、品質・変更・障害・リリース判断、全体効果 |

全員に全役割の自立遂行を求めない。他者に確認することと支援条件を示す。

## 11. 引き継ぎと効果測定

参照版、合意、判断理由、実施結果、未解決事項、起動・復旧・運用手順を渡し、別担当者に条件変更の影響を調べてもらう。

比較例（架空）：従来は調査2＋実装6＋レビュー2＋テスト4＝14時間。AI試行は調査・指示3＋実装2＋レビュー5＋テスト・手戻り6＝16時間。

生成時間だけでなく全体の工数・待ち・品質と案件条件を比べ、負担の移動を調べる。次の適用範囲と教育・支援を提案する。

## 12. 提出上の注意

計画と実施済み、期待値と実測、成功・失敗・未実施を区別する。実装していなければ計画として記録する。AI利用の履歴と本人の修正理由、第三者の指摘と再確認を残す。自己申告や選択問題だけで実務能力を認定しない。