Webを知るCOBOL技術者が必要

 富士通ビジネスシステムでは,比較的順調に開発が進んだ。しかし既存資産を生かして,言語が混在するシステムを作る際には,大きな課題がある。

 その一つは,技術者不足である。まず,開発言語が多様化したことなどにより,若いCOBOL技術者数は減少傾向だ。基本情報技術者試験の午後試験でCOBOLを選択する割合は,「10年前の約半分」(日本情報処理開発協会 情報処理技術者試験センター 総務部 総務課 成海洋氏)と言う*3

 実際,技術者が確保できないためにCOBOL資産を捨てざる得ないケースもある。東急建設では,リストラクチャリングの一環として1999年に情報システム部を廃止した際,関連会社に業務委託を行った。しかし,結果としてシステムの内容に精通した後継人員の育成ができなくなってしまった。最終的に,500万ステップのCOBOL資産を捨て,ERPパッケージに一気に移行する選択となった。

図2●損保ジャパン・システムソリューションにおけるCOBOL技術者のWebスキル取得の例
Web部署へ配属されたCOBOL技術者や希望者は,1カ月半の実務研修を受ける。新規開発言語の習得は,実際の開発現場で学ぶことが最短の近道だが,業務は固定しやすい。大規模開発で分業化が進む同社では,スキルが固定化しないようにWeb基礎教育はすべてのCOBOL技術者に必須としている

 技術者確保に向けて,教育方針を見直すベンダーも出てきた。日立製作所の民間系システムの構築を担当する部署では,新人教育のCOBOL研修期間を2000年にいったん短縮したが,2002年には元の日数に戻した。金融向けや産業向けの新規開発ではWeb系の開発が進むものの,実は5割がCOBOL開発だったという現状を再認識したためだ。

 もう一つの課題は,COBOLのスキルだけではリサイクル開発ができないということだ。「COBOLとWebの橋渡しができるバイリンガルが不足している」(アリコジャパン システム企画部 品質管理担当 主任 水摩和人氏)。コーディングは1つのスキルで足りても,設計,保守,トラブル対応などでは両方のスキルが必須となってくる。

 こういった問題を意識し,バイリンガル教育に力を入れる企業もある。損保ジャパン・システムソリューションでは,COBOL技術者に1週間のWeb基礎研修を必須としている(図2[拡大表示])。

 希望者は1カ月半のWeb実務研修も受講できる。Web実務研修では,コーディングを含むASP*でのWebシステム開発手法を実践。「スキルは学ぶだけでなく実践することで,初めて身につく」(同社 保険システム事業部 自動車グループ 主任システムズ・エンジニア 北岸享氏)と考えるからだ。

整理しないとリサイクルできない

 またどんなCOBOLアプリケーションでも容易にリサイクルできるわけではない。リサイクル前に確認すべきポイントが2つある。

 一つは既存アプリケーションが構造化されていること。「画面と業務ロジックが分離されているシステム,構造化されているシステムからは業務ロジックが抽出しやすい」(日立製作所 ソフトウェア事業部 基本ソフトウェア本部 言語設計部 部長 横塚大典氏)。

 富士通ビジネスシステムの開発では,旧パッケージの仕様自体は生かせたものの,実際にリサイクルできたCOBOLソースは30%程度だった。旧パッケージが開発された1980年では構造化設計がサポートされていなかったため,画面と業務ロジックの結び付きが強い設計になっていたためだ。

 実際の開発ではMVCモデルを利用して,分業による並行開発を進めた。画面であるビューは2名のVB技術者が,処理フローを制御するコントローラは3名のJava技術者が,既存のCOBOL業務ロジックをリサイクルしたモデルは西面氏ともう1名のCOBOL技術者が担当した。さらに,1名のC#技術者がDBアクセスなどの共通部品を作成した。異なる言語を並行して開発できるメリットは大きい。

COBOLプログラムを分解して利用

 もう一つのポイントは,業務ロジックが利用しやすい大きさ(粒度)であるかどうかだ。

 損害保険ジャパンは保険料試算サービスを,代理店向けなど用途別に4つのシステムに構築していた。各システム開発の際,保険内容の書かれた分厚い「規定集」をそれぞれの開発者が読んで仕様を作成したため,「システム間で仕様解釈に違いが発生してしまった」(構築を担当した損保ジャパン・システムソリューション 代理店システム事業部長 小澤淳氏)。

 そこで同社はCOBOLプログラム自体の共有を検討した。しかしその際,各システムごとに画面項目の入力順が異なるため,「共有するためには一番細かい単位までプログラムを分解する必要があった」(同 保険システム事業部 自動車グループ グループリーダー 山田一彦氏)。

 つまり,再利用するにはプログラムの単位が大き過ぎた。手続き型であれば通常,あまりサブルーチン化し過ぎるとかえって読みにくくなるが,再利用するためには細かい機能単位に分かれていた方が良い。同社では既存システムを徹底的に見直し,合計7000個の保険内容チェックと保険料計算の部品に分解した。各システムでは,これらのCOBOLで作った部品を適宜組み合わせてCOM化し,Webシステムで利用している。

「COBOLもJavaも」と認識すべき

――COBOLコンソーシアム会長

 現状,世界では250万人以上のCOBOL技術者がいるが,減少傾向にある。一方,Java技術者は80万人程度で増加傾向だ。両者は2010年ごろに逆転するだろう。

 COBOLは規格が安定しており,COBOLで書かれた企業ロジックはなくなることは無い。ただし,柔軟にWebアプリケーションを構築できるJavaと組み合わせる事例はさらに増えていく。これからは「COBOLかJavaか」ではなく「COBOLもJavaも」と認識すべきだ。

 J2EEには,今後も成長していきシステム構築の基盤になってくれると,大きな期待を持っている。ただし現状では,大量データのバッチ処理やシステム・ダウンの許されない大規模のミッション・クリティカルな業務では,開発手法やミドルウエアの実績からCOBOLが適すると考えている。

 また,2002年11月に第4次規格「COBOL2002」がISO承認を受けた。第3次規格「COBOL85」から17年ぶりの新規格だ。規格の下位互換性は保証されているため,企業はいずれCOBOL2002に移行する。

 新機能の目玉は,オブジェクト指向機能を搭載したことと,漢字などのマルチバイト文字が扱えるようになったことだ。ただし,オブジェクト指向機能は,オープン系のCOBOL開発ツールがまず実装するだろう。具体的には,オブジェクト指向言語との連携コードはツールが自動生成する。オブジェクト連携を行うCOBOLアプリケーションは徐々に広まるはずだ。開発者全体がその機能を使うようになるのは,まだしばらく先と見ている。


(井上 英明=h-inoue@nikkeibp.co.jp)