UMLが大変にもてはやされている今，開発の現場にも急速な勢いでUMLが浸透しているのだろう…と思うのが自然な発想だ。ところが現実は「今の大騒ぎに比べると，現場の反応はクール」（NTTコムウェア ビジネスイノベーション本部 ビジネス企画部の堂山真一担当部長）。あるシステム開発のコンサルタントも，「今は言葉が先行しているだけ。実際はそれほど使われていない」と語る。「興味があるというレベルでは，確かにUML熱は高い。しかし実際に使っているのは，一部の大手企業に限られる」（UMLによるモデリング・ツールを販売するグレープシティ マーケティングチーム主任の熱海英樹氏）という声もある。

　なかなか実用に至らないのは，UMLを使いこなすまでにさまざまな壁を克服しなければならないからだ。ここでは，10の壁を取り上げる。これらは，大きく3種類に分けられる。オブジェクト指向がもたらす問題，分析や設計などのモデリングの難しさによる問題，そしてUMLそれ自体が持つ性質の問題である。

オブジェクト指向の壁(1)

オブジェクト指向わからずしてUML生かせず

　まず，オブジェクト指向が持つ壁である。元々UMLは，オブジェクト指向開発のさまざまな手法で使われていた図の表記法を統一したものだ。したがってオブジェクト指向とは切っても切れない関係にある。これが原因で，UMLとオブジェクト指向の区別が難しくなり，そのメリットや問題点が混同されることが多い。ただここで明らかなのは，オブジェクト指向がわかっていないとUMLは使いこなせない，ということだ。実際，「オブジェクト」をはじめ，「クラス」「継承」といったオブジェクト指向の基本的な概念や用語を理解していなければ，UMLで書いた図を読むのすら難しい。

図7●データベースを扱う部分をいくつかの個所に分散させたシステム（左）と，一つのオブジェクトにまとめたシステム（右）。
例えばデータベース処理部分に不具合が起こった時，左のシステムだと3カ所を別々に見なければならないが，右のシステムは1カ所で済む。右の方がより独立性が高く，保守も楽になる

　実のところ，UMLを採用するメリットとして語られる「再利用性」や「保守性」の向上は，かなりの部分をオブジェクト指向に負っている。したがってUMLのメリットを生かすには，オブジェクト指向の習得が必要となるのだ。

　オブジェクト指向を採用して再利用性を向上させる方法はいくつかある。中でも有効な方法として知られているのが，ソフトウェアのコンポーネント化だ注4）。システムを機能単位（コンポーネント）に分割して，同じ機能を必要とする別のシステムで再利用する。このテクニックをうまく利用すれば，共通部分を新たに作り直す必要がないので開発効率が上がる。また，そのプログラムは既存のシステムで使われているので，不具合があればすでに改修されている可能性が高い。つまりある程度安定した状態になっている。したがって，システムの品質に対する信頼性も上げられる。

　保守性とは，メンテナンスのしやすさのことである。一度作ったらそれきり改変しなくて済むシステムはごく少ない。通常は運用を続けるうちに，時代の変化に合わせてシステムを変更したり，後から発覚した誤りを修正したりしなければならない。この作業にかかるコストは決して小さくない。このとき，システムがオブジェクトを単位に作られていれば，修正個所がわかりやすい（図7[拡大表示]）。オブジェクト指向の特徴である，各オブジェクトの「独立性」がここで生かされる。

オブジェクト指向の壁(2)

既存のシステム資産の移行が大変

　しかし，オブジェクト指向を現場にうまく浸透させるのは難しい。「既存資産」という第二，第三の壁がここにある。

　まずこれまで開発してきた膨大なシステム資産の存在が足を引っ張る。オブジェクト指向開発を新たに始めるということは，業務の分析の仕方，システム設計の仕方を根本から変えることにほかならない。「オブジェクト指向を始める時には，プロジェクトの人員配分から開発環境まで，すべてがらっと変える必要がある」（オージス総研 eソリューション事業部 オブジェクトテクノロジー・ソリューション部の竹政昭利マネージャ）。別の言い方をすれば，既存のシステムをオブジェクト指向に基づくシステムに移行するのは，一から作り直すのと同じである。システムの提供や既存資産が大きければ，それだけコストがかかってしまう。簡単に踏み切れるものではない。

オブジェクト指向の壁(3)

「発想の転換」が難しい

　一方新規のシステムを開発するときは，既存のシステムを一つの大きなオブジェクトとして取り扱うことができる。だから新規システムの開発からオブジェクト指向技術に取り組むことが多い。だが始めてみると，また壁にぶつかる。技術者自身の既存資産である。オブジェクト指向への「発想の転換」をしなければならないのだ。

