先に、3つの原則
- 止めない。計画停止を前提にしない。並行稼働で進め、障害時は遮断・切り戻しできる状態を保つ。
- 最初は書かない。接続は読み取り専用・最小権限から。書き込みは検証と別途合意の後。
- 照合する。APIの返す値が現行の帳票・画面と一致することを、件数・金額・コードで突き合わせてから使う。
この3つを守ると、失敗したときに失うものが「作業時間」だけになります。手順のすべては、この原則の言い換えです。
手順1: 棚卸し(何が、どこで、どう動いているか)
最初にやるのは設計ではなく調査です。OS・DBのバージョン、テーブル(物理ファイル)の一覧、夜間バッチの流れ、既存の連携(CSV出力・FTPなど)、そして接続に使えるアカウントと権限。仕様書がない場合は、稼働中のソース・DB定義・帳票・ログから読み起こします。ここの精度が、後の全工程の安全性を決めます。
手順2: 接続方式を選ぶ
読み取りの経路には、大きく4つの選択肢があります。環境と制約で決まるもので、優劣は一概には言えません。
| 方式 | 概要 | 向いている条件・注意 |
|---|---|---|
| DB直接照会 | ODBC/JDBCなどでDBを直接参照 | IBM iのDb2など照会経路が確保できる環境。読み取り専用アカウントと負荷監視が前提。当社が最初に検討する経路 |
| ジャーナル・ログ連携 | 更新ログを読んで変更分だけ取り込む | 更新頻度が高く、参照側を最新に保ちたい場合。設定の難度は高め |
| ファイル連携 | 既存のCSV・固定長出力を活用 | すでに夜間出力がある環境で早い。リアルタイム性は低い |
| 画面経由(5250など) | 端末画面の項目を読み取る | 他の経路が塞がれている場合の最後の手段。画面変更に弱く、恒久策には不向き |
実際には複数を組み合わせます。たとえば在庫はDB照会、確定済みの実績は夜間ファイル、という形です。
手順3: 文字と型を変換する
古い基幹のデータは、そのままではWebの世界で読めないことが多いです。典型は3つ。
- 文字コード。EBCDIC(CCSIDの確認が必須)や半角カナ。Shift_JIS経由の変換で化ける文字の扱いを先に決めます。
- 数値の型。ゾーン10進・パック10進。桁数と符号の扱いを間違えると金額が壊れます。
- 日付。6桁数値(YYMMDD)、和暦、ゼロ埋めなしなど。「19600101より前は未設定扱い」のような業務ルールが埋まっていることもあります。
変換ルールは表にして残し、後述の並行照合で毎回突き合わせて確認します。
手順4: 「読み取り専用」を技術で担保する
「読み取りしかしません」は約束ではなく設定で担保します。専用アカウントを作り、参照権限だけを付与。接続元を接続層のサーバーに限定し、同時接続数と実行時間に上限を設けます。基幹側のCPU・応答時間を監視し、しきい値を超えたら接続層側で自動的に間引く(スロットリング)構成にします。夜間バッチの時間帯は照会を避ける設計も有効です。
手順5: APIを設計する
テーブルをそのまま公開せず、業務の言葉でリソースを切ります(在庫照会、受注状況、出荷予定など)。基幹の項目名は接続層で読みやすい名前に写像し、キャッシュの持ち方(何秒前のデータまで許すか)を業務ごとに決めます。ここで決めた「鮮度」の合意が、後の運用トラブルを防ぎます。認証・認可・監査ログはこの層で一元化します。
手順6: 並行照合(いちばん地味で、いちばん大事)
APIが返す値と、現行の帳票・画面の値を並行期間中ずっと突き合わせます。観点は3つ: 件数(レコードが欠けていないか)、金額(合計が一致するか)、コード(変換で壊れていないか)。日次で自動照合し、不一致はすべて原因を特定してから先に進みます。「だいたい合っている」で進めないことが、後の信頼をつくります。
手順7: 受入基準を満たしてから本番へ
本番化の条件は感覚ではなく数値で決めます。例: 日次照合の不一致が0件のまま規定日数続くこと、応答時間が合意値以内であること、障害時の遮断・切り戻し手順のリハーサル完了、基幹側負荷が合意の範囲内。満たさない範囲は本番化しません(ここは当社の受入基準の考え方そのままです)。
手順8: 運用(公開してからが本番)
誰が・いつ・何を読んだかを監査ログに残し、基幹側の変更(項目追加・帳票変更)を検知したら照合を再実行します。障害時にはAPI側だけを止めて業務を現行運用に戻せることが、読み取り専用構成の最大の強みです。ここまでを運用手順書と移管資料にして、内製でも回せる状態でお渡しします。