DXを支援するスパイスファクトリーが報道機関向けの公的機関DXの勉強会を実施。そこで見えた課題とは？

デジタルトランスフォーメーション（DX）を支援するインテグレーター、スパイスファクトリー株式会社が報道機関向けに勉強会を実施し、公的機関でのDXについてソフトウェア開発手法やプロジェクト体制、事例を交えて解説を行った。今回はこの勉強会から、DXを推進する際の課題についての考察を解説したい。

勉強会はZoomによるオンライン配信で行われ、スパイスファクトリーのCEOや東京都とのプロジェクトに関わったコンサルタント、そして外部講師として一般社団法人行政情報システム研究所の主席研究員などがプレゼンテーションを行い、最後に質疑応答という形式となった。

報道機関向けの勉強会で公共機関におけるDXを解説

まずスパイスファクトリーのCEOである高木広之介氏による企業紹介とアジャイル開発の解説に続いて、行政情報システム研究所の狩野英司氏がプレゼンテーションを行い、自治体におけるDXの要点としてローコード開発を解説した。

ローコード開発を新たなサービス開発の手法として紹介

狩野氏はコロナ禍の影響から「現場主導のデジタル化が行われた」と紹介し、その中でローコード開発、現場の職務担当者によるソフトウェア開発の内製化が行われたと解説。

この例では職員が1週間で無償の開発ツールMicrosoft Power Platformによって業務をシステム化し、それが各部門に拡がっていると解説した。しかしながら次のスライドではオンライン化、ペーパーレス化の次に行われるべき改革としてDXを位置付け、デジタルを前提に業務を再設計するべきと提案していることと矛盾を感じるのは筆者だけだろうか。

オンライン化、ペーパーレス化の次のDXでは置き換えではなく再設計が必要

質疑応答において「これまでLotus Notesを始めとしてエンドユーザーコンピューティングという名称でさまざまなエンドユーザー、現場担当による業務のコンピュータ化が行われてきたが、どれもメンテナンスにおいて大きな課題を残して持続しなかった。それがローコード開発で解消されるという根拠は何か？」と質問したところ、「これまでのツールよりも容易に他部門にも移植することが可能で利用が拡がる」という若干的外れな回答が返ってきた。

ローコード開発が現場担当者による知見から出発していることから考えると、大局的に業務全体を見渡して根本からデジタルプラットフォームによる再設計が行われるとは考えづらい。ローコード開発もRPA（Robotic Process Automation）と同様、今実行していることの置き換えという意味合いが強く、抜本的にデジタルで改善されるというのは希望的願望だろう。またメンテナンスに必要な仕様書のドキュメント化、テストの実施、異常ケースの対応など、ソフトウェア開発に必須なプロセスが省かれているのも現場担当者にとっては盲点だし、情報システム担当にとっては無視できない弱点だ。

また勉強会前半から、これまでのウォーターフォール開発ではなくアジャイル開発、特にスクラムによる開発手法を重点的に解説し、素早く変化に対応できるソフトウェア開発の方法論として公的機関においても効果を発揮すると説明。特にe-Govでのソフトウェア開発はデザイン思考を取り入れて、ユーザビリティテストなどによって予め仕様ありきの開発ではなくユーザーの評価を取り入れて設計に取り込み、改善を続けたことを紹介。

アジャイル型プロジェクトでは発注～受注という関係ではなく一体となった体制が必要

ここまででアジャイル開発の良さを強調した狩野氏のプレゼンテーションは終わり、続いてスパイスファクトリーのプロジェクトマネージャーが東京都のデジタルサービス局でのシステム開発の内容を解説した。

COOとプロジェクトマネージャーが東京都の事例を紹介

ここでは2022年10月から2023年3月の6ヶ月に渡って開発された4つのプロダクトについて解説を行っている。特に注目すべきは請負契約ではなく準委託契約で時間単価による支払いがなされていることだろう。

目的はスクラムによる開発を実践し、知見を得ること

ここではプロジェクトの目的にスクラムによる開発を実践し、プレイブックとしてまとめることまでがスコープとして定義されていることに注目したい。つまり実験的にアジャイル開発、スクラムを試してみたかったということだろう。約6ヶ月で終了する規模のシステム開発で収まっているのもそのためだと思われる。

時間契約の中で最大の価値を提供し、スクラムを体験するのが目的

このように予算と人員に余裕がある組織にアジャイル開発の経験を持つインテグレーターが手を組んで臨むのであれば、「スクラムを試してみる」ことも可能だろう。しかしそもそも請負契約から準委託契約に移行すること事態が大きな課題であることは明らかだ。

補足のスライドから。準委託契約を締結するための課題が整理されている

これはプレゼンテーションとしては使われずに補足として提供されたスライドからの引用だが、請負契約から委託契約に移行するためには費用の妥当性、どのプロジェクトに適用するのかの判断を誰がやるのかという大きな課題が提示されている。東京都庁であれば平均3年程度で職員は他部門に異動となるという公務員のキャリアパスを考慮すれば、開発を行うエンジニアと同じチームで一緒になって大きなソフトウェア開発を行い、継続して改善を行うという終わりなき開発プロジェクトを公的機関が採用するのは非常に困難だろう。この事例のように半年で終了する小さなプロジェクトだけをアジャイルにしても、それを継続してメンテナンスする責任を負うのは業者側になりかねない。

質疑応答では「定期的に異動する公務員にアジャイル開発を促してもそれが定着するとは思えない。それを実現するためのやり方はトップダウンなのか、ボトムアップなのか？」と訊ねてみたところ、「これはトップダウンでやるしかない。そういう意識改革が必要」という回答だった。「東京都の公務員のトップは小池百合子さんだが、彼女の意識を変えるのか？」との質問には「そうだ」と回答が返ってきた。

しかしながらその意識改革はシステムインテグレーターの業務範疇を超えているし、コンサルティングサービスを提供する大手コンサルタントであってもそこまで介入することは難しいのではないか。公的機関が請負契約から準委託契約に移行するのは「言うは易し行うは難し」の典型であり、実際には法改正も視野に入れないと実現できないと思う。

事実民間企業であっても「アジャイル開発を取り入れた別組織を作ってみたが、その成果や評価については四半期ごとの取締役会では苦労している」という話を某大手テレコム事業者のコメントとして聞いたことがある。さらに都庁のような公的機関であれば、選択の公平性が担保できる請負契約から特定業者との癒着とも受け取られかねない準委託契約に移行することは、透明性を確保するという意味からも難しいのではないか。成功体験が少ないことで費用の妥当性、適正なプロジェクト選択、成果物検収の定義が明らかにできないのは、成功事例が少ないのが原因ではなく「どうしてウォーターフォールではなくアジャイル開発が必要なのか？」を真摯に研究して、その適応の妥当性を議論する以外ないだろう。

他の部署や省庁がやっているからという横並びのボトムアップでのアジャイル開発が浸透するとは思えないが、都知事の意識改革につながる成功例としてスパイスファクトリーの事例が効果を出すことに期待したい。