物流配送アプリ x OOUI

はじめに

画面や機能からではなく、ドライバーが扱う「対象」からUIを考え直す

司会

OOUIにおけるUIモデリングについて、どのように理解していますか？

利用者が扱うオブジェクトを見つけ、その関係・状態・操作を整理したうえで、コレクションビューとシングルビューへ落とし込むプロセスだと理解しています。

物流配送アプリの実務事例をもとに、現在の理解で再モデリングします。

【補足】このページで扱うOOUIとは？

OOUI（オブジェクト指向UI）は、操作メニューを先に並べるのではなく、利用者が業務で扱う「対象」を中心にUIを組み立てる設計方法です。

物流配送アプリでは、「配送コース」「訪問先」「配送タスク」「荷物」「配送実績」を対象として整理します。

ドライバーは地図や一覧から訪問先を選び、その訪問先の住所・荷物・注意事項・作業状態を確認して、到着や完了を登録します。

地図・訪問順一覧・検索結果は、複数の訪問先から対象を探すコレクションビュー、詳細画面やボトムシートは、選んだ訪問先を確認・操作するシングルビューとして設計します。

用語の補足

【補足】「コレクションビュー」と「シングルビュー」とは？

対象を探す「コレクションビュー」と、
対象を理解・操作する「シングルビュー」

司会

コレクションビューとシングルビューとは、どのようなものですか？

コレクションビューは、複数のオブジェクトから目的の対象を探し、比較し、選択するための表示です。

シングルビューは、選択したひとつのオブジェクトについて、詳細情報・状態・実行可能な操作を提示する表示です。

複数の対象を探して選ぶ、コレクションビュー

コレクションビューは、同じ種類のオブジェクトを複数まとめて表示し、利用者が目的の対象を見つけるためのビューです。

一般的には、一覧、カード、検索結果、表、カレンダーなどがコレクションビューに該当します。
物流配送アプリでは、次の表示を「訪問先」のコレクションビューとして捉えられます。

• 地図：現在地と複数の訪問先の位置関係から、対象を探す
• 訪問順一覧：配送順序や進捗状態から、次の訪問先を選ぶ
• 検索結果：名称、住所、コードなどから、目的の訪問先を探す
• 未完了一覧：状態を条件に、作業が残っている訪問先を確認する

地図と一覧は見た目が異なりますが、どちらも複数の訪問先を提示し、ひとつの訪問先を選択するためのビューです。
コレクションビューでは、すべての詳細情報を表示するのではなく、対象を識別・比較するために必要な情報を優先します。

• 訪問先名
• 住所や位置
• 時間指定
• 現在の状態
• 配送順序
• 警告や注意事項の有無

ひとつの対象を理解して操作する、シングルビュー

シングルビューは、コレクションビューで選択したひとつのオブジェクトについて、詳しい情報と操作を提示するビューです。

物流配送アプリでは、訪問先を選択した後に表示する詳細画面やボトムシートが、訪問先のシングルビューに該当します。
シングルビューでは、次の情報を扱います。

• 訪問先名と識別情報
• 住所と地図上の位置
• 時間指定
• 荷物と作業内容
• 注意事項
• 現在の業務状態
• 過去の配送実績
• 現在の状態で実行できる操作

操作は独立した機能メニューとして並べるのではなく、対象となる訪問先の近くに配置します。
たとえば、訪問先の状態に応じて、次のような操作を提示します。

• 経路を確認する
• 到着を登録する
• 作業を開始する
• 荷物を確認する
• 作業を完了する
• 問題を報告する

一覧と詳細の間で、同じ対象を扱い続ける

OOUIでは、コレクションビューとシングルビューが、別々の機能として分断されないことが重要です。

利用者が地図や一覧から訪問先を選択した後も、「どの訪問先を扱っているか」という文脈を維持したまま、詳細情報と操作へ移れるようにします。

物流配送アプリで検討したボトムシートは、地図上の訪問先を選択した状態を保ちながら、訪問先の情報量を段階的に増やす構造です。

