エンジニアが殺到!経産省が極秘にはじめた「電子政府計画」の本気度

一体、なにをするつもりなのか

初めて「アジャイル」を採用

また、行政チームと3人のCIO補佐官、新規採用のプロダクトマネージャーで「アジャイル開発の体制を整える」と明言していることにも筆者は注目している。中央省庁やその外郭機関が表立ってアジャイル開発を採用するのは、ほとんど初めてのケースだからだ。

ITの世界で「アジャイル」と言えば、脱20世紀モデル(脱レガシー/脱SIer/クラウド志向)を意味する。実際のシステム開発を既存の大手ITベンダーに発注したのでは、クラウド型のワンストップ/ワンスオンリーサービスはおぼつかないーーという懸念は、ある程度払拭される。

読者の中には馴染みが薄い方もいると思うので、「アジャイル開発」について説明しておこう。

アジャイルとは英語の「agile」(俊敏・機敏)のこと。本稿では詳細は省くが、一般的な事務計算系のシステム開発方式は「ウォーターフォール(滝)」と呼ばれ、その期間を短縮する手法はRAD(Rapid Application Development)と呼ばれる。滝のように上流から下流へと、目標を定め、行程を順にクリアしてゆくのがウォーターフォール方式の基本だ。

しかし現在は、本格的なクラウド時代を迎え、ビジネス環境の変化もめまぐるしい。それに的確に対応するシステムを作るには、ウォーターフォール方式では時間がかかり過ぎる。「何をしたいか」が確定するのを待って、それからようやくシステムを作り始めたのでは、完成したとき状況が一変しているかもしれない。

それならば、分かっているところ・できるところから作り始め、それを動かしながら、機能を追加したり改善を重ねていけばいい。小さなシステムを育てるという意味で、「スモールスタート」という言葉がしばしば使われる。

ウォーターフォールだと、最短でも週単位の工程で設計・開発・テスト・実装・運用・改善のサイクルを回すが、それを1日以下(数時間)に短縮して何十回、何百回と繰り返す。開発工程の区切りがなくなるので「完成」もない。これが「アジャイル」と呼ばれる開発手法で、「納期なき受託」とも称される。

「できるところから作る」のだから、発注者(実務担当者)と受注者(ITエンジニア)が一緒に仕事をしたほうがいい。そこで「DXオフィス」では、民間から豊富な経験値を持つエンジニアを臨時職員として採用し、政策立案や事務管理の実務を担う官僚とチームを組む形をとっている。

またDXオフィスには、補助金申請システムや中小企業向け行政サービスの開発を通じて、ウォーターフォールとアジャイルのハイブリッド化(バイモーダル)および、アジャイル開発における省内共通API(Application Program Interface)仕様や開発標準、ベンダー・マネージメント手法を確立していく狙いもある。

これまで遅々として進まなかった電子政府システムの構築に喝を入れると同時に、産業界の脱レガシー推進、アジャイル開発手法の普及、ITベンダーの質的転換という一石三鳥を目論んでいるようだ。

現状の反省よりも…

今回の取り組みの背景には、安倍首相が昨年12月、高度情報通信ネットワーク社会推進戦略本部(IT総合戦略本部)と官民データ活用推進戦略会議の合同会議で「行政手続きにおける電子申請に紙の書類を添付することを一括して撤廃する」と述べたことがある。

さらに、あまり取りざたされることはなかったが、今年1月の国会における所信表明演説でも、安倍首相は「法人登記手続きはオンラインで24時間以内に完了」を盛り込んだ。

DXオフィスの担当者は、近い将来の展望として、「この動きを電子行政システム全体に広げていきたい」と語っている。

いきなりこんな大きな話を聞くと、さまざまな疑問も浮かんではくる。「その前に、省庁のバックオフィス系業務の電子化は行政の生産性を改善したのか」「申請書類のPDF化がデータの利活用を阻害していないか」「業務ごとにシステムが最適化されたためにデータ連携ができなくなっていないか」…こうした現状の反省からまずは入るべきではないか、との声もある。

それはそれで重要だが、ただ、アジャイル開発では「まずやってみる」が大切なのだ。