モデレータ 藤井氏

藤井　まず、参加者（約70人）の中で実際にUMLを使っている人はどのくらいいますか？

細川　半分くらいですか。上々の成績ですね。

藤井　では、細川さんからUMLの最近の動向・傾向をお話いただくことで口火を切っていただきましょう。

細川　UMLは、現在大変なブームになっています。さまざまなところで使われていますね。ところが、どうも話を聞いていると「UMLが使われている局面は千差万別なのではないか」と思い始めてきました。

　1つは、ビジネス・モデリングといった上流工程において、UMLを利用するケースが増えてきていることです。これは、ビジネスを実現しているプロセスと構造をUMLを使ってモデリングするものです。一方で、プログラミングとUMLも非常に緊密な関係にあります。すなわち、プログラムをUMLによってモデル表現することにより、プログラム仕様をシンプルに示すことができるのです。

　UMLが利用される領域は、ビジネス分析からプログラミングに至る非常に広いものであり、それだけに期待されるところが大なのですが、一方ではそれぞれの局面で実際にUMLを使いこなせるかどうかが大きな課題になっているのではないでしょうか。

　では、パネリストの方々は日ごろどういった局面でUMLを使っているのでしょうか。順番にコメントをお願いします。

パネリスト 堂山氏

堂山　私のバックグラウンドは、交換機のソフトウェア開発でした。もう20年も前のことです。当時は電電公社でして、インプリメンテーションのところをどうドキュメントにするか、というのが最重要課題でした。というのも、NEC、日立製作所、富士通、沖電気などの交換機メーカーにインプリメンテーションの部分を分割発注していたからです。そこで、開発の分担をはっきりさせるためのドキュメント作成が非常に重要でした。このような背景があって、当時はモデリング図をたくさん書きました。もちろん、当時は「UML」とはいいませんでしたが、非常によく似た図でした。

　最近いろいろな話を聞いていると、EJBが登場してインプリメンテーションの側面でUML、つまりモデリングを活用しようとしている傾向が強くなってきたと思いますね。

羽生田　豆蔵は、UMLをすべての局面で活用しています。最上流の世界から要求定義、システム分析、設計、実装まで全部です。

　UMLの利点は、自然言語を中心にやっていた部分を、モデリングを活用することでビジュアルに表現し、顧客との間に誤解が生じないようにすることが可能となったことですね。

山岸　私は、まず「業務がどうなっているのか」ということをオブジェクトモデルとしてとらえて、システムに落とし込むことが必要だと実感しています。

　マズいシステムというのは、人のやっていることをそのまま電子化してしまうというIT化です。そうなると、やたら画面数が多くて中身が複雑なシステムになります。しかし、シンプルなほど拡張性は高いのです。そこで、まずはスコープを業務まで広げてモデル化します。視覚化すると業務フローの冗長な部分が見えるので、それをすっきりさせたうえでシステム化の範囲を決めます。「煩雑すぎて結局使われないシステム」ではなく、全体の業務に直結したシステムを構築するのが最優先でしょう。そういう全体のビジネス・プロセスから落ちていく業務をUMLで表現するのが、ウルシステムズのテーマです。

　結論としては、「最上流からできるだけUMLを使いますよ」ということです。

パネリスト 浅海氏 浅海　自分1人でプログラムを書くときはあまり使いませんが、チームで開発する場合には担当者にクラス図とシーケンス図を書いてもらってレビューします。これを書いてもらえば、担当者がシステムの構造を理解しているか、解決に必要な技術を持っているのかといったことが判断できますから。つまり、開発現場のコミュニケーション・ツールとして使用しています。 　プログラムというのはフォームが大事で、きれいなフォームができれば後は暗算でもいいのですよ。逆に、最初にフォームがめちゃくちゃだと、プログラムは書けないですよね。そういう意味では、これからオブジェクト指向を始める方は、最初はUMLをきちんと書いた方がいいですね。

細川　UMLというのは多様に使われていて、かつ多様な効果を持っているのではないか。この仮説を前提として、「本当にUMLは役に立つのか？」という疑問に注目してみましょう。UMLは、ビジネスを考えるとき、またはプログラミングを考えるときに、思考の道具として有効なのでしょうか。

