text：小川 誠 ティアンドトラスト
IBM iのブラックボックス化と
ドキュメント問題を解決する
次に、長期にわたり使用される基幹システムの弊害について、少し掘り下げたい。
IBM i ユーザーから、「稼働しているプログラムのドキュメントがない」という話をよく聞く。システムを改修する必要が生じた時にそもそも何を修正すればよいのか、対象のプログラムはどんな処理が実装されているのか、修正がシステムにどう影響するかが見えない。
それでも、ユーザーからの要望に対応しながら基幹システムは日々動き続けている。ドキュメントがないにも関わらず、なぜ対応できるのか。
それは社内のIT部門に、システムにも業務知識にも長けたプロフェッショナルがいるからだ。システムの概要がほぼ頭に入っており、問題が発生した場合にどこを見ればよいのか、新しい要望があった場合に改修の影響度をどうやって見極めるか、職人技で対応できる人材がいる。「この人に任せておけば大丈夫」というプロフェッショナルたちのおかげで、基幹システムは社内インフラとして今日も稼働し続けている。
しかし今後は、これが大きな問題となる。真のプロフェッショナルも、いつかは仕事を離れるからだ。ドキュメントがなくても、その人たちがいたから運用できた基幹システムは、その人たちがいなくなった途端にブラックボックス化する。そんな日が、このままだと必ず訪れる。
このドキュメント問題は、以下のようなさまざまな要因が複雑に絡み合って生まれている。
●初期のころは（30年以上前はそもそもPCがないので）、ドキュメントが手書きだった
●ドキュメントの重要性が今ほど技術者に認識されていなかった（30年後もプログラムが使われることを想定していない）
●ワープロ専用機でドキュメントを作成し、印刷して保管していた
●PCが登場して多様なワープロソフトで作成するようになったが、ファイルの保管について取り決めがなかった
●現在では利用できないワープロソフトが多く、保管していたファイルがあったとしても、読み込めない
●印刷・保管していたドキュメントを廃棄・紛失している
もちろん、きちんと管理しているユーザーも多いだろうが、そうした場合でも、日々発生する修正点や改善点を該当ドキュメントにその都度、正確に反映しているケースは少ないのでなかろうか。
このようにドキュメントは保存・印刷された瞬間から、時間の経過とともに内容が陳腐化し、システム改修時に参照されなくなり、最終的には存在を忘れられる。IT部門のプロフェッショナルは、この仕様書に書かれている内容のエッセンス（日々の運用と改修に必要な情報）が頭の中に入っており、彼らの存在によってドキュメント問題が表面化していないにすぎない。
となると、「このようなブラックボックス状態で、かつ古い言語で作られているシステムを今後も使い続けるのは危険。一刻も早く別システムに移行しよう」という声が説得力を帯びることになる。
このドキュメント問題には、実は解決策がある。IBM i はディスクに保管しているものをオブジェクトとして扱う。個々のオブジェクトは種類によって必要な情報がその中に記録されており、そのオブジェクトに対して行える操作も厳密に制御される。
このオブジェクト情報はデータベース情報として出力する仕組みがあり、プログラムのソースコードなどと一緒に分析すれば、ある程度のドキュメントはこのオブジェクトから生成できる。
つまりまったくドキュメントがなくても、システムの全体像やプログラムの概要などをディスクに保管している内容から復元できる。これを実現するツールは多数提供されているので、ドキュメントが存在しないと諦めるのではなく、積極的にツールを使ってブラックボックス化したシステムを解析することが重要だ。
システムの歴史と
ソースコードの変更履歴・作業ログ
ツールを使って生成できる情報は、「システムの現在の姿」である。今現在の姿を把握して初めて、そのシステムを改修できる。現在のシステムを将来にわたって使い続けていくのにどうしても必要な情報であり、基幹システムに精通しているプロフェッショナルが頭の中で日々反芻している情報である。
しかし、ツールで生成される情報には欠落がある。それは「歴史」である。基幹システムの年表はツールでは作成できない。プロフェッショナルはこの年表が頭に入っていたり、自分の作業メモとして残していたり、文書としてファイルサーバーなどに保管している。
しかし、いつでも誰でも参照できるように整理されていることは稀で、結局担当者に聞かないとわからない。これまでのシステムの歴史についてはDX の重要なステップとして、プロジェクトを立ち上げるなりして整理してほしい。
それではオブジェクトからツールを使って今ある姿を捉え、プロフェッショナルからの聞き取りや資料の整理で歴史をまとめられたとしよう。果たしてこれで十分だろうか。
実は、将来にわたってシステムを改修する上で最も重要な情報がまだ欠けている。それはプログラムのソースコードの改変履歴である。
プログラムの改修サイクルは、以下のような手順をだどる（図表5）。
●改修要望が発生する
●改修要望がシステム開発の担当部署に届く
●実装する要望かどうかを検討する
●担当者を割り当てて作業を開始する
●単体テスト、受け入れテストを実施する
●本番環境にリリースする
多くの企業では、改修要望などはきちんと起票されて関係者に回覧し、実装もしくは却下の結果を記録している。またプログラムの改修者は、テストケースの作成とテストログ、報告書などを作成している。最終的なリリースの日時も記録するケースが多い。
しかし、記録されていない情報がある。プログラムのソースコードの変更履歴である（図表6）。誰がいつ、ソースのどこを修正したのかという情報である。
せっかく改修要望が起票されて改修サイクルを管理していても、どこを修正したのかを記録していないので、それについては改修者に確認するしかない。改修者もどこをいつ変更したかなど、すべてを詳細に覚えているわけではない。
そして、もう1つ欠けている情報がある。プログラム改修者の作業ログである。改修に際してどのように準備し、どのぐらいの時間を要したか、何を疑問に思ったか、その疑問は誰に聞いてどのように解決したか、など。これは作業者が毎日の作業のなかで、日々の習慣として記録すべき情報である。そして、その記録は共有されねばならない。
今後は、過去のプログラム改修者の作業ログを記録する習慣が必要になる。とくに既存システムをどのように改修したかというメタ情報は、将来の担当者にとって重要な情報になる。作業ログは自分のためではなく、将来の担当者に向けた情報なのだ。
これらの情報がきちんと管理できる環境を構築することで、初めて次のステップに進んでいける。それがモダナイゼーションであり、DX への対応策となるはずだ。
既存システムを動かしながら
IBM iのモダナイゼーションに対応
IBM i でのモダナイゼーションは、以下の組み合わせを想像することが多いだろう。
●データベース処理は既存のRPG言語を用いる
●外部インターフェースをオープン系言語＋Web技術で開発する
データベース処理はRPG Ⅲでもできなくはないが、可能な限りFF RPGで実装することを推奨したい。外部との連携処理が必要な場合には、今後も機能拡張されるFF RPGを使うことが必須となってくる。
データベース処理部分と外部インターフェースおよびWeb系部分を疎結合で設計できれば、後者については外部の技術者が担当することも可能となる。IBM iで動かすからという理由だけで、IBM i 技術者が担当する必要はない。
モダナイゼーションは、半年から数年といったプロジェクトではなく、既存の基幹システムを動かし続けながら、データを参照・確認したり、新しいインターフェースを追加したりといった作業が多くなり、起案からリリースまでのサイクルが短くなる傾向にある。あまり悠長に構えてはいられない。
もちろん仕様はしっかり決めて、ドキュメントに残す必要があるが、それもプロトタイプを何度も回しながら、利用者とミーティングを繰り返して積み上げるアジャイル方式を採用せざるを得なくなる。
短いサイクルで、さまざまな記録やログを取る必要があるので、自動化できる部分は自動化し、手作業で記録すべき内容はなるべく手間をかけずに記録でき、その情報を全員が共有できるツールを用意しておきたい。
◎ IBM iの開発環境を見直そう
・IBM iとDX｜ IBM iはレガシーを継承しつつ、新しい技術基盤を併せもつ
・PDMとSEU ｜ IBM iの開発に欠かせない2つのツールがもつ強みと考慮点
・IBM iとモダナイゼーション｜ これからのIBM i開発に求められる機能とは（今回）
・これからの開発環境｜ ソースコード管理を起点に理想的な開発環境を考える（近日公開）
著者｜小川 誠氏
ティアンドトラスト株式会社
常務取締役
1989年、エス・イー・ラボ入社。その後、1993年にティアンドトラストに入社。システム/38 から IBM i まで、さまざまな開発プロジェクトに参加。またAS/400 、IBM i の機能拡張に伴い、他プラットフォームとの連携機能開発も手掛ける。IBM i 関連の多彩な教育コンテンツの作成や研修、セミナーなども担当。2021年6月から現職。
［i Magazine 2021 Summer（2021年7月）掲載］
