Lazy Diary @ Hatena Blog

PowerShell / Java / miscellaneous things about software development, Tips & Gochas. CC BY-SA 4.0/Apache License 2.0

デジタル庁 情報システム調達改革検討会のフォローアップ資料を読む

www.nikkei.com

日本の公共調達でアジャイル開発プロセス(以下、アジャイル開発)を採用しようと思ったら、調達方式・契約形態の話は当然避けて通れません。2022年度にデジタル庁は「情報システム調達改革検討会」を立ち上げました。

www.digital.go.jp

2022年度の成果としてまとめられたデジタル庁情報システム調達改革検討会 最終報告書 簡易版では「アジャイル開発の導入ガイドの整備」「契約方式・調達仕様書・調達方式の整備」をやっていくぞということになっています。

で、その後2023年度が終わり、今年1年で何をやって、何が分かり、何ができたんだっけ?という資料である 2023年度デジタル庁情報システム調達改革のフォローアップ が出てきました。 簡易版の方は内容が要約されすぎてて成果しか書かれておらず、その背景にどういう思いがあるんだろう?とかが分からないので通常版の方を見た方がいいです。

で、p.12が「実際にこういうことをやってみました」という内容、p.14~16がその結果分かったことのまとめです。どうも、発注元も課題が大量にあるし、受注者側も気を抜けない状況という感じのように読めます。

  • p.12で「アジャイル開発の採用や調達単位変更の試行」を行ったとあるのですが、結局2022年度の最終報告書に書かれていた「アジャイル開発の導入ガイドの整備」「契約方式・調達仕様書・調達方式の整備」とかは実施されていない模様。最終報告書が出たのが2023年3月だったので、当然2023年度予算はそれよりずっと前に提出されているわけで、2023年度はいったん最終報告書の内容は横に置いておいて、予算策定時に検討されていた内容?として「試行してみようぜ」をやったってことなんですかね。

  • p.14は主に「ウォーターフォール型開発だったら、発注元は発注後の作業はそんなに多くなくても回せていたのに、アジャイル開発だとスクラムイベントとかで発注後も定期的な稼動発生してツラい」とかいう意味だと思われます。ほかにもスクラムでやろうと思ったら特にプロダクトオーナーには超人が求められるわけで、そりゃ発注を細分化しようとすればリソースの問題は出るだろうな、と思います。あとは今後の取り組みに「外部の先進的な成功例も参考とし」と書かれているのがちょっときな臭い。参考元が民間だと「アジャイル開発にしたらよりチャリンチャリンするか?」「早期撤退が良い判断と認められるか?」、参考元が米国だと「官公庁におけるITエンジニアの総数の違い」とかがあるので、自分としてはローカライズが必須、場合によっては前提条件ふまえて一から指針を作った方が早道なのではという気がしているのですが……

  • p.15は契約形態の話で、調達改革検討会の中でも「公共調達なんだからまず透明性を確保しなさいよ」と言われていた点につながるので、デジ庁の中だけに閉じる話じゃないのでは?というのが感想。

  • p.16は調達単位の設定の話。まず前提として「発注元の人的リソースに不足がありツラい」という状況と、「中小・スタートアップ企業等の多様な事業者が参入出来る案件規模に分割」したいという思惑が噛み合っていないように見える。さらに、受注者の規模をめがけて調達単位を区切ろうとすると、既設システムがある場合なんかは「システムとしてソフトウェア工学的に適切な分割範囲」でなくなる(分割損が出るだけならまだよくて、発注単位優先で分けた結果発注先間で作業に順序関係が発生したらその調整も必要だし、場合によっては発注先ごとに業務知識量が異なることで発生する軋轢みたいなものまで気にする必要が出てくる)。さらに、「調達単位の細分化に係るリスクやメリット・デメリットについて、発注担当者の理解が進んでいない」とか言われている。これって「何がしたいのか自分に思いはありませんが、上からアジャイル開発で調達範囲分割しろと言われております!」みたいな状況を誘発するのでは?