MSDN Home MSDN Home

株式会社滋賀富士通ソフトウェア

公開日 2005 年 11 月 17 日

言語の変換は本来技術者の悩むべきところじゃないと開発した Visual Basic から .NET への移行ツール。
目標は、パートナーを募って迅速に裾野を広げること。

滋賀富士通ソフトウェア

滋賀富士通ソフトウェア
株式会社滋賀富士通ソフトウェア (以下、滋賀富士通ソフトウェア) は、「富士通」 と 「滋賀銀行」 をバック ボーンとして、 金融システムや地域システムに貢献する SE 集団です。 同社のさまざまな事業の大きな柱の 1 つとして、企業の人事管理・給与管理業務に対するトータル ソリューションの提供があります。 その中核基盤に、お客様の業務に応じた柔軟なシステム構築と貴重な人財情報の有効活用を実現する 「HITKOT for .NET」 があります。 これは 「お客様の文化を大切にする」 というビジョンの下に、データ モデリングと共に業務を定義しながら完成させていく 画期的なパッケージ アプリケーションです。 同社がこの 「HITKOT」 の .NET 版を開発する過程で気づいたのが、Visual Basic (以下、VB) プログラム資産の効率的な .NET 移行の重要性です。 そこで誕生したのが VB マイグレーション ツール 「CoolCat for .NET」 だったのです。


＜きっかけは自社アプリケーションの .NET 移行＞
―― そもそもどういう経緯で 「CoolCat」 を開発されたのでしょうか。

佐藤保幸 氏
株式会社滋賀富士通ソフトウェア
システム統括部 統括部長代理
マネージングコンサルタント
佐藤 保幸 氏
佐藤　 2001 年から 2002 年にかけて、「HITKOT」をクライアント / サーバー型アプリケーションから Web アプリケーションにバージョンアップしようというプロジェクトが持ち上がったのがきっかけです。 その当時、富士通グループでは全社的に Java の利用を推進していて、当社も EJB でブラウザ化を実現しようという流れがありました。 「HITKOT」は入力の仕組みを VB6.0 で作っていたのですが、それを EJB (Enterprise Java Beans) 化しようとしたのです。 ところが、半年ぐらいかけて取り組んだものの、手間がかかったり、なかなか性能が出ないという問題が発生するなど、うまくいかなかった。 どうしようかと悩んでいるときに、「HITKOT」の導入を進めてくださっていたある金融機関のお客様との商談の中で、 マイクロソフトに出会いまして、.NET 化を薦められました。一緒にやりましょうということで。 そのお客様が .NET Framework を採用されていたこともあり、そういうことであれば乗り換えようと、.NET 化を決断しました。

―― 最初 EJB で取り組まれたのがうまくいかなかったというのは、どのような点が難しかったからでしょうか。

川村　 VB の資産をできるだけそのままの形で Web アプリケーション化しようとしましたが、 それが EJB では難しかったのです。結局、中身を理解しつつ 1 から全部 Java に置きなおすことになってしまいます。 基本的には画面イメージなどはそのまま流用して使いたいのに、Java で解釈しなおさなければならないため、資産をそのまま生かせないというのが最大のネックでした。
それでも、画面の見た目などはブラウザで動かすこともあり、若干直さなければいけないのは覚悟していたのですが、 そのまま利用できる業務ロジックの部分まで全部作り変え、画面とのインターフェイスを考えて、という作業そのものが非常にリスクも高く無駄だと思いました。

佐藤　 それで、VB 6.0 から .NET に取り組んだのですが、それでも簡単には進められませんでした。 標準アップグレード ウィザードという仕掛けは提供されていましたが、それほど単純には移行できません。 私たちはそのプロジェクトでマイクロソフト コンサルティング サービスと協業していたのですが、 そこでいろいろ技術支援を受けながら、それでも 1 年ほどかかって、ようやく 「HITKOT for .NET」 をリリースでき、そのお客様にお納めすることができました。
このことが富士通グループの中でもある意味有名になりまして、富士通本体から VB 4.0 を利用していて .NET への移行を検討されているお客様を支援して くれないかという話がきたのです。業務的に不満足かというと決してそうじゃない。ただ Web 化の波がきているとか、 ハードウェアが使えなくなってきたといった理由でのシステム更改ニーズが非常に高かったのです。2004 年の 1 月ごろのことですね。
そのような案件がいくつもあって、.NET 化というのはビジネス チャンスがあると実感するようになりました。私たちもよく知らなかったのですが、日本の中には膨大な VB 4.0 の資産があります。今までは何とかメンテナンスという方法で乗り切ってきましたが、ハードウェアや OS をアップグレードしていかなければいけない中で、 VB 4.0 で稼動しているクライアント/サーバー型システムというのは、企業にとって 1 つのリスクになってきていたのです。