　開発の現場では，現在も構造化手法が使われていることが多い。一方，システム開発の案件はJavaなどのプラットフォームが中心である。「今，一番ポピュラーな開発プラットフォームはオブジェクト指向。なのに，開発の状況は従来型だ。これではオブジェクト指向のメリットは生かされない。とてももったいない技術の使い方だ」（豆蔵の羽生田栄一代表取締役社長兼CEO）。実際，オブジェクト指向言語を使っていても，システムの構造はオブジェクト指向になっていないケースも少なくない。オブジェクト指向は考え方なので，覚えるだけではできない。

　構造化手法では，システムを「機能」によって分解する。この考え方に慣れた人にとって，「モノ」を単位にシステムを分解するオブジェクト指向に取り組むことは，システムに対する考え方そのものを変えることを要求される。このため，従来から構造化手法で開発してきた人にとって，オブジェクト指向はとても難しい，と言われる注5）。

　オブジェクト指向的なものの考え方ができないまま開発を始めても，効果は現れにくい。それどころか，「オブジェクト指向やUMLのコンセプトを理解しないままシステムのモデリングや開発を進めると，開発品質は逆に落ちる場合もある注6）」（日本ラショナルソフトウェアのテクニカルコンサルティンググループ/ITチーム ソフトウェアエンジニアリングスペシャリストの平野清美氏）。

　このように“オブジェクト思考”を習得するのは，それほど簡単ではない。UMLのモデリング・ツールの販売や開発のコンサルティングを展開するテクノロジックアートの長瀬嘉秀代表取締役は「オブジェクト指向開発は，コンサルタントを入れなければ絶対に失敗する」とまで言い切る。

オブジェクト指向の壁(4)

スキルがなければ利点は生かせず

図8●部品化がうまくいっている場合（上）と，上手に部品化できなかった場合（下）。
いくらシステム内部を部品化しても，それが再利用しやすいかどうかは別問題だ

　さらに，オブジェクト指向の利点を享受するには，もう一段階の壁を越えなければならない。マイクロソフトのデベロッパー・マーケティング本部 .NETテクノロジー部の萩原正義部長が，「オブジェクト指向の本来の意義は，人間が理解しやすい形でシステムを抽象化できることにある。再利用性や保守性は，後で付け加えられた利点にすぎない。これらの利点を享受するために必要なハードルは高い。だから，技術者のスキルによって個人差が出る」と指摘するように，再利用性や保守性を高めるのは一朝一夕にできないのだ。

　例えば再利用性を上げるために，オブジェクト指向に基づいてシステム設計し，内部をコンポーネント化したとしよう。しかしそのコンポーネントが再利用できるとは限らない。最初に作ったシステムで使えていても，それが他のシステムで使えるかどうかは別の問題だからだ（図8[拡大表示]）。どのようにシステムをコンポーネント化すれば再利用性が高まるかまで考慮しなければならない。

　保守性に関しても同様だ。システムを適切にオブジェクト化できず，巨大な一つのオブジェクトに多くの処理が集中していたら，従来より保守性が上がることはない。仮に分散していても個々のオブジェクトが独立するように分けられていなければやはりダメだ。かえって見るべきポイントが分散し，保守しにくくなる。どのようなオブジェクトを作り，それぞれどのような役割を持たせるかを明確にしなければ，保守性は確保できない。

オブジェクト指向の壁(5)

UMLと開発手法は違うものである

　以上のようなオブジェクト指向開発の壁を乗り越え，開発を成功させるために提案されているのが，さまざまな開発手法である。ただ最近の風潮を見ると，UMLがこれらの開発手法の一つであると誤解され，万能視されているようだ。しかしUMLは万能ではない。というより，UMLそのものを覚えてもシステムはよくならない。

　元々開発方法論自体「万能」ではない。あくまでも開発のガイドラインを示しているにすぎず，考え方そのものではない。開発方法論に従っても，質の悪いシステムはできてしまう。しかもUMLは開発手法ではない。万能性をUMLに求めるのは，二重の誤解である。

　「UMLを知っているだけでは何もできない。これが世の中に知られていないことが一番問題だ」と，テクノロジックアートの長瀬氏は現状を嘆く。UMLが統一したのは図の表記法であり，それをどのように使うかという開発手法ではない。UMLが担うのは，あくまでもモデリングのための道具の役割なのである。これを忘れると，表記法を覚えただけでいいシステム開発ができるように思えるから要注意だ。

（北郷　達郎、八木　玲子）