時代遅れという認識を払拭し、最新環境の第一線でもCOBOLを活用可能にする

富士通(株)
ソフトウェア事業本部
ミドルウェアソリューション事業部
第3開発部
松竹 伸博/ 高橋 義雄
2001/04/04


―― COBOL言語でGUIを設計することができるのですか?

松竹:PowerCOBOL97では、Visual Basic(VB)のような感覚で、フォームに部品を貼り付けながら、COBOLベースでGUIを設計できるGUIビルダを用意しました。これを利用すれば、ビジネス・ロジックからユーザー・インターフェイスまで、すべてをCOBOL言語で開発できます。また、PowerCOBOL97では、VBでユーザー・インターフェイスを設計し、ここからCOBOLプログラムを呼び出すことも可能です。これにより、コアとなるビジネス・ロジック部分はCOBOL言語で開発し、フロントエンドとなるユーザー・インターフェイスはVBで設計するというスタイルが可能になります。

 VBとCOBOLを組み合わせるか、COBOLだけで実現するか、どちらを採用するかはユーザー次第です。

PowerCOBOL97のGUIビルダ
PowerCOBOL97には、GUIビルダと呼ばれるGUI構築ツールが用意されている。これを利用すれば、フォームに部品を貼り付けることで、COBOLベースでもVBライクにGUIを設計することができる。

―― 今回御社は、COBOL製品でMicrosoft.NETプラットフォームをサポートすると発表されました。この背景についてお教えください。

松竹:Microsoft.NET(以下.NET)プラットフォームをサポートする最大の理由は、.NETが標榜するようなネットワーク分散環境が今後は主流になっていくだろうと考えたからです。そしてプログラマの方々が、.NET対応プログラムを開発しようと思ったときに、タイムリーに弊社の開発環境を利用できるようにすることが、言語ベンダとしての責任だと考えました。前に述べたように、これまでもGUI設計ツールの導入など、言語処理系の進化を独自に図ってきたのですが、これはあくまで独自のもので、マイクロソフトの開発環境などと歩調を合わせていたわけではありません。当然ながら、マイクロソフトの開発環境は、その時代時代の最新の技術トレンドを反映しているわけですが、これに比べると、どうしてもCOBOL言語処理系の進化は一歩遅れた感が否めませんでした。新しい技術トレンドに追随できないというイメージが、「COBOLは古くさい言語だ」という認識に通じているのではないかと思います。

 今回の.NETサポートについては、米Microsoft社からも協調しないかという打診があり、今述べたような思いもあって、いち早く対応することを決定したのです。

―― .NET対応COBOLが登場することで、COBOL言語だけで.NET対応ソリューションを開発できるようになるわけですね。

松竹:そうです。しかし無理にCOBOLだけを使う必要はありません。COBOLの苦手な処理でも、他の言語を使えばより効率的に処理できる部分があるなら、適材適所で他の言語を使えばよいのです。例えば、Javaが適した処理にはJavaを使い、COBOLに適した処理にはCOBOLを使って、それらを組み合わせることができます。特に.NET環境では、異なる言語間でクラスを継承できるなど、マルチランゲージ・サポートが強化されています。より自然な形で、異なる言語で作成されたプログラム同士の連携が可能になるでしょう。

 また現実の商談では、将来を考えて、古いCOBOL言語ではなく、Javaなどの新しい言語を使って開発してほしいというお客様も少なくありません。今まで申し上げてきたように、本当は誤解なのですが、これが現実なのです。このような場面でも、さまざまな言語を組み合わせて利用できる.NET環境なら、柔軟な提案をすることができます。もちろん最終的には、COBOLに対するこのような誤解を解いていきたいとも思います。

.NET環境では、より自然な形で、異なる言語で作成されたプログラム同士の連携が可能になるでしょう(松竹)

―― .NET対応COBOLを利用すれば、COBOLで開発された既存のソフトウェア資産を最新の.NET環境に移行させることが容易になるものと思われます。またCOBOLに親しんだプログラマが、新しい.NET環境に移行しやすくなるでしょう。しかしベースとなる環境が大きく変わるわけですから、その影響がプログラムにまったく及ばないとは考えられません。従来のCOBOL環境と、新しい.NET対応COBOL環境の互換性はどの程度維持されているのでしょうか?

