40代シニアソフトウェアエンジニアが見つけた「燃え尽きない」ための“バランス”

2025年6月12日

竹添 直樹

トレジャーデータ勤務、プリンシパルソフトウェアエンジニア。新卒で零細SES企業に就職し様々な現場を渡り歩いたのち、趣味として行っていたOSS活動をきっかけに某大手SIerの子会社に転職、OSSを活用した研究開発プロジェクトからアジャイル受託開発、大手ユーザ企業での内製支援など9年ほど務めたのちSI業界を離れ、Webサービス企業でCTO直属チームとして新規サービス立ち上げ、技術広報等に従事したのち現職。イングランドプレミアリーグのアーセナルを応援しています。
X: @takezoen
GitHub: https://github.com/takezoe
ブログ:「たけぞう瀕死ブログ」

トレジャーデータ入社後、ソフトウェアエンジニアとして一心不乱に働いてきました。徐々にチームメンバーも増えていき、気付くとチームでも古株となり、チーム統合などを経てチームも拡大。いつの間にかタイトルも「スタッフソフトウェアエンジニア」(現在はその上の「プリンシパルソフトウェアエンジニア」)というものになっていました。

日本ではまだあまり馴染みのない「スタッフエンジニア」という呼称ですが、いったいどのようなものなのでしょうか。

今回は、私がソフトウェアエンジニアとして働き続けてきた中、スタッフエンジニアとなった後の役割の変化、その変化にどのように適応したかという振り返り、そして長くソフトウェアエンジニアとして働き続けるために必要なことを私自身の経験に基づいてまとめます。

組織に「スタッフエンジニア」のポストが置かれる意義

スタッフエンジニアやそれ以上のエンジニア職を指す「スタッフプラス」は、聞き慣れないという方もいるかもしれません。

スタッフプラスのキャリア
▲「スタッフプラス」のキャリアパス

最近では日本語でもいくつかの関連書籍が出ています。

『スタッフエンジニア マネジメントを超えるリーダーシップ』の中ではスタッフプラスエンジニアを以下の4つのタイプに大別しています。

テックリード…所属するチームもしくは複数のチームのマネージャーと密接に連携してチームをアプローチや実行へと導く
アーキテクト…重要分野において技術面だけでなくユーザのニーズや組織面なども考慮の上で方向性や質、アプローチへの責任を負う
ソルバー…技術に深く精通し、困難な問題解決に取り組む。特定の領域に長期間取り組むこともあれば、組織内の技術的なホットスポットを飛び回るケースもある
ライトハンド…幹部の右腕(補佐役)としてその権限を代替し複雑な組織の運営にあたる

スタッフエンジニアやスタッフプラスというタイトルを用意していない場合でも「テックリード」や「アーキテクト」というロールを採用している企業は多いのではないでしょうか。また技術に特化した「ソルバー」もイメージしやすいところかと思います。「ライトハンド」はかなり特殊な役どころで立ち回りも難しいところですが、大規模な組織において経営陣のリーダーシップを広げるためにこのような存在を必要とすることもあるかと思います(ただ、個人的にはここまで来ると、一般的なソフトウェアエンジニアのロールとは呼び難いのではと感じるところもあります)。

いずれにしろ共通するのは「チームや組織レベルの成果に影響を及ぼすことが期待されている」という点です。

こういった管理職以外のエンジニアのキャリアパスは、組織内で前例がなかったり、前例があったとしてもサンプル数が少ないことがほとんどです。そのため、本人の適性と組織からの期待値の間で齟齬が起きやすく、活かし方に困る組織も多いのではないかと思います。

組織が適性のないエンジニアを無理に昇格させたり、パラシュート人事で配置したりして、本人が大変苦労するという例を、私自身もこれまで何度も見てきました。

一方で、このような分類があると、組織としても所属するメンバーの適性に応じた役割を用意することでシニアなエンジニアを活かしやすくなりますし、エンジニアとしても長期的に働きやすくなるのではないでしょうか。

スタッフプラスになり、自然と担うようになった“マネジメント”の役割

現在の私の立場としては「テックリード」が近いのではないかと思います。

これは平たく言えば「ソフトウェア開発チームのリーダー的な役割」だと思います。前述のように、スタッフプラスエンジニアには様々なタイプに分類できますが、現実的にはこのタイプが多数を占めるのではないでしょうか。トレジャーデータでもスタッフプラスエンジニアの責務の中には「マネジメントへの関与」が含まれています。

もちろん、前述のスタッフプラスエンジニアの分類における「ソルバー」のように、組織レベルの問題を解決するような高度な技術を持つエンジニアであれば、マネジメントに関与せずに技術一本で生きていくことも可能かもしれません。しかしそれは、その組織や業界においてトップオブトップの一握りのエンジニアのみ選ぶことのできる道であると感じています。

多くの場合はエンジニアとしてのキャリアパスを歩むにしてもいずれマネジメントへの関与を期待されるのではないかと思います。これは私自身、一ソフトウェアエンジニアとして働くことができる状況に、3度も終わりを告げられてしまったということを意味するわけですが(詳しくは前回の記事をご覧ください)、今回はこの「マネジメントへの関与」を不思議と自然と受け入れられたところがありました。

当時は疑問に感じなかったのですが、これまでの転職の動機を考えると不思議な話です。今の役回りを自然に受け入れることができたのは、周囲の環境や出来事がどのように私の心境に影響を与えた結果なのだろうか、といまさらながら振り返って考えてみました。

