マイグレーションパートナーインタビュー - 日本コンピュウェア株式会社

日本コンピュウェア株式会社

公開日　2004 年 12 月 24 日

開発支援ツールへの引き合い内容の変遷に、.NET への本格的な移行の状況を実感。移行への理由はズバリ「開発生産性の高さ」。

マイクロソフトの統合開発環境を利用するデベロッパーに、広く知られたデバッグおよびテストの開発支援ツール DevPartner Studio 。国内では法人組織のお客様を中心に 4,500 社以上の導入実績を誇っています。
その開発元の日本コンピュウェア株式会社は、マイクロソフトと長年に渡って緊密なリレーションシップを保ってきています。Visual Studio .NET 2002 が登場した際には、先陣をきって対応を表明したツールベンダの 1 社であると同時に、日本における .NET 環境の普及を自らのビジネス体験を通じて語っていただける貴重なパートナーでもあります。今回は、同社が VSIP (Visual Studio Industry Partner) に参加されたのを機会に、お客様における .NET への移行状況を伺いました。

＜コンピュウェアは .NET 普及に最初に立ち上がったパートナー企業＞

――　日本コンピュウェア株式会社 (以下、コンピュウェア) とマイクロソフトといえば、統合開発環境の提供者とその支援ツールの製品を有するベンダとしての協業関係を長く続けていますね。

松嵜　そうですね。もともと DevPartner は、米国の NuMega Technologies 社の製品だったのですが、それを 1997 年にコンピュウェアが買収し、開発支援のプロダクトライン化して以来、ほぼ 8 年になります。Visual Studio の進化に合わせるように、DevPartner Studio も進化してきました。特に Win32 アプリケーション全盛の時代は、BoundsChecker という、今は DevPartner Studio の製品の一機能になっている、メモリリークやリソースリークを発見する実行時エラー検出ツールが、たくさんのお客様に高く評価されていました。.NET の時代になってからは、お客様がプログラム品質をより重視されるようになってきたので、エラー検出だけにとどまらず、DevPartner Studio を .NET アプリケーションの品質を向上させるための支援ツールとして利用していただいています。

――　そういう意味では、黎明期から Microsoft .NET の普及に深く関わっていらっしゃいますね。

日本コンピュウェア株式会社
マーケティング本部
プロダクトマーケティング
専任／担当課長
松嵜　あつ子氏

松嵜　最初からのメンバということができると思います。2002 年 3 月の Visual Studio .NET の発表の時も、グレープシティ、東芝テック、富士通インフォソフトテクノロジ (以上、敬称略) 、と当社の 4 社で真っ先にアライアンスを組んで、「これから .NET は普及しますよ」「 .NET アプリケーションを補完するツールベンダは、確かにここにいます」という意気込みをアピールしています。具体的にはこの 4 社で、セミナーの共催や協賛、SODEC や Microsoft expo のイベントへの出展などを行いました。それに加え、4 社のアライアンスで製品カタログも作りました。当時 .NET と名のつくイベントは、すべて参加した記憶があります。
マイクロソフトから Visual Studio .NET のポスターをたくさんいただき、当社の出入り口、セミナールーム、担当者のデスクのそばなど、あらゆる場所に貼って社内での啓蒙はもちろん、当社を訪れるお客様にもプロモーションを図ったこともあります。

――　今回は、VSIP (Visual Studio Industry Partner) プログラムへ参加していただきましたね。

松嵜　当社は、DevPartner が Visual Studio .NET の統合開発環境に組み込まれる製品であるため、この前身の組織の Visual Studio Integration Program に参加していることから、今回、VSIP にも当然のように入りました。.NET への移行推進に関しても、DevPartner Studio の中に Visual Basic (以下、VB) から VB.NET への移行を支援する機能が含まれていたため、2002 年のリリース当時からメイン機能としてお客様に紹介させていただいており、VSIP 参加は昔からずっと継続している活動の一環と捉えています。

――　この 3 年間、お客様への移行支援機能の紹介を通じて、お客様からの反応はどのようなものがありますか。

日本コンピュウェア株式会社
営業技術本部
第二システム部
専任システムエンジニア
藤原　祐之氏

藤原　私は営業技術担当として、お客様へ伺い、DevPartner Studio の使い方や活用方法を説明させていただいていますが、お客様の反応が以前に比べてずいぶん変わってきたという印象はありますね。

