未来PM
プロジェクトマネジメント事例集

追加要望で膨らんだ費用を、変更管理の作り直しで止めた事例

この事例は、追加要望で費用が膨らんでいくプロジェクトを、どうやって止めたかの記録です。自治体の電子申請システム構築で、稼働9か月前に追加要望が147件たまっていました。全部対応すると3,260万円の追加となり、予算の限度額を1,560万円超えます。

ここで打った手は、要望を断ることではなく、要望の扱い方を作り直すことでした。結果として最終額は1億6,080万円、限度額まで420万円を残して着地しています。会社・自治体名・数字はすべて架空ですが、記事の中で辻褄が合うように作っています。


■ 自治体と案件の前提

項目

内容

自治体名(架空)

みどり市

人口

18万2,000人

世帯数

8万4,000世帯

職員数

1,240名

案件名

市民向け電子申請・窓口予約システムの構築

対象手続き

68手続き(当初)

期間

2024年7月1日 〜 2025年10月1日 本番稼働(15か月)

契約方式

一般競争入札

当初契約額

185人月 × 80万円 = 1億4,800万円

債務負担行為の限度額

1億6,500万円

体制

市側:情報政策課4名 + 各課の業務担当者12名(兼務)/ベンダー:最大11名

新規開発規模

64KStep

自治体の案件で特徴的なのは、「発注者」が1つではないことです。契約の相手は市ですが、実際に要望を出すのは市民課・保険年金課・子育て支援課など、それぞれ運用が違う各課です。この構造が、後で効いてきます。


■ 何を「成功」とみなしたか

観点

合格ライン

なぜその線なのか

Q(品質)

受入テストの不具合密度 0.25件/KStep 以下

市民が直接使うため、稼働後の不具合は問い合わせ対応の負荷に直結する

C(コスト)

債務負担行為の限度額 1億6,500万円 以内

限度額を超える契約変更は議会の議決が必要で、次の定例会(3か月後)まで待つことになる

D(納期)

2025年10月1日 稼働

翌年度の予算要求に、稼働後の効果測定値を載せる必要があるため

民間との大きな違いは、Cの超過が「お金の問題」で済まない点です。限度額を超えると議会の議決が要り、そこで3か月止まればDも守れなくなります。CとDが一体になっている案件でした。


■ 立ち上げ時の計画

No

作業

計画(人月)

実績(人月)

差

1.0

プロジェクト管理

24.0

24.0

0

2.0

要件定義

30.0

30.0

0

3.0

電子申請機能 設計/開発

62.0

60.0

−2.0

4.0

窓口予約機能 設計/開発

26.0

29.0

+3.0

5.0

既存システム連携

18.0

33.0

+15.0

6.0

データ移行・様式登録

12.0

12.0

0

7.0

テスト(結合・総合)

8.0

8.0

0

8.0

受入支援・職員研修

5.0

5.0

0

―

合計

185.0

201.0

+16.0

主なマイルストーンは次のとおりです。

マイルストーン

計画

実績

要件定義 完了(68手続き)

2024/10/25

2024/10/25

変更管理ルールの改訂(2月に追加)

―

2025/2/28

基本設計 完了

2025/2/28

2025/3/14(10営業日遅れ)

開発 完了

2025/7/4

2025/7/4

結合・総合テスト 完了

2025/8/29

2025/8/29

受入テスト・職員研修 完了

2025/9/19

2025/9/19

本番稼働

2025/10/1

2025/10/1


■ 2024年11月〜12月:要望が「どこからともなく」入り始めた

要件定義は10月25日に完了し、68手続きの仕様が確定しました。ここまでは順調です。

変化は11月からでした。基本設計に入り、各課に画面イメージを見せ始めると、そこで初めて「うちの窓口ではこうしている」という話が出てきます。要件定義の段階では紙の様式を見て議論していたので、実際の運用の違いは表に出ていなかったのです。

