ハンディ」のUXデザインとアプリ開発を担当している長嶋です。私はアプリケーションエンジニアとして4年間プロダクト開発に携わって来たのですが、よりユーザーに近いところで価値を創ってみたいと思い、2019年4月からUXデザインの業務も担当しています。ハンディ」チームがどのように克服しているか紹介しようと思います。ハンディ」は飲食店向けの業務支援プロダクトです。詳細はこちらをご覧ください。カンタンにするオーダーエントリーシステムです。お客様をおもてなしする飲食店の一連のairregi.jpエンジニアの私が初めて要件定義をして「飲食店のスタッフが時間帯ごとの売上や客単価を知るのが難しい」という課題を解決すべく、初めて要件定義を行いました。私たちのチームでは要件定義をする際に下図のフローに沿って検討を進めます。1チームで前提事項のすり合わせを行います。2入手済みのファクトを元に現状の課題の整理を行います。3課題から根底にはどのような問題が発生していて、ユーザーにどのような影響を与えているか明らかにします。4課題から想定されるユースケースを洗い出します。ファクトから既に分かっているユースケースがあればそれも含めて整理します。6ユースケースを踏まえて解決策を洗い出し、あらかじめ定義した評価軸を元に解決策の選定を行います。7選定した解決策を画面要件を詰めます。8最後に検証設計を行います。要件定義する中で感じた"判断"の難しさ担当案件のUXデザインを考える中で特に難しく感じたのは、解決案を評価するところでした。要件定義する過程で画面のレイアウトパターンや必要な機能などを考えて解決案を洗い出すことはできましたが、様々な評価軸を元に解決策の選定を行うところでつまづきました。評価軸の性質や量が今まで行なってきたエンジニアリング領域で定義するものとは異なるため、ユースケースを踏まえた評価軸の洗い出しや優先度付けに難しさを感じました。解決案を評価するための整理イメージ判断が難しい理由1:外向きの不確定要素を持つ評価軸が多い不確定なものエンジニアリングにおいて不確定要素の多い評価軸として例えば、システムの拡張性が挙げられます。将来的にシステムの複雑度がどんどん増すと想定される中で、どのような設計やデータ構造にすれば良いか考えます。UXデザインではユーザーの行動や考えが不確定要素に当たると思います。確定方法では、次にどのように不確定要素を確定させているのか説明します。エンジニアリングでは将来的にプロダクトの進む道をプロダクトマネージャーやメンバーと十分認識合わせをして、プロダクトの進化にあった設計やデータ構造を考えます。そのときに既存システムがどのようになっているか熟知している必要があります。UXデザインでは、ユーザーにヒアリングしたり行動履歴を分析して、不確定要素を明確にします。チームが持っている情報だけでは判断を下すには不十分なケースが多いということが言えます。チームの外からも情報を集め、解決策の優劣を評価しなければならない点が、判断を難しくしている要因と言えるでしょう。開発は主に内部のチームメンバーが関係者になり、心理的な距離感が近いため確認や合意形成はしやすい傾向にあります。システム面として、先が見えにくく一度決めたら変更が難しいものに対して、工数や拡張性などを天秤にかけて最良の選択をしなければならない大変さがあります。UXデザインは、外部環境に属するユーザーが関係者であり、そもそもバックグラウンドが異なるため、どうしても解釈が曖昧になってしまうことがあります。距離感のある不確定要素に対して確からしさを担保しつつ評価軸を定めることに難しさがあります。その評価軸の確からしさの程度をあげるためにも、ユーザーの真意を汲み取るために深いユーザー理解やユーザー視点で物事を考える力が必要になります。評価軸の優先度付けが難しい評価軸の優先度付けが難しい根本的な要因として2つあると思います。1つは解決案を選定する際に考慮すべき判断軸が多いことです。ユーザーを取り巻く環境や行動の分だけユースケースが考えられます。解決案がユースケースを満たしているか考えるためユースケースの数だけ評価軸は増えることになります。評価軸が増えると、それぞれを意識しながら優先度を決める必要があるので一層優先度付けが難しくなります。開発では何かを決める際に必要となる評価軸のセオリーがおおよそ決まっているため、ユースケースごと比較することの難しさを感じました。(もちろん、プロダクトのKPIがどれだけ明確になっているかや開発フェーズ、規模感などによって難易度は異なりますが)もう一点難しいと思っているのは、メンバーによって前提の置き方や背景となる知識に違いがあるときに、その差分を埋めて共通認識できている状態に昇華させていくことです。開発でもあることですが、メンバー間ですでに形成されている暗黙知が評価軸の優先度付けに知らないうちに反映されていることがあります。それをコミュニケーションを取る中でいかに汲み取るかが大事だと感じました。ハンディ」チームでは"判断"の曖昧性を出来るだけ回避するために、重要なユースケースと案件ゴールの目線合わせをすることで曖昧な論点への判断をスムーズに行えるように工夫しています。実際に行なっていることを3点紹介します。ユースケースの洗い出し既にある知見があるとき過去案件でヒアリングした内容は全てあとで見返せる形でストックしており、誰でも確認できる状態になっています。関連案件があればそのときに収集したヒアリングの内容を見てクライアントがどんなことを考えて業務を行なっているかイメージするようにしています。実例:過去案件リリース後に行ったヒアリングの記録シート知見がないとき知見がなければ直接訪問してユーザーヒアリングを行なったり業務の観察を行うことでユーザーの行動や考えを知るようにしています。ユースケースに確証がないときはユーザーアクションログを見て定量的に判断します。細かいアクションを観察できるようにするために全てのアクションのログを収集しています。ハンディ」チームでは定量データを元に、想定しているユースケースが本当に存在するか、分析して明らかにする取り組みも行なっています。下の表は、客が来店した10分以内に席を連結したケースの割合を指しています。一度にたくさんの客が来店したときは人数に合わせて、都度複雑な席連結の操作を行なっているのではないかという仮説を立証したケースになります。ハンディ」チームのUXメンバーが大切にしていることだと感じました。案件の中でユースケースを整理する際に、ユーザーが何を考えてどのような行動をするか一つ一つ整理した上でチームに共有し、ユースケースの確実性について認識を揃えます。このフェーズで徹底して認識を合わせられると、後にチームで納得感を持って解決策を選定することに繋がります。実例:今回担当した案件からまず想定し得るユースケースを洗い出して信憑度を設定し仮説を立てました。チームと信憑度の認識をすり合わせた後に、実際のユーザーにヒアリングをしたりプロトタイプを見せながら仮説を検証しました。ここで当初全く想定していなかったユースケースを発見できたり、最初に大事だと仮定していたものよりも更に重要なユースケースが見つかりました。その後、検証内容をもとにチームでユースケースの優先度を設定します。ユーザーをどのような状態に導くか設定するユースケースの認識合わせが完了したら、対象の画面や機能で一番大事にすること・ユーザーがどのような状態になって欲しいのかを言語化します。ユーザーの達成状態を明確化しチームで共通認識することで、それが一番守るべき軸となるため、新しいユースケースやレイアウトパターン等の評価軸が出てきたとしても評価軸がブレにくいため、メンバー全体が納得した状態で解決策の選定を行うことができます。UXデザインをする中で感じたこと開発をメインに行っていたときは、システム的な観点やプロダクトの使いやすさなどを特に意識してプロダクト開発を行っていました。そこからエンジニアの私が、今回UXデザインを経験する中で、ユースケースを探索することの難しさに直面したり、ユーザーに寄り添ったサービスを作るには深い顧客理解も不可欠なことを痛感しました。UXデザインとエンジニアリングのどちらも経験した今、立ち返ってみるとプロダクトは役割が異なる人たちの個々の強みが合わさって成るものだと改めて実感しました。役割は違えど、それぞれが顧客のことを真に理解していたら、それぞれの強みが良い方向に多角的に作用し、結果的にユーザーの行動や考えに沿ったプロダクトになるのだと思います。UXデザインとエンジニアリングの性質の違いから難しさを感じることはありますが、今後開発者としての視点も持ち合わせながらUXデザイナーとして様々な視点からプロダクトを見れるように精進します。ハンディ」では案件の解決策を考える際に評価軸や不確定要素が多くてもできるだけスムーズに解決案を絞り素早く世の中に送り出す工夫を行なっています。ハンディ」にも限らずリクルートライフスタイルではUXを検討する際に一つ一つの詳細までこだわりながらユーザーの行動や考えに沿ったプロダクトを作っています。何か解決案を決める際に同様のことで悩んでいる方がございましたら、参考になると幸いです。UXデザイングループが運営する公式noteです。