LASSIC Media らしくメディア
システム改修の稟議書の項目と例文｜影響範囲と止めた場合の書き方
監修・編集責任者：牛尾 昭昌（株式会社LASSIC 執行役員）
この記事の結論
- システム改修の稟議書には、導入の稟議の項目に加えて、現行への影響範囲・回帰テストの範囲・止めた場合の不利益を書きます。
- 止めた場合の不利益は、法改正・サポート終了・不具合・業務の変化という改修の理由ごとに書き方と期限が変わります。
- 影響調査を先に決裁し、改修の費用は調査の結果と内訳を分けた見積もりで改めて申請すると説明しやすくなります。
※ 本記事は2026年10月時点の公式情報（省庁・公的機関、および製品やサービスを提供する事業者が公開している資料）に基づきます。
法改正に合わせてシステムを直したいのに、稟議を出したら「今のままで何が困るのか」と差し戻された——。既存のシステムを直す稟議では、新しく入れるときとは違う問いが返ってきます。システム改修の稟議書は、改修の理由・範囲・費用に加えて、いまのシステムへの影響と、改修しなかった場合の不利益を決裁者に示す社内の書類です。
本記事では、システム改修の稟議を初めて書く担当者に向けて、改修ならではの項目と例文、改修の理由ごとの「止めた場合の不利益」の書き方、決裁者から出やすい質問と答え方、見積もりを保守会社に頼むときの確認点を整理します。
目次
システム改修の稟議書とは
システム改修の稟議書は、稼働中のシステムを直す費用と作業の承認を求める社内の書類です。件名・目的・費用・体制という骨組みは、新しくシステムを入れるときと変わりません。共通の項目の書き方はシステム導入の稟議書の書き方で扱っています。改修では、すでに動いている業務とデータがあるため、決裁者は「何を変えるか」と同じくらい、「何が壊れないか」を気にします。
- 現行への影響範囲：変える箇所につながる画面・帳票・データ・連携先
- 回帰テストの範囲：変えていない部分のうち、どこまでを確かめ直すか。デジタル庁の解説書は回帰テストを、修正箇所がほかに影響していないことを確かめるテストとして扱っています*2
- 止めた場合の不利益：改修を見送ったときに起きることと、その時期
稟議を書く前に、その修正が保守の作業なのか改修なのかも確かめます。デジタル庁の実践ガイドブックは、保守の修正を、サービスの開始時点で定めた設計どおりに動かすためのものとしています。そのうえで、既存の機能の修正や新たな機能の開発を「機能改修」と呼んで分けています。*1
改修の稟議書の項目と例文
システム改修の稟議書でよく使う項目を、書く中身・例文・決裁者が見る点に分けると次の表のようになります。例文の「〇〇」は、自社のシステム名や部署名、数値に置き換えて使います。
| 項目 | 書く中身 | 例文 | 決裁者が見る点 |
|---|---|---|---|
| 件名 | 何を直す承認を求めるかを一言で | 「〇〇システムの〇〇機能の改修の件」 | 改修なのか、作り直しや保守の作業なのかが分かるか |
| 改修の理由 | 法改正・製品のサポート終了・不具合・業務の変化のどれかと、その期限 | 「〇年〇月の制度の変更に合わせ、請求書の記載項目を改める必要がある。」 | 期限が社外で決まっているか、社内で動かせるか |
| 改修の範囲 | 変える画面・帳票・機能と、変えないもの | 「請求書の発行画面と帳票の〇か所を改修する。受注の入力画面は変えない。」 | 範囲が後から広がらないか |
| 現行への影響範囲 | 変える箇所につながる機能・データ・連携先と、調べた方法 | 「影響調査の結果、〇〇システムへ渡すデータの項目にも変更が及ぶ。」 | 調べた結果なのか、見込みなのか |
| 回帰テストの範囲 | 変えない部分のどこまでを確かめ直すか | 「改修する〇機能に加え、つながる〇機能を、過去のテストの記録を使って確かめ直す。」 | テストの費用が何に使われるか |
| 止めた場合の不利益 | 改修を見送ったときに起きることと、その時期 | 「改修しない場合、〇月以降は請求書を〇〇部が手作業で直す必要が生じる。」 | 今のままで何が困るのか |
| 費用と見積もりの根拠 | 金額、内訳、見積もりを出した事業者と取った数 | 「影響調査・改修・テスト・リリースの内訳で〇〇万円。現行の保守会社を含む〇社から見積もりを取った。」 | 内訳が「一式」になっていないか |
| 時期とリリースの判定 | 本番へ反映する日と、反映を見送る条件 | 「〇月〇日に本番へ反映する。重大な不具合が残る場合は反映を見送り、〇〇の手作業で対応する。」 | 期日ありきで反映を決めていないか |
| 体制と契約 | 社内の責任者、改修を頼む先、契約の形 | 「社内は〇〇課長を責任者とし、改修は現行の保守会社に依頼する（保守契約とは別の契約）。」 | 保守契約の範囲と重なっていないか |
導入の稟議と比べて書き漏らしやすいのは、現行への影響範囲と回帰テストの範囲の行です。デジタル庁の実践ガイドブックは、改修の要件を新規構築時の要件定義書に混ぜると、何を直すのか分からなくなるおそれがあるとしています。そこで、既存の要件と改修の要件を分け、改修で足す画面や機能を「改修要件定義書」にまとめる方法を挙げています。*1 稟議書でも、変えるものと変えないものを分けて書きます。
理由別の止めた場合の不利益
改修の稟議で決裁者が最も確かめたいのは「今のままで何が困るのか」です。止めた場合の不利益は、改修の理由によって書き方と期限の決まり方が変わります。
| 改修の理由 | 止めた場合の不利益の書き方 | 期限の決まり方 | 添える資料 |
|---|---|---|---|
| 法改正・制度の変更 | 施行日以降、業務や帳票が法令や制度に合わなくなる点を書く | 施行日で決まり、社内では動かせない | 制度の変更の概要、対象になる帳票と画面の一覧 |
| 製品のサポート終了 | サポートが切れた後は、弱点が見つかっても提供元の修正が届かないおそれを書く | 製品の提供元が決めたサポートの期限 | サポートの期限が分かる提供元の資料 |
| 不具合 | 起きている頻度、手作業で避ける手間、再発したときの業務への影響を書く | 社内で決めるが、再発のおそれが大きいほど早まる | 障害の記録、回避の作業の記録 |
| 業務の変化 | 今の仕組みのままで続く手作業や、受けられない取引を書く | 社内の計画で決まる | 業務の流れ図、手作業の記録 |
製品のサポート終了について、デジタル庁の実践ガイドブックは、サポートが切れた製品を使い続けると、脆弱性（セキュリティ上の弱点）などの問題が起きても製品の供給元が対応しないおそれがあるとしています。原則としてサポートが終わるまでに後継の製品を入れるなどの対応をとるよう求めています。*1 稟議書には、サポートの期限と、その日までに改修を終える工程を並べて書きます。
法改正のように期限が社外で決まる改修では、稟議を早めに動かします。同じガイドブックは法改正への対応を例に、影響の詳細が分からなくても、影響が出る可能性が分かった段階でまず関係者に一報を入れるよう勧めています。*1 稟議も、影響調査の費用を先に決裁し、改修の費用は調査の結果をもとに改めて申請する、と区切ると期限に間に合わせやすくなります。
決裁者から出やすい質問と答え方
改修の稟議を回すと、導入の稟議とは違う質問が返ってきます。先に答えを添付の資料に入れておきます。
| 質問 | 答え方 | 添える資料 |
|---|---|---|
| 少し直すだけなのに、なぜテストの費用が大きいのか | 変えていない部分が壊れていないかを確かめる回帰テストの範囲と、その範囲にした理由を示す | 影響調査の結果、テストの範囲の一覧 |
| 保守の費用で直せないのか | 保守契約の作業範囲と、今回の改修がその外になる理由を示す | 保守契約の作業範囲 |
| 作り直したほうがよいのではないか | 改修と作り直しを、費用・期間・止まる業務の長さで比べる | 比較表 |
| 範囲が後から広がらないか | 変えるものと変えないものを分けて書き、広がるときは改めて申請すると示す | 改修の範囲の一覧 |
| 期日に間に合わなかったらどうするか | 反映を見送る条件と、その間の業務の回し方を示す | リリースの判定の基準 |
テストの費用の質問には、データを添えると答えやすくなります。IPA（情報処理推進機構）の「ソフトウェア開発分析データ集2022」では、改修・保守と拡張を合わせた改良開発580件で、総合テストが工数に占める比率の中央値が14.2％でした。新規開発270件の11.9％より高くなっています。*3 変えていない部分を確かめ直す分、改修ではテストの重みが増えると説明できます。
期日の質問には、判定の基準で答えます。デジタル庁の実践ガイドブックは、制度改正や機器の更改でリリース日を延ばせない場合の判定会議は形だけになりやすいとしています。そのうえで、否認する条件を先に並べ、1つでも当てはまれば否認すると決めておくよう勧めています。*1
見積もりを保守会社に頼むときの確認点
稟議書は社内で書きますが、影響範囲や見積もりの根拠は、保守会社の手を借りて出すことになります。保守会社の比べ方はシステム保守会社の選び方で扱っています。
- 影響調査：設計書とソースコードを読み、変更が及ぶ画面・データ・連携先を洗い出す作業
- 改修の要件の整理：変えるものと変えないものを分けた資料づくり
- 回帰テストの範囲の案：影響調査の結果をもとに、確かめ直す範囲を示す作業
- 見積もりの内訳：影響調査・改修・テスト・リリースに分けた金額
頼むときは、次の点を先に確かめておきます。
- 範囲：影響調査だけを先に頼めるか、改修まで一緒に頼むか
- 期間：法改正の施行日や製品のサポート期限に間に合うか
- 体制：現行の保守会社と別の会社に頼むとき、設計書やソースコードを渡せるか
- 費用の決まり方：調査の費用と改修の費用を分けて見積もれるか
- 引き継ぎ：改修した箇所の設計書とテストの記録を、更新した形で受け取れるか
デジタル庁の実践ガイドブックは、改修による影響度を調べたうえで、発注者と受注者がテストの範囲や方法を話し合えば、減らせる作業を見つけられる場合があるとしています。改修の規模と実際にかかった工数を報告させておくと、次に同じ規模の改修をするときに工数が妥当かを確かめられる、とも述べています。*1
まとめ：システム改修の稟議書で確かめておきたい3つの点
システム改修の稟議書を書くうえで、確かめておきたい点は3つに整理できます。第一に、導入の稟議と共通の項目に加えて、現行への影響範囲と回帰テストの範囲を、変えるものと変えないものに分けて書くこと。第二に、止めた場合の不利益を、法改正・製品のサポート終了・不具合・業務の変化という改修の理由に合わせて、期限とともに示すこと。第三に、影響調査と改修で決裁を区切り、内訳を分けた見積もりと実績の工数を根拠にすることです。影響調査や見積もりの資料づくりに迷いがあれば、外部の手を借りるのも一つの選択肢です。
よくある質問
小さな改修でも稟議は必要ですか
必要かどうかは、社内の決裁の規程で確かめます。保守契約の作業範囲に入る修正なら、別の稟議が要らないこともあります。範囲に入るかどうかは、保守契約の作業範囲と、今回の修正が設計どおりに動かすためのものかで判断します。
影響調査の結果が出る前に稟議を出してもよいですか
出してもかまいませんが、その場合は改修の費用を見込みとして書き、調査の後に金額が変わりうることを添えます。期限が迫っているときは、影響調査の費用だけを先に決裁し、調査の結果をもとに改修の稟議を改めて出す方法もあります。
改修ではなく作り直しで稟議を出すべきか迷ったときはどうすればよいですか
改修と作り直しを同じ表で比べ、費用・期間・止まる業務の長さ・今後も改修が続く見込みを並べます。設計書が残っておらず改修のたびに調査がかさむ場合は、作り直しの案も比較の欄に入れておきます。
システム改修の影響調査と見積もりのご相談
改修の稟議に添える影響調査や回帰テストの範囲の整理から、内訳を分けた見積もり、改修と本番への反映まで、元請（プライムベンダー）としてご提案します。
2006年の創業以来、一次請けのシステムインテグレーターとして、企業のシステム開発と保守・運用を受託してきました。
出典
- *1 参考：デジタル庁「デジタル社会推進実践ガイドブック DS-120 デジタル・ガバメント推進標準ガイドライン実践ガイドブック」（2026年6月12日）（https://www.digital.go.jp/resources/standard_guidelines）。出典：第3編第3章「予算及び執行」（サポート終了対応、法改正の影響の段階的な伝達）、第3編第6章「調達」（改修要件定義書）、第3編第7章「設計・開発」（リリース判定・稼働判定の否認条件）、第3編第9章「運用及び保守」（保守と機能改修の違い、テストのスコープの協議、実績工数の報告）を参照（2026年10月確認）
- *2 参考：デジタル庁「デジタル社会推進実践ガイドブック DS-110 デジタル・ガバメント推進標準ガイドライン解説書」（2026年6月12日）（https://www.digital.go.jp/resources/standard_guidelines）。出典：第7章5「開発・テストの実施・管理」（回帰テストとテスト工程の合理化）を参照（2026年10月確認）
- *3 参考：独立行政法人情報処理推進機構（IPA）「ソフトウェア開発分析データ集2022」（https://www.ipa.go.jp/digital/software-survey/metrics/metrics2022.html）。出典：A3.3.8・A3.3.9「工程別工数」（表A3-3-8 新規開発・表A3-3-9 改良開発）を参照（2026年10月確認）
