強いエンジニアとはと問われれば真っ先に思い浮かぶのは、特定のアプリケーションに対して必要な機能を素早く的確に実装できる人、だ。これは単なる実装能力に限らず、テックリードやエンジニアリングマネージャと呼ばれる役割のたちが、人的リソースや技術的要件をうまく活用し、滞りなく実行できることだ。ここではエンジニアの定義をコーディングだけにとどめなかったのは、潜在的に自分が他領域への興味を持っており実装をする上で自らが要件を定義できたり、ステークホルダーとの折衝ができる方が良いと考えているからだ。エンジニアである前にビジネスマンである社会人の我々は、本来はコーディングだけに専念するだけでなく、どのようなビジネスインパクトを持っているかを考えた前提で技術選定や実装方針を立てるのが理想だ。
要件、予算、品質、納期を天秤にかけた際に品質が蔑ろにされがちなのはステークホルダーの中で直接的な関わりがな炒めではないだろうか。要件、予算、納期は会社として決定事項であることが多く、品質は一定損なわれてもリリースすることはできる。一旦リリースすることができればその他の項目については体面を保つことができるが、その被害はユーザが被ることになり、プロダクトのレビュー、ひいては会社の名前に傷がつくのはそう遅くないだろう。
また品質は唯一現場が監督できる分野であり、エンジニアの責任になりがちだ。質の高いプロダクトはレビューも高く、その実装ができるエンジニアは評価されるべきだが、バグを生まないプロダクトを作ったとて会社として評価されることは少ないのではないだろうか。テストカバレッジなど、定量的に評価できる軸があればその数字を持って自信に変えられれば良いと思う。
では、強いエンジニアになるために何から始めれば良いのか。高品質なプロダクトを生み出すことが大前提だ。その中で、メンテナンス性の高いコードを書く、新旧様々な技術を知った上で要件に沿った選定ができること、不具合に対して早急な対応ができることなど様々な要素が考えられる。そのすべての大元は課題解決であり、そのプロダクトの方向性に対して正しい実装を行っていくこと他ない。ポッドキャストでも話されていたが、綺麗なコードを書けるに越したことはないがそれだけが強いエンジニアでもなければそのコードがビジネスに対して影響を持っていなければならない。日々大事なのは目の前のことを大事にしながらも、そのコーディングの先にどんな影響を与えられるのかを想像することではないだろうか。