こんにちは。ギブアンドサポート合同会社の吉田です。
私はシステムエンジニア（アプリケーションエンジニア）⇒公務員⇒コンサルタントというキャリアを経験していることもあり、自治体における情報システムの見積書を精査するご支援も行っています。
少し前でしょうか、ニュースで「学校の先生がプールの水道の蛇口を閉め忘れ、数百万の損害賠償を求められた」という話題を目にすることがありました。公務員にとって非常にシビアなご時世です。
これを対岸の火事だと思ってはいけません。翻って、公務員である皆さんが日々扱っている「情報システムの調達」はどうでしょうか。
公共工事の請負契約であれば、細かい部材から丁寧に積算し、予定価格を算出し、また、厳格に工事検査を行います。しかし、情報システム構築や改修となると、なぜか詳細な内訳が不明瞭な「ゆるふわな見積書」のまま予定価格を設定したり、そのまま契約したりするケースが多いのではないでしょうか。
もし明日、住民の方から「他市と比べて、わが市の情報システム費用はなぜこんなに高いんだ！住民監査請求をする！」と突き上げられたとき、担当職員は、そしてそれを統括する情報政策課（情シス）は、胸を張って見積の根拠を説明できるでしょうか？
今回は、自治体が直面している厳しい現実と、ブラックボックス化しがちな情報システム見積書の具体的な精査テクニック、そして個人の頑張りに依存しない「組織としての仕組み・体制づくり」について、私の考えをお話しします 。
第1章：なぜ情報システムの見積は「高額なバッファ」を含んでしまうのか
職員は減るのに、仕事は増える「負のスパイラル」
そもそも、なぜ情報システムの見積精査がおろそかになりがちなのでしょうか。その根本原因は、自治体現場の圧倒的なリソース不足にあります。
現在、地方公共団体の多くは、人口減少とそれに伴う税収減という負のスパイラルに直面しています。平成6年をピークに、地方公務員の総数は約47万人（14%）も減少しました。その一方で、子ども・子育て関連の新制度やコロナといった感染症対策、システム標準化・ガバメントクラウド対応など、自治体が対応すべき業務は幅広に膨れ上がっています。
職員数が減り、仕事が激増する中、これらを乗り切るためにはデジタル技術を活用した抜本的な業務改革がもはや待ったなしの状況です。しかし、デジタル技術を活用するために情報システム（サービス）を導入すれば、当然ながら自治体の情報システム関連費用は中長期的に右肩上がりで上昇していきます 。
原課の「とりあえず」が、ベンダーの「バッファ」を生む
日々の業務に追われ、運用主体である業務所管課（原課）の担当者は、ついベンダーにこう言ってしまいます 。
「急いでいるので、とりあえず見積を出してください！」
実はこの「とりあえず」が、情報システム関連費用を押し上げる要因のうちの一つです。要件がフワッとした状態で正確な見積を作ることは不可能です。のちのち「あの機能も必要だった」「仕様が変わった」と追加作業が発生して赤字になるリスクを避けるため、ベンダーは自己防衛に走ります。
- 「要件がわからないから、のちのち開発費用を削られないように費用を多めに上乗せ（バッファ）しておこう」
- 「今回は国費が100%出る法改正対応で、国からの方針もまだ出ていないから、リスクも考慮して費用を上乗せしておこう」
国費が100%出るからといっても、その原資は国民の血税です。ベンダーが不誠実なのではなく、自治体側のコミュニケーション不足と丸投げが「不本意なコストの膨張」を生んでいるのです。
第2章：ベンダーに「エスパー」を求めない依頼術
では、どうすれば精度の高い見積が出てくるのか。まずは見積を「依頼する段階」でのアプローチを変える必要があります。相手にエスパー能力を要求するような「いい感じでお願いします」という依頼はよくありません。
1. 目的や背景を伝える
「ご存じかもしれませんが、〇〇業務において国から法改正の話が来ています。法改正内容としては～～～といったものです。おそらく本市の基幹業務システムも変更となる見込みと推測し、〇〇画面と△△処理、帳票も数本改修となるのではと考えます。国からの現時点の方針は～～～となっているようです。予算確保のため、改修コストを把握したいです。」といったように、背景と目的をしっかり伝えます 。これだけで、ベンダーは「どんなスキルを持った要員が必要か」「どの程度の作業が発生するか」を推測しやすくなり、自社の情報を合わせてることで認識が深まります。
※ベンダーから見積もりがでてきて初めて知るということがないようにしましょう。
2. 未確定な部分を隠さず、分けて見積もらせる
要件の一部が未確定なことはよくあります。その場合は「国からの詳細な方針がまだ示されていない」「オプションを追加するかは庁内で決まっていない」と正直に伝えます。そして、「オプション追加分がわかるように分けて見積を出してほしい」と明確に指示を出します。
※パターン別の見積はお願いしすぎるとベンダーは大変なので２～３パターンまでにしましょう。
3. メールで終わらせず、直接対話する
阿吽の呼吸に頼ってはいけません。見積依頼後には、必ずWeb会議などで「疑問点はありませんか？」と聞いたり、「対象となる職員数と端末数は20台程度です」と情報を伝えたり、直接すり合わせる場を設けます。
※できるだけ対面で実施しましょう。
前提条件や制約条件を言葉にして手渡すだけで、出てくる見積書の解像度はかなり上がります。
第3章：いざ実践！見積書にメスを入れる3つのポイント
ベンダーから見積書が提示されたら、いよいよ精査です。ここで大事なのは、情報システムの知見がない職員でも「自ら納得して予算化・契約する」というマインドセットを持つことです 。
私が自治体向けの情報システム見積精査研修で配布している「簡易見積書チェックシート」の中から、明日から具体的な精査ポイントを3つご紹介します。
① 内訳が不明瞭な見積を解体し、過剰な数量マジックを見破る
詳細な内訳が書かれていないどんぶり勘定の見積は基本認めず、打ち合わせ・設計・開発・テスト・移行といった工程ごとに積算（単価・人工）を明記させます。 その際、機能や画面、帳票などの本数が明記されているか確認してください。
- よくある事例： 同じような帳票について同じ修正を10か所する場合、ただ単に工数を「×10」で積算しているケースがあります。1本開発・テストをすれば効率よくその他帳票も開発が進むこともあります。
- 対策： 1つ修正すればあとは横展開で済む作業に、単純な掛け算で積算するのは少し待ったをかけてください。何をどれだけの工数をかけて改修するのか、定量的に確認しましょう。
② 「やっていない作業」の架空請求を削ぎ落とす
見積書の内容と、実際の作業実態が伴っているかを確認します 。
- 事例1： 打ち合わせ費用を積算しているのに、実際は打ち合わせをしない、もしくは見積書の時間に全く満たない。
- 事例2： パッケージ適用の微小な改修なのに、プロジェクト管理や課題管理に過大な工数が積まれている。
- 事例3： 現地立会費用を積算しているのに、リモート対応で現地に来ない（実は不要だった）。
こうした「あるある」な過大積算がないか、臆せずベンダーに確認し、確認するようにしましょう。
③ SE/PG単価に注意する
各工程の人工（人日・人月）と単価が明記されているか確認します。
- よくある事例： 実際は下請け企業（時には孫請け）のプログラマー（PG）が対応するのに、元請けのシステムエンジニア（SE）の高い単価で積算しているパターンです。
- 対策： 一般財団法人経済調査会が発行する「積算資料」のソフトウェア部門（土木・建築部門が冊子を持っているはず）や、防衛装備庁が公開している「実例技術者料金（通知）」の企業規模ごとの単価相場と比較し、妥当性を判断します。
※SE単価は年々上昇傾向にあるため最新の動向に注意が必要です。ちなみに吉田は複数自治体の見積書をチェックする仕事柄、ベンダの人口レンジ別のSE単価を概ね把握できていますので、高い・安いの判断ができます。 - 令和７年度に契約する情報システムの価格計算に適用する実例技術者料金及び協議の様式について（通知）
http://www.clearing.mod.go.jp/kunrei_data/j_fd/2024/jz20250331_06251_000.pdf
第4章：忘れてはいけない「交渉のマインド」
ただし、ここで絶対に忘れてはいけないルールがあります。ベンダーの担当者も人間です。誠意をもって対応しましょう。
まれに、ベンダーの方に激詰め・鬼詰めをされる職員さんがいますがハラスメントになりますので絶対にやめましょう。
ベンダー側も社内で単価の決まりがあることが多く、ただ「単価を安くして」と要求しても難しいケースがほとんどです。頭ごなしに交渉するのではなく、以下のような現実的な落としどころを探る姿勢が大切です。
- 担当の職位を下げても対応可能か？
- 閑散期に対応してもらうことで値引きは期待できないか？
タイムアップまで粘り強く交渉するためにも、精査の着手はできるだけ早く行いましょう。見積精査は、ベンダーを敵視して買い叩くことではなく、健全で対等なパートナーシップを築くためのプロセスでもあります。
第5章：個人の頑張りから脱却する「組織的な仕組み・体制づくり」
ここまで実践的な精査ノウハウの一部をお伝えしましたが、これを「一部の担当者の頑張り」で終わらせてはいけません。自治体において最も重要なのは、異動があってもノウハウが引き継がれ、適正な調達が当たり前になる「組織としての仕組みと体制」を整えることです 。
自治体の現場では、しばしば「原課」と「情シス」の責任の押し付け合いという深いジレンマが存在します 。 原課からすれば「システムの専門的なことはわからないから、情シスで確認してよ」となります 。一方、情シスからすれば「実際に業務で使うのは原課なんだから、原課が責任をもって見積を精査すべきだろう」というのが本音でしょう。
しかし、組織全体最適の観点からすれば、ITの知見がある情シス部門がしっかりとガバナンスを効かせ、システム見積を一元チェックすべきというのが私の考えです。とはいえ、情シスには全庁の見積を一つひとつ精査する圧倒的なマンパワーと時間がありません。
だからこそ、情シスがすべてを抱え込むのではなく、「原課を巻き込んだ体制化」が必要と考えます。
組織として機能させる「3段階の予算化プロセス」
情報システムの予算化において、私は以下のような役割分担の仕組みづくりを提唱しています。
- 原課による一次チェック（当事者意識の醸成）
ベンダーから見積を入手した業務所管課（原課）が、自ら「見積書チェックシート」に基づいて内容を精査し、妥当性のある金額を算出します。詳細が不明瞭な見積は突き返し、内訳を出させることを義務付けます。不明点があれば情報システム部署に確認を行います。ベンダと打ち合わせする際は情報システム部署に同席してもらうなどフォローしてもらいます。 - 情シスによるダブルチェック（組織の関所）
原課がチェックした内容を踏まえ、情報システム部署がシステムの専門的知見からダブルチェックを行います。ここで単価の妥当性や自治体内の他案件との乖離がないかを見極め、組織としての関所（ゲートキーパー）の役割を果たします。また、「これは余計な仕様ではないのか？」といった仕様面での精査も重要になります。原課からの相談ベースではなく、予算化対象となる案件（新規・継続に関わらず）はすべて情報システム部署でのチェックを行うべきです。 - 財政部門への予算要求
精査が完了した上で、財政部門へ予算要求を行います。すでに予算化が完了している事業であっても、契約前に必ず要件と費用を再度精査するフローを徹底します。
「意地悪なベンダー役」で体制を強固にするロールプレイング
とはいえ、ITの知見がない原課の職員に「精査しろ」と言っても無理があります。そこで私が自治体向けの研修で行っているのが、実践的なロールプレイング演習です。
講師である私や情シスの職員様が「架空のベンダー役」になり、ツッコミどころ満載の見積書を参加職員に提示します 。
- 事例1： 法改正対応で詳細不明のまま「1,000万円」とだけ書かれた見積書。
- 事例2： パッケージ適用（2名で1日対応）に過剰な費用が計上され、さらにパソコン1台40万円、マウス1個1万円という異常な機器代が含まれた見積書。
- 事例3： パッケージ料（500万円）に対して、プロジェクト管理費や課題管理費が過剰に積まれている見積書。
参加する職員には、これらの見積書のどこがおかしいかを考え、実際に声に出して指摘してもらいます。ベンダー役からの切り返しを疑似体験することで、原課職員の「調達マインド」を向上させます。交渉力は、結局のところ「場数」でしか養えません。
※この研修そこそこ好評です。
第6章：専門的な内容は外部専門家を活用するのも一つ
原課の意識を変え、情シスがダブルチェックを行う体制が理想ですが、システムのコアな部分の精査や大規模案件のチェックは、内部のリソースだけでは限界があるのも事実です 。
だからこそ、すべてを庁内だけで完結させようとせず、私たちのような外部の専門人材を「情シスの右腕」として活用するのも一つです。
削減効果だけでなく、第三者の協力も得て「きちんと精査した」ということが重要です。
情報システム費用は高額になりがちで、数千万円になることも珍しくありません 。たった1時間交渉し、1%削減するだけで、数十万円の効果が生まれることもあります。100円、1000円の消耗品費の削減に汗を流すのと同じように、システムの数万円、数十万円の削減にも真剣に向き合うべきです。
組織としてのガバナンスをどう構築し、議会や住民に胸を張れる適正なシステム調達を実現するか。お悩みの自治体ご担当者様はご相談ください 。