• 地図：訪問先のコレクションを確認する
• 小さいボトムシート：選択した訪問先の要点を確認する
• 広げたボトムシート：訪問先の詳細と操作を確認する

表示領域が変化しても、扱っているオブジェクトは同じ「訪問先」です。

このように、複数の対象から目的の対象を選び、選択した対象の詳細を理解し、その対象に対して操作する流れをつくることが、OOUIにおける基本的なビュー構造だと理解しています。

実務事例を、現在のOOUIへの理解で振り返る

本記事では、物流領域の複数プロダクトを横断して担当した、ドライバー向けアプリの画面刷新と検索機能の設計を題材にします。

元となる実務事例は、以下のページで紹介しています。

2025.09.23

2026.06.24

保護中: 【toB】物流配送アプリ

...

なお、当時のプロジェクトで「OOUI」という名称の工程を正式に採用していたわけではありません。

そこで本記事では、実務で行った業務理解、情報設計、画面構造の検討を、現在のOOUIへの理解に基づいて再整理し、どのようにUIモデリングへ落とし込めるかを説明します。

実際に行っていないプロセスを後から実績として置き換えるのではなく、既存の設計判断を別の観点から検証し、今後の実務へ応用できる知識にすることを目的としています。

今回の題材で確認すること

• 物流業務に存在するオブジェクト候補をどのように抽出するか
• オブジェクト同士の関係と、親子関係をどのように整理するか
• 中心となるオブジェクトをどのように決めるか
• コレクションビューとシングルビューをどう設計するか
• 状態とアクションを、どのオブジェクトへ所属させるか
• タスクフローとオブジェクト中心の設計をどう使い分けるか

OOUIへの理解

「何をするか」の前に、「何を扱うか」を明確にする

司会

タスク指向のUIと、OOUIにはどのような違いがありますか？

タスク指向では「何をするか」から入口をつくりやすい一方、OOUIでは先に対象を選び、その対象に対して可能な操作を提示します。利用者が実世界で認識している対象と、UI上の構造を近づける考え方です。

操作メニューから始めると、対象が見えにくくなる

物流配送アプリで、次のような操作を最初に並べる設計を考えます。

• 配送を開始する
• 訪問先を検索する
• 注意事項を確認する
• 作業完了を登録する
• 問題を報告する

これらは必要なタスクですが、操作だけを並べると、利用者は「どの訪問先に対する操作なのか」「現在どの配送を扱っているのか」を都度確認しなければなりません。

一方、実際の配送業務では、ドライバーは「次の訪問先」「現在担当しているコース」「この訪問先の荷物」「のように、対象を手がかりに状況を理解しています。

そこでOOUIでは、まず配送コースや訪問先という対象を提示し、その対象を選んだ後に、現在可能な操作を見せる構造を考えます。

名詞を見つけるだけでは、UIモデリングにならない

OOUIでは、業務上の会話やユースケースから名詞を抽出することが出発点になります。
ただし、見つけた名詞をすべて独立したオブジェクトの対象外候補も含まれます。

たとえば「住所」「指定時間」「注意事項」は、最初は訪問先の属性として扱えます。

一方で、複数の訪問先で共有する、履歴を管理する、個別に編集・承認する必要がある場合は、独立したオブジェクトとして扱う可能性があります。

判断する際は、次の観点を確認します。

• その対象を、利用者が独立したものとして認識しているか
• ほかの対象と区別できる識別情報を持つか
• 独自の状態やライフサイクルを持つか
• その対象に対して固有の操作が発生するか
• 一覧と詳細を分けて確認する必要があるか
• ほかのオブジェクトから参照・再利用されるか

名詞の抽出はゴールではなく、利用者が認識している世界を、操作可能なUIの構造へ変換するための仮説づくりに利用しています。

プロジェクト背景

地図と配送情報を行き来する現場で、判断対象を見失わないUIへ

司会

物流配送アプリでは、どのような問題がありましたか？

