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

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

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

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

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

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

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

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

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

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

図3-1

表3-1

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

① 特殊要因登録	特殊要因とは、一時的に大きく増える義務的な経費をあらかじめ財務省に登録することです。例年４月頃に登録し、６月頃まで調整して決定されます。ただし、認められるには財務省の審査があり、高いハードルを超える必要があります。特殊要因分の金額と通常の概算要求の金額を区別しなければなりませんので、ＰＭＯは財務省との調整結果をデジタル庁に報告する必要があります。
② 概算要求内容整理	ＰＪＭＯは、予算要求に必要な資料の準備を進め、デジタル庁またはＰＭＯからの指示内容に従って資料を完成させます。この間には、事業者との対話を経て事業者から提出される見積りの精査等も行います。一括計上対象システムについては、ＰＭＯはデジタル庁からの指示に基づき金額の調整を行い、概算要求額を決定します。一括計上対象外システムについては、各府省の予算担当（会計課等）にて調整を行います。なお、概算要求以後に、追加要求はできません。
③ 確認・助言	ＰＭＯが①特殊要因登録や②概算要求内容整理を行うにあたり、悩んだり困ったりすることがあれば、当該案件の内容を踏まえ、必要に応じてデジタル庁へ相談することができます。デジタル庁は、ＰＭＯから相談を受けた内容について、政策的観点・技術的観点・費用対効果の観点から確認や助言を行うことで、ＰＭＯの取組を支援します。
④ 最終調整	概算要求基準を基に予算額の調整を行います。一括計上対象システムについてはデジタル庁にて、一括計上以外のシステムについては、ＰＭＯ及び会計課等にて調整を行い、概算要求額をとりまとめ財務省に提出します。
⑤ 予算編成・ヒアリング等対応	財務省は、提出された概算要求に基づきヒアリングを実施します。「要求ヒアリング→宿題対応」を繰り返すことになりますが、回答期間の短い作業もありますので、迅速に対応できるようにしておく必要があります。
⑥ 省庁各担当間等調整	デジタル庁は必要に応じて財務省との間で調整を行います。また、各ＰＭＯや各ＰＪＭＯとの間で必要に応じて調整を行います。デジタル庁は情報システム関係予算の概算決定額をとりまとめます。
⑦ 補正予算	補正予算編成がある場合には、上記②～⑥までの作業を１か月程度の短い期間で行います。そのため、あらかじめ補正予算に相応しい内容について検討しておくことが必要です。

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

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

予算要求の対象の特定 後述する「予算要求から漏れがちな項目」にも注意しながら、予算要求の対象となる項目をピックアップします。また、情報システムの機能に影響がありそうな制度改正の動向や、情報システムの構成に影響がありそうな技術動向等、予算要求の前提となる背景事象については、事前調査も必要となるので、そのための期間を確保します。
当然増減額の整理 当年度限りの経費（当然減）は翌年度予算では計上する必要がなくなります。逆に当年度の途中から運用開始をして、予算上数箇月分しか計上されていないもの（平年度化増）については、翌年度に１２か月分必要となりますので、自動的に増えることになります。このような、自動的に増減するような経費をあらかじめ特定して、基礎的な金額を把握しておきます。
*経費の見積り* 予算要求額の前提となるための見積りを取得します。見積り対象の規模にもよりますが、事業者に見積り依頼を行ってから見積りを受領するまでには、数週間必要になることが一般的です。また、見積り依頼のプロセスは１回で完結するわけではありません。事業者から提示を受けた見積り内容について、対象範囲や積算根拠を確認し、場合によっては前提条件を変更した上で再見積りを依頼することもあります。見積り取得後にこのような精査を含めることも考慮して、経費の見積りに十分な期間を確保しましょう。
資料の準備 予算要求の全体がわかる資料、業務説明資料等を作成します。特に、新規に情報システムを整備する際には、資料の準備には数箇月にわたって十分な期間を確保することが必要です（大規模な情報システムを新規に構築する場合は、サービス・業務企画の期間を含めて数年をかけることもあります）。予算要求の内容に応じて、十分な期間を確保できるようにしましょう。

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

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

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

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

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

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

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

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

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

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

