運用・保守チームと語らずに、移行設計はできない——14年間課長だった人の話
シリーズ：現役PMOがAI協調設計の新境地を拓く
Zenn第1話：AIには渡せない判断がある——現役PMOが「人間の仕事」を再定義した話
Zenn第2話：ブロックCRUDをどう育てるか——AIと人間が往復する設計の実際
Zenn第3話：履歴を中間と間違えたらどうなるか——ブロックCRUDが守るもの
Zenn第4話：世代管理と履歴——レガシーエンジニアが混同しやすい理由
Zenn第5話：テスト観点案はテストケースではない
▶ Zenn第6話：運用・保守チームと語らずに、移行設計はできない（本稿）
はじめに——A-AUTOの画面とCA乗務スケジュール
A-AUTOのスケジュール設定画面を初めて見たとき、ふと思い出したものがある。
某航空会社のCA（客室乗務員）乗務スケジュール帳票だ。昔の帯のような給与明細と同じ紙に、CA一人一人の名前が並び、日付の下にアスタリスクやアルファベットが入って、乗務や現地待機などの予定が一目でわかる。あの一覧だ。
A-AUTOのジョブスケジュール画面は、それに酷似している。ジョブがCA一人一人の名前に見えてしまう。
レガシーのスケジュール管理からあの乗務スケジュール帳票が生まれたのか、それとも逆なのか。どちらが先かはわからない。ただ、「きっちり管理する」という設計思想は同じ根を持っているように感じる。
この「きっちり感」の正体を、移行プロジェクトに入るエンジニアは理解していなければならない。
A-AUTOとJP1——市場はどこにいるか
A-AUTOの現在地
A-AUTOはユニリタ（旧ビーエスピー）が提供するジョブ管理ツールだ。1977年の提供開始以来、40年を超えてメインフレーム向けジョブ管理ツールとして歩んできた。
1980年代後半のオープン化・ダウンサイジングの潮流の中で、1993年にオープン版A-AUTOの提供を開始し、現在はAWSをはじめとするクラウド環境にも対応している。2024年にはAWSのメインフレームモダナイゼーションサービス「AWS Mainframe Modernization」との連携を実現し、メインフレームからAWSへの移行においてジョブ管理システムの構築と運用が継続できることが確認されている。
移行中も止めない、既存の分散コンピューティング環境とのジョブ連携を維持しながら並走できる。「移行しながら、レガシー運用も続ける」という現実に寄り添った立ち位置にある。
ライセンスの特徴として、OSが変わっても年間サポートサービス料の範囲内でライセンスを継続できる。プラットフォームの変更に伴う買い直しが不要という点は、移行コスト試算の際に見落とされやすい優位点だ。
JP1の現在地
JP1は日立製作所が開発・販売する統合システム運用管理ソフトウェアだ。1994年の販売開始以来、金融をはじめとする各種産業や官庁など、業種・規模を問わず幅広く採用されており、国内トップシェアとされている。
ジョブ管理製品「JP1/Automatic Job Management System 3（AJS3）」は、SAPシステムとの連携が強みであり、SAP S/4HANA移行においてもAJSを中核に据えるケースが多い。また、30年以上にわたって培われた技術基盤から、認定資格保有者が数多く輩出されており、長期運用を支える技術者の確保がしやすい点が評価されている。
クラウド対応も進んでおり、AWS・Azure・Google Cloudを対象としたJP1 Cloud Serviceも提供されている。オンプレミスのAJS3のジョブ資産を最大限活かしながらクラウドリフトできる点を強調している。
二刀流構成という現実
レガシーがIBMメインフレーム中心の場合、A-AUTOで夜間バッチを管理しつつ、オープン系の監視・通報・運用はJP1、という構成は珍しくない。両製品とも「移行中も止めない」という設計思想を持っており、共存しやすい。
移行フェーズによっては、A-AUTOとJP1が同時に稼働する期間が生まれる。その期間の運用設計を誰が担うかを、早い段階で決めておく必要がある。
レガシー運用の「きっちり感」——物差しが違う
基本的には、どこでもそうだが、汎用機を保守運用してきた現場は、高いリース代を含め運用してきたのだから「きっちり」運用しているのである。
ただ、オープン系の中小や、オフコン現場をみてきた方々には、目を見張るような高等な運用に見えるのかもしれない。
何を言いたいかというと、レガシーの運用を設計する前に、ざっくばらんに運用・保守チームと話すと、レガシーを知らないオープン系の中小やオフコン系のスタッフの「物差し」が変わるのである。
お客様は「汎用機と同じように運用される」としか言わないが、この一言の重みを理解させるには、レガシーの保守・運用チームと語ることだ。
具体的に何が違うか
以下は、レガシー運用チームが当たり前に持っている設計思想の一部だ。
| 観点 | レガシー運用チームの常識 | オープン系出身者が見落としやすい点 |
|---|---|---|
| 異常終了時 | リカバリ手順書が細かく定義されている | 再実行すればよいという発想になりがち |
| スケジュール管理 | 業務カレンダーごとに先行・後続が厳密に設計されている | ジョブを並べれば動くという発想になりがち |
| 夜間バッチ | 朝までに完走することが絶対条件 | 性能見積もりが甘くなりがち |
| 監査対応 | いつ、誰が、何を実行したかの証跡が必須 | ログは取るが証跡管理の意識が薄くなりがち |
| 二重実行防止 | 同一バッチが二度走らない仕組みが組み込まれている | 再実行設計が後回しになりがち |
この物差しのズレを、移行プロジェクトの初期に認識できるかどうかが、後工程の品質を大きく左右する。
14年間課長だった人の話——評価されなかった仕事の重さ
わたしが入社したとき、与野の計算センターの運用課に、やさしい課長がいた。
その課長は、わたしが14年後に退職するまで、課長のままだった。
なぜ評価されにくかったのか。見積もり時の単価から、そうだったようだ。
日本の同年代のエンジニアには、保守運用の職に対してどこか引いたような空気感が存在する。「やりたくない仕事」「評価されない仕事」という無言の空気だ。
その空気感があると、保守・運用チームとの協調関係は図れない。
移行プロジェクトで設計書を作る側と、日々運用を守る側の間に、このような空気感が存在していると、運用上の重要な情報が設計書に反映されないまま実装に進む。その結果として、本番稼働後に「なぜこの設計になったのか」という問いに誰も答えられない状況が生まれる。
技術伝播——何を引き継ぐべきか
レガシー運用チームが持っている知識は、ツールの使い方だけではない。引き継ぐべきものは大きく3つある。
1. 運用判断の暗黙知
異常終了したとき、「これは再実行できる」「これは要確認」と即座に判断できる感覚がある。JCLのリターンコードの読み方だけでなく、業務の文脈ごとの判断基準が体に染み込んでいる。
この暗黙知は、ドキュメントに書かれていないことが多い。移行プロジェクトの初期に、運用チームのベテランから「こういうときはどうするか」という話を引き出す場を作ることが、後工程の異常時設計の精度を上げる。
ブロックCRUDの「再実行時の扱い」欄に書ける内容の多くは、この暗黙知から来る。
2. スケジュール設計の思想
A-AUTOの画面を見ればわかるが、ジョブの先行関係、カレンダー例外、リカバリ時の実行順序制御は、相当な設計思想の産物だ。
Spring Batch化しても、この思想は捨てられない。JCLのSTEP順序をそのままSpring BatchのJobに変換すればよいわけではない。「なぜこの順序か」「この先行関係が崩れると何が起きるか」を理解した上でないと、Spring Batchの設計は正しく作れない。
3. 「夜間が終わらない」という恐怖の記憶
夜間バッチが朝までに終わらないと何が起きるか。業務開示が遅れ、問い合わせが殺到し、手動対応で全員が走り回る。
この恐怖の記憶が、運用設計の厳しさを生んでいる。性能見積もりの慎重さ、処理件数の上限設計、並列処理の採否判断——すべてに「夜間突き抜け」への警戒が反映されている。
移行後の設計者にこの感覚を伝えることが、技術伝播の核心だ。Oracle 19cの並列処理やフェッチバッファの設計が、単なる性能改善の話ではなく「夜間突き抜けを防ぐための設計」であることを理解した上で作るかどうか。それが設計品質の差になる。
AI・PMOへの示唆
AIはJCLを読んで構造を把握できる。スケジュール定義を解析して先行・後続関係を整理することもできる。
しかし、「このジョブが夜間突き抜けを起こしたとき、運用チームはどう動くか」「この異常終了は再実行可能か、それとも手動介入が必要か」は、JCLだけでは判断できない。
運用・保守チームと話した内容が、ブロックCRUDの「再実行時の扱い」欄と「未確認ID」欄を埋める。AIとの往復の精度は、この事前インプットの質に依存する。
PMOとして運用チームの話を引き出し、それを設計書の言葉に変換する。その役割を担える人が、レガシー移行には不可欠だ。
まとめ
移行設計は、設計書の精度だけでは成立しない。
A-AUTOとJP1はともに「移行しながら止めない」を実現する方向に進化している。ツールの選択よりも、そのツールで何十年も運用を守ってきた人たちから何を学ぶかが、移行成功の鍵を握っている。
14年間課長だった人が積み上げてきた「きっちり感」を、新しい設計の中にどう移植するかが問われている。
その第一歩は、設計書を読むことではなく、運用チームの人と話すことだ。
参考：
ユニリタ A-AUTO クラウド環境におけるシステム構成
https://www.unirita.co.jp/products/aauto/cloud.html日立製作所 JP1/Automatic Job Management System 3
https://www.hitachi.co.jp/Prod/comp/soft1/jp1/product/jp1/ajs/index.html
次回（Zenn第7話）では「昭和と令和が共存する外部連携」を書く予定です。
CSV渡し・メール渡しからAPIまで、レガシーバッチの外部連携が抱える現実を書きます。