たとえばこういう話です。

  • 「この申請は、窓口では本人確認書類を2点もらっている。画面では1点しか登録できない」

  • 「支所では受付時にこの項目を手書きで足している。画面にも欄が欲しい」

  • 「この手続きは、申請後に職員が訪問する運用になっている。訪問日の調整画面が要る」

どれも「言われてみればそのとおり」の話で、断る理由が見つかりません。ベンダーの担当者も、目の前で困っている職員に「それは契約外です」とは言いにくい。結果として、口頭で依頼されたものがそのまま着手されていきました。


■ 2025年1月末:3,260万円の追加になると分かった

年が明けて、ベンダーから正式な文書が届きます。「11月以降にご依頼いただいた事項を整理したところ、147件ございました。対応に必要な追加費用は3,260万円です」。

  • 当初契約額:1億4,800万円

  • 追加見積り:3,260万円

  • 合計:1億8,060万円

  • 債務負担行為の限度額:1億6,500万円

  • 超過見通し:1,560万円

ここで焦ってやりがちなのは、「147件を1件ずつ見て、削れるものを探す」ことです。実際、最初の部内検討ではその方向で話が進みました。しかし147件を1件ずつ検討すると、1件あたりの金額が小さいので、どれも削る理由が弱くなります。「22万円ですよね、それくらいなら」という会話が147回続くだけです。


■ まず調べたのは、金額ではなく「入り方」だった

方針を変えて、最初に調べたのは147件がどうやって入ってきたかでした。

依頼の経路

件数

割合

承認の記録

口頭(窓口での会話・電話)

62件

42%

なし

メール本文での依頼

71件

48%

なし

所定の様式での依頼

14件

10%

あり

合計

147件

100%

記録ありは14件(9.5%)

この表が、すべてを説明していました。147件のうち133件は、誰が決めたか分からない状態で入っている。だから止まらなかったのです。

金額が膨らんだのは、各課の要望が贅沢だったからではありません。要望を受け取る入口が無かったからです。入口が無ければ、要望は一番近くにいる人のところへ直接行きます。この案件では、それがベンダーの設計担当者でした。

ここで打つべき手が決まりました。147件を削ることではなく、148件目からの入り方を変えること。そして147件は、新しい入り方に一度通し直すこと。


■ 作り直した変更管理のしくみ

2月の1か月をかけて、変更管理のやり方を作り直しました。新しいしくみは次のとおりです。

図1 作り直した変更管理のしくみ

5つの決めごとを、あらためて文章にします。

  1. CR票(変更依頼票)でのみ受け付ける:口頭・メール本文だけの依頼は、ベンダーは着手しない。これは契約の覚書として明文化しました

  2. CR票に「この変更がないと、何が、どう困るか」を書く:欲しい機能ではなく、困りごとを書いてもらう

  3. 判定は変更管理会議で行う:隔週、課長級以上が出席。PMが個別に判断しない

  4. A〜Dの4分類で判定する:判定の基準を先に決め、毎回同じ物差しを使う

  5. 判定結果と金額を、毎月の部長会に報告する:増えた分と減った分をセットで出す

このうち、効き目が大きかったのは2つめでした。「こういう機能が欲しい」は誰でも書けますが、「これが無いと、月に何件の申請で、誰が、どれだけ余計な手間をかけるか」は書くのに手間がかかります。結果として、本当に困っているものだけがCR票になりました。

3つめも重要です。それまでは各課がPMやベンダーに直接依頼していました。依頼する人と判断する人が1対1で向き合うと、断ることが人間関係の問題になります。隔週の会議体に移したことで、「会議で決めること」に変わりました。


■ 147件を仕分けた結果

既に受け付けていた147件も、新しい物差しで一度通し直しました。2月末までの2週間で全件を分類しています。

判定

内容

件数

金額

今期の扱い

A

当初要件に含まれる(仕様の読み方の違い)

52件

0円

契約の範囲内で対応

B

法令・制度改正への対応(必須)

18件

1,200万円

今期に全件対応

