マネジメントをやりたくないエンジニアは、何を避けたいのか
設計や実装を中心に経験を積んできたエンジニアが、「次はリーダーをやってみないか」と打診される。周りの同僚もPLや管理職へ進み始め、自分もそろそろマネジメントを考える時期なのだろうか、と迷うことがあります。
技術を身につけることが楽しくてこの仕事を選んだのに、これからは会議や調整ばかりになるのではないか。現場から離れて、手を動かす時間がなくなるのは嫌だ。そう感じる人もいるでしょう。
私自身、採用面接で「マネジメントより、現場で技術を中心に仕事をしたい」というエンジニアに一定数会ってきました。ただ、話を聞いてみると、何を避けたいのかは人によって違います。人事評価や勤怠の管理をしたくない人もいれば、設計や実装から離れたくない人もいる。まだ経験していない役割を、周囲から聞いた話で判断している場合もあります。
「マネジメントをやりたくない」と感じたら、まずはその中身を分けて考えてみてください。技術の軸を保ちながら、チームの成果に関わる範囲を広げる方法もあります。その一つが、技術的な判断で開発を前に進めるテックリードです。
この記事では、テックリードの具体的な仕事と、実装担当からそこへ進むための5つのステップを紹介します。PLへの向き不向きを考えたい方は、PLに向いている人・向いていない人も参考にしてください。
「やりたくない」の中身を分けてみる
マネジメントという言葉には、異なる仕事がまとめて含まれています。嫌だと感じる部分をはっきりさせると、次に身につけるべき能力も変わります。
人の管理を避けたい。 勤怠管理、人事評価、予算の管理に関心が持てない。この場合、技術面でチームをリードする仕事まで避ける理由はありません。ただし、テックリードもメンバーの作業を見たり、困っている人を支援したりします。「人の管理」と「人と協力して成果を出すこと」は分けて考えたいところです。
技術から離れたくない。 新しい技術を調べ、設計を考え、難しい不具合を解決する。その仕事を続けたいなら、技術的な責任を広げる方向が考えられます。ただ、テックリードになったからといって、自分の実装時間が増えるとは限りません。レビューや設計方針の検討、ほかのメンバーへの説明にも時間を使います。
調整や板挟みがつらそう。 顧客からの要望、納期、開発現場の事情。その間に立つのが苦手だと感じる人もいるでしょう。ここは少し慎重に見ておきたいところです。テックリードも仕様の曖昧さを顧客と確認したり、技術的な制約を説明したりします。対人調整そのものは残ります。
もう一つ確かめたいのは、その苦手意識が自分の経験から来ているかどうかです。実際にリーダーの補佐をして負担を感じたのか。それとも、忙しそうな上司の姿やインターネット上の体験談から、同じことが起こると想像しているのか。後者なら、小さな役割を引き受けてから判断しても遅くありません。
当社が公開しているキャリアの道筋でも、伸ばす能力は分かれています。PLの道では、プログラムマネジメント、予算・リソース管理、経営層への提案力、組織マネジメント。テックリードの道では、システム構成の設計、技術選定、性能・品質の課題解決、既存システムの解析、そして得た知識をチームへ還元する力です。
どちらを選んでも、自分一人の仕事を終える力の先が問われます。何に責任を持ってチームを動かしたいか。その違いが選ぶ基準になります。
テックリードとは、技術の判断でチームを前に進める役割
テックリードの仕事を「チームで一番プログラミングができる人」と考えると、実際の役割を見誤ります。難しいコードを書けることは強みです。ただ、テックリードに期待されるのはその先で、技術力を使ってチーム全体の設計・開発を成立させることです。
既存システムに新しい機能を追加するとします。テックリードは、その機能が作れるかどうかに加えて、既存機能への影響、データの整合性、性能、セキュリティ上の懸念まで確認します。実現方法が複数あるなら、利点とリスクを整理して設計方針を決める。必要なら顧客にも技術的な理由を説明します。
工数見積も重要な仕事です。技術と既存システムを理解していれば、実装作業のほかに必要な調査や試験、影響範囲も見通せます。わからない部分は前提条件として示し、無理のある見積もりを見過ごさない。この判断が、その後の進捗や納期を支えます。
開発が始まれば、設計書やコードのレビューを通じて問題を早めに見つけます。メンバーが行き詰まったときには技術的な助言を行い、担当者によって品質が大きく変わらないように設計上の考え方も共有する。
PLは顧客との合意形成やチーム運営を軸に開発を進め、テックリードは技術的な課題や設計開発の実務に深く責任を持ちます。PLも技術判断を担うため、実際の仕事には重なる部分があります。役割の整理はPLとPMの違いを扱った記事でも紹介しています。
テックリードになるには、設計と技術判断の経験を積む
では、テックリードになるには、どんな経験を積めばよいのか。最初からプロジェクト全体の技術方針を決めたり、複数のエンジニアを指導したりする必要はありません。自分の担当機能から始めて、技術判断の範囲を少しずつ広げていけばよい。一つの道筋として、次の5段階で考えてみます。
STEP 1：実装担当から、詳細設計に責任を持つ
最初の段階は、与えられた設計に沿って実装する仕事から、自分で設計の妥当性を考える仕事へ進むことです。既存システムにデータ更新処理を追加するとして、処理を実装するだけなら、設計書に書かれた手順をコードにすれば済むかもしれません。設計を担うなら、更新途中でエラーが起きたらどうなるか、既存機能に影響しないか、どんなテストが必要かまで考えます。設計書に不足があれば、自分から修正案を出す。
次へ進む目安： 自分が担当する機能について、設計の理由、変更の影響範囲、品質上の懸念を説明できる。
詳細設計の経験をどう積むかは、実装から詳細設計・基本設計へ進む記事で詳しく紹介しています。
STEP 2：複数の実現方法を比較し、技術判断を行う
設計に慣れてきたら、作り方の選択肢を自分で検討します。システムの処理が遅いという問題があったとして、データベースへのアクセスを減らすのか、SQLを直すのか、処理の構成そのものを変えるのか。原因を調べ、それぞれの方法で期待できる効果と改修リスクを比べます。ここで問われるのは、なぜその方法を選んだのか、ほかの方法では何が問題になるのかを説明できるかどうかです。
次へ進む目安： 複数の技術案を比較し、性能・品質・保守性などの判断基準を示して、採用する方法を提案できる。
STEP 3：顧客と仕様を決め、設計に落とし込む
次は、技術判断の対象を、自分の担当機能から顧客の要求や業務へ広げます。顧客から「処理をもっと速くしてほしい」と言われたら、どの処理が遅いのか、利用者が何に困っているのか、どの程度の速度が必要なのかを確認します。求められているのが画面の応答速度なのか、夜間バッチの終了時刻なのかで、解決策は変わります。業務上の制約や既存システムの事情も踏まえて、実現方法を提案します。
顧客の要望を技術的な仕様へ具体化し、曖昧な点を残さず合意する。技術力に加えて、相手の話を理解し、説明する力が要る段階です。
次へ進む目安： 顧客の要求から技術的な論点を洗い出し、実現方法・制約・影響範囲を説明して、仕様の決定に関われる。
STEP 4：レビューと技術支援で、チーム全体の品質を支える
ここからは、自分以外のエンジニアの成果にも関心を広げます。ほかのメンバーが作った詳細設計書をレビューし、考慮漏れや仕様との食い違いを見つける。コードレビューでは修正を指示して終わりにせず、なぜ問題なのか、どう直すべきかを説明します。工数見積も同じです。担当者から出てきた見積もりについて、技術的な難しさや調査の必要性を確認する。開発中に問題が起こりそうなら、期限が迫る前に技術面から支援します。
一人で難しい仕事を解決する能力から、チームが安定して成果を出せるようにする能力へ。ここが大きな転換点です。
次へ進む目安： ほかのメンバーの設計や見積もりを技術面から評価し、レビューや支援によって問題の早期発見・解決に貢献できる。
STEP 5：テックリードとして、プロジェクトの技術方針を担う
ここまでの経験を土台に、プロジェクト全体の技術的な判断へ責任を広げます。新しいシステムの開発なら、採用する技術やシステム構成を検討し、性能・可用性・セキュリティの要件を踏まえて設計方針を決める。既存システムの改修なら、複数の機能や外部システムとの関係を理解し、変更の影響とリスクを評価する。必要な調査や開発作業を整理し、メンバーの技術的な適性も見ながら担当を割り振ることもあります。
自分がすべてのコードを書くわけではありません。メンバーが適切に判断できるように技術方針を共有し、重要な設計をレビューする。PLと連携して技術的な課題を解決し、プロジェクトが予定どおり品質を確保できるよう支えます。
この段階で期待されること： 個別の機能からシステム全体まで技術的な課題を見通し、設計方針・品質・リスクについて判断し、チームの開発を前に進められる。
もちろん、進む順番は人によって違います。顧客との仕様調整を先に経験する人も、レビューや後輩の支援から役割を広げる人もいます。この5段階は、身につける能力と経験の広がりを整理したものです。社内のクラスや昇格条件とは別のものと考えてください。
テックリードのキャリアパスと、その先の選択肢
テックリードになった後も、技術を中心にキャリアを広げる道があります。
一つは、より難しい技術課題を解決する方向です。個別システムの設計から、複雑な既存システムの改善、大規模なデータ処理、複数システムの連携へ。扱う問題が複雑になるほど、特定の技術に詳しいだけでは対応できなくなります。業務や運用を深く理解し、複数の条件を踏まえて最適な方法を選ぶ力が要ります。
もう一つは、技術判断の及ぶ範囲を広げる方向です。単一チームの設計方針から、プロジェクト全体の技術方針へ。複数の開発チームで設計上の考え方をそろえたり、共通する技術的な問題を解決したりと、より広い範囲に責任を持つ仕事です。
技術面で経験を積んだ後に、PLや組織マネジメントへ進む選択もあります。技術を理解していることは、進捗や品質のリスクを把握し、顧客と合意形成するときにも役立ちます。テックリードを目指すと決めても、その先の進路はあとから選び直せます。当社でも、技術でリードし続けながら、さらに上位のクラスへ進む道は制度上開かれています。
キャリアパスを考えるときは、次にどんな肩書を得るかより、どのような問題を、どこまで自分の判断で解決できるようになりたいかを考えてみてください。
自分に合うかを確かめる、最初の一歩
まずは、マネジメントの何を避けたいのかを書き出してみてください。人事評価や予算の管理か、技術から離れることか、顧客やメンバーとの調整か。それぞれについて、実際に経験して負担を感じたのか、周りの話から想像しているのかも分けてみます。
次に、先ほどの5ステップのうち、いま自分がどこまで経験しているかを確かめます。詳細設計は一人でできるが、技術選定を提案した経験は少ない。それなら、次の仕事で実装方法を複数比べ、判断の根拠を説明する機会を作ってみる。自分の担当機能の設計はできるが、ほかのメンバーのレビューは経験していない。それなら、レビューに参加するところから始める。
いきなりリーダーの肩書を得る必要はありません。いまの仕事から一段だけ範囲を広げてみる。その経験で、技術的な判断をすることや、ほかの人の開発を支えることに面白さを感じるかどうかがわかります。
何がやりたくないかを考えるのも大事ですが、何をできるようになりたいかが具体的になると、次の行動は決めやすくなります。
スーパーソフトウエアで、技術でチームをリードする道
スーパーソフトウエアでは、チームを率いる段階にPLとテックリードの二つの担い方を設け、同じクラスとして評価しています。テックリードはプロジェクトの中で担う役割で、クラスの名前とは別です。制度の全体像はキャリアページで公開しています。
当社がテックリードに期待しているのは、技術の詳しさをチームの成果に変えることです。実態に合った見積もりを組み立て、設計上の問題を早めに察知し、メンバーを支えながら開発を前に進める。技術判断がチーム全体の成果につながっているかを見ています。
実際に、公共事業系システムの仕様を関連ドキュメントから丹念に読み解き、チームの誰よりも深く理解している社員がいます。その知識を生かして、チーム内の技術的な相談先になり、開発担当の割り振りやレビューも引き受けています。長年扱われてきたシステムには、資料を読み込まなければ理解できない仕様や複雑な制約が数多くあります。その知識を自分の仕事だけに使うのではなく、ほかのエンジニアが適切に開発できるように生かしている例です。
当社が掲げる「開発推進力」のうち、設計やリスクを見極める判断する力と、知識をレビューや支援を通じて広げる共有する力が、ここで生きます。
技術を軸に仕事の幅を広げたい方は、AWS領域のテックリード・PL求人もご覧ください。
この記事のテーマについて、もっと話を聞いてみたい方へ：
- カジュアル面談を申し込む — 30〜45分のオンライン面談
- 募集職種を見る — テックリード・PLを担う求人を含む一覧
- キャリアを知る — PL とテックリード、2つの担い方
- PLに向いている人・向いていない人 — PLという選択を考えるとき
- 他のキャリア記事を読む — PL／上流工程／キャリアに関する他の記事