ドライバーが地図と配送情報を何度も行き来し、現在確認している訪問先と業務情報の関係を保ちにくい状態がありました。また、大量のスポットから目的の訪問先を見つける検索体験も必要でした。

場面によって、必要な情報量が変化する

ドライバーは、配送業務の進行に応じて異なる情報を必要とします。

• 配送開始前：担当コース、訪問先全体、配送順序を確認する
• 移動前：次の訪問先、位置、経路、指定時間を確認する
• 到着前：注意事項、駐車条件、連絡事項を確認する
• 到着後：荷物、個数、作業内容を確認する
• 作業後：完了結果や問題を登録する

同じ訪問先を扱っていても、状況によって確認したい属性と実行したい操作が変わります。

地図画面と詳細画面を完全に分離すると、画面を移動するたびに文脈が切れます。
反対に、すべての情報を地図上へ表示すると、重要な情報が埋もれます。

この課題をOOUIの観点から見ると、必要なのは画面数の調整だけではありません。同じ「訪問先」オブジェクトを扱い続けながら、業務状態に合わせて情報量を切り替えられる構造が必要だと捉えられます。

検索対象も、単なる文字列ではない

新規検索機能では、数万件規模のスポット情報を扱う必要がありました。

利用者が探しているのは、検索キーワードそのものではなく、業務で扱う「訪問先」です。
同じ名称の候補が存在する場合は、住所、コード、担当エリア、関連情報などを手がかりに、目的の訪問先かどうかを判断します。

そのため、検索機能も入力欄の設計だけで終わらせず、訪問先オブジェクトをどの属性で検索し、どの属性で判別し、選択後にどのビューへつなげるかまで考える必要がありました。

モデリング STEP 1

ユースケースから、利用者が扱うオブジェクト候補を抽出する

司会

最初に、どのようなオブジェクトを抽出しましたか？

「ドライバーが担当コースを確認し、次の訪問先へ移動し、荷物と作業内容を確認して、完了結果を登録する」という業務の文章から、対象となる名詞を抽出しました。

業務の文章から、名詞と動詞を分ける

公開可能な情報をもとに、代表的なユースケースを次のように置きました。

ドライバーが担当する配送コースを確認し、次の訪問先と経路を確認する。訪問先へ到着したら、荷物、作業内容、注意事項を確認する。作業が終わったら配送実績を登録し、問題があれば管理者へ報告する。

この文章から、まず次の候補を抽出します。

• 名詞：ドライバー、配送コース、訪問先、経路、荷物、作業内容、注意事項、配送実績、問題、管理者
• 動詞：担当する、確認する、到着する、登録する、報告する

名詞はオブジェクトまたは属性の候補となり、動詞はアクションまたはオブジェクト間の関係を表す候補になります。

オブジェクト候補を、役割ごとに整理する

オブジェクトと属性の境界は、要件によって変わる

「注意事項」は、訪問先に付随する文章として扱うなら属性です。

しかし、複数拠点で共有する、更新履歴を残す、確認済み状態を管理する場合は、独立したオブジェクトとして扱う方が自然です。

同様に、「問題」も単なる配送実績の入力項目で済む場合と、担当者、対応状況、コメント履歴を持つ「インシデント」として管理する場合があります。

この段階で構造を固定せず、業務要件、データ、権限、ライフサイクルを確認しながら境界を調整することが重要です。

モデリング STEP 2

オブジェクト同士の関係を、業務の言葉でつなぐ

司会

オブジェクト同士の関係は、どのように整理しますか？

線を引くだけでなく、「誰が何を担当する」「何が何を含む」「どの操作で何が生成される」という業務上の動詞で関係を説明します。

公開可能な範囲で置いた、関係の仮説

今回の再モデリングでは、次の関係を基本形として置きました。

1. ドライバーが、配送コースを担当する
2. 配送コースが、複数の訪問先を含む
3. 訪問先が、ひとつ以上の配送タスクを持つ
4. 配送タスクが、対象となる荷物を扱う
5. 配送タスクを完了すると、配送実績が記録される
6. 管理者が、配送コースと配送実績を確認する

