保守・改善・引継ぎ・終了学習記事全11節Design
「取り下げたい」「取消したい」という要望を、優先順位付きの一覧にする
この記事で身につくこと利用状況と業務課題から、追加・修正・廃止を判断する考え方と、要望をそのまま実装しない理由を説明できる。
記事内目次（19項目）
この記事の会社・人物・データはすべて架空の設定です。実在する会社や案件とは関係ありません。この記事の要望は、02-02で「後で」とした拡張候補を題材にした想定例であり、実際に利用者から寄せられた要望ではありません。12-01の運用項目を実際に確認して見つけたものでもありません。
この記事は何の話か。「提出済みの依頼を取り下げたい」「承認を取り消したい」という架空の要望を、02-02・01-03の内容に照らして、優先順位と扱い（追加・修正・廃止・見送り）を決め、改善要望一覧にまとめる話です。
なぜ必要か。要望が来るたびにそのまま実装していては、02-02で決めた最小機能の範囲が際限なく広がり、そのたびに権限表・テスト・利用手順書の直し忘れが起きます。逆に、要望を放っておくと、利用者は「言っても変わらない」と感じて申告そのものをやめてしまい、12-01の運用項目でも異常に気づけなくなります。要望を、業務効果・失敗の影響・実装と検証の負担から判断し、見送るものにも理由と再検討条件を残す必要があります。
この記事を読むとできるようになること。
- 利用状況と業務課題から、追加・修正・廃止を判断する考え方を説明できる
- 架空の要望を、目的・指標に照らして優先順位と扱いを改善要望一覧に書ける
- 優先順位を、業務効果・失敗の影響・実装と検証の負担から比較して判断できる
- 要望ごとに「誰が判断し、何を見て、どこで止め、次にどの記事へ進むか」を言える
読む順路。この記事は3つの深さで読めます。全部を順に読む必要はありません。
- 基本だけ理解する：第1節→第3節（要望をそのまま実装しない理由）→第4節（判断すること）→第9節。ここまでで、要望を「追加・修正・廃止・見送り」に分け、見送りにも理由を残す考え方が分かります。AIへの依頼は出てきません。
- 作って確かめる：上に加えて第5.2節（02-02の拡張候補との対応）→第5.3節（誰が・何を見て・どこで止めるか）→第5.4節（AIに下書きを頼む場合の注意）→第6節（改善要望一覧）→第7節（確かめたこと・確かめていないこと）。
- 設計判断を深める：上に加えて第8節（優先順位の判断観点、02-02の比較との関係、未採用テーマの再検討条件）。
1. 今回の業務課題と完成するもの
この記事でやることは、02-02で「後で」とした拡張候補（提出済みの取り下げ、承認取消、代理承認）について、01-03の目的・指標、12-01の運用項目に照らして優先順位と扱いを決め、改善要望一覧にまとめることです。
12-01では運用項目を確認する仕組みを決めましたが、そこから見つかった課題をどう扱うかはまだ決めていませんでした。この記事では、それを扱います。
この記事を読み終えると、次のものが手元にできます。
- 改善要望一覧（要望、出所、関連要件ID、区分、優先度、理由、判断者）
2. 前提知識と読む順路
この記事で使う言葉を先に説明します。
改善要望
一言でいうと、利用者や運用担当から寄せられる、「こうしてほしい」という声です。
区分（追加・修正・廃止・見送り）
一言でいうと、その要望をどう扱うかの判断です。「追加」は新しい機能として実装すること、「修正」は既存の機能を直すこと、「廃止」は既存の機能をやめること、「見送り」は今回は扱わないことです。
これがないと、要望が来るたびに個別に判断することになり、判断の基準がぶれたり、02-02で決めた範囲を無計画に広げてしまったりする可能性があります。
読む順路：運用項目は12-01、目的・指標は01-03、最小機能と拡張候補は02-02が該当します。この記事の改善要望一覧は、13-02（変更の影響を調べる）の調査対象になります。
3. 理解する：要望をそのまま実装しない理由
3.1 追加・修正・廃止を判断する考え方
利用状況（12-01で確認した運用項目）や業務課題から要望が出てきたとき、それをすぐに実装するのではなく、次の順で確かめます。
- 出所を確かめる。誰が、どの場面で困って言ったのかを記録します。出所が無い要望は、あとで「本当に必要だったか」を確かめられません。
- 過去の判断を確かめる。02-02で「後で」「今回は作らない」とした理由が今も当てはまるかを見ます。理由が消えていなければ、見送りを続けます。
- 目的・指標と結びつける。01-03の指標（問い合わせ回数、記録がないという申告の件数、重複対応の件数）のどれに効くかを書きます。どの指標にも効かない要望は、優先度を上げる根拠がありません。
- 失敗の影響と負担を見る。実現したときに間違いが起きたら何が壊れるか、直す範囲（権限表・テスト・手順書）がどこまで広がるかを見ます。
たとえば「承認を取り消したい」は、誤承認の訂正手段として効果はありますが、承認済みの扱いを変えるため、05-02の状態遷移・05-03の権限・履歴の扱いに波及します。効果があっても、失敗の影響と負担が大きければ、見送りを続けて理由と再検討条件を残します。
3.2 よくある誤解
「利用者から要望が来たら、なるべく実装すべき」。02-02で「承認取消」を拡張候補とした理由（取消の影響範囲を先に確定させないため）は、この記事の時点でも当てはまるかどうかを確認する必要があります。理由が今も当てはまるなら、見送りを継続します（第6節）。
「優先順位は要望が来た順で決めればよい」。要望が来た順ではなく、業務効果・失敗の影響・実装と検証の負担から比較して優先順位を決めます（第8.1節）。
「一覧を作れば改善は進む」。一覧は「何を、どの順で検討するか」を決めるものです。「追加を検討」とした要望は13-02の影響調査に進めて初めて動きます。見送りは、再検討する条件を書いて初めて「放置」と区別できます（第8.2節）。
「AIに要望をまとめさせれば一覧は完成」。AIは要望の言い換え・分類・表の下書きには使えますが、区分と優先度の判断、見送りの理由が今も当てはまるかの判断は人が行います。渡す要望に個人情報が混ざっていないことも人が確かめます（第5.4節）。
4. 判断すること
改善要望一覧を作るときに人が判断することは、次の5つです。
| 判断すること | なぜ判断が必要か | 仮置きしてよいか | 間違えた場合の影響 |
|---|---|---|---|
| 出所を記録するか、どこまで書くか | 出所が無いと、あとで「誰の、どの場面の困りごとか」を確かめられない。ただし申告者の連絡先や依頼の本文までは書かない | 可（「依頼者からの申告」のような役割単位でよい） | 要望の必要性を後から検証できない。または個人情報が一覧に残る |
| 過去に見送った理由が今も当てはまるか | 02-02で「後で」とした理由（代替運用がある、影響範囲が未確定、社内ルールが未確認）が消えていなければ、実装しても同じ問題に当たる | 不可（理由が当てはまるかは、02-02の表を見て確かめる） | 前提が変わっていないのに実装を始め、05-02・05-03を後戻りさせる |
| 区分（追加・修正・廃止・見送り） | 区分が無いと、一覧が「言われたことのメモ」になり、次の工程（13-02）に何を渡すかが決まらない | 可（「追加を検討」のように、影響調査の結果で変わる前提で仮置きしてよい） | 検討していない要望が実装に進む、または必要な要望が埋もれる |
| 優先度と、その理由 | 理由が目的・指標（01-03）と結びついていないと、声の大きさで順番が決まる | 可（この記事の優先度は想定例。実際の申告件数で見直す） | 効果の小さい変更に手間をかけ、効果の大きい変更が遅れる |
| 誰が判断者か | 判断者が決まっていないと、一覧を作った人が実質的に決めることになる | 可（この記事では総務課長（架空）で仮置き） | 業務の責任者が知らないうちに機能の範囲が変わる |
勝手に決めてはいけないこと：実際に利用者から要望が寄せられたかのように書きません。この記事の要望は想定例です。02-02で確認済みの最小機能の範囲を、この記事の判断だけで変更しません（見直しが必要な場合は02-02に戻ります）。記事Aの対象外一覧（代理承認・承認取消・取り下げ・通知・添付）に無い新しい機能を、この記事で「追加」に区分しません。
AIに任せる範囲：要望の言い換え（同じ内容の要望をまとめる）、02-02の拡張候補との対応づけの下書き、一覧の表の形への整形はAIに任せられます。任せてはいけないのは、区分と優先度の判断、過去の見送り理由が今も当てはまるかの判断、判断者の決定、そしてAIに渡す要望に申告者の個人情報・依頼の本文が混ざっていないことの確認です（第5.4節）。
5. 作って確かめる：改善要望一覧を作る
5.1 架空の改善要望
| 要望 | 出所（想定） |
|---|---|
| 提出済みの依頼を取り下げたい | 依頼者からの申告（12-01の「提出済みのまま一定期間承認されない依頼」の確認で見つかった想定） |
| 承認を取り消したい | 承認者からの申告（誤って承認してしまった場合の想定） |
| 代理承認をしたい | 承認者が長期不在の場合の申告（10-03の問い合わせ手順で扱った割当変更とは別の要望） |
5.2 02-02の拡張候補との対応
| 要望 | 02-02での扱い（拡張候補とした理由） | この記事での再検討 |
|---|---|---|
| 提出済みの依頼を取り下げたい | 差戻してもらう運用で当面代替できる | 代替運用で対応できているか、12-01の滞留件数を見て判断する |
| 承認を取り消したい | 承認済みの扱いを初期版では固定し、取消の影響範囲を先に確定させない | 影響範囲（状態遷移、権限、履歴）はこの記事の時点でも未確定のため、理由は今も当てはまる |
| 代理承認をしたい | 誰がいつ代理できるかという社内ルールが未確認 | 社内ルールはこの記事の時点でも未確認のため、理由は今も当てはまる |
5.3 誰が・何を見て・どこで止めるか
一覧の1行ごとに、実務では次を決めます。この記事の内容はすべて想定で、実際の申告・滞留件数は確認していません。
| 要望 | 何を見るか（判断の材料） | 誰が判断するか | どこで止めるか（この記事では進めない条件） | 次にどこを見るか |
|---|---|---|---|---|
| 提出済みの依頼を取り下げたい | 12-01の「提出済みのまま一定期間承認されない依頼」の件数と、差戻しで代替した回数。申告の出所 | 総務課長（架空） | 滞留が無く代替運用で足りている場合は「見送り」に戻す。取り下げは05-02の遷移表に無い遷移（提出済み→下書き）を増やすため、遷移表・権限表をどう変えるかは、この記事では決めない | 13-02の影響調査（6観点）へ。小さな単位で試す流れは13-03 |
| 承認を取り消したい | 誤承認の申告の有無と件数。02-02の見送り理由が消えたか（取消の影響範囲を確定させる社内ルールが整ったか） | 総務課長（架空） | 社内ルールが整うまでは「見送り（継続）」。誤承認が起きた場合は、02-02の代替運用（運用管理者が記録し、手順を見直す）で扱う | 再検討条件が満たされたら13-02へ（13-02はこの要望を題材に影響を調べている） |
| 代理承認をしたい | 承認者の長期不在の申告の件数。10-03の割当変更で足りているか | 総務課長（架空） | 「誰がいつ代理できるか」の社内ルールが確認できるまでは「見送り（継続）」。割当変更で対応する | 社内ルールの確認は業務側（01系）へ。確認できたら13-02へ |
止める判断は、要望を却下することではありません。「この記事の判断だけでは進めない」と決め、理由と再検討条件を一覧に残すことです。
5.4 AIに一覧の下書きを頼む場合の注意
要望の言い換え・分類・表への整形はAIに任せられます。この記事ではAIに実際に頼んではいませんが、頼むときの決まりを先に定めます。
| 項目 | 内容 |
|---|---|
| 渡してよいもの | 要望の内容（役割単位の出所を含む）、02-02の機能一覧（区分と理由）、01-03の目的・指標の表、12-01の運用項目一覧 |
| 渡す前に人が確かめること | 申告者の氏名・連絡先、依頼の本文・件名など、個人情報や業務の中身が要望の文面に混ざっていないこと（06-04）。03-01のデータ持出しの制約に反しないこと |
| 任せてよいこと | 同じ内容の要望をまとめる、02-02の拡張候補との対応づけの下書き、01-03の指標との対応づけの候補出し、一覧の表への整形 |
| 任せてはいけないこと | 区分と優先度の決定、過去の見送り理由が今も当てはまるかの判断、判断者の決定。AIの下書きに「追加」と書かれていても、人が02-02と照合してから区分を決める |
| 記録に残すこと | AIに渡したもの、AIの下書き、人が変えた箇所とその理由。AIの下書きを「判断済みの一覧」として単独で残さない |
6. 実行結果（改善要望一覧）
| 要望 | 出所 | 関連要件ID | 区分 | 優先度 | 理由 | 判断者 |
|---|---|---|---|---|---|---|
| 提出済みの依頼を取り下げたい | 依頼者からの申告（想定） | REQ-002、REQ-005（誰が自分の依頼に何をできるか、履歴を残す。05-02の遷移表には無い遷移） | 追加を検討 | 中 | 01-03の指標「状態が分かるまでの問い合わせ回数」に関連し、差戻し運用による代替が利用者の負担になっている可能性がある | 総務課長（架空） |
| 承認を取り消したい | 承認者からの申告（想定） | REQ-003、REQ-005 | 見送り（継続） | — | 02-02で確認した「取消の影響範囲を先に確定させない」理由が、この記事の時点でも当てはまる | 総務課長（架空） |
| 代理承認をしたい | 承認者からの申告（想定） | REQ-002 | 見送り（継続） | — | 02-02で確認した「誰がいつ代理できるかという社内ルールが未確認」という理由が、この記事の時点でも当てはまる | 総務課長（架空） |
7. 確認結果
実行環境：本節は文書によるまとめであり、コードの実行は伴いません。作成日：2026-09-20、判断項目の展開：2026-09-21。
完了条件との照合：
| 完了条件 | 確認結果 |
|---|---|
| 各要望に出所と区分がある | 第6節の表に記載 |
| 優先度の理由が目的・指標と結びついている | 第6節の理由欄に記載（01-03の指標を引用） |
| 見送りの要望にも理由がある | 第6節の理由欄に記載。再検討する条件は第8.2節 |
| 要望ごとに誰が・何を見て・どこで止め・次にどこへ進むかがある | 第5.3節の表に記載 |
| AIに下書きを頼む場合の渡すもの・任せないことが決まっている | 第5.4節に記載 |
この記事で確かめたこと：3件の要望の区分・理由が、02-02の機能一覧の区分と理由（後で／今回は作らない、代替運用）と食い違っていないこと。優先度の理由が01-03に実在する指標を指していること。
この記事で確かめていないこと：
| 範囲 | 理由 | どこで確かめるか |
|---|---|---|
| 実際に利用者から寄せられる要望の内容・件数 | 要望は想定例。12-01の運用項目を実際に確認した実績も無い | 実際の運用開始後、12-01の確認結果と申告の記録で |
| 「取り下げ」の代替運用（差戻し）が利用者の負担になっているか | 滞留件数・差戻し回数は未測定 | 12-01の「提出済みのまま一定期間承認されない依頼」の件数で |
| 「追加を検討」とした要望の影響範囲 | この記事では調べていない | 13-02の6観点で |
| AIに下書きを頼んだ場合の実際の結果 | この記事ではAIに頼んでいない | 実際の運用で第5.4節の決まりに従って試す |
残る制限：この記事の要望は想定例であり、実際に利用者から寄せられたものではありません。この記事の本文はClaude Codeが作成したもので、業務担当者による内容確認は行っていません。
8. 設計を判断する
8.1 優先順位を判断する観点
| 観点 | 内容 |
|---|---|
| 業務効果 | その要望を実現すると、どれだけ業務が改善するか（01-03の指標との関連） |
| 失敗の影響 | 実現した場合に、誤った操作や設計ミスが起きたときの影響の大きさ |
| 実装と検証の負担 | 実現するために必要な変更範囲（13-02で調べる）と、検証にかかる手間 |
「提出済みの依頼を取り下げたい」は、失敗の影響が小さく（自分の依頼を下書きに戻すだけ）、業務効果も見込めるため、優先度を「中」としています。「承認取消」「代理承認」は、失敗の影響（権限・履歴への影響、社内ルールの未確認）が大きいため、見送りを継続しています。
02-02第8節では、同じ3観点で「後で」の機能を比べ、次に着手するなら「通知メール」が先という順序を挙げていました。この記事で「取り下げ」を先に検討しているのは、この記事の想定では「取り下げ」の要望（申告）があり、「通知」の要望は無かった、という前提の違いによるものです。観点は同じで、材料（実際の申告）が違えば順番が変わる、という例です。どちらが正しいかは、実際の申告と業務の責任者の判断で決まります。
8.2 初版の未採用テーマを再検討する条件
| 未採用テーマ | 再検討する条件 |
|---|---|
| 承認取消 | 取消の影響範囲（状態遷移、権限、履歴）を確定させる社内ルールが整った場合 |
| 代理承認 | 誰がいつ代理できるかという社内ルールが確認できた場合 |
条件が満たされるまでは、これらのテーマを改善要望一覧に「見送り」として残し、条件が満たされた段階で13-02（変更の影響を調べる）に進めます。
9. 持ち帰る成果物
| 成果物 | 空欄版 | 記入例 |
|---|---|---|
| 改善要望一覧ひな形（要望、出所、関連要件ID、区分、優先度、理由、判断者） | templates/13-01-improvement-backlog_template.md | templates/13-01-improvement-backlog_example.md |
自分の業務に使うときの手順は次のとおりです。
- 利用状況（12-01）や業務課題から寄せられた要望を洗い出し、出所を役割単位で記録する
- 過去に「後で」とした理由（02-02など）が今も当てはまるか確認する
- 業務効果・失敗の影響・実装と検証の負担から優先順位を判断する
- 見送りの要望には理由と、再検討する条件を書く
- 要望ごとに、誰が判断し、何を見て、どこで止め、次にどの工程へ進むかを決める
- AIに下書きを頼むなら、渡すもの・渡す前の確認・任せないことを決める
10. 次工程への受渡し
次へ渡すもの：改善要望一覧。
次工程での使われ方：13-02（変更の影響を調べる）では、この一覧の要望を6つの観点で調査します（13-02は「承認取消」を題材に、見送り判断の根拠を具体的にしています）。「追加を検討」とした「取り下げ」を小さな単位で試す流れは13-03（更新して再検証する）で扱います。
前工程へ戻る条件：大きな変更（最小機能の範囲を超える変更）が必要な場合は、02-02（要件定義）に戻って確認します。
11. 根拠と更新情報
- この記事の会社・人物・データはすべて架空の設定です。
- 拡張候補とその理由は02-02、目的・指標は01-03、運用項目は12-01に基づきます。
- 制作の来歴：本文はClaude Codeが作成しました。人（ユーザー）による実読・内容確認、実際の利用者からの要望収集は未実施です。
- 未確認事項：実際に利用者から寄せられる要望の内容・件数は、この記事の時点では確認していません。
- 2026-09-21（Phase 5B-2D）：読む順路（3つの深さ）、第4節の判断項目（判断すること・仮置き可否・間違えた場合の影響・AIに任せる範囲）、第5.3節「誰が・何を見て・どこで止めるか」、第5.4節「AIに一覧の下書きを頼む場合の注意」、第7節の確かめていないこと、第8.1節の02-02第8節との関係、POINT・CHECKLIST・記事間の参照を追加した。「取り下げ」の関連要件IDを REQ-004（必須項目・理由）から REQ-002・REQ-005 に訂正した。要望3件・区分・優先度・判断者・完了条件は変えていない。