話題の新刊書「オブジェクト指向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を考えるためのオブジェクト構成を把握するためにクラス図も併記されている。「やはりオブジェクト指向は正義であり真理であった。ならば、これまで以上にオブジェクト指向開発に徹することで、効果的なDB構造を伴う情報管理システムを開発できるようになるだろう」といったナイーブな期待を抱く向きもあるかもしれない。
なお本書には、既存の「アクション→オブジェクト」なUIを「オブジェクト→アクション」にデザインし直す演習問題がいくつも載っている。しかし、それを目的としない本だからであろうが、DB構造を新たに考えるような課題は含まれていない。著者は「UIとDB構造とが異質な設計課題であることは自明」と正しく理解しておられるのであろう。
しかしながら、「使いやすいUIや効果的な業務フローから、合理的なDB構造を自然に導ける」と考えている開発者が少なくないのが実情だ。はたしてこの本がその勘違いを助長しないと言い切れるだろうか。
じっさい、UIやクラス図や業務フローが緻密にまとめられているわりにDB設計がおざなりな設計書の例はあまりに多い。その無責任さは、「住みやすそうなマンションの秀麗なイラスト」を描いた建築士が、施工業者に対して「これが設計図です。あとをよろしく。鉄筋の本数？それはそちらが責任をもって考える問題でしょう」と言うようなものだ。マンションが住みやすいかどうかと、力学的に適切であるかどうかは直交した（つまり無関係の）設計課題である。「使いやすさ」は適切な業務システムであることの必要条件ではあるが、十分条件とはなり得ない。そもそもUIをほとんど伴わないバッチ処理中心のシステムも存在するし、居住性を問題にしない倉庫や駐車場専用のビルも存在する。
30年前に取り入れて以来、私はOOUIが「使いやすいUI（住みやすいマンション）をデザインするための銀の弾丸」であることを疑ったことはない。しかしそれが「矛盾の生じないDB構造（力学的に適切なマンション）をデザインするための銀の弾丸」であるとはまったく思わない。そのように見なせば手痛いしっぺ返しを受けるだけだ。少なくとも、一定以上複雑なデータ構造を相手にするのであれば、OOUIやUXとは異なるDB設計のための工学的（数学的）枠組みが必要だ。DBデザイン論がDBのためにあるように、UIデザイン論はUIのためにある。どんなに効果的であっても、その分限を超えるような使い方をしてはいけない。この点に注意しさえすれば、本書はシステム開発者の必読書としてお勧めできる。
