「あの人に聞けば分かる」。長く使ってきた基幹システムでは、日々の業務がこの一言に頼っていることがあります。しかし、その担当者が退職したときに失われるのは、古いプログラミング言語を読める能力だけではありません。 なぜ月末だけ処理順を変えるのか。どの取引を手作業で補正するのか。夜間処理が止まったとき、どこまで実行済みなら再実行できるのか。こうした判断の根拠が失われると、プログラムが残っていても業務を安全に続けることが難しくなります。 レガシーシステムのモダナイゼーションでは、技術の更新と同時に、担当者の判断を組織で再現できる状態にすることが重要です。 継承する対象はコードだけでなく、判断の根拠と運用上の確認方法まで含みます。 ブラックボックスは、プログラムの外にもある ブラックボックス化を「仕様書がなく、ソースが読みにくい状態」と捉えると、調査範囲が狭くなります。実際に確認すべき知識は、少なくとも次の四つに分かれます。 知識の種類 確認したい内容 残すべき成果物 業務ルール 締め日、計上基準、端数処理、例外の承認条件 ルール一覧、判断表、具体的な入出

「保守費が高いのでオープン化したい」「技術者を確保しやすい言語に変えたい」「業務に合わなくなった仕組みを見直したい」。いずれもモダナイゼーションの出発点になりますが、必要な移行方式は同じではありません。 現行の動きをできるだけ変えずに移す方式に大幅な業務改革まで期待すると、目的と実施内容がずれます。逆に、保守期限への対応を急ぐ局面で、業務とデータを一度に全面再設計すれば、期限と予算の制約が厳しくなります。 方式を選ぶ前に決めたいのは、何を改善するために、どこまで変えるのかです。 移行方式にはそれぞれ役割があります。業務目的と制約に照らして選びます。 「オープン化」を、投資の目的に言い換える オープン化という言葉は、専用環境から汎用的な基盤へ移すこと、技術や接続方式を標準化することなど、異なる意味で使われます。本記事では、移行先のOSや言語を決めるだけでなく、保守・連携・調達の選択肢を広げる取り組みとして考えます。 その効果を評価するには、目的を観察可能な指標に言い換える必要があります。 優先したい目的 評価する指標の例 併せて確かめる条件 コスト

新システムが完成しても、そのまま業務を移せるとは限りません。旧システムで処理中の注文、締め前の残高、承認待ちの申請、送信済みか判別しにくい外部連携など、切り替え時点にはさまざまな途中状態が残っています。 一括切り替えか、段階移行かを選ぶ際には、画面やプログラムの完成度だけでなく、これらの状態をどこで引き継ぎ、どう検証するかを考える必要があります。 「業務を止めない」とは、必ずしも停止時間をゼロにすることではありません。許容できる停止時間と、守るべき取引・データを先に定め、その条件を満たす移行を設計することです。 移行経路だけでなく、切り替えを止める地点と戻す条件を計画します。 一括と段階では、難しさが現れる場所が違う 観点 一括切り替え 段階移行 切り替え単位 対象範囲を決めた時点でまとめて移す 業務・拠点・利用者などの単位で順に移す 主な負担 移行作業、データ検証、判断を短時間に集中させる 新旧連携、同期、運用ルールを一定期間維持する 業務への影響 失敗時の影響範囲が広くなりやすい 影響を限定しやすいが、共通データから波及する場合がある データ

NotesからMicrosoft 365への移行を考える際、「NotesのデータベースをSharePointへ移せばよい」と捉えると、見積もりや設計を誤る可能性があります。同じNotesデータベースでも、文書を共有するものと、承認・計算・外部連携を担う業務アプリでは、移すべき対象が異なるためです。 移行の起点は、製品同士を一対一に対応させることではなく、現在のアプリが提供している機能を分解することです。文書、画面、処理、データ、権限を整理し、それぞれに適した移行先を検討します。 本記事では、Notes／Domino上の業務アプリと共有データを対象にします。メール・カレンダーの移行は、別の計画として扱う必要があります。 一つの移行先へまとめる前に、アプリの役割を分解します。 Notesの「文書」には、業務の状態が入っている 見た目が帳票のようなフォームでも、入力に応じた計算、必須項目の判定、承認者の選択、定期的なデータ更新などが含まれている場合があります。Notes／Dominoでは、エージェントによる処理の自動化も可能です。そのため、文書を抽出す

