KonifarPod

ユーザー目線って何?システムの速度を6倍にしたのに上司に怒られた話

   

Pocket

 

最近『ユーザー目線』という言葉をブログ記事でよく見ます。言葉自体は太古の昔からあったわけですが、正直僕はこの言葉がよくわかりません。ユーザー目線って、なんかふわっとして意味不明じゃないですかね?ユーザー目線で考えるのは悪くないけどユーザー目線になるのはよくないというか、なんかよくわかんない微妙な言葉だと思います。

と言っても、最初からこんなことを考えていたわけではありません。なぜこんな考えになったかというと、新卒の時ユーザー目線の認識を間違えて見事に大失敗したからです。具体的に言うと、システムの速度を改善して1時間から10分にしたら上司に怒られたんですね。今回は、ちょっと当時の失敗を思い出しながら自分の思考を整理してみようと思います。主観100%になりますが悪しからず。

 

1.とりあえず全力だった新卒の僕

Usersite1

「この機能遅くてお客さん困ってるからいい感じにしといて」

パッケージベンダーのエンジニアとして配属された僕は、とある機能の速度改善を任されました。開発経験0・Javaってなに?状態の僕によく任せてくれたもんだと思います。案件を渡された僕は、ことの大きさもわからないまま とりあえず全力でやるかと思い、素直に頑張ってみることにしました。

遅いと言われていたのは、月に1回自動実行されるバッチシステムでした。2万人分の処理をするのに1時間くらいかかっていて、今後5万人6万人分をさばくことを考えると今改善した方がいいのは明らかに思えました。ユーザー目線とか考えるまでもなく、改善するのは正義だと考えたんですね。当然、速くなればユーザーは喜ぶはずです。

それから3ヶ月間はとにかくひたすら勉強しつづけました。何を勉強したらいいのかすらわからなかったので、とりあえず速度改善とかパフォーマンス改善とかでググって出て来た記事や書籍を読みあさり、最終的にはマルチスレッドで並列処理させることで1時間の処理を10分程度まで改善させることができました。何も知らないところから、我ながらよくやったものだと思います。改善の効果が出たのでマネージャーレビューに持って行ったのですが、そこで僕は二度と忘れられない経験をすることになりました

 

2.まさかのレビュー撃沈

Usersite6

「なんで速くしたの?」

レビューで説明を終えるとまずこの質問が飛び出し一気に場の雰囲気が最悪になりました。 もうね、目がテンですよ。時が止まりましたよ。だって速度6倍になったわけですよ?ユーザーだって喜んでくれるはずです。

「いやいや、だって速度改善って案件だったやんけ!?」とも思いましたが、「言われたからやった。今は反省している」なんて言えるはずもありません。お客さんが今遅くて困っている ⇒ 速くして解決できた という事実はあったので色々ごにょごにょ言ってみたわけですが、当然レビューは落ちました。それはもう見事な惨敗でしたね。

 

3.先入観だらけのエンジニア

Usersite3

「誰も『開発して解決しろ』とは言ってないよ?」

僕がレビューでごにょごにょ悪あがきしている時、ボスにこう言われました。レビューの時は「ちょwww」と思いましたが、終わった後に思い返して考えてみました。言われてみれば、たしかに「お客さんが困ってるからいい感じにしといて」と言われたものの、「速くして」とは言われていなかったんですね。これだけ聞くと言葉遊びに聞こえるかもしれませんが、とても重要なことです。

つまり「お客さんはなぜ困っているのか」という本質的な話です。システムの速度が遅いことに困っていたのでしょうか?違います。システムが遅いことで業務のスケジュールが逼迫するのが困るのです。本質的には、お客さんはシステムの速度なんて全く興味ありません。「そもそもなんで速くしたいとか言いたくなっちゃったの?」という問いが重要なのです。

自分の失敗ケースを例にしましょう。僕の仕事の仕方を例えるとこんな感じでした。

