328
Help us understand the problem. What are the problem?

More than 1 year has passed since last update.

posted at

updated at

Organization

業務アプリの銀の弾丸、OOUI本を読む

OOUI本とは

OOUI、すなわち、オブジェクト指向ユーザーインターフェース(Object-Oriented User Interface)。
この技術は昨年のWEB+DB PRESS Vol.107でも取り上げられましたが、単著となってオブジェクト指向UIデザイン ― 使いやすいソフトウェアの原理という本として出版されました。図やイラストも多く、大変読みやすい本です。

3行でまとめる

  • 業務用アプリケーションに関わる人は読んだほうがいい
  • タスク指向とオブジェクト指向でUIを分類し、業務アプリケーションでは特に後者のアプローチが有効
  • ワークアウトが充実しているので、実践的なOOUI設計の手順を知れる

書かれていること

オブジェクト指向の、What(そもそも何か)、How(どのように設計・実装するのか)、Why(なぜ使うのか)が書かれています。業務アプリケーションに限らず、ゲームなどのソフトウェアでも、アイテムを選択する際のUIだったりには適用できる部分が多いと思います(というか、むしろゲームではすでにOOUIで作られている部分が多いかもしれません。。。)
また、SIerだけではなく、自社サービスを作っている場合でも、大抵の場合は運用のためにカスタマーサポートさんたちが使う業務用アプリケーションが作られます。よって、対象読者は結構広い範囲に及ぶかと思います。

流れとしては、Whatが1章に、Howが2〜5章、Whyが6章にまとまっています。
主に扱っているのは、よくあるECサイトや業務アプリケーションです。

What(1章)

まず、1章で業務アプリケーションのUI設計の手法として、オブジェクト指向とタスク指向を比較しています。
また、なぜ業務アプリケーションがタスク指向で作られてしまうのか、という疑問も「1-5 UIがタスク指向になってしまう背景」で説得力を持って分析されています。

How(2章〜5章)

2章で設計の概要を述べ、3章でかなり具体的な事例を扱って実践してく様子を解説しています。
4章、5章はしっかりとしたワークアウトとなっています。基礎的な練習から業務ではよくある、段階的に要求が変化していく場合のものもあり、大変参考になります。

Why(6章)

章のタイトル「オブジェクト指向UIのフィロソフィー」の通り、背景となる哲学からコンピュータにおけるユーザーインターフェースの歴史までを元に、そもそもGUIはオブジェクト指向であるということが書かれています。このあたりはUIの専門の方ならご存知かもしれませんが、50年前ぐらいからの流れがコンパクトにまとまっています。

WebアプリケーションとOOUI

自分が大体Webアプリケーションを作っているので、そのへんとの関連をつらつら書いてみます。

Webフレームワークにはある程度取り込まれている

RailsのようなWebのフレームワークは、最初からある程度OOUIになるように作られています。手前味噌ですが、そのあたりは別記事であるRailsにおけるOOUIに考えをまとめてあります。
この本の中にもありますが、オブジェクト指向UI自体はかなり昔からあり(本の中では「古くて新しい」と表現されています)、そういった意味ではベストプラクティスとしてすでに普及していると考えていいでしょう。ただ、業務アプリケーションではタスク指向で実装されてきた歴史があるようです。

フロント周り

Webアプリケーションは永続化するのがサーバ側にあり、モードレスで作ることが一定難しいです。しかし、これは近年ではバックエンドのAPI化やフロントエンドの高度化によって解消されつつあります。
オブジェクトの一覧、コレクションを表示する際には様々な表示方法が考えらるので、そのあたりの表現を充実させる必要があるかと思います。時系列や地図表示、それらを組み合わせたものなど、情報の表示の仕方はいくらでもありますし、状況に応じて必要な表示方法も細分化していくでしょう。
また、レガシーなアプリのUIの改善として、今までタスク指向だったUIをオブジェクト指向に変換する仕事は増えるかもしれません。

企画者とのやりとりの仕方

機能の実装を提案してくださる方々は、画面のモックアップを書いてくださることが多いです。第4章に出てくる以下の図の右側の部分です。

スクリーンショット 2020-06-15 7.30.03.png

(オブジェクト指向UIデザイン 137ページより抜粋)

しかし、ユーザのメンタルモデルであり、アプリケーションの操作対象となるオブジェクトを抽出するところ(図の左上)までをまとめていることは中々ありません。アプリケーションをデザインするのであれば、ユーザーのメンタルモデルであるオブジェクトが何であるのかを明確にしないと、それは設計(デザイン)とは言えないでしょう。これはアプリの企画者と開発者でデザインをする人が分離されているということです。それでは良いアプリケーションは生まれそうにありません。この本の中でも、モデル、インタラクション、プレゼンテーションを行ったり来たりすることが大事だと書かれています。
開発時には、ラフでも良いのでこういった図を使って、企画者と頭の中を揃えるとより良いアプリを作れるようになるかと思います。

また、ここまでモデルがしっかり作られていれば、NoCode系のツールで(簡単なアプリケーションなら)作れてしまいそうです。
弊社(リブセンス)では、10%ルールという形で業務時間の一部を実験的な技術を試したりすることができます。
その時間を使ってAppSheetというNoCodeツール(Googleが昨年買収した)を試してみたところ、モデル(主にデータ周り)を設計し、それを一覧と詳細で表示、新規作成・更新・削除といったOOUIで操作が可能なアプリをプログラミングせずに実装できました。
これはある意味、Railsでアプリケーション部分だけを書いてきたようなITエンジニアには辛い時代と言えるかもしれません。

まとめ

ざくっと書いてみました。
個人的には、コンピュータを道具としてより扱いやすくしていくために、積極的にオブジェクト指向UIでアプリケーションが実装して行きたいと思います。もちろんタスク指向が向いている場合もあるのですが、そういった場合を見極める方法もこの本の中に書かれています。
そういった意味でも、業務アプリケーションに関わる方であれば職種を問わずおすすめできます。
6章あたりは特に大好物でした。技術に歴史ありですね。
ワークアウトをしっかりやると読むのに時間がかかると思います。しかし、研修コースなどもあると聞いておりますので、そちらを受けてみるのも良いかもしれません。

Why not register and get more from Qiita?
  1. We will deliver articles that match you
    By following users and tags, you can catch up information on technical fields that you are interested in as a whole
  2. you can read useful information later efficiently
    By "stocking" the articles you like, you can search right away
Sign upLogin
328
Help us understand the problem. What are the problem?