Digital Agency Information Systems procurement Reform Study Meeting (3rd)

Overview

Date and time: Wednesday, September 7, 2022, from 13:00 to 14:30
Location: Online
Agenda:
1. Opening
2. Proceedings
  1. How to proceed with the third review meeting
  2. Summary of each discussion point
  3. Free discussion
3. Adjournment

Materials

Relevant policies

Ensuring fairness and transparency in procurement / procurement reform to utilize new technologies

Summary of proceedings

Date

Wednesday, September 7, 2022, from 1:00 p.m. to 2:30 p.m.

Location

Online (Teams)

Members in attendance

Committee Members Kajikawa, Kawazawa, Kimura, Sakashita, and Sumiya

Summary of proceedings

The secretariat explained about "Large-scale bulk development is more mainstream than agile development", "Strengthening ordering capacity toward segmentation", "Improving experience and knowledge of agile development", "Improving ordering party's skills in creating written specifications and contracts", "Improving ordering party's abilities in price proposal and service evaluation", and "Mechanism for accumulating, sharing, and utilizing procurement results". After the explanation of each point, free discussion took place in transition, and active opinions were expressed. The main opinions from each committee member are as follows.

A-2 "Large-scale bulk development is more mainstream than agile development", "Strengthening ordering capacity toward segmentation", A-4 "Improving experience and knowledge of agile development"

Regarding Agile development, it is necessary to consider how far we can go in the Japanese market based on global trends through trial and error. I have no objection to the point that we should proceed with the study centered on Digital Agency.
Regarding the segmentation of the procurement unit, the split order is not an end in itself. Shouldn't we first consider what kind of unit the appropriate system will be loosely coupled or tightly coupled? I think the past failure was caused by the split order without resolving the tight coupling. I would like you to consider the system design for the appropriate system design, not the split or integration.
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 procurement workload, but we were concerned about how much the significance of Agile development will come out.
I agree with the creation of a guide on Agile development. In it, I think that the idea of full cost may be necessary. If the period of use is long, and especially in the case of one party bidding, it is assumed that maintenance expenses may be required (depending on the subsequent procurement), so it may be more efficient as full cost to be able to perform maintenance to a certain extent by ourselves. In addition, if the person in charge is proficient in Agile development in one project, the management costs of other system development may be lower, so it is necessary to consider the full cost of multiple projects. Therefore, it may be good to include the idea of full cost in the perspective of considering the target of Agile development.
It was pointed out that when a procurement is subdivided, a review is conducted multiple times, but I think that a review that summarizes multiple projects that can be considered full cost is necessary, so it is necessary to link the development target and the review target. Administrative reviews are project units, so they need to be organized, but I think they can be included as viewpoints.
I think it is necessary to consider reviewing the system procurement in local government. In order to procurement a similar system in each local government, there is a system procurement for which the Agency has presented common specifications. By gathering the persons in charge of procurement in each local government to conduct development using Agile, there may be a project that serves as a reference when promoting the system development in each local government.
It is good to create a manual for Agile development, but I think Agile development is a version of PDCA, which has been said in public authorities for a long time, that is closer to development, so it would be good to create a manual that is easy to accept and read.
In private sector, there are cases where Agile development is outsourced by contract. Since there are problems not only in the contract type, such as problems of work sharing and responsibility distribution, we would like you to listen to the opinions of the business operator when creating the contract model. There is a concern that simply making it a quasi-mandate will be difficult for the government to use.
It is difficult to improve the transfer of employees because it is related to other operations. It may be a good policy to prepare a system in which knowledge will remain in the department in addition to the abilities of individuals. In particular, it may be better to change the system to a system in which knowledge can be stored by firmly fostering the department, because it is not good to be dependent on individuals in the process of establishing a mechanism such as childcare leave.
With regard to the increase in the workload due to the segmentation of the procurement, it is necessary to make the contract template easy to use when the procurement is segmented. In the process of segmentation, the required contract provision may appear, so I think that it will lead to the reduction in the workload for the group that creates the contract template to create the template in cooperation with the group in charge of segmentation.
As long as it is a new system called Agile development, I think the number of people needed will change compared to the conventional waterfall type, so it is good to analyze where people are needed and allocate more people to the places where the need is increased. In particular, considering the fact that paper payments are no longer used, I think it would be good to allocate people to the places where they are needed.
Regarding Agile development, waterfall development and Agile development are not contradictory concepts. If the product specifications are fixed, there is no problem with waterfall development, but if the product specifications are not fixed, Agile is development. Therefore, I would like you to think about it on a case-by-case basis. If you look back at how App development, which had problems, would have been if it had been Agile, you would have accumulated knowledge.
Regarding the examination of rational procurement unit, feasibility, technical adequacy, and cost are necessary conditions, but sufficient conditions are not known. I would like to see a manual that clearly explains what technical adequacy and feasibility are and spread it. If it is Digital Agency, we can see the systems of other ministries and agencies, and system personnel are gathered from private sector, so I would like to see a manual created based on such knowledge. In addition, I agree with the implementation of survey research on system loose coupling and procurement unit fragmentation.
I am in favor of creating a manual or guide for Agile development and starting with Digital Agency. In order to make it easier for employees to understand whether Agile development should be applied, I think it is important to show examples of cases in which Agile development should be applied by showing specific product examples, such as those in which the public uses UI and UX. I think there are requirements for teams in the guide, but I think it does not apply to many cases under the current system of the Cabinet Office and Ministries, so if there is a team, it is not good to do Agile, but Agile development is necessary, so I would like it to be a manual guide that promotes Agile development so that people can try it.
Agile development training is important, so I would like you to advance it. At the same time as training for product owners and organization leaders, training for members who conduct acceptance inspection is also necessary. I have heard of cases where the acceptance inspection side does not have IT knowledge, so I would like you to consider training for members who conduct acceptance inspection.
Regarding the segmentation of the procurement unit, considering the uncertainties, it will be difficult to create a heavy and long system in order to respond to the risks in the future, and it may be better to avoid it as much as possible. Until now, when the Cabinet Office and Ministries create systems, it has been mainstream to start projects with scratch development. However, I think that all the Cabinet Office and Ministries will be required to change their thinking about what kind of segmentation can be done and what kind of modules should be used, as in the following case: first, they will check whether there are products in private sector that can be used by the administration, and then they will consider whether customization is possible, and if it is still difficult, they will use scratch development.

