「オブジェクト指向UI」のワナ
SmartHR のホーム画面（ファーストビュー）には大きなアクションボタンが並んでいます。
これらのボタンは社内では「おじいちゃんボタン」と呼ばれ（私が命名しました）、SmartHRの使いやすさの象徴として今日も元気に稼働しています。
この「おじいちゃんボタン」というインターフェースの是非については、開発者とユーザーで大きく意見が分かれるでしょう。
通常、アプリケーション開発においてはオブジェクト（対象物）に対して操作を行うようなインターフェース設計が妥当とされます。人は操作できる対象物を認識したうえで、それらに対する操作の期待値を得るからです。
そういったインターフェースデザインの定石（広く知られる呼びかたをすれば「オブジェクト指向UI」）から、この「おじいちゃんボタン」は大きく外れています。
しかし、前述した「慣れ」もあり、業務アプリケーションにおいてはこうしたタスクベースのUIが尊重されるシチュエーションは少なくありません。
業務に従事するユーザーは、自身の業務をオブジェクトへのアクションではなく「一連のタスク」として認知しています。
また、ユーザーの業務は日々繰り返し行われるので、慣れ親しんだ「タスク名」が業務アプリケーションにおいても道しるべとなります。安易にオブジェクトを整然と並べただけの画面を提供しても、ユーザーが見覚えのある「タスク名」と結びつかず、学習するコストが増えてしまいます。
具体的に SmartHR での失敗例を紹介します。
上述の「おじいちゃんボタン」の中のひとつの機能をリニューアルした際、その機能で管理するオブジェクトをホーム画面に一覧として展開し、該当する「おじいちゃんボタン」を削除する、といったリリースを行いました。リリース直後、当時の私の座席ななめ向かいに位置していたカスタマーサクセスチームの社用携帯が一斉に鳴り出し、「おじいちゃんボタンが消えた」と問い合わせが殺到した光景はいまだに忘れられません。
同じ機能を担当していた隣席のプロダクトマネージャーと私は、ちらりと視線を交わしたきり、俯き貝のように黙ることしかできませんでした。（その後、該当の「おじいちゃんボタン」は再びホーム画面に表示させました）
もちろん、中長期的な開発効率や機能拡張性の観点で言えば、オブジェクトを起点としたインターフェースを設計するべきです。しかし、業務アプリケーションの機能は、すでにあるユーザーの業務への認知と大きくずれない範疇で提供しなければ、ユーザーの業務効率化には直結しないのです。
ちなみに、「おじいちゃんボタン」の命名については深いコンテキストと私の天才的なひらめきがあるのですが、それはまた別の機会に説明させてください。
おわりに
冒頭で述べたとおり、この記事は幾度にもわたる改稿の果てに書きあげたものです。最初の原稿では社会性を疑われていた私も、SmartHRの優秀なメンバーに支えられてこうして記事を公開することができました。
過去の至らなかった自分と決別するためにも、最後に社内で大いに笑いを誘った弊社広報の素敵な校正コメントとともにお別れしましょう。
あ、次回は 310（@oremega）によるユーザビリティテストのお話です。
