ソシオメディア主催のオンラインセミナーに参加しました。主な内容はオブジェクト指向UIデザインの解説と質問への回答です。書籍『オブジェクト指向UIデザイン』の発売を記念したセミナーで、書籍を読んだもしくは読んでいる読者が主な対象者かと思います。

自分は書籍『オブジェクト指向UIデザイン』を読んでいる途中（この時点でワークアウト基礎編までを完了した状態）での参加でしたが、セミナーの内容が面白く、勉強になりました。

セミナーはカジュアルな感じでリラックスして参加できました。こちらからのチャットメッセージにも丁寧に回答いただき、感謝しています。

質問と回答のメモについて

有料セミナーですが、質疑応答の内容についてTwitterやブログでの公開許可をいただけたので、以下セミナーでの質問と回答について自分なりに解釈した内容をメモとしてまとめました。

解釈やメモした内容が間違っている可能性があります。誤りにお気付きの際はTwitterのダイレクトメッセージでお知らせいただけますと幸いです。

※以下テキストのみのメモですが、実際のセミナーでは映像と音声でわかりやすく学べました。

オブジェクト指向UI（OOUI）デザインを適用しないほうがいい場合はあるか？ その判断や適切なアプローチは？

• ほぼ全ての場合でオブジェクト指向UIデザインを適用したほうが良い。
• 例外的に銀行のATMのような、やることを選ぶユーザーインターフェイス（UI）の場合はタスク指向を取り入れる方法も部分的にはあり。
• 自明であるオブジェクトの選択が済んでいる場合はあり。その場合は実はオブジェクトが選択された状態でもある。
• オブジェクトが事前に選ばれている状態や、用途が限定されている場合はアクション（タスク）から始まっても良い。

例外的に銀行のATMのようなタスク指向UIのほうが良いとされる場合、「実はそれはオブジェクトが選択された状態のUIである」という考え方が面白かったです。新たな発見でした。

初めて訪れたユーザーをコンバージョンに導くWebサイトにはオブジェクト指向UI（OOUI）デザインは適さない？

• ユーザーに対して、何かしてほしいことが目的なのであれば適さない可能性が高い。
• 一方でECサイトはオブジェクト指向と相性が良い。

サービスサイトのようなWebサイトの場合、仮に問い合わせが目的だとしてもナビゲーションのラベル（文言）や情報整理によって、オブジェクト指向UIのほうが使いやすくなる場合もあるのではと考えました。

Webサイトの規模や目的、コンテンツ内容、情報の整理方法、文脈などを複合的に判断して、オブジェクト指向とタスク指向のどちらが良いのかを決めるのが良さそうだと思います。混合型になりやすい対象かもしれません。

ITリテラシーがあまり高くない方用のアプリケーションをつくる場合もオブジェクト指向UI（OOUI）デザインは有効か？

• 有効。
• もし使用難易度の高い状態になっているのであれば、オブジェクト指向の考えをもって、アプリケーションの機能数や画面数を減らすなどで対応できるのではないか。

もし使いにくい状態になってしまっているのであれば、まずは情報や機能の取捨選択から始めるのが良いかもしれません。必要な機能のみに絞ることも、使いやすさの底上げにつながると考えるためです。

オブジェクト指向UI（OOUI）デザインの専門知識がない人や有用性に疑問を持つメンバーにOOUIの利点をどう伝えたら良いか？

• まずはオブジェクト指向UIデザイン（OOUI）の本を読んでもらう。
• OOUIを知らない人にはOOUIという言葉をあまり使わないほうが良いかもしれない。別の言葉で置き換えて伝えるのもあり。
• いきなり実プロジェクトでやるのは難易度が高いかもしれない。
• 小さいプロジェクトで実験的に試していく。
• 現状の機能評価から試していく。OOUIにすることでの改善できる点がないかを探す。

まずは小さく試して自身がその概念を理解した上で、チームメンバーに少しずつ知見を共有していくのが良いと思います。

現状のアプリケーションの機能を評価し、その機能をオブジェクト指向UIデザインによる設計でどう改善できるかの仮説から始めるのも良さそうです。

オブジェクト指向UI（OOUI）の効果を評価する指標や方法はあるか？

