Loading
|
|
＠IT｜＠IT自分戦略研究所｜QA＠IT｜イベントカレンダー＋ログ |
|
Loading
|
|
| ＠IT総合トップ > ＠IT セミナー＆カンファレンス > ＠IT特別協賛 翼システム カンファレンス2002 > Keyman Interview[4] |
|
いまや情報システムは、企業の戦略を左右する重要な鍵といえます。システム開発者に求められるスキルは、技術はもちろんのこと長期的なビジネスビジョンに基づくシステム構築を行える能力が不可欠となっています。いま企業が求めるIT戦略と課題は何か、業界キーマンに聞き、次代のITビジネスの方向性を展望していきます。
第4回は、ソフトウェア開発の効率化、開発プロセスやソフトウェアのライフサイクルを向上させるための方法を研究し、それを実現するための統合開発環境を提供するトゥゲザーソフト・ジャパンの脇本亜紀氏、後藤啓氏の登場です。これからの企業の情報システム開発の在り方と、開発者に求められる課題について伺います。
（聞き手：＠IT藤村厚夫）
藤村●トゥゲザーソフト様は、非常にユニークな製品を創り出されていますね。最初に、トゥゲザーソフト様とは、どんな企業なのかお聞かせください。
ピーター・コードが蓄積した開発方法論、および彼が実践してきた理想的な開発スタイルをもってTCCは開発されました。そして、そのTCC上で、さらにTCCが進化しているという部分がユニークでしょう。 まもなくTCC 6.0をリリースしますが（日本語版、英語版は3月末リリース済み）、もちろんTCCの上で開発されています。TCC自体がTCCに関して最高の事例といえます。リリース・スケジュールをスリップしたこともありませんし、お客様にも安定性や品質の良さを評価していただいています。 本社はアメリカのノースカロライナですが、開発拠点は、チェコのプラハや、ロシアのサンクトペテルブルクにあります。日本語化に関しては、日本からも技術者が参加していますので、まさにワールドワイドで遠隔地間の調開発をTCC上で行っているわけです。
藤村●現在、ソフトウェア開発環境、あるいはソフトウェア開発自体が変革期を迎えています。この課題をどうクリアしていけばいいのでしょうか。 脇本●まず、ビジネスとシステムの関係ですが、システムにおけるリスクが経営の根幹を揺るがしかねない状況になってきています。以前はシステムの問題はシステム内で完結していました。しかし、最近はソフトウェア開発の成否がビジネスの成否に直接かかわるようになり、システムの内包する経営リスクというものを考えなければならなくなっています。一方で、技術の進歩があまりにも急速であるために、企業マネジメント層とシステムとが乖離してしまっています。つまり、システムの重要性が増し、マネジメントはシステムに内在するリスクを管理しなければならないのに、システムのことが分からない──そうした矛盾した状況にあると思います。 これは完全に解決できる問題ではないにしても、ソフトウェア開発の側から一歩踏み出すようなアプローチがあってもいいのではないかということから、弊社では“開発プラットフォーム”という提案をしています。現状では、個々の開発者が、個別に選択したツールを開発のそれぞれのフェーズで別々に使っているという姿が圧倒的に多いと思われます。しかし、プロジェクトの重要性が増し、しかも大規模化している状況では、こうしたあり方は、不十分でむしろ非効率的です。会社全体として一貫したシステム構築を行うために、個々のツールではなく、“開発プラットフォーム”というレイヤを利用することによって、システム開発と運用の面で、さまざまなリスクをヘッジできることをマネジメント層の方々に分かっていただきたいと考えています。 現場の開発者にとっても、技術の進歩は非常に速く、しかも納期などのビジネス上の要求も厳しくなる一方です。新しい技術にキャッチアップすることは、さらに難しくなっています。このままでは、技術が進歩しているのに、それを使いこなせる技術者が減ってしまうということが考えられます。開発プラットフォームの利用により、新しい技術を利用しながら、個々の技術者への負担が軽減する──という効果も期待できるのです。
藤村●開発者を取り巻く環境は、時間、コスト、クオリティだけでなく、ビジネス上の難しい課題を投げかけられるようになり、厳しくなる一方ですね。貴社の技術や製品は、開発者にとってどんなメリットがあるのでしょうか。 脇本●開発プラットフォームとして、TCCの1つの画面から、「すべて」が繋がる究極の標準化を目指した製品作りを行っています。「すべて」の中身は3つあります。 1つ目は「すべての人」。これはユーザー、マネージャーから現場のコーダーまで、プロジェクトメンバーのすべてをこの1つの画面から繋ぐという意味です。もう少し簡単に言うと、すべての人が同じバージョンで作業していることや、遠隔地開発をスムーズに行うことを保証するということです。プロジェクトのコミュニケーションのベースを提供するということですね。 2つ目は「すべての開発環境」です。すでにTCCがインテグレーションを済ませているJtestなどのツールもありますが、弊社がインテグレーションをしていなくても、使いたいツールをOpen APIで、TCCに引き寄せて使うことができるのです。いろいろなツールの使い方をそれぞれに覚えるというアプローチではなく、TCCのインターフェイスから使うことで、それぞれのツールが一層便利になるという相乗効果が生まれることを目指すものです。 3つ目は「実行環境・実装環境」です。アプリケーションサーバやデータベースサーバの選択は、将来その製品がどうなるか、そのバージョンがサポートされるかなどのリスクを伴うものです。TCCは、こうしたリスクも可能な限り吸収したいと考えています。メジャーな製品はできる限り多くかつ最新のバージョンをサポートしていきます。TCCがサポートする実行環境ならば、ユーザーは安心して使えるようにしようというわけです。つまり、将来のレガシーリスクをわれわれが吸収するのです。 TCCは開発者が個別に使ってももちろん便利ですが、本当に効果的なのは、企業全体で同じ“開発プラットフォーム”というレイヤを採用して、最終的には、実装部分だけではなく設計、ドキュメントからテストの方針まですべてを標準化し、それを関係会社も含めた標準的なアプローチとすることです。
藤村●後藤さんはエンジニアとして、最初にTCCを見たときに、どの点に注目されましたか？
これまで、実際の論理設計をアプリケーションにまで落とし込んだときにどうなるのかという部分にあるギャップが、おざなりになっていました。アーキテクトが論理的な設計だけして、「あとはコーダーがやってくれ」というスタイルで開発を行っていくと、実際にはまともなアプリケーションは作れません。例えば、論理的なクラスを実際のコードに落とすときに、EJBに落ちるのか、通常のJavaクラスへ落ちるのかという選択で、アプリケーションのパフォーマンスは明らかに違いますし、スケーラビリティの有無などの部分で、まったく異なる結果となります。TCCは、コードレベルでのこうした点をきちんと設計できるのが、大きな特徴です。 われわれのコンサルテーションでは、実際にお客様とコードレベルでのレビューを行っていますが、システムをアーキテクチャ的に「こういった形で設計するといいでしょう」とコミュニケーションするときでも、やはり詳細設計のレベルでのコミュニケーションが取れるようにサポートしてくれる製品があると非常に便利です。TCCはこうした面がきちんとできている製品で、最初に見たときは「これは面白い」と評価しました。 藤村●開発サイドには、上流設計からコードレベルの実装を担当する開発者まで存在しており、その中のスキルにもばらつきがあるわけですが、“開発プラットフォーム”アプローチは、全体をうまく繋いでいくことで、トータルの生産性を高めていくという考え方なのですね。 脇本●優秀な人は、本来あまりツールを必要としていません。ひらめき型の天才は、きっとツールが嫌いでしょう（笑）。しかし、大規模プロジェクトを遂行する場合はツールのサポートが必要です。たとえば平均的な開発者のレベルをこのようなプラットフォームによって底上げしていくことが重要となります。それが全体としての生産性向上に繋がるのです。TCCでは、難しい技術をより簡単に使うための機能やデザインパターンの適用、品質管理のための様々な機能を提供してるうえに、実はここが重要なのですが、習得のためのハードルもきわめて低くなっています。
藤村●設計からコーティング、配備、そしてそれを反復して次の開発プロセスへというサイクルを一貫してサポートし、社内のいろいろな役割の人々との繋がりの中で、標準的な仕事が行えるようになる──そしてそれが企業のビジネスプロセスそのものになっていくというイメージでしょうか？ 脇本●そのとおりです。今のシステム開発の現場は、紺屋の白袴状態ではないかと思いますね。たとえばシステムインテグレータの方々にうかがってみたいですね。メーカーや金融業界などの顧客に対して、「BPR（Business Process Re-engineering）が必要です」「eCRM（e-Customer Relationship Management）を推進しましょう」と提案されていますが、自社のソフトウェア開発のプロセスは整備されているでしょうか？ 冒頭にも申し上げましたが、経営に関わる方々とソフトウェア開発の現場とが乖離しているケースが多いのです。ソフトウェア開発にかかわるマネジメント層にとって必要なのは、もちろん個別の技術に詳しくなることではなく、例えば生産を開始する前にきちんとした生産ラインを整備するといった、過去にほかの産業で検証されているアプローチを意識することではないかと思います。開発プラットフォームというレイヤをうまく利用することで、ソフトウェアの生産ラインを整備していただき、効率をあげていく、というアプローチをぜひ検討していただきたいのです。 後藤●それと開発現場では、やはりいざとなれば頭数を揃えて、力で開発を行ってしまうところがあります。無理が通ってしまうところがIT業界の中に残っているような気がしますね。根性主義的なその場しのぎではなく、経営手法ときちんと繋がったサイクルとしての開発体制が必要なのではないでしょうか？
藤村●今後、ますます標準化されたプラットフォームが注目を集めていくと思います。「翼システム カンファレンス2002」デベロップメントトラックでのセッションでは、発表を控えたTogether ControlCenter 6.0を見せていただけるのですね。 後藤●バージョン6.0になって最も拡張された機能は、GUIビルダーという部分です。GUIのSwingやAppletなどのサポートといったいままでのTCCにはなかった機能が追加されました。また、リファクタリング機能をかなり改善したほか、チェックイン・チェックアウトの新しいライセンス体系や、Webサービスへの対応を行っています。もちろん、いままでのTCCの大きな骨格であるライブソースの考え方や設計から実装まで一貫してサポートする点に変わりありません。
藤村●最近UML（Unified Modeling Language）やRUP（Rational Unified Process）のような手法が出てきて、モデル中心の開発にスポットがあたるようになってきました。そこに寄与するのが、それらをサポートするコンテンツやツールですし、一方でフレームワークやコンポーネントをうまく活用していくような仕組みだと思います。プラットフォームとしての統合化、標準化というアプローチと、モデル重視やコンポーネント活用とは異なるアプローチだと思うのですが、それぞれどのような関係だと整理できますか？ 後藤●開発者が目指しているのは、いかに速く、そしてラクにアプリケーションを作るか──ということです。フレームワークの中心は実行環境であって、そのフレームワークに適合したコンポーネントを追加したり、組み合わせたりして、システムを構築して行くことにより、「速く、ラクな開発」を実現しているわけです。TCCでは、こういった各種フレームワークに適合したコンポーネントの構築や、メンテナンスをサポートする機能を簡単に作り込むことができます。つまり、TCCはフレームワークを補完する位置づけのプラットフォームとして使うことができるのです。 いってみれば、開発環境の部分と運用時のサポートの部分という関係ですね。フレームワークは型で、その中で動くコンポーネントを作らなければなりません。そのコンポーネントを作るために、ジェネレータのようなものを各フレームワークのベンダが提供しています。しかし、こういったジェネレータは、基本的には一方向のものがほとんどで、出来上がったJavaのコードをメンテナンスする場合には、通常のエディタやIDEツールを使用する場合が一般的だと思います。TCCでは、そういったコードジェネレーションの機能や、コードのメンテナンス機能を作り込むことができます。TCCを使用して、そういった機能の作り込みを行えば、フレームワーク・ベンダ側は、わざわざ開発環境を提供する必要がなくなります。 こういった機能をTCC上で実装することは、実際にフレームワークを使ってシステムを構築されている方々にも、非常にメリットがあると思います。フレームワークを使用してシステムを構築する場合、定型的で単純な作業が非常に多くなるわけですが、そういった作業自体をTCCに行わせることができるからです。 藤村●カンファレンスを主催する翼システム様とはどのようなコラボレーションが可能ですか？ 後藤●いま、翼システム様は、同社のプロダクトを使用する場合の使用方法を、コードテンプレートのような“サンプル”として提供されています。ユーザーはそれを見ながら自分のコードを書いていくというアプローチが可能なのですが、この“サンプル”を、TCCにテンプレートとして登録しておくと、パターンでパラメータを渡せば、そのコードが自動生成されます。TCCを使うことで翼システム様のプロダクトを使用する際に、非常に効率的にJavaのコードを作成できるようになります。 脇本●われわれが考えている開発プロセスは、翼システム様のソリューションを支えることができると信じております。 藤村●パターン化を前提にして、翼システム様が提供されるSVFなどをコンポーネントとして、上流から開発プロセスの中に取り込んでいくことができるということですね。セッションを楽しみにしています。本日はありがとうございました。
|
|
