Step.4 見積りの精査

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

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

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

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

人件費の見積り精査

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

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

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

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

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

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

安易な掛け算の精査

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

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

作業重複の精査

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

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

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

主要成果物との比較

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

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

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

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

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

開発生産性の精査

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

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

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

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

開発生産性を精査するためには、テストにおいて不要なテスト項目が含まれていないか確認することも有効です。例えば、機能改修を行う場合に、改修を行わない部分に対する影響がないかリグレッションテストを実施しますが、影響範囲の絞り込みが不十分であるためにテスト範囲が広すぎ、 生産性が低下している場合があります。

機能改修の特性を踏まえて、テスト自動化の検討、テスト項目の妥当性の精査、機能改修による影響範囲の特定などを適切に実施することで、効率的にテストを実施し、過剰な工数を削減することができます。

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

見積り精査を行うにあたっての参考資料

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

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

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

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

  • 参考3-4

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

製品単価を精査する

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

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

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

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

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

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

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

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

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

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

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

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

保守料を精査する

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

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

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

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

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

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

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

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

  • 参考3-5

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

  • 注記

    ベアメタルとは、ユーザから申し込みがあると、あらかじめ事業者のデータセンターに用意された物理サーバを割り当てて利用可能とするサービスのこと。

    一般的なクラウドサービスに対応していないソフトウェアも利用できる、リソースを専有できて他の利用者の影響を受けないなどのメリットがある。

    一方で、利用に当たって初期コストがかかる場合がある、サーバを仮想化しておらず共用できないため、リソースを柔軟に変動させることができないといったデメリットがある。

  • 事例3-5

クラウドサービスの見積りの精査

  • 参考3-6

    クラウドサービス特有の料金体系

  • 注記

    ウォームスタンバイ、コールドスタンバイとは、本番機の障害発生時に予備機に切り替えることで信頼性を向上させる手法であり、ほかにホットスタンバイがある。

    ホットスタンバイ、ウォームスタンバイ、コールドスタンバイの順に切替えが早い。

    なお、災害対策環境をウォームスタンバイやコールドスタンバイとすると、大規模災害発生時には同環境が設置された拠点に利用が集中してリソースを確保できないおそれがある。そのため、システムの特性や目標復旧水準を踏まえた検討が必要となる。

  • 注記

IOPSとは、１秒間あたりに入出力できる回数のことで、性能指標の一つ。

IOPSはInput/Output Per Secondの略。