OOUIは強力だが、合理的なDB構造を導くわけではない

　話題の新刊書「オブジェクト指向UIデザイン」を読んだ。使いやすいUIについては昔から興味があって手に取ったのだが、読みながら既視感につきまとわれた。かつてAS/400使いであった筆者は、90年代初頭に「アクション→オブジェクト vs オブジェクト→アクション」という話題で仲間と盛り上がっていたことがある。その内容がまさにこの本で書かれていたことだった。

　「アクション→オブジェクト」とは古いタイプのUIで見られるパターンである。ワープロソフトが普及する以前、「ワープロ専用マシン」というものがあった。それを起動して最初に現れるメニューには、以下のようなメニューオプションが並んでいたものだ。

・ドキュメントの追加
・ドキュメントの複写
・ドキュメントの編集
・ドキュメントの削除
・ドキュメントの印刷

　たとえば「ドキュメントの編集」を選ぶと、ドキュメント名を入力・選択するためのダイアログが現れる。つまり、最初にアクション（操作）を選択して、その後でオブジェクト（対象）を選択するというスタイルである。これを「アクション→オブジェクト」と言う。

　対する「オブジェクト→アクション」はその逆である。AS/400上で動作する外国製のCASEツール（今でいうローコード開発ツール）の付属資料で初めてこの考え方を知ったのだが、そこではまさに「オブジェクト指向」と呼ばれていた。これにもとづくUIの例を示す。

▼「オブジェクト→アクション」のUI例

　この例では、まずは扱うべき「自治体」を選び、その自治体やこれに付随する世帯や住民等の情報を確認したうえで、それらに対するアクションを選ぶ形になっている。メニュー上で並ぶアプリのタイトルはここでは「ナントカの一覧・保守」のパターンになっているが、その資料の英語表記では「Work with ナントカ」になっていた。「ナントカを扱う」くらいのざっくりした意味なので、メニューでは事実上オブジェクトが一覧されているといっていい。

　この「オブジェクト→アクション」の自然さや合理性に気づいて、一瞬でUI設計のスタイルが変わってしまった。実践してみるとじつに効果的で、エンドユーザから使いやすくなったと何度言われたかわからない。これは日本語の語順に沿っているからではないかと、仲間とビールを飲みながら話していたことを覚えている。日本語の構文は、目的語の後に動詞が来る「オブジェクト→アクション」であるからだ。「水を飲む」であって、「飲む水を」ではない。

　さて、「オブジェクト→アクション」を知る少し前、私はデータ指向アプローチ(DOA)に魅了されて開発実務で実践していた。つまり、「DB構造からUIや業務フローが導かれる」というDOAの考え方とオブジェクト指向UI(OOUI)とが、矛盾なく貢献できていたということだ。この事実は、それぞれが「DBデザイン論」と「UIデザイン論」として補完しあえる枠組みであることを示している。

　まさにこの点に関わる危うさを、私は「オブジェクト指向UIデザイン」に感じる。OOUIを取り入れて徹底することで、必要なデータベース構造も自然に手に入ると勘違いしてしまう読者がいるのではないだろうか。なにしろ本書では、UIを考えるためのオブジェクト構成を把握するためにクラス図も併記されている。「やはりオブジェクト指向は正義であり真理であった。ならば、これまで以上にオブジェクト指向開発に徹することで、より良いシステムを開発できるようになるだろう」といったナイーブな期待を抱く向きもあるかもしれない。

　なお本書には、既存の「アクション→オブジェクト」なUIを「オブジェクト→アクション」にデザインし直す演習問題がいくつも載っている。しかし、それを目的としない本だからであろうが、DB構造を新たに考えるような課題は含まれていない。著者は「UIとDB構造とが異質な設計課題であることは自明」と正しく理解しておられるのであろう。

　しかしながら、「使いやすいUIや効果的な業務フローから、合理的なDB構造を自然に導ける」と考えている開発者が少なくないのが実情だ。はたしてこの本がその勘違いを助長しないと言い切れるだろうか。

　じっさい、UIやクラス図や業務フローが緻密にまとめられているわりにDB設計がおざなりな設計書の例はあまりに多い。その無責任さは、建築士が「住みやすそうなマンションの秀麗なイラスト」を描いて工務店に渡し、「これが設計図です。施工をよろしく。鉄筋の本数？それはそちらが責任をもって考える問題でしょう」と言うようなものだ。マンションが住みやすいかどうかと、力学的に堅牢であるかどうかは直交した（つまり無関係の）設計課題である。「使いやすさ」は適切な業務システムであることの必要条件ではあるが、十分条件とはなり得ない。

　30年前に取り入れて以来、私はOOUIが「使いやすいUI（住みやすいマンション）をデザインするための銀の弾丸」であることを疑ったことはない。しかし、それが「矛盾の生じないDB構造（力学的に堅牢なマンション）をデザインするための銀の弾丸」でもあるとはまったく思わない。そのように見なせば手痛いしっぺ返しを受けるだろう。少なくとも、一定以上複雑なデータ構造を相手にするのであれば、OOUIやUXに先行して適用されるべきDB設計の枠組みが必要だ。その点に注意しさえすれば、本書はシステム開発者の必読書としてお勧めできる。