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

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

第5回 クライアントのためのUMLモデリング 〜灰皿のよけ方〜

　プロジェクトがよじれずにきちんと進んでいくためには、プロジェクトマネージャ（以下プロマネ）のリーダーシップはプロジェクトの内外において極めて重要である。特にクライアントの要求をきちんと把握している、すなわちシステムの全貌がプロマネの手の内にある状態になると、そこから先はスムーズにいく。プロジェクトがよじれてクライアントから灰皿を投げられないようにするには、要求分析をきちんとやるためのUMLによるモデリングが効果的である。

　本稿では要求仕様を定義するスキルに焦点を絞りたい。UMLを使ったモデラーにあこがれる諸兄も多々いらっしゃるようだが、きれい事では済まない。実はプロマネと同じスキルセットが必要である……。

■仕様が変わるリスクを最小限に

　開発をしていて何がつらいかというと、開発中にクライアントからの要求仕様がコロコロ変わることである。クライアントはビジネス中心でモノを考えているが、一方で開発側のコンピュータは完璧な仕様を要求する。クライアントからすると「思いは伝えた。後はよきに計らってほしい」ところだが、途中で開発側の話を聞くとどうやら全然違うシステムになりそうである。「分かりました」といっていたのに、どうして伝わらないのか？ 「いった・いわない」問題が続き、結局涙を飲んで妥協をし、開発側は修羅場を経験することになる。短気なクライアントにはロジックが通用しないため、時々開発側に灰皿が飛んできたり（？）する。灰皿をよけるには反射神経だけでは不十分である（だいたいうまく避けるとさらに怒られる）。そもそも灰皿が飛んでこないようにする努力が必要である。

　要求仕様を明確に定義することは、プロジェクト立ち上げ期の命運を左右する。もちろんプロジェクトの途中でも外部要因などにより仕様変更は避けられないが、最も重要なのは仕様定義の過程でクライアントとの信頼関係を結ぶことである。信頼できるパートナーであることが分かれば、クライアントもむちゃなことはいわなくなる。クライアントとプロマネが同じ価値とゴールを共有できるようになると、プロマネ側もクライアントの事情が分かってくるため、逆に積極的に正しい仕様変更を提案できるようになる。

　では、どうすればクライアントの心も仕様もつかめるのか？ UMLを使うとちゃんと仕様が決まるのか？ UMLオタクがいればプロジェクトが成功するのか？ 実は優秀なモデラーは、優秀なプロマネとスキルセットが重なっている。クライアントとのコミュニケーション力や物事をまとめていく力、リーダーシップなど、そのままプロマネとして従事できるレベルでないと優秀なモデラーではない。単なるモデリングオタクは飛んでくる灰皿の的になりかねない。また開発側からの不満も下手なモデラーに集中してしまう。

　クライアント要求を満たさないソフトウェアは、どんなに先端の技術を使っていても、たとえUMLで「美しい」モデルを作っても、短納期で提供できても、まったく意味がない。クライアントのニーズを正しく反映し、満足を得ることこそがソフトウェア開発の目的であることをいま一度肝に銘じたい。

■「使えるUMLモデラー」はプロマネとしても優秀

　とあるクライアントから愚痴を聞いた。「最近モデリングでシステム構築をやってみたんだが、開発がうまくいかず結局失敗した」。よくよく聞いてみると、いわゆるプロマネのスキルを持った人間がおらず、プロジェクトとしては単にモデリングをずっとやっていただけらしい。モデリングの人は、UML使いとしては優秀だったのだろうが、ひたすらユースケースを書いていただけでは結局自己満足にすぎない。

　要求定義自体にもいろいろなレベルがあるが、Javaコードが1行1行思い浮かぶくらいまで細分化しても意味がない。それよりもクライアント要求を確実に引き出し、大幅な手戻りがない状態に持ってこないと、ソフトウェア開発にはつながらないのである。

　有効なモデリングとは、クライアントの意図を上手に引き出し、かつ適度なレベルで仕様を限定し、開発につなげることである。クライアントの意図を上手に引き出すためには、かなり上級のヒアリングテクニックが必要となる。もちろんコミュニケーション力も大切である。ヒアリングのセッションにおいては、議論が拡散しすぎないようにうまく調整する議長としてのまとめ役も兼ねることになる。また要求仕様が膨らみすぎる場合は、適度にスケジュール調整したりして、自然と機能を優先順位付けして適切な開発範囲に収めるような誘導力も求められる。

　クライアントの要求を正しく理解し、ほかの人に分かるようにUMLで表記していくスキルは、プロマネそのものにまさに必要とされる資質である。もちろん開発リーダーたるプロマネとモデラーとは自己実現の目標が違うだろう。しかしプロマネすらできないモデラーは、クライアントにろくな価値も提供できないのは前述の事例のとおりである。きちんとプロジェクトを統括してきた実績を背負っているモデラーこそ、クライアントから評価されるリーダーとなり得る。

■「なんちゃってコンサルティング」の排除

　クライアントの要求分析をしようとしても、クライアント側で何をやりたいかがはっきり固まってない場合も多い。必然的に開発側から必要な機能やビジネスアイデアを提案しながら、仕様を決めていくことになる。新しいアイデアを形にしていくには、発想力と構想力、問題分析力と解決力が求められる。いわゆる「ビジネスコンサルティング」のスキルが必要である。

　誤解してはならないのは、ビジネスシステム構築を視野に入れている場合の要求定義には、いわゆる戦略コンサルティング力だけでは足りないということである。われわれはコンサルティングの結果を紙で提出すれば終わりではない。そこから先、実際にビジネスシステムとしてきちんと仕上げないとクライアントからは認められないのである。ひどいコンサルタントになると、業務のことを一切知らないのに平気な顔で（恐らく背中に汗をかいているだろうが）現実とかけ離れた内容を提案してくる。「なんちゃってコンサルティング」の登場である。これではまともな要求仕様となるわけがない。戦略シナリオから実際のビジネスとそれを支えるITの機能仕様を具体化する作業、これが最も大変であり、かつ現実的でなければならない。

　実はさまざまな業種別に、ビジネス要求を定義する方法論がすでに存在している。ERPやSCM、EコマースやCRMなどのビジネスプロセスをシステマティックに定義し、UMLなどのモデリングされた仕様につないでいく一連の方法論が今後は注目を浴びるだろう。業界知識が豊富な一流のコンサルタントによる一流のシステム構築こそがクライアントに真の満足を届けられる。

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