Melting Pot of Thoughts

SaaSスタートアップのCTOです。思考の整理のため考えたことをメモとしてアウトプットしていくブログです。

成果と技術的成長のトレードオフが起きるとき

若いころに先輩エンジニアから「若いうちは技術だけを追求し、その技術が生み出す成果物の価値(例:プロダクト価値)は意識しないのもアリ」と言われたことがありました。
私は基本的に『技術はツールでしかなく生み出すものの価値こそが大事』という考え方なのですが、それと逆の意見だったので印象に残っています。
今考えると、なかなか面白いことを言っていたなと感じています。

 

大前提として成果を追求することは超大事です。
価値を出すためにどう動けばいいか考え続けることで、自身の行動の内省につながり、その結果より大きな価値を出せるよう成長できます(俗に言うPDCAサイクルというやつですね)。
成果を追求すると、問題解決速度が上がったり、「今手持ちの技術力でいかにして課題を解決するか」というクリエイティビティが磨かれます。

 

しかし成果を高効率で出そうとすると、どうしても今知っていてかつ使い慣れている技術で解決することになります。そして大体のシステム要件は今の時代、手持ちの技術力で頑張れば実現できてしまいます
解決できない課題は、サービスにユーザ数が増えてきたりだとか、大手企業が導入を決定したときだとか、そういった特殊なケースにしか現れません。
そうなると解決できる課題の場合、手持ちの例えば100点満点で50点しかとれない解法で問題を解いてしまうことになります。
結果「問題数はたくさんこなせるけど、全部50点ぐらいしか取れない」人になってしまいます。

 

さらに悪いことには、システムでいう50点というのはバグが多かったりメンテナンス性が低かったりすることを指します。
これらは開発の手を遅める直接的な原因でもあります。
成果を最速で出すために頑張っていたのに、実は回り道して他の問題解決手段を探したほうが早かった、ということにもなりかねません。


というわけで、エンジニアは成果だけを追求するのではなく、時には技術という問題解決ツールそのものを学ぶプロセスを楽しむこともすごく大事だと感じています。
OKR等会社内での成果目標は色々あると思いますが、その達成だけにとらわれず自分の技術の幅や深さを広げることも意識するのが大事です。
歳を取れば取るほどどうしても早期に結果を出すことが求められるようになるため、私自身は若いうちに成果にこだわりすぎず技術力を深める時間も取れたのでよかったなと思っています。
余談ですがエンジニア35歳定年説の一つの原因として「自身の技術を磨く機会が業務上どんどん減っていくから」というのもあるのかもしれないなと思っています。

 

どうしても仕事では成果が求められるので、休日などに時間をとって自分の技術を磨く時間を捻出しなければいけないなという自戒を込めつつ書きました。