• Column
  • 官公庁DXに不可欠な“大手 × スタートアップ”の勧め

なぜ大手ITベンダーだけでは官公庁DXは進まないのか【第3回】

𡌶 俊介(ジーグラビティ 取締役COO)
2026年8月31日

前回は、官公庁におけるDX(デジタルトランスフォーメーション)を推進するには“下からアプローチ”が有効であると説明しました。「下」すなわち「基盤」を担うには、単一のアプリケーションではなく、複数のアプリケーションを横断的に設計し構築・運用する必要があるためです。そこでは、大手ITベンダーの知見や経験が不可欠です。では、全てを大手ITベンダーに任せれば官公庁DXはうまくいくのでしょうか。

 官公庁DX(デジタルトランスフォーメーション)の本質の1つに、省庁内のデータを統合しAI(人工知能)技術も使った分析や再利用により、担当職員による属人化を防ぎ、業務のスピードと品質を高めていくことにあります。

 これは民間企業にも当てはまることですが、官公庁においては国民の生活に広く結びつくことや、税金を使用するための公平性や透明性を確保するために民間企業にはない手続きが必要であることなどから、その必要性は、より高いと言えるでしょう。

基盤の構築には大手ITベンダーの知見と経験が生きる

 その官公庁DXを支える基盤は、全てのアプリケーションの結節点であると同時に、データの整合性や、アクセス権などの情報セキュリティ、システム全体の可用性といった信頼性の担保など、大規模システムが持つべき設計と実装、運用が求められる領域です。それだけに基盤においては、大規模システムへの知見と経験を持つ大手ITベンダーが担うことには合理性があります。

 官公庁のための基盤の特徴のもう1つが「オンプレミス」であることです。デジタル庁が主導する「ガバメントクラウド」の利用が進みつつありますが、一部の省庁やシステムでは、特定秘密などを扱うシステムなどが存在し、それらはガバメントクラウドを利用しないシステムとして規定されています。

 これらのシステムは従来通りオンプレミス環境での運用が必要です。そのため、これまで蓄積された大手ITベンダーの知見がそのまま生かせる機会が多く存在します。重厚なオンプレ環境の設計や構築、運用においては、クラウド環境を使ってサービスをスピード感を持って提供するスタートアップは得意ではないことも多くあります。

制度上アプリ開発に掛けられる時間は限られる

 では、職員が実際に使用するアプリケーションはどうでしょうか。基盤上で開発・実行されるアプリケーションも大手ITベンダーが担うべきなのでしょうか。

 アプリケーション開発に最も求められる点を挙げれば、それは“スピード”です。第1回で述べたように「仕事は増えているが、人は減っている」という状況に加え、官公庁特有の理由、すなわち入札制度と人事異動があるからです。この制度的な理由により、アプリケーション開発は本来、圧倒的なスピードが要求されるはずなのです。どういうことか。

 ある業務を対象にDX化を進めたいとしましょう。しかし、一般的には、すぐには取り掛かれません。次年度の予算確保に向けて、まず事業要求を行い、概算要求(予算要求)などを経て、さらに事業規模が一定以上であれば財務省との折衝なども必要になります。事業企画から予算確保まで制度上1年かかるのです。

 翌年度、承認された予算を執行しますが、公示、入札などを経て落札業者が決まるまでに、さらに時間を要する場合があります。落札業者が、営業活動を通して事業の目的や内容を理解していればプロジェクトを円滑に開始できるかもしれません。しかし、一般競争入札では、どの事業者が落札するかは分かりません。プロジェクトの背景を理解していない事業者が落札してしまうこともあり得ます。

 そうなると、実質的にプロジェクトを開始するまでに、さらに時間を要します。官公庁に特有の事業要求から調達までの手続きにより、プロジェクト開始の時点で事業企画から1年以上が経過しているのです。

 もう1つのポイントが人事異動です。幅広い経験によるキャリア形成や組織の活性化、不正防止といった理由から、組織の特性上、必要な面はあります。ただ、そのサイクルは、一般的には2~3年のことが多く、役職が上がるほど短くなる傾向があります。

 仮に2年での異動を前提にすると、事業を企画した責任者も、プロジェクト開始時には任期がすでに1年を切っており、この責任者のもとに残されている開発期間は限られるのです(図1)。

図1:任期中にアプリケーション開発に掛けられる時間は限られる

 もっとも入札時に調達仕様書が作成されているため、責任者の異動があったとしてもプロジェクトは契約期間内は継続します。

 しかし、後任の責任者が前任者の取り組みを完全に踏襲するとは限りません。「もっとこうしたほうがいいのではないか」「優先順位を変更しよう」といった話が出てくることがあります。調達仕様書はシステムの要件定義書とは異なり抽象的な表現で、いかようにも受け取れるものが多いため、変更を余儀なくされる可能性もあります。