―― 企業における VB 資産は想像以上に大きいものなのですね。

佐藤　 ええ。もう 1 つビジネス チャンスがあると思った理由があります。当時よく標準アップグレード ウィザードを使った移行の失敗事例を聞きまして。具体的には、これがあれば簡単だろうとコンバージョンしてみたらコンパイル エラーが続き、想定した納期や品質を保てなくなるというケースです。それを聞いて .NET 移行については 「ただのソースの変換なのに、 とんでもなく工数がかかる」 と一種の風評のようなものが流れ、非常にリスクがあるという感じで受け止められていました。 我々からすると、それは標準アップグレード ウィザードに頼りすぎるからだと言いたいのですが。


＜「HITKOT for .NET」 の開発プロセスで気づいたこと＞
―― それでは、御社自身の .NET 移行へのご経験でいろいろ気づかれたことがあったのですね。

佐藤　 そうです。私たちが苦労したことや、VB 4.0 や VB 5.0、VB 6.0 からの .NET 化の要望などを考え合わせて、このまま放置しておくと、 もう一度同じように経験されるお客様やシステム インテグレータが続出してしまうと考えました。 それはリソース的に非常にもったいないことだと思いました。 正直申し上げて標準アップグレード ウィザードでは限界がありますから、 もう少し私たちが何かのツールとして開発すれば他の技術者が楽になるのではないかと、 「CoolCat」の開発を決断したのです。

―― そういう流れがあったのですね。

佐藤　 VB の技術者に言わせれば、VB 6.0 から .NET への移行というのは親和性がある。 見た目は一緒だから入りやすいし、市販の書籍もたくさん出ていて、 インターネットでも結構な情報が得られると言います。 だから、全部マニュアルで移行すればいいじゃないかというと、プロジェクト管理を行う私のような立場から するとそうではありません。 すでに稼動している VB の資産をハードウェアの保守期限切れを契機に新 OS にして、VB も更新しなければ いけないとなったとき、技術者をそれだけ集められるかというと別の問題があります。 資産があまりにも膨大なので、とても追いつきません。
もう 1 つの選択肢としてオフショア開発も考えられますが、その場合、外に出すということで 言語や文化の面で壁があります。それなら、しょせん言語なのだから、システムで きちっと変換できないのかと。 技術者といろいろ会話して変換ポイントというのはいくつか押さえてあったので、 ではそれをベースに仕掛けを作ろう、と。 単純な言語移行といっても、業務的なテストの量というのは、標準アップグレード ウィザードを使おうと、 ツールを使おうと、1 から作り直そうと、まったく変わらないでしょう。 しかし、標準アップグレード ウィザードで出たエラーを一生懸命手で直すのと、 ボタンを押したらビッと変換してくれるのと、1 から Java などの他の言語でコーディングし直すのとでは、 やはり工数が全然違いますよね。そこがやるべきだなと思った理由です。

佐藤保幸 氏
株式会社滋賀富士通ソフトウェア
システム統括部 HR ソリューション部
グループリーダー
川村 錦ニ 氏
――　移行ツールの開発を検討された企業は他にもありますが、VB と .NET は別ものだからなじまない、と判断されたところもお聞きしたことがあります。御社ではそういうお考えはありませんでしたか。

佐藤　 私たちは業務設計をしっかりやって、プログラミング、コーディングという 工程をいかに短縮するかということを長年行っているので、 ツールを使って効率化するということに対し、リスクと感じることはなかったですね。


