コラム
中央省庁におけるDXは、行政手続の迅速化や政策実行の精度向上に直結する重要課題である。しかし現実には、システム刷新やオンライン化の案件が、開発の遅延、品質不良、再調達、国民の信頼低下を招く例が少なくない。そうした問題の多くは、開発工程そのものより前段階、すなわち調達と要件定義の局面で、すでに埋め込まれている。
失敗は開発工程ではなく「調達の瞬間」に始まっている
行政機関の情報システム調達では、公平性や透明性、予算統制、会計年度の制約が重視される。その結果として、事業目的よりも「調達可能な文書」に案件が引き寄せられ、本来は曖昧さを残したまま検証的に進めるべき課題まで、最初から固定的な要件として記述されやすい。この構造では、現場部門が抱える業務課題、制度改正の見通し、利用者体験、既存システムとの接続条件が十分に整理されないまま、機能一覧だけが先行する。
例えば、「オンライン申請を可能にする」「審査を効率化する」「データ連携を高度化する」といった政策目的は掲げられても、誰がどの画面で何を入力するのか、例外処理はどの程度発生するのか、制度改正時にどこまで柔軟に変更できるべきかといった実務要件にまで落とし込まれないまま、調達が始まる。するとベンダー側は、曖昧な仕様を前提に価格を抑えて応札するので、契約後に仕様追加や解釈のずれが噴出する。その結果、追加改修費やスケジュール圧迫、品質低下が連鎖する。
さらに中央省庁では、発注者側に十分なプロダクト責任者が不在であることも少なくない。業務部門、情報システム部門、調達部門、外部ベンダーが分かれ、最終的に何を優先するかを決める主体が曖昧になる。制度所管課は制度趣旨を説明できても、システムとしての実装優先順位を決める訓練を受けていない場合がある。他方で情報システム部門は、技術標準やセキュリティ要件には強くても、業務現場の例外処理の重みを把握しきれない。こうした要因が積み重なり、結果として使いにくい、あるいは使えないシステムができあがる。この種の失敗は技術力不足というより、調達時点での責任分担と要件形成の失敗であると言える。
加えて、単年度予算と短い調達期間も問題を深める。実証や試作、段階導入、本番前のユーザーテストといった地道な工程は、書類上は省略しやすい一方で、後工程で大きな負債となる。民間企業のDXであれば、まず小さく作り、利用データを見ながら改良することが一般的だが、行政では最初の調達で完成版が求められることが多い。それによって、その時点で確定できないものまで確定した体裁にするため、現実の運用に耐えない設計が生まれてしまう。
直近の事例に見る要件定義と調達のつまずき
例えば、厚生労働省の雇用調整助成金オンライン申請システムは、コロナ禍で申請需要が急増する中でオンライン化が急務となり、稼働後に不具合やセキュリティ上の問題が発生して運用停止と再開を繰り返した。そもそも、助成金制度は例外規定や添付書類の分岐が多く、紙運用の慣行も深く残っていた。にもかかわらず、申請者の属性ごとの導線、審査側のワークフロー、本人確認、ファイル取扱い、問い合わせ対応までを通しで設計する視点が弱かった。結局、オンライン化を実現すること自体が目的化し、どの業務をデジタル前提で再設計するかというBPRの視点が後回しにされたため、利用者にとっては入力しにくく、行政側にとっては審査効率が上がらないという二重の不全が生じた。
また、デジタル庁発足以前から政府全体で進められてきた電子政府関連の各種手続でも、制度ごとに画面設計や添付書類の考え方が異なり、利用者から見れば「オンライン化されていても使いにくい」状態が続いた。そこでは、要件定義の単位が制度所管ごとに分断され、共通UIや本人認証、データ再利用、問い合わせ導線といった横断要件が弱かったことが要因となった。結局、個別案件ごとには仕様を満たしていても、政府全体として見れば重複投資と利用者負担を増やしてしまう。
これらの事例に共通するのは、失敗の原因が単一ではないことだ。制度改正の頻度や緊急対応、既存システムの老朽化、ベンダー依存、技術人材不足など複数の要因が重なっている。それらに共通するのは、何を作るかではなく、何を先に決め、何を後で学習しながら決めるかという設計思想の欠如である。要件定義で全てを固定しようとして失敗する一方、逆に曖昧なまま契約しても失敗する。重要なのは、最初にすべてを固定することでも、曖昧なまま進めることでもない。固定すべき要件と、検証を通じて後から具体化すべき要件を切り分けることである。したがって、中央省庁のDXに必要なのは、変更を前提とした契約、段階的な検証、運用データに基づく改善を可能にする調達モデルと言える。
DXを立て直すために必要な視点とは
では、調達と要件定義はどのように変わるべきか。まず必要なことは、政策要件、業務要件、システム要件を同じ文書に押し込めないことだ。政策として実現したい価値や現場業務として守るべき制約、技術実装として選べる方式は本来別の層にある。これを混同すると、制度変更のたびにシステム全体を作り直すことになる。要件定義とは、最初に全てを決める作業ではなく、何を固定し何を変動領域として残すかを定める作業であるべきだ。
次に、中央省庁の調達は「完成品の一括発注」から「段階的成果の調達」へ比重を移す必要がある。すなわち、要件整理からプロトタイプ作成、限定運用、効果検証、本格展開までを分けて契約し、その都度レビューと改善を行う仕組みが不可欠だ。これは、アジャイル開発とも言えるが、行政におけるアジャイル開発では、利用者の反応と業務データを見ながら、意思決定を更新する必要がある。調達制度上の制約はあるにせよ、少なくとも巨大案件を初回の仕様書だけで完結させようとする発想から離れなければ、同じ失敗は繰り返される。
また、行政組織の中にプロダクトの責任者となり、アーキテクチャを理解し、データ設計や運用評価を担う中核人材がいなければ、発注者の責任は空洞化する。特に省庁のデジタル化では、調達仕様書を整える人材だけではなく、利用者視点で優先順位を決められる人材、障害発生時に業務影響を評価できる人材、改修投資の妥当性を説明できる人材が必要になる。これは単なるIT人材育成ではなく、行政運営そのものの改革と言える。
最後に重要なのは、失敗事例を「例外的な不祥事」として処理しないことだ。前述のようなオンライン申請の混乱を、緊急事態における特異な事例と片づけてしまえば、平時の大型案件でも同じ問題が形を変えて現れる。むしろ失敗事例は、中央省庁のDXが抱える構造問題を最も鮮明に映す鏡と考えるべきだ。中央省庁に求められているのは、新技術の導入競争ではない。失敗を前提に学習し、変更を制度として吸収できる調達と要件定義への転換である。それこそが、行政DXを国民にとって実効あるものへ変える出発点と言えるだろう。