――　以前はどのような反応だったのですか。

藤原　出荷が開始されてまもなくの頃は、お客様の戸惑いが大きかったようで、「とりあえず過去に VB や Visual C (以下、VC) で作ったものは、まだこのまま行きたい」という声が多数でした。そのため 2002 年の出荷時から移行を始めたお客様はそれほど多くありませんでした。本格的に使われ始めたのは、2003 年に入ってからですね。
当初、多かったお客様からの相談は「移行を考えているが、移行していいものでしょうか」とか「移行するならどの言語がいいでしょうか」「VB のアップグレードウィザードはちゃんと動くのでしょうか」といったものですね。やはり、オブジェクト指向

に慣れておられなかったので、どうすればいいのか手探りされていたという記憶があります。
そのようなお客様に対しては、DevPartner Studio の静的ソースコード解析というコーディングをチェックする機能を勧めています。まず移行の前に、移行しやすいようにわかる範囲で変更していただいて、移行してからこの機能を使うと、VB .NET の文法として適当でないソースコードや、C# らしくないソースコードがリストとして出力されます。その後で、このように直した方が良いとアドバイスが表示されます。もちろん、これはマイクロソフトの .NET 開発のガイドラインや MSDN の情報を活用したものです。
この機能を使うと、大概のコーディングでは多くの箇所がリストとして検出されます。お客様も驚かれるのですが、そこで 1 つ 1 つを説明すると「なるほど」と納得されます。例をあげれば、C# あるいは .NET のクラスにパブリック変数を書かれている方が結構いらっしゃいます。しかし、オブジェクト指向としては、適当ではありません。また、ネーミング規則も、昔はハンガリアン記法がよく使われていましが、新しくなってからはパスカル記法などへと大きく変わりました。
しかし、実際の開発案件では、今までの人的資産、ソースコード資産も活用しなければならないので、すぐには一斉に変更できません。そこで、当初はツールを使って自動的にチェックしていき、内容を見ながら変更点を学び、徐々に慣れていただくという段階的な方法をとられることを勧めているのです。

――　まずは人やコードを尊重して変更をツールに任せ、ツールに指摘された部分を人が学んでいくわけですね。

藤原　そのとおりです。ルール的には、静的ソースコード解析では 610 個入っているのですが、こんなたくさんの数を一度には到底覚えられません。ネーミング規則も含めて、そうしたルールを少しずつ、ツールを利用しながら自習していくわけです。実際、この静的ソースコード解析は手前味噌ながら強力で、マイグレーションウィザードだけを使って移行した場合と、これをかけてからマイグレーションウィザードを使って移行した場合では、And や Or などの動作が変わってしまうといったロジック的な部分の移行率が大幅に違ってきます。

＜開発生産性の高さに納得したお客さまが、.NET への移行を進めている＞
――　以前の反応から今は、どのように変化してきたのでしょうか。

藤原　最近では、本当に移行が始まっているのだなと実感しています。というのも、「移行を始めたのですが」という具体的な相談が非常に多くなってきたからです。お客様へ伺うと以前のように「移行なさった方がいいですよ」という場合より、「移行するにはこうされた方が良いですよ」と申し上げることが増えました。お客様の現在の環境を伺ったりもするのですが、3 年前は VC6.0、VB6.0 を使用されている方は 80% でしたが、今年に入ってからは逆に 70 ～ 80% が .NET を使っておられます。
最近では「ちょっとスピードが遅いのですが」とか「Win32 の VB6.0 や VC6.0 で作った DLL をどうしても呼ぶのですけど」と言われる方が多いですね。ツールでなんとかなりますかという問い合わせとでもいいますか。

――　ツールを使うとなんとかなるのでしょうか。

藤原　なりますよ。DevPartner Studio は、開発の流れに沿って、コーディングのときは静的ソースコード解析を行ってプログラムの文法をチェックし、実行時エラー検出機能で実際に動かしてエラーを見つけ、単体テストの時にカバレッジを分析し、再度動かしてパフォーマンスやメモリを分析するといった具合に、開発の工程に応じて順番にサポートしていくので、開発作業全体をトータルに支援することができます。なかでも最近人気が高いのがパフォーマンス分析ですね。「.NET アプリケーションを作って動かしてみたのだけど、実際のパフォーマンスを見てみたい」というお客様が非常に増えていますね。

