みなさん、こんにちは。
2025年も4月に入り、新年度が始まりましたね！
新入生・新社会人のみなさん、おめでとうございます🌸
みなさんは、「シニアエンジニアとはどんなエンジニアか？」と聞かれた際に明確な回答をお持ちでしょうか？
私は、社会人7年目に突入しましたが、未だにシニアエンジニアって何なのか？という疑問を持っており、完璧な回答を持っているわけではありません。笑
しかし、少なからず言語化できるようになってきたことはあります。
なので、今回は私が考えるシニアエンジニアに求められるであろう要素の一部をご紹介したいと思います！
基本となる技術的能力
技術の習得は大前提
ジュニアエンジニアとして歩み始めた方は、これから色々な経験を積みながらしっかりとした基礎を身につけていくと思います。
最初は小さなバグ修正から始め、徐々に大きな機能リリースまでを経験していき、そのうちコードの扱い方も慣れていくことでしょう。
そこからシニアエンジニアへと成長していくためにはどのような要素を身につけていけば良いのでしょうか？
私は、シニアエンジニアと呼ばれるレベルになっていくためには、もはやどれだけ多くのコードを書けるかということだけが重要な指標ではなくなっていくと考えています。
ChatGPTやCursorなどの台頭によって、以前よりもコードを書くこと自体はかなり容易になりました。
もちろん、LLMが出力したコードを適切に評価できる技術的な見識を持っていることは、現時点ではまだ重要であります。
しかし、シニアレベルへと成長していくためには、さらにコードを超えて考える必要が生じると考えています。
経験のない技術でも素早くキャッチアップできる
これまでに経験してきた技術をどれだけ熟知しているかはもちろん重要ではありますが、まだ経験していない技術をどれだけ素早くキャッチアップして、アウトプットできるか、そして成果に繋げることができるかも重要です。
昨今、AI技術の進歩が目覚ましいですが、これらをプロダクトに組み込んで新しい価値を顧客に提供していく場合など、これまで自分が経験していなかった技術のキャッチアップが求められる場面は、エンジニアとして仕事をしていればいくらでも遭遇し得ます。
そのような時に、「経験が無いためできません」と回答するエンジニアか、素早くキャッチアップして成果を出すエンジニアか、どちらがより企業にとって嬉しい人材かは考える余地もありません。
他にも、新規サービスを立ち上げる場合などで、プログラミング言語やフレームワーク、ライブラリなど、最新の技術動向をキャッチアップした上で自社に適切な技術選定を行う場合などにも必要なスキルになってくると考えます。
適切なツールを適切に扱える
エンジニアにとって、ツールの選定と活用は、開発効率を大きく左右する重要な要素です。
シニアエンジニアは、単に多くのツールを知っているだけでなく、状況に応じて最適なツールを選び、効果的に使いこなせることが求められます。
例えば、パフォーマンス問題へのアプローチを考えてみましょう。
適切な計測ツールを使用してデータに基づいた意思決定ができるエンジニアと、勘と経験だけに頼っているエンジニアとでは、問題解決の結果に大きな差が生じるかもしれません。
また、CI/CDやモニタリングなど、開発ライフサイクルの全体をサポートする様々なツールの特性を理解し、プロジェクトの状況や組織の成熟度に合わせて適切に導入・活用できることも重要です。
新しいツールを導入する際には、学習コストやチームへの影響も考慮した上で判断できなければなりません。単に「流行っているから」や「個人的に好きだから」という理由でツールを選ぶのではなく、そのツールがもたらす価値と導入コストを冷静に評価できることがシニアエンジニアには求められます。
さらに、ツールの限界を理解し、過度に依存しないことも重要です。
どんなに優れたツールでも万能ではありません。
ツールに頼りすぎず、必要に応じて自前の解決策を検討できる判断力も持ち合わせているべきだと考えます。
自動化によって時間を節約できる
もし単調な作業に繰り返し時間を使っていると気づいたら、それは自動化できないかを検討すべきかもしれません。
もし毎回リリースの前に全てのテストケースを手動でテストしているのであれば、できるだけ早く自動テストを導入し、人間の工数を減らすべきです。
もし毎回手動でデプロイを行なっているのであれば、継続的デリバリー環境を整えるべきです。
自動化するために必要な時間を確保できないとしたら、自動化するために必要な時間を見積もり、どれくらいでその投資が回収できるか計算してみましょう。そしてそれ説得材料として使うのです。
他にも普段の業務で単調な作業を繰り返し行なっているものを見つけたら、自動化を検討しましょう。
思考法・視野の拡大
常に先を見越した行動ができる
ジュニアエンジニアであれば、常に目の前のタスクにのみ集中していれば良いかもしれません。
しかし、シニアエンジニアとして成長していくためには、目の前のタスクだけではなく、中長期的な視点で考え、行動できることが重要です。
新規サービスの開発を例に考えてみましょう。
新規サービスを構築する場合、単に要件を満たす機能だけを開発すれば良いというわけにはいきません。
予測されるユーザー数やリリース後の機能拡張にも対応できるようにアーキテクチャを構築することが重要であることは言うまでもありません。(いわゆる非機能要件と呼ばれるものですね)
当たり前ですが、事業の成長に合わせてシステムも進化させていく必要があります。
システムが事業成長のボトルネックにならないようにしなければなりません。
例えば、
- ユーザー数の増加によってパフォーマンスに影響が出始めるかもしれません。
- 技術的負債が原因で、新機能の追加や既存機能の改修が困難になり始めるかもしれません。
- チームメンバーの増加に備えるためにドキュメントやオンボーディング環境を整える必要性があるかもしれません。
このような先見的なモノの見方は、一部経験によって培われるものだと思いますが、意識的な習慣化によっても身につけられるものだと思います。
局所最適ではなく全体最適で考えられる
私の好きな考え方に「局所最適よりも全体最適」というものがあります。
局所最適とは、ある特定の部分だけを最適化することを言います。
例えば、ある部署の業務効率化を行なったとします。一見、その部署は効率が上がったように見えます。
しかし、組織全体を見て効率化を行なったわけではないので、ある部署の効率化が他の部署へのしわ寄せを生み、全体で見た場合にむしろ以前よりも効率が落ちてしまうケースなどがありえます。
システム開発においても同じことが言えると思います。
ここでも新規サービスの開発を例に考えてみましょう。
新規サービスの開発において、まず重要なことはQCDに代表されるように、クオリティとコストとデリバリースピードのバランスです。
このうちどれか1つに偏ってしまうと、そのプロジェクトは失敗に終わってしまうかもしれません。
例えば、クオリティに偏り過ぎてしまうと、完璧なサービスを目指して開発が長期化し、コストが膨大になるだけでなく、顧客にいつまで経ってもサービスを提供できません。
そしてサービスが完成した頃には、他の競合サービスがいくつか出現しており、思うように売上を伸ばすことができないかもしれません。
このような失敗を避けるためには、顧客のニーズや課題、市況環境を踏まえて、QCD全体の最適化を考えることが重要です。
コードを超えてビジネスへの影響を考えられる
私たちエンジニアに給料が支払われているのは、ただ芸術的な美しいコードを書いているからではありません。
書いたコードが直接ないし間接的に顧客に価値を届け、その対価としてお金をいただけているからです。
事業会社に雇われているエンジニアであれば尚更このことは意識しなければならないと考えます。
エンジニアが読んで美しく感じる芸術的なコードを書くことも、ある観点では重要かもしれません。
しかし、それ以上に何を作るかがビジネスでは重要です。
何を作るかは、エンジニアの責任ではなく、PdMなど企画職の責任だと考える人(環境)も一定数いると思います。ここは意見が分かれる点であると認識しています。
しかし、私は、エンジニアも顧客やユーザーに関心を持ち、ニーズや課題を理解するために努力し、よりビジネスに好影響を与える機能を作ることに貢献するべきだと考えます。
開発リソースは会社にとって重要な経営資源です。
無駄な開発に貴重な開発リソースを割くことは望ましくありません。
私個人としては、誰かに何かを作らされるよりも、自分が作りたいものを作る方が100倍楽しいと感じますし、やりがいも感じます。
ですが、会社で開発する以上、単に個人的に作りたいものだけを作るわけにはいきません。
ビジネスへの影響を考慮した上でユーザーにとって価値ある機能を作る必要があります。
ユーザーに関心を持ってニーズや課題を理解するために努力することで、機能の必要性が理解できたり、別のソリューションの提案に繋がったりするかもしれません。
それが成果に繋がったら、よりやりがいを感じ、開発のモチベーションにも繋がると考えています。
プロジェクト・技術マネジメント能力
大きな課題を適切な粒度に分解できる
大きな課題に取り組む際に、適切な粒度に分解して取り組むことが、シニアエンジニアには求められます。
複雑で大きな課題に対して、そのまま闇雲に取り組もうとするのは得策ではありません。
なぜなら、大きな課題のままでは、工数を見積もることも困難ですし、チームメンバーと並行して作業を行うことも難しいからです。
シニアエンジニアには、大きな課題を適切な粒度に分解することで、チームメンバーとの作業分担を可能にし、作業進捗の可視化を容易にすることが求められます。
課題を分解する際は、ビジネスへの影響やデリバリー速度を考慮したタスク分解と優先順位付けができるとなお良いと思います。
技術的負債を適切に管理できる
みなさんはエンジニアとして働いていてこのように思ったことはありませんか？
「今携わっているプロジェクトの技術的負債を全て解消して綺麗なコードベースにしたい」
私はこのような考えに対して「待った！」の声をかけたいと思います。
一度深呼吸をしましょう。
コードベースに技術的負債が多く残っている状況はエンジニアとしては居心地が悪いことかもしれません。
技術的負債が全くない状態は理想です。
しかし、ロードマップ上の開発において妨げになる技術的負債以外は一旦優先順位を下げるべきかもしれません。
直近の開発や運用に悪影響を及ぼしている又は及ぼす恐れのある技術的負債以外の返済は可能な限り先延ばしにすべきだと考えます。
逆に、直近の開発に悪影響を及ぼす技術的負債に関しては、きちんと解消してから開発に臨むべきです。
その判断と調整、スケジューリングなどがシニアエンジニアには求められます。
それを判断するためには、やはりビジネス的な影響も考慮できないと適切な判断は下せないと考えます。
対人スキル・リーダーシップ
利害関係者と適切なコミュニケーションが取れる
もしシニアエンジニアは技術だけを極めれば良いと思っているのであれば考えを改める必要があるかもしれません。
技術スキルはもちろん重要ですが、ソフトスキルも同じくらい重要です。
ここで言う利害関係者とは、一緒に仕事をするエンジニアメンバーはもちろんのこと、デザイナーやPM、営業やマーケティング、カスタマーサクセスや経営者、ユーザーやお客様など、業務で関わる全ての人のことを指します。
適切なコミュニケーションとは、とても曖昧な表現ですが、例えば、技術的な話を営業の方やカスタマーサクセスの方にも伝わる表現で説明できること、ユーザーが抱えている課題を相手の立場・目線に立ってヒアリングできることなどを指しています。
技術的負債に関する説明をするシチュエーションで考えてみましょう。
- 技術的負債とは何か
- なぜこのタイミングでこの技術的負債を解消する必要があるのか
- 技術的負債を解消することによってどのような効果が得られるのか
といったことを、説明する相手の立場や目線に立って説明することが求められます。
つまり、コミュニケーションを取る相手の立場や目線に立って考えてコミュニケーションを取るということがシニアエンジニアには求められます。
文章で書くととても当たり前のことのように感じますが意外とできていないことも多いように感じます。
言うは易く行うは難しですね。
他のエンジニアのお手本となれる
シニアエンジニアの重要な役割の一つがチーム内で他のエンジニアの模範となることです。
まず、コーディングの面では、可読性・保守性・変更容易性の高いコードを書くことが求められるでしょう。
コードレビューにおいては、単に問題点を指摘するだけではなく、なぜその実装が問題なのかを分かりやすく説明することでチームメンバーの成長に貢献することが求められるでしょう。
そして、シニアエンジニアは仕事への取り組み方を持ってお手本となることが求められるでしょう。
常に学び続ける姿勢、新しい技術への好奇心、ユーザーを中心に考える姿勢、そして謙虚さと協調性を持って仕事に取り組む姿勢は、ジュニアエンジニアにとって最も価値のあるお手本たり得ます。
最後に
色々と記載しましたが、企業規模や業界、組織文化によっても異なる点はあると思います。
ここに挙げたものが全てだと思っていませんし、挙げたものを全て満たしていないとシニアエンジニアと言えないかというとそうとも限らないと思います。
また、シニアエンジニアという呼び方ではなく別の呼ばれ方をしているケースだってあると思います。
私自身、ここに記載したことが全てできているとは思っておらず、一部自分のことは棚に上げてつらつらと記載しました。
なので、改めてこれからも精進していきたい所存であります。
この記事が、シニアエンジニアに必要なスキルって何だろう、エンジニアとして成長するためにはどんなスキルを身につければ良いんだろうと考えている方の参考に少しでもなれば幸いです。
参考にさせていただいた文献
Discussion