システムを速度改善して１時間の処理を１０分に短縮したら怒られた話 / Konishi Yusuke | STORYS.JP

パッケージベンダーのエンジニアとして配属された僕は、とある機能の速度改善を任された。当時開発経験０・Javaってなに？状態だった僕。事の大きさもわからないのでとりあえず全力でやるかと思い、とにかく勉強して改善することにした。
結果、二度と忘れられない得難き経験をすることになったわけである。
「遅いからいい感じにしといて」と言われ、とにかくやってみた
(中略)
最終的にはマルチスレッドで並列処理させることで１時間の処理を１０分程度まで改善させることができた。
(中略)
「なんで速くしたの？」と言われてレビュー惨敗
(中略)
僕はもう目が点。ザ・ワールド状態。「いやいや、だって速度改善って案件だったやんけ！？」
(中略)
当然レビューは落ちた。
(中略)
「誰も開発して解決しろとは言ってないよ？」という言葉
僕がレビューでごにょごにょ悪あがきしている時、ボスにこの言葉を言われた。
(中略)
「誰も『開発して解決しろ』とは言ってないよ？」というのは、「開発で解決するのが一番メリット出るの？」ということだ。１時間の処理を改善して１０分にすれば確かにお客さんは喜ぶだろう。しかし５０分しか変わらない。もしかしたら、それより前の処理に２日かかっているところを１日でこなせるように助言すれば、開発しなくても２４時間の削減効果があったかもしれない。問題解決のアプローチは色々あったにも関わらず、上司に、コンサルに、お客様に言われたままに最初からシステムの改善に注力しまくっていた僕。つまり、僕は先入観にとらわれまくっていたクソエンジニアだったわけだ。レビューで怒られて当然と言える。
(中略)
開発はあくまで手段であって目的ではない。ユーザーの目的はサービスの特性によって様々かもしれないが、そもそも本質的に抱えている問題はどういうことなのかを常に問い続けることが大事だと思う。
(中略)
ちなみにこんな感じのことを悶々と考えてからレビューにリベンジしてちゃんと説明した結果、無事にレビューに合格し、リリースすることができた。
(後略)

http://storys.jp/story/1417

…これ、いい感じに筆者がまとめているように見えるけれど、
・最初の問題点洗い出しと、解決プロセスは正しい。
・最終的に、最初にリリースした高速化プログラムが導入されている
という結果から逆算する限り、無駄に１回リリースタイミングを逃したマネージャー陣の低能っぷりの方が際立つだけな件。
別に、筆者に問題の本質的解決を考えさせる、という教訓を与えるのは良いんだけど、それは自社内の社内教育案件であって、顧客の不満改善を３か月放置の後にリリース一回分延期させた責任は、どこへ行ったとしか。
なんか、「新人に無茶な課題を与えて３か月放置し、結果をクソミソにけなす事でひとまず折る」という頭の悪い教育しようと思ったら、ベテラン技術者より優秀な成果を出してしまい、逆切れした教育担当。
…という臭いのが漂ってくる案件じゃね？
少なくとも、経験も知識も無い新人に、雑な指示を出して３か月も放置した挙句、理不尽なリジェクトかますマネージャーに感謝って、社畜精神育成ですね、判ります。としか言えないわ…。