質疑応答で筆者が質問した（というか意見を述べた）のは、大きく分けると４点だった。いずれも複数の開発支援ツール・ベンダーが集まった意味を、より有用にすることを意図したものだ。
一つ目はソフトウェア開発パターンの変化への対応だが、これに対して明快な回答はなかった。筆者の質問の主旨が伝わらなかったのかもしれない。
異種プロダクト間のインターフェースは?
二つ目は異種プロダクト間のインターフェースについてである。適用領域は限定的で、なおかつ各社のプロダクトはブラックボックスの島宇宙を形成することでユーザーを囲い込んできた。特定のDBMS、特定のクライアント・アプリケーション（例えばExcel＋IE）でしか稼動しないプロダクトもある。これを解決しないと、開発支援ツールの市場は大きく広がらない。
回答は「インターフェース作りに取り組みます」だったが、具体策は聞けなかった。筆者の想像だが、要求定義やデータ項目の情報をExcel（またはcsvファイル）に落として、プログラム・ジェネレーターに連動させるのがせいぜいだろう。それは当然で、なぜなら海外のプロダクト・メーカーが国内のプロダクト・メーカーにインタフェース情報を開示することは、よほどのことがない限りありえないからだ。
三つ目は分科会またはSIG（Special Interest Group）についてだった。開発支援ツールといいながら、センター処理モデルのウォーターフォール型アプリケーション向け、オープンシステムの分散型協調システム向け、オブジェクト指向のクライアント・アプリケーション向け、Webに対応したRIA（Rich Inernet Apprication）向けなど水と油に近いツールが混在している。同じ土俵で情報を交換・共有するのは不可能というか、ほとんど意味がない。
これについての回答は、「活動していくなかで、そうなる（分科会を設置する）かもしれませんね」だった。ありゃりゃ、ひな壇に並んでいるツール・ベンダーの方々は何を考えているんだろう、が筆者の感想。結局のところ、「コミュニティ」を通じて有望な潜在顧客を探し出すのがねらいなのだろうか？
ソフトウェア技術者を忘れてはいないか
四つ目は「コミュニティ」におけるソフトウェア技術者の立ち位置だ。発表者はコミュニティの参加者として、ツール・ベンダー、ユーザー、システム開発受託業、ITコーディネーターなどコンサルタント業を想定しているのだが、具体的なイメージをつかんでいない。経営者なのか役員なのか、管理職なのか現業部門の従業員なのか。ソフトウェア開発支援ツールのメリット／デメリットを理解してもらうべきなのは、何より先にソフトウェア技術者だろう。
というのは、現場のソフトウェア技術者は、得てしてこのようなツールの導入に対して強い拒否反応を示すことがあるためだ。能力があればあるほど、システム設計やプログラミングに自信があればあるほど、抵抗感は強くなる。なぜなら、開発支援ツールの利用を強いられるのは、技術者にとって能力を疑われていると受け取れる。あるいは上層部が、プロジェクトの進め方に問題がある、と認識している証左と考えられる。ここを乗り越えない限り、開発支援ツールがソフトウェア開発の現場に根付かない。
この質問の意味を理解して、すかさず樋山氏が「あ、いいご指摘をいただきました」と反応したが、他の発表者はあまり関心を示さなかった（ように見えた）。「コミュニティ」といえば個人が肩書き抜きで参加し、組織の枠を超えて情報を交換・共有する場ではないか。「コミュニティ」の意味を分かっているのだろうか――はちょっと言い過ぎ。おそらく何も決まっていないのに違いない。ひょっとすると、ここでいう「コミュニティ」とは、定期的に各社のプロダクトを紹介するセミナーのことなのか。
「コミュニティ」といえば個人が肩書き抜きで参加し、組織の枠を超えて情報を交換・共有する場ではないか。「コミュニティ」の意味を分かっているのだろうか―はちょっと言い過ぎ。おそらく何も決まっていないのに違いない。もしそうであれば、ネット上のバーチャルなコミュニティ（例えばＳＮＳ）と、フェイス・ツー・フェイスのリアルなコミュニティ（例えばセミナーや勉強会あるいは飲み会）の融合を図ってもらいたいものだ。
派生開発への対応 課題の認識に疑問
ソフトウェア開発パターンの変化というのは、ゼロベースからシステムを再構築するスクラッチ＆ビルトが減少し、既存のシステムを運用しながら機能を追加・改善していく派生開発が増加していることを指している。あるいは、中堅・中小企業ではＩＴ利活用のマインドが「作る」から「使う」へ変化し、アプリケーション・パッケージやSaaSに移行するケースも目立っている。
派生開発の手法が適用されるのは、自動車や家電製品に代表されるエンベデッド・ソフトウェアが典型だが、ライフサイクルの期間こそ違え、ビジネス・アプリケーションでも同様だ。ビジネス・アプリケーション領域では新規開発では予算が取れないので、保守運用費から開発費を捻出している情報システム部門の事情にも依っている。
そのような開発パターンにあっては、開発支援ツールを適用するのが難しい。多くの開発支援ツールはスクラッチ＆ビルトを前提としているので、既存システムのデータ構造やプログラムのソースコードを解析して再設計するリバース・エンジニアリング機能が脆弱なのだ。超高速開発コミュニティのメンバーがどんなに「手組みと比べて３〜10倍の速度」を謳っても、適用できる範囲は限られている。
もう一つ見逃せないのは、プログラムの総ステップ数――規模を測る指標が他にないのでこういうしかないのだが――が、脅威的に膨張していることだ。伝聞だが、例えば1990年代の初めに「大規模」とされた金融機関の第３次オンライン・システムは、ざっくり1メガ（M）ステップだった。先に失敗プロジェクトとして話題になった特許庁のシステムは60Mステップとされる。さらにインターネット／イントラネットで、複数の企業や事業部門のシステムがシームレスに連携する。
またソフトウェア技術者１人／月のプログラムの生産性は、モジュール化の進展もあって大幅に向上している。対象のアプリケーションやプログラミング言語、開発環境にもよるが、１人／月３万ステップというケースもある。このような状況下にあって、開発支援ツールが時速100kmを120kmにアップさせるとして、どれほどの意味があるだろうか。ソフトウェア開発現場で焦眉の的となっているのは、プログラムを作ることではない。かつてはいざ知らず、現今のソフトウェア開発の本質は、設計とテストとレビューである。
60Mステップものプログラムをどのようにテストしていくのか、プログラム作成の進捗をどのように把握し、どのように“見える化”（見せる化）していくか。派生開発の視点に立てば、機能の改善・追加に伴う波及分析とテストのエビデンス／アシュアランスということになる。そうなると、これはもはや「超高速開発」という言葉が意味を持つ世界ではない。
超高速開発コミュニティの設立者たちがこのことに気がついているなら、よりユーザー（ないし経営者）の目線に近づいて、「めまぐるしく変化するビジネス環境に、情報システムを迅速に対応させるには」を訴求していくほかない。ベンダーの立場を離れることができるだろうか。
