変幻する実行可能知識 4「わかるといふこと」たいていのUMLの教科書を見ると, モデリングの作業はまずユースケース図なるものを描きなさい, というところから始まっている. 何を隠そう, 筆者の書いたUMLモデリングの教科書もそうなっている. ま, これはこれで無理もない. UMLは従来のソフトウェア開発工程でいえば, 要求分析から基本設計, 詳細設計といった辺りまでをカバーするものと考えられているし, ユースケース・モデリングとはその要求分析を行うことにほぼ相当する. ユースケースとはこれから作ろうとするシステムのユーザがシステムに期待していることを記述したものだ. サービスといっても, 目的といっても, フィーチャといっても, ユーザ機能といっても, 外部機能といってもいいけれど, 「システムが外からどう見えるべきか」というのが共通するキー・ポイントになる. そしてUMLの他のモデル要素に較べればとても単純で, とりあえず楕円の中に「~を~する」と書けばいいのだ. こんなものは何だかすぐに書けそうな気がしてくる. 実際たいていの場合は簡単に書き始めることができる. ところが, だ. ずんずん調子に乗って書いていくとだんだん訳が分からなくなってくる. あまり細かくしすぎるなとか, 拡張と包含を使い分けろとか, whatを記述するのであってhowを記述するのではないとか, ああしろこうしろという技術的なポイントを押さえるのももちろん難しい. でも多分それだけではない. 一生懸命ユースケースを考えれば考えるほど, これから作るシステムが何をするためのどんなシステムなのかが分からなくなってくるのである. ちょうど同じ漢字 - 例えば「指」- を, 何度も何度も続けて書いているうちに「本当に"ゆび"ってこういう字だったろうか? 手の先に5本付いているものはこういう字で表すんだったろうか? 何で"オブジェクト指向"にまでこんな字が現れるんだろうか?」などという妄想の世界に入り込んでいくことがあるのに似ている. 視点を固定して, 集中してモデリングしていくと, 今まではとりあえずはっきりしているかに見えたモデリング対象の輪郭が逆にどんどんぼやけてくる. これはユースケースに限ったことではない. シナリオを描いていても, クラス図を描いていても, もしかしたらソースコードを書いていても, 同じことは起こり得る (少なくとも妄想癖のある筆者には日常茶飯事である:-) 「だからモデリングなどというものにうつつを抜かしているやつは駄目なんだ」と考える人もあるかもしれない. 確かにそうかもね. でも別の考え方をすることもできる. これは「分からないということが分かってくる」とても重要で貴重な体験なのだ. なぜこれから作るシステムはこんなものだと今まで分かったような気になっていたのか? なぜここにこのパターンを使うのが当たり前だと思いこんでいたのか? どこまでがこのシステムでやるべきことなんだろうか? 実は僕らは何も分かっていないのだ, もうプロジェクトはとっくに走り始めているというのに... でも実際にはこのとき, 次に進むべき未知の入り口が霧のすぐ向こうにあるのだ. この霧を晴らすためにはどうすればよいのだろう? 例えばユースケース分析は取りあえず棚上げにして, 概念分析に進むといいかもしれない. whatとhowを分離するのが鉄則といわれたって, そこはしょせん人間, howを考えているうちによりよいwhatが見えてくることもあるだろう. 物事は順を追って進むとは限らない. あるいはこんなユースケース図は捨ててしまってもう一度真っ白から書き直してみよう. それとも悩んだ頭を抱えたまま一杯飲みに行こう, 本屋をぶらついたり (計算機科学の棚周辺は避けた方がよろしい), 映画を見に行ってもいい (個人的な経験則によればビデオよりは映画館の方が良さそうだ). 前にやり残していた別の仕事をやっつけておこう. そのうちにモデリングの神様があなたの肩の上に降りてくる. もしあなたがこんなメンバを抱え込んだチームのリーダだったらどうしようか. せっかくだから彼女の書いたユースケース図を肴にあれやこれやねちねちと屁理屈をこねていじめてみようか. あるいは彼の頭上に一発大きな雷を落としてみるか. いずれにしろ, 行くところまでいって行き詰まって, それから何かが「壊れる」ことが大切なのだ. 実は霧が深いのではなく, 自分がかたくなに目をつぶっていたのだと気付くためには. 禅ではこのような師の振る舞いを払拳棒喝 (ほっけんぼっかつ) などと呼ぶ. 詳細はgoogleされたし.
UMLは図という直観に訴えかける表現方法を使い, 線を引く, 箱を描くといった肉体的行為を促すという意味で, 今までのテキスト中心のプログラミングとは異なるパラダイムをわれわれにもたらしてくれた. けど, まだまだ「分かる」=「壊れる」ための表記法やツールとしてはまったく十分でない. UMLツールで描くユースケース図もクラス図もできあがった作品としてはきれいに見えるかもしれないけれど, それは到着点であって, 「ソフトウェアを作る」というものごとを「分かっていく」過程の出発点にはなりにくそうだ. まず第一に「壊れ」にくい. 試行錯誤したり, 遠くに離れて見てみたり, ぐしゃぐしゃって丸めて捨てたり, 大きく×を描いたりしにくい. 画面も小さいし, マウスやタブレットはいまいち肉体的感覚にそぐわない. 何が正しくて何が間違っているのか, よく分からない. 第二に今のUMLは「分かった」結果を表すために作られだもので「分かる」過程をうまくサポートしてくれない. 実は「分かる」過程を手伝ってくれるような図の描き方, 考え方はUML以外にいっぱいある. 例えば「マインドマップ」は代表的な例の一つだ (ググってくだされ). 汎用的なツールだけれど, Catalysisというオブジェクト指向方法論ではドメイン分析にマインドマップを用いている. CRCカードなんてのもオブジェクトの世界では昔から使われている (「実践CRCカード - ロールプレイとブレーンストーミングによる大規模システム開発手法」, デビッド・ベリン他著, 2002, ピアソンエデュケーション). CRCカードには「ストーリ性」というまた別のおもしろさもある. 論証分析というのは一人ではなく複数の人間で「分かる」のに使われる (「ハイパーテキスト情報整理学 - 構造的コンテンツ作成のすすめ 」, ロバート・E・ホーン著, 1991, 日経BP社, 残念ながら版元在庫切れ). これは議論の枠組みを次のような図を使って明らかにするものだ.  (同上書, p.186)
|