「訪問先」を中心オブジェクトとして扱う

ドライバー向けアプリでは、中心オブジェクトを「訪問先」と考えました。

理由は、ドライバーの主要な判断と操作が、訪問先を起点にまとまるためです。

• 地図上で位置を確認する
• 次に向かう対象として選ぶ
• 住所や指定時間を確認する
• 荷物や作業内容を確認する
• 到着・作業中・完了などの状態を確認する
• 問題がある場合に報告する

画面を「地図画面」「詳細画面」「完了登録画面」という単位だけで考えるのではなく、ひとつの訪問先を、状況に応じた異なるビューで扱っていると捉えます。

これにより、画面が変わっても同じ対象を操作していることが伝わりやすくなり、情報や操作の所属先も整理しやすくなります。

管理者側では、中心オブジェクトが変わる可能性がある

同じ物流プロダクトでも、ドライバーと管理者では目的や目線が異なるケースもあります。

管理者は、荷量配送全体を比較・調整するため、「配送コース」や「配送実績」が中心になる可能性があります。

OOUIは、プロダクト全体でひとつの中心オブジェクトだけを決めることではありません。利用者の役割と目的によって、入口や優先するビューは変わります。

ただし、ドライバーと管理者が同じ配送コース・訪問先・実績を参照できるよう、オブジェクトの意味と識別方法をそろえることが重要です。

モデリング STEP 3

コレクションとシングルのビューへ落とし込み、対象の同一性を保つ

司会

抽出したオブジェクトを、どのように画面へ落とし込みますか？

複数の対象から選ぶコレクションビューと、選んだ対象を理解・操作するシングルビューを基本にします。物流では、地図も訪問先の空間的なコレクションビューとして扱えます。

訪問先のコレクションビュー

訪問先を複数件まとめて確認するビューには、異なる表現があります。

• 地図：現在地と訪問先の位置関係を理解する
• 訪問順一覧：配送順序と進捗を理解する
• 検索結果：名称や住所などの条件から目的の訪問先を探す
• 未完了一覧：状態を基準に、残っている訪問先を確認する

これらは別々の機能に見えますが、すべて「訪問先の集合を、異なる切り口で提示するビュー」と捉えられます。

訪問先のシングルビュー

ひとつの訪問先を選択した後は、その対象を理解し、必要な操作を行うための情報を提示します。

• 訪問先名と識別情報
• 住所と地図上の位置
• 指定時間と現在の遅延状況
• 荷物と作業内容
• 注意事項
• 現在の業務状態
• 状態に応じて実行できるアクション

シングルビューでは、利用者が「今、どの訪問先を扱っているか」を見失わないよう、名称、位置、状態などの識別情報を一貫して提示します。

地図と詳細を、ボトムシートで連続させる

実務では、地図表示を維持しながら、ボトムシートの表示量を切り替える構造を検討しました。

地図を広く見たいときは情報領域を小さくし、訪問先の詳細を確認したいときはボトムシートを広げます。

OOUIの観点では、これは単なる省スペースのUIではありません。

訪問先という同じオブジェクトを選択した状態のまま、コレクションの文脈とシングルの情報を連続して確認できる構造だと説明できます。

画面を往復して対象を選び直す必要がなく、地図上の位置と業務情報の関係も保ちやすくなります。

情報量は、オブジェクトを変えずに段階化する

熟練ドライバーは、地図と次の訪問先だけを短時間で確認したい場合があります。一方、新任ドライバーは、住所、荷物、作業内容、注意事項まで詳しく確認したい場合があります。

どちらか一方へ情報量を固定するのではなく、同じ訪問先オブジェクトについて、次のように段階的に開示します。

• 最小表示：訪問先名、状態、次の主要操作
• 中間表示：住所、指定時間、注意事項の要約
• 詳細表示：荷物、作業内容、履歴、補助操作

情報を減らすことではなく、利用状況に応じて必要な深さまでアクセスできることを重視しています。

