モデリングの神さまが降りてくる瞬間実行可能な知識とソフトウェア(4)

ある程度の経験を積んだプログラマならば、UMLなどのダイヤグラム表現を使わなくても、単なる文字列であるプログラムからさまざまなイメージ、感覚(最近のはやり言葉でいえば「クオリア」)を感じ取ることができるだろう(本文より)

» 2004年06月18日 12時00分 公開
[山田正樹,メタボリックス]

 UMLの教科書を見ると、たいてい、モデリングの作業はまずユースケース図なるものを描きなさい、というところから始まっている。何を隠そう、筆者の書いたUMLモデリングの教科書もそうなっている。ま、これはこれで無理もない。UMLは従来のソフトウェア開発工程でいえば、要求分析から基本設計、詳細設計といった辺りまでをカバーするものと考えられているし、ユースケース・モデリングとはその要求分析を行うことにほぼ相当するとされているからだ。

 ユースケースとはこれから作ろうとするシステムのユーザーがシステムに期待していることを記述したものだ。「サービス」「目的」「フィーチャ(feature)」「ユーザー機能」「外部機能」、どう呼ぶかは自由だけれど、つまりは「システムが外からどう見えるべきか」というのが共通するキー・ポイントになる。そしてUMLのほかのモデル要素に比べればとても単純で、取りあえずだ円の中に「〜を〜する」と書けばいいのだ。こんなものは何だかすぐに書けそうな気がしてくる。実際、簡単に書き始めることができるのだ。

 ところが、だ。調子に乗ってずんずん書いていくと、だんだん訳が分からなくなってくる。そうすると、「あまり細かくし過ぎるな」とか「拡張と包含を使い分けろ」とか「whatを記述するのであって、howを記述するのではない」とか、ああしろこうしろという技術的なポイントを押さえて書くようになるのだが、もちろん、このような技術的な要件を満たすのは簡単なことではない。この時点で混乱する人は多いのだが、一方で、一生懸命ユースケースを考えれば考えるほど、これから作るシステムが何をするためのどんなシステムなのかが分からなくなってくるという人も、また多いのである。 同じ漢字、例えば「指」という字を、何度も何度も続けて書いているうちに「本当に“ゆび”ってこういう字だったろうか? 手の先に5本も付いているコレはこういう字で表すんだったろうか? なぜ“オブジェクト指向”というコトバにこの漢字(指)が使われているんだろうか?」などという妄想の世界に入り込んでいくことがあるのに似ている。

 視点を固定して、集中してモデリングしていくと、いままでは取りあえずはっきりしているかに見えたモデリング対象の輪郭が逆にどんどんぼやけてくる。これはユースケースに限ったことではない。シナリオを書いていても、クラス図を描いていても、もしかしたらソースコードを書いていても、同じことは起こり得る(少なくとも妄想癖のある筆者には日常茶飯事である)。

 「だからモデリングなどというものにうつつを抜かしているやつは駄目なんだ」と考える人もあるかもしれない。確かにそうかもね。でも別の考え方をすることもできる。これは「分からないということが分かってくる」という、とても重要で貴重な体験なのだ。なぜ、これから作るシステムはこんなものだといままで分かったような気になっていたのか? なぜ、ここにこのパターンを使うのが当たり前だと思い込んでいたのか? どこまでがこのシステムでやるべきことなんだろうか? 実は、僕らは何も分かっていないのだ、すでにプロジェクトは走り始めているというのに……。

 実はこのとき、次に進むべき道の入り口が、霧のすぐ向こうにあるのだ。では、この霧を晴らすためにどうすればよいのだろう? ユースケース分析は取りあえず棚上げにし、概念分析に進むといいかもしれない。whatとhowを分離するのが鉄則といわれたって、そこはしょせん人間、howを考えているうちに、より良いwhatが見えてくることもあるだろう。物事は順を追って進むとは限らない。

 あるいは、いままで描いたユースケース図なんて捨ててしまって、もう1度最初から描き直してみよう。あるいは、悩んだ頭を抱えたまま一杯飲みに行こう。本屋をぶらついたり(計算機科学の棚の周辺は避けた方がよろしい)、映画を見に行ってもいい(個人的な経験則によればビデオよりは映画館の方が良さそうだ)。ただし、やり残していた別の仕事はやっつけておこう。そのうち、モデリングの神さまがあなたの肩の上に降りてくる。

 さて。もし、あなたがこんなメンバーを抱え込んだチームのリーダだったらどうしようか。せっかくだから彼(彼女)の書いたユースケース図を肴(さかな)にあれやこれやねちねちと屁理屈をこねていじめてみようか。あるいは彼(彼女)の頭上に一発大きな雷を落としてみるか。……いずれにしろ、頭の中の何かが「壊れる」(注)ということが大切なのだ。霧が深いのではなく、実は、自分が頑(かたく)なに目をつぶっていたのだと気付くためには。禅ではこのような師の振る舞いを払拳棒喝(ほっけんぼっかつ)などと呼ぶ。詳細はGoogleされたし。

