バージョンアップルールの整備について

Transcript

1. 1 バージョンアップルールの整備について 2022.1.27 APPLIC 吉本明平 1 バージョン管理単位 今後標準仕様のバージョンアップを考える際、バージョンを整理する単位を明確にする必要があ る。 すくなくとも、 • 個々の業務標準仕様 • 共通事項（標準非機能要件） • 共通事項（データ要件、連携要件） • 共通事項（ガバメントクラウド） についてのバージョン管理が必要となる。 個々の業務標準仕様は共通事項と依存関係にあるため、対応関係を明示する必要がある。さら に、個々の業務標準仕様についても相互に依存関係となる場合もあり、こちらの対応の明示も必要 となる。 最もシンプルな方法としては • 全体バージョン • 構成要素バージョン に分けて整理することである。 構成要素バージョンとは上記の個々の仕様についてのバージョンであり、現状の各標準仕様書 のバージョンや、標準非機能要件のバージョン（日付しか入っていないが）がそれに当たる。 全体バージョンは構成要素全体の集合についてのバージョンである。 構成要素の一つでも変更があれば、変更のないものも含め、全体パックとして更新して全体バー ジョンを上げる運用となる。 全体バージョンのそれぞれが、そのバージョン内で整合されたパックであり、自治体への適用はこ の全体バージョンをもって実施されることとなる。 2 付番ルール バージョン番号の付番についてはルール付されていることが望ましい。 メジャーバージョンアップやマイナーバージョンアップの考え方と、付番の運用手順が必要となる。 全体バージョン、構成要素バージョンそれぞれについての付番ルール、全体バージョンとして構成 要素バージョンを束ねる際の管理ルールを整理して、対応関係が一目瞭然となるようにすることが 望ましい。
2. 2 3 リリーススケジュール 構成要素バージョンの個々についてリリーススケジュールを明確にする必要がある。全体バージョ ンは構成要素バージョンのリリーススケジュールによってスケジュールが確定する。よって、全体を整 理して全体バージョンのリリーススケジュールを確定させる必要がある。 理想的には全体バージョンのリリーススケジュールを確定し、それに合わせて構成要素バージョン のリリース計画を作成するべきである。可能な限りその運用とする。 ただし、法改正による構成要素バージョンのバージョンアップの事情が優先されるため、構成要 素の状況にあわせた運用手順は必ず作成する必要がある。 標準化法によって対応が義務である以上、全体バージョンのリリーススケジュールの明示と同時 に、自治体への適用スケジュールの明示（新バージョン適用の猶予期限）が必要となる。 自治体への適用スケジュールは構成要素バージョンではなく、全体バージョンを基準に提示され る必要がある。よって、各構成要素のリリーススケジュール（法改正においては施行期日）に対応し て全体バージョンのリリーススケジュール並びに自治体への適用スケジュールを確定させる必要が ある。 施行期日が複雑に分散した場合、短期間に全体バージョンが複数回バージョンアップされる状 況もありえる。 なお、自治体への適用は、理想的には全団体同時期であるべき。 標準化の目的が自治体の状況を揃えることにある以上、全体バージョン V1 の自治体と V2 の 自治体が混在する時期は可能な限り短くする必要がある。 なお、マルチベンダー構成となっている自治体においては、全体バージョンのバージョンアップに 適切に対応するための全体運用が必要であり、ある程度のフォローが必要になる可能性がある。 準拠確認は個々の業務については構成要素バージョン単位に確認することとなるが、自治体の 全体像としては全体バージョンに準拠していることを確認する必要がある。 4 変更管理 全体バージョンのバージョンアップに際する変更管理の方法を明確にする必要がある。 構成要素バージョンのどの部分が変わったかを明示することになる。 構成要素バージョンの変更管理については、別途整理する必要がある。 以上
3. 3 政府全体としてのバージョン 住基としてのバージョン → インデックス（機能集合） 機能要件 1 機能要件 2 税全体としてのバージョン 個人住民税のバージョン 機能α 法人住民税のバージョン ガバクラのバージョン 非機能要件のバージョン