モデリング STEP 4

状態とアクションを、対象となるオブジェクトへ所属させる

司会

アクションは、どのように配置しますか？

操作を独立したメニューとして並べるのではなく、対象の詳細と現在状態に応じて提示します。「訪問先を選ぶ→その訪問先で可能な操作を行う」という流れです。

状態によって、必要な情報と操作が変わる

訪問先は、業務の進行に伴って状態が変わります。

主要操作と補助操作を分ける

スマートフォンの限られた画面に、すべての操作を同じ強さで並べると、次に行うべき操作がわかりにくくなります。

そこで、現在状態を前提に、主要操作と補助操作を分けます。

• 主要操作：現在の業務を次の状態へ進める操作
• 補助操作：詳細確認、連絡、履歴確認など、必要時に使う操作
• 例外操作：保留、取り消し、問題報告など、通常フローから外れる操作

「完了する」ボタンを常に表示するのではなく、訪問先へ到着し、必要な作業を開始した状態で提示するなど、オブジェクトの状態と操作可能条件を一致させます。

状態は、色だけに依存させない

配送業務では、完了、警告、遅延、問題ありなどの状態を短時間で判断する必要があります。

色だけで状態を区別すると、利用環境や色覚特性によって判別しにくくなる可能性があります。そのため、色に加えて、ラベル、アイコン、文章、配置を組み合わせます。

同じ状態は、地図、一覧、詳細、管理画面でも同じ意味と表現を利用し、ビューが変わっても利用者の理解が変わらないようにします。

検索体験

検索を独立機能ではなく、目的のオブジェクトへ到達する入口として設計する

司会

数万件規模のスポット検索にも、OOUIの考え方を活かせますか？

はい。検索対象を「文字列」ではなく「訪問先オブジェクト」と捉えることで、検索対象、候補の判別情報、選択後の遷移を一続きで設計できます。

検索結果で、オブジェクトを識別できること

名称だけを表示した検索結果では、同名のスポットや似た名称の候補を見分けられません。

そこで、利用者が候補を判別するときの手がかりを整理します。

• 訪問先名
• 住所
• 識別コード
• 担当エリア
• 現在の配送コースとの関係
• 訪問状態
• 必要に応じた関連情報

すべてを表示すると一覧性が下がるため、候補を識別するうえで重要な属性を優先し、詳細情報は選択後のシングルビューへ分けます。

検索前・検索中・検索後を、状態として整理する

検索体験には、結果一覧だけでなく複数の状態があります。

• 入力前の初期状態
• 入力途中で候補がある状態
• 候補が多すぎる状態
• 検索結果が0件の状態
• 通信・取得に失敗した状態
• 訪問先を選択した状態

それぞれの状態で、利用者が次に取れる行動を用意します。候補が多い場合は絞り込みを促し、0件の場合は条件変更や表記確認へつなげます。

訪問先を選択した後は、検索機能内に閉じず、同じ訪問先のシングルビューへ遷移します。検索は目的地ではなく、オブジェクトへ到達するための入口です。

一貫性と運用

オブジェクトの意味・状態・操作を、プロダクト横断で再現できるルールへ

司会

OOUIとデザインシステムは、どのように関係しますか？

OOUIが対象と関係を整理するのに対し、デザインシステムは、その意味や状態を複数画面で一貫して表現・実装するための基盤になります。両方を接続することで、構造と表現のずれを減らせます。デザイントークンもその一部です。

同じ意味を、同じ表現で伝える

実務では、デザイントークン、コンポーネント、状態表現、利用ルールの整理も担当しました。

OOUIで訪問先や配送タスクの状態を定義しても、画面ごとに異なる色やラベルで表現されると、利用者は同じ状態として認識しにくくなります。

そこで、次の項目を横断的にそろえます。

• 未訪問、作業中、完了、警告などの状態名称
• 状態に利用するSemantic Token
• 主要操作と補助操作のボタン表現
• 訪問先カードや検索結果行の基本構造
• 空状態、エラー、読込中などの例外状態
• 操作可能・操作不可の条件