高橋:まずCOBOL言語には、ANSIという世界標準規格があるわけですから、どのようなCOBOLにせよ、これに準拠することは大前提となります。.NET対応だからといって、.NET用の方言をどんどん追加してよいということにはなりません。まずはこのレベルでの互換性を完全に維持するのは必要条件です。

 ANSI規格に準拠したうえで、.NETに対応するための必要な拡張を加えます。しかしその際でも、過去との互換性を維持することに最大限配慮します。これまでも弊社では、Windows環境とSolaris環境向けのCOBOL言語処理系を開発・販売してきました。その経験から言って、プログラマの方々が最も強く求めるのは、過去との互換性、あるいは異なる環境向け製品間での互換性です。これまでもそうであったように、.NET対応においても、最も重視するのはこの「互換性」です。.NETを特別視するのではなく、あくまでCOBOL製品の対応環境を拡張するという一環として、従来どおりの開発姿勢で臨むつもりです。

これまで同様、.NET対応においても、最も重視するのは「互換性」です(高橋)

―― たとえば、従来のVisual Basic 6からVisual Basic.NETへの移行では、言語仕様が完全なオブジェクト指向対応になり、この結果として、従来のソフトウェア資産を移行するのは容易ではなくなっています。同じようなことは、.NET対応COBOLについても言えるのでしょうか?

高橋:前述したとおり、PowerCOBOL97では、すでにオブジェクト指向の機能を取り入れていますから、この点から言えば、VB6→VB.NETのようなオブジェクト指向対応を理由とするインパクトはほとんどありません。言語仕様という観点からはこう言えるのですが、問題は、多くのプログラマがすでにオブジェクト指向に沿ったプログラミングを行っているかどうかということです。

 たとえば前述したGUIビルダでは、さまざまな部品(コントロール)をオブジェクトとして実装しています。ですから本来、COBOLプログラムからこれらの部品を操作するときには、プロパティを変更して見映えを変えるとか、コントロールが提供するメソッドを実行するなど、オブジェクト指向の流儀にのっとってプログラミングする必要があります。しかし現実には、そのようなオブジェクト指向の流儀はなるべく隠蔽してほしいという要求があり、GUIビルダの製品化にあたっては、これらを従来の流儀で操作できるようにマッピングしました。たとえば具体的には、プロパティの変更をMOVE命令で実行できるようにしたのです。これによりプログラマは、オブジェクト指向を意識することなく、GUIビルダを操作できるようになっています。

 最近では、オブジェクトのメソッドへのアクセスを露出させるなど、オブジェクト指向を少しずつ意識してもらうような実装に変わりつつあります。しかし現時点では、こうした新しいプログラミング・パラダイムを習得するより、従来からの知識でプログラミングしたいという需要のほうが圧倒的に多いですね。

―― ということは、実質的には、VB6→VB.NET同様の問題が.NET対応COBOLにもあるということになりますか?

高橋:オブジェクト指向技術を使用せず、今までと同じ方法で.NETアプリケーションを作成可能とする予定です。ただし当社のCOBOLがサポートしていない.NETの機能を利用する場合には、オブジェクト指向技術が必要となります。

 しかし逆に、オブジェクト指向のハードルを越えれば、他のC#やVisual C++.NET、VB.NETとまったく同じレベルで.NETのクラスライブラリを使用して、.NETのネイティブ・アプリケーションを開発することが可能です。COBOLの知識があるプログラマは、改めてC#の勉強をしなくても、最新の.NET対応アプリケーションが開発できるということです。

オブジェクト指向のハードルを越えれば、COBOLで.NETのネイティブ・アプリケーションを開発することが可能です(高橋)

―― .NET対応COBOLの開発環境はどのようなものになるのでしょうか? 御社は従来から独自に開発環境を提供されていますが、複数の言語を組み合わせて使用できるという.NETのメリットを活かすには、.NET対応COBOLの開発環境もVisual Studio.NETに統合されるべきだと思いますが。

