すべてのカテゴリ

古いExcelや業務システムを直す相談で、一番危ない言葉があります。「せっかくだから全部新しくしましょう」気持ちは分かります。ただ、全部を一度に変えると、全部が同時に止まる可能性もあります。全面刷新という大博打2026年も、国内では古い業務システムを更新するモダナイゼーション需要が続いています。ただ、中小企業や小規模な現場で必要なのは、大企業向けの巨大な刷新計画とは限りません。実際の相談では、次のような状態が多いです。・Excelに長年の計算式が入っている・Accessや古いWeb画面が一部だけ動いている・担当者しか分からない入力ルールがある・紙やメールも業務の途中に残っている・過去データを捨てられない・止められる期間がほとんどないこの状態で全部を作り直すと、必要な例外まで一緒に消すことがあります。しかも、旧システムの説明書がない。担当者の頭の中が最新仕様書です。はい。退職されたら仕様書も退職します。残すExcel、変える画面私は、Excelをすぐ廃止せず、保存先として残したまま閲覧画面だけWeb化する対応をよく行います。たとえば、建築関係のExcelを読み込み、明細をWeb画面へ表示するツールでは、元のExcelを残しながら新しいHTML画面を追加しました。利用者は見やすい画面からIDを選び、詳細を確認し、計算結果を元データへ反映します。この方法なら、いきなりデータ形式を全部変えずに済みます。まず画面の使いにくさを改善する。次に入力や計算処理を整理する。最後に、必要であれば保存先をデータベースへ移す。段階を分けることで、どこで不具合が出たかも追いやすくなります。ID列ひとつの

はじめにアセンブラは「CPU に近い制御」を前提とした言語であり、COBOL は「業務ロジックの可読性」を重視した言語です。そのため、アセンブラ的に正しい実装をそのまま COBOL に持ち込むと、動作はしても保守性の低いコードになりがちです。本記事では、実際の移行作業で頻出する「ASM 的には正しいが、COBOL では避けるべきコードパターン」を 5 つに整理して紹介します。パターン①：GOTO 依存の制御構造■ ASM 的な書き方BNE LOOP1BE EXIT👉 分岐命令で処理を飛ばすのが基本。■ COBOL に直訳するとIF A NOT = B GO TO LOOP1END-IFIF A = B GO TO EXITEND-IF👉 処理の流れが追いづらく、スパゲッティ化しやすい。■ COBOL 的に望ましい書き方PERFORM UNTIL A = B ...END-PERFORM👉 制御構造を使い、処理の意図を明確にする。パターン②：1 バイトフラグによる状態管理■ ASM 的な書き方・X'00' / X'FF' で状態管理・フラグレジスタや 1 バイト領域で制御■ COBOL に直訳するとIF FLAG = X"FF"👉 フラグの意味が読み取れず、可読性が低い。■ COBOL 的に望ましい書き方IF END-OF-DATA = TRUE👉 意味のある名前＋論理値で、意図が一目で分かる。パターン③：型を信用せず MOVE を連鎖させる■ ASM 的な書き方PACK ...UNPK ...👉 数値⇔文字の変換を頻繁に行う前提。■ COBOL に直訳するとMOVE A