注記

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

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

プロジェクトの方向性の確実性 現状分析や検討が十分に行えていない段階でプロジェクトが立ち上がった場合は、担当者の経験や推測に基づいてプロジェクトの方向性を定めた状態となっていることが多いでしょう。このような状態からすぐに情報システムの開発に着手すると、十分な効果を得られない可能性があります。情報システムの開発や改修のために多額の予算を確保する前に、詳細な現状分析に基づいたサービス・業務企画を実施し、プロジェクトの方向性を検証、改善するための予算を確保することが重要です。
スケジュールとの整合性 プロジェクトの全期間にわたって、必要となる作業の内容、開始時期と終了時期を確認します。特に、作業間で順序関係があるものには注意が必要です。例えば、情報システムの新規開発を行う際には、遅くともテストを実施する時期までに情報システムが動作する環境が必要です。この環境を構築するためには、事前にサーバやネットワーク機器等のハードウェアを調達することが必要です。また、サーバ等の機器を設置する場所（データセンター）や通信回線については、さらにその前から準備する必要があります。このように、必要となる作業を並べてみながら順序関係を整理し、抜け漏れがないかを確認することが重要です。
役割分担の網羅性 関係者が多いプロジェクトでは、予算要求に先立って、関連する部門の役割分担について綿密に調整することが重要です。設計・開発工程では、情報システム連携、データ移行、テスト等の役割分担、運用工程では障害時対応、利用者からの問合せ対応等については、特に役割分担の観点から問題になりがちです。プロジェクト計画書やプロジェクト管理要領に記載した体制やステークホルダーを再確認し、予算要求の前提となる基本的な役割分担が決まっていて、予算要求に漏れがないことを確認しましょう。

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

図3-2

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

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

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

表3-2

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