AS/400の刷新を検討すると、「RPGを別の言語へ書き換える」という話から始まることがあります。しかし、保守の難しさの原因が、言語そのものにあるとは限りません。巨大なプログラム、分かりにくいデータ定義、複雑な呼び出し関係、再現できないテストやビルドが、変更を難しくしている可能性もあります。 刷新の選択肢には、既存環境を改善する方法と、別の基盤へ移す方法があります。どちらが適切かは、現在の問題と、将来の運用方針によって変わります。 本記事では、現在もAS/400という呼び方が使われる業務環境を含め、IBM iとそのRPG資産を対象に考えます。実際の対応では、稼働しているOS、RPGの世代、コンパイラー、適用済みの更新を確認します。 既存環境の改善と、別基盤への移行は、それぞれ目的と変更範囲を定めて比較します。 最初に、刷新したい対象を分ける 「AS/400を刷新する」という一言には、性質の異なる課題が含まれます。画面操作を改善したいのか、機能追加を速くしたいのか、保守要員を確保したいのか、基盤を統一したいのかを、切り分けて考える必要があります。

RPGのソースを解析し、画面と帳票を一覧にすれば、移行範囲を把握できるでしょうか。IBM iの業務システムでは、それだけでは不足する場合があります。 CLは、どのプログラムを、どの順序で、どのファイルに対して実行するかを制御します。論理ファイルは対象レコードを絞り込み、トリガーはデータ更新をきっかけに別の処理を起動します。こうした構造では、一つのRPGを移しても、業務全体を移したことにはなりません。 現行調査の対象は、プログラムの本数だけでなく、業務の入口、処理の呼び出し、データの読み書き、運用上の実行条件まで広げる必要があります。 表面のコードだけでなく、実行とデータを支える依存関係までたどります。 「請求処理」という名前のプログラムだけでは、請求業務は分からない 仮の例として、月次請求の処理を考えます。スケジューラーからCLが起動し、CLが実行対象のライブラリーやファイルを設定したうえで、複数のRPGを呼び出す構成です。 RPGは、論理ファイルを使って未請求の取引を読み、物理ファイルを更新します。その更新を契機にトリガーが履歴を記録し、後続の

「全件を取り込めた」「移行プログラムは正常終了した」。どちらも必要な確認ですが、それだけでは新システムで業務を続けられると判断できません。移した顧客コードが別の取引先を指していたり、過去の伝票が現在の単価で再計算されたりすれば、処理として成功していても業務上は誤りです。 レガシーシステムには、長年の運用によって定着したデータの読み方があります。モダナイゼーションのデータ移行は、その読み方を明らかにし、新しい設計でも意味が通じる形へ変換する仕事です。 変換前後の対応と例外を追跡できることが、移行品質の土台になる。 最初に調べるのは、項目名と実データのずれ 設計書の項目名が「日付」でも、実データには未確定を表すゼロや、特別な処理を指示する値が含まれているかもしれません。「顧客コード」も、全社で一意なのか、会社・部門・年度と組み合わせて初めて一意になるのかで移行方法が変わります。 そこで、項目定義の確認と並行して、値の分布、空欄、重複、桁数、参照先のないデータを調べます。これをデータプロファイリングと呼びます。ただし、異常に見える値を機械的に修正する前