ユーザー「なんか遅くて困ってるんですよね・・・」

僕「まじですか?確かに遅いっすねー。速くできると思うんで直しましょう!(ドヤァ) 

以上!しかし、本来考えなければならないのは下記のようなやり取りです。

ユーザー「なんか遅くて困ってるんですよね・・・」

僕「確かに遅いですよね。けどなんで遅いと困るんですか?

ユーザー「いやあ、結構スケジュールがキツキツなんですよ」

僕「なるほどー。けど遅いと言っても1時間ですよね?

ユーザー「1時間でも惜しいくらいキツキツなんですよ・・・」

僕「それって全体はどんなスケジュールなんですか?」

ユーザー「まず処理の前にデータをかき集めて・・・それが2日くらいですね

僕「そこ改善して1日にできないですかね?

何となーく雰囲気は伝わるでしょうか?

「誰も『開発して解決しろ』とは言ってないよ?」というのは、「開発で解決するのが一番メリット出るの?」ということです。1時間の処理を改善して10分にしたところで、50分しか変わりません。もしかしたら、それより前のデータ収集に2日かかっているところを工夫するよう助言すれば、それだけで24時間の削減効果があったかもしれません。問題解決のアプローチは色々あったにも関わらず、上司に、コンサルに、お客様に言われたままに最初からシステムの改善に注力してしまったんですね。つまり、僕は先入観にとらわれまくっていたクソエンジニアだったわけです。

  

4.ユーザーの目線は視野が狭いかもしれない

Usersite5

「速度が遅くて困っている。改善できるならしてほしい」

最初に案件をもらった時、当然僕は問題の機能についてコンサルやお客様にヒアリングを行いました。もちろん誰に聞いても「速度が遅くて困っている。改善できるならしてほしい」と言われました。そりゃそうです。速くなったら嬉しいですよ。ユーザーの目線に立てば、改善してほしいに決まっています。しかし、本当はシステムの速度を改善してほしいのではなく、業務上の問題を解決してほしいはずなのです。ユーザー自身、システムを使ううちに本当の問題や望みが分からなくなっていることが多いんですね。ユーザーの目線は視野が狭い可能性があるのです。

ユーザーは速度を改善してほしいと言いました。コンサルもそう言いました。僕もそうすべきだと思いました。しかし、これはバイアスにかかっていたのです。ユーザーは問題に気づかないことも多いです。問題に気づかないユーザーの目線に立ってユーザーの要望を理解しようとしている限り、本質的な問題にたどり着くことはできないのではないでしょうか。

 

5.ユーザー目線という言葉がよくないと思う

Usersite7

ユーザーにメリットを提供したいのであれば、ユーザーの目線では視界にも入っていない問題の本質を理解しなければなりません。そうすることで初めて目指すべき解決方法が見えてきます。もしかしたら開発する必要すらないかもしれません。ユーザー目線を持つというのは、ユーザーになりきることではありません。ユーザーの問題の本質を理解することが重要なのです。

言葉遊びに聞こえるかもしれませんが、ユーザー目線という言葉自体が曖昧で誤解を生みやすいのではないかと思います。大事なのは、ユーザーの問題の本質を捉えることです。「ユーザー目線で考える」ではなく「ユーザーの本質を捉える」という表現がいいのではないかと思います。エンジニアは開発で解決できる幅が大きい分、ユーザーの要望を正面から解決しようとしがちです。もちろんそれが一番いい解決かもしれませんが、それはユーザーの本質を捉えてはいません。

問題の本質を見極め、ユーザー目線でも捉えられない解決を先回りして提供してこそ、かっこいいエンジニアなのではないでしょうか。ユーザー目線というただの言葉に捉われることなく、僕なりにかっこいいエンジニアを目指していきたいと思います。

 

ちなみにこんな感じのことを悶々と考えてからレビューにリベンジし、ちゃんと説明した結果、無事に合格してリリースすることができました。めでたしめでたし。

Pocket

 - 仕事