経費項目	留意点
データ移行	新規で情報システムを構築するに際し、既存の情報システムがある場合は、データ移行が発生します。データ移行は、新規情報システムの構築事業者だけで完結することは難しく、既存情報システムからのデータ抽出等については、既存情報システムの保守運用を行っている事業者と共同で作業を実施することが一般的です。既存事業者側の必要作業について予算要求を漏らさないようにしましょう。また、データ移行に際して、データ形式の変換用のプログラムが必要となるケースもありますし、既存データの修正（データのクレンジング等）や、データ化されていないデータの電子化（パンチ入力作業等）が必要になることもあります。データ移行の作業後も、テスト工程の中で新旧の処理結果比較を行ったり、新旧情報システムの並行稼働を行いながら最新のデータを移行（差分連携）することも必要になったりします。これらの作業が、予算要求内容に含まれていることを確認しましょう。さらに、既存情報システムから新規情報システムへの移行に伴い、クラウドサービスの場合は、既存情報システムのデータの抽出自体に費用がかかることに留意が必要です。データ移行が伴う情報システムの構築では、既存情報システムの運用・保守事業者のデータ抽出にかかる費用について予算要求を漏らさないようにしましょう。なお、既存の情報システムが存在しない新規開発においても、他の情報システムからデータを連携するケースでは初期データの投入が発生する場合もあるため、留意が必要です。
他システム連携	他の情報システムと連携が発生する場合、対向となる情報システム側の予算も検討する必要があります。反対に、対向の情報システムに変更が入る場合も同様に検討が必要となります。これらは、情報システムに係る変更だけでなく、テスト・移行が含まれることにも留意が必要です。特に連携テストについては、テストを実施する環境（本番環境ではなくテスト用の環境を双方の情報システムが準備する等）、テストに用いるデータ（本番データに相当するテストデータで重要部分のみマスキングする等）、テスト種類（異常系テスト、負荷テスト等を含めた実施範囲）、テスト実施方法（スケジュールや体制等）について、事前に十分に調整が行えずにテスト実施時期に問題となるケースがあるため、関係する情報システムの担当者と事前に調整を行いましょう。
システム操作研修	情報システムの新規構築時や大幅な変更を行う場合、職員向けの操作研修の検討が必要となります。利用者の量や拠点数等により、場所・移動費・人件費等が大きく変動するため留意が必要です。多数の利用者がいる場合は、利用者が自学自習できるようなｅラーニング環境を整える、操作研修の模様を撮影して配布する等、操作研修を直接受講できない利用者への対応方法も工夫しましょう。
マニュアル作成	一般的なプロジェクトでは、次の３種類のマニュアルを作成します。・業務マニュアル（職員向け）業務全体を対象に実施方法や注意点を記載するもの・情報システムの操作マニュアル（利用者向け）情報システムの利用者（職員を含む）向けに、操作方法を説明するもの・情報システムの運用マニュアル（管理者向け）情報システムの運用者（職員、事業者）向けに運用方法を説明するもの特に、新規のサービスや業務内容が大きく変わる場合、業務マニュアルの作成・更新は必要不可欠であり、効果指標の達成に対しても大きな影響を与えます。
運用計画作成	情報システムの運用に関する経費は、運用する段階で予算要求すればよいと考えがちです。しかし、実際には設計・開発を行う時点で同時並行的に運用計画を作成し、質の高い運用業務を実施できるように情報システムの設計内容に反映するとともに、運用体制を確立するための準備を進めます。運用計画は、効果指標のモニタリングを適切に行うためにも重要です。日々の運用業務を行うなかで、情報システムが利用者に使われているか、利用者に役立つ効果を達成できているかを定期的に把握するため、各種ログや主要統計指標を分析できるように考慮しましょう。
引継ぎ	プロジェクトに関係する事業者との契約が切り替わる際には、事業者間での引継ぎが必要になります。例えば、設計・開発事業者から運用事業者への引継ぎでは、設計・開発工程で作成した運用計画や手順書の内容を引き継ぎます。引継ぎをスムーズに行うためには、現行の運用事業者から新規の運用事業者への引継ぎにおいて、運用手順等の内容に加えて、過去に発生した課題と対応方法、過去の経験から判明した注意すべき点などについて、具体的な内容を引き継ぐことが有効です。また、設計・開発事業者と運用事業者の契約期間の設定を工夫する方法があります。（実践ガイドブック第3編第7章　Step6-2　事例：異なる事業者間で引継ぎをスムーズに行う工夫　参照）引継ぎへの対応は、引継ぎを行う側の事業者にも、引継ぎを受ける側の事業者にも必要です。予算要求の時点で、検討漏れがないか注意しましょう。
サポート終了対応	情報システムを構成するハードウェア、ソフトウェア等の製品には、製品供給元からのサポートサービスの提供期限が定められていることが一般的です。特に、各種ソフトウェア（ＯＳ、ブラウザ、アプリケーションサーバ用のミドルウェア、データベースサーバ用のミドルウェア等）については、バージョン別に細かくサポートポリシーが設定されており、注意が必要です。サポートが切れた製品の利用を継続すると、当該製品に対するセキュリティ脆弱性等の問題が発生した際に製品供給元からの対応が行われない可能性があります。そのため、原則として、サポートが終了するまでに後継製品を導入する等の対応をとってください。

経費項目

留意点

データ移行

新規で情報システムを構築するに際し、既存の情報システムがある場合は、データ移行が発生します。データ移行は、新規情報システムの構築事業者だけで完結することは難しく、既存情報システムからのデータ抽出等については、既存情報システムの保守運用を行っている事業者と共同で作業を実施することが一般的です。既存事業者側の必要作業について予算要求を漏らさないようにしましょう。

