見出し画像

使えない機能をデザインしてしまったことからの学び

Grooves＋＜プラス＞｜株式会社Grooves公式メディア

こんにちは。株式会社grooves（グルーヴス）でプロダクトデザイナーをしているイハラです。
私は、HR×テクノロジー領域で、全国の人材紹介会社と求人企業をつなぐ、国内最大級のクラウドサービス「Crowd Agent（クラウドエージェント）」のプロダクト開発をしています。

今回は「使えない機能をデザインしてしまった話」を紹介しようと思います。
タイトルからは悲愴感が漂っていますが、デザイナーとして、開発チームとして、とても学びになったので、ぜひこの経験をシェアしたいと思います！


何を作ったのか？

お客様の求人作成や選考のサポートなどを担当する社内のカスタマーサポートメンバー向けに、日々手動で行っている業務の一部を自動化して工数削減するための機能を作りました。


どうやって作ったのか？

この5名でチームを組んで、プロジェクトを立ち上げました。

  • カスタマーサポートチームのマネージャー 1名

  • プロダクトマネージャー1名

  • デザイナー1名

  • エンジニア2名

以下の流れでプロジェクトを進行しました。

業務フロー理解のため、5名にインタビューして、業務フローを可視化
可視化した業務フローを自動化するためのソリューションを立案し、
プロジェクトチーム全員で仕様検討しながら開発
ユーザーテストで実際に機能を使ってもらい、問題点を改善


作ってどうなったのか？

リリース後、作った機能がどうしてもカスタマーサポートチームの運用に乗らず、既存の運用を継続し、作った機能は削除することになりました。

運用に乗らなかった理由は4つ。これらの問題点に事前に気づくことができませんでした。

  • 既存の運用を変更するために体制変更と人員増加が必要

  • チーム合併の時期と重なり業務フローの構築が難しい

  • 併用しているサービスとの連携が難しい

  • 複雑なパターンに対応できない


なぜこうなったのか？原因は大きく2つです。

  • 「作る人」が「作ってもらう人」の本音を引き出せなかった

  •  業務フローの全体像を把握できていなかった


「作る人」が「作ってもらう人」の本音を引き出せなかった

インタビューやユーザーテストには現場のメンバーを巻き込めたものの、プロジェクトメンバーは「作る人」、現場メンバーは「作ってもらう人」という関係性になってしまい、本音を引き出すことができませんでした。

「作る人」は現場の業務を担当していないので、実際に使える機能なのか知りたいと思っていますが、「作ってもらう人」は、意見を出すことに遠慮してしまい、ユーザーテストなどの限られた時間だけでは実務で利用するイメージを持つことは不可能な状況でした。

「本当に使えるのか？」という問いに答えられなかった結果、事前に以下2つの問題を回避することができませんでした。

  • 既存の運用を変更するために体制変更と人員増加が必要

  • チーム合併の時期と重なり業務フローの構築が難しい


業務フローの全体像を把握できていなかった

業務を自動化するにあたって、まず現場の業務フローを理解することから始めました。
カスタマーサポートチームのうち数人に、現在の業務フローについて話を聞き、miro （オンラインホワイトボード）で業務フローを可視化→抽象化→課題分析していきました。
しかし、ヒアリングしたフロー以外のパターンも存在することや、ヒアリング対象外の方は別のやり方で業務をしていることに気がつかず、十分な調査になっていませんでした。

また、「工数削減のために業務を”自動化”する」という手法（HOW）に囚われて、実装までのステップを早めてしまい、十分な調査・分析時間を確保していなかったのも原因の1つです。

見えない業務フローの存在に気づかなかったことで、事前に以下2つの問題を回避することができませんでした。

  • 併用しているサービスとの連携が難しい

  • 複雑なパターンに対応できない


どうすればよかったか？

「作る人」が「作ってもらう人」の本音を引き出せなかった
⬇︎
本音を言い合えるよう「一緒に作る」関係になる

一緒に課題解決するチームとして、現場の業務を熟知した方をプロジェクトメンバーに含めることで、率直な意見を言い合い、実務をよりリアルにイメージしながら機能を作ることができます。


業務フローの全体像を把握できていなかった
⬇︎
業務フローを”聞く”のではなく、担当者全員の業務を”観察”する

人は無意識に考えたり行動するため、業務フローを聞いても、全てを言語化して伝えることは不可能です。
見えない業務フローを把握するためには、担当者全員を対象とし、実際の業務をそばで観察するシャドーイングという手法を使うのが適切です。
業務フロー分析は徹底的に！


失敗からの学びを得て

このような学びを得て、作っているものの価値を確かめながら不確実性に対応していくため、グルーヴスのプロダクトチームでは仮説検証型の開発手法を導入しています。
まだ模索中ではありますが、何が課題であるかを仮説を立てながら検証する「価値探索フェーズ」と、実際に開発しながら価値を確かめる「開発フェーズ」を繰り返すことで、徐々に不確実性を小さくしながら、ユーザーの皆様により良い体験を提供できるよう、本質的な価値を追求しています。

グルーヴスのプロダクトチームについて、詳しくはこちらのマガジンもぜひご覧ください！


メンバー募集中！

グルーヴスのプロダクトデザイナーは、この記事のような学びを得ながら、サービスの提供価値・ユーザー体験をさらに向上させるため、日々模索しています。
少しでも興味がある、ちょっと気になる、こんな部分をヘルプできそう、という方、ぜひご連絡お待ちしております！カジュアルな面談も大歓迎です！


この記事が参加している募集

#最近の学び

186,533件