型式試験への提出後に、書類やプログラムを確認することになったとき、実際に提出したものと、それらに対応する社内の開発データを特定できるでしょうか。作業フォルダにある最新版と、提出した版が同じとは限りません。提出後も開発が進む場合は、どのデータを使ったかを後からたどれる記録が必要になります。
この記事では、遊技機メーカーや開発子会社の開発管理責任者に向けて、提出版の識別、変更理由、書類との対応、保管と権限の4項目を整理します。一般的な開発データ管理の方法を、提出版と関連データの管理に当てはめた提案です。型式試験の現場で効果を検証した事例を紹介するものではありません。自社の提出物と管理方法に合わせて、必要な項目を選んでください。
まず、一つの提出版を取り出してみる
最初に、過去に提出した案件を一つ選びます。実際に提出した書類・プログラム等と、それらに対応する社内のソースコード・設定・生成条件を、当時の担当者の記憶に頼らず特定できるか確認してください。以下で挙げるデータがすべて提出対象という
意味ではありません。
- 提出した書類と、社内で更新中の書類を区別できるか
- プログラムの生成に使ったソースコードと設定を特定できるか
- 提出後に変更した箇所と、その理由が分かるか
- 確認する権限を持つ別の担当者が、同じ一式を取り出せるか
取り出せなかったものや、対応関係が不明だったものを記録します。ツールの入れ替えを決める前に、管理上のどこで情報が途切れるかを確認するためです。
本記事の「開発証跡」は、対象の版や変更の経緯を確認するための記録を指します。ここで示す管理方法は、型式試験の申請要件や適合性を判定するものではありません。実際の申請には、申請先の最新の案内・様式を確認してください。保安通信協会の公式サイトには、型式試験に関する手続きの案内が掲載されています。
1. 提出物と関連データに、識別できる記録を付ける
「提出用」「提出用_最終」といったフォルダ名だけでは、どの時点の何を指すかが曖昧になります。提出の単位ごとに管理番号を付け、書類と開発データを対応づけます。
バージョン管理システムは、ファイルの変更履歴や特定時点の状態を管理する仕組みです。SVNやGitを使っている場合は、提出物に対応する社内データのリビジョン番号やコミットID（履歴上の状態を特定する番号・識別子）を記録します。別の場所に置いている書類や成果物は、その保管先と版も記録します。
以下は社内管理の記入例であり、申請様式ではありません。
| 管理項目 | 記入例 |
|---|---|
| 提出管理番号 | SUB-2026-001 |
| 書類 | 書類一式の保管先と版番号 |
| ソースコード | リポジトリの場所とリビジョン番号／コミットID |
| 実際の提出物 | 提出した書類・プログラム等の一覧と保管先、必要に応じてハッシュ値 |
| 社内の関連データ | 対応する設定・素材等の一覧、保管先、対象の版 |
| 生成条件 | 使用ツールのバージョン、設定、依存する部品 |
| 確認記録 | 確認日、確認者、対象範囲 |
ハッシュ値は、ファイルの内容から計算する照合用の値です。保存した値と再計算した値の比較に使えますが、それだけで提出の事実や承認者を証明するものではありません。
タグ名を付ける場合も、タグが変更されない前提にしないことが必要です。Gitのタグは操作によって置き換えられ、SVNのタグも通常のディレクトリとして変更できます。更新権限を絞り、対象の識別子と確認記録を併せて残します。
図1：提出物と社内データを対応づける管理例。申請先の提出要件を定める図ではありません。
2. 変更内容と理由を、確認結果につなげる
提出後に修正するときは、変更前後の版、変更した理由、確認した内容を対応づけます。
たとえば、変更を管理するチケットに「何を直すか」「なぜ直すか」「どう確認するか」を書き、関連するコミットや更新した書類を紐づけます。既存の仕組みで追跡できるなら、同じ内容を別の台帳に転記する必要はありません。
バージョン管理に登録したファイルの差分は確認できますが、判断の理由、システム外のファイル、実機での確認結果までは自動で揃いません。何が履歴に残り、何を別途記録する必要があるかを決めます。
3. 書類と開発データの対応を残す
書類に記載した処理が、どのソースやデータに対応するかを確認できるようにします。最初は、社内の照合で確認に時間がかかる項目から始められます。
| 書類の対象箇所 | 対応するデータ | 特定する版 | 確認記録 |
|---|---|---|---|
| 章・項目・図表番号 | リポジトリ内の場所、ファイル名など | リビジョン番号／コミットIDなど | 確認日・確認者・結果 |
これは社内で使う対応表の例です。申請先が求める書類の代わりにはなりません。また、最新版へのリンクだけでは、提出時点の状態に戻れない場合があります。保管場所と対象の版をセットで記録してください。
プログラムを後から生成し直す必要がある場合は、ソースコードに加えて、使用ツール、設定、依存する部品のバージョンも必要になります。提出物に含まれるプログラムそのものの保管と、社内で生成に使った情報の保管を分けて確認します。
4. 保管先・閲覧権限・復元方法を確認する
提出版の一式が個人のPCにしかない場合、担当者の交代や端末故障の際に取り出せなくなるおそれがあります。会社が管理する保管先を決め、職務に応じて閲覧・更新権限を設定します。
確認するのは、権限の設定だけではありません。必要な担当者が取り出せるか、誤って削除した場合に復元できるか、変更履歴やアクセス記録をどこまで取得できるかを確認します。記録できる操作は利用する製品や設定によって異なるため、バージョン管理を導入しただけで閲覧履歴まで残ると考えないことが必要です。
保管期間は、適用される要件と社内規程・契約を確認して決めます。データ、履歴、対応表を別々に管理する場合は、それぞれが必要な期間取り出せるかも確認します。
次の提出から、確認できなかった項目を埋める
過去の一件を確認した結果、版が分からなかったなら識別子を残す、変更理由が分からなかったなら既存のチケットに記録する、といった形で日常の作業に組み込みます。
すでに記録されている項目は、その保管先を使います。未確認の項目を絞り、次の提出時に別の担当者が同じ一式をたどれるかを確認すれば、追加した管理が役立っているか判断できます。
開発データの保管・引き継ぎについて相談する
提出した版を取り出せない、書類とソースの対応を確認するのに時間がかかる、担当者の交代に備えて保管先を整理したい。こうした状況があれば、対象のデータと困っている作業をお知らせください。
バージョン管理の利用、既存サーバーからの移行、保管・運用の見直しについて、対応可否・範囲・費用を個別に確認します。お問い合わせには、機密性のあるソースコードや申請書類を添付せず、状況の概要をご記載ください。
