インサイドセールス トレイル005

プロダクトオーナーとUX/UIデザイナーとエンジニアとの協調

インサイドセールス事業は、他社サービスを利用していましたが、システム開発も行っていました。現在もそれは続いていますが、UX/UIデザイナー（以下、デザイナー）との協調について、いくつかの失敗から得た学びがあるのでそれを共有したいと思います。

 

起こったこと

システム開発が始まって1か月ほどでプロダクトオーナーとエンジニアで要件定義と見積もりを実施しました。 本来はデザイナーと一緒に見積もりたかったのですが、その時はデザイナーたちは別の案件を担当していたため、参画が遅れました。 このためワイヤフレーム設計等は後回しにし、画面と画面遷移図は再度見直す前提を置き、機能数や各画面のイベント総数等で計算したざっくりとした概算でエンジニアが見積もりました。

このような経緯から、デザイナーが参画したとき、エンジニアはデザインのアウトプットとしてUIを期待しており、 画面デザインと画面遷移図の具体化が主なアウトプットと考えていました。 しかし、ここでエンジニアとデザイナー間での意識の齟齬が生じます。 UIの前に王道といえるUXのデザインから行っていった結果、見積もり時には隠れていた新たな要件が見つかったり、既存の要件に膨らみや大きな変更が入りました。 このような意識の齟齬が出た要因は、案件を兼任していたデザイナーはエンジニアのチームとは独立させている中で、エンジニアとデザイナーとの間の目的意識のすり合わせや協調が不足していたことにあると考えています。

また、前述の粗い見積もりのまま納期を決め、それに基づいて人員計画を立てたため、エンジニアのチーム組成は増員が急に行われる形のものでした。 増員されたエンジニアが実装する画面を優先的にデザインする必要が生じ、自転車操業のようなUIレビュー⇒実装というサイクルが行われるようになりました。

また、上述の理由によって、すぐにデザインが行いやすい簡単な機能のデザインが優先され、重要だが複雑でデザインに時間がかかる機能ほど後になっていきました。 開発として本来行うべきは、不確実性が高いものや重要なものから先に実装しリスクを減らしていくことです。 しかし、簡単な機能に関するデザインと機能開発が先行し、重要だが複雑な機能に関しては後回しになってしまった結果、事業としてのリスクは減らないままでした。 振り返ってみれば、本来あるべき開発ができなかったのは、開発のあるべき姿を念頭にUX・UIデザインや開発順の戦略を練ることができていなかったからと考えています。

加えて、先行してデザイン・開発を行なったバックオフィス機能については、顧客へ提供する価値は低いにもかかわらずウェルデザインなもの、悪く言えば作り込みすぎたものを作ってしまいました。 事業のどこにコストを投入するべきか、投入するだけの意味がある機能なのかという費用対効果を、デザイナー・プロダクトオーナー・エンジニアで検討できていなかったことが主な原因です。

これらのことから、以下のような点を課題として認識しました。

  1. UX・UIのデザインを経ない、サービスとしての解像度が低いままで見積もってしまったこと
  2. UX/UIが不明確な状況で、エンジニアの体制を厚くしてしまったこと
  3. デザイナーとエンジニアでチームを分けたにもかかわらず、その間での目的意識や協調が不足してしまったこと
  4. 開発する機能・デザインに関して、費用対効果を意識できなかったこと

結果

要件が膨らみすぎた時点でスコープ調整を実施しましたが、顧客にとっての価値ある機能までもスコープアウトしてしまいました。
後段でその点に気づき、価値ある機能をスコープに含めて再見積もりをした結果、期限までに開発を完了させることが困難であると判断し、最初のリリースは見送ることとなりました。

学び

UX/UIデザイナーの役割とは？

みなさんは、「UX/UIデザイナーの役割とは何か？」と聞かれたら、明確に答えられるでしょうか。 書籍や記事を色々見ましたが、UXという言葉自体が100人いれば100通りの解釈があるほど広域に使われている現状では、曖昧と言わざるを得ません。

したがって、役割と期待する事柄、それらを達成するためのプロセスを明確に決め、合意した状態で進めていくべきです。

いつ協調するべきでしょうか？

プロダクトオーナーとエンジニア、デザイナーがバラバラのタイミングでUX/UIの要件や業務フローの整理をするべきではありません。

できるだけシステム開発の初動から、同時に、少人数で行うべきだと言えます。少人数であるべき理由は、多人数では議論の一人あたりの密度が低下し、コストが高くつくからです。

またタイミングは見積もりの前に行うべきでしょう。なぜなら、UX/UIデザインを行うと要件は変化するからです。仮に見積もりを粗く行ったとしても、変化する前提で考えて、適切なタイミングで再度見積もりを精緻化するべきでしょう。

どういったプロセスを取ればよかったのでしょうか？

UX/UIをデザインしていくプロセスと、開発のプロセスでは順序が違います。

上でも述べたように前もって少人数でUX/UIや要件を決定し、その後開発のエンジニアの人数を増やして、顧客にとって価値あるものと不確実性やリスクの高いものから着手していくのが良いプロセスだと思います。

また、すべてのUIを理想的な、最高のデザインにする必要は無いとも言えます。コストが限られるため、顧客にとって価値のある機能に比重を置き、バックオフィスの機能は必要以上に凝らないことも大事です。

以上が、失敗からの学びになります。

最後に、プロダクトオーナーとエンジニア、デザイナーは一体感をもって出来るだけ最初から行動を共にし、顧客へ提供できる価値やコスト意識を共有することが成功への鍵だと思っています。