LoginSignup
10
1

More than 1 year has passed since last update.

@kitaharamikiya

デザイナーとエンジニアの対話で、UX/UI の意思決定のボトルネックを解消する

Last updated at Posted at 2021-12-11

Classiでモバイルアプリチームの責任者兼Androidアプリエンジニア担当の @kitaharamikiya です。

この記事は Classi developers Advent Calendar 2021 12日目です。前回は、 onigraさんのEC2からECSへ移行する道のりでした。

背景

モバイルアプリチームは、プロダクトオーナー・デザイナー・エンジニアの10数名ほどのメンバーと共にモバイルアプリの価値を最大化することに責任を持ったチームではありますが、最近特にデザイナーとエンジニアとの間で認識齟齬が発生したり意思決定が遅いという問題が発生してました。

認識齟齬や意思決定の遅さが発生する原因を俯瞰してみたところ、以下のような課題が見えてきました。

  • デザイナーとエンジニアとの会話の機会が少ない
  • 私自身がAndroidアプリでのUI実装経験があるのでデザインについてわかっているつもりだった
  • デザイナーとエンジニアとの間で前提知識が揃っていなかった

今回は、私達のチームでどんな衝突があったか、またそれを解決するために学習したことを紹介します。

課題1. デュアルトラック・アジャイルのアンチパターンを踏み抜いていた

発生した事象

名著 リーンUX で紹介されている デュアルトラック・アジャイル 1 を行いました。
これはリーンUXにも記載してあるのですが、チーム内で、ディスカバリの担当者をプロダクトオーナー・デザイナーに、デリバリーの担当者をエンジニアに、というように完全に分けるのは悪手です。

このようなチームになると以下のような弊害があるとのことです：

  • ドキュメントは各職能において必要な項目が書かれていないことがあるので書き直しが必要になります
  • そのドキュメントを通じてコミュニケーションやミーティングが増え都度同じことを共有する必要が発生します
  • その結果、共通理解が薄れ意思決定が遅くなり、チームの結束力、生産性、学習能力が低下します。

まさにこのような状態に陥りました。

実は、ディスカバリとデリバリーを分ける前には1つのチームでディスカバリフェーズも体験していたことはありますが、ディスカバリ・フェーズのタイムボックスを決めてなくて無限の時間を費やしてしまうのでなんとか開発するものが決まっても、デリバリーの時間がなくなってしまうことが課題でした。

そこで、デリバリーにも対応できるようにリーンUXで紹介されていたデュアルトラック・アジャイルを導入をしました。専門分野を職能ごとで対応することにより特定の仕事に集中でき並行でモノゴトが進むことでスピード感が得られると考えていたかと思います。
しかしながら、アンチパターンの部分を理解しておらず表面上の知識のみで導入してしまったことで、結局デザイナーとエンジニアが完全に分かれるチームになって、話し合う時間がなくなりチーム全体が停滞してしまいました。

対応

デュアルトラック・アジャイルを導入する前後の課題として、デザイナーとエンジニアで目的や前提知識を共通理解にするという対話ができていないことであると考えました。

解決策として、あらためて1つのチームに戻し現在はSlackのハドルやoViceなどを利用してまずは気軽に対話を行える環境を整え、コミュニケーションをとる時間を明確に取るようになりました。
また、デュアルトラック・アジャイルに限らずですが知識をチームを取り入れる場合は、第一人者の情報や複数な書籍を読み込み得た知見を共有・議論してチームメンバー共通の知識にすることが必要です。

課題2. ユーザビリティとはなんなのかの定義が揃っていなかった

発生した事象

UIデザインをデザイナーとエンジニアで会話するときに平行線になることがありました。
どちらの立場でも、ユーザビリティを良くしたいと感じられるのですが議論がまとまりません。
この原因を考えてみたところ、

  • ユーザビリティにはいくつかの特性があり、特性はそれぞれの定義によって異なっている
  • 各メンバーが重点においているユーザービリティの定義と特性がバラバラで噛み合わない

の2つの課題があるように思えました。

対応

ユーザビリティにはどの定義を使うにしてもそれぞれの特性があります。今話しているのはどの項目かを意識しているかによって「ユーザビリティ」という言葉の意味は違ってきます。まずはユーザビリティの代表的な定義の認識を揃える必要があります。

「今ここで考えるべき、ユーザビリティは、◯◯の定義の××の特性について話します。」と明確に宣言することで対話が進むと考えられます。
これらの知識は、デザイナーだけでなくメンバー全員で認識を揃えるとより効果が高くなるので、定期的に勉強会を開いたり社内ブログ等で共有するようにしております。