また、データ移行に際して、データ形式の変換用のプログラムが必要となるケースもありますし、既存データの修正（データのクレンジング等）や、データ化されていないデータの電子化（パンチ入力作業等）が必要になることもあります。データ移行の作業後も、テスト工程の中で新旧の処理結果比較を行ったり、新旧情報システムの並行稼働を行いながら最新のデータを移行（差分連携）することも必要になったりします。これらの作業が、予算要求内容に含まれていることを確認しましょう。

さらに、既存情報システムから新規情報システムへの移行に伴い、クラウドサービスの場合は、既存情報システムのデータの抽出自体に費用がかかることに留意が必要です。データ移行が伴う情報システムの構築では、既存情報システムの運用・保守事業者のデータ抽出にかかる費用について予算要求を漏らさないようにしましょう。

なお、既存の情報システムが存在しない新規開発においても、他の情報システムからデータを連携するケースでは初期データの投入が発生する場合もあるため、留意が必要です。

他システム連携

他の情報システムと連携が発生する場合、対向となる情報システム側の予算も検討する必要があります。反対に、対向の情報システムに変更が入る場合も同様に検討が必要となります。

これらは、情報システムに係る変更だけでなく、テスト・移行が含まれることにも留意が必要です。特に連携テストについては、テストを実施する環境（本番環境ではなくテスト用の環境を双方の情報システムが準備する等）、テストに用いるデータ（本番データに相当するテストデータで重要部分のみマスキングする等）、テスト種類（異常系テスト、負荷テスト等を含めた実施範囲）、テスト実施方法（スケジュールや体制等）について、事前に十分に調整が行えずにテスト実施時期に問題となるケースがあるため、関係する情報システムの担当者と事前に調整を行いましょう。

システム

操作研修

情報システムの新規構築時や大幅な変更を行う場合、職員向けの操作研修の検討が必要となります。利用者の量や拠点数等により、場所・移動費・人件費等が大きく変動するため留意が必要です。

多数の利用者がいる場合は、利用者が自学自習できるようなｅラーニング環境を整える、操作研修の模様を撮影して配布する等、操作研修を直接受講できない利用者への対応方法も工夫しましょう。

マニュアル作成

一般的なプロジェクトでは、次の３種類のマニュアルを作成します。

・業務マニュアル（職員向け）

業務全体を対象に実施方法や注意点を記載するもの

・情報システムの操作マニュアル（利用者向け）

情報システムの利用者（職員を含む）向けに、操作方法を説明するもの

・情報システムの運用マニュアル（管理者向け）

情報システムの運用者（職員、事業者）向けに運用方法を説明するもの

特に、新規のサービスや業務内容が大きく変わる場合、業務マニュアルの作成・更新は必要不可欠であり、効果指標の達成に対しても大きな影響を与えます。

運用計画作成

情報システムの運用に関する経費は、運用する段階で予算要求すればよいと考えがちです。しかし、実際には設計・開発を行う時点で同時並行的に運用計画を作成し、質の高い運用業務を実施できるように情報システムの設計内容に反映するとともに、運用体制を確立するための準備を進めます。

運用計画は、効果指標のモニタリングを適切に行うためにも重要です。日々の運用業務を行うなかで、情報システムが利用者に使われているか、利用者に役立つ効果を達成できているかを定期的に把握するため、各種ログや主要統計指標を分析できるように考慮しましょう。

引継ぎ

プロジェクトに関係する事業者との契約が切り替わる際には、事業者間での引継ぎが必要になります。例えば、設計・開発事業者から運用事業者への引継ぎでは、設計・開発工程で作成した運用計画や手順書の内容を引き継ぎます。

引継ぎをスムーズに行うためには、現行の運用事業者から新規の運用事業者への引継ぎにおいて、運用手順等の内容に加えて、過去に発生した課題と対応方法、過去の経験から判明した注意すべき点などについて、具体的な内容を引き継ぐことが有効です。また、設計・開発事業者と運用事業者の契約期間の設定を工夫する方法があります。（実践ガイドブック第3編第7章　Step6-2　事例：異なる事業者間で引継ぎをスムーズに行う工夫　参照）

