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

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

第１回 やっつけインテグレーションに成功はない

　IT革命、企業革命が進むにつれ、ますますJavaやインターネット関連の技術者が切望されるようになってきている。本当に大規模なシステムにもJava技術が当然のように導入され、Java技術者の腕の見せどころはますます増えてきている。しかし、まったく報われない悲痛なプロジェクトが多数を占めているのも確かである。第1回では、特に大規模なプロジェクトにおいてなぜ火を噴いてしまうのか、Java技術者として目指すべき方向は何か、について論じたい。具体的なプロジェクト体制の組み方、開発方法論、フレームワークなどについては第2回以降に詳しく解説する。

■Java技術者たちの悲痛な叫び

　いま、優秀なJava技術者こそが最も求められている。優秀であればこそ、大きな仕事も任されるし、やりがいも貢献もプレッシャーも大きい。しかし、実際にプロジェクトが始まってしまうと、どんなJava技術者であれ本来の夢や希望はそっちのけで、しゃにむに血みどろのシステム開発に追われてしまうことになる。これではCOBOLやCで一生懸命プログラミングをしていた時代と一緒ではないか。だいたい大規模なプロジェクトで皆が一様に叫ぶ単語は決まっている。

• 徹夜に次ぐ徹夜は、もう嫌だ！
  
• お願いだから仕様は変えないで！
  
• 時間がない、時間が。
  
• 始めるときから感じていたが、やはり納期1カ月前に破たんした。
  
• ほかに優秀なヒトはいないのか？
  
• クライアントは、自分がやりたいことを分かってない。
  
• そもそも何のためのシステムだったっけ？

　Javaの使いやすさ、生産性の高さ（そう聞いていたが……）、スマートさはすべてどこかへ消えてしまっている。単なる従来型のシステムインテグレーションにJavaという技術を適用しただけでは、当然のごとく何の進歩もないわけである。筆者のまわりでも、いまだに「COBOLで何千本も稼働しているシステムをJavaへ移植しているんだが、泥沼だ。助けてくれ」「J2EEで開発しているんだが、結局100人体制を取ってそれでもまだ間に合わない」という話を聞く。インターネット系のサイトを、JavaやXMLなどの新しい技術を使って構築するのはよいが、古いやり方の「やっつけインテグレーション」が前提では血みどろになるのは火を見るより明らかである。

　どこかでだれかが「Javaは使いやすいし、生産性も良い」とかいっていた気がする。しかし本当に生産性を向上させるには、いままでのウォーターフォール型の開発では駄目なのである。またプロジェクト全体のコーディネートの仕方、クライアントの要求の受け止め方など、古いやり方をそのまま適用したら通用しないことが多々あるのである。これに気付かずに「さぁJavaで開発しよう」とやると、単なるC言語での開発と何ら変わらない憂き目に遭うのである。

■何がいままでと違うのか

　どうしたらよいかは次回以降の連載に譲るとして、今回は、なぜ開発に手間取るのかを分析したい。従来の「やっつけインテグレーション」ではどうして血みどろになってしまうのか、どういうスキルが今後必要とされているのか、優秀なJava技術者の方々に考えていただく機会としたい。

(1) どうしてクライアントの仕様は頻繁に変わるのか？

　インターネットシステムは、ころころ仕様が変わる。システム稼働直前であってもまだ仕様が確定していなかったり、不確定要素がある場合が多い。クライアント自身も明確に仕様を確定できないのである。ビジネス環境も変化するし、競合他社の状況もあるし、なんといってもやったことのないビジネスをシステム化する場合がほとんどであるため、クライアント自身が「正直、どうしたらいいか分からない」のである。

　こういう状況に対して、クライアントから見て最も「しょうもない」対応をする技術者は、「早く要件を決めてくれないと間に合いません。これで絶対変わらないですね」という発言をする。開発側からすれば自己防衛のための発言であるが、こういわれてうれしいクライアントはいない。クライアントにしてみれば、要求の変化に追従できない開発をしている技術者こそが間違っているのである。従来のウォーターフォール型の開発（まず仕様を確定して、詳細設計、モジュール設計、コーディング、テストと進めるやり方）では、仕様が変わった場合の手戻りが大きすぎる。

　これからは、仕様が変わることを前提とした開発手法が重要になる。またクライアントの仕様を一緒になって確定していけるスキル、特にビジネス全体像からシステム化をきっちり支援できる技術スキルが大切である。単なるJava技術者ではこれからはプログラマーの歯車に入れられてしまうだけである。また、クライアントのシステム化要件のモデリングをきっちりやらず、単にEJBだとオブジェクト指向だから生産性が高いとかいっていても机上の空論にすぎない。しっかりした設計図が書けなければ変化に強いシステムもできないし、ましてや生産性なんてものとは無縁の血みどろインテグレーションになっていくだけである。これからはオブジェクトモデリングの技術が一層重要になってくる。