学習したこと

  • ヤコブ・ニールセンは、インタフェースのユーザビリティについて、5つの特性を示しています。

    • 学習しやすさ
    • 効率性
    • 記憶しやすさ
    • エラー (発生率の低下と復旧力)
    • 主観的満足度

  • ISO 9241-11 では「ある製品が、特定の利用者に、特定の利用の状況下で、特定の目的を達成するために用いられる際の、有効さ、効率、ユーザーの満足度の度合い」と定義されています

    • 有効さ：目的は達成できたのかどうか？と目的は意図通りに達成できたのかどうか？
    • 効率：目的を達成するために費やした資源 (時間など)
    • 満足度：目的を達成するための過程および利用後の、ユーザーの身体的や認知的、感情的な受け止め方

  • ISO 25010 では、システム/ソフトウェアの製品品質の1つとして、使用性(usability)が設定されている

スクリーンショット_2021-12-09_8_36_07.png

課題3. デザイナー視点での評価基準をエンジニアが把握できていなかった

発生した事象

デザイナーとエンジニアで共通認識を整え、対話をする環境ができてもまだ意思決定が遅くなることがありました。
なぜ意思決定が遅くなるのかを考えてみると、エンジニアがソースコードレビューを行うように、デザイナーもエキスパートレビューを行っていることがわかりました。

エンジニアである私の立場から、デザイナーがどのようなレビューを行っているのかを知りその観点を把握することで開発時点でデザインレビューも考慮することが後戻りが減り、開発スピードを上げられるのではないかと考えました。

対応

ユーザビリティの品質についてはユーザが最終的にどのように感じるかが一番大事ではありますが、リリース初期の学習したい段階でもある程度の品質を担保しなければそもそもユーザーに利用すらされず適切に評価されません。
Classiでも提供時に品質を高めるためにこれらのユーザビリティ評価を試したり組み合わせたりアップデートを進めています。

「ユーザビリティ」という曖昧さが残る評価では感覚 VS 感覚によってぶつかってしまって解決すべき課題が置いてかれて一進一退の無駄な攻防が始まり、開発スピードが遅くなったりチーム内での意思決定ができなくなってしまいます。
このようなデザインレビューの評価項目を実装時点で意識することで無駄な議論・開発の後戻りを減らし品質もスピードも上がります。

さらにメンバーが評価手法・プロセスとその目的、評価観点を知ることでメンバー内のフィードバックや受け止め方の質が上がることにより、少しずつプロダクトの品質もより良いものになっていることが日々感じることができています。

学習したこと

ユーザビリティを評価する方法として主に以下の3つが挙げられます、

  • ヒューリスティック評価

    • 実際のシステムを利用しながらデザイン原則や経験則に照らし合わせて評価し課題を洗い出す方法
    • ヤコブ・ニールセンが提唱した 10の評価、ベン・シュナイダーマンの8つの黄金律が有名です。
    • Naoyuki Matsumoto さんがまとめた5つの評価観点で簡潔にまとめられてます。 スクリーンショット 2021-12-09 10.13.38.png

  • 認知的ウォークスルー

    • ユーザがシステムを操作する際の「認知モデル」に基づき各シナリオにおいて目標設定→探査→選択→判断 の観点で評価を行う
      • 目標：画面をみてこのステップの目的や目標がわかるか？
      • 探査：必要な操作をイメージし実際の操作実行に移ることができるか？
      • 選択：必要な操作を実行し目標を達成できるか？
      • 判断：操作に対して適切なフィードバックが返されステップの目的を完了できるか？

  • ユーザビリティテスト

    • システムを実際にユーザに利用して行動を観察し課題を洗い出す方法
      • UXリサーチの道具箱Ⅱ では観察のポイントとして3点あげています。
        • ユーザは独力でタスクを完了できるか
        • ユーザは無駄な操作を行ったり戸惑ったりしないだろうか
        • ユーザは不安や不満を感じていないだろうか

まとめ

UX/UIの難しい点は、開発時にはとても良いと考えられていたモノが提供時にはすでにユーザから不評になることも十分ありえます。
また、究極的にはユーザに利用してフィードバックを得てはじめてと答えがわかるという点も上げられます。

デザイナーとエンジニアの経験の偏りがあることでUX/UIの議論が平行線をたどり意思決定においてボトルネックとなりました。
ユーザに利用してもらうには素早く提供する必要がありますが、このボトルネックによってユーザに提供することが遅れてしまうのは時間と労力の無駄となってしまいます。

しかしながらこのボトルネックは、以下の環境を構築することで解消に近づいていると実感しております。

  • デザイナーとエンジニアが同じチームで対話をしやすい環境をつくり、
  • 抽象的な概念を具体化して共通言語とし、
  • UX/UIにおける定性評価の観点をチームメンバー内で明確にする

今回はUX/UIデザイナーと課題や悩みを共有し連携を取りながらプロダクトの改善活動をより進めやすくするための学びを紹介しました。より良いプロダクトを素早く提供しユーザからのフィードバックを受け学習し続けるために、今後も職能を超えたメンバーの対話環境を整えお互いが学び合えるように課題に向き合い改善を進めていきます。

  1. Dual-Track Agile： 開発チームを 1.プロダクトバックログを生成するディスカバリユニットと、2.リリース可能なソフトウェアを製造するデリバリーユニット の2つのユニットがそれぞれのフェーズを並行に行う ↩

10
1
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
Sign upLogin
10
1