全3回のUX/UIワークショップで、プロジェクトを前に進める共通言語を獲得

当社ではUX/UIについて体系的に学ぶ機会が少なく、システム開発の際には各担当者が必要に応じて改修を重ねてきました。そのため、全体を通しての統一感が不足していたり、若手社員がシステムの使い方でつまずいたりすることがありました。UX/UIという言葉は知っていても、それをどう捉え、日々の仕事にどう取り入れればよいのかが分かっていなかったんです。

社内の担当者からアイスリーデザインさんの評判を聞いたことがあったんです。UIデザインの専門書を出版されていたことも、UIを深く理解している会社としての信頼につながり、今回ご相談しました。

ご相談をいただいた当初は、見た目の良し悪しを学ぶ座学も想定されていたと思います。ただ、それだけで社内プロジェクトに活かせるのかという疑問がありました。デザインの統一や使いやすさの改善は後回しになりやすいので、その状況をどう乗り越えるかが重要だと考え、UX/UIの基礎だけでなく、関係者との合意形成やプロジェクトマネジメントの考え方もプログラムに盛り込みました。

デザイナーではないさまざまな職種の方を対象に、UXを中心としたワークショップを行うのは、私たちにとっても新しい挑戦でした。

アイスリーデザインのUI専門書のノウハウを活用し、JTBビジネストラベルソリューションズ様が普段使っている画面を実際に診断するプログラムにしました。午前中はUI・UX・ユーザビリティの違いや基本概念を共有し、午後は評価観点をまとめたチェックリストで実際の画面を診断していただきました。

ユーザビリティの原則には「一貫性と標準化」のように専門的な言葉もありますが、「同じ意味のボタンが別の場所に点在している」「同じ操作なのに表記が異なる」といった具体例に置き換え、参加者が自分の目で判断できるようにしました。皆さんは画面上に多くの付箋を貼りながら、「これは実は同じ機能ではないか」「なぜここだけ違うのか」と次々に発見してくださいました。

基本的な考え方を学んだうえで改めて画面を見ると、使いづらさが可視化されました。私はシステムを使い慣れていますが、使ったことのないメンバーからは「これは何のためのボタンなのか」といった素朴な疑問が出ました。普段使っているシステムを、新鮮な目線で捉え直せたことが大きかったです。

新鮮だったのは、UIとUXをひとまとめにするのではなく、まずUXが重要だと教えていただいたことです。診断パートでは、「何となく使いづらい」と感じていたデザインについて、なぜそう感じるのかを言語化できました。同時に、長年の業務知識や情報が蓄積されていることには価値があり、それをどう整理し分かりやすく届けるかが重要なのだと気づきました。

第1回でシステムの課題について共通認識ができたので、第2回では「プロジェクトとしてどうコミュニケーションを取るか」に焦点を当てました。前半のステークホルダーマップでは、今回のテーマとしたシステムの利害関係者をすべて洗い出し、現状の関係性と理想的なコミュニケーションのあり方を整理しました。後半のサービスブループリントでは、利用者の行動を起点に、関係者やシステム、データがどう関わるかを1つの図にまとめていきました。

ステークホルダーの洗い出しでは、「この立場ならこういう意見が出る」「この外部パートナーには早めに話を通した方がよい」と、かなり具体的な議論ができました。普段システムを使っているだけでは見えにくい、裏側で調整しているIT部門の仕事についても理解が深まり、関係者を広く捉えるきっかけになりました。

私は今回題材にした業務を担当した経験がなく、業務の流れを十分に理解できていない部分がありました。サービスブループリントを作ることで全体像を改めて整理できましたし、自分たちの日々の業務に関わるテーマだったからこそ、参加者全員が自分ごととして考えられたのだと思います。

多様な部門から参加した意味も、このワークで強く感じました。自分だけでは気づけなかった関係者や「この人たちも関わってくるのか」という視点が、他部門のメンバーから出てきたんです。

第3回は全3回の総仕上げとして、「プロジェクト憲章」の策定に取り組みました。プロジェクト憲章は、基本理念や迷った時に立ち返る原則のようなものです。プロジェクトを実施する際に達成したいことや、大切にしたい想いを自分たちの言葉で表現していただきました。

どのようなプロジェクトにおいても、社内で合意形成がうまくいかず、途中で進められなくなることは珍しくありません。UIやUXの話を前に進めるためにも、社内でどのようなリスクが起こり得るかを把握し、プロジェクトの軸を作っておく必要があると考え、リスクマネジメントの考え方も取り入れました。

リスクマネジメントでは、「当社ではこういうことが起こりがちだ」と参加者同士で共感しながら議論が進みました。何かを変える場面では社内では大きな反応が起きやすい。その対応策を考えるための道筋を示していただきました。

プロジェクト憲章のワークでは、かなり白熱した議論になりました。参加者が大切にしたいことは少しずつ違うので、「この言葉を選ぶと、この要素が抜けてしまう」「ここだけは入れたい」と。大変ではありましたが、最後にはチーム全体が納得できる形にまとまりました。

リスクを考えるワークでは、「この立場の人なら、こういうことを言うかもしれない」と想像しながら進めました。その視点は、日々の業務の中でも活かされています。「相手にはこういう懸念があるかもしれないから、早めに話しておこう」という意見が、メンバーから自然に出るようになりました。

プロジェクト憲章は、迷ったり「そもそも何を実現したかったのか」が分からなくなった時に立ち返る指標です。その重要性を実感しましたし、UX/UIに限らず様々なプロジェクトにも応用できる考え方だと思います。

あるべき姿をきちんと考え、筋道を立てて進める姿勢が強くなりました。「この関係者には先に話を通した方がよい」「この人の意見を早めに取り入れないと、後で難しくなる」といった話が、社内で自然に出るようになっています。

以前は「この画面を変えたい」というピンポイントな話から議論が始まることがありました。ワークショップを経て、「そもそも私たちが実現したいことは何か」と考え、チームの思想を合わせられるようになりました。UX/UIの知識だけではなく、プロジェクトを前に進めるための土台ができたと思います。

たとえば資料を1つ作る時にも、読み手にとってどうすれば分かりやすいかという観点を持てるようになりました。幅広い部門のメンバーが参加したので、それぞれが日々の業務の中でUX/UIの考え方を広げていけると思います。

最後に作ったプロジェクト憲章も、作って終わりではなく、考え方を伝え続けることが大切だと感じています。今後、何かを改善する時に、共通の原則に基づいて判断していると説明できる、その土台を作れたことは私たちにとって重要です。

当初予定されていたUX/UIだけでなく、プロジェクトの進め方そのものを学べた、とても良い機会となりました。

業務システムの使いやすさについて、捉え方が変わりました。一般向けのサービスなら説明なしで使えることが重視されますが、社内の業務システムでは、誰がどのような知識を持って使うのかを踏まえた設計が必要です。その前提から捉え直せたことが大きな学びでした。