C

あると便利(業務効率の向上)

61件

1,620万円

今期9件(720万円)/第2期52件(900万円)

D

重複、または困りごとが書けなかったもの

16件

440万円

取り下げ

―

合計

147件

3,260万円

―

この表でいちばん意外だったのは、A判定が52件(35%)もあったことです。つまり3分の1は、追加でも何でもなく、最初から契約に含まれていたものでした。要件定義書の書き方があいまいで、市側は「入っている」、ベンダーは「入っていない」と読んでいたのです。

この52件をA判定に確定させたことで、追加費用が0円になっただけでなく、同じ争いが起きなくなりました。仕分けの作業には手間がかかりますが、金額以外の効果があります。

D判定16件も注目に値します。これは「困りごとが書けなかった」ものです。悪意があったわけではなく、依頼した本人も、なぜそれが欲しいのかを言葉にすると必要性が薄いと気づいたケースがほとんどでした。


■ ゼロサム枠:今期に入れるなら、同額を落とす

難しいのはC判定(あると便利)です。61件すべてを断れば1,620万円が浮きますが、それでは現場が使いにくいシステムになります。かといって全部入れれば限度額を超えます。

そこで決めたのがゼロサム枠です。C判定を今期に入れたい場合は、同じ金額ぶんの何かを今期から落とす。落とすものは、依頼した課ではなく、部長会が決めることにしました。

実際に今期へ入れたのはC判定9件、720万円ぶんです。そのかわりに、当初スコープの68手続きのうち利用見込みの低い7手続きを第2期へ送りました。この7手続きの年間申請見込みは合計480件で、全体(年間5万4,000件)の0.9%です。金額にして640万円ぶんになります。

図2 作り直し前後の着地見通し

項目

金額

当初契約額

1億4,800万円

B:法令・制度改正 18件

+1,200万円

C:今期に入れた9件

+720万円

当初スコープから第2期へ送った7手続き

−640万円

最終契約額

1億6,080万円(限度額の97.5%)

作り直さなかった場合の見通し

1億8,060万円

圧縮額

1,980万円

圧縮した1,980万円の中身は、C判定52件の第2期送り(900万円)、D判定16件の取り下げ(440万円)、当初スコープ7手続きの第2期送り(640万円)です。技術的な工夫は1つも使っていません。「今期は作らない」と決めただけです。


■ 結果(QCD)と稼働後の効果

観点

合格ライン

実績

判定

Q(品質)

受入テスト 0.25件/KStep 以下

0.20件/KStep(13件 ÷ 64KStep)

達成

C(コスト)

限度額 1億6,500万円 以内

1億6,080万円(限度額の97.5%)

達成

D(納期)

2025年10月1日 稼働

2025年10月1日 稼働

達成

品質の内訳です。

工程

検出件数

不具合密度(件/KStep)

社内基準

判定

結合テスト

92件

1.44

1.00以上

基準内

総合テスト

27件

0.42

0.60以下

基準内

受入テスト

13件

0.20

0.25以下

基準内

稼働後1か月

3件

0.05

0.10以下

基準内

稼働後3か月の効果測定値です。手続き数は68から61に減りましたが、事業目的は達成できました。

指標

目標

実績(稼働後3か月)

対象手続きの電子申請率

30%

34%

窓口予約の月間利用件数

2,000件

2,400件

窓口の平均待ち時間

13分以下

11分(稼働前18分)

第2期へ送った7手続きの年間申請見込みは全体の0.9%でしたから、電子申請率への影響はほとんどありません。落とすものを「申請件数」で選んだことが効いています。もし「難易度が高いもの」や「担当課が弱いもの」で選んでいたら、この結果にはなりませんでした。


■ 管理帳票の実物

課題管理表

ID

内容

影響

期限

状態

I-009

追加要望が口頭・メールで直接ベンダーに届き、誰が承認したか記録がない

追加費用の把握ができない

2025/2/7

完了

I-011