引継ぎへの対応は、引継ぎを行う側の事業者にも、引継ぎを受ける側の事業者にも必要です。予算要求の時点で、検討漏れがないか注意しましょう。

サポート

終了対応

情報システムを構成するハードウェア、ソフトウェア等の製品には、製品供給元からのサポートサービスの提供期限が定められていることが一般的です。特に、各種ソフトウェア（ＯＳ、ブラウザ、アプリケーションサーバ用のミドルウェア、データベースサーバ用のミドルウェア等）については、バージョン別に細かくサポートポリシーが設定されており、注意が必要です。

サポートが切れた製品の利用を継続すると、当該製品に対するセキュリティ脆弱性等の問題が発生した際に製品供給元からの対応が行われない可能性があります。そのため、原則として、サポートが終了するまでに後継製品を導入する等の対応をとってください。

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

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

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

注記

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

https://cio.go.jp/node/2703
事例3-1

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

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

クラウドサービスの調達・契約にはどのような方法があるのでしょうか。

現時点では、アプリケーションの設計・開発、クラウドサービスの利用、それらの運用・保守等を一括で委託し、その総額を固定した形で契約するケースが多くなっています。

一方で、第二期政府共通プラットフォームでは、クラウドサービスの利用分を実績額で支払うという従量課金の形態で契約を行っています。その詳細については、「第二期政府共通プラットフォームにおけるクラウドサービス調達とその契約に係る報告書」の中で、今後のクラウドサービスの調達・契約を検討する際に参考とできるように、本調達の検討過程で議論された論点や留意点を記載しています。以下でその一部をご紹介します。

また、実践ガイドブック「Step.3-5.事例：クラウドサービスの見積りの精査」では、クラウドサービスの見積りを精査する上での参考を掲載しているので、本事例と併せてご確認ください。

・直接契約／間接契約の検討

クラウドサービスの契約方法については、クラウドサービス提供者との直接契約と中間事業者^※を介してクラウドサービスの提供を受ける間接契約を検討しました。（※クラウドサービス提供者が提供するクラウドサービスに関する契約行為、支払行為等のすべてを代行する事業者のことです。）

![](../assets/ds-120-ch03-image3.png)

直接契約のメリットとして、当該クラウドサービスの提供に不具合が発生した場合に、原因追及や対処方法等が早く提供されることや、コスト面において中間マージンが発生しないことが考えられます。しかし、調達プロセスを経て直接契約を締結するためには、クラウドサービス提供者特有の契約の考え方や事務処理について課題があり、令和２年度においては採用できないと判断しました。

・従量課金（単価契約）の検討

利用料金の観点については、利用した分だけ支払うという従量課金を実現できる契約方法を検討しました。

国の契約においては、総額をもって契約する総価契約が原則ですが、特例として、単価契約が認められています。単価契約とは、契約上の数量が確定できないものについて、単価を契約の主目的とし、期間を定めてその供給を受けた実績数量を乗じて得た金額の代価を支払うことができる契約形態です。

クラウドサービスの調達におけるコストメリットの達成方法の一つは、従量課金による契約であり、政府共通プラットフォームにおいては、従量課金のメリットを最大限活かすために単価契約の契約形態としました。

ここまで第二期政府共通プラットフォームにおける調達・契約の論点の一部を紹介しましたが、採用するクラウドサービスやシステム規模などの違いによって、適切な調達・契約が異なるため、各システムの実情に合った検討が必要です。例えばクラウドサービスで従量課金（単価契約）を採用する場合、アプリ部分とインフラ部分とで契約が分かれることで煩雑になることもあります。また、第二期政府共通プラットフォームでは今後の利用システムの増加に柔軟に対応することなどを考慮して、単年度で間接契約を継続する形としています。一方で、クラウドサービスの中には複数年予約型割引を適用することで、安価にできるケースもあります。

