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

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

第3回 Javaコードでモノを考えないことの大切さ

　前回「Java時代の開発方法論を考える」では、新しい開発方法論の必要性について触れた。よく「設計にきちんと時間をかけることが大事」といわれる。ところが、設計にきちんと時間をかけたはずのシステムでもプログラムコードに落として稼働させるまでには大きなギャップがある。いままではそのギャップ埋めをプログラマーが血みどろになってやってきた。本稿では、仕様を正しく理解してJavaコードとして実装するまでの開発工程を見直してみたい。

■仕様書とプログラムコードのギャップ

　きちんとした仕様書は、クライアントのビジネスの生命線である。新しいビジネスを考えたとしても、それを正しく他人に伝わるように表現できなければ、システム化はおろかビジネスそのものの実現も怪しい。みんなの頭の中にあるアイデアをどう表現したらシステムのイメージがつかみやすくなるのだろうか？ クライアントのアイデアを書いたはずのRFP（Request for Proposal）やシステム仕様書がどれほど分かりにくいか、皆さんも十分以上に経験されていることと思う。

　例えばインターネットショッピングサイトをやりたいと考えているクライアントがいたとする。ところがそのヒトが書いた仕様書がよく分からない。どうするか？ もちろんクライアントとミーティングして、いったい何がやりたいのか、本当はどうしたいのか、細かいところはどんなものなのかを聞きに行くはずである。何となく分かった段階で取りあえず概要設計書みたいなモノを作ったりして、ますます分かった気になってみる。続いてちょっと機能別に考えて、顧客管理とか受注処理とかセキュリティとか決済処理とかに分けてみる。うん、ここまできたらコーディング勝負！ いきなりJavaツールと格闘を始めるわけである。ところがクライアントの要件はあいまいだったり間違っていたり、気が変わったりする。突然、新規機能として物流も入れたくなる。さて、顧客管理はいじらなきゃいけないし、テーブル属性は追加しないといけないし、受注処理も変えなければならない。あらためてプログラムのソースを見てみると、とてもとても汚いし、どこに何を追加するんだっけ……？ この繰り返しになるわけである。

　変更を前提としてきっちりクライアントの仕様を反映したシステムを作るためには、クライアントの頭の中にある仕様、これをスムーズにプログラムコードに落とす過程が大切である。プログラムコードとニラメッコして仕様書と付き合わせて合っているか検証しようとしても、どだい無理な話である。スーパープログラマーが仕様書からいきなり遮二無二コーディングしても、仕様そのものの変化が激しい時代では危険が大きい。いきなりコーディングする文化は、幼稚園児のサッカーに似ている。1つのボールが飛んでいった方向に全員でワァッと走り、ボールが何かにぶつかって別の方向にいくとまた全員でワァッと追いかける、あの構図である。子どものサッカーなら見ていてほほ笑ましいが、システム化プロジェクトで同じように変更に追従していては工数も膨らむ一方だし納期にも間に合わない。何より優秀な技術者が疲弊してしまう。

　仕様から実装をいきなりJavaのプログラムコードで考えるのはもうやめよう。プログラムコードを眺めながら仕様変更に思いをはせるのは、下半身でモノを考えるようなものである。

■Javaによるオブジェクト指向開発のだいご味

　仕様策定から分析・設計・実装のあらゆる段階でミスや変更は発生する。問題なのは、ミスや変更によるズレなどの大半が、プロジェクト後半の実装段階になって初めて発覚することである。動いているプログラムを見て初めてクライアントは「これは違う」と怒鳴り込んでくる。性能や技術的課題は実装してみないと分からない。また開発を始めてみないと全体のボリュームなんて想定できない場合もある。動くものを見ないとクライアントのニーズに合っているか判断できないし、ましてや仕様自体がどんどん変わっていく。このような「不確定さを前提とした開発」には、オブジェクト指向を用いた繰り返し型の開発が極めて有効である。ミクロなレベルでの分析・設計・実装・テスト、そして評価を１つのサイクルとし、複数回サイクルを繰り返してリリースする方法である。サイクルを繰り返すことで、本来なら最後の方にならないと分からないさまざまなリスクを初期の段階で消しておくことができる。

　繰り返し型開発で大切なのは、仕様書がきちんと要求分析のインプットになり、要求分析のアウトプットが設計のインプットになり、さらに設計のアウトプットが確実にJavaのプログラムコードにマッピングされるという一連の流れが確立しており、しかも相互に対応が付いていることである。オブジェクト指向のだいご味は、例えば「顧客」というオブジェクトは分析段階だろうが設計段階だろうが実装段階だろうが同じオブジェクトとして認識されることにある。もちろんJavaならClassとして実装される。同じオブジェクトのことをいっているのだから、実装から次の繰り返しサイクルのための分析に簡単に移ることもできるし、「顧客」の仕様が変わった場合でも対応ができるのである。以上のような開発プロセスが確立すると、Javaを利用した開発がうんと楽になる。

■上手なモデリングは将棋の定跡勝ちパターンを生む

　Javaのプログラムコードでモノを考えないようにする場合、一体どうやってジックリ仕様や実装について時間をかけて考えるのだろうか？ 答えはモデリングである。クライアントの要求仕様をいったん抽象化して整理するのである。分析や実装のモデルが上手にできていると、極めて楽に開発できるうえにクライアントの要求とのギャップも少ない。仕様を分析し、実装するモデルを作る作業こそ、十分な時間をかけるべき「思考」に相当する。あとは開発プロセスに任せて、粛々と実装していけばよい。

　モデリングするという作業は、例えば将棋で盤上の駒の配置を眺め整理するようなものだ。一方、Javaのプログラミング作業は、駒自体を作ることに相当する。将棋では、まず駒の並びをじっくり眺め考えることに時間を使うのが大切で、駒をいきなり作っても仕方がない。きれいに駒を並べていくと、「あ、これはどこかで見たことがある」という定跡の勝ちパターンになる場合がある。これがデザインパターンなどといわれるものだ。こうなればしめたもので、以前似たようなシステムを作ったことがあるわけだから、確信を持って実装できる。もちろん、駒の意味は100%クライアントも理解できる。

　「上手な」モデリングは、分かりやすいし見た目もきれいである。モデリングにはUMLがよく使われる。例えばインターネットでの書籍の注文のモデルを書いてみると以下のようになる。UMLの詳細は割愛するが、本稿でのポイントは上手にモデリングすることに時間を使え、ということである。本質を見抜いていないモデルは、分かりにくいし表現もあいまいであり、開発も楽にならない。逆に上手なモデルを使うと、実装段階を待たずともシステムの仕様をクライアントに正確に伝えられるし、オブジェクト化がきちんとできているため開発の効率も高い。しっかりしたモデリングと開発プロセスの整備がそろって初めて、Javaでの生産性向上の話が現実のものになる。

インターネットでの書籍の注文モデルをUMLで表現した例（クリックすると拡大します）

　よくUMLを使うだけで満足してしまい、モデリングそのものの「上手さ」に配慮しないヒトがいる。たとえUMLを使っていても、表現があいまいだったり実装と分析が混じっていたりしたらモデリングそのものをやっている価値がない。クライアントとのコミュニケーションを正確に行い、次の開発ステップにつなげられる「上手なモデリング」こそ、開発の至宝である。Javaのプログラムコードを見ながら仕様を考えるのではなく、「上手なモデリング」でクライアントと会話するように心がけよう。

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メールマガジン　新着情報やスタッフのコラムがメールで届きます（無料）