パッケージベンダーのエンジニアとして配属された僕は、とある機能の速度改善を任された。当時開発経験０・Javaってなに？状態だった僕。事の大きさもわからないのでとりあえず全力でやるかと思い、とにかく勉強して改善することにした。

結果、二度と忘れられない得難き経験をすることになったわけである。

「遅いからいい感じにしといて」と言われ、とにかくやってみた

遅かったのは、月に１回自動実行されるバッチだった。２万人分の処理で１時間くらいかかっていて、今後５万人６万人をさばくことを考えると今改善すべきなのは明らかだった。

それから３ヶ月間はとにかくひたすら勉強しつづけた。何を勉強したらいいのかすらわからなかったので、とりあえず速度改善とかパフォーマンス改善とかでググって出て来た記事や書籍を読みあさり、最終的にはマルチスレッドで並列処理させることで１時間の処理を１０分程度まで改善させることができた。並列処理は社内でもまだ例のないやり方だったし、何も知らないところから我ながらよくやったものだと思う。ちなみにこの時技術面のフォローをしてくれたGentaro Okaさんには今でも頭が上がらない。

「なんで速くしたの？」と言われてレビュー惨敗

一応効果と言えるものが出たので、マネージャーレビューに持って行った。マネージャーレビューを通らないとリリースさせてもらえないのだ。改善効果の説明を一通り終えた後、ボスから受けた最初の質問を僕は忘れることができない。

「なんで速くしたの？」

一気に場の雰囲気が最悪になった。僕はもう目が点。ザ・ワールド状態。「いやいや、だって速度改善って案件だったやんけ！？」とも当然思ったが、「言われたからやった。今は反省している」なんて言えるはずもない。納得できずごにょごにょ言ってみたわけわけだが、当然レビューは落ちた。それはもう壮絶な惨敗であった。

「誰も開発して解決しろとは言ってないよ？」という言葉

僕がレビューでごにょごにょ悪あがきしている時、ボスにこの言葉を言われた。レビューの時は「そりゃねえよw」と思ったが、後で落ち着いてよーく考えてみた。

言われてみれば、たしかに「お客さんが困ってるからいい感じにしといて」とは言われたが、「速くして」とは一言も言われていなかった。なのになぜ自分は、速度を改善しようとしたのか？

先入観だらけのクソエンジニアだった僕

お客さんはシステムの速度が遅いことに困っていたわけではない。システムが遅いことで業務のスケジュールが逼迫してしまうことが問題だったのだと気づいた。本質的には、お客さんはシステムの速度なんて興味はない。もっと言うと、興味をもっちゃいけない。エンジニアは「そもそもなんで速くしたいとか言いたくなっちゃったの？」という問いから考えなければならないのである。

「誰も『開発して解決しろ』とは言ってないよ？」というのは、「開発で解決するのが一番メリット出るの？」ということだ。１時間の処理を改善して１０分にすれば確かにお客さんは喜ぶだろう。しかし５０分しか変わらない。もしかしたら、それより前の処理に２日かかっているところを１日でこなせるように助言すれば、開発しなくても２４時間の削減効果があったかもしれない。問題解決のアプローチは色々あったにも関わらず、上司に、コンサルに、お客様に言われたままに最初からシステムの改善に注力しまくっていた僕。つまり、僕は先入観にとらわれまくっていたクソエンジニアだったわけだ。レビューで怒られて当然と言える。

今となってはいい思い出

それから、僕は開発する前にそもそも開発が必要なのかというところから考えるようにしている。エンジニアは開発で解決できる幅が大きい分、ユーザーの要望を正面から解決しようとしがちだと思う。もちろん結果的にそれが一番いい解決かもしれないが、それはユーザーの本質を捉えてはいない。

開発はあくまで手段であって目的ではない。ユーザーの目的はサービスの特性によって様々かもしれないが、そもそも本質的に抱えている問題はどういうことなのかを常に問い続けることが大事だと思う。

新卒の僕の失敗からそんなことを考えさせてくれた前職のマネージャー陣の皆さんには非常に感謝している。

ちなみにこんな感じのことを悶々と考えてからレビューにリベンジしてちゃんと説明した結果、無事にレビューに合格し、リリースすることができた。今も色んな会社で高速に動作していると思うが、ユーザーがそんなことを意識していないのを祈るばかりである。

※ 自分のブログにもまとめてみました。『ユーザー目線って何？システムの速度を6倍にしたのに上司に怒られた話』⇒ http://konifar.com/627