OSSによるダウンサイジング
- お問合せ
095-840-0021- LANCARD.COM
095-840-0021このページではよくいただくご質問とその回答をまとめています。ここに無い疑問などありましたら、お問合せフォームよりお気軽にご質問ください。
参考としてお客様のお問い合せからダウンサイジング完了までのシーケンスの例をあげます。
※「COBOL資産活用研究会」は長崎県のダウンサイジング経験がある業者などの本ダウンサイジング手法を実行できる業者で構成された団体です。
ダウンサイジングはその名のとおり小型化によって利益を生み出すことです。
コンピュータの話に限定しますと、汎用機と呼ばれる大型コンピュータで構築されたシステムをPC上で動作するUNIX系OSやWindowsなど、より小規模で安価な稼働環境へ移すことを言います。
汎用機で構築されたシステムはレガシーシステムとも呼ばれ、汎用機で動作しているソフトウェアを変換してLinux上で動かすという弊社が提案しているような方法はレガシーマイグレーションと呼ばれています。
レガシーシステムは運用実績や信頼性はあるのですが、リース料や保守料、ソフトウェアのライセンス料などが高額で維持費が高い傾向にあります。コンピュータの高性能化によりPCでシステム開発当時の汎用機と遜色ない性能を実現出来るようになったため、盛んにLinux等のOSS（オープンソースソフトウェア）のUNIX系OSへのダウンサイジングが行われています。
アップサイジングという言葉もあります
「クライアント単体で使用していたソフトをみんなで使いたい」
「ファイルを共有して使っていたらファイルが壊れてしまったり性能が悪かったりで使い物にならない」
そのような状況を解決するためにデータの置き場所をRDB（リレーショナルデータベース）に置き換えてクライアントサーバー構成にすることをアップサイジングと言います。
この言葉は狭い意味ではAccessやExcel等のMicrosoft社製品で構築されたスタンドアローンなシステムをMicrosoft社のRDBであるSQL Serverを使ってクライアントサーバー構築にすることを指すことが多いようです。
弊社もSQL Serverを使ったアップサイジングを行った経験があります。しかし、その場合、クライアントが増えるとサーバー側にもライセンス料が必要となるため、せっかくクライアントサーバー構成にしたのに、「クライアントを増やしたい」「でもお金が掛かり過ぎる」とお客様がお悩みになるという状況になってしまいました。
Accessベースの電子カルテシステムのアップサイジングのご相談を受けた際、そのような苦い経験もあり、弊社はLinuxサーバーとPostgreSQLというOSSによるアップサイジングをご提案いたしました。これは大成功。
電子カルテシステムは大幅な性能向上とスケーラビリィを獲得しました。お客様のご協力もあり、もう5年以上も安定稼働しています。
クライアント数も100台近くまで増え（実際の同時接続数はその1/3程度ですが）、随分大きなシステムになったものだと思います。
言葉の意味は逆なのですが、ダウンサイジングもアップサイジングも弊社の場合、結果的にOSSによるサーバーへの移行となっていることにお気づきになられたかもしれません。性能・安定性・コストパフォーマンスを考えると結局は同じところに落ち着いたのです。
汎用機、メインフレームと呼ばれる大型コンピューターで構築されたシステムはレガシーシステムと呼ばれています。レガシーシステムは稼働実績や信頼性はあるのですが維持費が大変高額であるという問題があります。維持費を削減するためにレガシーシステムから高性能化したUNIX系システム、Windowsシステムのプラットフォームにシステムを移植することをレガシーマイグレーションといいます。
長年稼働してきたレガシーシステムは利用者の業務に最適化されノウハウが詰まった資産となっています。この資産を活用できることは新たにシステムを構築しなおす場合にくらべて大きなメリットです。
弊社はレガシーマイグレーションによりLinuxというオープンなプラットフォームにまずはシステムを移すことにより、これまでの資産を活かしつつ拡張を行いやすくなることが大きなメリットだと考えています。
ソースコード（ソフトウェアの設計図にあたります）を公開しており、誰でも改良、再配布が行えるソフトウェアです。無料で使用できることが多く、それも特徴の一つです。
一般にはこちらの「無料で使えるソフトウェア」としての印象が強いかもしれません。
サーバーの分野ではOSSの利用が定着しており、本ソリューションで採用しているLinux等、OSSのUNIX系OSは低コストで安定性が高いプラットフォームとして定評があります。そしてLinux等のOS上で動作するソフトウェア、特にインターネットを支えるWebサーバー、メールサーバー、DNSサーバー等のほとんどはOSSが利用されていると言って過言ではりません。
OSSを知らなかったあなたも知らないうちにお世話になっていることでしょう。
インターネットを支えるサーバーソフトウェアが動作しているプラットフォームに移行するのですからWebやメールなどネットワーク技術との親和性が非常に高まります。現代のシステムでネットワークと無関係ということはまずありませんからこれは大きなメリットです。
特にWebとの連携に関しては、Webに特化し、よく使用されているPHPとOpenCOBOLの連携も実現しております（JCLの置き換えやマイグレーションアシストツールの主要開発言語として採用しているPerlでも十分なのですが）
PerlやPHPなどOSSの言語は利用者が多く、開発者の調達が容易です。そのため、地場の中小企業でも開発参入可能となり、結果としてシステムの寿命が延びます。
世界中の技術者の知恵が集約されているOSSの膨大で有用なリソースを利用できるようになるのも大きなメリットです。
一つ例をあげましょう。帳票の電子化を実現している仮想プリンタはPerl製です。ある日、お客様からバーコード印刷の要望をいただきました。OSSのライブラリのお陰で数時間後にはサンプルを動作させることができたのでした。
技術的には不可能ではないかもしれませんが、現実的ではないと考えております。
どこまで自動変換出来るようにするかで、コストパフォーマンスが決まります。既存ソースコードの分析、お客様の助言から判断し、あえて数%の自動変換を行わないことにより最高のコストパフォーマンス、最大のコストダウンを目指すのが本システムのキモなのです。
BPRでは収益や顧客満足度の向上のために業務内容や業務の流れ（ビジネス・プロセス）を見直します。その際、世界的な大企業が利用しているERP（統合業務パッケージ）を導入してそれに合わせる（つまり、うまく言っている企業のマネをする）形でビジネス・プロセスを変えるということも良く行われるようです。しかし、考えてみて下さい。あなたの組織・企業の強みはこれまで積み重ね、蓄えてきたノウハウにあるのではないでしょうか？
結局、歴史が浅いところではERP導入がうまくいっても歴史を積み重ねた組織・企業では上手くいかないことが多いようです。それではしょうがないと一からシステムを作り直すのであれば、結局のところ既存システムで動作していたビジネスロジックを再実装することになります。無駄ですよね。
そこで、弊社の提案はこうです。
まず、既存システムのリソースをなるべく自動変換することで、低コスト・短期間でクローズドな環境からオープンな環境に持って行ってしまいます。
オープンシステムではそれまであったシステム的な縛りが大幅に緩和されますから、ビジネス・プロセスの変更へ合わせてシステムの改修を行うことが容易になります。もちろんノウハウが詰まった計算ロジック等はそのまま活用できます！
業務ノウハウは持っているけれど頭が固いベテランさんが、その知識はそのままに思考の柔軟な若者に生まれ変わって業務の再構築に協力してくれるというわけです。
本ソリューションはCOBOLで稼働しているシステムをターゲットとしております。
COBOLが使用されていないシステムについては現在のところ対象外です。
COBOLとともに使用されているOSSに存在しないような特殊なプログラミング言語には対応致しますのでご相談ください。JCLには対応実績がございます。
もちろん、COBOL未使用のシステムについても新たなご提案は可能です。一緒に新たなソリューションを作りましょう！
事務所利用に開発されたプログラミング言語です。自然言語である英語に近い記述になるように設計されており、記述力は弱いですが、可読性は高いという特徴があります。
国際的な標準化が行われており、元来はプラットフォームへの依存性は低いのですが、主な稼働環境がクローズドな汎用機上であったこともあり各メーカーによる独自拡張が氾濫し、それが原因でプラットフォーム間の互換性は低下してしまいました。
汎用機上で動作する言語の中では圧倒的な利用率を誇り、誕生から半世紀たっているにもかかわらず現在でも現役で使用されています。
汎用機用のジョブ制御言語です。MVS系、VSE系、GCOS系などの系統はあるもののクローズドな環境で拡張が行われてきたため、メーカー間の差異が大きくなっており互換性はあまり期待できません。
Linux、Windows、Mac等のオープンシステム上で動作するOSSのCOBOLコンパイラです。ソースコードも公開されており、自由に使用できます。
OpenCOBOLはCOBOLプログラムを一旦C言語にトランスレート（変換）し、それをGCCというCコンパイラで処理することで実行ファイルを作成します。一旦C言語に変換されるため、OpenCOBOLコンパイラの動作を調べる際にはC言語のコードを見れば良いという利点があります。
現在、開発の中心は国外に移っていますが、実は日本生まれのソフトウェアで、日医標準レセプトソフトORCA（http://www.orca.med.or.jp/）で使用されており、安定稼働の実績も十分です。
OSSのプログラミング言語で、強力な文書処理能力、許容度の高い文法、柔軟な拡張性などの特徴があります。ソフトウェア技術者であれば知らない人はいないでしょう。
膨大なソフトウェア資産がCPAN（Comprehensive Perl Archive Network）という巨大なアーカイブに集約されており、開発者は望む機能を持つモジュールを容易に入手することができます。
必須なのはPerlです。マイグレーションアシストツールやJCLの置き換え、各システムを繋ぐ糊としてPerlは大活躍しています。COBOLやJCLなど既存システムで動作しているプログラミング言語も読めた方が良いです（一般にこれらは可読性に優れていますのでプログラミング経験者であれば比較的簡単に読めるようになります）
理想は業務を把握しているCOBOL技術者がOSS、特にLinuxとPerlを知っていることです。これらの教育についても対応いたしますのでご相談下さい。
加えて、OpenCOBOLはCOBOLをC言語へ一旦トランスレートするので、C言語も読めるとなお良し、といった感じです。
OSSのプログラミング言語はPerl以外にもいろいろとありますが、総合的に判断してPerlを採用いたしました。
マイグレーションアシストツールに必要な「強力な文書処理能力」はRubyやPythonも持っています。しかし、JCLを置き換えるには「許容度の高い文法」が必要であり、この点でPythonは不合格。「それならRubyでも良いのでは？」良いのですが、処理速度や蓄積されているソフトウェア資産を鑑みてPerlが最適であると判断いたしました。結果、正解であったと感じております。
言語自体の適正以外の判断条件として「技術者が多い言語」ということもありました。
弊社で全てを行うのであればRubyやPythonでも問題はないのですが、一般にはまだこれらの言語よりもPerlの技術者の方が多いでしょう。
ダウンサイジング後のシステムを真にオープンなものとするためには弊社だけでなく他社にとっても開発・運用がやりやすい環境である必要があると考えております。そのためには「技術者が多い言語」が望ましいという判断です。
日本国内なら飛行機で飛べばすぐですし、弊社には東京事務所もございます。
本ソリューションは初めから他社との恊働を想定しております。コア部分と教育を弊社が担当し、それ以外はお客様の社内SE、お近くの地場企業にお願いするといった方法も可能です（お勧めの方法です）
もちろんお受け致します！