概要
この記事は、汎用機からOpen系に移行するためのロードマップを検討し、一つの案を示す。
問題意識
汎用機をOpen系に移行するには、色々な問題がある。ここで検討したいのは技術的な問題ではなく、プロジェクトマネジメントの問題、特に開発規模の問題である。具体的には、開発規模が大きすぎて、開発が失敗しやすくなる問題である。
規模が大きいと開発が難しい
汎用機上でシステムの開発が始まった時、まだシステムは今よりも小さかったはずだ。年月が経つにつれ、追加で押し込んだ機能やら設計時の見込み違いやら、色々な事情が重なり、今の複雑化したシステムに至るはずだ。
このシステムを一度にOpen系で再現しようとすると、開発するシステムが大きすぎて、開発の難易度が跳ね上がってしまう。しかも、その新システムはいきなり全機能が稼働し始めるのである。これはかなり厳しい。
解決案
少しプロジェクトマネジメントを学んだ人なら、きっと頭に思い浮かぶことだが、リリースが大きすぎるなら分割するのが常套手段だ。この汎用機からOpen系に移行するプロジェクトも、リリースを分割しよう。
まず、大まかに以下の二段階に分ける。
① リライト
② リビルド
①が単なる書き換え、②が業務分析を含めてシステムをリファクタリングする工程である。
更に①を以下に分ける。
A. 帳票出力処理をJava + SVFで実装し、PDFで出力するようにする。
B. Springbootを使ったウェブアプリを作成し、照会画面などの参照系の画面を移行する。
C. 外部システムとの連携部分をOpen系に移行する。この移行により、外部連携部分が先行してOpen系になる。これはやりやすいケースとやりにくいケースがありそうなので、連携処理を調査して方針を決める。
D. バッチ処理をCOBOLからJavaに移行する。面倒な場合はOpenCOBOLをLinux上で動かすのはどうだろうか。できるかどうか分からないが。
E. 更新系の画面の移行。これは会計関連、販売関連など、ある程度のまとまりのある単位で少しづつ移行していく。
このリライトの利点と問題点
利点はリリースをかなり分割しているため、障害が起きにくくなるし、データ構造をそのまま残しているので、並行稼働もやりやすい。開発難易度を下げ、定期的にユーザーに新システムを提供する事ができる。これが一度にリリースするやり方だと、何年もユーザーにリリースを提供できない。
問題点は、そんなに綺麗にシステムを分割できるのかということである。
例えば何度も何度もリリースを繰り返すわけだが、そのたびに文字コード変換を行う箇所が移動していくのではないだろうか。一度に移行すれば作らなくて済んだ、汎用機とOpen系の境界面を吸収する処理を、何度も作ることになるのではないか。この煩雑さがある。
だが、自分の経験上、このぐらい丁寧にシステム開発を進めるのであれば、境界面を吸収する部分が余計だという話が出てきた時、どの程度一回分のリリース規模を大きめにするのか、何となく適切な規模が見つかるものだ。これ以上規模を大きくすると、開発難易度が上がって苦労するぞというレベル感は分かるので、「多少面倒でもこの辺で規模の拡大は止め、これ以上は次のリリースに回そう」という判断ができる。
問題は何も考えずに規模を拡大させることであり、規模を小さめに保つ意識があったうえで、いろんな事情でちょっとでかくなるのはありだと思う。
むしろ、そういう仕様追加だったり、あとからの要望ででかくなりすぎないように、最初の粒度を小さめにしておくということだ。
リビルド
こちらだが、これはOpen系への移行が一通り終わったと見なして入る領域である。逆に言うと、リライトのフェーズでちょっと改善したいという事があるだろうが、帳票や画面の見た目の検討など、リライトフェーズで小さな規模のリファクタリングは多分そこでやっていることだろう。そういう細かな修正ではなく、何か業務の流れそのものの改善や、複雑化している処理を整理し、データ構造そのものを見直すといったことである。
それを改めてやってみるという事である。
Open系への移行を通して、システムへの理解が深まり、問題点もわかってきているので、まぁ満を持して直すという事である。
まとめ
これでうまくいくのか、実は汎用機がよくわかっていないので、あまり自信はない。ただ自分としては、少しづつ移行し、一度に移行しないという方針で、ロードマップを描いてみたかった。
これで富士通の汎用機やIBMの汎用機から本当に移行できるのか、良くは分からない。
多分、そのシステムの複雑さにもよるかも知れない。簡単なシステムなら、当然難易度は下がる。だが、そもそも複雑なシステムを一度に移行させるのは無理だ。その場合には、リリース分割が一つの手段になる。これはその、リリース分割の案である。
一つづつ置き換えていけば、並行稼働もやりやすい。並行稼働は一ヶ月ぐらいやりたい。その検証をやりながら、次のリリース分を開発するとよいだろう。オペレーターも分割リリースを通して、少しづつ、新システムに慣れていくことになる。
小リリースが終わるたびに、仕様書や、ユーザー要望をまとめたドキュメントを作成し、いわゆる暗黙知を表に出していくようにしたい。
RabbitMQなどもいるかもしれない。Open系と言いつつ、どの技術を選定するかの話もある。
この方式は、並行稼働時に汎用機と新システムに処理を振り分ける、ファサードとなるプログラムもいるかもしれないし、いわゆる「移行が終わったら要らない」プログラムをそれなりに作ってしまう恐れがある。しかし、この辺は工夫次第だし、「別にいいよ、作るよ」もありだ。開発上の工夫で乗り切れるはずだ。
一番避けるべきことは、汎用機と新システムの段差が大きすぎて、いつまでも飛び越えられないまま、開発そのものが失敗して、中止の憂き目に遭うことだ。これを避けることに比べれば、分割リリースに伴う困難なぞ、全然乗り越えられると思う。