Skip to main content

This page has been translated using TexTra by NICT. Please note that the translation may not be completely accurate.If you find any mistranslations, we appreciate your feedback on the "Request form for improving the automatic translation ".

Study Group on Common Standards for Standardization in Local Government Information Systems (fourth meeting)

Overview

  • Date: August 5 (Tue), 2025 (2025)
  • Venue: Digital Agency Assembly Room and online conferences
  • Agenda:
    1. Results of Comments on "Standard for Non-Functional Requirements [Version 1.2] (Draft)"
    2. Matters to be reflected in the draft revision based on comments received
    3. Other issues to be addressed
    4. Issues to be continued after the revision
    5. Items to be implemented in the future

Material

Relevant policy

Summary of the proceedings

The proceedings of this Study Group will be disclosed as a summary of the proceedings from the viewpoint of leading to an open discussion among the parties concerned.

Attendees (honorifics omitted)

Member

  • Chair: Masahiko Shoji (Professor, Faculty of Sociology, Musashi University)
  • Toshiro Kakizaki (Associate Professor, Department of Information and Communications Science, School of Information and Communications Science
  • FUJIMURA Akiko (Senior Researcher, NTT Social Information Research Institute)
  • Mikihito Yoshioka (Head of Digital Strategy Department, Planning and Coordination Bureau, Kobe City)
  • Kiyoshi Takigami (Deputy Manager, Digital Strategy Division, Planning and Finance Department, Tomioka City)
  • Rie Saito (Section Chief, ICT Promotion Office, Planning and Finance Department, Fukaya City)
  • Akio Yoshida (Director of the Planning and Promotion Division, Kyoto Association of Towns and
  • Akihei Yoshimoto (General Manager of Planning Department, Association for Promotion of Public Local Information and Communication)

Associate member

  • Hiroshi Maeda (RKKCS Corporation)
  • Hitoshi Itaya (Gcom Holdings, Inc.) [Proxy]
  • Daisuke Yokoyama (TKC Corporation)
  • Takahiro Yamazaki (DENSAN CO.,LTD.)
  • Hiroki Fukuda (NEC Corporation)
  • Izumi Anayama (Hitachi Systems, Ltd.)
  • Chikahisa Omura (Fujitsu Japan Co., Ltd.)

Observer

  • Satoshi Takizawa (Deputy Director, General Affairs Division, Director-General's Secretariat, Children and Families Agency)
  • KOMACHI Yuma (Section Chief, General Affairs Division, Director-General's Secretariat, Children and Families Agency
  • Sagasakino (Officer, General Affairs Division, Commissioner-General's Secretariat, Children and Families Agency)
  • Takuya Matsuzawa (Officer, Maternal and Child Health Division, Children and Families Agency Regional Development Bureau)
  • Akira Itoh (Section Chief, Family Welfare Division, Children and Families Agency Support Bureau)
  • Akihiko Ueda (Deputy Director, Maternal and Child Health Division, Children and Families Agency Growth Bureau)
  • Kazunori Nishiya (Administrative Officer, Digitalization and Promotion Office, Ministry of Internal Affairs and Communications Local Tax Bureau)
  • Sunao Irabu (Deputy Manager, Resident Program Division, Ministry of Internal Affairs and Communications Local Government Bureau)
  • Satoshi Tezuka (Section Chief of the Resident Register, Resident Systems Division, Local Government Bureau, Ministry of Internal Affairs and Communications)
  • Yusaku Yoshida (Section Chief of the Resident Register No. 2, Resident Systems Division, Local Government Bureau, Ministry of Internal Affairs and Communications)
  • Tomohiro Watanabe (Administrative Officer, Resident Program Division, Ministry of Internal Affairs and Communications Local Government Bureau)
  • Ryosuke Fukazu (Section Chief, Administration Division, Ministry of Internal Affairs and Communications Electoral Department)
  • Yunosuke Nishijima (Administrative Officer, Resident Program Division, Ministry of Internal Affairs and Communications Local Government Bureau)
  • Tsukasa Furukawa (Family Registration Section, Civil Affairs Division No. 1, Ministry of Justice Civil Affairs Bureau)
  • KOSEKI Ken (Section Chief of School Attendance Support Section, School Attendance Support Project Team, Ministry of Education, Culture, Sports, Science and Technology Elementary and Secondary Education Bureau)
  • Kunihisa Shimoji (Section Chief of Information Planning Section, cybersecurity and Informatization Promotion Office, Policy Division, Minister's Secretariat, Ministry of Education, Culture, Sports, Science and Technology
  • Seiya Otsuka (Information Planning Section, cybersecurity and Informatization Promotion Office, Policy Division, Minister's Secretariat, Ministry of Education, Culture, Sports, Science and Technology)

Agenda

  • The secretariat explained the draft revision of the "Standards for Non-Functional Requirements for Local Government Information Systems" based on the results of the public comments.

Interpellation

Member

As a proposal to change the name of "essential level item," I feel that "standard level item" is a good name that is easy to understand.

Regarding "E. 6.1.1: Encryption of transmission data?", the closed environment prescribed in (I) of the minus condition is shown in the image diagram, and it seems that the government building side is included in the part to be the closed environment. Is the government building side included in the scope of application of the "Standard for Non-Functional Requirements"?

Secretariat

In order to show the communication path in this image diagram, the cloud service is shown as the sender and the local government office building is shown as the receiver. However, the government office building side is not included in the scope of application of the "Standard for Non-functional Requirements." More easy-to-understand expressions are being studied for the expression method in this image diagram.

Member

With regard to "E. 6.1.1: Whether or not transmission data is encrypted," is it understood that the negative conditions of "(ii) Communication logs shall be obtained" and "(iii) Incident management and response shall be performed" are not required of networks on the local government side?

Secretariat

We think it will be implemented by the cloud service side and partly by the application side.

Member

The previous study group expressed the opinion that the "Standards for Non-Functional Requirements" should be applied to systems such as integrated collection and delinquency management implemented as common functions, as well as to proprietary clouds, in the same way as the 20 services specified in the "Priority Plan for the Realization of a Digital Society."

In this arrangement, proprietary clouds are included in the target cloud services. However, is it correct to understand that the target systems are limited to those related to 20 services?

Secretariat

The "Standards for Non-functional Requirements" will be based on the "Act on Standardization of Local Government Information Systems." Therefore, it will be applied to local government information systems related to 20 operations, including common functions. As for the built environment, it will be applied not only to the Government Cloud and the public cloud, but also to proprietary clouds.

Member

With regard to "E. 6.1.1: Whether or not transmission data is encrypted," is it understood that the "in-office NW" indicated in the image diagram of the closed environment prescribed in (I) of the Minus Condition refers to the part such as terminals and printers beyond the router?

Secretariat

As you know. The diagram is based on the assumption that many cloud servers are connected to cloud services via routers, leased lines, etc.

Member

It is understood that the Government Cloud, public cloud, and proprietary cloud are within the scope of the "Standards for Non-functional Requirements," and that on-premise is outside the scope. However, the definition of the applicable scope should be specifically described so that it is easy for local governments and vendors to understand.

Secretariat

The explanatory material in the "Standards for Non-functional Requirements" provides specific definitions of each cloud service. We will consider expressions that are easier to understand in this section.

Member

Regarding the level setting method, there are multiple patterns depending on the presence or absence of positive and negative conditions, which may cause confusion. Could it be considered to give positive and negative conditions to all items and simplify the pattern in level setting?

The phrase "covering the requirements realized by system infrastructure (IaaS/PaaS)" may cause confusion by giving the impression that cloud environments are provided separately from services. If the aim is to convert to SaaS, it may be a good idea to classify SaaS as the scope of application, and systems built on-premise and systems that cannot be called SaaS as a requirement even in local government cloud should be classified as outside the scope of application.

With regard to "E. 6.1.1: Whether or not transmission data is encrypted," it is understood that local governments and vendors have pointed out the necessity of encryption in a closed environment. If it is necessary to select "Level 1: Encrypt some data" even in a closed environment, it may be misunderstood that encryption is necessary because Direct Connect in a closed environment as shown in the image diagram has a risk of eavesdropping. In addition, although the purpose of encryption has been added to the explanation of metrics, it is questionable whether encryption can prevent intrusion and falsification by malicious third parties from the outside. Therefore, it is requested that the expression be carefully examined.

Secretariat

With regard to the level-setting method, a better method of expression was under consideration within the Secretariat in light of the suggestions made.

Regarding the scope of application, there are many items that need to be sorted out, such as the responsibility demarcation point and the requirements for SaaS. Therefore, in this revision proposal, the term IaaS/PaaS is used to make it easier to imagine the scope of application. We would like to discuss the scope of application of SaaS in the medium to long term.

With regard to "E. 6.1.1: Presence or absence of encryption of transmitted data," "Level 1: Encryption of some data" was made selectable with the intention that local governments would be able to determine the presence or absence of encryption as long as it is within a safe closed environment. Image diagrams and expressions used to explain metrics have been revised to accurately convey the intent of this item.

Member

Regarding "E. 6.1.1: Whether or not transmission data is encrypted," in the image diagram of a closed environment, data is transmitted from a terminal to a printer. However, it is assumed that data may be transmitted to a printer via a print server built on the Government Cloud. Therefore, how about changing or adding cases shown in the image diagram?

Secretariat

The image diagram in "E. 6.1.1: Encryption of Transmission Data? Yes" shows a general configuration based on "Recommended Configurations for Government Cloud Usage." We will update the recommended configuration with examples of other cases.

Member
Regarding the name of the item type, it seems to be easy to understand the setting from the viewpoint of whether the selection level can be selected by oneself or whether it is decided by the government. If the name is not changed, the explanation should be shown in contrast and easy to understand.

Member

The ARRC believes that "recommended level items" and "standard level items" have become difficult to understand compared to the previous proposed names of item types. The ARRC requests the ARRC to consider renaming "recommended level items" and "standard level items" to make them easier to understand if there is room for further discussion.

Secretariat

The change of the name and the addition of a commentary are being considered based on the content pointed out.

Member

Regarding "C. 2.3.5: Patch application timing for OSs, etc.", expressions such as "immediate" and "prompt" are mixed and are unclear. Regarding prior verification, since it is not implemented to prevent zero day attacks, isn't the description of "considering zero day attacks" unnecessary?

The original intent of "C. 6.3.1: Whether or not to implement incident management" and other management items is to consider whether to implement the existing process as it is or to develop a new process when an operation management agreement is executed. The amended selection level of "implement management" or "do not implement management" seems to deviate from the original intent.

Regarding the application to proprietary clouds (local government cloud), it is understood that the main purpose of the "Standards for Non-Functional Requirements" is to be applied when vendors build SaaS and provide services standard compliance system. It may be a good idea to arrange it so that it is not applicable to specific SI for specific local governments, including shared use in local government cloud as well as on-premise.

Regarding the post-revision agenda, one of the opinions expressed at the Study Group so far is that "from the perspective of increasing the sustainability of local government services, it should be communicated that lower levels of non-functional requirements should be actively selected." However, there should be a Government Cloud to enable the achievement of higher levels of non-functional requirements without increasing costs, and it is contradictory to send a message to local governments to lower the level of selection on their own responsibility.

Secretariat

The PMDA will consider modifying the content of "C. 2.3.5: Timing of Application of Patch for OS, etc." based on the PMDA's suggestion.

"C. 6.3.1: Implementation of Incident Management" will be reviewed so that the original purpose and management items to be implemented can be described.

Regarding the application of proprietary clouds (local government cloud), I would like to change the notation to make it easier to understand, and leave the question of the scope of application, including SaaS, for future discussion.

We will reconsider the wording of the revised agenda.

Member

Regarding "C. 2.3.5: Patch application timing for OS, etc.", if it is applied after prior verification, "immediate" should be changed to "promptly". In addition, the wording regarding zero day attacks should be deleted, or emergency patches, etc. should be carefully explained.

Member

If the wording about 0-day attacks is to be included, it should be carefully described, for example, emergency patches may have to be applied without prior verification in order to prevent 0-day attacks, but if the risk of 0-day attacks is small, they should be applied after prior verification.

Secretariat

In light of the fact that there are few opportunities for instantaneous occurrence in standard compliance system, we will consider revising the content of the statement. In light of the fact that the wording regarding zero day attacks may cause confusion, we will also consider the content of the statement.

Member

Regarding "C. 6.3.1 Whether or not to implement incident control," etc., "Level 0: Not implemented" is not an option because the Ministry of Internal Affairs and Communications Security Policy Guidelines also state that control will be implemented. Careful description is requested so as not to cause misunderstanding among local governments.

Member

With regard to "B. 1.1.1: Number of users" and "B. 1.1.2: concurrent sessions," it is stated that "this may affect the license price." However, it seems that there is no consistency between the selection level and the explanation of metrics. Since most systems do not have limits on the number of staff and concurrent sessions, the presence or absence of limits does not affect the license price.

Secretariat

The main item "B. 1.1.1: Number of users" and "B. 1.1.2: concurrent sessions" are items for local governments to estimate the amount of processing required for system designing. As you pointed out, it is assumed that there is no upper limit on the number of staff and concurrent sessions. However, as this is within the scope of discussions between local governments and vendors, we would like to hear your opinion but refrain from modifying the explanation on metrics. Since it is possible to select a lower level, if it can be agreed upon during discussions between local governments and vendors that it is not necessary to indicate an upper limit, we would like you to select the level flexibly.

Secretariat

Based on today's discussion, we will revise the revised draft as soon as possible and hold the Fifth Review Meeting in writing. The schedule will be announced later.