IBM i（AS/400）を使い続ける？モダナイズ？決め手は見える化！

時代を超えて進化し続けるIBM i（AS/400）は、1979年ロチェスター研究所で生まれたSystem/38が原点であり、1988年にAS/400として舞台に登場しました。その後、「AS/400」「eServer i Series」「System i」「Power Systems」という名前を変えつつ、ビジネスマシンとして進化を遂げてきました。 現在ではIBM iとなり、多くの企業で利用されていますが、AS400という愛称は今でも根強く残り、ユーザーによって呼ばれ続けています。

AS400は発売当初から今日まで、開発されたソフトウェアが継承され使い続けることが可能な最大の特長があります。しかし、このAS400最大の特長が逆に課題となり、後継者不足という難題を引き起こしています。AS400の持つ技術的な特異性が、一方では多くの利点をもたらしていますが、同時に技術者の供給不足という課題を生み出しています。AS400を使い続けるにしても、将来的にモダナイズを検討するにしても、後継者不足は早急に対応する必要があります。

AS400の後継者不足が進む根本的な理由は、一度アプリケーションを開発すれば、AS400のリプレイスやOSをバージョンアップしても、アプリケーションをそのまま使い続けることが可能だからです。業務が大幅に変化しない限り、業務システムを再構築する必要がなく、上流工程担当のSEや新規開発時ほど多くのPGが必要ないからです。さらに、プログラム言語の「RPG」がAS400独自のものであり、IBM iまたはOS/400のシステム上でのみ動作するという事実も、AS400の後継者不足の要因となっています。 開発されたソフトウェアが継承され長期間使い続けることが可能なことによる、AS400の後継者不足が引き起こす問題の一つが、システムのブラックボックス化です。

AS400ユーザーの中には、20年以上AS400を使い続けているユーザーが結構いらっしゃいます。 システムは長年にわたり機能の追加や改修を繰り返し、その結果として肥大化・複雑化しています。さらに、システム設計書やその他のドキュメントが最新でないか、または存在しない可能性もあります。それでも、担当していたAS400技術者が在籍している間は、属人化の問題は発生するかもしれませんが、その知見により運用・維持作業は可能でしょう。
しかし、AS400技術者のスキル転換や高齢化により、AS400技術者不足が世界的な傾向となっています。 システムを担当していた技術者が定年を迎え体制が維持できない後継者問題や、システム開発を外注していた開発会社がなくなった場合など、この課題に対処するためには新たな戦略やスキルの導入が必要です。稼働中のAS400システムを理解している技術者が不在になれば、一気にブラックボックス化が進む可能性があります。

AS400システムのブラックボックス化がもたらす運用・維持作業への影響と、システム再構築時の根拠のない概算見積もりと実際の工数の乖離について整理してみました。この問題がもたらす具体的な影響や対策について検討することで、AS400システムの持つ課題に対する理解が深まり、新たな戦略が見えてくるかもしれません。

現行のAS400システムの運用・維持作業を「迅速」かつ「正確」に実施するためには、ブラックボックス化の解消が不可欠です。ブラックボックス化がもたらすシステム運用・維持時の問題点を以下に纏めます。

システムを理解していない作業者が問題にアプローチすることで、効率的で的確な作業が難しくなります。作業者がシステムの機能や構造を把握しやすくすることで、問題の特定やバグの修正を円滑に進められる。

修正やアップデートを行う際に、他のシステムへの影響確認が難しい点も深刻な問題となっています。異なるシステム同士が連携し、一方の変更が他方に与える影響を正確に把握することが困難であると、全体の安定性や信頼性に関わります。この課題の解決には、システム全体を俯瞰できるツールやプロセスの導入を行うことで解消します。

全ての条件や適切なテストケースを作成することが難しく、これがシステムの品質管理に対する大きな課題となっています。テストの充実性が不足していると、潜在的な問題が見逃され、品質の低下や予測不能な動作が発生する可能性が高まります。

変更内容によっては小規模な改修でも、システム内部の詳細を理解し、適切な変更を行う必要があります。しかし、この詳細理解には膨大な調査工数が必要であるか、または詳細理解が難しい場合があります。特に、システム内部の詳細理解に関する工数が大きな負担となっている場合、自動化ツールや診断ツールの活用も解決策の一つです。これにより、システムの構造やコードの解析が迅速かつ正確に行え、変更の影響範囲やリスクを把握しやすくなります。