注:壊れる=breakdown

 プログラミングでも「壊れる」のが重要なのはみんな知っているはず。プログラムを書き、動かしてみて何かまずいことが起きる、それで初めて「正しい」プログラムを書き始めることができるからだ。“まずいことが起きる”とはプログラマが心の中に描いている理想像(メンタル・モデル)と現実との間にずれが生じること。徹頭徹尾この考え方に基づいたソフトウェアの作り方をテスト駆動開発と呼ぶ。テスト駆動開発では、プログラムが壊れれば壊れるほど、ソフトウェアの品質は上がる。

 

 コミュニケーションでも同じ。どうでもいい会話を交わしているうちは、本当のコミュニケーションは生まれない。なぜなら、そのような場合は、相手のメンタル・モデルと自分のメンタル・モデルの間にずれが生じていないから。もし、ずれが生じていたとしても、その違いに誰も関心がなければコミュニケーションは存在していないといえる。

 

 何か相手のいっていることがおかしい、と思ったときから本当のコミュニケーションが始まる。2つのメンタル・モデルのずれを認識し、それを埋めよう(あるいはもっと拡大しよう)という行為がコミュニケーションなのだ。



 UMLは、図という「直感」に訴えかける表現方法を縦糸に、線を引く、箱を描くといった「肉体的行為を促す」という横糸を絡めて、いままでのテキスト中心のプログラミングとは異なるパラダイムをわれわれにもたらしてくれた。

 しかし、「分かる」=「壊れる」ための表記法やツールとしては十分ではない。UMLツールで描くユースケース図やクラス図は、出来上がった作品としてはきれいに見えるかもしれないが、それは到着点(つまり、分かってしまった後の結果)であって、「ソフトウェアを作る」という、物事を「分かっていく」過程の出発点にはなってはいない。

 まず第1に「壊れ」にくい。試行錯誤したり、遠くに離れて見てみたり、ぐしゃぐしゃって丸めて捨てたり、大きく「×」を描いたりしにくい。画面も小さいし、マウスやタブレットはいまいち肉体的感覚にそぐわない。何が正しくて何が間違っているのか、よく分からない。第2に、現在のUMLは「分かった」結果を表すために作られたもので、「分かる」過程をうまくサポートしてくれない。

 実は、「分かる」過程を手伝ってくれるような図の描き方、考え方が、UML以外にもいっぱいある。例えば、「マインドマップ」は代表的な例の1つだ(ググってくだされ)。汎用的なツールだけれど、Catalysisというオブジェクト指向方法論では、ドメイン分析にマインドマップを用いている。「CRCカード」なんていうのも、オブジェクトの世界では昔から使われている(『実践CRCカード―ロールプレイとブレーンストーミングによる大規模システム開発手法』、デビッド・ベリンほか著、2002年、ピアソンエデュケーション)。CRCカードには、「ストーリー性」という、また別の面白さもある。「論証分析」は、1人ではなく複数の人間の間で「分かる」ために使われる(『ハイパーテキスト情報整理学―構造的コンテンツ作成のすすめ』、ロバートE. ホーン著、1991年、日経BP社、残念ながら版元在庫切れ)。

 ある程度の経験を積んだプログラマならば、UMLなどのダイヤグラム表現を使わなくても、単なる文字列であるプログラムからさまざまなイメージ、感覚(最近のはやり言葉でいえば「クオリア」を感じ取ることができるだろう。色とかにおいとか手触りとかそういうものだ。「この関数のこの辺がちょっとくさいな」と先輩プログラマがいっているとき、おそらく彼は本当に「におい」をかぎ取っているのだ。そういう人にとって、UMLなどという記法は小うるさいだけのものに思えるのかもしれない。

著者プロフィール

山田正樹

(株)ソフトウェア・リサーチ・アソシエイツ 、(株)ソニーコンピュータサイエンス研究所を経て、1995年(有)メタボリックス設立。代表取締役。アーキテクチャ、モデリング、マネージメント、コラボレーションなどを含む広い意味でのソフトウェア・プロセス・エンジニアリングが専門。ソフトウェア・ツール開発、メンタリング、コンサルティングなどを行っている。



Copyright © ITmedia, Inc. All Rights Reserved.

注目のテーマ