1. はじめにCOBOL を VSCode で動かしてみたいと思い、GnuCOBOL を Windows にインストールして実行環境を整えました。 日本語でまとまった情報が少なく、特に「VSCode で実行するまで」の手順が分かりづらかったため、今回自分が実際に行った手順をまとめています。インストール画面や VSCode の設定画面もキャプチャしていますので、同じように環境を作りたい方の参考になれば幸いです。2. GnuCOBOL のインストール手順（Windows）● ダウンロード● MSI の実行● インストール完了● 動作確認（cobc –version）cobc --versionバージョンが表示されれば OK です。3. VSCode に COBOL 拡張機能を入れる● COBOL (bitlang) をインストールThemes ではなく “COBOL” を選ぶ点に注意。● 補完・シンタックスハイライトの確認4. HELLO_WORLD を書いて実行する● ソースコード● ビルドcobc -x helloworld.cob● 実行./helloworld.exe● 実行結果5. VSCode でワンクリック実行できるようにする（tasks.json）● .vscode フォルダを作成● tasks.json の内容{ "version": "2.0.0", "tasks": [  {   "label": "COBOL Build & Run",   "type": "shell",   "command": "cobc -x helloworld.cob;

はじめに本シリーズでは、メインフレーム環境で稼働していたアセンブラ（ASM）プログラムを COBOL へ移行する過程で直面した課題を中心に紹介してきました。今回は少し視点を変えて、変換作業そのものではないが、実際の現場では確実に必要になった作業について触れます。いわば「番外編」「付録編」のような位置づけです。移行作業は、プログラムを変換して終わりではありません。オープン環境で動かすためのビルド周りの整備も、確実に必要な工程でした。Makefile 作成を依頼された背景アセンブラから COBOL への変換作業が一段落しつつあった頃、次の依頼が届きました。「COBOL をコンパイルするための Makefile を作ってほしい」対象となる COBOL プログラムは複数本。コンパイル方法はほぼ共通ですが、数が多い。正直なところ、「1本や2本なら手で書けるけれど、この数を全部手作業で作るのは厳しい…」というのが最初の感想でした。手作業での Makefile 作成の問題点手で Makefile を作る場合、次のような問題が見えてきます。・ほぼ同じ内容を何度も書く必要がある・プログラム名の書き間違いが起きやすい・修正が入ると、すべての Makefile を直す必要がある・作業者によって書き方が微妙に変わる特に今回は 対象プログラム数が多い ことがネックでした。「とりあえず作る」ことはできますが、後からの修正や再実行に耐えない作業になってしまいます。自動生成という判断そこで考えたのが、Makefile を手で作るのではなく、“作る仕組み”を作るという方法です。・Makefile の雛形（テンプ

メモリ破壊の正体と、インターフェース再構築の舞台裏はじめに本シリーズでは、メインフレームのオープン化に伴うアセンブラ（ASM）から COBOL への移行について、実務で直面した課題とその対応を紹介しています。今回はその中でも、最も危険で、発見が難しい「メモリ破壊問題」と、そこから派生したインターフェース再設計について取り上げます。現行システムでは、DB アクセスに使用する入出力エリア（I/O エリア）が引数で受け渡されていました。しかし、そのサイズはプログラムごとに異なり、レイアウトも統一されていませんでした。この事実は関係者の間で「なんとなく」共有されていたものの、長年問題なく動いていたため、誰も手を付けていませんでした。今回の移行でも当初は、・現行の COBOL 資産は修正したくない・ASM 部分だけを COBOL 化したい・共通サブルーチンで吸収したいという方針でした。しかし、この判断が後に大きな問題へとつながります。想定していた構造COBOL（業務ロジック）  ↓ASM（I/O 制御）  ↓COBOL（DB ハンドラ）  ↓DB今回の移行では、この ASM 部分を COBOL で書き直し、共通サブルーチンとして置き換える計画でした。問題の本質：I/O エリアサイズの不一致DB アクセスに使用される I/O エリアは、呼び出し元の COBOL プログラムごとにサイズが異なっていました。・あるプログラム：200 バイト・別のプログラム：500 バイト・レイアウトも微妙に異なるこれらは仕様書に明記されておらず、暗黙の契約で成り立っている状態でした。ASM ではこの曖昧さが許容

はじめに アセンブラ⇔COBOL変換シリーズの第4回として、今回はビット演算に焦点を当てています。 メインフレームのオープン化対応では、アセンブラで記述されていた処理を COBOL へ変換する場面が少なくありません。 前回までの記事では、変換時に注意すべきポイントを整理してきました。 その中でも、アセンブラでは当然のように使われているビット演算（AND／OR）は、COBOL に置き換える際に「どの方法が妥当か」を検討する必要があります。 今回は、アセンブラ→COBOL 変換の中でもビット論理演算（AND／OR）に焦点を当て、実際に採用した方法と、その判断理由について整理します。今回は COBOL 標準ではないが CBLUBIT を使用して対応した 結論から書くと、今回の変換では CBLUBIT サービスルーチンを使用して対応しました。 CBLUBIT は COBOL の標準仕様ではありませんが、特定の処理系（IBM 系、日立系など）で提供されているビット論理演算用のサービスルーチンです。 CBLUBIT の基本的な使い方 CALL 'CBLUBIT' USING OP1 OP2 'A' RESULT この 1 行だけで、OP1 と OP2 を AND（論理積）で演算し、結果を RESULT に格納する処理内容が読み取れます。 演算コード - 'A' ：AND（論理積） - 'O' ：OR（論理和） - 'X' ：XOR（排他的論理和） アセンブラ経験者であれば、元の命令の意図をほぼそのまま読み替えられる点が大きな利点です。 なぜ CBLUBIT を採用したのか今回の変換では、以

はじめに メインフレームのオープン化に伴い、アセンブラで書かれていた資産を COBOL に変換する作業に携わる中で、言語仕様の“当たり前”の違いが想定外の不具合につながる場面を経験した。 今回はその中でも、「配列の添え字」と「変数の部分参照が 1 から始まる」という COBOL の特徴が、アセンブラや C 言語経験者にとってどれほど落とし穴になりやすいかを、実際の疎通確認試験での事例を交えて紹介したい。 COBOL の添え字・部分参照は 1 始まり COBOL 言語では、配列（OCCURS）の添え字や文字列の部分参照の開始位置が1 から数えるという仕様になっている。 これは COBOL を主戦場としてきた人には当然の前提だが、アセンブラや C 言語で開発してきた人間にとっては強い違和感がある。違いは次のようになる。頭では理解していても、無意識に「0 始まり」で考えてしまうのが経験者の性だ。 疎通確認試験で発覚した問題 実際の疎通確認試験において、入力ファイルの項目に「キー開始位置」が存在していた。この値はアセンブラ時代の仕様を踏襲しており、0 が設定されるケースがある設計だった。 COBOL プログラム側でこの値をそのまま部分参照の開始位置として使用したところ、 キー開始位置 = 0 → COBOL では参照範囲外 キー開始位置 ≥ 1 → 一見、正常動作しているように見える 特に厄介なのは、0 以外の値ではエラーにならず、正しく動いているように見える点だ。原因と対策 原因は単純で、 アセンブラ（あるいは C）的な「0 始まり」の発想 COBOL の「1 始まり」の部分参照

はじめに本シリーズでは、メインフレームのオープン化に伴うアセンブラ（ASM）から COBOL への移行について、実務で直面した課題とその対応を紹介しています。今回はその中でも、私が最初に苦労したレジスタ管理（R0～R15）について取り上げます。COBOL ではデータ項目に名前を付けて管理しますが、アセンブラでは CPU 内部のレジスタを使い分けながら処理を進めます。そのため、解析時には「今このレジスタには何が入っているのか」を常に意識しながらソースを追う必要がありました。レジスタの役割と複数使用の難しさメインフレームのアセンブラには、以下の 16 本の汎用レジスタがあります。R0 ～ R15（汎用レジスタ）レジスタは高速な作業領域として、次のような用途で利用されます。・データの格納・アドレスの保持・パラメータの受け渡し・演算結果の保存・ループ制御実際の ASM ソースでは、複数レジスタが同時に使われることが珍しくありません。・R1：入力データのアドレス・R2：出力データのアドレス・R3：処理件数・R4：ワーク領域・R5：テーブル検索用しかし、これらの役割がコメントに書かれているとは限らず、解析時には「R5 は今どのデータを指しているのか」「この命令で R3 は更新されたのか」といった点を逐一確認する必要がありました。レジスタ追跡の実際解析では、単に「R1 を使っている」ではなく、1 ステップ単位でレジスタの内容を追跡しました。その値が、・テーブルの先頭アドレスなのか・データ領域のオフセットなのか・ループカウンタなのかを確認しながら処理を追う必要がありました。さらに、アセンブラで

はじめに メインフレームのオープン化対応において、アセンブラからCOBOLへの変換作業は避けて通れないテーマです。 単に「文法を置き換える」だけで済めばよいのですが、実際の現場ではそう簡単にはいきません。 今回の変換作業で特に強く感じたのは、アセンブラ特有の「レジスタ思考」から、 COBOLの「変数（レコード）思考」へ切り替えることが最大の難所であるという点でした。 この記事では、構造化データ（レコード配列）のアクセス処理を例に、 ASM→COBOL変換で直面した“思考の転換”についてまとめます。アセンブラにおけるデータアクセスの考え方 アセンブラでは、構造化されたデータであっても最終的にはメモリ上の並びとして扱います。 今回の変換対象では、以下のような実装が多く見られました。 構造体（レコード相当）の配列 構造体サイズは256バイト固定 レジスタに配列先頭アドレスを設定 項目アクセスは「レジスタ + オフセット」 次の要素へは「レジスタに256を加算」 概念的な ASM の例を示すと、次のようになります。* ASM（概念例） LA R1,AREA ; 先頭アドレス L R2,0(R1) ; 項目A L R3,4(R1) ; 項目B LA R1,256 ; 次のレコードへこのように、アセンブラでは常に「このレジスタはいまどこを指しているのか」「次の要素に行くには何バイト足せばよいか」という、 アドレス演算中心の“機械寄りの思考”が求められます。COBOLにおけるデータアクセスの考え方 一方、COBOLではアドレス計算を意識する必要はほとんどありません。 デ

はじめに メインフレームのオープン化やモダナイゼーションに伴い、アセンブラ資産を COBOL に変換する現場が増えてきました。 ところが、アセンブラから COBOL への変換では、「アセンブラでは当然だった前提が、COBOLでは成り立たない」という問題に直面します。 その代表例が「1バイトの扱い」です。本記事では、アセンブラにおける 1バイト（16進 00～FF）を COBOL ではどう扱うべきか、実体験ベースでまとめます。 アセンブラにおける「1バイト」の世界 アセンブラにおいて 1バイトは、 16進：00 ～ FF 10進：0 ～ 255 という完全な数値範囲として自然に扱えます。 IC / STC：ロード・ストア A / AH / S：数値加減算 CLI：直接比較 ビット単位のマスクも容易 つまり、1バイト＝符号なし整数という前提でロジックが組まれているケースは珍しくありません。 COBOLで1バイト定義が難しい理由 まず直感的に定義しようとすると、次の罠にハマります。 01 WS-BYTE PIC 9. → これは「1桁の数字」であり、0～9 しか表現できません。 01 WS-BYTE PIC X. → これは 1バイトですが文字型であり、数値演算はできません。 つまり DISPLAY（ゾーン）形式では、アセンブラの 1バイト数値（00～FF）を再現できません。 COMP-5 を使えば 1バイトになる？ 次に思いつくのが COMP 系の利用です。 01 WS-BYTE PIC S9(3) COMP-5. 見た目は 0～255 を扱えそうですが、実際には 2バイト確保され

先月から取り組んでいる古いシステムの改修作業が、予想以上に大変な作業になっています。 10年以上前に作られたシステムで、当時とは技術的な環境がガラッと変わっているんです。 まさに「こんなはずじゃなかった」という状況の連続でした。 改修作業で特に苦労したのは、3つのポイントです。 まず、古いプログラムのコードを読み解くのに時間がかかりました。当時の開発者の方の考え方を理解するのに、まる2日かかってしまいました。 次に、データベースの構造が現在の標準的な作り方と大きく異なっていて、データの移行作業で予想外のトラブルが発生しました。 最後に、新しいセキュリティ基準に合わせるため、ログイン機能を一から作り直す必要が出てきました。 古いシステムの改修には、実はメリットもたくさんあります。 既存のデータをそのまま活用できるので、お客様にとってはコストを抑えて機能アップできます。 また、長年使い慣れた操作感を残しつつ、新しい機能を追加できるので、スタッフの方の負担も最小限に抑えられます。 そして、システム全体を入れ替えるよりも、はるかに短期間で改善効果を実感していただけます。 古いシステム改修のコツをお伝えすると、まず現状の徹底的な調査が欠かせません。 私は改修前に必ず、既存システムの動作を細かくチェックして、どの部分が重要でどこを変更できるかを整理します。 また、段階的に改修を進めることで、途中でトラブルが起きても影響を最小限に抑えられます。 無理に最新技術にすべて置き換えようとせず、必要な部分だけを現代的にアップデートする方が成功しやすいです。 以前にも、古いシステムを改修を手掛けた後は

山村風太です。「このシステム、もう限界なんです…」スタートアップや中小企業から、よくこんな相談を受けます。何年も前に作られたレガシーシステム。メンテナンスが困難で、新機能を追加するたびにバグが発生。でも、業務は止められない。どうすればいいのか。。。レガシーシステムの刷新は、エンジニアにとって最も難易度の高いミッションのひとつです。でも、正しい手順を踏めば、リスクを最小限に抑えながら移行できます。僕が実践しているのは、「段階的移行アプローチ」です。まず、現行システムの全体像を把握します。どの機能が、どの業務で、どれくらいの頻度で使われているのか。ここを理解しないと、優先順位を間違えます。次に、新システムと並行稼働させる期間を設けます。いきなり切り替えるのではなく、両方を動かしながら徐々に移行。何か問題が起きても、すぐに元に戻せる状態を維持します。そして、ユーザーとの密なコミュニケーション。現場の声を聞きながら、必要な機能を優先的に実装していく。完璧を目指すより、まず使える状態を作ることが大切です。レガシーシステムは、企業の歴史そのもの。それを尊重しながら、新しい未来を作る。技術だけじゃなく、寄り添う姿勢が問われる仕事だと思っています。もし同じ悩みを抱えているなら、一緒に解決策を考えましょう。