Step.2 予算要求の事前準備

予算要求の事前準備として、どのようなことを想像するでしょうか。

とりあえず、3社くらいに見積りを取っておけばよいか・・。そのように安易に考える人もいるかもしれません。しかし、そのように準備を手抜きした場合は、予算要求内容の査定段階で要求内容の必要性や経費妥当性等を十分に説明することができず、必要な予算額を確保できないということにもなりかねません。

逆に、プロジェクトの目標、内容、経費、効果等について第三者にもわかりやすい説明資料を準備しておけば、その後の査定段階でも関係者の理解を得ることが容易になります。

予算要求の資料をどのように準備していけばよいか、見積りをどのように取得してどう精査すればよいかについて、具体的に説明します。

予算要求の活動を計画的に実施する

【標準ガイドライン関連箇所:第3編第3章全般】

予算要求の活動の中では、資料の作成、見積りの取得、関係者との調整等を行います。

予算要求の年間スケジュールを把握する

まずは、予算要求の基本的なスケジュールを見てみましょう。なお実際には、毎年度発出される、事務連絡等の指示に従ってください。(なお、本項では、基本的に一括計上対象システムについて記載します。)

  • 図3-1
  • 表3-1

予算要求の年間スケジュール

予算要求・編成作業は、各段階において作業の締切り日が厳格に定められていますので、作業が遅延すると必要な予算を確保できないことになってしまいます。そのような事態とならないため、いつ頃どの作業を行うかを意識し、計画を立てて、十分な時間と期間を確保して進めれば、スムーズに作業を進めることができます。

予算要求に向けた作業のポイント

  • 予算要求の対象の特定 後述する「予算要求から漏れがちな項目」にも注意しながら、予算要求の対象となる項目をピックアップします。また、情報システムの機能に影響がありそうな制度改正の動向や、情報システムの構成に影響がありそうな技術動向等、予算要求の前提となる背景事象については、事前調査も必要となるので、そのための期間を確保します。

  • 当然増減額の整理 当年度限りの経費(当然減)は翌年度予算では計上する必要がなくなります。逆に当年度の途中から運用開始をして、予算上数箇月分しか計上されていないもの(平年度化増)については、翌年度に12か月分必要となりますので、自動的に増えることになります。 このような、自動的に増減するような経費をあらかじめ特定して、基礎的な金額を把握しておきます。

  • *経費の見積り* 予算要求額の前提となるための見積りを取得します。 見積り対象の規模にもよりますが、事業者に見積り依頼を行ってから見積りを受領するまでには、数週間必要になることが一般的です。また、見積り依頼のプロセスは1回で完結するわけではありません。事業者から提示を受けた見積り内容について、対象範囲や積算根拠を確認し、場合によっては前提条件を変更した上で再見積りを依頼することもあります。見積り取得後にこのような精査を含めることも考慮して、経費の見積りに十分な期間を確保しましょう。

  • 資料の準備 予算要求の全体がわかる資料、業務説明資料等を作成します。 特に、新規に情報システムを整備する際には、資料の準備には数箇月にわたって十分な期間を確保することが必要です(大規模な情報システムを新規に構築する場合は、サービス・業務企画の期間を含めて数年をかけることもあります)。予算要求の内容に応じて、十分な期間を確保できるようにしましょう。

予算要求の対象範囲を早期に決める

【標準ガイドライン関連箇所:第3編第3章全般】

情報システム関連の予算要求は、情報システム特有の専門的な言葉や知識が数多く登場するために難しい印象があると思います。また、情報システムの開発や運用を経験したことがない人にとっては、どのような経費がいつ必要になるかが理解しにくいと思います。

まずは、予算要求の前提となるプロジェクト計画書を丹念に読み直してみましょう。プロジェクト計画書には、予算要求の対象となる活動が、プロジェクト全体でどう位置づけられ、何を達成し、何の条件を守らないといけないかが書いてあります。これを理解して予算要求作業を進めることで、予算要求の内容が具体的になり、第三者にも理解しやすいものとなります。

では、具体的にどのようなポイントを踏まえ、何を行えばよいかを見ていきましょう。

プロジェクト計画書を再確認する

予算要求に当たっては、予算要求年度に必要となる経費だけに着眼してしまいがちですが、プロジェクト全体における「予算要求の全体像」を把握することが大切です。プロジェクトが進んでいく過程では、多様な作業が複雑に発生するため、どうしても目前に必要となる作業だけに気を取られることになりがちです。

特に重点的に確認すべき点を、次に示します。

プロジェクト計画書を再確認する際に気をつける点

  • プロジェクトの目標達成への充足性 プロジェクトの目標を達成することを念頭に、実現するサービス・業務を俯瞰し
  • 注記

リモートとは、固定された場所(自席等)のみではなく、自席以外の会議室、外出先、自宅等のから、職務遂行に必要なサーバへのアクセス、メール受信等をすること。

