第3章 予算要求

デジタル・ガバメント推進標準ガイドライン

実践ガイドブック

(第3編第3章 予算要求)


第3章 予算要求

目次

Step.1 予算要求の活動の全体の流れ

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

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

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

B. 予算要求に向けた作業計画を立てる

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

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

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

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

3 コスト削減の検討

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

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

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

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

Step.3 予算要求に必要な資料の準備

1 全体像と要点の明確化

2 予算要求に必要な資料の作り方

A. 作成する資料の一覧

B. 「サービス・業務の説明資料」の作成ポイント

C. 「予算要求の概要」の作成ポイント

Step.4 見積り依頼

1 見積り依頼書の作成

A. 要件が未確定な部分を明確にする

B. プロジェクトの状況によって内訳粒度を変える

C. 見積りフォーマットを指定する

D. 工程の名称の違いをなくす.. 27

E. 見積り手法に注意する

F. できるだけ詳細な要件を書く

2 事業者への見積り依頼

A. 見積りしてくれる事業者を探す

B. 見積り事業者と対話して、発注者の意図を正しく伝える

Step.5 見積りの精査

1 人件費の見積り精査

A. 安易な掛け算の精査

B. 作業重複の精査

C. 主要成果物との比較

D. 開発生産性の精査

2 ハードウェア等の見積り精査

A. 製品単価を精査する

B. 高額な製品を中心に、必要性を精査し他製品と比較する

C. ソフトウェアライセンスを精査する

D. 保守料を精査する

3 複数事業者の見積りの比較

Step.6 予算を要求する

A. 府省内の確認

B. 府省外の確認

Step.7 予算要求後の対応

1 人事異動時は確実に引継ぎする

2 プロジェクト計画書に反映して最新化する


事例・参考の一覧

参考:予算要求時期とプロジェクト計画書策定時期との関係

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

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

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

参考:LOC法による工数見積り

参考:ファンクションポイント法(FP法)による工数見積り

参考:ハードウェア・ソフトウェア等の見積りの記載例

参考:三点見積りによる予算要求額の算出

事例:予算要求のプロセスでPMOと会計担当部門が密接に連携

事例:引継ぎ不足により、後日問題が顕在化した


Step.1 予算要求の活動の全体の流れ

予算要求には大変な作業という印象があるかもしれません。

少ない準備期間で付け焼刃的に予算要求を行った場合は、恐らく大変な作業となってしまうでしょう。そして、必要な予算を確保することに失敗することにもなりかねません。

しかし、予算要求時期までに計画的に準備作業を行うことができれば、予算要求に必要となる作業のハードルは、高いものではなくなるかもしれません。本章では、予算要求を計画的に進め、必要な時期までに、必要な検討を終えて、必要な資料を揃えるための方法について説明します。

本章の構成は、次のとおりです。

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

予算要求の直前に作業が集中したり、手戻り作業が発生したりすることがないように、予算要求を行う前に整理すべき検討事項や事前準備の内容について説明します。

Step.3 予算要求に必要な資料の準備

予算要求では、必要な経費を正確に把握するために事業者に見積りを依頼しますが、自分たちのやりたい事・見積もってほしい事をまとめて伝えるために、見積依頼資料を提示します。見積依頼資料とは、何を準備し、どのような点に気をつけて作ればよいのかを説明します。

Step.4 見積り依頼

情報システムの見積りには、やや専門的で見慣れない表現や内容が含まれることがあります。職員自身が見積りの内容を十分に理解しながら事業者から必要な情報を入手するための具体的な方法を説明します。

Step.5 見積りの精査

見積金額は、過少でも過大でも問題です。必要十分な金額水準とするために、事業者から受け取った見積りに対して内容の過不足を見つけ、より精度を高めるための作業について、その流れと注意点を説明します。

Step.6 予算を要求する

予算要求作業の流れでは、省内や省外の予算要求関係者に対して、予算の内容、必要性、金額妥当性等の説明を行うことが不可欠です。避けて通れない第3者による様々なチェックや調整で気をつけるべき注意点を説明します。情報システムに係る経費であればこその様々なチェックが入りますので、いつどんなチェックが入るのか、そのチェックをクリアしていくためのノウハウをお伝えします。

Step.7 予算要求後の対応

予算要求が完了したあとの処理について説明します。予算要求が終わりほっとしてしまうところですが、予算要求が通ってからがプロジェクトの実質的な始まりですので、プロジェクトの実務を計画的に進めるための準備作業を早めから行っておくことがポイントです。

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

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

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

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

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

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

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

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

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

まずは、予算要求の基本的なスケジュールを見てみましょう。省によって時期や内容に若干の異なりはありますが、おおむね次のようなスケジュールで活動を行います。

図3-1 情報システム関係予算の予算要求の年間スケジュール

図3-1 情報システム関係予算の予算要求の年間スケジュール



前年度 プロジェクト推進責任者から情報システムの導入や改修の検討指示を受け、PJMOは予算要求までに行う作業を計画して、当該予算要求の対象を特定します。その後、予算要求の前提となる資料の準備を開始します。
社会情勢の変化や法改正等があれば、情報システムにも影響が出ることが多くありますので、早めに動向を察知して、要件の検討や見積り依頼等の準備を進めます。
4 ~5月 府省の方針によりますが、情報システム関係予算の要求方法について、PMOが実施説明会を開催することもあります。説明会では、当該年度の予算要求スケジュール、作成する資料、作業上の注意点等を説明します。
PJMOは、予算要求に必要な資料の準備を進め、説明会の内容に従って資料を完成させます。この間には、事業者との対話を経て事業者から提出される見積りの精査等も行います。
6 ~7月 府省の方針によりますが、PJMOは、会計担当部門へ予算要求資料を提出する前にPMOによる事前ヒアリングを受けます。検討内容や資料内容が十分でなかった点については、改善を行います。
7 ~8月 PJMOは各省の会計担当部門へ予算要求資料を提出します。会計担当部門は、提出された予算要求を取りまとめ、調整し、8月末に概算要求として提出します。
9 各府省から提出された予算要求の内、情報システム整備に係る予算について、内閣官房IT室又は総務省行政管理局が確認を行います。
財務省は各府省に対して、提出された概算要求に基づきヒアリングを実施します。
12 月~ 予算の財務省原案を策定します。その後、政府内で予算案の最終調整を行い、閣議決定した予算案を国会へ提出します。国会審議を経て、衆参両院の可決により予算が成立します。

表3-1 予算要求の年間スケジュール


いつ頃どの作業を行うかを意識し、計画を立てて、十分な時間と期間を確保して進めれば、スムーズに作業を進めることができます。

B. 予算要求に向けた作業計画を立てる