松嵜　パフォーマンスという観点では、当社のワールドワイドプロモーションの一環で、 Profiler という DevPartner Studio の中のモジュールを試用していただくためのリーフレットを、Visual Studio .NET のパッケージに同梱していま

す。要はダウンロードサイトを紹介しているのですが、そのダウンロード率が昨年と比較して、今年は 10 か月で 25% もアップしているのです。たぶん、お客様が .NET アプリケーションを開発されている真最中で、パフォーマンスを出したいというフェーズに差しかかっているのではないかなと思います。

――　藤原さんなりに、移行が本格的に進んでいるのは何が原因だと思われますか。

藤原　いちばん大きいのは「開発生産性」ですね。とにかく作るのが簡単ですから。それに、人的資産、ソースコード資産も活用できます。たとえば、Web のアプリケーションを作るとします。画面１つでも試しに作ってみるとわかるのですが、.NET だと「あっ」という間にできあがります。これなら、お客様が作っていけると思われても不思議ではないでしょう。

――　利用者の 1 人として自身で使われた場合、ここがいいなと思われる点はありますか?

藤原　昔はプログラマをしていましたので、個人的にオブジェクト指向は好きです。システム全般にそれを適用していくのにも賛成です。ただ、普通のやり方で学ぶとオブジェクト指向は難しかったり、面倒な点がありますね。
前の会社で SE をやっていて、VB を使って新人を教育したことがあります。プログラムを初めて作るという人に教えるのは大変でしたが、なんとか VB を覚えてもらいました。しかし、その次にオブジェクト指向へ入っていけるかというと、非常に難しい部分があります。今、会社にいるプログラマを活かしていくという意味でも、.NET はオブジェクト指向のパラダイムへのシフトを助けるという点で、私は非常に意味のある、すばらしい環境だと思っています。多くの会社では、通常の仕事で多忙なために教育までなかなか手が回らないし、かといって独学でするといっても思うようにいかないでしょう。.NET を使えば、その辺を短縮できてオブジェクト指向という次のステップへきちんと進めるのがいいですね。

――　.NET でプログラムを作られて、最も開発生産性の高さを実感される瞬間は?

藤原　最近ですと、Web サービスですね。Web サービスを自分で 1 から作り、活用していくのは大変だと思うのですが、.NET で作ると先ほどの Web のページと同じくらいの速さで、「あっ」という間に作ることができます。そこから入って、だんだんと使えるものに仕上げていくと、工数も少なくてすみます。それが .NET のすごいところだと思います。お客様の環境でも、最近になって「Web サービスを使っています」と述べられる企業が多くなりました。当社では、.NET は十分基幹業務にも適用できると考えていますが、お客様もそれをそろそろ認識され始めたのではないかと考えています。

＜ .NET アプリケーションの品質を保つための支援は、これからも続けます＞

――　これから先 .NET 関連の製品で、何か新製品の予定はありますか。

松嵜　はい。まず、米国では DevPartner Studio が Visual Studio 2005 への対応を表明し、また、.NET アプリケーションの例外をシミュレーションして例外処理を検証できるツールや、ASP.NET アプリケーションに含まれるセキュリティの脆弱性を自動的に検出するセキュリティ検査ツール、さらに、結合テスト時などに GUI の操作をテストスクリプトとして記録・再生することで自動化し、テスト時間の短縮や効率化を図る機能テストツールといった新製品を 2005 年の春にリリースする予定です。.NET アプリケーションの品質の向上を図るという切り口で、この先もコンピュウェアは .NET をサポートしていきます。

マイクロソフトにとっても、.NET 対応ツールがどんどんラインナップ化されていくことで、今や VB の時と同じ環境が整いつつあります。これはお客様に .NET を検討していただくうえで非常に重要なことと考えています。

当社のお客様の多くは、とにもかくにも品質にこだわられておられる企業です。現在、システムがますますライフライン化し、アプリケーションが担う社会的責任も重くなってきているのは、だれの目にも明らかです。そうした中にあってコンピュウェアは、今日お話しした DevPartner Studio を初め、開発から運用までのライフサイクルに合わせた長いスパンで .NET アプリケーションの品質を保つ製品を提供していこうと考えています。昨今、マイクロソフトがアプリケーションライフサイクルの重要性を訴求されており、その点も当社のスタンスとますます同じといえますので、今後もずっと変わらずに支援させていただきたいと考えています。