アイディアの問題報告 | デジタル改革アイデアボックス

あなたと創るデジタル社会

デジタル改革アイデアボックス


アイディアの問題報告

対象の内容

標準レイアウトの失敗を繰り返さないために…制度改正に強い"手法の標準化"が必要

アイデアボックスをしばらく見ていたのですが、システム標準化の期待値が高すぎるように思いました。 中間標準レイアウトの時も「これでマルチベンダーができる」と意気込んでおられましたが、産総研フレームワーク等を導入していない自治体は制度改正のたびに巨額の制度改正改修費を特命随契でベンダーに巻き上げられてしまいます。 そういうことにならないための標準化…だったと思うのです。 そのころはベンダー側にいたので、標準レイアウト対応の表に「〇」をつけるために全力で取り組んでいたのですが、結局のところ「幹の部分は標準、枝葉はお客様の実情に合わせてカスタマイズできます。やっぱり自治体の個性も大切ですよね。」ということで、自治体によって微妙に異なる「標準レイアウト対応版」が生み出され、制度改正改修のたびに、パッケージアップグレード費用「とは別の」個別カスタマイズ分対応費用というお金を頂けたわけです。 そもそも「システムにプログラミングが必要だ」という前提条件を疑ってください。 影響調査をしてパッケージのコードを反映して、更に個別カスタマイズ部分は手作業で…という仕組みから脱却するのは今しかないと思うのです。 神戸市の給付金の取り組みで脚光を浴びていましたが「ローコード開発」という便利な手法が存在しています。 さすがにPowerAppsでは基幹系システムを作ることはできません、と思います、が。 京都市の失敗事例が注目されていますが、その中でさらっと触れられている「Outsystems Platform」 https://xtech.nikkei.com/it/atcl/column/14/346926/101101158/ これについては「福祉系のオンライン処理の刷新を予定通りに終了させている」とあり、つまりはそういうことです。 標準的な仕様のモデリングが終わったら、実装は基幹系業務システムにも耐えるローコード開発ツールを使う。1つのツール(モデリング手法)、1つのDB、1つの言語に統一する。 #個人的にはOutsystems、SQL-Server、C#が良いと思います…理由はデジタル庁に呼んでください! 制度改正があるたびに、具体的にこのオブジェクトをこう直せ、という指示もセットで出す。 それでようやくベンダー縛りの巨額特命随契から自治体が開放されるのだと思うのです。

報告/依頼内容
ページの先頭へ