「DX推進しましょう」と掛け声をかけても、現場から返ってくるのはこんな言葉です。

「でも、稟議通りませんよ」
「仕様書が出ないと契約できません」
「前年度と同じものじゃないと、調達部から怒られます」

民間企業でこれなら、自治体はもっと深刻です。
予算年度ごとに「何をいくら買うか」を決めて、契約を結んで、検収して……という厳格な流れが死ぬほど堅いんです。

だから、「走りながら決める」というアジャイルな開発とは相容れない。

でも、自治体DXが進みだしたのは、その「堅さ」を理解した上で、逆手に取ったからです。
その工夫が、実は民間企業のDXにも効きます。


なぜ「仕様書」が絶対悪になるのか

DXが文化の業界(スタートアップとか)では、「仕様書なんか作るな、動くコードを作れ」という空気があります。

気持ちはわかります。仕様書を完璧に作って、その通りに開発したら、「実は違うものが欲しかった」なんてよくあることですから。

でも、そう言える組織は、「変更に強い体制」を持っています。

  • 予算が足りなくなったら継ぎ足す
  • 人が足りなくなったら引っぱってくる
  • スケジュールがズレたら伸ばす

つまり、変更コストを社内で吸収できるだけの権限と資金があるってことです。

自治体や大企業の調達はそうじゃありません。

  • 予算は年度単位で決まり、契約は「これだけ」と明記されていて、追加予算なんて取れません。
  • だから「仕様書を完璧にする」という戦略がうまれたんです。

それはそれで正しい戦略なんですが、問題はそこからです。


「調達」と「開発」の時間軸がズレている

自治体のDX事例を見ると、調達に3ヶ月、契約に1ヶ月、開発に6ヶ月。
合計で10ヶ月かかって、やっと「何かが動く」という状態になります。

その10ヶ月の間に、こんな気づきが出てきます。

  • 「あ、やっぱりこっちの機能が先に欲しい」
  • 「その仕様では現場が使えない」

でも、契約書に「△△機能を6月末までに納品する」と書いてあるから、仕様変更ができない。

結果、「誰も使わないシステム」が納品されて、フォルダの奥深くに眠る——。

これ、自治体の話ではなく、あなたの会社でも起きていませんか?

「前年度の調達で決まった予算なので変更できません」とか、「契約書にはこう書いてあるから」とか。


調達を「制約」から「武器」に変える

ここからが本題です。

自治体の優秀なDX担当者たちは、この「調達の堅さ」を逆手に取っています。

① 「概要仕様書」と「詳細仕様書」を分ける

最初の調達では、全体像だけを決めて契約する

  • 「ユーザー認証機能を持つ」
  • 「データはクラウドに置く」

くらい。

その後のアジャイル開発で、月ごとに「何ができたか」を検査会(スプリントレビュー)で確認して、次のフェーズの詳細を詰める。

② 「段階発注」という武器

最初は100万円の概要設計までの契約

その結果を見てから、「本当に必要か」を判断して、本開発(500万円)の発注を決める。

やってみたら違ったら、そこで止める。損失は100万円で済む。

③ 「事業者の責任」と「市民の声」を分ける

デジタル庁やガバメントクラウドのような取り組みでも、次のような線引きが明確です。

  • 「セキュリティは事業者が責任を持つ」
  • 「ユーザーの声は定期会議で吸い上げる」

この**「責任分界」**が決まると、変更の判断が早くなります。


民間企業がやるべき同じ工夫

調達の自由度が高い民間企業だからこそ、逆に「調達を武器にする」ことができます。

今週、経営が決めること(1つだけ)

「全社DXプロジェクトの予算配分を『年度ごと・一括』から『四半期ごと・段階的』に変える」

具体的には:

Q1(1〜3月):調査・設計・仮説検証に予算を割く
「本当に必要か」を事実で検証する期間。ここで「やめる」という判断もあり。

Q2以降:実装予算の実行を、Q1の成果に基づいて承認する

こうすることで、「契約を何度も結ぶ」という煩雑さを避けながら、**「変更に強い体制」**が作れます。

言い換えれば

  • 調達の透明性を保つ(経営の説明責任)
  • 現場の学習速度を上げる(事実による判断)
  • 失敗を小さく抑える(段階的な予算消化)

これら全てが、「調達の枠の中」で実現できます


問いかけ

今、あなたの会社の大型DXプロジェクト予算は、いつ、どうやって「確定」されていますか?

「年度始めに全部決めて、後は手をつけない」としたら、現場は「仕様書通りに作るしかない」という牢獄に入っています。

来週は、その「牢獄感」が特に強い金融業界の「規制」が、実は突破口になるという話をします。


参考資料