前述のように、情報システム関係予算の要求には、府省内(PMO、会計担当部門)、府省外(内閣官房IT室又は総務省行政管理局)の関係組織が確認を行いますので、それぞれの提出スケジュールを踏まえて、作業の計画を立てましょう。

計画のスケジュールイメージを、以下に示します。

図3-2 予算要求の作業計画イメージ

図3-2 予算要求の作業計画イメージ


予算要求に向けた作業の概要

予算要求の対象の特定

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

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

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

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

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

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

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

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

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

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

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

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

プロジェクトの目標達成への充足性

プロジェクトの目標を達成することを念頭に、実現するサービス・業務を俯瞰した視点から、必要な作業や経費の漏れがないかを確認します。


例えば、職員の働き方を改善することを目的に持ち運び可能なPCを導入するのであれば、PCを導入するだけで通常と同様の業務をリモート環境でも実施できるかを考える必要があります。場合によっては、業務に必要となる紙書類を電子化して参照できるようにしたり、利用頻度の高い情報システムをリモートからでも操作できるように変更したりすることが、併せて必要かもしれません。(注記:リモートとは、固定された場所(自席等)のみではなく、自席以外の会議室、外出先、自宅等のから、職務遂行に必要なサーバへのアクセス、メール受信等をすること。)


情報システムを導入することを目的としないように、目指す姿を実現するために必要なことが何か、プロジェクト全体を見渡してもう一度確認してみましょう。

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

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

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

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

図3-3 予算要求スケジュールの例

図3-3 予算要求スケジュールの例


参考:予算要求時期とプロジェクト計画書策定時期との関係

通常のケースでは、まずプロジェクトを立ち上げ、プロジェクト計画書を作成し、現状把握、サービス・業務企画、要件定義等の内容について基本となる方針を決めた上で、必要となる予算について要求を行います。そのため、予算要求を行う前には、検討のための十分な期間と体制を確保する必要があります。

ただ、実際には様々な理由から急な予算要求をせざるを得ず、予算要求の時点ではプロジェクト計画書が未作成という状況も発生します。このような状況では、どのように対応すべきでしょうか。

基本的には、当該年度の予算要求を見送り、次年度以降に要求することを検討してください。計画と検討が不十分な状態で予算が決まってしまうプロジェクトは、多くの場合に「情報システムが使われない」、「現場の職員が苦労する」等の悲惨な結末を迎えてしまうからです。

しかし、時期的な問題から予算要求を見送ることが難しいこともあります。そのような場合は、例えば、プロジェクト計画書としてのドキュメントの整備は後回しにしたとしても、準備する予算要求資料の中でプロジェクト計画書等に相当する内容を具体的に組み込むといったやり方もあるかもしれません。ドキュメントとしての完成有無よりも、実質的な検討の有無が重要です。また、このような状況で対応方法について迷うことがあれば、PMOやCIO補佐官に相談してみましょう。


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

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

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



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

表3-2 見積項目の漏れがちな項目


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

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

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

3 コスト削減の検討

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

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

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

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

削減観点

留意点

A1 サーバの統合や削減 サーバの全体構成や使用率、ピーク特性等を把握した上で、サーバの統合や削減等を行う。
A2 端末の統合や削減 端末の全体構成、使用率、ピーク特性等を把握した上で、不要な端末削除や同一端末への機能集約を行う。
A3 専用機器の標準機器へのリプレース 特定の情報システムのみで利用可能な専用端末、専用プリンタ及び専用通信機器などの機器類を、一般に市場で調達可能な標準製品にリプレースする。
A4 周辺機器の削減・機種統一等 プリンタ等の周辺機器について、使用率、ピーク特性等を把握した上で不要な機器の削除、機種統一等を行う。
A5 システムアーキテクチャの変更 メインフレーム型のシステムアーキテクチャを刷新し、 Web サーバ型などに変更する。
A6 ソフトウェアの集約や削減 サーバや端末等における市販ソフトウェアの利用状況を調査し、ライセンス数の見直し等を行う。
A7 オープンソースソフトウェアの活用 オープンソースソフトウェアへの代替可能性を検討し、ソフトウェア利用に要するコストを削減する。
A8 ハードウェア・ソフトウェアの保守条件の見直し 保守時間帯、保守実施方法等の条件を見直し、過剰な条件を修正することで保守費用を削減する。
A9 機器やソフトウェア単位での保守対象等の見直し 保守費用/借料の比率確認、細かな構成機器に対する保守の見直し、予備機のハードディスクへの保守の見直し、業務利用しないソフトウェアの保守の見直し等を行う。
A10 レンタル契約の見直し 長期にわたってレンタル契約を締結している場合に、買取り又はリース契約等への変更を行い、全体経費を削減する。

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


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

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

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

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

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

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

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


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

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



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

削減観点 留意点
C1 運用実績の把握による工数精査 運用に関する作業実績を確認し、必要に応じて工数や生産性を見直す。
C2 運用業務の効率化、一元化 複数情報システムでの運用一元化や、オペレータの集約等、各種作業の見直し等により、運用業務の効率性を高める。
C3 運用作業のピーク平準化 リリース作業、帳票印刷、データ入力等の業務ピーク特性を把握し、運用作業のピークを平準化することで運用業務全体の工数を削減する。
C4 冗長化・BCP対策の適正化 東日本大震災以降、各府省の業務システムのバックアップ体制の充実が図られたが、冗長化・BCP対策が過剰と思われるケースも散見されるので、可用性要件とコストの実態を把握し、適正化を検討する。

表3-5 運用業務のコスト削減観点


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

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

表3-6 その他のコスト削減観点



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

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

<第三者保守の活用>

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

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

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

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

(注意点)  

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

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

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

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

<調達におけるその他の工夫>

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

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

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

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

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




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

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

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

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

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

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

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

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

事例3-3 PCの保守形態の変更

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

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

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

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


Step.3 予算要求に必要な資料の準備

予算要求には様々な資料を作成しなければならず、作業負荷が高いと感じる方も多いかもしれません。確かに、複数の資料を作成することが必要になりますが、これまでの検討過程の資料をうまく取りまとめることが主体であり、予算要求のためだけに新たな検討を行う部分は少ないと言えます。

一方で、予算要求の過程では短期間の間で多くの関係者に対してプロジェクトの目標や予算の必要性等を理解してもらう必要があるため、要点をわかりやすく表現することが求められます。また、わかりやすい資料を作成することで、事業者からも有意義な提案を受けて的確な見積りを取得することが可能になります。

どのように予算要求に必要な資料をまとめればよいか、そのポイントと注意点を解説します。

1 全体像と要点の明確化

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