コンポーネントを、見た目だけで標準化しない

カードやボタンの外観だけを共通化しても、使い分けが定義されていなければ、画面ごとに意味が変わります。

たとえば、訪問先カードには何を必ず表示するのか、どの状態で主要操作を出すのか、警告がある場合にどの位置へ表示するのかを、利用条件と合わせて定義します。

オブジェクトモデル、ビュー、コンポーネント、実装上の状態をつなげることで、デザイナーとエンジニアが同じ言葉で仕様を確認しやすくなります。

使い分け

OOUIだけで完結させず、業務フロー・安全性・例外処理と組み合わせる

司会

すべてをオブジェクト中心に設計すればよいのでしょうか？

いいえ。OOUIは強力な整理方法ですが、業務の順序、安全確認、入力完了条件などはタスクフローでも確認します。目的に応じて組み合わせることが重要です。

順序を守る必要がある業務では、タスクフローも必要

配送業務には、自由に操作できる方がよい場面と、順序や確認を守る必要がある場面があります。

たとえば、配送完了を登録する前に、荷物の照合や必須項目の入力が必要な場合があります。誤った訪問先へ完了実績を登録すると、業務や顧客対応へ影響します。

そのため、次の観点はタスクフローや状態遷移でも確認します。

• 作業開始前に確認すべき条件
• 完了前に必須となる入力
• 操作を戻せる範囲
• オフライン・通信失敗時の扱い
• 誤操作を防ぐ確認方法
• 問題発生時の報告と復帰経路

オブジェクトモデルを土台に、重要なタスクを検証する

私の理解では、OOUIとタスクフローは対立するものではありません。

まずオブジェクトモデルによって、利用者が扱う対象とその関係を安定させます。そのうえで、重要な業務シナリオをタスクフローとして通し、必要な情報、状態、例外処理が不足していないかを確認します。

1. オブジェクト候補と関係を整理する
2. コレクションとシングルのビューを設計する
3. 状態に応じたアクションを定義する
4. 主要ユースケースをタスクフローで通す
5. 迷い、誤操作、例外状態をプロトタイプで確認する
6. 検証結果を、モデルとビューへ戻して改善する

OOUIを形式的に適用するのではなく、利用環境と業務リスクに合わせて使うことを大切にしたいと考えています。

検証

モデルが正しいかは、利用者の理解と行動から検証する

司会

作成したオブジェクトモデルは、どのように検証しますか？

図として整っているかではなく、利用者が対象を理解し、迷わず見つけ、適切な操作を選べるかで検証します。業務担当者との言葉の一致も確認します。

業務担当者と、言葉と関係を確認する

モデリングの初期段階では、PO、PdM、エンジニア、現場理解のある担当者と、次の内容を確認します。

• オブジェクトの名称が、現場で使われている言葉と一致しているか
• 同じ名称を、異なる意味で使っていないか
• 親子関係や所属関係に例外がないか
• 状態の変化と、変更できる権限が正しいか
• オブジェクトと属性の分け方が、実際の運用に合っているか
• 将来的な機能追加でも構造を維持できるか

プロトタイプで確認したいこと

• ドライバーが次の訪問先を短時間で見つけられるか
• 地図上の訪問先と、詳細情報の対応を理解できるか
• 現在どの訪問先を操作しているか見失わないか
• 訪問先の状態と、次に行うべき操作を理解できるか
• 同名の検索候補を必要な属性から判別できるか
• 通常フローから外れた場合に、報告や復帰ができるか

成果を確認するための指標

守秘義務に配慮しながら、実務では定性・定量の両面で次のような変化を確認したいと考えます。

• 目的の訪問先へ到達するまでの時間と操作数
• 地図と詳細の不要な往復回数
• 訪問先や荷物の取り違えにつながる操作ミス
• 検索結果から目的の候補を選べた割合
• 完了登録や問題報告で発生する入力エラー
• 新任ドライバーが操作を理解するまでの時間
• 管理者・サポートへの問い合わせ内容

