保守・改善・引継ぎ・終了学習記事全11節Design
「承認取消」を追加する場合の影響を、6つの観点でたどる
この記事で身につくこと要件、データ、連携、権限、運用、教材の関連箇所をたどる理由と、要件IDを使った対応づけの役割を説明できる。
記事内目次（20項目）
この記事の会社・人物・データはすべて架空の設定です。実在する会社や案件とは関係ありません。「承認取消」は13-01で見送りとした要望であり、この記事の調査は、その見送り判断の根拠を具体的にするための想定の調査です。実際に実装したものではありません。
この記事は何の話か。13-01で見送りとした「承認取消」を仮に追加するとしたら、要件・データ・連携・権限・運用・教材の6つの観点でどこに影響が及ぶかをたどり、変更影響調査にまとめる話です。
なぜ必要か。「見送り」という判断だけでは、次にこの要望が出てきたときに、また一から検討し直すことになります。逆に、影響を調べずに「小さな変更だから」と実装を始めると、状態遷移表・権限表・テスト・利用手順書のどれかを直し忘れ、08-04で扱った「状態は変わったのに記録が無い」のような不整合を、今度は取消の場面で作ってしまいます。影響範囲を具体的に調べておくことで、13-01の見送り理由を裏づけ、将来の再検討にも使えます。
この記事を読むとできるようになること。
- 要件、データ、連携、権限、運用、教材の関連箇所をたどる理由を説明できる
- 変更内容について、6つの観点で変更影響調査にまとめられる
- 影響範囲の大きさから、変更を分割する・見送る・別の方法で実現する案を比較できる
- 観点ごとに「誰が、どの表を見て、何を確認し、どこで止めるか」を言える
読む順路。この記事は3つの深さで読めます。全部を順に読む必要はありません。
- 基本だけ理解する：第1節→第3節（6つの観点でたどる理由）→第4節（判断すること）→第9節。ここまでで、変更したい箇所だけを直すと何が起きるか、要件IDで何をたどるかが分かります。AIへの依頼は出てきません。
- 作って確かめる：上に加えて第5.2節（要件への影響）→第5.3節（データ・連携・権限）→第5.4節（運用手順・教材）→第5.5節（AIに洗い出しを頼む場合の注意）→第6節（変更影響調査と、誰が・何を確認して・どこで止めるか）→第7節（確かめたこと・確かめていないこと）。
- 設計判断を深める：上に加えて第8節（そのまま実装・分割・見送りの比較、適用限界）。
1. 今回の業務課題と完成するもの
この記事でやることは、13-01で見送りとした「承認取消」を仮に追加するとした場合について、影響する要件ID、データ、連携、権限、運用手順、教材（このFast Trackで作成してきた記事群）の6観点で影響を調べ、変更影響調査にまとめることです。
13-01では要望の優先順位と扱いを決めましたが、「見送り」とした理由を裏づける具体的な影響範囲はまだ調べていませんでした。この記事では、それを調べます。
この記事を読み終えると、次のものが手元にできます。
- 変更影響調査（変更内容、影響する要件ID、データ、連携、権限、運用手順、教材、検証が必要な範囲）
2. 前提知識と読む順路
この記事で使う言葉を先に説明します。
要件IDを使った対応づけ
一言でいうと、REQ-003のような要件IDを手がかりに、その要件に関わる設計・実装・テスト・手順書をたどることです。02-01以降、この教材ではずっとこの方法を使ってきました。
影響範囲
一言でいうと、ある変更が、どこまでの設計・実装・文書に波及するかです。
これがないと、変更したい箇所だけを直して、関連する権限表やテスト、利用手順書の更新を忘れてしまう可能性があります。
読む順路：改善要望は13-01、変更履歴は06-03、状態遷移は05-02、権限は05-03が該当します。この記事の調査結果は、13-03（更新して再検証する）の更新単位・再検証範囲になります。
3. 理解する：6つの観点でたどる理由
3.1 要件・データ・連携・権限・運用・教材
| 観点 | たどる内容 | 見落とすと起きること |
|---|---|---|
| 要件 | 変更によって、どの要件（REQ-001〜008）が影響を受けるか | 要件が変わったのにテストと手順書が旧要件のまま残る |
| データ | 05-01のデータ項目表、05-02の状態遷移表に変更が必要か | 遷移表に無い状態変化がコードだけに存在し、誰も説明できない |
| 連携 | 08-03のような画面・処理間の連携に変更が必要か | 画面に操作が無い、または処理側に受け口が無い |
| 権限 | 05-03の権限表に変更が必要か | 誰でも取消できる、または誰も取消できない |
| 運用手順 | 10-03の利用手順書、12-02の初動手順に変更が必要か | 利用者が操作を知らない、誤操作の対応が決まっていない |
| 教材 | このFast Trackで作成した記事のうち、内容を更新する必要があるものはどれか | 正本（記事・ひな形）と実装が食い違い、引継ぎで混乱する |
要件IDが、この6観点をつなぐ手がかりです。たとえばREQ-003（割当承認者のみ、自己承認禁止）を出発点にすると、05-03の権限表の「承認」の行、記事Bの要件・テスト対応表のREQ-003の行、10-03の承認者の手順、というように、直す候補が芋づる式に見つかります。
3.2 よくある誤解
「コードを直すだけで変更は完了」。要件IDをたどると、コード以外にも、権限表・テスト・利用手順書など、直す必要がある箇所が見つかることがあります（第5節）。
「小さな変更だから影響調査は不要」。「承認取消」のように、一見1つの機能追加に見えても、状態遷移・権限・履歴・運用手順など、複数の箇所に波及する場合があります（第6節で具体的に確認します）。
「影響調査をすれば、実装して分かる副作用も全部分かる」。この記事の調査は、既存の記事の表を読んで論理的に推定したものです。実装して初めて分かる副作用（第8.2節）は含みません。調査は「実装する前に直す箇所を漏らさない」ためのもので、「実装後の検証を省く」ためのものではありません。
「AIに記事を読ませれば影響箇所は洗い出せる」。AIは「REQ-003 に言及している箇所」を集めることはできますが、その箇所を直す必要があるか、変更を進めてよいかは人が判断します。渡す資料に秘密情報が混ざっていないことも人が確かめます（第5.5節）。
4. 判断すること
変更影響調査を作るときに人が判断することは、次の5つです。
| 判断すること | なぜ判断が必要か | 仮置きしてよいか | 間違えた場合の影響 |
|---|---|---|---|
| 変更内容をどこまで具体的に想定するか | 「承認取消」だけでは、誰が・どの状態から・どこへ戻すかが決まらず、影響をたどれない | 可（この記事は第5.1節の想定で仮置き。実装するときに確定する） | 想定が曖昧なまま調べ、影響の抜けに気づけない |
| 6観点のどれに影響があるか、無いか | 「影響なし」も判断。無いと決めた理由が無いと、あとで確かめられない | 不可（観点ごとに、見た表と理由を書く） | 権限表・手順書の直し忘れ |
| 影響する要件IDはどれか | 要件IDが、テスト（記事B）・手順書（10-03）をたどる手がかりになる | 可（調査の途中で増えてよい） | 再検証の範囲（第6節）が狭すぎる |
| 再検証が必要な範囲 | 変更した箇所だけでなく、同じデータ・同じ権限判定を使う既存機能の再実行が必要かを決める | 可（13-03で実際に再実行して見直す） | 既存の承認機能が壊れたことに気づかない |
| そのまま実装・分割・見送りのどれにするか | 影響範囲の大きさと、未確認の前提（社内ルール）から決める。調査した人ではなく、業務の責任者が決める | 可（この記事では「見送り」で仮置き。再検討条件は13-01第8.2節） | 前提が未確認のまま実装し、05-03を後戻りさせる |
勝手に決めてはいけないこと：実際に「承認取消」を実装したかのように書きません。この記事は影響調査のみです。05-02・05-03で確認済みの内容を、この記事の調査のために変更しません（変更が必要なら、その旨を影響として記録するだけにとどめます）。「誰が取消せるか」の社内ルールを、この記事で決めません（未確認のまま記録します）。
AIに任せる範囲：要件IDや用語（「承認済み」「取消」）を手がかりに、既存の記事・ひな形の中で言及している箇所を集めること、集めた箇所を6観点の表に整形することはAIに任せられます。任せてはいけないのは、その箇所を直す必要があるかの判断、「影響なし」の判断、再検証の範囲の決定、そのまま実装・分割・見送りの判断です（第5.5節）。
5. 作って確かめる：変更影響調査を作る
観点ごとに、どの記事のどの表・行を見て、何を根拠に「影響あり」としたかを書きます。すべて既存記事を読んだ机上の推定で、実装はしていません。
5.1 変更内容（想定）
「承認済みの依頼について、承認者が取消操作を行うと、状態を提出済みに戻し、取消の履歴を残す」という機能を、仮に追加すると想定します。
この想定で決めていないこと（調査の中で「未確認」として扱うもの）：誰が取消せるか（承認した本人だけか、割当承認者なら誰でもよいか）、取消の理由を必須にするか、取消を何度でもできるか。
5.2 要件への影響
見た表：記事Aの業務要件一覧（REQ-001〜005、007）、05-04のREQ-008。
| 要件ID | 影響内容 | 根拠（見た行） |
|---|---|---|
| REQ-003（割当承認者のみ、自己承認禁止） | 「誰が取消せるか」という新しい権限条件が必要（承認した本人だけか、割当承認者なら誰でもよいか、未確認） | REQ-003は「対象が提出済みのときだけ承認・差戻しができる」と定めており、承認済みの依頼への操作は定義が無い |
| REQ-005（履歴を残す） | 取消の操作も履歴に残す必要がある | REQ-005の対象操作は「提出・再提出・承認・差戻し」の4つで、取消は含まれていない |
| REQ-007（片方だけの完了を正常扱いしない） | 状態を戻す処理と、履歴への記録が、08-04と同様に片方だけ成功する部分失敗を起こさないようにする必要がある | REQ-007は承認・差戻しを対象に書かれている。取消も「状態を変える＋記録を残す」の組なので同じ条件が要る |
| REQ-001、002、004、008 | 影響なし | 依頼の識別・閲覧範囲・必須項目・バックアップの条件は、取消を加えても変わらない（取消の履歴が増える分は REQ-005 側で扱う） |
5.3 データ・連携・権限への影響
| 観点 | 影響内容 | 根拠（見た表・行） |
|---|---|---|
| データ | 05-02の状態遷移表に「承認済み→提出済み（取消操作）」という新しい遷移を追加する必要がある。新しい状態は増やさない | 遷移表の4行（下書き→提出済み、差戻し→提出済み、提出済み→承認済み、提出済み→差戻し）に、承認済みから出る遷移は無い。05-02第3.1節は「提出済みからしか差戻しできない」と決めることで承認済みの依頼への誤操作を防いでおり、この前提を変えることになる |
| 連携 | 08-03のような連携処理がある場合、取消操作を送る受け口（API）を処理側に追加し、画面側に操作を追加する必要がある | 08-03の処理側は提出（POST /submit）の受け口だけを持ち、承認・差戻しの連携は範囲外。取消の受け口も画面側の操作も無い |
| 権限 | 05-03の権限表に、取消操作の行を追加する必要がある（誰が取消せるかの社内ルールが未確認のため、この記事の時点では行を確定できない） | 権限表は3役割×主要操作の組合せで、「取消」の列は無い。運用管理者の承認代行禁止（設計書5.2）との整合も未確認 |
5.4 運用手順・教材への影響
| 観点 | 影響内容 | 根拠（見た表・行） |
|---|---|---|
| 運用手順 | 10-03の承認者の手順に取消操作の説明を追加、12-02の初動手順に「誤って取消した場合」の対応を追加する必要がある | 10-03の承認者の手順は承認・差戻しまで。12-02の初動手順の入口（記録・通知・申告）には「取消の申告」が無い |
| 教材 | 05-02（状態遷移表）、05-03（権限表）、08-02（保存処理）、記事B（09-02、要件・テスト対応表）、10-03（利用手順書）、12-02（初動手順）の6本の内容更新が必要になる | それぞれ上の行の表・手順を正本として持つ記事。08-02は状態を保存する処理の正本で、遷移が増えれば保存の条件が変わる。記事Bの対応表にはREQ-003・007の行があり（履歴の件数はREQ-006・007の行で確かめている）、取消のテストを足す必要がある |
5.5 AIに関連箇所の洗い出しを頼む場合の注意
要件IDや用語を手がかりに既存の記事・ひな形から関連箇所を集める作業はAIに任せられます。この記事ではAIに実際に頼んではいませんが、頼むときの決まりを先に定めます。
| 項目 | 内容 |
|---|---|
| 渡してよいもの | 変更内容の想定（第5.1節）、既存の記事・ひな形（このFast Trackの正本は架空の題材で、秘密情報を含まない）、要件一覧（記事A）、探す手がかり（REQ-003、REQ-005、REQ-007、「承認済み」「取消」） |
| 渡す前に人が確かめること | 実際の業務で使うときは、渡す設計書・手順書に接続先・鍵・実在の人物の連絡先が混ざっていないこと（06-04）。03-01のデータ持出しの制約に反しないこと |
| 任せてよいこと | 手がかりに言及している箇所の一覧化（記事ID・節・表の行）、6観点の表への整形、「影響あり」候補の根拠の引用 |
| 任せてはいけないこと | その箇所を直す必要があるかの判断、「影響なし」の判断、再検証の範囲の決定、そのまま実装・分割・見送りの判断。AIの一覧に無い箇所が無いとは限らないため、要件IDごとに人が正本の表を1回は自分で見る |
| 記録に残すこと | AIに渡した手がかり、AIが挙げた箇所、人が「影響あり／なし」と判断した理由。AIの一覧を「調査結果」として単独で残さない |
6. 実行結果（変更影響調査）
| 変更内容 | 影響する要件ID | データ | 連携 | 権限 | 運用手順 | 教材 | 検証が必要な範囲 |
|---|---|---|---|---|---|---|---|
| 承認取消の追加（想定） | REQ-003、REQ-005、REQ-007 | 05-02の状態遷移表に新しい遷移を追加 | 08-03相当の連携にAPI追加 | 05-03の権限表に新しい行（社内ルール未確認のため確定できない） | 10-03の利用手順書、12-02の初動手順の更新 | 05-02、05-03、08-02、記事B（09-02）、10-03、12-02（6本） | 状態遷移、権限判定、履歴記録、既存の承認機能（記事Bの対応表の再実行） |
この調査結果を実務で使うときの、誰が・何を確認して・どこで止めるかは次のとおりです。
| 観点 | 誰が確認するか | 何を確認するか | どこで止めるか | 次にどこを見るか |
|---|---|---|---|---|
| 要件 | 業務の責任者（総務課長、架空） | REQ-003の「誰が取消せるか」を社内ルールとして決められるか | 決められない間は、この変更を進めない（13-01の見送り継続） | 決まったら02-02へ戻り、要件として追加する |
| データ・権限 | 設計を担当する人（運用管理者、架空） | 05-02の遷移表・05-03の権限表に、取消の行を矛盾なく足せるか | 承認済みの不変条件（記事A）を崩さずに書けないなら止める | 05-02・05-03の更新 |
| 連携・検証 | 実装・検証を担当する人 | 取消の受け口を足したうえで、既存の承認のテストが全件PASSするか | 既存テストに不一致が出たら、反映せず変更内容を見直す | 13-03の更新→再検証→段階的反映 |
| 運用手順・教材 | 運用管理者（架空） | 10-03・12-02・記事Bなど6本の正本を、実装と同じ変更単位で更新したか | 正本の更新が終わっていない間は、利用者に取消操作を案内しない | 06-03の変更履歴に記録し、13-04の引継ぎ資料に含める |
7. 確認結果
実行環境：本節は文書によるまとめであり、コードの実行は伴いません。作成日：2026-09-20、根拠と判断項目の展開：2026-09-21。
完了条件との照合：
| 完了条件 | 確認結果 |
|---|---|
| 要件・データ・連携・権限・運用・教材の6観点がある | 第5節・第6節の表に記載 |
| 影響する要件IDが特定されている | 第5.2節・第6節に記載（REQ-003、REQ-005、REQ-007）。影響なしとした要件にも理由を記載 |
| 再検証が必要な範囲が書かれている | 第6節に記載 |
| 観点ごとに、見た表・行（根拠）がある | 第5.2〜5.4節の根拠欄に記載 |
| 誰が・何を確認して・どこで止めるかがある | 第6節の2つ目の表に記載 |
この記事で確かめたこと：影響ありとした箇所が、既存記事に実在する表・行（05-02の遷移表、05-03の権限表、記事Aの要件一覧、記事Bの対応表、10-03の手順、12-02の初動手順）を指していること。「影響なし」とした要件に理由があること。
この記事で確かめていないこと：
| 範囲 | 理由 | どこで確かめるか |
|---|---|---|
| 実装して初めて分かる副作用 | 実装していない（机上の調査） | 実装を検討する段階で、13-03の形で小さく作って再検証する |
| 「誰が取消せるか」の社内ルール | 未確認（13-01の見送り理由そのもの） | 業務側（01系）で確認する |
| 6本以外に更新が必要な記事が無いか | 要件IDと用語で人が読んでたどった結果であり、機械的な全文検索はしていない | 実装するときに、要件IDごとにもう一度正本をたどる |
| AIに洗い出しを頼んだ場合の実際の結果 | この記事ではAIに頼んでいない | 実際の調査で第5.5節の決まりに従って試す |
残る制限：この調査は、実際に「承認取消」を実装したものではなく、影響範囲を見積もった想定です。この記事の本文はClaude Codeが作成したもので、業務担当者による内容確認は行っていません。
8. 設計を判断する
8.1 変更を分割する・見送る・別の方法で実現する案の比較
| 案 | 内容 | この記事での判断 |
|---|---|---|
| そのまま実装する | 第5〜6節で調べた影響すべてに対応する | 影響範囲が6観点・6本の教材に及ぶため、実装と検証の負担が大きい |
| 分割して実装する | 「取消の権限ルールを確定する」工程を先に切り出し、それが決まってから実装に進む | 権限ルール未確認のまま実装すると、05-03の権限表を後戻りさせる可能性が高い |
| 見送る（この記事で採用、13-01と同じ） | 現時点では実装せず、社内ルールが整った段階で再検討する | 13-01の見送り判断は、この記事の影響調査によって裏づけられる |
見送りの間は、02-02の代替運用（誤承認が起きた場合は運用管理者が記録し、以後は手順を見直す。システムでは戻さない）で対応します。再検討する条件は13-01第8.2節のとおりです。
8.2 適用限界
この調査は、既存の記事（05-02、05-03など）の内容から論理的に推定した影響であり、実際に実装してみて初めて分かる影響（想定していなかった副作用など）を含んでいません。実際に実装を検討する段階になったら、あらためて詳細な調査が必要です。
9. 持ち帰る成果物
| 成果物 | 空欄版 | 記入例 |
|---|---|---|
| 変更影響調査ひな形（変更内容、影響する要件ID、データ、連携、権限、運用手順、教材、検証が必要な範囲） | templates/13-02-impact-analysis_template.md | templates/13-02-impact-analysis_example.md |
自分の業務に使うときの手順は次のとおりです。
- 変更内容を明確にする（誰が・どの状態から・どこへ。決めていないことは「未確認」と書く）
- 要件IDを手がかりに、関連する設計・実装・テスト・手順書をたどる
- 要件・データ・連携・権限・運用・教材の6観点で影響を整理し、「影響なし」にも見た表と理由を書く
- 観点ごとに、誰が確認し、どこで止めるかを決める
- 影響範囲の大きさから、そのまま実装する・分割する・見送るを判断する（判断者は業務の責任者）
- AIに洗い出しを頼むなら、渡すもの・渡す前の確認・任せないことを決める
10. 次工程への受渡し
次へ渡すもの：変更影響調査。
次工程での使われ方：13-03（更新して再検証する）では、この調査結果を更新単位・再検証範囲として使います（この記事では見送りとしたため、13-03では13-01で「追加を検討」とした「取り下げ」を、同じ6観点で小さくたどってから実装します）。06-03の変更履歴には、見送りの判断とその根拠（この調査）を残します。
前工程へ戻る条件：影響範囲が要件定義（02系）に及ぶ場合は、02-02に戻って確認します。
11. 根拠と更新情報
- この記事の会社・人物・データはすべて架空の設定です。
- 影響範囲の推定は、記事A（要件一覧）、05-02・05-03・08-02・08-03・08-04・記事B（09-02）・10-03・12-02の既存記事の内容に基づきます。
- 制作の来歴：本文はClaude Codeが作成しました。人（ユーザー）による実読・内容確認、実際の実装は未実施です。
- 未確認事項：実際に「承認取消」を実装した場合に初めて分かる影響（想定していなかった副作用など）は、この記事の時点では確認していません。
- 2026-09-21（Phase 5B-2D）：読む順路（3つの深さ）、第4節の判断項目（判断すること・仮置き可否・間違えた場合の影響・AIに任せる範囲）、第5.2〜5.4節の根拠欄（見た表・行）と「影響なし」の理由、第5.5節「AIに関連箇所の洗い出しを頼む場合の注意」、第6節の「誰が・何を確認して・どこで止めるか」、第7節の確かめていないこと、POINT・CHECKLIST・記事間の参照を追加した。変更内容の想定・6観点・影響する要件ID・見送りの判断・完了条件は変えていない。