このように契約方式や契約期間等について、様々な観点から比較・検討することが必要です。

注記

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

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

３コスト削減の検討

【標準ガイドライン関連箇所：第３編第３章第４節】

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

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

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

表3-3

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

削減観点		留意点
A1	サーバの統合や削減	サーバの全体構成や使用率、ピーク特性等を把握した上で、サーバの統合や削減等を行う。
A2	端末の統合や削減	端末の全体構成、使用率、ピーク特性等を把握した上で、不要な端末削除や同一端末への機能集約を行う。
A3	専用機器の標準機器へのリプレース	特定の情報システムのみで利用可能な専用端末、専用プリンタ及び専用通信機器などの機器類を、一般に市場で調達可能な標準製品にリプレースする。
A4	周辺機器の削減・機種統一等	プリンタ等の周辺機器について、使用率、ピーク特性等を把握した上で不要な機器の削除、機種統一等を行う。
A5	システムアーキテクチャの変更	メインフレーム型のシステムアーキテクチャを刷新し、 Web サーバ型などに変更する。
A6	ソフトウェアの集約や削減	サーバや端末等における市販ソフトウェアの利用状況を調査し、ライセンス数の見直し等を行う。
A7	オープンソースソフトウェアの活用	オープンソースソフトウェアへの代替可能性を検討し、ソフトウェア利用に要するコストを削減する。
A8	ハードウェア・ソフトウェアの保守条件の見直し	保守時間帯、保守実施方法等の条件を見直し、過剰な条件を修正することで保守費用を削減する。
A9	機器やソフトウェア単位での保守対象等の見直し	保守費用／借料の比率確認、細かな構成機器に対する保守の見直し、予備機のハードディスクへの保守の見直し、業務利用しないソフトウェアの保守の見直し等を行う。
A10	契約方法の見直し	長期にわたってレンタル契約を締結している場合に、買取り又はリース契約等への変更を行い、全体経費を削減する。
A11	クラウドサービスへの移行	クラウドサービスの特性を十分に理解し、業務改革（BPR）やアーキテクチャの見直し等を行いつつクラウドサービスへの移行を行う。
A12	クラウドサービスの課金プランの見直し	クラウドサービスの料金体系は、サーバ等の稼働時間に応じた従量課金が基本となるため課金プランの見直しを行う。
A13	マネージドサービスの活用	クラウドサービスが提供するマネージドサービスの活用により、ミドルウェア等の運用・保守に要していたコストの削減を行う。
A14	クラウドサービスが標準提供するサービスの活用	クラウドサービスが標準提供するサービスを活用することにより運用管理やセキュリティ対策に関するコスト削減を行う。

事例3-2

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

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

あるプロジェクトでは、全国に存在する多数の業務拠点ごとに拠点サーバを配置し、中央のデータセンターには本番環境以外にも本番環境とほぼ同じ構成の環境を複数用意するなど、多数のハードウェアに多額の投資を行っていました。

しかし、実際にハードウェアの使用状況（ＣＰＵ使用率等）を詳細に確認してみると、サーバを廃止、集約したり、データセンターやネットワークを見直したり、大きく改善の余地があることが判明したため、全面的な構成見直しを行うこととしました。

また、サーバ構成の見直し等は次期更新時まで待つ必要がありましたが、すぐに取り組める改善事項として一部の不要機器を即時撤去することで保守費を削減したり、新規機器を導入予定であった部分に不要機器を転用したりといった工夫も行いました。

「すぐにできる改善」と「次期更新時の改善」の両方の観点から、総合的に取組を行った結果、大幅な運用コスト削減を実現することができました。

![](../assets/ds-120-ch03-image4.png)

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

表3-4

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

