質問の背景: 企業のモダナイゼーションの取り組みにおいて、ビジネスアナリストはしばしば 知識の劣化 に直面します。これは、重要なビジネスロジックが読めないレガシーコードにしか残っていない現象です。この質問は、元のアーキテクトが数十年前に退職し、完璧に実行されるが解釈が困難な COBOL プログラムが残された メインフレームからクラウド への移行から生まれました。歴史的な文脈は、モノリシックなバッチ処理から分散型 マイクロサービス への移行に関するものであり、暗黙の状態管理は明示的な API 契約に変わらなければなりません。
問題は、認識の不透明性に集中しています: システムは機能するが、誰もその理由を知らない。 COBOL コードベースには、暗黙のビジネスルール（エッジケース、規制パッチ、手動オーバーライド）が含まれており、元の開発者はそれを記録として残していませんでした。現在の運用スタッフは入力と出力を理解していますが、意思決定ロジックは理解していません。一方、新しい クラウドネイティブ アーキテクチャでは、これらのルールを分離し、文書化し、リアルタイム消費のために REST エンドポイントを通じて公開する必要があります。固定された規制の締切は、数年にわたる考古学的調査を防ぎますが、ルール抽出のエラーは GDPR のデータ処理命令や財務報告の正確性を侵害する可能性があります。
解決策は、三角測量逆アプローチを採用します。まず、運用スタッフと イベントストーミング ワークショップを実施して、観察可能なビジネス行動をマッピングし、「ブラックボックス」プロセスを特定します。次に、静的コード分析ツールを使用して COBOL プログラムの 制御フローダイアグラム を生成し、ビジネス成果に対する変数の変化をクロスリファレンスします。三番目に、新しい マイクロサービス プロセスがレガシーシステムに対してトランザクションをミラーリングする 並行稼働シャドウモード を実装し、生産影響なしで不一致を調査のためにフラグします。これにより、コード考古学がステークホルダーの記憶を検証し、ステークホルダーのコンテキストがコードの異常を説明します。
地域の保険会社は、1980年代の COBOL ポリシーレーティングエンジンを Python/FastAPI マイクロサービススイートに置き換え、リアルタイムモバイル見積もりを可能にする必要がありました。元の計算ロジックには、複雑な地域リスク重み付け、季節調整要因、40年以上も修正された再保険条項が含まれていました。残りの3人の COBOL 開発者は退職し、現在のITスタッフはシステムを「魔法の箱」と見なし、正しいプレミアムを生成するが特定のエッジケースに対する数学的な導出を説明できない状態でした。規制当局は、未サポートのインフラ罰則を回避するために、8ヶ月以内に移行を完了するよう要求しました。
要件を把握するためにいくつかのアプローチが評価されました。最初のオプションは、開発者が COBOL ソースのすべての IF ステートメントと MOVE 操作を手動で文書化する コードから仕様への転写 を提案しました。利点には理論的な完全性と正確なロジックの保存が含まれました。欠点は深刻でした: コードベースには2百万行以上のスパゲッティコードが含まれ、文書化されていないグローバル変数があり、これは数年かかる作業となり、期限を逃す可能性が高く、転写エラーを引き起こす恐れがありました。
二つ目のオプションは、統計的回帰を通じてルールを推測するために、入力（ポリシー属性）と出力（プレミアム金額）を観察する ブラックボックス要件導出 を提案しました。利点はスピードと、技術的負債ではなく現在のビジネス価値に焦点を当てたことでした。欠点には、稀な請求シナリオのための休眠コードパスを検出できないことと、バグを機能として定義してしまうリスクが含まれました。
三番目のオプション、並行検証による行動考古学 では、5年間の生産ログからサンプルデータを抽出し、実際のトランザクションから意思決定ツリーを構築し、自動差分ツールを使用してこれを COBOL ソースと照合します。
チームは、精度を重視しながら速度のバランスを取ることができるため、三番目の解決策を選択しました。実行されるコードパスに焦点を当てることで、スコープを60％削減し、ビジネスルールを正しく捕捉することを保証しました。匿名化された過去のトランザクションを含む データレイク を設立し、これをレガシー JCL ジョブと新しい FastAPI サービスに通して、0.01％を超えるプレミアム計算の不一致を自動的にフラグしました。これにより、1992年以前に発行されたフロリダポリシー用のハリケーン控除のオーバーライド、退職したエージェントのための特別手数料計算、数十年にわたり手動のスプレッドシート調整で「修正」されていた四半期の税務報告における丸め誤差の3つの重要な未文書の条件が明らかになりました。 マイクロサービス は、これらのエッジケースをハードコーディングされた定数ではなく、設定可能なビジネスルールとして明示的に処理するように再設計されました。
レガシーコードを逆アプローチする際、移行中に安全に排除できる重要なビジネス制約と技術的な作業周辺の違いをどのように判別しますか？
候補者はしばしば、すべての既存のロジックが現在のビジネス目的に役立っていると仮定し、レガシー保存の 埋没コスト誤謬 に陥ります。正しいアプローチは 時間的文脈分析 を含みます: コード変更の日付スタンプを調べ、既知の規制変更、合併、または存在しない技術的制約と相関させることです。たとえば、 COBOL のデータ切り詰めルーチンは、元の DB2 スキーマが固定幅フィールドを使用していたために存在する可能性が高く、現代の PostgreSQL は可変長文字列をサポートしているため、切り詰めルールの必要が完全に排除されます。BAは、ビジネスステークホルダーとの 意図確認セッション を実施し、疑わしい作業周辺を「これを削除することで簡素化できますか？これはコンプライアンスに影響しますか？」と提示する必要があります。「Xを保持すべきですか？」と尋ねるのではなく、これにより、必要性ではなく保存の負担が移ります。
新しいシステムが COBOL モノリスに存在するからという理由だけで非効率的なバッチ処理ワークフローを複製しないようにするにはどうしますか？
多くの候補者は、プロセス再設計 なしに機能的同等性にのみ焦点を当てます。失敗は、BAが現在の状態（例: 「システムが2 AMに夜間バッチを実行します」）を未来の状態の要件として文書化し、Apache Kafka や RabbitMQ を利用したイベント駆動アーキテクチャがリアルタイム処理を可能にすることを無視することから生じます。解決策は、能力マッピングを必要とします: 「何」(リスク計算は実行しなければならない)と「方法」(バッチvsストリーミング)を分けます。BAは 価値ストリーマッピング を実施して、業務ルールではなく操作の便宜に役立つバッチスケジュールの待機時間を特定すべきです。 REST エンドポイントがアンダーライターに即時フィードバックを提供できることを示すことで、見積もりから契約までの時間を24時間から30秒に短縮し、通常なら「古いシステムからあまりにも異なる」と拒絶される可能性のあるアーキテクチャの変更を正当化します。
サンプルデータ観察期間中にトリガーされなかった暗黙のルールなどの「未知の未知」のリスクを定量化し、コミュニケーションする方法論は何ですか？
候補者は頻繁に、歴史的データに対して100％のテスト合格率に基づいてステークホルダーに誤った自信を与えます。洗練された回答は、レガシーデータにおける サンプリングバイアス を認識し、合成シナリオに対するストレステスト を採用することを訴えます。これは、生産ログで見られない境界条件を評価する ファジー入力データ を生成し、その後 COBOL と新しいシステムの出力を比較することを含みます。さらに、BAは新しいアーキテクチャに サーキットブレーカーパターン を設ける必要があります: もし マイクロサービス が処理できないトランザクション構造に遭遇した場合（潜在的なルールを見逃したことを示している）、それは優雅にレガシー SOAP ラッパーにデグレードするか（利用可能な場合）、人間のレビューのためにフラグを立てるべきであり、静かに失敗したり、null値にデフォルトしたりするべきではありません。コミュニケーション戦略では、95％のルールが検証されている一方で、5％の残余の不確実性があることを示す 確率的リスクマトリックス を利用し、3か月のハイパーケア期間と手動の照合チェックを倍増させることを要求します。