Third Meeting of the Digital Agency Information Systems Acquisition Reform Study Panel

Last Updated:: Oct 6, 2022

Outline

Date and time: September 7, 2022 (Wed) 13:00 to 14:30
Location: online
Agenda:
- 1. Opening
- 2. Proceedings
  - 1. Procedure of the 3rd Investigative Commission
  - 2. Overview of Each Topic
  - 3. Free Discussion
- 3) Closing

Data

Relevant policy

Ensuring Fairness and Transparency in Procurement / Procurement Reform to Utilize New Technologies

Summary of the proceedings

Date and time

Wednesday, September 7, 2022 from 13:00 to 14:30

Place

On-line

Attending committee member

Member Kajikawa, Member Kawasawa, Member Kimura, Member Sakashita, Member Sumiya

Summary of the proceedings

The Secretariat explained the following points: "Large-scale package development is more common than agile development."; "Enhancement of ordering capabilities for segmentation."; "Improvement of experience and knowledge of agile development."; "Improvement of the ordering party's skills in preparing specifications and contracts."; "Improvement of the ordering party's capabilities in evaluating proposed prices and services."; and "A system for accumulating, sharing, and utilizing procurement results." After each point was explained, free discussion took place and opinions were actively expressed. The main opinions from each committee member are as follows.

A-2 "Large-Scale Batch Development is Mainstream over Agile Development", "Strengthening Ordering Capabilities for Product Segmentation", A-4 "Improving the Experience and Knowledge of Agile Development"

Regarding agile development, it is necessary to examine the extent to which it should be implemented domestically through trial and error, based on global trends. We have no objection to the idea of advancing examinations mainly in Digital Agency.
With regard to the fragmentation of procurement units, the idea of dividing orders into parts is not an end in itself. Rather, we should first consider what units the appropriate systems should be loosely coupled or tightly coupled with. I believe that past failures were caused by dividing orders without resolving the tight coupling. Rather than predetermining division or integration, I would like to see consideration given to system design for the sake of appropriate system design.
Regarding the designation of deliverables at the time of procurement, it is stated in the document that the procurement unit will be the same as before in consideration of the administrative burden of procurement. However, I am concerned about how far the significance of agile development will go.
I agree with the creation of a guide for agile development. In doing so, I think that the idea of full cost may be necessary. If the period of use is long, and especially in single-party bidding, it is assumed that maintenance costs will be incurred (due to subsequent procurement). Therefore, there may be cases where it is more efficient in terms of full cost to be able to maintain to a certain extent on our own. In addition, if the person in charge becomes familiar with agile development in one project, the management cost for other system development may become lower. Therefore, it is necessary to consider the full cost of multiple projects. Therefore, it may be a good idea to include the idea of full cost in the perspective of considering the target of agile development.
When the procurement was segmented, it was pointed out that multiple reviews would be conducted. In order to consider the full cost, it would be necessary to review multiple projects together. Therefore, it is necessary to link the development target and the review target. Administrative reviews need to be organized as they are for each project, but they may be included as a point of view.
I think it is necessary to consider reviewing system procurements by local governments. In order to procure similar systems by each local government, there are system procurements for which the head office indicates common specifications. It may be a good idea to have a project that serves as a reference when promoting system development by each local government, by gathering the procurement staff of each local government and conducting development in an agile manner.
Creating a manual for agile development is a good thing, but I think agile development is closer to development than PDCA, which even government agencies have been talking about for a long time. It would be good if we could create a manual that is easy to accept and read.
In the private sector, there are cases where agile development is entrusted under a contract. Since there are problems with the type of contract, such as the allocation of work and responsibility, I would like the government to listen to the opinions of business operators when creating a model contract. There is concern that simply making it a quasi-delegation will make it difficult for the government to use.
It is difficult to improve the transfer of employees because it is related to other work. It may be a good idea to prepare a system in which not only the abilities of individuals but also the knowledge of the department remains. Especially when a system such as childcare leave is being prepared, the situation where it depends on individuals is not good, so it may be better to change to a system in which the department is properly trained and knowledge can be stocked.
With regard to the increase in administrative burden due to the segmentation of procurement, it is necessary to make the contract form easy to use when the procurement is segmented. Since there are some contract terms that are required in the course of segmentation, I think that it will lead to the reduction of administrative burden if the group that creates the contract form creates the form in cooperation with the group in charge of segmentation.
As long as we shift to a new system called agile development, I think the number of people needed will change compared to the traditional waterfall model, so it would be good to analyze where people are needed and allocate more people to locations where the need increases. In particular, considering that paper payments are no longer used, I think it would be good to allocate people to where they are needed.
In agile development, waterfall type development and agile development are not concepts that conflict with each other. If the product specifications are fixed, there is no problem with the waterfall type, but if the product specifications are not fixed, agile development is adopted. Therefore, I would like you to consider it on a case-by-case basis. If you look back on how problematic app development would have been if it had been developed with agile, you will have a lot of insights.
"Although feasibility, technical adequacy, and cost are necessary conditions for the rational review of the procurement unit, sufficient conditions are not clear. I would like to see a manual be created and disseminated that clearly explains what technical adequacy and feasibility are. In Digital Agency, it is possible to view the systems of other ministries and agencies, and people involved in the system are gathering from the private sector. I would like to see a manual be created based on these findings. In addition, I support the implementation of research and studies on loosely coupled systems and procurement unit segmentation."
I am in favor of creating manuals and guides for agile development and starting with Digital Agency. In order to make it easy for employees to understand whether agile development should be applied, I think it is important to show examples of cases where agile development should be applied by showing examples of specific products, such as those that citizens use UI / UX. I think there are team requirements in the guide, but I think there are many things that do not apply to the current system of the Cabinet Office and Ministries, so if there is this team, it is not okay to do agile, but because agile development is necessary, I would like to have a manual guide that promotes and makes it possible to try agile development.
Training for agile development is important, so I would like you to proceed with it. Along with training for product owners and organizational leaders, training for members who perform acceptance inspections is also necessary. I have heard of cases where the acceptance inspection side does not have knowledge of IT, so I would like you to consider training for members who perform acceptance inspections.
When creating systems at the Cabinet Office and each Ministry in the future, it has been the mainstream practice to start a project based on the development from scratch. However, in the future, the Cabinet Office and each Ministry will be required to change their way of thinking about what kind of segmentation is possible and what kind of modules should be assembled. For example, the Cabinet Office and each Ministry will first investigate whether there are any products in the private sector that can be used by the administration as well. Next, they will examine whether customization is possible, and if it is still difficult, they will decide on development from scratch.