削減観点		留意点
B1	保守実績の把握による工数精査	アプリケーション保守に関する作業実績を確認し、必要に応じて工数や生産性を見直す。
B2	利用頻度の低いアプリケーションプログラムの廃止	アプリケーションの機能単位等で利用状況を調べ、利用頻度の低いアプリケーションプログラムを廃止する。
B3	システム管理対象データのスリム化	保存期限を超えたデータを削除する、媒体に退避する等の対策により、管理対象データをスリム化する。
B4	アプリケーションプログラムの保守条件の見直し	保守時間帯、保守実施方法等の条件を見直し、過剰な条件を修正することで保守費用を削減する。
B5	保守作業の効率化	テスト工程の手順や環境の見直し、ＯＳバージョンアップ対応の効率化等の工夫により、保守作業を効率化する。
B6	保守開発プロセスの自動化	運用期間中、アプリケーションプログラムの改修作業を頻繁に行う必要のあるシステムにおいては、保守開発プロセスを自動化することにより保守工数を削減する。

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

表3-5

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

削減観点		留意点
C1	運用実績の把握による工数精査	運用に関する作業実績を確認し、必要に応じて工数や生産性を見直す。
C2	運用業務の効率化、一元化	複数情報システムでの運用一元化や、オペレータの集約等、各種作業の見直し等により、運用業務の効率性を高める。
C3	運用作業のピーク平準化	リリース作業、帳票印刷、データ入力等の業務ピーク特性を把握し、運用作業のピークを平準化することで運用業務全体の工数を削減する。
C4	冗長化・ＢＣＰ対策の適正化	東日本大震災以降、各府省の業務システムのバックアップ体制の充実が図られたが、冗長化・ＢＣＰ対策が過剰と思われるケースも散見されるので、可用性要件とコストの実態を把握し、適正化を検討する。
C5	ヘルプデスクの契約形態の見直し	問合せ件数に応じた従量課金型のヘルプデスクを採用する、または他の複数システムとヘルプデスクを統合することで総コストを削減する。
C6	リモート運用の採用	システムの特性上、必ずしも常駐である必要がない場合は、常駐体制の見直しを検討する。また、クラウドサービスを活用している場合は、常駐体制と比べ、より効率的に低コストで運用支援を受けられる可能性のあるMSP（マネージドサービスプロバイダ）の活用を検討する。

注記

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

D. その他のコスト削減観点

表3-6

その他のコスト削減観点

削減観点		留意点
D1	サービス内容の見直し	ASP、SaaS、PaaS、ホスティングサービス等について、利用実績等を勘案してサービスの必要範囲を見直す。
D2	ネットワークの統合や見直し	ネットワークの全体構成や使用率、ピーク特性等を把握した上で、ネットワークの統合や削減等を行う。
D3	ネットワークの保守条件の見直し	保守時間帯、保守実施方法等の条件を見直し、過剰な条件を修正することで保守費用を削減する。
D4	データセンターの統合や条件見直し	複数データセンターの集約等を検討し、データセンターへの経費を削減する。
D5	関連経費の見直し	研修、ヘルプデスク、コールセンター、監査、情報セキュリティ検査等について、実施回数、実施内容、実績等を勘案して範囲を見直す。

事例3-3

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

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

あるプロジェクトでは、50台弱の物理サーバを持つ業務系情報システムのハードウェア/ソフトウェア製品について、第三者保守等を活用し、保守費用の削減等を実現しました。

＜第三者保守の活用＞

第三者保守とは、メーカーによる直接的な保守サービスではなく、メーカー以外の第三者が保守サービスを提供する形態です。海外では導入事例も増えており、日本国内でも第三者保守サービスの調達が可能なことが判明したため、その利用を検討しました。

複数の第三者保守ベンダーに対象機器リストを提示して保守料の簡易見積りを依頼したところ、サーバやネットワーク機器等の汎用的な製品については、従来の保守金額と比べて、安価に保守サービスを受けられることがわかりました。一方で、一部の機器については第三者からの保守サービス提供が難しいことが判明しました。（注意点として後述）

また、費用面だけでなく保守条件についても検討した結果、当該プロジェクトにおいては、従来のSLAと同等なサービスを維持できることを確認しました。