(2) どうしてシステムは大規模になっていくのか？

　インターネットシステムも、大規模にさえならなければ「楽勝」の開発である。アーキテクチャやスケーラビリティや信頼性などは考慮せず、とにかく作ってしまえばいい。しかし不幸なことに、うまくいくサイトは必ずトランザクションやアクセス量が多い。考えてみれば当然で、どんなビジネスモデルであれ、ある程度のシェアやアクセス（例えば会員数50万人とか、200万ページビューとか）を確保できるようになることが前提であるからである。

　もしだんだん大きくなっていくようなシステムを構築するのであれば、当然ながらやっつけ仕事では駄目である。取りあえずいい加減なアーキテクチャで構築したために、うまくいき出すとだんだんシステムが持たなくなったりダウンしたりして破たんしていくサイトがなんと多いことか。クライアントにしても、途中でアーキテクチャを全面変更するような膨大なリスクとコストは歓迎しない。クライアントのことを真剣に考えればこそ、当初からスケーラビリティなどの要素を考慮したアーキテクチャにしておく。特にJava技術を適用するサイトは、前提としてCGIなどよりも早くて楽というイメージが先行している。しっかり実証してあげることこそが技術者のプライドである。

(3) なぜ開発期間はこんなに短いのか？

　開発期間は短い！ 時間は取り戻せないため、これだけは肝に銘じなければならない。クライアントにとってはメガコンペティションが起きている不安定な世の中を常に勝ち抜いていかねばならないわけであり、スピードは最も重要な競争要素の１つである。常に他社より先行している・先行できるということは競争優位にたてるということにほかならない。
　開発期間が短く「なってしまう」要因は、開発側にもある。インターネットシステムの場合、前述のとおり仕様の確定にかなり時間がかかってしまうことが多い。またデータセンターの手配とか、あるいはブランディングのための広報活動とか、アライアンスパートナーとの調整とか、単なる開発以外の膨大な作業が待っている。これを知らずに思いつくままやると、必然的にプロジェクト全体のスケジュールが圧迫されるわけである。特に自社だけでは提供できない部分が多々あるため、調整の時間などについては十分余裕をみた線表が必要である。優秀なJava技術者は、不幸なことにこれらのもろもろの雑用を押し付けられる場合が多々ある。最初に全体作業を見通せる経験と見識が求められているのである。

(4) 結局、なぜ血みどろになっていくのか？

　不確定で気まぐれなクライアントの要件、迫りくる納期、厳しい技術的課題などさまざまなプレッシャーの中、最終的には大規模なプロジェクトであってもソフトランディングさせなければならない。だいたい納期が遅れそうになってくると、素人でもいいからそこらへんの技術者を無意味に投入するシステムインテグレータが多い。優秀な技術者からすると、素人をいくらあてがわれても困るわけで、それよりはきっちり分かっている優秀な人材が欲しいのである。すなわち、オブジェクト指向設計にしろ、大規模アーキテクチャ設計にしろ、プロジェクトマネジメントにしろ、きっちり分かった経験者が少数精鋭でリードしていくのが、これからのプロジェクトである。労働集約的な人海戦術で乗り切れる部分は、恐らく今後はインドや中国といったオフショア開発の部隊にアウトソースされていくだろう。

　プロジェクトマネジメントの具体論については次回以降に譲るが、血みどろになっていく原因の大多数は、プロジェクトの最初の段階でリスクを膨大に積み残していることである。結局最後の方になって問題が噴出し、結局納期1カ月前になって破たんが露呈する、というパターンが典型である。プロジェクト初期の段階でリスクを洗い出し、極力最初のうちにリスク低減策を実施するのが、クライアントにとっても自分たちが血を流さないためにも、大変重要なスキルになる。特に、開発ボリュームの見積もりの甘さや、内外要因によるプロジェクトのリスクの見極めの甘さなどが、後で致命傷となってくる。

■Java技術者よ、立ち上がれ！

　いかがだったろうか？ 共感していただける部分が多ければ幸いである。いま、Java技術者に対して求められているのは、Javaに対する深い技術的な洞察だけでなく、さらに一歩高みにたった、経験とクライアントに対する想い、プロジェクト全体への気配り、実際にリードしていける行動力である。とかく「やっつけインテグレーション」になりそうな開発に対して自分で工夫して血みどろにならないようにするのは、クライアントのためでもあり、何より自分自身を守るためであると確信している。

　第2回以降の連載では、実際のプロジェクトにおける成功要因となったポイントについて具体的にいくつか論じていきたい。

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