山岸　思考の道具というかといえば、そのように利用していると思います。モデリングしている人を横から見ていると、将棋を指しているときの表情とよく似ています。「このクラスをここに置いて」とか。全体との関係を読みながら、一手ずつ置いていくあたり、視覚的に表現されていることで思考が深まっているのではないでしょうか。そういう意味では、いきなりコーディングではなく、業務の全体像をモデルで頭に描きながらプロジェクトを進行させるとスムーズにいくと思います。少し複雑なものを思考するための補助ツールとしてUMLを使うのは、有効なのではないでしょうか。

パネリスト 羽生田氏

羽生田　UMLのメリットは、世界標準だということ。なおかつ、言語として覚えておけばどんなエンジニアとも会話ができる、という特徴でしょう。

　デメリットは、「UML」といっても単なる言語にすぎないので、UMLが使える・話せるということと、良い設計ができることは関係がないということです。現在のUMLの流行は、このような誤解を生じさせていると思いますね。

浅海　UMLには、9つのダイアグラムがあります。初心者は、9つをすべて覚えようとします。しかし、仕事の内容によって必要な機能はかなり変わってきますから、結果として全然必要ない部分もでてくるわけです。僕は、「取りあえずクラス図とシーケンス図とユースケース図だけ覚えればいいよ」といういい方をしています。ミニマムな切り出し方をして、自分にとって必要なことだけ覚える方がいいのです。UMLの最小限の機能の範囲を使用する、簡単な開発プロセスを浸透させていかないと、UMLはなかなか広がっていかないのではないかと思います。

堂山　UMLのメリット、デメリットを指摘するときに、社内でよく起こる議論を紹介します。

　既存システムで、レガシーなドキュメントが山ほどあり、そこに機能を追加する場合、仕様は全部UMLで作り直すのか、少しだけ作り直すのか、というような議論です。単純にゼロから作るときにUMLを活用するのは有効かもしれませんが、現実はどうするんだという、適用方法の問題ですね。正解は私にも分からないのですが、おそらく皆さんも同じような課題を抱えていると思います。

細川　UMLについてはもう1つ、「CASEツールを用いてUMLを行うのがよいのかどうか」という議論があります。

　CASEツールを使ってUMLモデリングをするのは非常にメリットがある、とお考えの方はどのくらいいらっしゃるでしょうか？ ほとんどの方が手を挙げましたね。では、参加者の方にも簡単にコメントしていただきましょう。

参加者　私は、UMLをビジネス・モデリングに使う場合、紙にいろいろな図を描いてビジネスの形をつかみ、アイデアが完全にまとまった段階で初めてツールを使います。「ビジネス」という巨大なモノをいきなり単なるクラスの中に収めて、それでビジネスの全体像を把握したと考えるのは早計だと思っています。思考というのはさまざまな視点があり、UMLもそれを表現する1つの手段にすぎないと思いますね。

参加者も議論に加わる

参加者　UMLもCASEツールも進化してはいますが、いまのところデバッグができないのが最大の難点です。自分の行ったモデリングが正しいのか間違っているのかは、コードに落して初めて分かるのです。それならば、いきなりコード書いてしまう方が早い。確かに、考え方を鍛えるには非常に便利だと思いますが。

堂山　私がなぜ20年前の交換機開発の話をしたかというと、私はそのプロジェクトに2年いて、別のプロジェクトに移ったのです。しかし、10年たっても「このプログラムの問題がどうだ」とか、「どうしてこう書いたんですか」という質問がくるのです。当時はワープロで仕様書を書いていたので仕様書の紙しか残っていない。ワープロ自体がなくなってしまった。いまならUMLで書いて配布すれば、それで済むのではないでしょうか。ちなみに、ITUでもUMLが標準になっています。

パネリスト 山岸氏 山岸　新たなツールを使い始めることで、思考方法が変わることはあるでしょう。もちろん、ツールによっていろいろな制約を受けるという面もあるのですが。 　例えば、ワープロを使うようになってから、文章の書き方は変わったと思います。UMLもこれと同じことがいえるのではないでしょうか。クラス図を書くにしても、取りあえず「こんなやつ」「こんなやつ」という感じでクラスの候補を置いていって、それから関係をじっくり考えるようになりました。ツールの制約に縛られるのは仕方ありませんが。

