« かすれたマーカーを使わされる拷問 | トップページ | 会計システムのアーキテクチャ論 »

2005.06.25

バカもハサミもバカなコダワリも使いよう

◆そのモデルは「見つめていたい」ほどに美しいか

データモデルだけでなく、業務モデルや機能モデルといったさまざまなモデル(図面)が企業システムの基本設計情報の中核となる。これらのモデルの妥当性を評価するためのいろいろな視点があるが、ほとんど取り沙汰されないのが「美しさ」である。「良いモデルは美しい」とはよく言われるが、それはたいてい「論理構成上の美しさ」の意味である。ここで言う美しさとは「視覚的な美しさ」だ。それは「ていねい」とも違うし、「清書されている」とも違う。

後輩のモデルをレビューする際に筆者がさんざん言ったのは「みめ麗しくまとめよ」である。記法のルールにのっとったうえで、アイデアを視覚的に心地よくまとめなければいけない。一瞥しただけで「絵として美しくないからダメ」と却下していたものだ。

最初の本を書いたときも、モデルの図版をさんざん書き直してもらった経緯がある。こちらが手書きで描いたものを図版に落としてもらうわけだが、こちらが意図した視覚効果がなかなか伝わらず、「この曲線をもっと大きく」とか「このテーブルとこのテーブルの間を0.5行分空けてください」とかいったチマチマした修正依頼を何度も送って編集者をうんざりさせたものだ。その過程で筆者のこだわりを理解してもらったので、2冊目以降のほうがモデルはずっと綺麗だったりする。

前回のマーカーの話につながるのだけれど、視覚的な美しさにそれほどにこだわるのはモデルが「皆が見つめるべきもの」であるからだ。皆が見つめて意見を出し合うことではじめてモデルは磨かれてゆく。「変にきれいだとそれで正しいと思ってしまわないか」と心配されることもあるが、美しくないと誰もじっと見つめてくれないのでそもそも検証作業が始まらない。美しくなくても同業者なら興味をもって見つめてくれるかもしれないが、データモデルのようにただでさえ理屈っぽい図面を一般人に見つめてもらうには、視覚的な魅力(「セクシーさ」と言ってもいい)が必要だ。

◆美しさへのこだわりをツールに明け渡す

このようなことを書くと「絵が下手ならば設計の仕事には向かない」という傲慢な主張をしていると思われかねないが、むしろその逆だ。まあさすがに、「人前で描いたり書いたりするなんてイヤだ」と思うほどに苦手意識があるとしたらこの仕事には向かないとは思う。そんな人に無理やり描かせても、ホワイトボードに一筆描くたびに「不調法でスミマセン」と謝りつつますます萎縮しそうで、それでは仕事にならないだろう。

しかし、下手なりに人前で堂々と描いたり書いたりできる姿勢さえあれば、システム設計に向いていないということはない。なぜなら、グラフィックな構成感覚の不備をモデリングツールがカバーしてくれるからだ。とくに、モデルの美しさにこだわりを持った人が設計したモデリングツールならば、より少ない努力で成果物を美しくまとめるための仕掛けが組み込まれているはずだ。XEADはそんなツールのひとつである。

話はちょっと変わるが、絵としての美しさへのこだわりも、ときに両刃の剣(もろはのつるぎ)となる。前回の失敗談もそのひとつだが、納得できるまでモデルを不必要に添削し続けるという問題も生じ得る。たとえば筆者はデータフローダイアグラム(DFD)を長い間VISIOで描いていたのだが、偏執的なこだわりのゆえに、フローの矢印の曲がり方やプロセスへの接続角度の修正にひどく時間をかけていた。これはQCDの責任を負っているプロとしては無様すぎる。また、これでよしと思って印刷して見返すとまた改善点に気づいて修正するなんてことを繰り返すので、環境保護の観点からいっても不適切だ。

DFDの描画機能をXEADに組み込もうと考えたのは、そのような反省からでもある。モデルを見栄えよく描画してくれるロジックや制約をツールに組み込んでしまえば、それを使いながら工数も森林資源も節約できる。実際にXEADを使ってみればわかるが、DFDもERDも微妙で優雅な曲線を基調とした絵としてどんどん描ける(そのため、描画ルーチンはポリゴンデータと曲線描画ロジックのバケモノと化している)。「自動的に美しくなる」とまでは言わないが、美しくまとめるための努力の量はお絵かきツールを使うときの比ではない。「萎縮することなく人前で描ける」程度のふつうのセンスさえあれば、次のような「みめ麗しいモデル」を時間をかけずに描ける(と自画自賛する)。

