新しい業務システムを導入する際、最も重要なステップの一つが「稟議書」の作成と承認です。

どれほど優れたシステムを選定しても、稟議が通らなければプロジェクトは頓挫してしまいます。特に、経理・バックオフィス系のSaaS導入支援を数百社以上担当してきた経験から見ると、稟議書に「あるべき要素」が欠けているために、惜しくも承認が得られないケースを数多く見てきました。

この記事では、元大手SaaSセールスとして多くの導入現場を見てきた筆者が、経営層や関係部門を確実に説得するための稟議書の構成と書き方を解説します。

ステップ1：「何をするか」より「なぜ今、するのか」を明確にする【問題提起と目的】

多くの稟議書は、「○○システムを導入します」という結論から入ってしまいがちです。しかし、経営層が最初に知りたいのは、「現状の問題がなにで、それを放置するとどんなリスクがあるのか」です。

悪い例

「現行のExcel管理は非効率なため、クラウド型システムを導入し、業務を効率化したい。」

良い例

問題提起

「経費精算業務において、紙の領収書対応と手入力作業により、月間150時間の残業が発生し、コスト増を招いています。また、人的ミスによる税務調査リスクを抱えています。」

目的

「本システム導入により、残業時間を50時間に削減（年間人件費約300万円の削減）し、データの自動連携により税務・コンプライアンスリスクをゼロにすることを目指します。」

説得のポイント

• リスクとコストを数値化し、「危機感」を共有する。
• システムの目的を「効率化」ではなく「経営課題の解決」に昇華させる。

ステップ2：「機能」の説明は最小限に留める【選定理由と効果】

稟議書で最も陥りやすい罠が、「選定したシステムの機能一覧」を細かく書きすぎることです。経営層は、機能ではなく「投資対効果（ROI）」にしか興味がありません。

悪い例

「Aシステムは、申請機能、承認機能、連携機能など豊富な機能があり、特にモバイル対応が優れています。」

良い例

選定理由と効果

1. 残業削減効果 (ROI): 〇〇機能により、経理部門と申請者側の合計工数を月間100時間削減します。（削減率66%）
2. 既存システムとの親和性: 既に導入済みの『〇〇販売管理システム』とAPI連携が可能であり、データ移行の手間がありません。
3. ガバナンス強化: 〇〇機能により、不正申請を自動検知し、コンプライアンスレベルを向上させます。

説得のポイント

• 選定したシステムが、ステップ1で定義した課題をピンポイントで解決できる理由だけを記述する。
• 機能名ではなく、「その機能がもたらす具体的効果（数値・リスク回避）」を主語にする。

ステップ3：導入・運用フェーズのリスクを先回りして潰す【予算とスケジュール、リスク】

承認者は、導入後の失敗や想定外の追加出費を最も恐れます。初期費用だけでなく、隠れたコストやリスク、そしてその対策までを明記し、プロジェクトの堅実性を示すことが重要です。

抜けがちな項目

• ランニングコスト以外の「隠れコスト」

• 導入に失敗した場合の「代替案」

• 他部署への「影響と協力要請」

良い例

予算計画（5年間試算）

• 初期費用: 50万円（初期設定費、データ移行費用など）
• 年間ライセンス料: 60万円 × 5年 = 300万円
• 合計コスト: 350万円
• 回収期間: 1年2ヶ月（残業代削減効果に基づく）

導入スケジュール

• キックオフ：〇月〇日
• パイロット運用（経理部のみ）：〇月〇日〜
• 全社展開： 〇月〇日（最も工数のかかるフェーズを明記）

潜在リスクと対策

• リスク: 従業員がシステム利用に慣れず、定着が遅れる可能性がある。
• 対策: 導入後3ヶ月間、ベンダーによるオンサイト研修を計3回実施し、マニュアルを電子化して周知徹底する。

説得のポイント

• 費用は単年だけでなく5年程度の長期視点で試算し、「回収期間」を必ず明記する。
• リスクは隠さず洗い出し、「そのリスクに対して具体的な対策を用意している」ことを示すことで、計画の完成度をアピールする。

ステップ4：承認ルートを滑らかにする「根回し」の技術【社内協力の確保】

稟議書を提出する前に、必ず済ませておくべき工程が「社内根回し」です。これが抜けると、稟議が差し戻されたり、承認後に他部門からの反対で頓挫するリスクが高まります。

失敗する稟議パターン

• 承認ルートの途中にいる部長から「話を聞いていない」と承認を止められる。
• システムを利用する別部門（例：営業部）から「使い勝手が悪い」と導入後に不満が噴出する。

解決の方向性：関係者からの「事前同意」を文書に盛り込む

稟議書には、以下の「根回しの結果」を記載します。

• 影響部門の代表者からの合意:
  • システム利用部門（例：営業、開発）の部長クラスに事前に説明を行い、「このシステムは〇〇部門の課題も解決するため、賛同を得ています」という一文を入れる。
• IT部門・情報システム部門のチェック:
  • セキュリティや既存システムとの連携について、情報システム部門から事前に技術的な合意（例：「セキュリティ基準を満たしていることを確認済み」）を取り付ける。
• 最終承認者への個別説明（トップダウンの要素）:
  • 最終承認者（社長や役員など）に対して、数字（ROI）とリスク対策について事前にブリーフィングを行います。これにより、承認者が稟議書を目にしたときには、既に「知っている案件*としてスムーズに判断が進みます。

説得のポイント

• 根回しは、反対意見を封じるためではなく、建設的な意見を取り入れ、計画の完成度を高めるためのプロセスと位置づける。
• 稟議書は「関係者全員が既に承認している証拠」として機能させる。

【まとめ】稟議書は「ラブレター」ではなく「ビジネス文書」

稟議書は、選定担当者の「好き」や「熱意」を伝えるラブレターではありません。「この投資は、企業の利益とリスク回避に貢献する」ということを論理的かつ数値で証明する、厳格なビジネス文書です。

上記3ステップの要素を網羅し、客観的なデータと明確なROI（投資対効果）を記述することで、あなたの提案は必ず承認フェーズに進むでしょう。