・突然役割が変化したわけではなく、同じチームで数年間働く中で自然と他のメンバーのサポートやチーム内でのコーディネーションなどを担当するようになっていた
・トレジャーデータには個性的かつ技術的に優れたエンジニアが多数在籍しており、チームとして自分の強みをより活かすことができるのはマネジメント的な役割であると感じるようになった
・チームのマネジメントについてはエンジニアリングマネージャーという専門家がおり、自分はエンジニアとして働き続けることができるため、現場から離れなければならないという不安がなかった

結果的にではありますが、トレジャーデータでもう一度ソフトウェアエンジニアとして1つの領域や、チームで腰を据えて働く時間を得ることができたおかげで、自然とこのような心境の変化に至ることができたのではないかと思います。

現在はマネージャーと連携してチームを運営しています。これも前回紹介したとおり、私が所属するチームはメンバーが地理的に分散していたり、チーム統合などを経て以前と比べるとチームの技術領域や規模が拡大してきたといった事情もあり、マネジメントの難易度が高いチームだからではないかと思います。

そのため、チームとマネージャーの架け橋になるということも現在の自分の役割の1つと認識しています。こういった面において自分でマネジメントを行わないにしろ、マネージャーが何を考えているか、どのような情報を必要としているかなど、前職までの経験で学んだマネジメントやエンジニアリング組織からの視点が役立っていると感じています。

エンジニアの“勘”を鈍らせないためにOSSを通じてコードに触れ続ける

一方で、役割がシフトすることでどうしても実際にコードを読んだり書いたりする時間は少なくなってきてしまうことは避けられません。

もちろん、チームとしての成果を最大化するためにメンバーに頼るのも必要なことですが、完全にコードから離れてしまってはそもそもソフトウェアエンジニアを続けている意味がありませんので、業務内でも業務外でも意識的にコードを触る時間をつくるようにしています。

ここは正直個人のエゴもありますので、チームの迷惑にならない範囲で細かい改善タスクを取ってプログラミングの時間をつくったり、業務外の時間をOSS活動に割いたりして勘が鈍らないようにしています。

ちなみに、OSS活動については以前から趣味として行っていたものですので、特に意識して続けてきたわけではないのですが、結果として、これまでのキャリアの様々なポイントにおいてソフトウェアエンジニアとしての拠り所になってきたと感じています。

OSS活動が仕事や転職の機会に直接繋がったということもありますし、自分で開発したOSSを世界中のユーザに使ってもらうという経験や、海外を含む技術カンファレンスへの登壇や書籍の執筆など貴重な機会を得ることもできました。なにより業務でなかなかコードを書けなかったり技術に触れられない時期でも、OSS活動で欲求を満たすことができました。

自分にとって、OSS活動という業務外でコードに触れることのできる場所があったということは、ソフトウェアエンジニアとして20年以上成長を続けてきた中で、とても大きな助けになったことは間違いありません。

現在は業務でTrinoというOSSの分散クエリエンジンを扱っています。個人のOSS活動でもTrinoやその周辺領域を中心に取り組んでおり、OSS活動で得た知識や成果が業務でも大いに役立っています。単にコードに触れる機会を維持するというだけでなく、実益を兼ねた素晴らしい趣味になっています。

ソフトウェアエンジニアとして長く働き続けるための戦略

現職であるトレジャーデータでは、かれこれ6年以上ソフトウェアエンジニアとして働くことができているのですが、1つ強調したいのは人によってどのような環境が適しているかは千差万別だということです。

事業領域や組織のカルチャー、さらには一言でソフトウェアといっても技術領域や実際の作業内容など考慮すべき要素は様々です。たとえば、現在の私のチームではOSSのミドルウェアを扱っているため、自分でコードを書くよりも運用や調査にかける時間の方が圧倒的に長く(1週間かけて調査して、結果的に1行のコードを直すだけということもよくあります)、ソフトウェアエンジニアといってもバリバリコードを書きたいという方にはあまり向いていないだろうと思います。

また、キャリアのフェーズによっても最適な環境は異なるはずです。ソフトウェアエンジニアに限った話ではありませんが、まずは自分にあった環境を探すことが長く働き続けるために重要なことだと思います。

とはいうものの、最近は寄る年波に勝てず、体力的にソフトウェアエンジニアを続けるのは難しいかもしれないとも感じることも増えてきました。若い頃と比べると集中力も落ちていると感じますし、運用にも携わっているとオンコールや障害時の緊急対応なども年々辛さを感じるようになってきました。体もあちこち痛くなってきましたし、最近は老眼も来ているのか、ディスプレイを見るのも辛くなってきたところもあります。

個人的に、プロダクションシステムから離れてしまうことへの不安はどうしてもあります。

完全に現場を離れるということはいまのところ考えていませんが、今後も長くソフトウェアエンジニアを続けるためにはむしろ少し距離を置いたり、充電期間を取ったりするのもよいのかもしれないと感じることもあり、最近はプライベートの時間に仕事とはまったく異なる趣味をつくることで、ON/OFFの切り替えをしたり、長めの休暇も積極的に取ったりするようにしています。

ソフトウェアエンジニアは燃え尽き症候群の割合が高い職業とも言われています。長くソフトウェアエンジニアを続けていくのであれば、こういったフィジカル・メンタル面の問題に気を配ることが実は一番大切なことなのかもしれません。

関連記事

人気記事

  • コピーしました

RSS
RSS