連載 「プロジェクト成功のキーポイント」 ――成功するECサイト構築―― 漆原茂 ウルシステムズ株式会社 代表取締役社長 2001/8/25

本連載では、先進的な取り組みで数々のJavaプロジェクトを成功させているウルシステムズのスタッフに、Java技術や周辺テクノロジといった各技術論ではなく、プロジェクトを成功へと導くためにどのように先端技術を使っていくか、というトップダウンの視点でトピックをとりあげていただく。開発方法論やプロジェクトマネジメント、システムのアーキテクチャデザイン等、これからのシステムインテグレータや技術者、ユーザー、コンサルタントの方々への参考にしてほしい。（編集局）

第2回 Java時代の開発方法論を考える

　前回「やっつけインテグレーションに成功はない」では、いくら優秀なJava技術者であっても「やっつけインテグレーション」では結局は血みどろのシステムインテグレーションを繰り返すことにしかならないことを指摘させていただいた。新しい技術を使っても、やり方が古ければ元のもくあみである。しかも技術はどんどん進化し続けている。相変わらずクライアントの要件は不透明なままである。しかも個別技術要素が変化あるいは陳腐化しても追従できる、そういう開発方法はないものか？

　本稿ではまずシステムの開発方法にフォーカスし、新しい開発方法論の必要性と利点について触れ、読者各位のご意見を賜る機会としたい。

■EJB開発ブームの反省

　ちょっと前までは（まさかいまでも？）EJBが全盛のように語られていたが、どうやらようやく一部のヒトはEJBコンポーネントだけではちっとも仕事が楽にならないことに気付いたようだ。そもそも開発をするうえでオブジェクト技術を「うまく」使うと楽になる、その意味でJavaでの実装の一部がEJBだったはずだが、いつの間にか「EJBを使うと生産性が良い開発ができる。EJBコンポーネントもたくさんあるようだし……」という話にすり替わっている。過熱気味だったEJBブームを反省してみたい。

　EJBを使うかどうかは、ソフトウェアの生産性向上の本質ではない。コンポーネント技術が生きるのは、その前提としてきちっとしたモデリングができている事実がなければならない。だいたい他人が作った部品を何千個もそろえて、そもそも使いこなせるのだろうか。まず自社内での生産性が確保できていないところへ、新たに何千もの部品を加えても混乱が増すだけである。生産性というものを考慮しない古いやり方のまま、単にオプションが増えても開発効率は上がらないのである。

　J2EE技術での実装にもさまざまなオプションがある。例えば受注処理1つを取ってみても、Servlet+JDBCで開発することもできるし、EntityBeanを使ってラッピングしながら開発することもできる。Javaの世界のMVCモデルといっても、J2EEの使い方を決めておかないと実装がばらつく。生産性を確保し皆が一様のコーディングをできるようにするにはJ2EEの上位に何らかのルールを規定する必要がある。これがいわゆる「フレームワーク」と呼ばれるものである。

　いま現在、ある意味フレームワークブームといっても過言ではないかもしれない。一言で「フレームワーク」というと何でも該当するため、生産性や開発方法論とは無縁の、単なる独自のアプリケーションプラットフォームもフレームワークと呼んでいる場合もあるようだ。一部のクライアントからは「EJBベースのフレームワークとかがまったく使い物にならずにすべて自前でやり直したため、ひどい目に遭った」という声も聞こえてくる。結局はセミカスタムの独自パッケージのような形でしか使い道がなく、強引にシステムにボトムアップで適用しようとするとひどい目に遭うのである。

　EJBやフレームワークだけなく、これからWebサービスなどの新しいテクノロジが本格的に実用化され始める。いままでEJBなどで作ったモノはどうすればいいのだろうか？「これからはコンポーネントだ」と確信していたにもかかわらず、それに追い付く前に（テクノロジは）ドンドン先へ行ってしまう……。ソフトウェアの生産性とは、EJBなどの個別技術によらない次元の話なのである。

　では、そもそも何をやりたかったのか？ 血みどろのインテグレーションをやめたかったのではなかったか？ 個別の要素技術がすべてを楽にしてくれるかもという甘い期待は案の定裏切られた。そもそも開発のやり方を変えないと、本質は変わらないのである。

■新しい開発方法論

　それではどういう開発方法が正しいのか？ ほとんどの方が、従来のウォーターフォール型の開発でJavaを利用している。これでは確かに血みどろになっても致し方ない。本稿では筆者の経験から、Java技術者としてスマートにシステムを開発していくために必要ないくつかのポイントと例を挙げてみたい。これらは、単なるプログラミングテクニックだけでは済まない、さまざまな別の視点をプログラマーへ与えてくれる。

(1)ビジネス要件からシステム開発まで一貫したプロセス

　これからの開発でポイントとなるのは、システム化の内容がクライアントのビジネス要件と密接にリンクしている、ということである。いまさらながら、ビジネス要件が変わったらシステム内容も変わり、開発内容も変化せざるを得ない。このような環境下できっちりとシステムを仕上げていくためには、ビジネスのモデリングのフェーズから一貫して開発に落とし込んでいく過程が開発に必須となる。いままでのように、クライアントからのRFP（Request for Proposal）を待っていたのではいけないのである。ビジネスの要件がまだ固まっていないときの最初のヒアリングから開発プロセスは始まっている。

