なぜ今、「構造」を先に人が決めるのか
プロダクトマネージャーなら、こんな経験があるはずです。
対応するプロダクトが大きくなるほど、チームは担当領域ごとに分かれていきます。それぞれが自分の領域に集中するあまり、プロダクト全体としてどうあるべきかという視点が抜け落ちてしまいます。
- 「更新」「変更」が生じた際、影響範囲の確認に時間がかかり、抜け漏れも起きやすい。機能一覧や画面項目書は数が多く、関連性が確認しにくい
- 仕様は合意したはずなのに、開発が進むにつれて認識のズレが見つかり、実装段階で手戻りが発生する
- 同じ言葉を使っているのに、人によって指している範囲が違う
これは、個人の能力不足やコミュニケーション不足の問題ではありません。チーム全員が同じ「プロダクトの地図」、つまり構造の認識を持っていないことから来ています。ツールがどれだけ進化しても、この問題は解消されません。
AIが開発現場に浸透するにつれて、この問題はより鮮明になります。だからこそ今、「構造」を先に人が定義することが重要になります。
本連載では、この「プロダクトの地図」をどう作るかを、全4回にわたって解説していきます。扱うのは、「OOUX（Object-Oriented UX：オブジェクト指向UX）」というアプローチをベースにした情報構造設計の考え方と手順です。
OOUXとは、プロダクトが扱う対象（オブジェクト）を起点に、情報の関係性や構造を整理していく設計思想です。グローバルの先進的なプロダクト開発現場では実践が進んでいますが、日本ではまだあまり知られていません。
AIに何を任せるかではなく、人間が何を決めるべきなのか。その答えを、一緒に考えていきたいと思います。
その「被害報告」は、本当に一つですか
デジタルサービスの設計・開発を手がける株式会社PIVOTで、UX/UIデザイナーとしてシステム開発に携わる私が経験した、あるリニューアルプロジェクトでのことです。
そのシステムには「被害報告」という情報がありました。しかし、一つの言葉の背後には本来は別々に定義すべき「対象＝Object」が存在していました。
職種によって報告する内容が異なり、取るべきアクションも業務フローも違います。例えば、道路上点検では作業員の位置情報がそのまま点検の進捗として記録されていました。一方、施設点検では建物内の設備に対するステータスを手動で更新していきました。同じ名前でも、内容もフローも異なる以上、これらは本来別々のオブジェクトとして定義されるべきものでした。にもかかわらず、それらは「被害報告」という同じ「対象」として扱われ、開発が進んでいました。
実はクライアント側でも、職種をまたいでそれぞれの業務フローについて深く話し合われることがなく、インタビューの場が初めてクライアント社内で互いの職種のフローを知る機会となりました。
一つの言葉の下に異なる「対象」が混在したまま開発が進んだ結果、誰の期待にも沿わないシステムができあがっていました。
これは特殊な事例ではありません。プロダクト開発の現場では、同じ言葉が人によって全く違う対象を指しているということが日常的に起きています。そしてその状態のまま開発が進むと、システムはどうなるでしょうか。
こうした状況の行き着く先が、いわゆる「フランケンシュタイン型」のシステムです。それは機能だけが継ぎ足されていった、画面や開発都合で構成された物体です。「この画面でもあの情報を見たい」「モーダル（ウインドウ）を開けばいい」「とりあえずここに置いた」など。知る人ぞ知る機能が積み重なり、ユーザーは画面単位で使い方を覚えなければならなくなります。
特に業務システムのような専門アプリケーションでは、この問題がより深刻になります。ECサイトの「商品」や「カート」であれば、ある程度の共通認識が最初から存在します。しかし業務システムが扱う概念、例えば「案件」「稟議」「契約」は組織やビジネスによって意味が異なるからこそ、定義と一貫性がシステムの使いやすさを左右します。
「対象」の振る舞いがシステム内で一貫していなければ、ユーザーはその都度例外ルールを覚えさせられることになります。言うまでもなく操作スピードは落ち、初めて使うユーザーは慣れるのに時間がかかります。本来、自分の業務を助けるために導入されたはずの「ツール」を、ユーザーはいつしか嫌い、信頼を失っていきます。
では、どうすればこの悪循環を断ち切れるのでしょうか。手がかりは、画面を作り始めるよりも前の段階にありました。