追加要望147件に対応すると3,260万円の追加になると判明

限度額を1,560万円超過

2025/2/14

完了

I-015

窓口ごとに申請様式の運用が異なり、共通化の可否が判断できない

電子申請機能 +12人月

2025/3/14

完了

I-022

第2期へ送る7手続きの市民周知の方法が未定

稼働後の問い合わせ増

2025/7/11

完了

I-028

職員研修の日程が9月の繁忙期と重なる

受入支援 +3日

2025/8/8

完了

リスク管理表

ID

リスク

発生度

影響

監視する数字

対応

R-02

追加要望が再びしくみの外から入る

中

限度額超過

月次の「CR票以外の依頼」件数(目標0件)

CR票のない依頼は着手しないことを、契約の覚書で明文化する

R-06

第2期の予算が確保できない

中

C判定52件と7手続きが実施されない

次年度予算要求の査定状況

第2期の内容と概算額を、9月の予算要求時点で資料化しておく

R-10

電子申請の利用が伸びない

中

事業目的が未達

稼働後3か月の電子申請率(目標30%)

申請件数の多い上位15手続きを先に公開する

R-14

既存の住民記録システム側の改修が遅れる

低

結合テスト +10日

既存側ベンダーの週次進捗

連携部をモックで先行テストできるようにする

R-02の「監視する数字」に注目してください。目標0件です。0件を目標に置くと、1件でも出た月にすぐ話題になります。「なるべく減らす」では、誰も気づけません。

TODO

内容

担当

期限

状態

CR票の様式を作成し、全課に配布

情報政策課

2025/2/14

完了

既受付147件をCR票に転記し、A〜Dに分類

情報政策課・ベンダーPL

2025/2/28

完了

「CR票のない依頼は着手しない」旨の覚書を締結

契約担当

2025/3/7

完了

第2期へ送る7手続きの選定基準を部長会で承認

PM

2025/3/28

完了

第2期の概算額資料を予算要求に間に合わせる

情報政策課

2025/9/12

完了


■ 振り返りと、自分の現場で使うなら

まず反省点です。

  • 変更管理のルールを、着手時に作っていなかった:契約書には「変更は協議のうえ」としか書いておらず、具体的な手順が無かった

  • 要件定義を紙の様式だけで進めた:画面イメージを見せるのが基本設計からだったため、運用の違いが11月まで表に出なかった

  • 基本設計が10営業日遅れた:2月を仕分けに使ったぶんです。これは必要な遅れでしたが、後工程を圧縮して吸収しました

次に効いた点です。

  • 金額ではなく「入り方」を先に調べた:147件中133件に承認記録が無いと分かった時点で、打つ手が決まった

  • 「困りごと」を書かせた:欲しい機能ではなく困りごとを聞くと、本当に必要なものだけが残る

  • 判定する人を、依頼する人から分けた:断ることが人間関係の問題でなくなった

  • 落とすものを「申請件数」で選んだ:事業目的への影響を最小にできた

最後に、明日から使える形にまとめます。追加要望で費用が膨らんできたとき、まず次の3つを調べてください。

  1. その要望は、どこから、どうやって入ってきたか:承認の記録があるものは何件か。記録が無いものが多ければ、問題は要望の中身ではなく入口にあります

  2. すでに契約に含まれているものは何件か:この事例では35%がそうでした。仕分けるだけで金額が減ります

  3. 「この変更がないと何が困るか」を書いてもらえるか:書けないものは、依頼した本人にとっても優先度が低い可能性があります

そして、いちばん大事なことを最後に書きます。要望を断るしくみを作るのではなく、要望の優先順位を依頼した側が考えてくれるしくみを作ってください。ゼロサム枠がそれです。「入れてもいいが、同額ぶん落とす」と言うと、各課は自分たちで優先順位を付け始めます。断るより、ずっと早く決まります。

ユーザーコメント(0)

  • まだコメントはありません。

ログイン するとコメントを投稿できます。

ホーム画面に追加する