『オブジェクト指向UIデザイン』を読んでる感想
こんにちは@kaori_choです。OOUI本を読んでる雑感メモです。
３行まとめ
- タスク指向UIではなくOOUIでいこうぜ！って書いてある本
- 体系的にまとめられた教科書的な本 時間がある時にじっくり読んで考え方をインストールする系
- 「銀の弾丸、OOUI」と帯にあるように、実践できたら確かに強くなれそう
感想
直感的にわかりやすいことは正義である。直感的にわかりやすいUIは熟練したデザイナーの直感から創造されている。先に形ありきなんだけど、実はきちんと計算されている。その「行間」を解説してくれている本。
わー！こういう本が欲しかった！こういうこと体系的に学べる本ってありそうでなかった！もともと日本語で書かれているので表現がわかりやすい。
読んでみて、OOUI、たしかに銀の弾丸ではあると思うけど、これアルテマウェポンでありマスターボールみたいなものですよね。そもそも全クリできるくらいのレベルと経験があってやっと手に入れられるスキルっぽさ。たぶんOOUIを実践するには、頭の中で抽象と具体を高速で行き来しつつ、現実的な解決策を示すコミュ力もいる。
マスターボールはちょっと伝わりにくいかしら？別の例えをすると、微分積分や三角関数、フーリエ変換みたいな、とても強力な武器だが習得にはちょっと修練が必要、なたぐいのツールだと思う、オブジェクト指向IU。（まあちなみに私フーリエ変換はわかんないですけど。。。）
メモ
一言一句すみずみまで読み込んだわけではないので、気になった部分をピックアップ。
はじめに
まず石器の画像から入るのが面白い本だなという印象。オブジェクト指向UIの対義語として「タスク思考UI」というのが語られていて
一方タスク思考UIでは、入り口でまず謎の人格が立ちはだかります。
立ちはだかる謎の人格にめっちゃ笑った。すごいわかる。
1 オブジェクト指向UIとは何か
正直この本はここだけ読むだけでも１２０％価値があると思う。
タスク思考UIのソフトウェアを触ったことがある人間なら、「そうそうだからわかりにくかったのかー！」と膝を打つこと間違いなし。
P.28
UIがタスク思考になってしまう背景
...(略)...
システム業界では、業務上の複雑なニーズを満たすために、開発プロジェクトの上流工程において、ユーザーの要求事項をまとめます。
...(略)...
業務というのは仕事の流れでありタスクですから、ユーザーの要求は「やること」としてまとめられていきます。その「やること」を実現するためにさまざまな機能要件が定義されていくので、UIの構成もその「やること」をベースに組み立てられてしまうのです。
あ〜〜なるほどなと。ユーザー「こういう機能を追加してほしい」開発者「よっしゃ」という感じで育つと、どうしてもタスク指向UIになりがちなのはそういうわけか。
だからこそ「オブジェクト指向UI」という考え方を開発者がインストールしておくことが大事なのかなと。（現実的にこんなことできんわーっていう現場もあるだろうけど、知っているのと知らないのは全然違うと思う）
2 オブジェクト指向UIの設計プロセス
急に話が難しくなる。もしかすると後ろの例を読んでから戻ってきてもいい章かもしれない。
P.47
つまりデザインという行為を正当に行おうとすれば、そこには、ある種の直感によって、論理的な推察を経ずに直接最終の形に到達する術が必要です。
...(略)...
優れた実践者が共通して言うのは、制作の非プロセス性です。それは線形でも円形でもなく、帰納的でも演繹的でもありません。
...(略)...
熟練者は決して行儀よく手順を踏んでいませんし、論理を積み上げてもいません
...(略)...
先に形があり、ロジックは後から見いだされるのです。
えええ、いやいや、ちょっとまって。急にむずいむずい！
ただこれがわからなくても、P.50のりんごの皮むき機の例を覚えておけば良いと思う。
ユーザーの「りんごのかわをむきたい」というのを真に受けて「りんごの皮むき機」を開発して渡すのは筋が悪い。「果物ナイフ」を渡せば、りんごだろうがたまねぎだろうがユーザー自身の工夫で切れるでしょ？という図が書いてある。
つまり抽象度の高い道具の発明するよう心がけろ！ というメッセージとして個人的には受け取った。
5 ワークアウト 応用編
すでにいけてない管理画面を、どのように要求と向き合い改善するかが書いてある章。これをただのあるあるではなく実践的な例で、before/afterを示し、その行間にある考え方をきちんと紹介してくれるのが素晴らしい。
P.242
ベンダーの課題認識
（略）
・ボタンが目立たないので色分けしたほうがいい
ユーザーからの要望
（略）
・再入力をしやすくしてほしい
・検索結果をカスタマイズしてほしい
すでにある管理画面に対して、よくある改善要望である。（正直この改善要望・要求を対話で引き出すのも実はむずかしかったりする。）ただ本書ではこれをみて「検索結果をカスタマイズする機能」を作ってはいけないという話をしてる。
p.243
要求の中にある本来の目当てに着目する
（略）
カスタマイズして欲しいというユーザーの意見に対して開発者が行うべきは、カスタマイズ機能を作ることではなく、カスタマイズしなくてもはじめからユーザーのさまざまな用途をサポートし、ユーザー自身が少しの工夫で自分のコンテキストとツールの性質をつなぎ合わせられるような、シンプルで工夫のきくデザインを提供することなのです。
これ個人的にはUIデザインという文脈で「真のissueを掘り当てろ」ということなのかなと。私が去年登壇した時に話した「なぜ？を聞く」の話 も、これに近いことかな・・？
別の例で示されてたユーザー側にしかなかった概念を抽出し、それをソフトウェアに反映するところはまさしくDDDに通じるところがある。
OOUIにしろ、issue drivenにしろDDDにしろ、誰かが、ユーザーの要求を理解したうえで「（当初のオーダーとは違うけど）こんな感じでどうすかね？」とやることベースではない解決策 を示す必要があるなと。
これを実践するための思考訓練として後半の事例を読み込んでヒントを得るといいのかもしれない。
そんなことを考えながら読みましたとさ。
@kaori_cho でした。よかったらいいね！やコメントいただけると嬉しいです。
Discussion