imageDFD

だから、描くことが大好きな技術者はもちろんのこと、描くことに自信のない技術者もXEADを使ってみてほしい。モデルの視覚的な美しさに関してはツールがモデラーに代わってこだわってくれるので、ほんらいもっと重要な「論理構成上の美しさ」に注意を振り向けることができるからだ。そして、視覚的にも論理的にも美しいモデルになればしめたもので、皆でモデルを眺めながら「システム要件上の適切さ」をさらに磨いていけばいい。

最近ではよほどオトナになったとは思うが、自分の視覚的な美しさへのこだわりがいくぶん病的ではないかと思うこともあった。そのような偏狭さがいろんな人を傷つけたり、困惑させたりしたのは事実だから。けれども、プログラムのロジックの形にカプセル化することでその狂気(?)を社会的に成仏させることができる――そんな風に考えたりもする。まったくもってバカとハサミは使いようであって、バカな自分はプログラマであってよかったとつくづく思う。

|

« かすれたマーカーを使わされる拷問 | トップページ | 会計システムのアーキテクチャ論 »

コメント

同意します。ここに書かれているようなものに共通しそうですね。
「世にも美しい数学入門」
http://www.amazon.co.jp/exec/obidos/ASIN/4480687114/

ただ、この業界で「美しい」だけを根拠にすると誤解する人がたくさんいるので、美しいの根拠を、例えば以下のように分かりやすく説明する必要があると思います。

・シンプル:複雑なI/Oがシンプルなモデルで表現できる。線の交差やぎこちない部分が少ない。
・一貫性:下手な繰り返しや分岐が無く、抽象化がうまくいっている。各部分の役割が明確。
・安定性:多少の仕様変更にもそのまま対応できる。OCPが実現されている。

以上の性質がそろったモデルは、ちゃんと実装のことを考えて作ったモデル(実装側からのフィードバックも歓迎している)である限り、実装しやすいといえます。
また、これらの実現には単に経験だけではなくて芸術的センスも要求されるので、「美しい」と表現することは妥当だと思います。

逆に、実装を知らない人が単に美しさを求めたとしたら、酷い目にあうことは確実なので、そのあたりも触れてもらえると実装担当側としてはありがたいです。

投稿: matt | 2005.06.26 14:33

コメントを書く



(ウェブ上には掲載しません)




トラックバック


この記事へのトラックバック一覧です: バカもハサミもバカなコダワリも使いよう:

» [開発]美しいモデル? [カレーなる辛口Javaな転職日記]
「良いモデルは美しい」とはよく言われるが、それはたいてい「論理構成上の美しさ」の意味である。ここで言う美しさとは「視覚的な美しさ」だ。それは「ていねい」とも違うし、「清書されている」とも違う。 http://watanabek.cocolog-nifty.com/blog/2005/06/post_642e.html モデラーは見た目の美しさだけに拘るが,実装の美しさには無頓着.「モデラーにとっての良いモデル」が,「開発者にとっての悪夢」であることは少なくない.そういう見かけ倒しの「設計」に基... [続きを読む]

受信: 2005.06.26 11:49

» 愛される設計書って [このシステム開発者(SE)はどんなことを考えているのか?]
愛されるソフトウェア 読んで思ったこと。 ■愛される設計書(or仕様書)って何だろう・・・ きっとそれは、バグがない、とか、記述に誤りがない、とかで判断するものではないだろう。 きっとそれは、読んでる傍から次の内容が予想できてしまうようでいて、 時々、... [続きを読む]

受信: 2005.07.01 23:57

» 美しさへのこだわり [OOJIBOO Blog]
設計者の発言: バカもハサミもバカなコダワリも使いよう 見た目に美しいモデルとは? 渡辺幸三さんの言う「みめ麗しく」まとめられたモデルとは、視覚的な美しさを追求したモデルのようです。... [続きを読む]

受信: 2005.07.06 19:33

« かすれたマーカーを使わされる拷問 | トップページ | 会計システムのアーキテクチャ論 »