A-4 "Improvement of Ordering Party's Skills in Preparing Written Specifications and Contracts," "Improvement of Ordering Party's Abilities in Evaluating Proposed Prices and Services," and B-3 "Mechanism for Accumulating, Sharing, and Utilizing procurement Performance, etc."

Regarding the procurement Specifications and the database that stores quantitative information, it is necessary to take into account the review of the previous system, the Government Information Systems Management Database (ODB). Please do not repeat the same failure, including the reason why the improvement was not made.
Regarding the improvement of the orderer's skills in creating written specifications and contracts, I think that the service of writing on behalf of the orderer and the service of supporting the orderer are very useful. In the medium to long term, I would like Digital Agency to actively respond to the recruitment and development of professional human resources.
I agree with the establishment of a consultation service, but I doubt whether Digital Agency has sufficient resources. It would be good if we could consider the formation of a department that deals with specialized procurement in Digital Agency, like CCS in the United Kingdom.
Regarding the sharing of system procurement results, I believe that it is not the phase to conduct vendor evaluation now. It is difficult to say that the cause of procurement's failure is necessarily the vendor, and there may be problems on the administrative side. Therefore, the necessary evaluation should be conducted after the training and support system under consideration is created and the project can be conducted while building a relationship of trust with the vendor. Human resource development and strengthening of the support system should come first.
Procurement performance, successful bidders, project outlines, and raw data of projects are very important in terms of what to accumulate in the database. Even if the person in charge is transferred, the next person in charge will be able to continue the project based on the raw data. Therefore, I would like to see the creation of a function that can be steadily accumulated in the database. Since it was difficult to input information as a reflection of ODB, I would like to see the cooperation between systems that automatically reflect information that has been registered somewhere once.
The Open Contracting Partnership, an international NPO, is preparing a guide to data standards for procurement information. It is used by more than 30 governments. If you are preparing a standard database, you should refer to such a guide and make it open to ensure reliability and transparency.
Regarding the ability guarantee of procurement operators, Digital Agency should be actively involved, rather than taking a passive attitude of establishing a consultation window.
Regarding the appropriateness of the vendor selection process, I think it is better to create a database of system procurement. The Issue of ODB should not be repeated. Regarding the appropriateness, we have asked for advice from the executive adviser for chief information officer of each ministry and agency, so it is better to interview them and organize the appropriateness. In addition, the reliability was evaluated by administrative review. I think it is important to look back on such things and make them into data.
CCS is useful as a reference, so I would like you to study it well in Digital Agency. We have implemented about 20000 procurement, and have created public procurement rules based on the EU Directive. We have also made procurement from venture companies into rules, so I think it is useful as a reference. I would like you to study it and if there are requirements that Digital Agency can meet, I would like you to specify them.
Regarding the support system for the creation of contracts, there is a efficiency due to the introduction of legal services such as automatic contract services as a recent trend in lawyers and legal affairs, so why don't you consider it?
In order to increase the motivation of education for professional human resources, it may be advisable to consider reforms such as increasing incentives for those who have received education.
Although the development of specialized human resources tends to be focused, problems actually tend to occur in system procurement because of mistakes made by people who responded at the initial stage, before the involvement of specialized human resources, or at the initial stage. Therefore, it may be necessary for the entire staff to raise the minimum level of knowledge about system procurement, such as by holding seminars that can be widely participated in.
We believe that it is necessary to accumulate the data of the system procurement, but if there is a user's complaint that it is difficult to input because there are many items, it may be good to start by preparing a system to change the design and items in response to the complaint.
As for the database of System procurement, I think it is necessary. The outline of the system is useful if it is properly input, but there are cases where the input content is difficult to understand. I think it is better for multiple ministries to consider how to set flags so that the outline can be understood. It is better to make a set of raw data and make a design so that you can contact the raw data immediately if you want to check it.
I think that examples of public works are useful as a mechanism for evaluation. On the other hand, this is an evaluation of public works in general in the country and local government, and it is stipulated in the Construction Business Act, so it functions within a firm institutional mandate. However, it should be examined to what extent it can be used as an information system. I think that examination is possible, but it is necessary to show whether it can be realized as a functioning mechanism, or if it cannot be stipulated as a business law, it is necessary to show the advantages of using it.

End