本文へ移動

デジタル庁情報システム調達改革検討会（第3回）

概要

  • 日時：令和4年（2022年）9月7日（水）13時00分から14時30分まで
  • 場所：オンライン
  • 議事次第：
    1. 開会
    2. 議事
      1. 第3回検討会の進め方
      2. 各論点の概要
      3. 自由討議
    3. 閉会

資料

関連政策

議事概要

日時

  • 令和4年（2022年）9月7日（水）13時00分から14時30分まで

場所

  • オンライン

出席委員

梶川委員、川澤委員、木村委員、坂下委員、隅屋委員

議事概要

事務局から「アジャイル開発よりも大規模一括開発が主流」、「細分化に向けた発注能力強化」、「アジャイル開発の経験・知見向上」、「発注者の仕様書・契約書作成スキル向上」、「発注者の提案価格・サービス評価の能力向上」、「調達実績等を蓄積・共有し活用する仕組み」について説明があり、各論点の説明後自由討議に移行し、活発な意見が出された。各委員からの主な意見は下記のとおり。

A-2「アジャイル開発よりも大規模一括開発が主流」、「細分化に向けた発注能力強化」、 A-4「アジャイル開発の経験・知見向上」について

  • アジャイル開発については世界の潮流を踏まえ、どこまで日本国内でやっていくか試行錯誤しながら検討していく必要があり、デジタル庁を中心に検討を進めていくべき点について異論はない。
  • 調達単位の細分化については、分割発注はそれ自体が目的ではなく、適切なシステムがどのような単位で疎結合するか密結合するかを、まず検討すべきではないか。過去の失敗は、密結合を解消せずに分割発注したことが原因だと思う。分割ありき、統合ありきではなく、適切なシステム設計のために制度設計を考えてほしい。
  • 調達時の成果物指定に関して、調達事務負荷を勘案し調達単位を従前と同様とすると資料に記載があるが、アジャイル開発の意義がどこまで出てくるのか懸念した。
  • アジャイル開発に関するガイドの作成については賛成である。その中で、フルコストという考え方も必要ではないかと考えている。使用期間が長いのであれば、また、特に一者応札では（その後の調達により）保守費用がかかることも想定されるので、自分たちで一定程度メンテナンスできる方が、フルコストとしては効率的という場合も考えられる。また、1つのプロジェクトでアジャイル開発に担当者が習熟すれば、他のシステム開発のマネジメントコストが安くなることもあるので、複数事業のフルコストを考える必要がある。したがって、アジャイル開発の対象を考える際の観点にフルコストという考えを入れてもいいのではないか。
  • 調達を細分化した際に、複数回レビューが行われるとの指摘があったが、フルコストを考えられるような、複数の事業をまとめたレビューが必要になると思うので、開発対象とレビューの対象をリンクさせる必要がある。行政レビューは事業単位なので整理は必要だが、観点として入れてよいのではないか。
  • 自治体でのシステム調達の見直しも視野に入れる必要があると思う。各自治体で同じようなシステムを調達するために、本庁が共通仕様書を示しているシステム調達もある。各自治体の調達担当者が集まってアジャイルで開発を行うことで、各自治体のシステム開発を進める際の参考となるようなプロジェクトがあってもよいのではないか。
  • アジャイル開発のマニュアルの作成はよいことだが、アジャイル開発は、行政機関でも昔から言われているPDCAを開発に近づけたものだと思うので、受け入れられやすい・読みやすいマニュアルを作成できればよいのではないか。
  • アジャイル開発を民間では請負契約で委託している事例もある。業務分担や責任分配の問題など、契約類型だけに問題があるのではないため、契約書の雛形を作るうえでは事業者の意見を聞きながら取り組んでほしい。単純に準委任とするだけでは国にとって使いにくいものになる懸念がある。
  • 職員の異動について改善をするのは他の業務とも関連するので難しい。個人の能力だけではなく、部署に知見が残るような体制を用意する方針がいいのではないか。特に育休のような仕組みを整える中で、個人に依存している状況はよくないので、部署をしっかり育成して知識のストックができる体制に変える方がいいのではないか。
  • 調達の細分化による事務負荷の増大については、契約書の雛形を、調達を細分化したときに使いやすいものにする必要がある。細分化をしていく中で求められる契約条項が出てくるものもあるので、契約書の雛形を作る班が、細分化を担当する班と連携して雛形を作成することが事務負担の軽減につながると思う。
  • アジャイル開発という新しい体制にする以上、従来のウォーターフォール型に比べて必要な人数も変わってくると思うので、どこに人が必要なのかを分析し、必要性が高まった場所により多く人を割り当てられるようにするといい。特に紙決済でなくなっている点も踏まえ、必要なところに人員を割り当てられるとよいのではないかと考えている。
  • アジャイル開発について、ウォーターフォール型の開発とアジャイル開発は二項対立する概念ではない。製品仕様が定まっているならウォーターフォール型で問題なく、製品仕様がしっかり決まっていないからアジャイルが開発となっている。そのため、ケースバイケースで考えていただきたい。問題のあったアプリ開発がアジャイルで開発した場合にどうだったのかを振り返ると、知見が溜まるのではないか。
  • 合理的な調達単位の検討について、履行可能性や技術妥当性やコストは必要条件ではあるが、十分条件が分からない。技術妥当性や履行可能性とは何なのかをしっかりと解説するマニュアルを作って広めてほしい。デジタル庁であれば他府省のシステムを見ることができるし、民間からもシステム関係者が集まっていることから、それらの知見を踏まえてマニュアルを作ってほしい。また、システム疎結合化と調達単位細分化の調査研究の実施は賛成である。
  • アジャイル開発のマニュアルやガイドについて作成することと、デジタル庁から始めることについては賛成である。職員がアジャイル開発を適用すべきか分かりやすいように、例えば国民がUI・UXを使うものなど、具体的なプロダクトの例などを示してアジャイル開発を適用したほうがいい事例を示すことが大事だと考える。ガイドにチームの要件などがあると思うが、現在の府省の体制だと当てはまらないことが多いと思うので、このチームがあるならアジャイルしてもよいではなく、アジャイル開発が必要なので、こういうチーム体制にするというように、アジャイル開発にトライできるような、促進するようなマニュアル・ガイドにしていただきたい。
  • アジャイル開発のトレーニングは大事なのでぜひ進めてほしい。プロダクトオーナー・組織リーダ向けの研修と同時に、検収を行うメンバー向けのトレーニングも必要である。検収側にITの知識がないという事例も聞いているので、検収を行うメンバー向けのトレーニングも考慮してほしい。
  • 調達単位の細分化について、不確実性を考えていくとリスクに対応するためには重厚長大なシステムを作ることは、今後難しくなり、なるべく避けたほうがいいのではないか。今後府省でシステムを作る際は、今まではスクラッチ開発ありきでプロジェクトを始めることが主流であったが、まずは行政でも使えるプロダクトが民間に存在しないか調べてもらい、次にカスタマイズが可能かを検討して、それでも難しければスクラッチ開発とするといったように、どういう細分化ができるか、どんなモジュールで組むかという思考の転換が全府省に求められるようになると思う。