た視点から、必要な作業や経費の漏れがないかを確認します。 例えば、職員の働き方を改善することを目的に持ち運び可能なPCを導入するのであれば、PCを導入するだけで通常と同様の業務をリモート環境でも実施できるかを考える必要があります。場合によっては、業務に必要となる紙書類を電子化して参照できるようにしたり、利用頻度の高い情報システムをリモートからでも操作できるように変更したりすることが、併せて必要かもしれません。 情報システムを導入することを目的としないように、目指す姿を実現するために必要なことが何か、プロジェクト全体を見渡してもう一度確認してみましょう。

  • プロジェクトの方向性の確実性 現状分析や検討が十分に行えていない段階でプロジェクトが立ち上がった場合は、担当者の経験や推測に基づいてプロジェクトの方向性を定めた状態となっていることが多いでしょう。このような状態からすぐに情報システムの開発に着手すると、十分な効果を得られない可能性があります。 情報システムの開発や改修のために多額の予算を確保する前に、詳細な現状分析に基づいたサービス・業務企画を実施し、プロジェクトの方向性を検証、改善するための予算を確保することが重要です。

  • スケジュールとの整合性 プロジェクトの全期間にわたって、必要となる作業の内容、開始時期と終了時期を確認します。特に、作業間で順序関係があるものには注意が必要です。 例えば、情報システムの新規開発を行う際には、遅くともテストを実施する時期までに情報システムが動作する環境が必要です。この環境を構築するためには、事前にサーバやネットワーク機器等のハードウェアを調達することが必要です。また、サーバ等の機器を設置する場所(データセンター)や通信回線については、さらにその前から準備する必要があります。このように、必要となる作業を並べてみながら順序関係を整理し、抜け漏れがないかを確認することが重要です。

  • 役割分担の網羅性 関係者が多いプロジェクトでは、予算要求に先立って、関連する部門の役割分担について綿密に調整することが重要です。設計・開発工程では、情報システム連携、データ移行、テスト等の役割分担、運用工程では障害時対応、利用者からの問合せ対応等については、特に役割分担の観点から問題になりがちです。プロジェクト計画書やプロジェクト管理要領に記載した体制やステークホルダーを再確認し、予算要求の前提となる基本的な役割分担が決まっていて、予算要求に漏れがないことを確認しましょう。

なお、以下のようにスケジュール表の形で計画を可視化し、各年度で必要となる経費を一覧でまとめておくと、次年度以降の経費項目の要求漏れの防止に効果的です。

  • 図3-2

予算要求から漏れがちな項目を理解する

情報システムを構築する際に、主要な作業経費(設計・開発経費やハードウェア関連経費等)が漏れることはまずありませんが、付随する作業経費については予算要求時点で漏れる可能性があります。

特に、次のような項目については漏れることが比較的多いので、注意してください。

  • 表3-2

見積項目の漏れがちな項目

関係者との役割分担は早期に確認

予算要求に当たって、他プロジェクトにも影響がある場合は、可能な限り早期にその状況を伝えましょう。最初の一報を入れる際には、影響の詳細がわかっていなくても構いません。法改正への対応等が典型的な例ですが、影響範囲が確実に判明する時期まで待っていると、他プロジェクトへ連絡する時期がとても遅くなってしまいます。影響が発生する可能性を把握した段階でまず一報を入れ、その後に影響範囲が具体的に見えた段階で続報を入れるといった段階的な伝達を行うことで、影響を受ける側のプロジェクトにとっても十分な検討期間を確保することができます。

また、予算要求を行う時期までには、それぞれのプロジェクト間で対応方法に関する役割分担を決めましょう。役割分担が不明確なままでは、双方のプロジェクトが必要以上に作業範囲のリスクバッファを積む形となり、結果的に過大な予算要求内容となってしまうためです。

  • 注記

    第二期政府共通プラットフォームにおけるクラウドサービスの調達とその契約に係る報告書

    https://cio.go.jp/node/2703

  • 事例3-1

    第二期政府共通プラットフォームにおけるクラウドサービスの調達

  • 注記

    「第二期政府共通プラットフォームにおけるクラウドサービスの調達とその契約に係る報告書(概要)」内の図「契約方式のイメージ比較」を基に作成

    https://cio.go.jp/node/2702

コスト削減の検討

【標準ガイドライン関連箇所:第3編第3章第4節】

既に情報システムが導入されている場合は、見積りを依頼する前に、まず現状の情報システムのコストを削減する余地がないかチェックしてみましょう。

また、新規に情報システムを導入する際も、これから予算要求を行う対象に無駄がないかチェックしてみてください。

ハードウェア・ソフトウェアのコスト削減観点

  • 表3-3

ハードウェア・ソフトウェアのコスト削減観点

  • 事例3-2

全面的にハードウェア等の構成を見直し運用コストを削減

アプリケーションのコスト削減観点

  • 表3-4

アプリケーションのコスト削減観点

運用業務のコスト削減観点

  • 表3-5

運用業務のコスト削減観点

  • 注記

    MSP(マネージドサービスプロバイダ)とは、クラウドサービスの開発や提供に深い専門知識を有することを認定された事業者が提供する運用サービスである。リモートでの運用が前提となるが、複数のシステムを同時に運用するため、効率的な運用サービスの提供が期待できる。

その他のコスト削減観点

  • 表3-6

その他のコスト削減観点

  • 事例3-3

第三者保守等を活用したハードウェア保守費用の削減等

  • 事例3-4

PCの保守形態の変更