まず、資料を作り出す前に一呼吸を置いて、頭を整理してみましょう。

説明資料を作成する人は、プロジェクトの背景や状況を詳しく知っているため、そのような大前提の説明を飛ばしてしまい、プロジェクトが直面している課題だけにフォーカスを当てがちです。

プロジェクトの内容を第三者に正確に伝えるためのコツは、「全体」から「詳細」につながるような構成で説明することです。まず、サービスや業務の全体を俯瞰した視点を示し、目指している目標を明らかにした上で、その中で今回のプロジェクトがどの範囲なのか、今回の予算要求対象がどの範囲なのかと順をおってクローズアップしていく構成にすることで、資料の読み手に対して正確にプロジェクトの姿と予算の必要性を伝えることができます。

図3-4 全体を俯瞰した視点のイメージ

図3-4 全体を俯瞰した視点のイメージ


資料の読み手は、予算要求内容を確認する担当者(PMO、総務省行政管理局、内閣官房IT総合戦略室、財務省主計局)だけではありません。PJMO内部の職員も、利用者や関係者等のステークホルダーも、見積り依頼先の事業者も重要な読み手です。読み手によって、関心のポイントに異なる部分もありますが、どの読み手も共通して知りたいのがサービスや業務の全体像です。プロジェクトの前提を間違えて捉えると、的確な判断ができないからです。

また、これらの資料は、PJMO内部やステークホルダーに対しても、プロジェクトの目標や全体像を共有するための良いツールとなります。

プロジェクトとして、これらの全体像がわかる資料をわかりやすく整理するとともに、プロジェクトの進捗や変化に応じて資料内容をバージョンアップする活動を日常的に行うことで、予算要求に限らず、様々な状況でプロジェクトの状況説明を円滑かつ効率的に行えるようになります。

2 予算要求に必要な資料の作り方

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

予算要求で作成する資料はプロジェクトにより若干異なりますが、次に示す資料が中心です。新たに作成するのではなく、情報を整理し、取りまとめを行う作業が主体となります。


A. 作成する資料の一覧

No. 資料名 概要
1 予算要求の概要 予算要求を行うに当たって、施策の趣旨・概要、実施根拠、目的・目標、要求金額、想定する実施スケジュール等を取りまとめた資料。
本章(Step.3)でまとめ方を解説します
2 予算要求明細書 予算要求を行う経費項目と金額についての積算資料及び根拠資料。細目レベルで要求額及びその積算内訳(数量、月数、単価等)について前年度予算額との対比を明示している(三段表とも呼ばれる)。補足資料として次の資料を用意する。
本章(Step.4、5)で見積り方法を解説します
3 プロジェクト
計画書
プロジェクトを計画的に遂行するために、政策目的やプロジェクトの目標、範囲、体制、全体スケジュール等をとりまとめたもの。
第2章(プロジェクトの管理)で解説します
4 サービス・業務の説明資料 情報システムを活用する作業と活用しない作業を含めて、実施する業務全体の特徴や流れ、サービス・業務の実績(利用者数、利用率、業務量等)等をまとめた上で、サービス・業務改革(BPR)の要点をまとめた資料や、サービス・業務の内容が理解できるイメージ図。
第4章(サービス・業務企画)で解説します 本章(Step.3)でまとめ方を解説します
5 情報システムの説明資料 情報システムの役割、対象範囲、主要利用者、主要機能、情報システム全体構成(ハードウェア、ソフトウェア、ネットワーク、クラウドサービス等の構成及び当該構成とした理由が記載されている資料)等の概要をまとめた資料。
第5章(要件定義)で解説します → 情報システム稼働環境、システム方式等を中心に、その要点を予算要求資料としてまとめます。
6 想定する効果、
目標指標
(KGI、KPI)
投資に対して想定する効果の内容と、効果の達成度を判断するための定量的な指標(KGI、KPI)について記載した資料。
第2章(プロジェクトの管理)で解説します
7
(既存情報システムがある場合)

既存の情報システムについての 資料
過去の事業がもたらした効果と情報システムが果たした役割、コスト削減に向けた取組の説明資料、情報システムの運用実績、情報システムの稼働実績、要求事項と同等の内容の直近の調達結果の詳細等
第8章(サービス・業務の運営と改善)及び
第9章(運用及び保守)で解説します

表3-7 予算要求に必要な資料


まずは、上記の資料の中でも、予算要求のために重点的なとりまとめを行う2つの資料について、資料をつくるための具体的なポイントを見ていきましょう。

・サービス・業務の説明資料

・予算要求の概要

B. 「サービス・業務の説明資料」の作成ポイント

プロジェクトが前提としているサービス・業務の概要を説明する資料です。

サービス・業務の現状分析や検討方法の詳細については、「第4章 サービス・業務企画」で詳述します。サービス・業務企画での詳細な検討成果を、予算査定に係る様々な関係者にわかりやすく伝えるため、業務自体の概要、業務全体を示す業務フロー(概略)を1枚から数枚程度で簡潔に説明したものが、ここで作成する資料となります。

図3-5 業務概要図

図3-5 業務概要図


作成時に気をつける点

・業務(情報のやりとり)が発生する主体を明確化し、矢印等と使ってやりとりする内容を明確にする。

・管理指標と現在の達成状況について、定量的に記述する

・顕在化している課題を記述する

・異なる主体であっても業務や取り扱う情報等に共通点がある場合には、一括して記述するなどして、図が難解にならないようにする

C. 「予算要求の概要 」の作成ポイント

予算要求の概要は、プロジェクト計画書の内容を前提に、予算要求を行う範囲についての目標、内容、スケジュール、体制等を要約した資料です。

この資料は、予算要求の過程の中で、様々な関係者が真っ先に確認する資料となります。前述したように全体像と要点を明確化して、簡潔に理解できるように工夫しましょう。

作成時に気をつける点

全体像と目標の明確化

サービス・業務観点からの全体像と現時点の問題発生状況を明らかにした上で、プロジェクトの目的・目標を示し、サービス・業務の改善後の実現像を示す。

具体的な改善内容の明確化
改善を実現するために必要となる事項として、サービス・業務の改善内容、制度や業務ルールの改善内容、情報システムの改善内容を明確にする。
(情報システムの改善だけの目線にならないように留意する)

主要なスケジュールの明確化
全体スケジュールを作成し、新しいサービス・業務の開始時期を明示するともに、情報システムの主要な整備スケジュール(要件定義、調達、設計、開発、テスト等)、関連する制度変更のスケジュール、サービス・業務の変更のための手続等を明確にする。