モデルは一度作って完成ではありません。検証で見つかった理解のずれを、オブジェクトの名称、境界、関係、ビュー、アクションへ戻して改善します。

学びと関心

画面遷移を減らすだけでなく、利用者が認識する世界をUIへ反映する

司会

今回の再モデリングから、どのような学びがありましたか？

地図と詳細を一体化した理由を、画面遷移の削減だけでなく、「訪問先という同じ対象を扱い続けるため」と説明できるようになりました。設計判断の再現性を高める視点だと感じています。

既存の設計判断を、別の角度から説明できた

実務では、配送ユースケース、情報量、利用環境をもとに、地図と詳細情報を行き来しやすい構造を検討しました。

OOUIの観点で振り返ると、その判断を次のように説明できます。

• 地図と一覧は、訪問先のコレクションビューである
• ボトムシートは、選択した訪問先のシングルビューである
• 表示量が変わっても、扱っている訪問先は同じである
• 到着・作業中・完了は、訪問先または配送タスクの状態である
• 検索は、目的の訪問先へ到達するための入口である

「画面を使いやすくした」という説明だけでなく、対象・関係・状態に基づいて、なぜその画面構造にしたのかを言語化しやすくなりました。

複雑なBtoBプロダクトほど、共通言語が重要

BtoBプロダクトでは、機能、権限、データ、例外状態が増えやすく、画面単位の議論だけでは全体の整合性を保ちにくくなります。

オブジェクトモデルを共通資料にすることで、デザイナー、エンジニア、PO、QAが、同じ対象と状態について会話しやすくなります。

また、新しい機能を追加するときも、「新しい画面をどこへ置くか」だけでなく、「既存のどのオブジェクトに属する情報・操作なのか」「新しいオブジェクトとして扱う必要があるか」を検討できます。

今後、さらに深めたいこと

今回の整理を出発点として、次の領域も実務の中で深めたいと考えています。

• オブジェクトの粒度と境界を、データモデルとどこまで接続するか
• 役割・権限ごとに異なるビューとアクションの設計
• 複雑な状態遷移と、例外処理のモデリング
• オブジェクトモデルとデザインシステムの接続
• モデリング段階からエンジニア・ドメイン有識者と協働する方法
• ユーザーテストの結果をモデルへ反映する方法

まとめ

訪問先を中心に、情報・状態・操作がつながるUIを設計する

今回のUIモデリングで整理したこと

物流配送アプリをOOUIの観点から再モデリングし、次のように整理しました。

• 業務の文章から、配送コース、訪問先、配送タスク、荷物、配送実績などを抽出する
• 名詞をすべて独立させず、識別情報、状態、操作、ライフサイクルから境界を判断する
• ドライバー向けアプリでは、主要な判断と操作が集まる「訪問先」を中心に置く
• 地図、一覧、検索結果を、訪問先のコレクションビューとして捉える
• ボトムシートと詳細画面を、訪問先のシングルビューとして捉える
• 未訪問、移動中、到着済み、作業中、完了などの状態に応じて操作を提示する
• 検索を、目的の訪問先へ到達する入口として設計する
• 重要な業務順序と例外処理は、タスクフローや状態遷移でも検証する

OOUIを、設計判断を共有するための方法として活かす

私がOOUIに関心を持つ理由は、画面を作る前に、利用者が何を対象として認識し、どのような関係の中で操作しているのかを整理できるためです。

UIを画面一覧や機能一覧だけで捉えると、機能追加のたびに構造が複雑になる可能性があります。

一方、オブジェクト、関係、状態、アクションを共通言語として持つことで、新しい要件を既存構造のどこへ接続するかを判断しやすくなります。

利用者が認識する対象を起点に、情報と操作を一貫して設計し、チームが同じ構造を共有できる状態をつくること。

この考え方を、今後のBtoBプロダクトや複雑な業務システムの設計でも活かしていきたいと考えています。