導入・受入の準備学習記事全11節Operate
残課題・受入結果・復旧手段を並べ、今の事実で下せる利用開始判定を記録する
この記事で身につくこと未解決問題、利用範囲、責任者、復旧手段、承認条件を照合して判断する意味と、「演習成功」「限定試行」「実業務導入」を分ける理由を説明できる。
記事内目次（17項目）
この記事の会社・人物・データはすべて架空の設定です。実在する会社や案件とは関係ありません。この記事の判定は、これまでの記事（09-04、10-01〜10-03）の結果をもとにClaude Codeが行った例であり、実際の業務担当者・責任者による承認ではありません（第8.1節）。判定は、確認できていない事実を確認済みとみなさずに下します。
この記事は何の話か。これまでの記事で積み上げてきた残課題一覧（09-04）、受入結果（10-01）、移行結果（10-02）、利用手順書（10-03）を並べ、「演習成功」「限定試行」「実業務導入」のどこまで進めてよいかを、今ある事実だけから判定して利用開始判定記録にまとめる話です。
なぜ必要か。個々の確認（テスト、レビュー、受入確認）に合格しても、それだけでは「今すぐ全社で使い始めてよい」ことにはなりません。逆に、確認できていないことがあるのに「試しに使ってみる」と決めてしまうと、実際の依頼データを未確認のアプリに載せることになります。残る問題と未確認の範囲を踏まえて、どこまで進めてよいかをまとまった形で判断する必要があります。
この記事を読むとできるようになること。
- 未解決問題、利用範囲、責任者、復旧手段、承認条件を照合して判断する意味を説明できる
- 「演習成功」「限定試行」「実業務導入」を分ける理由を説明できる
- 残る問題を受け入れて開始する条件と、開始を延期する条件を、失敗の影響と業務上の必要性から比較して判断できる
- 「未確認のまま開始する」判定にならないよう、入力の事実と判定区分を一致させられる
読む順路。この記事は3つの深さで読めます。全部を順に読む必要はありません。
- 基本だけ理解する：第1節→第3節（3つの判定区分と、未確認を判定材料にする理由）→第4節（判断すること）→第6節の利用開始判定記録→第9節。ここまでで、判定区分「演習成功」と、限定試行へ進む条件①〜④が分かります。
- 作って確かめる：上に加えて第5.1節（これまでの確認結果の一覧）→第5.2節（未解決問題と受容／延期）→第7節（判定が入力の事実と矛盾していないことの照合）。
- 設計判断を深める：上に加えて第8節（この判定が実際の承認ではない理由と初版を改めた理由、受容と延期の条件）。
1. 今回の業務課題と完成するもの
この記事でやることは、09-04の残課題一覧、10-01の受入結果、10-02の移行結果、10-03の利用手順書を並べ、それらの事実から下せる判定区分と、次の区分へ進むための条件を決めた利用開始判定記録を作ることです。
10-01〜10-03では個別の確認・準備を行いましたが、それらを総合して「今、どこまで使い始めてよいか」を判断する作業はまだ行っていませんでした。この記事では、それを行います。
この記事を読み終えると、次のものが手元にできます。
- 利用開始判定記録（判定区分、利用範囲、未解決問題と扱い、責任者、復旧手段、承認条件、判定日）
2. 前提知識と読む順路
この記事で使う言葉を先に説明します。
判定区分
一言でいうと、どの段階まで使い始めるかの区分です。この記事では「演習成功（確認は済んだが実際には使わない）」「限定試行（一部門など限られた範囲で試しに使う）」「実業務導入（全社的に本格的に使う）」の3区分を扱います。
未解決問題の受容／延期
一言でいうと、残っている問題について、「この問題があっても開始する（受容）」か「解決するまで開始を待つ（延期）」かを、問題ごとに決めることです。
これがないと、個々の確認には合格していても、残る問題の大きさに見合わない範囲で利用を始めてしまう可能性があります。
読む順路：レビュー記録は09-04、受入確認は10-01、移行計画は10-02、利用手順書は10-03、復旧方針は05-04が該当します。この記事の判定記録は、11-01（公開先と設定を確認する）の前提になります。
3. 理解する：判定区分を分ける理由
3.1 「演習成功」「限定試行」「実業務導入」
| 判定区分 | 内容 | この記事での位置づけ |
|---|---|---|
| 演習成功 | 確認・準備は済んだ範囲を架空データで確かめた。実際の業務では使わない（教材演習として完結） | これまでの09〜10系の記事はこの段階に相当する。この記事の判定もここ（第6節） |
| 限定試行 | 一部門など、限られた範囲・期間で、実際の依頼を使って試す | 実際に動く画面があり、受入確認で観測した結果があって初めて進める段階 |
| 実業務導入 | 全社的に、本格的に業務で使う | 限定試行で問題がないことを確認してから進む段階 |
3.2 よくある誤解
「テスト・レビュー・受入確認に合格したら、そのまま全社導入してよい」。09-04の残課題（実装者以外の人による確認が未実施であることなど）を踏まえると、いきなり全社導入するのはリスクが大きいと考えられます（第6節・第8.1節）。
「限定試行は小さく試すだけだから、確認が足りなくても始めてよい」。限定試行でも、実際の依頼データを載せて実際の利用者が操作します。画面が無い、受入確認で観測した結果が無い、という状態で始めると、「試す」のではなく「未確認のものを業務に使う」ことになります。確認できていない事実は、判定区分を下げる材料です（第5.2節・第6節）。
「未解決問題が1つでもあれば、利用開始できない」。問題の影響の大きさによっては、問題を受け入れたうえで限定的に開始し、並行して対応することも選択肢です（第8.2節）。
4. 判断すること
利用開始判定で人が判断することは、次の5つです。
| 判断すること | なぜ判断が必要か | 仮置きしてよいか | 間違えた場合の影響 |
|---|---|---|---|
| どの判定区分（演習成功／限定試行／実業務導入）にするか | 個々の確認の合格と、実際の依頼を載せてよいかは別。判定区分は「確認できた事実から下せる上限」で止める（第3.1節・第6節） | 不可。事実より上の区分にしない | 未確認のアプリに実際の依頼データが載る |
| 判定区分が第5.1節・第5.2節の事実と矛盾していないか | 「画面が無い」「受入確認済み0件」という事実がありながら「限定試行」にした初版は矛盾していた（第8.1節） | 不可 | 判定記録が事実を隠す文書になる |
| 未解決問題ごとに受容するか延期するか | 影響の大きさ・検知できるか・観測した結果があるかで分かれる（第8.2節）。観測していないことは受容の対象にしない | 可（受容した問題は、次の区分へ進む前に扱いを見直す） | 観測していない問題を「受容」で通し、限定試行で初めて顕在化する |
| 次の区分へ進む条件を何にするか | 足りない確認を「判定区分を上げる条件」として書く（第6節の①〜④）。書かないと、いつ進めるかが決まらない | 可（条件が満たされたら改めて判定する） | 延期が無期限になる、または条件なしで進む |
| 責任者・承認条件は誰か | この記事の判定はClaude Codeによる材料整理で、実際の承認ではない。責任者（運用管理者、架空）と承認者（総務課長、架空）を明記する | 可（架空の体制で仮置き） | 材料整理が承認として扱われる |
勝手に決めてはいけないこと：
- 実際の業務担当者・責任者が承認したかのように書きません。この記事の判定はClaude Codeによる例です（第8.1節）。
- 09-04で見つかった未解決問題を、この記事で勝手に「解決済み」に変更しません。
- 10-01で「未確認」とされた受入条件を、確認済みとみなして判定しません。
AIに任せる範囲：これまでの確認結果の一覧化、未解決問題の出所の整理、判定記録の下書きはAIに任せられます。任せてはいけないのは、判定区分の決定、受容／延期の判断、次の区分へ進む条件の決定、そして承認です。
5. 作って確かめる：判定材料を並べる
5.1 これまでの確認結果の一覧
| 工程 | 結果 |
|---|---|
| 09-02（記事B） | 5系統以上の検証に合格（コードの動きとしては確認済み。架空データ） |
| 09-03 | 権限・重複・途中失敗・同時更新の4系統を確認。本格的な同時アクセス・負荷は未検証 |
| 09-04 | 08-04の差分をレビュー。指摘4件は対応不要、1件（状態のロールバック）は未対応の残課題。レビューは実装者と同じAIによるもの |
| 10-01 | AC-005・006・007・009・011の5件のうち、受入確認済み（合格）は0件。AC-005は作成時の必須項目チェックだけを演習で確認（判定保留）、残り4件は観測する対象が無く未確認。提出時の必須項目チェックが無い件が見つかった |
| 10-02 | 架空データ5件のうち3件を移行、2件は日付不正・文字化けのため移行しない扱い |
| 10-03 | 3役割の利用手順書・問い合わせ手順を作成済み（実際の利用者への説明は未実施） |
| 実装の範囲（08系） | 承認可否の判定、保存処理、提出の連携（固定値の本人確認）まで。画面、差戻し・再提出、一覧・閲覧・編集は未実装 |
5.2 未解決問題と扱い（受容／延期）
| 未解決問題 | 出所 | 扱い | 理由 |
|---|---|---|---|
| 実際に動く画面が無く、受入確認で観測した結果が無い（合格0件・未確認4件） | 10-01 | 延期（画面完成後に10-01と同じ手順で再確認） | 観測していないものを確認済みとはみなせない。限定試行に進む前提が整っていない |
| 提出時の必須項目チェックが実装に無い（AC-005の一部） | 10-01 | 延期（08-02へ戻して修正） | REQ-004に関わる。修正前に実際の依頼を載せない |
| 実装者以外の人による確認が行われていない | 09-04、10-01 | 延期（画面完成後、業務担当者による受入確認とあわせて行う） | 同じAIによる確認は独立した保証にならない。限定試行の中で並行して行う案は、確認できていないものを実際の業務に載せることになるため採らない |
| 履歴書き込み失敗時のロールバック設計の是非 | 09-04 | 受容（演習の範囲では） | 発生頻度が低く、失敗ログで検知できる。ただし限定試行へ進む前に扱いを決める（12-02） |
| 本格的な同時アクセス・負荷が未検証 | 09-03 | 延期（実業務導入前に確認） | 限定試行の利用規模では影響が小さいが、全社導入前には確認が必要 |
6. 実行結果（利用開始判定記録）
| 項目 | 内容 |
|---|---|
| 判定区分 | 演習成功（実際の業務では使わない） |
| 判定の根拠 | 承認可否の判定・保存・提出の連携は架空データで確認済み（09-02、09-03、08-03）。一方、画面が無く、受入確認で観測した結果が0件（10-01）。実際の依頼を載せる限定試行に進む前提が整っていない |
| 利用範囲 | 配置サンドボックス内での演習のみ（11-02・11-03）。実際の依頼データは載せない |
| 限定試行へ進む条件 | ①画面（提出・承認・差戻し・一覧）が実装・配置されていること、②10-01と同じ手順で業務担当者役（実装者以外）が受入確認を行い、AC-005〜011に観測した結果があること、③提出時の必須項目チェック（10-01の見つかった事項）が修正されていること、④総務課長（架空）の承認 |
| 未解決問題と扱い | 第5.2節の表のとおり（延期4件、受容1件） |
| 責任者 | 運用管理者（架空の仮定、03-01と同じ想定） |
| 復旧手段 | 05-04の復旧方針（架空の仮定）、12-03・12-04のバックアップ・復元手順（記事Cの範囲。この題材アプリではREQ-008の実装・確認は対象外） |
| 承認条件 | 限定試行へ進む条件①〜③が満たされたうえで、総務課長（架空）の承認を得ること |
| 判定日 | 2026-09-20（この記事の作成日。実際の承認日ではない） |
7. 確認結果
実行環境：本節は文書によるまとめであり、コードの実行は伴いません。作成日：2026-09-20。
完了条件との照合：
| 完了条件 | 確認結果 |
|---|---|
| 判定区分（演習／限定試行／実業務）が明記されている | 第6節に記載（演習成功。限定試行は延期条件付き） |
| 責任者と承認条件が書かれている | 第6節に記載 |
| 未解決問題ごとに受容／延期の扱いがある | 第5.2節・第6節に記載 |
| 判定区分が入力の事実と矛盾していない | 受入確認済みが0件・画面未実装という事実に対し、実際の依頼を載せる区分（限定試行）を選んでいない |
残る制限：この判定はClaude Codeが例として作成したものであり、実際の業務担当者・責任者による承認ではありません。判定区分「演習成功」は、この記事の時点の事実から下せる上限であり、限定試行へ進めるかどうかは第6節の条件が満たされてから改めて判定します。この記事の本文はClaude Codeが作成したもので、業務担当者による内容確認は行っていません。
8. 設計を判断する
8.1 この判定が実際の承認ではない理由と、初版の判定を改めた理由
09-04で確認したとおり、実装者と同じAIによる確認は独立した保証になりません。この記事の判定区分・利用範囲も同じ限界があり、実際には総務課長（架空）などの責任者による承認が必要です。この記事は、判定に必要な材料をどう並べ、どう判断するかの「型」を示すものです。
この記事の初版は、「実際に動く画面での受入確認が未実施」と自ら記録しながら、判定区分を「限定試行（実際の依頼のうち低リスクなものから試しに使う）」にしていました。画面が無ければ利用者は操作できず、受入確認で観測した結果も無いのに実際の依頼を載せることになり、判定が入力の事実と矛盾していました。判定は「確認できたことから下せる上限」で止め、足りない確認は判定区分を上げる条件として書く、という形に改めています。
8.2 残る問題を受け入れる条件と、延期する条件
| 観点 | 受け入れる場合の目安 | 延期する場合の目安 |
|---|---|---|
| 失敗の影響 | 影響が小さく、失敗しても検知・回復できる（例：失敗ログで検知できる部分失敗） | 影響が大きく、検知・回復が難しい（例：未検証の同時アクセス・負荷） |
| 業務上の必要性 | 限られた範囲・期間であれば、業務への支障は小さい | 全社的な利用には、より高い確実性が求められる |
| 確認の有無 | 実際に観測した結果があり、その範囲で問題が無い | 観測する対象が無い、または観測していない。この場合は「受容」の対象にせず、判定区分を上げる条件にする |
この記事では、演習の範囲で許容できる問題（履歴のロールバック設計）は受容し、観測していないこと（画面での受入確認、実装者以外の確認）は受容の対象にせず、限定試行へ進む条件として延期しています。
9. 持ち帰る成果物
| 成果物 | 空欄版 | 記入例 |
|---|---|---|
| 利用開始判定記録ひな形（判定区分、利用範囲、未解決問題と扱い、責任者、復旧手段、承認条件、判定日） | templates/10-04-go-nogo_template.md | templates/10-04-go-nogo_example.md |
自分の業務に使うときの手順は次のとおりです。
- これまでの確認結果（テスト、レビュー、受入確認、移行、手順書）と、実装・確認が済んでいない範囲を一覧にする
- 未解決問題を洗い出し、出所と扱い（受容／延期）と理由を決める。観測していないことは受容しない
- 事実から下せる判定区分を決め、次の区分へ進む条件・利用範囲・責任者・復旧手段・承認条件を判定記録にまとめる
- 実際の責任者による承認を得る（この記事の判定はその前段階の材料整理である）
10. 次工程への受渡し
次へ渡すもの：利用開始判定記録。
次工程での使われ方：11-01（公開先と設定を確認する）では、この判定記録（演習成功。限定試行は延期条件付き）を前提に、配置サンドボックスへの配置に向けた公開前チェックを行います。11-02・11-03の配置と初期利用も、演習の範囲で行います。
前工程へ戻る条件：限定試行へ進む条件①〜③が満たされていない間は、08（画面・提出時チェックの実装）・10-01（受入確認）に戻ります。同時アクセス・負荷は実業務導入前に09-03へ戻って確認します。
11. 根拠と更新情報
- この記事の会社・人物・データはすべて架空の設定です。
- 未解決問題の一覧は09-04、受入結果は10-01（Remediation Phase 1で修正後：合格0件・判定保留1件・未確認4件）、移行結果は10-02、利用手順書は10-03に基づきます。
- 2026-09-20（Remediation Phase 1）：受入監査で「画面での受入確認が未実施と記録しながら限定試行と判定しており、判定が入力の事実と矛盾する」と指摘された。判定区分を「演習成功」に改め、限定試行へ進む条件を明記した。判定材料の並べ方（型）は変えていない。
- 復旧手段の参照先は05-04（復旧方針）・12-03（記事C）・12-04です。REQ-008（バックアップ・復元後の照合）は、02-04のとおりこの題材アプリの対象外であり、記事Cで扱われています。
- 2026-09-21（Phase 5B-2C2）：Quality Contract への整合として、読む順路・第4節の判断項目・POINT・CHECKLIST・記事間の参照を追加した。判定区分・限定試行へ進む条件・未解決問題の扱い・第5〜8節の本文は変えていない。
- 制作の来歴：本文はClaude Codeが作成しました。人（ユーザー）による実読・内容確認、実際の業務担当者・責任者による承認は未実施です。
- 未確認事項：実際の業務担当者・責任者による承認、限定試行の実施と結果は、この記事の時点では行っていません。