今なお多くの企業でメインフレームと呼ばれるシステムであったり、そこまで古くはなくとも20年近く動作している業務システムが存在します。そして多くの企業でリプレース案件が動いていたりします。
しかしシステムの全面的なリプレースにおいてうまくいったというケースは少ないのが現状です。何年も動かし続けたシステムはアンドキュメントな仕様が多数存在し、ワークフローの洗い出しとそれに合わせたシステム構築によって大規模な工数が必要になってしまいます。
先日富士通社よりWSMGR for Webという製品がリリースされました（富士通メインフレームをWeb API化できる端末接続ソフト - 製品＆サービス：ITpro Activeより）。これはゲートウェイソフトウェアで、REST APIを経由してメインフレームを操作できるようにするソフトウェアです。これはシステムのリプレースではありませんが、既存資産を活用して現在のビジネスに合わせて拡張していく一助になると考えられます。
APIの利点として、API提供元のシステムはブラックボックスにできる点が挙げられます。つまりRuby on RailsやDjangoといった最新のフレームワークで作られているか、メインフレームであるかは利用者からはうかがい知れないのです。RESTfulの原則に沿って提供さえされていれば、開発者は安心して利用できるでしょう。
さらにREST APIの多くがデータの公開に偏りがちですが、サービスの公開としての役割も担いやすくなります。元々メインフレームで利用されている機能（在庫引き当てや受発注など）をREST APIから呼び出せれば、実際のワークフローは気にせずにUIやそれ以外のワークフローに集中して開発できるようになります。機能の再実装コストを抑えられるでしょう。
メインフレームを置き換える目的は様々ですが、その一つに新しいシステム（グループウェアやECシステム）との連携が挙げられるかと思います。耐久年数や保守の問題などの場合は別ですが、システム連携であればWSMGR for Webのようにメインフレームをブラックボックス化してしまうのは一つの解決策であると言えます。
これは何もメインフレームだけに限りません。過去に開発した業務システムがオープン系でWebシステムに対応していない、古いフレームワークで開発されていて手を付けられない、運用フェーズに入っており、安定性が重要であるといったケースはよくあります。そうしたシステムにおいても別なシステムでラッピングしてしまうことでREST API化してしまう手が考えられます。何よりリプレースに比べると安価で、安全な移行と言えます。
一旦API化してしまえば、新しい施策も打ちやすくなるでしょう。業務システムの操作UIもスマートフォンやタブレットに対応したり、自動化も進めやすくなります。もちろんすでに稼働しているWebシステムとの連携も容易になります。
従来システム連携ではHTTPを使わないAPI連携であったり、CSVファイルを介した連携が行われてきました。基幹システムをREST API化できれば、より速いビジネススピードで業務改善や新しいビジネス創出が見込めるはずです。
