共同印刷株式会社

ビジネスフォームやデータプリントサービスの製造は、同社ビジネスメディア事業部のシステム推進部が顧客との打ち合わせで帳票の仕様を詰め、顧客から物理媒体でデータを受け取るところから始まります。その都度データを受け取るのはセキュリティを考慮してのこと。同部システム開発課が設計仕様に基づいてプログラムを開発、データを取り込みながらバッチ処理で帳票を業務用大型高速プリンターで出力していきます。

事業をスタートした当時、顧客からのデータはメインフレームから出力されたもので、同社のコンピュータもメインフレームでした。メインフレームのメーカーや文字コードが異なっていても、ベースとなる言語はCOBOLであり、媒体にも一定の規格が存在、ファイルの形式も似通っていたため、やりとりに大きな問題はありませんでした。

しかし、ダウンサイジングの波とともに、顧客からWindows、LinuxやUNIX OSベースのデータが提供されるようになります。CSV形式のファイル、UNICODEを使って記述されたものなどは、メインフレームにそのまま投入できません。当初、システム推進部では取得したファイルに変換処理を施してからメインフレームに取り込み、出力業務を一本化していました。しかし、システム推進部での前処理業務の負荷はどんどん高くなっていきました。

このような入力時の課題に加え、出力時にも課題が生じていました。それはPDF文書の普及によるPDF出力ニーズです。従来、出力はメインフレーム対応大型高速プリンターが主流だったのですが、PDF文書として出力するならオープンシステムの方が適しています。

そこでシステム推進部では、オープンシステムのデータに関しては、オープンシステムで入出力業務を行うことを考えます。この構想のさらなる推力となったのが、東日本大震災でした。この震災をきっかけとしてBCP（事業継続計画）の強化気運が高まります。バックアップシステムを持つなら、オープンシステムの方が少ない投資で体制を整備することが可能でした。

それでは、その出力処理の開発基盤をどう構成するか。システム推進部における主要開発言語はCOBOLだったので、COBOLであることは前提でした。挙がった候補は二つ。一つはメインフレームメーカーの提供するUNIXベースのCOBOL製品で、もう一つはWindowsベースのMicro Focus Visual COBOLです。

システム推進部は、検討の結果、後者を選択します。同部 システム開発課 課長 小川喜之氏は、次のように語ります。

「メインフレームメーカーの提案は、UNIXベースの自社ツール群で固められており柔軟性に欠けると感じました。われわれがオープンシステムで馴染んでいたのがWindows環境で、Micro FocusのCOBOL製品はここでも豊富な導入実績を持っていました。Windows環境の方が、顧客の求めに応じて何か新しいソリューションを導入しなければならないという場合でも選択肢が多く、拡張性が確保できるという利点もありました」

また、高く評価されたのは、最新のCOBOL統合開発環境である Micro Focus Visual COBOLによって.NET Framework 及びその上で数多くのISVが提供している豊富なクラスライブラリ資産を活用した開発が可能なことでした。小川氏は次のように続けます。

「オープンシステムでメインフレームと同じことができるというのはもちろん重要でしたが、何かプラスアルファがないか、と思っていた時にマイクロフォーカスのWebサイトで .NET Frameworkの活用をテーマとしたホワイトペーパーを発見、読んで『これだ』と思いました。いくつかの案件でVB.NET開発を経験して便利なメソッドが豊富にあることを知っており、これをCOBOLプログラムで活用して“いいとこどり”すれば開発生産性を上げられると考えたのです」