仕様書が古い、処理の意味を知る担当者が少ない、ソースコードの量が多すぎる。こうした状況で、生成AIによるコード説明や仕様書作成は、調査の負担を軽くする手段として期待できます。 ただし、読みやすい説明ができても、それだけで新しいシステムを設計できるわけではありません。その間には、確認の段階が必要です。AIの活用を成果につなげるには、出力の量だけでなく、説明を裏付ける根拠と、まだ確認できていない範囲を管理する必要があります。 AIが整理した説明を、元資料と実行結果へ結び付けて確認する。 三つの問いを分けると、AIの役割が明確になる レガシーシステムの調査では、少なくとも三つの問いを扱います。 問い 主な確認材料 AIを活用できる作業 コードには何が書かれているか ソース、定義体、設定、依存先 処理の要約、条件の整理、関連資料の検索 本番では何が起きているか ジョブ履歴、ログ、実データ、実行環境 記録の分類、仮説の作成、調査箇所の抽出 今後もその業務が必要か 業務方針、利用状況、担当者への確認 論点の整理、選択肢や確認事項の草案 最初の問いに答えられて

レガシーシステムを刷新するとき、現行システムと新システムに同じデータを与え、結果を比較する方法は有効です。仕様書が十分でない場合でも、実際に動いている処理を確認材料にできます。 しかし、出力の一致だけで移行を判断すると、現行の不具合を引き継いだり、帳票に出ない更新の誤りを見落としたりします。移行テストでは、そのまま引き継ぐ振る舞いと、承認を得て変更する振る舞いを切り分けたうえで、「この業務を続けられる」と判断するための証拠を集めます。 差異を発見し、その理由を説明できることが新旧比較の価値になる。 期待する結果を誰が決めるか テストを始める前に、何を正しい結果とするかを整理します。現行の出力をそのまま期待値にできる処理もあれば、業務ルールの確認が必要な処理もあります。 対象 期待値の決め方 判定で残す記録 そのまま継承する業務 現行結果と業務担当者の確認を基にする 比較条件と一致の証拠 仕様を変更する業務 承認済みの新しい業務ルールを基にする 変更理由と期待される差異 現行の不具合を修正する業務 正しいルールを改めて確認する 旧結果の問題と修正後

基幹システムを使い続けながら、新しいWeb画面や外部サービスを連携させたい。こうしたモダナイゼーションでは、既存の機能をAPIとして提供する方法が有力な選択肢になります。変更する範囲を抑え、必要な機能から追加できます。 一方、古いテーブルの項目をそのまま公開するだけでは、既存の複雑さが新しいシステムにも持ち込まれます。API化を将来の変更に生かすには、業務の意味と責任の境界を設計する必要があります。 連携先が既存内部の都合を抱え込まないよう、境界で意味と処理条件をそろえる。 公開する単位を、業務上の操作から考える たとえば「注文テーブルを更新する」というAPIだけを用意すると、利用側が注文の状態、明細との関係、変更可能な条件を知る必要があります。連携先が増えるほど、同じ業務判断が複数の場所に散らばる可能性があります。 「注文を受け付ける」「注文を取り消す」「出荷状況を照会する」のように、利用側が実行したい操作から考えると、既存側に残す判断が明確になります。すべてを大きなAPIにまとめる必要はありませんが、整合性を保つために一体で判断すべき処理は、

レガシーシステム刷新の検討で、最初に知りたいことの一つは費用と期間です。しかし、プログラム本数や画面数を数えた段階の見積もりと、業務やデータの調査を終えた後の見積もりでは、前提が大きく違うことがあります。 見積もりの精度を高めるには、数字を細かくする前に、その数字を変え得る条件を明らかにする必要があります。何が分かっていて、何が未確認で、どの調査を行えば次の判断ができるのか。これを説明できる計画が、予算と進捗の管理を支えます。 図：調査で得た根拠に合わせて、実施範囲と見通しを具体化する。 プログラム本数だけでは、必要な仕事が見えない 同じ本数のプログラムでも、独立した照会処理が中心のシステムと、締め処理や外部連携が複雑なシステムでは、必要な調査と試験が異なります。コード量に表れないデータ補正や運用担当者による手作業が、移行範囲に入ることもあります。 また、変換されたコードが動くまでの工数だけでは、刷新全体の費用は説明できません。データの移行、性能確認、権限設計、利用者教育、切り替え準備、運用引き継ぎ、旧環境の終了までを対象に含める必要があります。