AS400システム再構築を行う際も運用・維持作業と同様に、ブラックボックス化の解消が不可欠です。しかし、ブラックボックス化の解消ができなかったために、システム再構築に踏み切ることができなかったり、プロジェクトが途中で頓挫してしまった事例を解説します。

ユーザーがSIerにシステム再構築の見積もりを依頼した際、見積もりの作成に必要な調査費用が、予想していた費用や期間と大きく乖離していたため、結局見積もり依頼を断念した。

ユーザーがSIerにプログラム本数、ステップ数、およびディスク使用量を提示し、システム再構築の概算見積もりを依頼しました。しかし、ドキュメントがなく、ユーザー自体も詳細を理解していない複雑なシステムに対し、SIerは各工程でリスクを考慮して概算見積もりを作成した結果、後に判明した必要な費用の約4倍に膨れ上がり、結局プロジェクトは見送られました。この事例は、要件やシステムの理解が不十分なまま見積もりを行ったことが、プロジェクトに深刻な影響を及ぼした例です。

SIerはユーザーから提供されたシステム資産資料を基に概算見積もりを作成し、その規模に基づいてプロジェクトを受注しました。しかし、提示されたシステム資産資料と実際のシステム資産との間に乖離があり、これが大幅な費用追加と開発期間の延長を引き起こし、結果的にプロジェクトは頓挫しました。この事例は、見積もりの段階での情報の不整合がプロジェクトに与える影響を浮き彫りにしています。

過去のシステム再構築の見積もり及びプロジェクトの断念と、プロジェクトが途中で頓挫した事例は、AS400システムの解析を怠り、ブラックボックスのまま「どんぶり勘定」の概算見積もり工数でシステム再構築を試みたことが原因でした。AS400を長年にわたり使い続けている場合、世代ごとのソースコードが混在し、肥大化・複雑化した状態で稼働していることが一般的です。 ソースコードから不要な資産や不良な資産を取り除いた後に、AS400システムの解析が必要です。ソースコードだけでなく、アプリケーションに関連する他のオブジェクトについても、網羅的な解析が必要です。これにより、正確な見積もりと計画を策定することが可能となります。

長年使い続けるAS400システムは、ますます肥大化・複雑化し、ドキュメント類は放置されているか存在しない状態になっています。元担当のAS400技術者はスキル転換や高齢化により後継者不在となり、ブラックボックス化が進んでいます。このように深刻な問題に直面しているAS400ユーザーは少ないかもしれませんが、AS400技術者不足とブラックボックス化が進行するAS400システムでは、解決すべき重要な課題となっています。

システムがブラックボックスのままでは、あらゆる側面で制約されることになります。逆に、システムの見える化により、AS400技術者以外でも対応可能となり、属人化の解消や技術者不足や後継者不足への対処が可能です。ただし、システムの解析作業は人手では難しく、断念せざるを得ないケースもあります。運用・維持作業においては、迅速性と正確性を考慮して、最新の解析情報を即座に利用できる環境整備のために、解析ツールの導入が有益です。

また、「AS400システム資産の棚卸」結果を基にシステム再構築の手法を判断することも重要です。 プロジェクト開始後も詳細な調査を実施することが、プロジェクト成功の鍵となります。この「AS400システム資産の棚卸」では、以下の9つの視点が特に重要です。
①資産規模
②プログラムソース仕分け
③機能構成
④プログラム間及び他オブジェクトの関係性
⑤ファイルの関係性
⑥資産品質
⑦プログラムの複雑性
⑧CLコマンド使用傾向分析
⑨冗長・不使用リソース
これらの解析結果により、「どんぶり勘定」ではなく、根拠のある見積もりが可能となります。　 以下のポイントが特に注目されます。
●要件定義の見積もりが可能
システム資産の棚卸に基づいて、要件定義に必要な工数やリソースの見積もりが適切に行えます。
●後工程全体の概算見積に必要な情報が提供可能
不要・不良資産、冗長化、アプリケーションの複雑度・難易度などを含む情報が揃っているため後工程全体の概算見積もりが正確に行えます。これによりプロジェクトの見積もり段階から正確な情報を把握することができ、計画の立案やリソースの適切な配分が可能となります。

