#06 - プログラム資産の一元管理を実現
メインフレーム全盛時代、銀行などのシステムでは本番業務をサポートするシステムと開発系を担うシステムは明確に分離され運用されていました。しかし、多くの製造業や流通業などでは高価なコンピュータへの投資を可能な限り抑えた運用を実現するため、本番環境と開発環境を同じコンピュータの中で共存される方法を利用していることが多々ありました。そんな環境の中で、複数のお客様を担当するようになっていた私は、開発されたプログラムを資産として効率的に管理する方法ができないかと常に考えていました。その時に解決のために考えたことや仕組みの概要について綴ってみます。
感じていた疑問
現在システムとしては正常に稼働しながら、改善のために開発や修正が実施されている状態が日常でした。そんな時、ふと思ったのは、今現在、本番で稼働しているプログラムはどのくらいあって、開発や修正中のプログラムはどのくらいあるのだろう。即座にわかる方法とかあるのかな。また、本番で稼働しているプログラムの内、修正のために開発環境にも存在するプログラムはどのくらいあるのだろう。
大切なプログラムはきちんと資産管理ができているのだろうかという疑問が出て、現状のプロセスを確認してみました。
プロセスの現状と課題
システムを開発をしている間は、開発環境の中のみでプログラムを作成し管理していました。そして、サービスインを迎える際に開発環境の中のプログラムを本番環境に移して運用管理されます。ごく当たり前の管理形態ですが、ともすれば、開発環境から本番環境に移行する際はCOPYしてしまうこともしばしば発生し、その時点で最新のソースはどちらかということが問題になることも時折発生していました。
どうしても、すぐに修正が発生するかも知れないと考えてしまうと、本番環境は簡単にアクセスできないので、開発環境に残しておいて迅速に対応できる環境を各SEが効率化のために実施していたように思います。ただし、このような運用は、担当の変更や機能追加の仕事が発生した場合に対象となるソースを取り違えてしまうリスクを持っていました。
結局は、効率化だと錯覚したプロセスを長年運用し続けていたのかもしれません。もし、間違いが発生すれば元に戻すためには何倍もの工数が必要になったわけですから。
解決するための案
なんとかして、開発と本番のアクセス権を考慮しながらシームレスに利用できる仕組みができないかと考え始めました。あるお客様で仕事を担当していた時代は、ライブラリアンというソース管理のパッケージソフトが導入されていたため、チェックイン・チェックアウト機能により一元管理されていましたが、高価なパッケージソフトを利用せずに簡易的なチェックイン・チェックアウト機能の様なことを実現し加えて最新のソースの存在場所や資産として管理するためのステップ数やデータベースアクセスの種類なども管理できるようになれば一元管理ができるのではないだろうかと考えました。保守段階になると、データベースを更新しているプログラムの特定化をしなければならないことはよくあります。そのような情報も瞬時に検索できれば保守においても有用な仕組みになるに違いないと考えました。
プログラムを修正しなければならなくなっても、簡易的なチェックアウト機能を実現し、本番環境から開発環境にCopyすることができれば、最新ソースは開発環境にあり修正中であるということが管理できるようになります。また、プログラム内のデータベース・アクセス部分も情報管理できれば、プログラムの構成管理に加えて、どのプログラムからどのデータベースのテーブルに対してどんな処理(検索、更新、挿入、削除)を実施しているかも把握でき保守の効率を大きく改善できるのではと考えました。
実現方法と効果
問題は実現方法でした。仕組みを作るにしてもその仕組み自体を保守しなければならないので、容易に修正できる構成にしなければなりませんでした。そこで、考えたのは、当時はCOBOLを管理できれば全体の80%以上のプログラムを管理できる環境に有ったことから、プログラムは必ずコンパイルするというプロセスに目をつけました。合わせて、ツールとして作成するプログラムもCOBOLで実現する計画にしました。
プログラムをコンパイルするためのコマンドを開発用と本番用の2種類作成するとともに、開発と本番間のソースのMove/Copyのコマンドも準備することを考えました。開発から本番の環境に移すときは、プログラムはMoveモードで移して開発環境からは削除します。逆に本番環境から修正するために開発環境に持ってくる時にはCopyモードで処理するようにします。
コンパイルコマンドの中では、コンパイルが正常に終了した場合は、ソースをスキャンしてステップ数やプログラム構成、利用しているSQLの情報などを取得してデータベースのテーブルに格納するようなプログラムを作成しました。同時に起動された回数もカウントできるようにして失敗回数が把握できるようにしました。
これらにより、コンパイルの失敗回数、成功回数も同時に取得することができ、コンパイルする回数が多く、なかなかコンパイルが完了できなくて困っている担当者を見つけ出し、サポートすることができるという派生効果まで実現できました。さらに、情報収集したデータベースのテーブルの中をSQL検索することで、本番で稼働しているプログラム総ステップ数や開発環境で作成または改善しているプログラム総ステップ数も瞬時に取得できるようになりました。もちろん、誤って最新ではないソースを修正するという人的ミスも防止できるようになったわけです。
保守段階での有効利用
保守段階での作業では、利用しているサブルーチンを使っているメインルーチンの一覧取得や任意のデータベースのテーブルに対し、更新を実施しているプログラム一覧なども即座に確認できる環境が出来上がり、この仕組みは多くのお客様のシステムで利用していただきました。
お客様担当SEとして、複数箇所を訪問した際に、お客様の資産状況について非常に短時間で把握できるようにもなりました。また、お客様においては外部のSEさんにお願いして開発してもらっているプログラムが、この管理テーブルを確認することで適正サイズを維持できているかという確認もできるようになり、大変満足していただきました。
最後に
今回は、コンパイルが必ず必要なプロセスであるということに目をつけた改善策でした。この視点から、ソースそのものをスキャンして情報をデータベース化するという発想に繋がったわけです。製造業で言えば、プログラム構成を部品表のようなデータベースとして構築し運用することができるようになったわけです。
一つ一つは、当時で言えばごく普通のことですが、作成中や作成したプログラムという情報を連携させて情報として蓄積し活用するというのが、目新しかったと思います。例えば、プログラム同志の構成図を作成するなど単独の機能として使えるものはありましたが、開発途中の状況管理だったり、本番で稼働しているプログラムの修正状況管理などの機能と一元管理されるような仕組みは私が知る限り見たことはありません。しかし、プログラムを大切な資産として考えれば必要なことではないでしょうか?
日頃当たり前だと思っていることでも、もっと便利になるんじゃないかということを考えると改善点の糸口が見えてくるものです。目の前のプロセスが完全であると思わず、もっと楽になる方法があるんじゃないかと考えることにより、効率化や品質改善が実現できていくと思っていますし、考え方自体は現在の環境でも応用の余地があるのではないかと思っています。
他のSE経験記事は以下のマガジンに入っています。よければ覗いてみてください。
いいなと思ったら応援しよう！