• どれくらい効率が上がるかで評価する。
• 例えば作業効率で評価する。
• タスクベース時のUIと比較して、目的のアクション達成までのクリック数がどれくらい減っているかを測る。
• 例えば4クリック必要なアクションが2クリックで実現できるようになれば、作業負荷は50%になったといえる。
• タスクベースからオブジェクトベースに変えることで画面数が減ることが多い。画面遷移が減る分、作業効率が上がる。

作業効率の向上を数値で判断するために画面数やクリック数（画面遷移数）で判断するのは、わかりやすくて取り入れたいと思いました。

合わせて実際に使っていただいたユーザーの声を直接聞いて、感覚的な印象も知りたいところです。

ユーザーにとって未知の概念や新しいオブジェクトを扱うときにも有効か？

• 有効。
• 頭の中にあるものを触れる形にするために、オブジェクト指向がある。

このときにどうオブジェクトを定義（命名）して伝えるのか、伝わりやすく（ユーザーが使い方を解釈しやすく）設計するのかが重要と感じました。

タスク指向UIの既存システムをオブジェクト指向UI（OOUI）にしたい場合、どのように進めるのが良いか？

• 既存システムを変えるのはOOUIに限った話ではなく、大変。
• まずは既存システムを把握する。
• 既存のものを変えることに合意を得るため、現状の問題認識からすり合わせるのが良い。

経験則として、既存システムの把握と現状の問題の認識のすり合わせが大事だと実感しています。かけられる時間にもよりますが、問題の認識合わせの際に要件の再定義や理想型を描いたワイヤーフレームを設計する方法があります。

そのワイヤーフレームをUI改善議論のたたき台として、デザイナー、エンジニア、プロジェクトマネージャーを交えて議論するのはありかと思っています（ちょうど実践中です）。

根本的なUI変更に対するユーザーの抵抗をどうするか？

• システムの提供側はよく心配する。
• オブジェクト指向UIのプロトタイプを見てもらうと、ほとんどの企業がオブジェクト指向UIのほうが良いという。
• 一方でタスクベースで同一のタスクを繰り返しているような使い方のユーザーにとっては、UIが変わることで学習コストが増える場合もある。
• 解決策：いきなり全部変えるのではなく、部分的に変えていく。
• 解決策：既存システムとの併行期間を設ける。
• 解決策：企業内に理解を求める。

すでに稼働しているサービスのデザインを変えるときには、既存ユーザーへの配慮と、今後の長期的な運用を考慮した理想型のデザインとのバランスに悩みます。理想型のイメージは事前に描きつつも、少しずつ変えていくのが現実的にバランスが良いかもしれません。

情報量が膨大なサービスや機能が複雑なアプリケーションでOOUIを導入する際に注意すべきことは？

• そもそも情報量を減らすことを検討する。

不要な情報であれば減らします。必要な情報であれば、情報の分類方法やデータへのアクセス方法（例えば検索方法や並び替え方法）を整理できると良いと思います。

組織的にOOUIを始める良い順序は？

• 順序はあまり気にしなくて良い。
• デザイナー、エンジニア、プロダクトマネージャーなど、関係者で認識を合わせる。

複数人で開発する場合、基本設計がオブジェクト指向UI（OOUI）デザインになっていれば後続の開発は自然とOOUIになるか？

• 自然にOOUIにはならない。崩壊する可能性がある。
• なので設計意図を伝えたり、認識を共有することが大事。

長期的な開発でUIデザインやデータ構造の一貫性を維持するために、要件やデザインシステム、情報設計の考え方などのルールの明文化と共有が大事になると考えます。

OOUIにすることでデータベース構造などのバックエンドにも影響する場合、開発チームにおけるデザイナー、エンジニア、プロジェクトマネージャーの役割分担にどのように影響するか？

• そもそもソフトウェアデザイン領域において、デザイナーとエンジニアは別のことをやる職種ではない。
• ソフトウェアデザインには、デザインとエンジニアリングの両方の知見や技術が必要。
• クロスオーバーしていく（お互いの境界線を越えて交じり合う）のが大事。
• 組織の中でソフトウェアデザインの知見を相互に深めていく。

