まず結論：厚い資料より、同じ図を見る5項目
業務システムの稟議で止まりやすいのは、機能が多い資料なのに「何が成功か」「今回やらないこと」が書いていないケースです。経営は投資対効果とリスク、現場は毎日の操作、情シスは権限と運用を見ます。見る点が違うので、同じ5項目を先に揃えます。
この型は補助金の有無に依存しません。補助金がある場合も、採択を主語にせず、使う範囲と段階導入の説明に補助線として触れる程度に留めます。
通りにくい
通りやすい
稟議キットの最小セット
最初に揃えるのは次の5つです。画面ワイヤーは「あるとよい参考」であり、無くても稟議は進められます。
目的
何の痛みを止めるか（漏れ／転記／属人化／期限）
範囲と対象外
今回やる一本と、やらない帳票・拠点・連携
成功条件
現場で続く状態を計測可能な言葉で
体制
業務オーナー／現場代表／情シス／ベンダーの役割
次の判断
何週間後に何を見て次段階へ進むか
- 目的が「システムを入れる」ではなく業務の言葉になっているか
- 対象外が書いてあり、後から無制限に広がらないか
- 成功条件が採択・納品完了以外で書けるか
- 現場代表の名前（または役割）が入っているか
- 次段階の判断日と見る指標が書いてあるか
1枚要約の書き方（補助金にも転用）
表紙1枚は、経営が30秒で追える要約にします。補助金に触れる場合は「初期投資の橋渡し」と書き、主語は業務の定着に置きます。金額の具体は見積前提が固まるまで空欄でも構いません。
添付は、現状の痛み（Before）、段階導入の図、リスクと回避（権限・併用期間）、参考見積の前提、の順が扱いやすいです。
- 01
課題と目的
いま止まっている業務を1行
- 02
範囲
やる／やらないを対で
- 03
効果の見方
成功条件と計測の目安
- 04
進め方
段階と次の判断日
- 05
依頼事項
承認してほしいことだけ
社内の役割分担
稟議が通っても、現場代表と業務オーナーがいないと定着しません。ベンダーに全部を委ねる前提の稟議は、後で仕様変更と責任の所在が曖昧になります。
社内で先に持つ
- 業務オーナーと成功条件
- 現場代表の指名
- 対象外の最終判断
- 権限・データの扱い方針
ベンダーと詰める
- 段階ごとの成果物
- 併用期間の設計
- 非機能（権限・ログ・環境）
- 保守の範囲
次の一歩
キットの骨格ができたら、開発プロセスのページとRFP最小セットで発注側の前提を揃えます。相談は、完成した厚い資料がなくても、5項目の下書きからで構いません。
よくある質問
稟議資料は何ページ必要ですか？
最初は1枚の要約＋補足数枚で足りることが多いです。厚い機能一覧より、目的・範囲・成功条件・体制・次の判断が揃っている方が質問に答えやすいです。
補助金がない案件でも使えますか？
使えます。本キットは補助金専用ではありません。補助金は「初期投資の橋渡し」として1項目で触れ、主語は業務の定着と段階導入に置きます。
金額をいくらと書けばよいですか？
具体額は案件と見積前提で変わります。稟議では「段階ごとの投資の意味」と「やらない場合の損失（漏れ・転記・属人化）」を先に書き、金額は見積確定後に差し込む方が安全です。
既存の稟議1枚記事との違いは？
既存は補助金×業務システム化の1枚に特化しています。本記事は補助金以外にも転用できる「キット」全体（1枚＋添付の役割分担）を整理します。