先日,中堅システム・インテグレータでSEマネジャーを務めるA氏が,記者にこんな悩みを打ち明けてきた。「以前参加していたプロジェクトはとても仕様変更が多くて変更管理が大変だった。これからは市販のツールを導入したいと思うのだが,なにせ値段が高くて。みんなどうしているんだろう」---。

 詳しく聞くと,そのプロジェクトでは,仕様の凍結がなかなかできず,詳細設計フェーズやプログラミング・フェーズに入っても仕様変更が発生したのだという。そこで,A氏は次に参加するプロジェクトでは仕様の変更管理の負荷を軽減するべく,変更管理支援ツールを導入したいと考えた。ところが,その値段の高さから導入すべきかどうか悩んでいたのである。

 ちなみにA氏が検討していたツールは,1ユーザー当たり約62万円。仮に20人のプロジェクトに導入すると,その金額は約1240万円にもなる。この価格に見合う効果が得られるか,それがA氏の悩みだったようだ。

上流支援・管理ツールは根付くか?

 ひと口に「開発支援ツール」と言っても,その種類はさまざまである。GUI画面上でプログラミングやデバッグが可能なツール,単体テストや結合テストを自動化するツール,UMLやE-R図などを記述するツールなどがある。加えて最近は,構成管理や変更管理を支援するツールのほか,要件定義ツールやテスト管理ツール,プロジェクトマネジメント・ツールといった製品も充実してきた。

 ところが,プログラミングやデバッグ・ツールなどとは異なり,上流工程を支援するツールや負荷テスト・ツール,各種管理ツールは値段が高い。このため,前出のA氏のように導入をためらってしまうケースが少なくない。

 開発支援ツールに詳しいアシスト ソフトウェア・リサーチ・センターの沖 冠吾氏もこう指摘する。「品質に対する意識の高まりから,1000万円を超える負荷テスト・ツールやテスト管理ツールの引き合いも出始めた。しかし,自社の開発手法の整備や利用に当たってスキルが求められる構成管理ツールやプロジェクトマネジメント・ツールについては,導入はこれからといったところだろう」。

 開発支援ツールによっては,導入に際してメンバー教育の時間やコスト,ツールをプロジェクト内に定着させるための開発手法の整備が不可欠である。これが,価格とともに,開発支援ツールの導入を難しくするもう1つの原因だ。ボーランドが昨年,CMM(Capability Maturity Model)やPMB0K(Project Management Body Of Knowledge)のコンサルティングを手掛けるTeraQuest社を買収したのも,製品の導入とともに開発手法の整備やメンバー教育を支援する体制を作り上げるためである。

 一方,プログラミングやデバッグ・ツールにも動きがある。その1つが製品ベンダーがそろって「個人」から「チーム」へと軸足を移している点だ。たとえばVisual Studio.NETに対しては,「チームでの利用を前提としており,システム開発の生産性向上に効果がある。今後,開発現場に深く浸透する可能性が高いのではないか」(沖氏)という声もある。NTTデータや日本ユニシスなどの大手ベンダーも.NET専門の開発部隊を設置するなど,開発プラットフォームとしての.NETの普及が進んでいる。

 J2EE環境においては,プラグインも充実してきたEclipseの牙城が揺るぎないだろう。オープンソースで無償配布の開発支援ツールの普及は顕著であり,たとえばJUnitやJMaterといったオープンソースのテスト・ツールも広く使われ始めている。こうした状況を見ると,とりわけ下流工程の開発支援ツールは今後,オープンソースのものの存在感が高まっていくことが予想される。そうなると,上流工程をカバーする市販ツールとの連携や,市販のプログラミングやデバッグ・ツールとのすみ分けはどうなっていくのか。興味があるところだ。

皆さんの声をお聞かせください

 こうした疑問に答えるために,2006年4月に新創刊する日経SYSTEMSでは,「開発支援ツールに関する利用実態調査」を実施中だ。調査のポイントは,以下のように大きく4つある。

 1つ目は,「フェーズ別のツール利用状況」を探ることだ。ここでは,要件定義や設計,プログラミング,単体/結合/システムテストといった各フェーズにおける開発支援ツールの利用の有無や検討状況,実際に使っているツール名などを聞く。要件の複雑さ,膨大さ,あいまいさに苦しむ開発現場では,ベンダーがこぞって製品化を図った要件定義ツールを導入・検討しているのか,品質への意識の高まりとともに高価な負荷テスト・ツールは本当に導入が進んでいるのかなどを明らかにしたい。

 2つ目は,「言語/プラットフォームの利用状況」である。ここでは,最もよく利用する言語やプラットフォーム,ツール名などを聞く。プロジェクトの規模や種類によってどんな言語/プラットフォームを採用しているのか,.NETの普及はどこまで進んできたのか,その他の言語の状況はどうかなどを明らかにする。J2EE環境においてはEclipseの牙城がどこまで本物なのか。現場の意見が気になるところだ。

 3つ目は,「各種管理ツールの利用状況」である。いま市場にはさまざまな管理ツールがある。前出の構成管理/変更管理ツールのほか,要求/要件管理ツール,バグ/テスト管理ツール,プロジェクトマネジメント・ツールなど多岐にわたる。ここで,利用の有無や検討状況などを聞く。果たして,仕様変更が頻発する中で構成管理や変更管理のツールは使われているのか,プロジェクトマネジメントが重視される中で統合的な管理ツールは使われているのか,バグの発生や除去,テストケースの実行状況などを管理するテスト管理ツールはどうか,などを探りたい。

 最後は,「開発支援ツールに望むもの」として,まずどんな技術分野において開発支援ツールの充実を望むのかを聞く。AjaxやO-Rマッピング,DIコンテナ,MDA(Model Driven Architecture)など,現場のITエンジニアはいったいどんな技術分野のツールに期待を寄せているのか。さらに,どんな点に重視して開発支援ツールを選定しているのかも興味深いところだ。ツールの採用において,開発チーム内での利用をどこまで意識しているのか,CMMやCOBIT(Control Objectives for Information and related Technology)といった組織の成熟度モデルを意識してツールを選んでいるのか などを探りたい。

 システム開発の生産性・品質を向上させる手段の1つとして,「開発支援ツール」の導入は有効である。しかし,一歩間違えれば,“宝の持ち腐れ”としてコストがかさむだけでなく,逆に生産性や品質を悪化させてしまう危険性もはらんでいる。それを回避するために,皆さんと一緒に開発支援ツールのあり方を考えていきたい。アンケートにご協力いただければ幸いである。

(池上 俊也=日経ITプロフェッショナル