2024-10-6
ある施策がどれくらいお金を稼ぐことができるのか、そうでないのか？ということを最近第一に考えている、というか考えざる得なくなっている。
エンジニアであれば、直接売上に貢献しないことをしたいこともある。それは日々の運用改善だったり、リファクタリングだったり、いわゆる技術的負債の返済という類のものがそれにあたる。
薄々感じていたし、フィードバックされて改めて感じることでもあるが、上記のようなエンジニアがやりたいことは「お金を稼げない」
もちろんこれらには副次的な効果もある。
目先の売上を目指して触りづらいソフトウェアになって、事業のスピードが将来的に落ち、結果機会損失が発生する、というのはある、、が、あくまでそれは教科書的な返答であり、実際に事業サイド、もっというと経営層に説明するときには、それをすぐに分かってもらうのは難しいと思う。（そういうときの CTOじゃないか？という話もあるが、案外見過ごされがちな観点として CTO は経営側の人間であり、CTO が経営チームで議題に上げるときにその議題の根拠となるものは現場から示さないといけないし、どれくらい ROI が上がるのか、を示さないといけない。
これを嫌がっていては、結局何も進めることはできないのである。
やってる施策が売上に直結するドライバー足りえれば、交渉はスムーズに進む。なぜなら企業はあくまで営利法人であり、株式会社においては利潤を追求し、株価を上げ、株主に還元することが企業運営の大きな命題になるからである。
その観点で言えば、自分のやりたいことは株価に結びつくのか？ということは思考実験として考えてみてもいいのかもしれない。
翻って、売上のドライバーにならないものであればあえて交渉せず、日々の業務の中で改善を進めるべきだろうと思う。
もちろん、大きな変更になる場合にはちゃんと ROI を示し、リソースを割く価値を理解して貰う必要がある。
ただ、そこまで大きなイシューというのは年に何回も起こるものなのだろうか？
ちょっとコードが汚い。
責務が大きなメソッド、クラスがある。
ライブラリのバージョンが古くて新しい機能が使えない。
このような「好み」のレベルや「現場レベルの生産性」に関わる物事など、日々の業務の中で現場でコミュニケーションを取って少しずつ変えていくべきだろうと思う。
それが Job Description に示された職責なのであれば積極的に進めるべきだし、いちいち説明する必要もない。
黙ってやるべきだと思う。
現場の改善は"上"の声を聞いてやるものではなく、現場で進めていくものである。
やっていこう。