歴史の長さゆえに
ソースコードが複雑化
本稿では最終的な目標として、コードの見える化を実践しながら以下を実現できるよう進めていくことにする。
❶SEU からの脱却
❷コードの修正履歴をいつでも確認可能にする
❸バグや新機能の追加作業を、チームの他メンバーの作業に影響することなく、いつでも自由に実行可能にする
❹作業途中でも他メンバーに引き継げるようにする
❺開発途中のコードと現在本稼働しているコードをそれぞれ管理可能にする
❻修正箇所を客観的に他メンバーに見てもらえるようにする
❼リリース記録をリリース番号で管理する
現在、IBM i で稼働している基幹システムにはRPG Ⅲ、ILE RPG（定位置記入方式）、フリーフォームRPG（以下、FF RPG） が混在している。なかでもRPG Ⅲは、まだまだ現役のコードとして活躍している。
すでに言われているようにRPG言語は大変歴史が古く、その分、長期に渡ってさまざまな開発者の手により修正されてきたため、以下のような問題を含んでいる。
・ドキュメントが最新化されていない、もしくは存在していない
・コードが読みにくい（サイクルを使用して記述されている場合はより顕著）
・誰がいつ、どこを修正したかの記録がない
ドキュメントについては多様なツールが登場しているので、手作業に頼らずある程度は作成できる。ここでは、それ以外について考えてみたい。
コードが読みにくい
定位置記入形式とコメントの多さ
コードの読みにくさには、大きく2つの問題がある。1つは定位置記入形式というRPG言語の特殊な事情。もう1つは「コメントの多さ」である。それぞれ考えてみよう。
まず、RPG ⅢおよびILE RPGのコードは定位置記入形式で記述されている。コンパイラーへの指示は何桁目に何を記述するかで決まるので、それを理解すれば非常に簡単にプログラムを作成できる。その反面、その意味を知らないとコードを読むことができない。
とくにRPGサイクルで書かれていると、ある意味難解なパズルを解いている感覚に捉われる。さらに桁位置の制約により、ファイル名や変数名の長さに制約があるのも読みにくさを助長している。RPG Ⅲではファイル名は8桁まで、変数名は6桁までしか名前に使用できない。
2つ目のコメントに関しては、長期に渡って使用されてきたプログラムの宿命とも言える。修正するたびにコメントとして修正記録を記入しているコードが多く（過去にはそれが推奨されていた）、サイズが固定された5250画面で使用するエディタ（SEU）では、ロジックそのものの視認性がコメントに阻害されているケースが多々あった。
よくあるRPGのコメントは、プログラムの鑑と修正履歴だが、コメントはあくまでプログラマーが記述するので、常に最新の状態で正しくかつわかりやすく記述されている保証はない。
プログラムの鑑には、作成者、作成日時、修正者、修正日時が書かれている場合が多いが、これが正確に記されているかどうかは誰にも保証できない。またその修正記録から、ソースのどこを修正したかを辿れるわけでもない。
以下のような経験はないだろうか。
・延々と修正コメントが書かれており、本来のコードのロジックをSEU画面で追うのが難しい
・修正前のコードがコメントアウト（7桁目にアスタリスク）されて新規コードがその下に書かれているが、アスタリスクを見落とし、コードの見間違えに気づかず時間を浪費した
・丁寧に書かれているコメントがかえって読みにくい
本来プログラムのコメントは、コードの読みやすさを補完するためにだけ記述されるべきで、修正履歴は別に記録しておいたほうがよい。つまり何をコメントとして残すのか、しっかり考える必要がある。
これらの問題を整理すると、現在のプログラムコードのブラックボックス化の原因は、最新のコード内にコメントとして変更履歴が詰め込まれていて読みづらい（リーダブルでない）、つまり保守しづらいことであり、最新のコード（現在本稼働しているプログラムのコード）と、その修正履歴を別々に管理する必要がある。
誰がいつ
どこを修正したかの記録がない
ソースコードの修正記録は、それをコメントで記述するのではなく、機械的に比較して認識できればよい。単純に言えば、修正前と修正後のコードがあって、それを比較できればよいのだ。
修正前のコードを保管することは、日常よく行われている。実際の修正作業の流れは、図表1のようになる。
ただし、コピーしたメンバーxxxxxx@1 などは万一の場合、修正を元に戻すために使用できるが、どこを修正したかの比較対象として利用されているケースは稀である。
このコードがタイムリーに削除されなければ、時間が経つにつれ、削除してよいかを判断できず（誰かが必要に応じて、あえて残しているかもしれない）、そのまま放置されることになる。
ソースコードの修正記録は、長く使われる基幹システムではとくに大事になる。いつ、誰が、どこを、どう修正してきたか（履歴）をきちんと追えるかどうかで、原因特定に必要な時間が決まってくるからだ。
基幹システム開発およびシステム保守は、個人ではなくチーム（システム開発課などの部署）で対応する。長期に渡って使用されれば、携わる担当者も多くなり、そのたびに引き継ぎが重要になる。あるいは引き継ぎできずに専任者に任せっきりにした結果、後継者がいない事態を招く。
保守の後継者を育てられない課題が指摘されているが、ノウハウが専任者の頭の中にしか存在せず、それを次の世代に引き継げないことが一番の問題である。せめてソースコードの変更履歴だけでも、口頭以外の方法で記録して引き継げる環境が理想である。
本来、基幹システムの開発は、作業途中でも他のメンバーに引き継げる仕組みがそもそも必要であるし、前日までの作業履歴を毎日確認したうえで続きから始められれば、作業効率も格段に向上する。
これを実現するのがバージョン管理システム（Version Control System。以下、VCS）である。種類はいくつかあるが、本稿ではデファクトスタンダードである Git を取り上げる。
Git を利用することで、以下が可能になる。
・前日までどこを修正したかが可視化できる
・複数のソースコードを修正していても、すべて把握できる
・他のメンバーにすぐに引き継げる
・開発とリリースを確実に分業できる
Gitはコマンドベースで利用するツールだが、今回はそちらを割愛し、Rational Developer for i （以下、RDi）とGitを連携して利用を開始できるよう、なるべくシンプルに説明していきたい。
著者｜
小川 誠氏
ティアンドトラスト株式会社
常務取締役
1989年、エス・イー・ラボ入社。その後、1993年にティアンドトラストに入社。システム/38 から IBM i まで、さまざまな開発プロジェクトに参加。またAS/400 、IBM i の機能拡張に伴い、他プラットフォームとの連携機能開発も手掛ける。IBM i 関連の多彩な教育コンテンツの作成や研修、セミナーなども担当。2021年6月から現職。
［i Magazine・IS magazine］