A-4: Improvement of Outsourcers' Skills to Prepare Specifications and Contracts; Improvement of Outsourcers' Capabilities to Evaluate Proposed Prices and Services; B-3: Framework for Accumulating, Sharing, and Utilizing Procurement Results

Procurement specifications and databases that store quantitative information should be based on the lessons learned from the previous system, the government information system management database (ODB). I hope that the same mistakes will not be repeated, including the reasons why improvements were not made.
In terms of improving the skills of the ordering party in creating specifications and contracts, I believe that the provision of note-writing services and other support services is extremely beneficial. I would like to see Digital Agency take a proactive approach to hiring and developing specialist personnel, even if this is only on a medium - to long-term basis.
While I support the establishment of a helpline, I doubt that Digital Agency has sufficient resources. It would be good if we could consider setting up a specialized procurement department in Digital Agency, like the UK's CCS.
Regarding the sharing of system procurement results, I think it is not the phase to evaluate vendors. It is difficult to say that the reason for the procurement failure is the vendor, and the problem may lie with the administrative side. Therefore, the training and support system under consideration should be established, and after the project can be implemented while building a relationship of trust with the vendor, the necessary evaluation should be conducted. Strengthening human resource development and support systems should be the first priority.
With regard to what will be stored in the database, the actual procurements, successful bidders, project outlines, and raw project data are extremely important. Even if a person in charge is transferred, the next person in charge will be able to continue the project using the raw data as a clue. Therefore, I would like to see a function be created so that the information can be reliably stored in the database. Reflecting on the ODB, it may have been difficult to input information. Therefore, I would like to see systems linked so that information that has been registered somewhere is automatically reflected.
The Open Contracting Partnership, an international non-profit organization, has produced a guide on data standards for procurement information, which has been used by more than 30 governments. If database standards are to be developed, it may be a good idea to refer to such standards and make them open to ensure reliability and transparency.
The Digital Agency should be actively involved in ensuring the capability of procurers, rather than simply setting up a consultation desk to receive requests.
As for the appropriateness of the vendor selection process, I think it is better to create a database for system procurements. The ODB issues should not be repeated. As for the appropriateness, since advice was sought from the executive adviser for chief information officer of each ministry and agency, it would be better to hold hearings with them to sort out the appropriateness. In addition, the reliability was evaluated in the administrative review. I think it is important to look back on such matters and convert them into data.
I would like Digital Agency to research CCS thoroughly because it is a reference. We have implemented about 20000 procurements, and have created public procurement rules based on EU directives. We have also established rules for procurement from ventures, which I think will be useful. I would like you to conduct research and, if there are requirements that Digital Agency can also possess, please materialize them.
With regard to a support system for drawing up contracts, one of the recent trends in attorneys and legal affairs is improving efficiency through the introduction of legal services, such as automated contract services. It may be advisable to consider such a system.
With regard to the education of specialized human resources, in order to increase motivation, why not also consider reforms such as increasing incentives for those who have received such education?
While there is a tendency to focus on the development of experts, problems that tend to occur in actual system procurement are mistakes made at the initial stage, before experts are involved, or by those who respond at the initial stage. Therefore, isn't it necessary to raise the minimum level of knowledge of system procurement across all employees, such as by holding seminars in which a wide range of people can participate?
We believe that it is necessary to accumulate data on system procurement. However, if users are dissatisfied with the number of items and the difficulty of data entry, it may be a good idea to prepare a system for changing designs and items in response to their dissatisfaction.
Regarding the database for system procurements, I think it is necessary. The outline of the system is helpful if it is entered properly, but there are cases where the entered contents are difficult to understand. I think it would be better for multiple ministries to discuss how to set flags so that the outline can be understood. It would be better to design a set of raw data so that you can immediately contact the raw data for what you want to check.
The cases of public works will be helpful as an evaluation mechanism. On the other hand, this is an evaluation of the entire public works of the national government and local governments, which is also stipulated in the Construction Business Act. It is a function in the context of firmly established institutional obligations, but the extent to which it can be used as an information system should be studied. I think it is possible to conduct the examination, but it is necessary to consider whether it can be realized as a function mechanism, and if it is not possible to stipulate it as an industry law, it is necessary to show the merits of utilizing it.

Greater Than