A-4「発注者の仕様書・契約書作成スキル向上」、「発注者の提案価格・サービス評価の能力向上」 B-3「調達実績等を蓄積・共有し活用する仕組み」について

  • 調達仕様書と、定量的な情報を蓄積するデータベースについては、前システムである政府情報システム管理データベース（ODB）の反省を踏まえる必要がある。改善が行われなかった理由も含めて、同じ失敗を繰り返さないようにしてほしい。
  • 発注者の仕様書・契約書作成スキルの向上については、代筆サービスやサポートするサービスは非常に有益だと思う。中長期的でよいので、専門人材の採用や育成はデジタル庁で積極的に対応してほしい。
  • 相談窓口の設置は賛成だが、デジタル庁に十分なリソースがあるかは疑問である。イギリスのCCSのように、デジタル庁の中でも専門的な調達を扱う部署の組成を考えていけるとよいのではないか。
  • システム調達実績の共有について、今はベンダー評価を実施するフェーズではないのではないと考えている。調達が失敗した原因は一概にベンダーにあるとは言いにくく、行政側に問題があることもあるので、検討しているトレーニングやサポート体制を作って、ベンダーと信頼関係を構築しながらプロジェクトを行えるようになった後に、必要な評価をするべきで、人材育成やサポート体制の強化がまず先ではないか。
  • データベースに何を蓄積するかについては、調達実績、落札者、プロジェクト概要、プロジェクトのローデータは非常に重要である。担当者が異動しても次の担当者がローデータを手掛かりにプロジェクトを継続できるものになるので、しっかりとデータベースに蓄積できるような機能を作ってほしい。ODBの反省として入力が大変だったというのもあるため、一度どこかで登録した情報が自動で反映されるようなシステム間連携は実施してほしい。
  • 国際NPOのオープン・コントラクティング・パートナーシップが、調達情報に係るデータ標準のガイドを作成していて、30以上の政府で使われている。データベースの標準を作成するのであれば、そうしたものも参考にしながら、オープンにして、信頼性・透明性の確保にいかせるとよいのではないか。
  • 調達者の能力担保について、相談窓口の設置という受けの姿勢ではなく、デジタル庁から積極的に関与していくべきである。
  • ベンダー選定プロセスの妥当性について、システム調達のデータベースは作成したほうがいいと思う。ODBの課題は繰り返してはいけない。妥当性については、各府省のCIO補佐官に助言を求めていたため、彼らにヒアリングを行い妥当性について整理をするとよい。また、信頼性については、行政レビューで評価していた。そういったものを振り返ってデータ化していくことが大事だと思う。
  • CCSは参考になるのでデジタル庁でよく研究してほしい。2万程度の調達を実施して、EU指令に基づいて公共調達規則を作っており、ベンチャーからの調達等もルール化しているので、参考になると思う。研究し、デジタル庁でも具備できる要件があれば、具体化して頂きたい。
  • 契約書の作成の支援体制について、最近の弁護士・法務の流行として、契約書の自動サービスなどのリーガルサービスの導入による効率化があるので、検討してはどうか。
  • 専門人材の教育について、モチベーションを高めるために、教育を受けた方のインセンティブを上げるといった改革も併せて検討してはどうか。
  • 専門人材の育成にフォーカスが当たりがちだが、実際にシステム調達においてトラブルが起こりがちなのは、専門人材が関わる前の初期の段階や、初期の段階で対応した人のミスであることがあるため、広く参加できるセミナーを開催するなど、最低限のシステム調達の知識は職員全体で底上げが必要ではないか。
  • システム調達のデータについて蓄積は必要だと考えるが、項目が多く入力が大変といったユーザの不満があれば、不満を受けて設計や項目を変えていく体制を用意して始めるとよいのではないか。
  • システム調達のデータベースについては、必要だと思うが、システムの概要は、きちんと入力されれば参考になるが、入力された内容がわかりにくい事例もある。概要が把握できるようにフラグをどう立てるのかは、複数の府省で検討したほうがいいと思う。ローデータをセットにして、確認したいものはすぐにローデータにコンタクトできるように設計した方がいい。
  • 公共工事の事例は、評価の仕組みとして参考になると思うが、一方でこれは国や自治体の公共工事全般に対する評価で、建設業法にも規定されているので、しっかりとした制度的義務付けの中で機能しているものだが、情報システムとしてどこまでできるかは検討すべき。審査は出来ると思うが、機能する仕組みとして実現出来るか、業法として規定出来ないのであれば、活用するメリットなどを打ち出す必要がある。

以上