１１．岩崎さん

　岩崎和隆です。

　昨朝、参加を申し込んだら、昨日の午後の早い時刻に参加できるようになっていたので、驚きました。佐野様、厚く御礼申し上げます。

　私とITとの関わりは、次の２つになります。
（１）情報政策の研究者
（２）受注者に丸投げしている発注者（神奈川県）

　メインフレームの最後の世代、バッチ処理中心のCOBOL　50KSの設計はしたことがあります。プログラミングは、COBOL　100本以上。いずれも20世紀のことです。これらは、研修を兼ねた内製です。得意ドメインは、人事給与システムです。

　県設立法人の人事給与システム開発の発注者側PMを２回担当しました。現在は、人事給与システムの運用をしています。都道府県の情報システム全般も得意ドメインです。神奈川県の情報システムの悉皆調査を２回担当しました。行政全般も、他の方と比べれば、得意ドメインと言えるかもしれません。

　データモデリングのお話についていけるか、自信はないのですが、興味があったので、MLに参加させていただきました。

　上流工程では、情報政策研究において、ある研究の一環でデータのストックとフロー、そして機能の簡単なモデルを作りました。

　情報政策研究では、なぜ我が国の官公庁の情報システムは上手く行かないか、どうしたら上手くいくかという、ありきたりに見えて研究者が数人しかいない分野を取扱っています。当該研究分野の参照領域は、ソフトウェア工学、プロジェクトマネジメント、行政学、行政法です。

　一般紙記者に依頼され、研究成果をレクチャーしたこともございます。

　第一人者でなくても自信をもって発信することについては、学会でいつも実践しています。

　研究者紹介Webサイト（私の著作物のほぼすべてに、無料でアクセスできます。）

　https://researchmap.jp/999-z

　私の著作物の2/3を占める情報システム学会メールマガジンバックナンバーは、こちらです。

　https://www.issj.net/mm/index.html#KANKO

　私の著作物のうち、学会内限定公開のものをご覧になりたいときは、メールにてお気軽にご依頼ください。

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

*****************************************************************

岩崎　和隆（いわさき　かずたか）

リサーチマップ(webサイト）　https://researchmap.jp/999-z

岩崎和隆

　官公庁IT調達のプロポーザルの審査基準の学術研究という、今では誰もやらなくなった研究を継続しています。実務において除算方式から加算方式に代わり、技術点のウエイトが高くなり、そして誰も審査基準を研究しなくなりました。

私の研究成果では、受注希望者の能力の見極め方が課題として残っていますが、点数配分については結論が出たと考えています。

多くの審査基準は、自ら若しくは他官公庁の前例踏襲です。そのため、プロポーザルの審査基準のポテンシャルを全然活かせていません。私自身、11年前は、そうでした。

会計法令上も実務上も、失注者と国民、住民をある程度納得させらる内容であれば、いくらでも自由に審査基準を作ることができます。

（ただし、国のIT調達では価格点1/4以上という制約あり。）

日経ビジネス「プロジェクト失敗の理由、15年前から変わらず」

https://business.nikkei.com/atcl/opinion/15/100753/030700005/

で示されているとおり、IT調達は公共工事などと比べて失敗率が高いことが課題ですから、よほど簡単なものでない限り、審査基準では、受注希望者の能力を極端に重視すべきです。そして、受注者に最低限やってほしいことは、すべて必須仕様にします。

2012年に特許庁運営基盤システムの開発がとん挫したとき、報告書で能力の高い受注希望者に大幅加点という提言があったのですが、審査基準の総得点の8割ないし9割くらいまで得点を傾斜配分しないと、他の評価項目の点数で能力評価の低さをカバーしやすくなるので、実効性がありません。能力評価がほぼ同じというときに限り、他の要素で優劣をつければよいです。しかし、8割9割まで傾斜配分している例は、少ないです。

また、能力評価をいくつかの小項目に細分化して合計するのも、やめた方がよいです。経験上、小項目の合計点と、総合的な良し悪しの評価は乖離します。小項目評価でなく１つの項目で能力評価をしている審査基準は、見たことがありません。私が知らないだけかもしれませんが。

　 能力の見極め方 について、以前はプロジェクト計画書と技術的対話による心証形成を考えていたのですが、渡辺様のご提案のとおり、データモデルとプロトタイプという方法を探求した方がよいと感じます。実務で行う機会があれば、皆様のお力をお借りしたいと考えています。

　それから、ローコード、ノーコード、あるいはパッケージソフトウェアのアドオンの数のような定義が問題になる用語は、審査基準において、避けた方がよいです。いざ、採点しようとすると、困惑することになります。

　シンプルに、能力、機能その他必須を上回るサービスの内容、費用の３要素で決めればよいです。能力評価項目は細分化しない。

　最後に、IT調達では付帯的政策は論外です。もっとも、ほとんどの方が認識しているようで、審査基準に入れている方は稀です。

2023/01

情報政策ないし官公庁DX研究者と名乗っているのに、官公庁DXの定義をしていませんでした。（汗）

私の官公庁DXの定義は、次のとおりです。

現在のITの技術水準で実現可能な範囲において、国民、住民の利益を最大化すること。ITの活用にとどまらず、業務や組織も最適化すること。

ゆえに、行政の効率化等に伴う行政の経費節減は、利益に含まれますが、おまけ程度のものです。

こういう定義をしないと、官公庁では、子供だましのようなDXが横行します。ミニ改善が横行しています。それをやることは否定はしませんが、国民、住民、議会にDXやったと説明したら詐欺です。

でも、やっている本人もやった気になって自己満足してしまう。

倒産しないという共同幻想を持つ組織の性です。

本当のDXが、手軽にできるはずがありません。

それに、手軽なものだったら、ちょっとしかエキサイトできません。

いずれ、機会が来たら、本当の官公庁DXとは何か、様々な場で主張します。

-----渡辺さん

補足すると、DXはただの「抜本的な改革」ではなくて、「事業に関わる情報を全面的にデジタル化することを前提とする事業そのものの変容」なんですよね。なぜ官公庁がデジタル化に沿って事業変容しなければいけないのかと問われたならば「国民、住民の利益を最大化するため」となる。官公庁DXではこの目的がとくに意識される必要がありそうですね。