藤井　私から2点、質問させてください。まず、従来の手法に慣れた顧客にUMLの活用を勧めていくには、どうすればいいでしょうか。

　もう1つは、見積もりの方法です。UMLで業務分析を行う過程で、どういう基準で見積もりを行うのでしょうか。

羽生田　単にUMLを使いこなすだけでは、システム全体の仕様は表現しきれません。従来の手法とUMLの融合というのは絶対に必要です。

　従来のやり方に慣れている人に対して、UMLをどう導入するか。まずは、簡単なシステム開発、つまりパイロット・プロジェクトをUMLで暫定的に規定してあげて、どう表現できるのか、ということに慣れてもらう。E-R図でうまくいっているのに、無理やりクラス図で書いてもあまり意味がありません。うまく共存するためのプロセスを定義してあげないと、お互い不幸になってしまうでしょう。

　現在のUMLは、まだ表現力に欠ける部分があり、UMLのダイアグラムを増やしても解決しないと思いますね。特に要求の仕様をまとめる段階は、UMLだけではうまくいかないでしょう。

山岸　見積もりについて、まずコスト構造を明確にすることが重要です。コストはアーキテクチャの設置などの固定費的なものや「ユースケースの数」、「画面・帳票の数」などに相関する変動費的なもの、全体に対して一定の比率で必要なテスト工程のコストなどから構成され、それぞれが複数のパラメータに依存します。ウルシステムズの場合は、「ユースケースの数」と「アウトプットの画面遷移の複雑さ」あたりが基準になります。

　また、見積もりの段階では、構築しようとするシステムの「賞味期限」を限定します。多くの企業は、システムを未来永劫使い続けるつもりで企画しています。そうなると、見積もりも難しいですよね。2年なら2年と限定してしまえば、利用技術や作る抽象レベルも絞り込めるのです。

モデレータ／パネリストと参加者の距離が、会場に一体感を生む

参加者　いま、会社ではオブジェクト指向でモノを作っていこうとしています。実感としてUML自体は難しくないのですが、オブジェクト指向の分析が大変難しいと感じています。オブジェクト指向を従来型技術者が簡単に会得できる方法やコツというものはあるのでしょうか？

羽生田　ある業務に精通していて、その業務をどう変革していくかという、一番大きなニーズを持っている人をモデラーとして育てていくことに尽きると思います。ビジネス・ドメインをある程度安定したモデルとして表現できれば、次に「どのようなフレームワークに載せるのか」というの段階に入ります。そこを開発者に任せればいいのです。しっかりと役割分担を行い、育てるメンバーを選抜することが必要でしょう。

　このような体制は、パイロット・プロジェクトのようなものを立ち上げ、可能性がある人たちによる中核チームを作り、彼らが牽引していく形で業務に対応していく組織作りが必要になってくると思います。

モデレータ 細川氏

細川　UMLは初心者にとって、とっつきやすいものなのでしょうか？

羽生田　教育という観点でみたときは、細かい文法にこだわるより、UMLで表現する図のイメージをいかに伝えるかが重要だと思います。クラス図、シーケンス図、コラボレーション図にしても、UMLのダイアグラムは凝りすぎているのです。基本的なイメージが確立した段階で、シーケンス図、ステートチャート図、コラボレーション図などのダイアグラムを教えていけばよいと思いますよ。

細川　UMLはエンドユーザーに対する説明資料として果たして有効なのでしょうか？

山岸　業務モデリングには、アクティビティ図、ユースケース図、クラス図を使います。問題はクラス図ですね。通常、業務の概念モデルとしてクラス図を書きますが、そのとき、「このクラスとこのクラスのアソシエーションの多重度は」なんていったら顧客はついてきません。一緒にモデルを構築しながら、顧客の分かる言葉で説明していけば、クラス図は書けないまでも理解できるようになります。

細川　UMLが今後解決しようとする対象が広がれば広がるほど、こういう課題は増えてくると思います。今日確認できたのは、やはりUMLが解決しようとする課題、領域はどんどん広がっていくということ。そして、さまざまな目的を持っている人が、UMLという同じ手段を使い始めているということでしょう。

Development Style Initialsponsorコーナー