＜CoolCat for .NET を核にサービスを提供＞
―― 「CoolCat」という名称の由来は何でしょうか。
佐藤保幸 氏
佐藤　 猫の手も借りたい、というところからきています。
というのは冗談で、当社に「CoolDog」というツール、ドキュメント生成ツールなのですが、 これが先行して存在していたので、こちらは猫にしようかなと。

―― それでは、まずこのツールの特長を教えていただけますか。

佐藤　 VB の文法というのは、技術者にとっては都合が良いものです。 技術者のクセを許容するというか、いろいろなバリエーションが可能で、 画一的な作り方がなかなかされていません。そういう文化のものをツールでポンと一括に変換させていくには それなりの工夫が必要でした。 そこで、いきなり完璧なツールを作ることを目指すのではなく、成長していけるツールにしようと考えました。 学習し、その学習で得た情報をツールに与えることで、次のお客様からはそこが一発で通るといった具合に。 これを最初の達成ポイントとして、2004 年の春ぐらいから半年ぐらいかけて作りました。


―― 成長させていくというのは、具体的にはどういうことでしょうか。

川村　 変換パターンを蓄積させるのです。変換テーブルというものを持って、 1 回変換して出た問題をそこへどんどん貯めていく。 最初はエラーが出ますが、次からは既に貯められた変換テーブル上の情報を使って変換できます。
これもツールの特長になっているのですが、一般的には変換をし、変換後のソースに手を入れて なんとか完成させようとします。しかし、「CoolCat」 は、変換後に一切手を入れないという考え方です。 それはなぜかというと、システムの規模が大きくなるほど移行間隔が長くなるため、 変換後のソースに手を入れる方法だとソースが二重管理になってしまう。 しかし、それでは管理が複雑になるし、リスクも高いので、ソースは常に 1 個にしているのです。 そして必ず一方通行の変換をします。どうしても変換できないものは、変換前のソースに、 .NET で実現する文法を作り、コメントとして入れこんだ後に、もう一度変換します。 こうして、だめだったら前に戻るという形で常に一方通行の変換を繰り返して完成度を上げていくのです。

佐藤　 川村が一方通行といいましたが、これがわれわれの大きなセールス ポイントでもありますね。ソース管理の世界では、よく 「分家する」 といいますよね。 そうするともう元に戻れなくなってしまうものなのですが、 私たちは 「先祖がえり、OK」 ということにしてあります。これは結構、有効ですね。

―― サービスの詳細について教えいただけますか。

佐藤　 大きく 4 つあります。「初期診断サービス」 「ソース変換サービス」 「動作検証サービス」 「テクニカル サービス」 です。
まず 「初期診断サービス」 ですが、システムを移行するときに、コメントを入れる率がどれぐらい あるかというのは、技術者のクセとか、どんな他社製の OCX (OLE Custom Control) を使っておられるかということでだいぶ違ってくるので、 いきなり 「これぐらいでできます」 とお答えするのは難しいのが実情です。 ですから、まず対象となるシステムをお借りして、移行するとなると、 どこに手が入って、見た目がどう変わる、ここはコメントを入れざるを得ない、 といったことをお伝えして、「それでも実行されますか？」 と伺うプロセスなのです。
そうして提案した変換方法に了解をいただければ、次の段階である実際のソース変換に入ります。 この段階では 「CoolCat」 を使った変換をして、コンパイルを完了したソースをお渡しします。 これは変換だけで動作を保証するものではないのですが、どういうところに手を入れました、 というレポート機能を非常に充実させています。
しかし、それだけではお客様としては安心できないだろうということから実施しているのが、 「動作検証サービス」 です。コンパイルを完了したものを、いくつか試験項目を決め、 お客様と一緒にソースを動かして、業務テストに堪えられる、というところまで確認します。
実際に業務テストが始まってから、新たな壁にぶつかるというケースももちろんあります。 「CoolCat」 は繰り返し変換して使うものなので、業務テスト中に、もう一度変換させる 必要が生じる場合もあります。そういったときに技術支援を行うのが 「テクニカル サービス」 なのです。

―― 基本的には 4 つのサービス全部を希望される感じでしょうか？