最後に、複数のAS400を利用するユーザーがシステム再構築を検討し、プロジェクトで発生した課題と、それに対する解決策として導入されたツールの、活用範囲と活用方法を含むモダナイズの事例を紹介いたします。この実例は、複雑な環境においてシステム解析における課題への対処法や、新しいツールの導入がどのようにプロジェクトの成功に寄与したか纏めています。
システム解析における課題は、AS400の複雑性と複数台の連携が挙げられ、これがプロジェクト進行を著しく妨げていました。課題解決のために導入されたツールは、システム全体の解析や相互の依存関係を明確に「見える化」できるものでした。これにより、複数のAS400間でのデータのやり取りやプロセスの流れを容易に理解することができ、解析作業の効率が飛躍的に向上しました。ツールの具体的な活用範囲としては、各AS400のソースコード解析からデータベースの依存関係まで網羅的な解析が可能となりました。
また、ツールの使い方に関しては、専門的な知識がないスタッフでも直感的に操作できるように設計され、全体の作業フローをスムーズに進めることができました。このような効果的なモダナイズが、プロジェクトのスケジュールの遵守と予算のコントロールに大いに寄与し、同時にAS400システムの見える化が将来的な運用や保守作業にもプラスの影響を与えました。

業種：流通卸会社
規模：約16,000本（CLP、RPG）
検討内容：現時点、IBM iを使い続けながらオープン系への移行を計画中

①各拠点に設置された複数台のIBM iに分散され冗長化したシステムの、アプリケーション資産が把握できない。
②サーバー統合およびアプリケーションの最適化を実施し、IBM iを1台に集約したい。
③上記②の集約・スリム化を実施したリソースに対し、段階的モダナイゼーションの実施。

課題解決には次の把握が必要となりますが、「システムの分析・可視化」により得ることが可能となります。
●稼働・非稼動リソースの把握
●冗長リソースの把握
●類似リソースの把握
しかし手作業でこれらの可視化を行った場合、膨大な工数が必要となり、均一ではない可視化データが出来上がる等の問題点が発生します。

次の工数やスキルが必要となります。
●ソースやオブジェクト間の関連性分析には、手間暇が掛かる（又は人手では不可能）。
●RPG、COBOL、CLPといったリソースを、均一に読み下す高いスキルが必要。
●読み下しのリソースが多ければ、膨大な工数が必要。
これでは、開発工程と変わらない作業内容となってしまいます。工数削減と均一化されたデータ作りには「システムの可視化」に特化したツールに頼る他は無いと考えます。それもIBM iに特化したツール利用がベストと考えます。

活用範囲：課題①②における調査工程
活用方法：
●稼働・非稼動リソースの把握
ツールのオブジェクト情報参照機能を用いて最終稼動日時情報を抽出し、閾値を決めて非稼動判断を行い整理する。
●冗長リソースの把握
ツールのリポジトリ比較機能を用いて、各拠点の相違・同一のオブジェクトを把握し、同一のものを対象として整理する。
●類似リソースの把握
ツールのソフトウエアメトリクス機能を用いて、アプリケーションソースコードの類似について評価された数値に基づき、類似分析を実施して最適化を図る。

本事例のAS400集約は、サーバー統合ではなくシステム統合であり、スリム化して段階的モダナイゼーションに備えることにあります。システム統合するには現行システムの把握が必須となり、元は同じシステムを拠点毎にカスタマイズを施し展開しているので、冗長リソース把握がプロジェクトの鍵となります。本事例の様に大規模システムの課題解決を、全て人手で行う場合その多くは不可能であるか、あまりにも工数が膨大で断念せざるを得ないことがよくあります。さらに、均一な調査結果を得ることが難しく、一貫性のない結果が発生することもあります。こうした問題に立ち向かうために、AS400システムの分析・可視化ツールを導入することが効果的です。このツールを使用することでリソースの読み込みは均一となり、分析にかかる工数は実質ゼロとなります。 その結果、調査作業が高品質で高効率に進み、調査工程における大幅なコスト削減が実現できます。