体制とステークホルダーの明確化
プロジェクトの体制や、主要なステークホルダーへの影響有無を記述する。また、難易度の高い調整が発生する場合に、今後の調整方法(各ステークホルダーへの調査やヒアリングを通して詳細な分析を行う、ステークホルダーの責任者を集めた会議体を設置する等)を明らかにする。

前提条件や制約の明確化
プロジェクトを推進する上での前提条件や制約がある場合は、その主要なものについて記述する。また、前提条件や方針等に不明確な箇所がある場合は、この資料にまとめて記述する(業務の説明資料、情報システムの説明資料等の個々の資料にも記載した上で、この資料にまとめる)。

Step.4 見積り依頼

正確な情報を伝えれば、正しい見積りが返ってくる。

確かにそのとおりなのですが、これを行うことは容易ではありません。そもそも正確な情報がない中で見積らなければいけない状況も多く、そのことに苦労しているのではないでしょうか。

また、情報システムに関する作業内容や製品選定は、専門的な知識がないと正確に理解することが難しいため、事業者から提示された見積りを精査することが難しいという実感を持っているかもしれません。

まずは、情報システムの見積りの特性を理解した上で、どのように見積り依頼を行えばよい情報を入手することができるかを解説していきます。

1 見積り依頼書の作成

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

プロジェクトの初期の段階で事業者に見積りをお願いするときに、細かい粒度の見積りを求めて嫌がられたり、協力を得られなかったりしたことがありませんか?また、見積りの比較検討の際に、比較のための編集作業に大変な労力を割いたことがありませんか?

事業者に見積りを依頼するときに工夫をしておくと、後で見積りを比較したり精査したりする際に苦労をしなくて済みます。見積りを依頼する際のポイントを見ていきましょう。

A. 要件が未確定な部分を明確にする

見積りを依頼するタイミングによっては、情報システムに求める機能や前提条件等について、詳細な内容が決まっていないこともあります。例えば、プロジェクト初期段階の見積りでは、十分な現状把握や要件の検討ができていないこともあります。また、新しい制度を導入する場合や、既存の制度を変更する場合等においては、制度自体の方向性や内容が、見積り依頼時期にはまだ定まっていないこともあります。

見積りを依頼する場合は、見積りの対象や前提条件を明確にすることが大前提ですが、サービスや業務を開始する時期の1年ほど前に見積りを依頼する必要があるため、現実的には上述した例を含めて、未確定な部分が発生することもあります。

見積りの対象や前提に未確定な内容がある場合、次の点に留意してください。

未確定な内容がある場合に気をつける点

・見積りを依頼する要件の中で詳細が未確定な箇所には、

未確定である旨

、その理由、どのタイミングで詳細化できる予定であるかを記述する。

・未確定な箇所については、できるだけ複数の対応案 を示し、それぞれの対応案に対して見積り金額を把握できるように見積り依頼を行う。また、見積り前提が変わった際の影響範囲(見積り金額だけでなく、工期や連携先情報システムへの影響等を含めた全体的な影響)について事業者に確認する。

・未確定な箇所を一覧にまとめる。後述するプロジェクトの概要の前提条件・制約として記述する。

ただし、大前提としての注意点ですが、精度の高い見積りを取得するために、まずは、見積り前にできる限り詳細を決定するようにしてください。

B. プロジェクトの状況によって内訳粒度を変える

見積りは、サービス・業務の内容や情報システムが提供する機能等の要件が明確になればなるほど精度が上がっていくものです。特に、プロジェクトの初期段階の見積りは、実際にかかる費用と見積りは大きくかい離していることが一般的です。

一方で、見積りを行う事業者にとっては、見積りに求める粒度が細かくなればなるほど見積りにかかる労力が高くなります。サービス・業務企画の内容や情報システムの要件の大半が未確定の段階で粒度の細かい見積りを求めても、詳細な根拠がないため、想定条件を設定した上での按分計算等により、見た目だけ細かくするだけの結果となってしまいます。結果として事業者は無駄な労力を消費し、PJMOは精査に必要以上の時間を使ってしまうことになりかねません。また、見積り算出に係る負荷を敬遠して、事業者から見積りの協力すら得られないことも往々にしてあります。

見積り内訳は細かい粒度であるほど精査を行いやすくなりますが、要件が十分に精査できていない段階で見積り内訳だけを細かく要求することにも無理があります。プロジェクトのシチュエーションに合わせて適切な粒度を検討することが重要です。