佐藤　 それ以上のことを求められるお客様もいらっしゃいますね。 たとえばクライアント / サーバー型システムで 10 年ぐらいメンテナンスしているソースでは、開 発当時のことを知っている人間が既に退職していて、「新任者に変わるのを契機に以後のメンテナンスを してくれないか」 という場合もあります。 このような話をきっかけとして商談の輪が広がっているのは事実です。
今回のサービスについて一言申し上げておくと、VB 4.0 や VB 6.0 のソースから .NET 版に するということは、それが必ずしも Web 対応をするというわけではありません。 あくまでもクライアント / サーバー型システムを .NET の言語に置き換えて、.NET 上のクライアント/サーバー型システムにするということです。 しかし、いったんその段階にまでこぎつければ、Web 対応をするのは比較的楽になります。 私たちとしては、いったん .NET でクライアント / サーバー型システムを作って、今度は Web 化、シンクライアントにしていくための再構築という段取りに持っていければと思っています。

―― そのようにお考えになっているのはなぜですか。

佐藤　 VB 4.0 から .NET にするというのは非常にリスクがあるとお考えのお客様はまだ多いようですので、 安心していただく意味合いでこう申し上げています。


＜前に出るよりパートナーを探して裾野を広げる方が大事＞
―― ずばり変換率は何パーセントでしょうか。

佐藤　 理論上は 100 % です。なぜかというと、100 % になるまで 繰り返し前に戻って変換し続けるからです。変換テーブルで対応できないような変換、 たとえば同じ操作をするのだけれども、.NET になったことによってプロパティ情報が増える、 それも固定値ではなく、業務的に判断しながら入れてやらなければならないものは、 コメントで 「こうやってちょうだい」 と入れる。だからツールは変換率 100 % になるわけです。 ただ、コメント行がゼロでいけるかというと、それはたぶん難しいとは思います。 これは業務的に判断が必要なプロパティ情報を持った OCX をどれだけ使っているかという お客様のプログラムによって違ってきますね。

川村錦ニ 氏

―― それにしても重要なサービスを開発されましたね。

佐藤　 最初は、これはマイクロソフトがやるべき仕事なのかなと思っていました。 ただ、マイクロソフトとも会話していく中でわかったことは、言語を提供しているベンダーとしては、 VB 4.0 から .NET というような変換も、とにかく言語に忠実に変換しなければならないということです。 言語に忠実に変換できないところは 「できません」 とアラームをあげるまでが ベンダーとしての限界なのだと思いました。
その点、「CoolCat」 は、言語ではない世界にも一歩足を踏み込んでいるというか、 言語の文法と業務のアプリケーションの端境にあるところも面倒みようとしています。 実はそこがいちばん泥くさいけれども非常に必要でマイクロソフトにそれを要求しても 難しいところなのかなと。富士通のような、お客様との間に立つようなベンダーが やるべき仕事なのではないかと思うようになりました。

―― このビジネスへの期待度はいかがですか。

佐藤　 これはサービス商品なので、どうしても SE が必要です。 滋賀富士通ソフトウェア 1 社で手がけるのは荷が重いところがあるので、 われわれと一緒になってやってもらえるようなパートナーさんを探しているところです。 このサイトを見て、「CoolCat」 のサービスをやってみたいと名乗りを上げてくださる システム インテグレータさんがいらっしゃったらうれしいですね。
「CoolCat」 というのは、あくまで HR ソリューション部の副産物です。 滋賀富士通ソフトウェアとして、大規模な部隊にしたいという意向はありません。 本来、こういった部分は技術者が悩んで立ち止まるところではないので、 パートナーの方々に助けていただきながらともに早く普及させていくことの方が大切だと思っています。


―― 本日はありがとうございました。


※ COOLCAT に関するお問い合わせは、滋賀富士通ソフトウェア COOLCAT ご担当者様 (coolcat@cs.jp.fujitsu.com) までお問い合わせください。

本ケーススタディに記載された情報は初掲載時のものであり、閲覧される時点では変更されている可能性があることをご了承ください。
本ケーススタディは情報提供のみを目的としています。Microsoft は、明示的または暗示的を問わず、本書のいかなる保証を与えるものではありません。