自分がユーザになれないプロダクトを作るということ
BtoB向けサービスのプロダクト開発において、開発者が「自分が使わないものを作るということ」にどう向き合ってきたか、というポエムです。
TL;DR
---
自分が使わない仕組みを作る機会
仕事としてシステムを開発するにあたって、自分が使わない仕組みを作る機会はかなりあるのではないかと思う。
受託でも自社サービスでも、BtoB向けのものや、作り手が男性の場合は女性用のもの(作り手が女性の場合は男性用のもの)、現場で働く人だけが使うもの、一部の専門家だけが使うものなど多岐に渡るはず。
職業エンジニアとして自分が使わないプロダクトにどう向き合うのか
「言われたとおりに作る」ということが決まっているものや、使い勝手に特化したツール的なものであればユーザテストやヒアリングを繰り返すことで、ユーザやプロダクトオーナーが求めるものを作り上げることができる。
しかし「それなりに評価されることを期待した世の中にない新しいもの」を作る時、新しい価値観と使い勝手のバランスをプロダクトに落とし込む作業が発生する。これが非常に難しい。
なぜならプロダクトオーナーはビジネス目線での正解を求め、ユーザはそれぞれの使い勝手での正解を求め、設計する者はシステム的な最適解を提案しつつそのバランスを実現することを考えなければならない。
ユーザになれないことは、ユーザのことを想像しなくていい理由にはならない
私自身もそういった局面で悩み、考える責任を放棄したい衝動に駆られることもあったが、作り手の先達たる方々の議論・意見が非常に参考になったので紹介する。
CAMPFIRE社内のやりとり
(Inside CAMPFIRE『プロダクトのもつエモさと作り手のエゴについて』より引用)
山中俊治さんのTweet
「作る人」と「分かってる人」の歩み寄り
「作る人」が「分かってる人」とのギャップを埋めるためのものが想像力だとして、その想像力を得るにあたって様々な取り組みを行う必要があった。
ユーザのことを知る
(主に営業職向けのサービスだったので)社内の営業の方に協力してもらいながら、営業の定義や種類、業務のパターン、歴史、手法やフレームワークなどをまとめ、作る人全員が最低限の知識をキャッチアップした状態に底上げした。
使い勝手をゼロから考えてみる
チームで開発合宿を行い、開発メンバーのみでアプリのリニューアル案を考えることで、開発メンバーが画面遷移やコンポーネントの配置などの文脈を理解できるようになった。
プロダクトオーナーの思想を引き出す
リニューアル案のプロトタイプをコミュニケーションツールとしてプロダクトオーナーへのヒアリングを繰り返していった。
回を重ねることでプロダクトオーナーもある程度開発者に任せられる安心感に繋がっていった。
得た学び
「それなりに評価されることを期待した世の中にない新しいもの」かつ「開発者自身がユーザになれないもの」を作ることは非常に大変なプロジェクトだった。
その大変さのほとんどは「組織や立場を越えて思想や価値観を連携する」ということの難しさに起因するものだと思う。
プロダクトを作ること以前に、組織やプロセスとして思想や価値観を連携を可能にするという事自体が非常にハードルが高く、同じような試みはほとんどの場合成功しないとさえ思える。このプロジェクトが完走できたのは関係者が建設的で素敵な人々に恵まれたという一点に尽きる。
もし同じようなプロジェクトをやるのであれば、実現難易度を下げられる大きさまで分割するか、全領域をカバーしたスーパーマンの登場を待つか、連携を仕組みで担保できる環境を作り上げてから挑むと思う。
---
これまで3社で自社プロダクトのリニューアルをやってきたけど、自分が使わないものは本当に難しい。しかしハードルが高い分、乗り越えてる競合も少ないと思うので取り組む価値は十分にあったという気持ちです。
この記事が気に入ったらサポートをしてみませんか?