シチュエーション 粒度の設定例
情報システムを新規に構築する場合 粒度:大
主要な機能の単位等で必要工数や金額の提示を依頼する。詳細な実現方法等については、機能の向上やコストの低減を含めて事業者からの提案の余地を含めた粒度とする
既存情報システムの改修や機能追加等を行う場合(前提となる要件が不明確 粒度:中
法改正の詳細条件が不明な中で予算要求を行う必要がある場合等においては、対応する範囲について前提条件を置いた上で、改修等に必要となる大まかな作業単位で工数の内訳を求める
既存情報システムの改修や機能追加等を行う場合(前提となる要件が明確 粒度:小
必要となる作業が明確であるため、改修対象となる画面数、帳票数、バッチ処理数等を事前に分析した上で、必要な作業を詳細な粒度で積算するように内訳を求める。

表3-8 シチュエーションごとの見積り粒度の設定例


C. 見積りフォーマットを指定する

一般的に、事業者は各社独自の見積りフォーマットを使って見積りを行います。複数事業者から見積りを取得した後、発注者側が各社の見積りを比較して差異を確認することになりますが、見積りフォーマットがバラバラだと比較や事業者への問い合わせに大変な労力を要します。

無駄な労力を使わないよう、見積り依頼時に見積りフォーマットを指定しましょう。各府省で見積りフォーマットを準備していれば、それを有効活用してください。

なお、複数事業者に見積り依頼を行う際は、見積りフォーマットの表頭(最初の1行目にあるヘッダ部分)だけを指定するのではなく、表側(最初の1列目)に主要な作業項目や機能を指定しておくことを推奨します。見積り結果を受領した後で各社の見積り内容を比較する際に、合計金額だけでなく内訳単位で比較を行うことができるからです。また、同じ内訳単位で比較して金額の差が大きい場合は、その理由を事業者に再確認することで、金額水準や見積り条件を見直すことができるようになります。

図3-6 見積りフォーマット(アプリ開発)の例

図3-6 見積りフォーマット(アプリ開発)の例


D. 工程の名称の違いをなくす

複数の事業者へ同一内容の情報を提供しても、回答する事業者によってその情報の捉え方が異なることがあります。例えば「詳細設計」という作業名称は、事業者によって呼び名が違ったり実施する内容が異なったりすることが多々あります。見積り依頼時に工程の名称と工程の示す作業範囲を指定すると、受領した見積りの比較検討が楽になります。

標準ガイドラインで定義する工程と事業者各社が用いる工程の名称の比較は、「第7章表7-1標準ガイドラインと各社が定義する工程の比較」をご参照ください。

E. 見積り手法に注意する

見積りを客観的に評価するためには、検証可能な計算式により見積根拠を明らかにしておく必要があります。

作業工数(人件費)の見積り方法は、発生する作業単位で必要な人数と期間を算出して足し上げる「積み上げ法」が実務的にはよく見られますが、その他にもシステムの開発規模から見積りを行うLOC法、FP法等があります。


参考:LOC法による工数見積り

類似情報システムや過去の開発実績を基に、アプリケーション(プログラム)のステップ数を類推し、アプリケーションの規模を見積もる手法です。 そのアプリケーションの規模を開発生産性で除したものが、開発工数となります。


参考:ファンクションポイント法(FP法)による工数見積り

アプリケーションの規模を測定する手法の一つで、アプリケーションが持つ機能数(内部論理ファイル、外部インタフェースファイル、外部入力、外部出力、外部照会の各機能の数)を洗い出し、洗い出した機能を複雑さによって重み付けをして、集計した値にシステム特性を加味する方法によって、そのアプリケーションの規模を見積る手法です。 そのアプリケーションの規模を開発生産性で除したものが、開発工数になります。


理想的な状態は、見積り依頼時に発注者側が見積り手法を指定し、同じ手法を前提に複数の事業者の見積りを比較できることです。

ただし、事業者もそれぞれ自社の標準的な見積り手法に基づいて経験を培ってきています。そのため、見積り手法を限定的に指定することによって見積り精度が落ちたり、事業者の協力を得にくくなったりすることもあります。見積り手法の指定が難しい場合は、事業者が選択する見積り手法で積算することになりますが、その際においても算定根拠となる計算式や基礎数値は明記するように依頼してください。

LOC法でもFP法でもプロジェクトの中で過去の生産性指標を蓄積することを推奨します。発注者と事業者が共通の物差しで開発規模や生産性を測定し共有することによって、見積金額の妥当性を評価しやすくなると共に、見積もり根拠を対外的にも説明し易くなります。

F. できるだけ詳細な要件を書く

以上のような注意点を参考にしながら、見積り依頼書を作成してください。

事業者が詳細な根拠に基づいて正確な見積りを作成できるように、開発する情報システムに求める機能要件(機能一覧、画面一覧、帳票一覧、外部インタフェース一覧等)と非機能要件(の機能要件を整理して、提示しましょう。

なお、現行情報システムに対する改修の場合は、システムの規模を参考にできるため、現行情報システムのLOC値やファンクションポイント数を、参考資料として提示します。

2 事業者 への見積り依頼

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

予算要求時点の見積りは、調達時の見積りとは違い事業者の受注に直結しないため、事業者も大きな労力を割きづらく、事業者の見積り協力を得にくいことや、意図にそぐわない見積りとなることがあります。

事業者から欲しい見積りを取得するためには、協力してくれる事業者を効率的に探し、資料では伝わりにくい意図を対話によって的確に伝えていくことが大切です。

事業者から良い見積りを効率的に取得するポイントを見ていきましょう。

ポイント

・見積り依頼できる事業者が見つからない又は少ない場合は、PMO、府省CIO補佐官等に協力を依頼する。

・事業者の見積り精度を上げるために、事業者との意思疎通を十分に行い、発注者側の意図ややりたいことを正確に伝える。そのためには、説明会・ヒアリング等を積極的に活用する。

A. 見積りしてくれる事業者を探す

見積りは、原則として、複数の事業者から取得し、取得結果を比較・検討する必要があります。見積りを依頼できる事業者が見つからないときは、PMO、府省CIO補佐官、内閣官房に相談してください。

また、事業者から見積り辞退の回答を得たときは、その理由を確認し、情報不足や調達内容の制約等、見直しが可能な事項は見直しを検討しましょう。

留意事項

・事業者を選定する際は、事業者間に資本関係がないことを確認してください。資本関係がある場合、見積りの客観性の問題があったり、利害関係から見積りを辞退されたりする可能性があります。

B. 見積り事業者と対話して、発注者の意図を正しく伝える

特に、プロジェクト初期段階のサービス・業務企画や情報システムの要件が粗い場合は、資料だけではプロジェクトの趣旨や実現したい内容、欲しい見積りの粒度等が伝わりにくく、結果として発注者の意図に合わない見積りとなり、双方にとって無駄な労力となることもあります。

事業者の見積り精度を上げるためにも、事業者との意思疎通を十分に行い、発注者側の意図ややりたいことを正確に伝えることは重要です。そのために、事業者への説明会を開催したり、見積り内容に対するヒアリングを行ったり、様々なコミュニケーションを通して発注者の意図を正しく伝えましょう。

Step.5 見積りの精査

情報システムの開発や運用等を委託する事業者は、情報システムを運営していくためのパートナーですので、事業者と良好な関係を維持することはとても重要です。

ただ、この良好な関係とは、決して業務の一切を事業者任せにする状態ではありません。適切な役割分担の下で緊張感を持って協働することこそが、良好な関係です。このことは、事業者が提示する見積の精査についても当てはまります。つまり、発注者側である職員が見積内容を十分に理解し、前提条件や取り得る選択肢を理解した上で、実現機能と価格のバランスを取ることが求められます。見積り金額を減らせばよいというものでもありません。必要不可欠な項目が抜け落ちてしまうと、システム開発や運用の段階で大きな問題になります。

見積りの精査は、実際には簡単なものではありません。ハードウェア、ソフトウェアの見積りには専門的知識がないとわからない横文字が列挙されていますし、人件費の工数積み上げについても、どのような観点で確認すべきか迷うことがあるでしょう。

見積り金額を適切な範囲に収めるとともに、発注者側・事業者側の双方がこの先の工程で円滑に活動ができるために、見積りを精査する具体的な方法について解説します。

1 人件費の見積り精査

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

情報システムの設計、開発、試験等に関わる経費、アプリケーション保守や運用に関わる経費等、多くの経費はPM(プロジェクトマネージャ)、SE(システムエンジニア)、PG(プログラマ)、等の人件費で構成されています。人件費の積算は、基本的に工数と単価の掛け算です。工数については、「人月」や「人日」といった単位で表されます。4人体制で15日間の作業が必要な場合は、60人日(3人月)の工数になります。そして、人件費単価が120万円/人月であれば、掛け算をして合計360万円となります。人日と人月の換算は、営業日ベースで計算するので、20人日を1人月とすることが標準的です。

見積りの中で、数十人月、数百人月といった大きな単位で一式としての工数が示されても、その中に様々な作業が混在して合算されているため、個々の作業工数の妥当性を判断することができません。まずは、工数内訳を詳細に確認できるようにしてください。

工数の内訳は、機能や作業単位で分けることが非常に重要です。時々、数百人月といった大規模作業を、工程単位(設計、開発、試験等)、期間単位(月ごとの工数等)、要員種別単位(PM、SE、PG等)で分けて、一見すると詳細な内訳として提示されることがあります。しかし、このような分け方ではこれ以上精査することが困難です。

居酒屋のコース料理に例えると、本来、料理のメニューや飲み放題の時間等のサービス内容面で金額が決まるはずなのに、料理人の人数や作業時間だけで金額を説明しているようなものです。そのような内訳では、サービス内容を調整して料金を変えることも困難ですし、サービスごとの費用妥当性を判断することも困難です。

個々の経費項目の必要性や生産性水準について精査できるようにするためには、実現する機能単位、実際に発生する作業単位での詳細工数が明記された見積が不可欠です。このような見積が提示されていない場合は、事業者に対して見積精査上の必要性を伝えた上で、必要な粒度での工数見積を取得しましょう。

A. 安易な掛け算の精査

画面、帳票等を作成、改修する際に、単純に画面数等の数量で掛け算をして工数が積算されることがあります。また、データの入力、変換等の各種作業を実施する際にも掛け算が利用することがあります。ただ、安易に掛け算を行うと、工数が過大に積算される可能性があります。

例えば、作業を共通化、自動化できる可能性があります。作業対象が10件あったとしても、作業全体工数が1つの作業工数の10倍になることはほとんどありません。作業工数の中には対象件数によらず必要となる共通部分があるため、その部分を外へ括り出すことが必要です。また、作業件数が増えた場合は自動化の工夫を行うことも有効です。ツールの作成や設定等、自動化のための準備作業に一定の工数がかかるものの1件当たりの作業工数を大幅に削減できるので、全体としての工数を下げることができます。

B. 作業重複の精査

見積書の各作業項目を見比べると、類似の名称の作業項目が存在したり、成果物が同一と思われる作業が列挙されていたりすることがあります。

例えば各種の設計を行う作業についても、見積書では方式設計、構成設計、環境設計、データ設計、機能設計、性能設計、パラメータ設計など、様々な名称が使われることがあります。これらの作業項目の名称だけでは重複有無を判断しにくいですが、各作業の成果物(ドキュメント)を明らかにすると、重複を発見しやすくなります。

また、事業者間での作業重複についても気を付ける必要があります。例えば、複数事業者協働してテストを実施する際に、それぞれに事業者がテスト工数を見積ります。ただ、実際のテスト作業においては、テスト計画書の作成、テストシナリオの準備、テスト環境等の準備、テストの日程や体制の調整といった前工程作業や、テスト結果のとりまとめ等の後工程作業を主体的に担う事業者が1社存在し、残りの事業者はその活動を支援しながら自社分の部分的な役割を担うことが多いです。この場合、工数積算においては、支援側の工数が相対的に少なくなるはずです。テスト工程だけでなく様々な工程で、事業者の作業分担を確認した上で工数のバランスを確認することが重要です。

C. 主要成果物との比較

工数の妥当性を判断する際の拠り所は、その作業によって完成する成果物の質と量です。

特に、システム開発では様々な種類のドキュメントを作成します。要件定義書、各種設計書、構築作業の設定書や手順書、テスト計画書、テスト結果報告書、運用設計書、運用手順書、マニュアル等が代表的な例になります。これらのドキュメントの作成工数は、発注者にとっても妥当性を判断しやすい部分です。

まず、各ドキュメントの「量」について、「50ページ程度」、「300ページ程度」など概算で構わないので何ページ程度の成果物を作成予定かを確認します。

次にドキュメントの「質」として、主要な構成を確認します。例えば、システム操作説明を主体としたマニュアルであれば、システムの機能構成単位で画面イメージを貼付ける構成となり作成工数も比較的少なくなるでしょう。一方で、業務面での解説を中心としたマニュアルであれば、業務上で発生する状況に合わせて情報システムの使い方を説明する形となり、作成工数も比較的多くなると考えられます。

このように、成果物であるドキュメントの量と質を確認すると、ドキュメントを作成する作業規模や難易度がわかるため、作成工数の妥当性を判断しやすくなります。

D. 開発生産性の精査

システム開発の実作業の中では、再利用できる「部品」を様々に準備した上で、それらを組み合わせて実装を行うことが中心となります。そして、このように再利用可能な部品によって体系的に構築された情報システムであれば、機能の追加や変更に際して特定の「部品」等への限定的な追加作業を行うことで十分な対応を行うことができるはずです。

前述の「A.安易な掛け算の精査」とも重なりますが、画面や帳票の新規追加を行う場合においても、実作業としては限定的な作業で済む場合が多いはずです。

まずは、画面、帳票等の各機能を追加する際に、具体的にどのような作業が必要になるかを把握してみましょう。画面については、基本的な「ひな形」が複数種類存在していて、その一部を使って新規画面を構成することが多くなります。特に、既存機能と類似の画面を作成する場合は、その類似画面をベースとした上で流用開発を行うことが多いです。つまり、既存の「ひな形」や「類似画面」との相似度が高いほど、追加的な工数は少なく済むはずです。

帳票については、帳票作成に特化したミドルウェア(ツール)を利用することもあります。このようなミドルウェアを導入することで、帳票のレイアウト設計や出力制御を簡易な作業で実施できるようになります。このような帳票作成ミドルウェアを導入している場合は、そのツールを前提とした作業工数になっているかを確認することが有効です。

また、プロジェクトを通して見積工数の計画と実績を蓄積しておくことも重要です。このような蓄積があると、見積りを精査する際に過去の類似見積りとの比較を行うことができます。

2 ハードウェア等の見積り精査

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

ハードウェア、ソフトウェアの借料や保守経費は、経費全体の中で大きな比率を占めます。

まずは、大前提として製品単位での価格内訳を入手してください。予算要求段階では「一式」等の形で大括りの見積が事業者から提示されることもありますが、一式の状態ではそれ以上に金額の精査を行うことができません。新規に整備する情報システムであっても想定する製品に基づいて金額を積算しているはずなので内容を確かめるべきですし、既存情報システムに対する改修や更改等の案件であればなおさら詳細な積算内訳を求めることが重要です。

参考:ハードウェア・ソフトウェア等の見積りの記載例

製品単位で、数量、借料、保守料の内訳が示される形が一般的です。

製品については、「WEBサーバ 一式」といったグループ単位で金額が示されることもありますが、できるだけWEBサーバを構成する本体部分やオプション部分も含めて詳細内訳を入手するようにしてください。

<ハードウェアの見積り記載例(サンプル)>

ハードウェアの見積り記載例(サンプル)

<ソフトウェアの見積り記載例(サンプル)>

ソフトウェアの見積り記載例(サンプル)

※ 上述の見積り記載例は、特定の事業者を想定したものではなく、借料等の金額も架空のものです。


A. 製品単価を精査する

まず、主要な製品について定価や実勢価格との差異を確認してみましょう。

ハードウェアについては、オープン価格として定価(希望小売価格)を明示的にしていない製品もありますが、多くのハードウェアについてはWebサイト等で定価を確認することができます。また、製品名称や製品番号等をキーワードにしてWebサイトを検索すると、各種販売代理店等による実際の販売価格を把握することができます。代理店によって販売条件(納期、納品場所条件、各種サポート条件、支払期限、支払方法、キャンセルポリシー等)が異なるため販売価格の最安値と単純に比較することは合理的ではありませんが、調査した販売価格の水準(実勢価格)と取得した見積価格とのかい離が大きい場合は、その理由を営業担当者に確認すると良いでしょう。

ソフトウェアについても、まずは同様に定価や実勢価格との比較を行ってみましょう。ライセンス数の精査については後述します。

また、同一製品で異なる単価設定になっていないか、過去に受領した見積りと比べて同一(類似)製品の価格が高くなっていないか等、製品単価を比較してみましょう。

B. 高額な製品を中心に、必要性を精査し他製品と比較する

次に、見積り内容を分析して、どのような製品が高額となっているかをつかみましょう。1つの製品が突出して高額な場合もありますし、低額な製品(部品)が多数計上された合計で高額となっている場合もあります。

そして、高額な製品についてはその必要性を確認しましょう。例えば、ストレージ装置が高額となっているならば、容量(記憶できるサイズが何TBか)、性能(読み書きの速度等)、機能(複製、圧縮、冗長性確保等のための諸機能)等について内容を確認し、他製品との比較検討を行い、当該製品が必要以上のスペックになっていないか確認します。

全ての製品について必要性の確認を行うのは大変な作業ですが、高額な製品から順番に突合せを行うことで、効率的に価格構成上の主要部分を精査することができます。

C. ソフトウェアライセンスを精査する

ソフトウェアのライセンスの考え方は各社各様であり、課金単位も様々です。サーバに導入するソフトウェアについては、サーバ台数又はサーバに搭載されているCPU数を単位とするものが比較的多い状況です。他方、利用するPCの台数、利用するユーザの数、ユーザの最大同時接続数、利用するデータ量など、利用形態に対して課金する形態もあります。

いずれのライセンス形態であっても、サーバ台数、CPU数、PC台数、利用ユーザ数等の実際の使用状況(あるいは使用予定状況)に比べて過剰なライセンスが積算されていないかを確認しましょう。

また、特にCPU数を単位とするライセンスについては、現行情報システムの瞬間的なピークだけを捉えて必要数を積算していないか、実際のCPU使用率の推移を確認してみてください。夜間バッチ、バックアップ等の目的で業務時間外に短時間だけCPU使用率が高くなっていても、通常の業務時間のCPU使用率が低ければ、基本的にそのピークに合わせる必要はありません。

D. 保守料を精査する

保守料は、保守サービスの前提によって価格が変わります。保守サービスの対応日(週末の有無当)、対応時間帯、故障発生時の駆け付け時間、サービスの各種オプションの有無等が価格に影響する代表的な要素です。

一般的な機器については、保守サービスの条件に応じた年間保守料が設定されています。まずは、Webサイト等でこれらの保守料を調べて、見積内容と比較してみましょう。

また、全ての機器に、良い条件の保守サービスを一律にかけるべきであるか検討してみましょう。全ての機器を定期保守(故障発生頻度にかかわらず定額で対応を行う方式)でオンサイト対応(故障時に現地で修理・交換を行うサービス)でなくても、スポット保守(故障発生都度に修理対応料金を払う方式)やセンドバック対応(故障時に故障製品を指定先に送付し、代替品が交換で送付されるサービス)で十分な場合もあります。

いずれにしても、保守金額は条件によって大きく変わり得るものなので、前提条件やサービス内容を確認して、必要十分な水準になるように検討しましょう。

3 複数事業者の見積りの比較

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

複数事業者から見積りを取得した場合は、その内容について比較を行います。

比較に際しては、合計金額だけで比較するのではなく、主要な経費項目の単位で比較を行うことで事業者の得意分野、不得意分野等を把握することができます。


参考:三点見積りによる予算要求額の算出

三点見積りとは、例えば5つの事業者から見積りを取得した際に、最高額と最低額を除外した3者で平均して算出した額を指します。見積り経費項目ごとに三点見積りを行い、総合計したものを予算要求額とします。

三点見積りは、金額だけではなく、工数や期間の算出にも適用できます。


Step.6 予算を要求する

予算要求のゴールは、正しい要求に応じて予算配分されることにありますが、府省内外からの様々なチェックを通過して行かなくてはなりません。これらに対応する労力は掛かりますが、事前に作業スケジュールを把握し、必要とされる資料を準備し、発生するやり取りとその目的や効果を理解することで、軽減することができます。

A. 府省内の確認

府省によって確認対象や実施スケジュール等は異なりますが、PJMOが作成した予算要求内容を会計担当部門に提出する前に、基本的にはPMOによる事前ヒアリングが行われます。事前ヒアリングでは、PMOの職員やCIO補佐官が専門的見地から様々な内容の確認を行います。例えば、以下のような項目です。

・政府方針や府省方針等との整合性

・利用者視点の効果、サービス・業務改革(BPR)等の検討十分性

・省内、省外情報システムとの機能重複回避、共用・統合の推進

・見積積算方法の妥当性、経費水準の妥当性

・CPU使用率等の現状分析に基づいたサイジングの適切性の確認

・ライフサイクルコストとして将来発生するコストの確認

・セキュリティポリシーとの整合性、サポート期限の対応網羅性の確認

・バックアップ機能、ディザスタリカバリ(DR)等、信頼性確保状況の確認

事例:予算要求のプロセスでPMOと会計担当部門が密接に連携

ある省では、情報システム整備に係る予算要求を効率的に行うために、会計担当部門とPMOが連携し、必ずPMOのチェックを通過してから予算要求資料を提出するよう手順化しています。

事例3-4 予算要求のプロセスでPMOと会計担当部門が密接に連携

従来の手順では、情報システムの構築に関する知識・経験が浅いPJMOが見積りを積算すると、その粒度や精度が低くなることが多くありました。しかし、その予算要求資料は、専門経験を持つ職員のチェックなしに会計担当部門に提出されてしまっており、資料の質の向上が課題となっていました。

この状況を改善するため、事前にPMO・CIO補佐官と会計担当部門がタッグを組み、自府省内の当該年度ごとの予算要求に関する全体方針を定めてPJMOへ伝達し(上図STEP1)、PJMOがその方針に則り予算要求関連資料を作成し、PMO・CIO補佐官はその資料を確認する(上図STEP2)という手順を取り決め、運用を始めました。

この結果、PJMOは作成した資料に対し、PMOの職員やCIO補佐官の専門的な知見に基づく助言を得た上で、会計担当部門へ提出できるようになりました。(上図STEP3)

また、会計担当部門にとっても、PMOによる事前確認のプロセスが入ることによって、予算要求上の課題が絞り込まれ、予算要求内容の妥当性確認がより精緻に行えるようになりました。


B. 府省外の確認

府省外の関係者(内閣官房や総務省等)との調整は、府省内の事前ヒアリングの延長線上に当たります。府省内部の視点だけではなく、外部からの視点での確認し、より客観的に評価することが目的です。事前ヒアリングで使用した資料等を活用して、十分な説明ができるよう準備してください。

Step.7 予算要求後の対応

予算要求に係る作業が一通り終わり、予算確認ができてほっとするところですが、実は今やっておくだけで後々発生するリスクや負荷を減らすことができる作業があります。

ここでは、それら作業とポイントについて解説します。

1 人事異動時は確実に引継ぎする

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

様々な検討と工夫をして予算要求をしても、プロジェクト推進責任者等のプロジェクトの中心となる職員が人事異動になってしまい、後任の職員がプロジェクトをうまく進められないことがあります。異動する当人が心残りであることは言うまでもありませんが、プロジェクトにとっても大きな痛手となります。

このような予期せぬ事態に備えて、予算要求にまつわる一連の作業は、複数名のグループで実施しましょう。これにより、多くの情報が常に共有できます。その上で、異動する職員は、まず後任の職員ではなくグループの他のメンバーへ引継ぐことにより、引継ぐ情報量が少なくて済み、円滑に引継ぎができます。

引き継ぐ内容は、実務的な内容はもちろんですが、なぜこのプロジェクトを進めるのか、どのようにサービスを向上するのか、といった熱い想いを引き継ぐことが重要です。

その後、後任の職員には、既存のグループメンバーが時間をかけて十分な教育ができます。

そのほか、1名でプロジェクトを任された場合には、後任に十分な情報を引き継ぐためにも、資料をしっかり作成し、引継ぎを実施しましょう。資料は、様々な決定事項に関する経緯がわかることが重要であり、それらは後任者の大きな手助けとなります。

ポイント

予算要求から執行までの間に、当該プロジェクトのPJMOを変更することは推奨しない。

・やむを得ず、異動が決定した場合は、十分な引継ぎを準備し、後任に引き継ぐ。引継ぎには、決定事項だけでなく経緯も伝達する。

事例:引継ぎ不足により、後日問題が顕在化した

ある省において、監査の結果、新たに機器・ソフトウェア等を購入しなければ情報セキュリティ対策ができないことが判明しました。その結果が判明した後、原課側担当者が人事異動で交替しましたが、新たな情報セキュリティ対策用の予算を確保しなければならないことについて、引継ぎが十分に行われていませんでした。

1年後、その原課で情報漏えい事案が発生し、原因究明や報道対応を含めた様々な対応業務が大量に必要となりました。このとき、監査結果を反映した情報セキュリティ対策が講じられていれば、情報漏えい事案が発生しなかった可能性が高いことが判明しました。しかしながら、原課の予算担当、会計課、PMOにおいても監査結果による新たな情報セキュリティ対策が必要なこと、そして予算要求が必要だったことを誰も知りませんでした。


2 プロジェクト計画書に反映して最新化する

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

ここまで予算要求の作業を進めてきましたが、見積りを入手した後、プロジェクトの目的・目標を達成するために、多岐にわたって調整や変更を行い、予算要求を行ったことと思います。

その結果、検討の過程でプロジェクト計画書に記載されていた内容とは、異なる方針に変更した項目があるのではないでしょうか。

予算にまつわる作業の最後の締め括りとして、変更内容をプロジェクト計画書に反映しましょう。

今回実施した内容を基にプロジェクト計画書を最新化することにより、次回の予算要求のときは、プロジェクト計画書を見直すことなく、計画書の内容に沿って作業を進めることができるため、準備作業が減ります。

また、人事異動が発生しても、最新のプロジェクト計画書を使って引継ぎができます。

ポイント

プロジェクト計画書に記載されている内容を、予算要求作業の結果から発生した変更を基にPJMO内で検討の上、修正し最新化する。

・修正したプロジェクト計画書を、関係者と共有し合意する。

プロジェクト計画書の各項目に対し、予算要求の活動から変更される頻度の高い内容を次の表に示します。

No. 項目 変更例
1 政策目的 当項目はプロジェクト全体への影響が大きいため、基本的には変更しない。例外的に政策の方針転換等があったときのみ変更する。
2 対象範囲 整備する情報システムが提供するサービス・業務の範囲が変更されたときは、その内容に修正する。
3 実施期間 期間延長や短縮が発生したときは、その内容に修正する。
4 サービス・業務企画の方向性等 当初想定していた予算内でサービス・業務企画内容を実現することが困難であると判明し、企画の方向性等の変更を検討したときは、決定した内容に修正する。
5 予算 プロジェクトの構想段階に記載されていた年度ごとに見積った経費区分ごとの概算予算を、当初予算が承認された段階で、初年度分については、作成した予算に係る各種資料を基に修正する。また、次年度以降の予算見積りを見直した結果を記載する。
6 目標 主にサービス・業務企画の方向性等の変更とともに、達成目標とする指標及び達成目標年度等の変更する必要有無を検討し、その結果を反映する。
7 体制 見積りの結果、人件費が当初想定よりも増減したときに、体制の増強又は縮小を検討し、その結果を反映する。
8 実施計画 プロジェクト計画書に記載されている他の項目(特に実施期間、対象範囲)に変更が発生したときに、あわせて当項目も整合性が取れるよう検討した上で変更する。
9 モニタリング 目標が変更されたときは、モニタリングで定義している内容の変更もあわせて検討し、変更する。
10 その他 見積りの際に事業者から得た情報や、省内・省外調整の過程で把握したプロジェクト運営上の課題やリスク等を追記・更新する。

表3-9 予算要求活動後に修正が必要となるプロジェクト計画書の変更内容の例