１．あるべき姿

岩崎和隆です。

業務モデリングの調査研究、２つあったのですね。資料を教えてくださり、ありがとうございます。

資料から離れてしまいますが、行政手続法の常識のない法律があって、驚いたことがあります。それから、今は、制度担当と話す機会が多いのですが、プログラミング経験がないためか、制度においてIF分岐で考慮漏れが多くて困ります。そのため、コンピュータなしの手作業であっても制度運営に支障を来します。

私の経験ですが、ある条件のときにゼロ除算が発生する制度がありました。制度開始後の初回の計算前に見つけて、制度を修正してもらいました。全体の0.5％程度発生するケースなので、そんなに少なくないのですが。難しい制度を考えようとして、担当者の能力を超えてしまい、自ら躓いている印象があります。難しい制度を作ると制度の細部まで整合性を保って設計するのが難しく、仮にその時の担当者ができても、後任が制度を維持管理できなくなります。保守しづらいプログラムと同じです。

制度と業務システムの関係では、今までは、制度ありきでしたが、業務コストを考慮すると、今後は、業務システムありきという発想に変える必要があると考えます。官公庁では、制度が法律、政令、省令、条例、規則などという形で制定されているため、業務システムを検討していて、法律どおりでは業務システムの設計に支障を来すことが判明しても、制度を見直すことが、ほぼ無理です。そのため、制度を先に決めるとうまくいきません。制度設計において業務コストを考慮するということは、目新しいことではなく、数十年前から行政学では言われていることです。

画面のバリデーションまで仕様書で指定してくれないという話は、メインフレームの一者随意契約からクライアント・サーバ・システムの競争的調達への移行で起こったことではなく、それとは別に、そういうことになったのでしょうか。

難易度と規模感がないと見積もりは難しいので、データモデリングとプロトタイプのコンペでは、応札時に価格の提案が必要な総合評価落札方式一般競争入札は、難しいかもしれません。企画提案方式随意契約で、優先交渉権者を選定して、開発内容と価格の交渉をした方がよいかもしれません。

ただし、都道府県及び政令市では、20万SDR以上では企画提案方式随意契約が使えません。【根拠】地方公共団体の物品等又は特定役務の調達手続の特例を定める政令（平成 7 年政令第 372 号）第 11 条第 1 項で「特定地方公共団体の締結する特定調達契約については、地方自治法施行令第百六十七条の二第一項（第五号、第八号及び第九号に係る部分に限る。）（略）によるほか、次に掲げる場合に該当するときに限り、地方自治法第二百三十四条第二項の規定により随意契約によることができる。（以下略）」と規定されているため。

なお、憲法と条約以外の法令は、国民、住民の理解が得られる内容であれば、いくらでも変更可能と私は考えております。

RPAは、OCRならまだしも、画面読み取りは、システム管理者が画面を変更したら、業務継続性を確保できません。システム管理者自身が使うなら、知らないうちに画面が変わることがないので、ぎりぎりOKかもしれません。

神奈川県でも、そういうことを知らない方が、画面読み取りのRPA活用の旗振りをしているので、危ないです。RPAについては、2019年なので古いですが、論文を執筆しています。

https://www.jstage.jst.go.jp/article/proceedingsissj/15/0/15_S1-B3/_pdf/-char/ja

この内容を、情報システム学会で口頭発表しました。セッションには、研究者だけでなくIT企業の方も参加されていたところ、異論はありませんでしたし、あるIT企業のOBからは、強く賛成されたので、概ねあっていると考えております。

いろいろと記しておいて恐縮ですが、話が拡散してきたので、続きは、別の機会にしましょうか。

ただ、調達関係は、パネルディスカッションのこともあるので、よろしければ、このメールで引き続き意見交換を続けましょうか。このメールでのディスカッションを通して、私は、データモデリングとプロトタイプのコンペでは、企画提案方式随意契約が適するかもしれないと気付くことが出来ました。

有益なことをおしえてくださり、ありがとうございます。

今後とも、なにとぞよろしくお願い申し上げます。

渡辺幸三

制度や法律先行ですか。民間でも同様です。最初に業務フロー（の改善版）とUI（の改善版）を手間暇かけてまとめて、それに見合うDBを設計するようなことをやって「DX」だと言っている。それでは「ピカピカの竪穴式住居」が出来上がるだけ。まずは、システムが扱う情報の論理的な形（データモデル）を明らかにする。そこからあるべき業務フローとUIを検討すべきです。

行政DXであれば、行政システムが扱う情報のデータモデルを抜本的に見直して、そこから制度や法律の調整を進める。現行の制度や法律を微調整するようなことから始めたら、やはりピカピカの竪穴式住居が出来上がります。住民にとっていいことはひとつもない。

ではデータモデリングできる業者を選べばいいのかといえば、そうではありません。この世には「構造計算したかのように見える建築図面」を納品するような業者がいるので、納品されたデータモデルがシステムを支えてくれるかどうかを検証する必要がある。そのためにモデルにもとづくプロトタイピングを業者に実施させる。手早くプロトタイピングできないとしたら、その業者は普段からプロトタイプによる検証をしていないことがわかるので、契約すべきではありません。

良好なスキルを持つ業者がいたら、データモデル、およびデータ移行済のデータベース上で動作するプロトタイプまでの開発までを準委任契約で進める。その後で、必要な制度や法律の見直しを実施する。その後ようやく、改めて業者を集めて合い見積もり可能な段階になる。そんな手順が合理的だと考えますがどうでしょう。

----

実際のところ、例のER図も眺めてみたのですが現行制度の維持を前提としてまとめ直しただけのもので、新味がないだけでなく、ER図の出来としても最悪ですよね。多重度のレベルからおかしくて、プロトタイプなんて絶対に作れません。

渡辺幸三

> そのためにも佐野さんにご紹介いただいたような、自治体が独自で行政サービス
> を構築していく仕組みづくりを模索していけたらと思います。

それはつまり、「標準仕様書」に準拠しつつ各自治体が自分たちで「標準システム」を開発するという体制ですよね。それでは従来と本質的に変わりません。そうではなく、どの自治体も格安で店子になれるような「標準行政管理システム・プラットフォーム」の開発を２５年までに終わらせるべきです。

そして、それを利用するかどうかは各自治体に決めてもらえばいい。税収の多いところや、札幌市のように業者と長期契約を結んでしまったところは独自システムで進めたらいい。税収の少ない自治体はプラットフォームに入居して、どうしても残るであろう独自部分についてはプラットフォームとＡＰＩ連係するように税収内で既存システムをカスタマイズすればいい。

そのうえで、各自治体のシステム運用コストを毎年シビアに比較する。独自システムにこだわる自治体の対税収コスト比は高くなるでしょうが、それを受け入れるかどうかは住民が決める。どんなにお金がかかろうが、どんなに不便であろうが、地元のシステム開発業者が潤うのであればそれでよし、と考える寛大な住民が多ければ堂々と独自システムでやればいい。「住民にコスパを示して選択肢を与える」ことが鍵です。

それにしても、「標準仕様書」をまとめて押し付けることだけが仕事と考えるのであれば、デジタル庁はデジタルなしろものを生み出さないという意味でデジタル庁ではなく「アナログ庁」か「ドキュメント庁」ですよね。適切に設計して適切に実装する――それがいちばん難しいのに、プロトタイプで検証されていない標準仕様書を押し付けるだけだなんて、自治体が気の毒でなりません。