前回に引き続き、コードの運用についてお話します。
前回はコード運用に対する利用基準や仕様書についてお話ししました。今回は変更管理です。
コードの変更管理（バージョン管理）
システムで正しいデータを維持するためにはコードに対する適切な情報提供が大切なことは前回お話しました。この情報提供のうち、新しいコードの情報提供は比較的できている企業が多いのですが、変更や廃止に対する情報提供がうまくできているところは意外と少ないです。
ましてや、コードのバージョン管理を行い、変更理由や廃止理由を記載しているケースはほとんどありません。結果として、なぜ、こうなったかの背景がわからずに、本来同様に変更や廃止にすべきだったコードが放置されたままになり、正しいデータが入力できていないという結果を生み出します。
コードの整合性がとれていないとよく入力側のミスのような言い方をすることがありますが、このコードの変更管理が出来ていない結果、整合性が取れていない状況が生じていることが実は背景にあります。つまり、適切な情報提供が出来ていない管理側の問題ということです。
正しいデータの維持にはコードのバージョン管理、変更管理を確実に行うとともに、それを関係者に適切なタイミングで伝える仕組みがコード運用ではとても重要だということです。
変更の承認と記録
まずは、変更手順への追記です。前々回お話したコード運用に対する業務担当、システム担当の役割分担と前回お話したコード自体の変更手順にバージョン管理の手順を加えます。
具体的には、変更の承認と変更記録と周知です。変更の承認はコード利用の関係者を集めて、変更に対する最終確認を行ってもらいます。先ほど記載したように変更範囲が十分かどうか、変更した担当だけでは判断できないこともあるからです。
特に廃止関連は集計関連に大きな影響を与えることが多いので、利用関係者を広くとらえたほうがいいことがある点も考慮してください。
次に変更記録です。バージョン管理といってもいいですが、いつ、誰が、どのような理由で、どのような変更を加えたかを記載しておくことが大切です。
具体的にはバージョン、改定日、改定内容、改定理由といった感じです。バージョン自体は連番でもいいですし、枝番をつけてもいいですが、管理しやすい番号体系が望ましいです。
改定内容はどこがどう変わったを記載します。できれば、旧コードと新コードを併記して、違いが一目でわかるようにしましょう。改定理由は商品自体の変更や商品体系の見直し、桁の意味の見直しといった形で記載します。
特に商品体系の見直しのようにまとめたコード変更がある場合は、別紙で対応表をつくって、旧コードと新コードが比較できる一覧があることが望ましいです。集計等で読み替えが必要になるケースも少なくないので、必要に応じて、変換の仕組みも検討することも出てくると思います。
変更の周知
最後は周知です。変更はある程度の予告期間をもって通知します。その上で、システムで対応できるのであれば、変更のメッセージ等が出せるといいです。変更の期日になると変更前コードは入力制限ができたり、メッセージがでるといいですが、どうしても旧コードが入力する必要性もあるので、その点をしっかり把握して対応策を準備してください。
また、廃止についてはさらに注意が必要です。システム側で自動的に入力不可になるのであれば安心ですが、そうでない場合は、相当の期間をもって、周知徹底できるような連絡（回覧や利用者側の会議等での説明会など）をしっかり行います。
正しいデータの維持にはコード運用はとても重要です。自社の管理を振返って、足りないところを見直してください。