高橋:ご指摘のとおり、現時点では、マイクロソフトの統合開発環境であるVisual Studio.NET(以下VS.NET)に弊社のCOBOL開発環境も統合する方向で作業を進めています。したがってコーディングからコンパイル、デバッグまで、C#やVC++.NETなどとまったく同様にして、VS.NETの機能を使用してプログラム開発を行うことが可能です。

 ただし、従来から提供してきた弊社独自の開発環境にも対応させるべきかどうかも併せて検討しています。まだ最終的な決断はしていませんが、既存のお客様のなかには、これまでの環境に馴れている方も多いはずですから。

―― .NET対応COBOLの製品化スケジュールについてお教えください。

松竹:残念ながら、製品化のスケジュールについては、まだ発表できる段階ではありません。しかし最初にも述べたとおり、新しい環境にタイムリーに対応したいというのが今回の大きな目的の1つですから、.NETシステムの出荷と同時期に出荷するというのが目標です。

―― 今回の.NET対応COBOL以外で、御社で.NET対応を進めているものはあるのでしょうか?

松竹:弊社は2001年1月29日に、アプリケーション・サーバ連携などを可能にするソフトウェア・プラットフォームの「INTERSTAGE(インターステージ)」をXMLSOAP対応にし、.NETプラットフォームとの連携を可能にすると発表しました(ニュースリリース)。また、Fortranも.NET対応にしようという計画もあります。弊社のFortran処理系の浮動小数点演算性能が非常に高いという評価をいただいており、新しいプラットフォームである.NETへの適用を検討しております。

Fortranも.NET対応にしようという計画もあります(松竹)

―― 最後に、今回の.NET対応COBOLによって、新たな展開として期待していることがあればお話しください。

松竹:現在のPowerCOBOL97でも、さまざまな機能強化を行っていますが、例えばWebソリューションにCOBOLを使おうとしたときに、Javaと同じようにできるかといえば、そうではありません。Javaはインターネット環境を前提として開発された言語ですから、その出発点からして、Webソリューションに適した数々の特徴を持っているからです。

 これに対し.NET対応COBOLでは、C#などの他の言語処理系とまったく同様に、.NETの機能をすべて活用してアプリケーションを開発できるようになります。複数の言語を適材適所で活用するというのも有効ですが、その一方では、最新の機能をすべてCOBOLで制御できるということも大きなメリットではないかと考えています。繰り返しになりますが、COBOLは古くさい言語だという認識が定着してしまっています。これに対し、今回の.NET対応COBOLが登場することでこうしたイメージが払拭され、COBOLは最新環境の最前線でも活用可能な言語処理系なのだと改めて認識してもらえることを期待しています。End of Article

COBOLは最新環境の最前線でも活用可能な言語処理系なのだと改めて認識してもらえることを期待しています(松竹)

 
 

 INDEX
  [Keyman Interview]
    1.時代遅れという認識を払拭し、最新環境の第一線でもCOBOLを活用可能にする
  2.時代遅れという認識を払拭し、最新環境の第一線でもCOBOLを活用可能にする


 

 



Insider.NET フォーラム 新着記事
  • 第2回 簡潔なコーディングのために (2017/7/26)
     ラムダ式で記述できるメンバの増加、throw式、out変数、タプルなど、C# 7には以前よりもコードを簡潔に記述できるような機能が導入されている
  • 第1回 Visual Studio Codeデバッグの基礎知識 (2017/7/21)
     Node.jsプログラムをデバッグしながら、Visual Studio Codeに統合されているデバッグ機能の基本の「キ」をマスターしよう
  • 第1回 明瞭なコーディングのために (2017/7/19)
     C# 7で追加された新機能の中から、「数値リテラル構文の改善」と「ローカル関数」を紹介する。これらは分かりやすいコードを記述するのに使える
  • Presentation Translator (2017/7/18)
     Presentation TranslatorはPowerPoint用のアドイン。プレゼンテーション時の字幕の付加や、多言語での質疑応答、スライドの翻訳を行える
@ITメールマガジン 新着情報やスタッフのコラムがメールで届きます(無料)

注目のテーマ

Insider.NET 記事ランキング

本日 月間