(2)リスク管理とフレームワークの利用

　血みどろの開発になるのは、気まぐれな要件に振り回されつつリスクが大きいばらついたプログラミングをしているからである。開発方法の中にリスク管理を盛り込んでおけば、必然的にリスクを下げつつプロジェクトを進めていくことになる。さまざまなリスクをはっきりさせないまま（リスクを下げないまま）開発を進めていくと、納期の1カ月くらい前になって確実に破たんして危険プロジェクトに突入してしまう。プロジェクト初期段階で確実にリスクを洗い出し、先に重要リスクを低減させることにより、開発はだいぶ楽になる。

　さらにプログラマー固有のクセやばらつきを極力なくすために、ソフトウェアフレームワークを規定するのも効果がある。前述のとおり、J2EEだけでは実装のオプションが広すぎるのである。ある程度だれがやっても同じようなコーディングになるようにJ2EEの使い方の枠組みとルールを規定しておくと効果が高い。

(3)オブジェクト指向によるイテレーションモデル

　繰り返しになるが、概要設計→詳細設計→モジュール設計→プログラミング→デバッグというウォーターフォール型では、クライアントからの仕様変更を吸収する柔軟性に欠ける。仕様が変わったときの影響範囲の特定方法や差分の開発を、あらかじめ開発方法に入れ込んでおく必要がある。

　筆者のウルシステムズではRUP（Rational Unified Process）をベースに、インターネットシステム向けにカスタマイズした開発方法論を確立している。プログラミングフェーズではイテレーションを繰り返し、スパイラル的に開発していく方法を採用している。これによりウォーターフォール型と異なり、途中でクライアントからの仕様変更を柔軟に吸収できるようになる。通常、開発期間が3カ月程度あれば、2〜3回のイテレーションを回し、要求変更に対応している。

(4)品質や性能などをあらかじめ盛り込む

　ソフトウェアの品質や性能を後から追求するのは無理がある。納期の１カ月前くらいの総合テストで品質がボロボロ、性能テストをやると遅くて使い物にならない、というケースをよく耳にする。品質や性能は積み重ねであり、開発の途中フェーズでしっかりと確認しておく必要がある。

(5)グローバルスタンダードベース

　どんな開発方法といえども、必ずグローバルスタンダードを一貫して採用すべきである。少なくともここしばらくは陳腐化しない技術標準を採用しておかないと、独自パッケージでいままで限界に達していたシステムの二の舞となりかねない。UMLやJ2EEやXMLは最低必須、あとは自分たちの得意なテクノロジを組み合わせて活用していくことになろう。

■すべてはまずみんなのため、自分のため、クライアントのため

　個別技術を論じていても、どうしても「やっつけインテグレーション」を脱却できない。といって、いままでのやり方を変えろといわれても、どうしてもしがらみがあって抜けきれないのが実情だろう。しかしどこにも行けない井戸の底から抜け出すためには、まず目の前のプロジェクトから多少でも考え方を変え、新しいやり方にチャレンジしてみる必要がある。クライアントの成功のためになるのはもちろん、皆さん自身のため、また同僚のために、そもそもどういう開発方法が必要か、ご一考されてはいかがだろうか？

　次回以降の連載では、具体的にウルシステムズで規定した開発方法論とフレームワーク、およびそれを支える技術要素やモデリング技術、フレームワークなどについて述べていく。

Index

第1回 やっつけインテグレーションに成功はない (2001/7/28) 第2回 Java時代の開発方法論を考える (2001/8/25) 第3回 Javaコードでモノを考えない (2001/9/26) 第4回 eビジネスを構築するプロジェクトマネジメント(2001/10/26) 第5回 クライアントのためのUMLモデリング（2002/2/5）

プロフィール

漆原茂（うるしばら しげる） 1965年生まれ。東京大学工学部を卒業後、沖電気工業株式会社に入社。1989年からスタンフォード大学コンピュータシステム研究所に2年間留学。ミドルウェアTUXEDOの日本市場における事業立ち上げ、WebLogic上のEJBコンポーネント開発などの他、大規模エンタープライズシステムの構築を多数手掛ける。2000年7月にウルシステムズ株式会社を設立、代表取締役に就任。 ウルシステムズ株式会社 UMLをベースとした最先端の方法論とフレームワークを駆使し、クライアントの戦略コンサルティングから大規模システムの構築を実施するコンサルティング会社。「常に動く活きたシステム」をアウトプットとして一貫して提供している。大規模かつミッションクリティカルな分野にフォーカスし、UML/J2EE/XMLを用いたグローバルなソリューションを展開している。 メールアドレス：info@ulsystems.co.jp ホームページ：http://www.ulsystems.co.jp/

Java会議室でご意見、ご感想を受付中

＠ITメールマガジン　新着情報やスタッフのコラムがメールで届きます（無料）