上記のことから、当該プロジェクトにおいて第三者保守を活用することとした結果、システム更改のサイクルの長期化と保守費用の削減を実現することができました。

（注意点）　

　第三者保守を活用する際には、以下のような点について、注意が必要です。

①第三者保守は中古市場から保守部品を調達するため、シェアの低い製品や特殊な機器等は対応ができません。

②第三者保守は新製品には対応できないため、最初の数年はメーカー保守が必要です。

③メーカー直接保守に比べて、修理時間の拡大とシステム稼働率の低下が発生する可能性があるため、リスクの検討を行った上でSLAの見直しが必要になる場合があります。

＜調達におけるその他の工夫＞

当該プロジェクトでは、従前、ハードウェアのメーカーも様々であるため、保守を全体管理する請負事業者に一括で委託し、サポート窓口となる事業者経由で各メーカーの保守サービスを受けていました。

今般、第三者保守を採用するにあたり、調達単位を見直し、第三者保守サービス、メーカー直接保守（定額保守）、メーカー直接保守（オンコール保守）の３つの契約形態に分割して調達を行う工夫をした結果、保守経費を従来よりも削減することができました。

なお、この場合においては、保守契約を複数に分割しているため、障害発生時の一次切り分け（障害機器の特定）を発注側で行う必要があることに注意が必要です。

![](../assets/ds-120-ch03-image5.png)

事例3-4

PCの保守形態の変更

事例：PCの保守形態の変更

府省のLANシステムでは、多くのPCを導入しています。また、個別の情報システムでも専用のPCを導入しているものもあるでしょう。これらのPCの保守はどのような形態で行っているでしょうか。

あるプロジェクトでは、PCについて年単位での定額保守契約を行っていました。

定額保守といっても、全ての事象について契約金額内で修理できるわけではありません。PC自体に衝撃を加えてしまった場合、飲み物をこぼしてしまった場合等でディスプレイ交換や基盤ボード交換に至るケースがありますが、利用者側の過失による故障については基本的に定額保守契約を結んでいたとしても、修理内容に応じて追加料金が必要となります。

そのような事情も勘案した上で、どういった保守形態が適切かを検討するために、直近３年間のPCの故障実績を調べてみました。

実績を調査した結果まずわかったことは、故障件数が多いのは導入１年目であり、しかもこれらの故障は１年間のメーカー無償保証でカバーされる初期不良が多いということでした。

ついで、導入2年目以降は修理に追加料金が必要な故障が多く定額保守契約の範囲で対応可能な故障が実はあまり多くないということでした。

以上の調査結果から、定額保守契約を結んだ上で修理内容に応じて追加料金を支払う場合と、定額保守契約は結ばずに導入１年目のメーカー無償保証とスポット保守（PCの故障の都度に有償で対応依頼）を併用する場合の料金を比較してみると、定額保守契約と追加料金の合計金額よりも、１年目のメーカー無償保証とスポット保守を併用する場合の合計金額のほうが、低くなることがわかりました。

![](../assets/ds-120-ch03-image6.png)

この比較結果を踏まえて、翌年度からは定額保守契約を結ぶよりも、実績に基づいた保守の予算要求を行った上でスポット保守に切り替えることとしました。

また、業務の継続性を確保するため、修理の間もユーザの業務に支障がでないよう実績に基づいて故障率を算出し、必要な台数の代替（予備）機をあらかじめ調達しておきました。

なお、予算要求についてはこの実績資料を根拠として想定される修理金額と代替機の金額を算定し、単年度で要求する形としました。

機器の故障のような予測しにくい出来事については、何が起きても対応できるように「定額」、「フルサポート」のようなサービスを選んでしまいがちです。しかし、そのようなサービスは必要以上にコストがかかってしまいます。実績を調べた上で、業務の継続性を確保しつつ、サービスを適切な水準に見直すことがとても重要です。