特に共感して納得した部分です。ソフトウェアのデザインには職種を横断する知見や技術があったほうが、品質と開発速度の両方を高めやすくなると思っています。そのために知見の共有や効率化の仕組みづくりが大事になると感じます。

オブジェクト指向プログラミング（OOP）で開発されたシステムがOOUIになっていない場合があるのはなぜか？

• オブジェクト指向UI（OOUI）デザインの方法や過程がほぼ明文化されておらず、知られていないから。
• できる人はできている。
• GUI（グラフィックユーザーインターフェイス）の設計とオブジェクト指向プログラミングは、別のものとして考えるものではない。

ウォーターフォール型開発で画面数を元に見積もりをおこなう際に、画面数の減るOOUIに消極的な場合の解決策は？ 画面数を元にしない見積方法はあるか？

• ある。工数で見積る。
• 提供側の意思決定の話。
• 「価値としてこのくらいあるので、このくらいの金額です」という金額設定をする。

画面数の増加はユーザーのメリットにつながりにくいと考えるので、「見積もりのために画面数を増やす」という発想に驚きました。ユーザーへのデメリットにつながる可能性が高いと思うので、この方法に疑問を感じます。

ユーザーのメリットを考えて、なるべく少ない画面で目的が達成できるように設計するほうが良いと考えます。

OOUIデザインは製品開発のどのタイミング、どのスコープに対しておこなうのが良いか？ MVP（Minimum Viable Product）か？

• 最初からやるのが良い。
• スコープ（対象範囲）は、最も小さいものから最も大きいものまで全て。
• プログラムとしては実装できるが、GUI（グラフィカルユーザーインターフェイス）としては表現できないようなものもあるので、最初期から形にするべき（形を設計するべき）。
• なので最初からOOUIにするべき。

理想は最初からオブジェクト指向UIデザインで設計できることです。一貫性や統一感を維持しやすくなって、ユーザーの使いやすさ、品質、開発効率などの向上につながりやすくなると考えます。

オブジェクト指向UI（OOUI）デザインを考慮したUXライティングとは？

• 概念から名詞を見つけ出すこと。
• OOUIと親和性が高い。
• 言葉や概念の単位がインターフェイスのラベリング（名前を決めること）につながる。
• 一貫性があることが理想。
• システム全体で一貫性があり、同期していること。

サービス全体で使う文言の共通化のため、用語の定義と一括管理ができると良いと思います。管理効率化のために一括の変数管理（もしくは定数管理）ができるとより良いです。

プラットフォームによってOOUIに違いはあるか？ 例えばスマートフォン用のOS、カメラのハードとソフトなど

• PCはデータ（オブジェクト）に対してランダムアクセスに対応できる設計が必要。
• スマートフォンはPCに比べると紙芝居方式（一方的な方向の画面）な面あり。

スマートフォンは画面領域の制約上、一方通行的な表現になることはあると思います。ただ前提としてデータへのアクセスのしやすさの観点から、データのアクセスはなるべく双方向性を維持できるように設計したほうが使いやすくなると考えています。

OOUIの手法とドメイン駆動開発は組み合わせられるか？

• 一部は上手く組み合わせられると思う。

ドメイン駆動開発がどういうものか自分が具体的なイメージを持っていないので、これから調べる対象とします。

タスク指向とオブジェクト指向を同居させても良いか？ 例えばメールアドレス変更やサービス登録導線など

• ユーザーの場面ごとに、線形的（フロー的）な流れを部分的に取り入れるのはあり。
• それでも線形なフローはできるだけ短くなるように設計すると良い。

できればオブジェクト指向で設計したいですが、部分的にタスク指向とオブジェクト指向の同居が適した場合もありそうです。

Siriなどの音声エージェント指向とうまく協調できると思うか？

• あまり協調できないと思う。
• 音声エージェントはタスク指向性が高い。
• 今後どのように発展していくのかが気になる。
• オブジェクト指向的な組み合わせになっていくのでは？

音声エージェントをあまり使っていないため判断しずらいですが、データ操作が容易になってくると使いやすくなるのではと思います。

モデル、インタラクション、プレゼンテーションの順番を変えても良いか？

• 変えても良い。

モデル、インタラクション、プレゼンテーションの大きな3分類で工程を分けた際、自分の場合はオブジェクトの抽出とプレゼンテーションから先に進めたほうが理解しやすい（イメージを描きやすい）と感じています。

実際に本書のワークアウトを試してみて感じたのですが、

1. モデル（オブジェクトの抽出）
2. インタラクション（シングル・コレクション遷移の設計）
3. プレゼンテーション（画面レイアウト）

の順序よりも、

1. モデル（オブジェクトの抽出）
2. プレゼンテーション（画面レイアウト）
3. インタラクション（シングル・コレクション遷移の設計）

や

1. プレゼンテーション（画面レイアウト）
2. モデル（オブジェクトの抽出）
3. インタラクション（シングル・コレクション遷移の設計）

などで進め、1〜3を行き来したほうが具体的なイメージとデータや画面遷移としての整合性を維持しやすいと感じる場面が多いです。

モデル抽出の適切な粒度や目安が知りたい

• 自分が良いと感じたものをよく知る。
• 粒度は個々の判断で分かれる。
• 少し汎用性を持たせるのか、少し特化（個別最適化と解釈しました）するかでプロダクトの汎用性が変わっていく。

動詞として捉えられるものはオブジェクトにする必要があるとあったが、ワークアウトの「棚卸し」はどの分類になるか？

• ユーザーがやりたいこと（ものごと）の単位を決める。
• それをオブジェクトにしたときに使いやすいのか、その都度決定していく。

オブジェクト把握のコツが知りたい

• 名詞か動詞かは1つの判断基準になるが、実際の使われ方にもよる。
• ユーザーがオブジェクトとして認識できる単位でオブジェクトとして扱うのが良いかもしれない。
• ユーザーが何を意識するのかが重要。
• 必要な粒度で必要なオブジェクトを抽出する。

経験的にはアプリケーションで「ユーザーが何をどう認識して、何をしたいのか（もしくは何をせずに済んだら嬉しいのか）」に焦点を当てて考えると、見えてきやすいと思います。ワイヤーフレームで検証するとより具現化します。

アクションが「新規作成」の場合の表示形式をどう選べば良いか？

• システム全体として統一できるようにするのが良い。
• 理想はモードレスな振る舞い。
• 「新規作成」アクションの場合はそれが難しい。
• できるかぎりモードレスな振る舞いにできるように、システム全体で統一できると良いのではないか。

「できるかぎりモードレスな振る舞いにできるように、システム全体で統一」という点が特に勉強になりました。

見積書・発注書・納品書などのように、ステータスによって名称が変わるオブジェクトはどう考えれば良いか？

• つくるアプリケーションによって、どの程度汎化するかを都度設計するのが良い。

設定画面はタスク指向になっても良いか？

• 例えばデバイス設定画面はオブジェクトベースになるのでは。

実務でコードを書く機会が少ない（もしくは書けない）デザイナーが、エンジニアと一緒にシステム設計するために必要なことは？

• ソフトウェアがどのような動きになっているのかを知るきっかけになるので、プログラミングはある程度やってみたほうが良い。
• エンジニアとの共通言語ができると良いのでは。
• エンジニアから見たときにも、グラフィックやインターフェイスの知見があると良い。
• クロスオーバー（お互いの境界線を越えて交じり合う）していく。双方向の知見が大事。

繰り返しとなるかもしれませんが、職種を越えてソフトウェアデザイン（アプリケーション設計）に関われたほうが品質を追求しやすく、そもそもつくっていて面白いと感じます。

Webサイト構築を例に挙げると、ビジュアルデザインの際には効率的な実装方法やコンポーネント設計、データ構造や情報設計のことを考えていたり、コーディングの際にはブラウザのレンダリング結果を見ながら余白を調整したり文字の大きさや色を調整したりします。デザインとコーディング（実装）をどちらも行き来しながらつくっている感覚です。

最後に

書籍やソシオメディアのブログで読んだ内容を振り返りつつ、新しい発見ありました。他の受講者からの質問から学べることも多く、回答や質問自体から新たな考え方や視点が生まれたことも収穫です。今後のUIデザインに活かしたいと思います。

Twitterのハッシュタグ「#oouiqa」で検索すると、いろいろな方の質問や回答が見られて勉強になります。