アーキテクトとテックリードの違い
はじめに
ITエンジニアの職種の中で、技術系の代表格として「アーキテクト」と「テックリード」が挙げられます。テックカンファレンスの登壇者の肩書きをみると、この二つはよく見かけるのではないでしょうか（大きなカンファレンスとなると、「CTO」という、フリーレンに登場する大魔法使いゼーリエ級の肩書きも見られますが）。
なんとなく最近の風潮としては、「アーキテクト」はあまり使われず、「テックリード」の方が好まれているような印象が（筆者には）あるのですが、「テックリード」って雰囲気先行で、定義が曖昧なままに使われていることも多いんですよね。まぁ、名乗る分には好きな呼称を使えばいいですし、この二つがなんとなく仰々しいと感じる場合は「エンジニア」でも「プログラマー」でも何でもいいんだろうと思います。
しかし、「自分はこれからテックリードを／アーキテクトを目指す」と言ったときには、「で、つまりどうなりたいの？」という質問に答えられなければなりません。
本稿では、アーキテクトとテックリードという職種ないし役割について、一般的な定義を確認し、また現場におけるソフトウェア開発の営みと照らし合わせて考察したいと思います。
アーキテクト
アーキテクトについては、情報処理推進機構（IPA）が定めるITスキル標準（ITSS）にITアーキテクトとしてキャリアパスが定義されており、同機構によるシステムアーキテクト試験も存在することから、その定義は明確です。後者に記載されている業務と役割を以下に引用します。
情報システム戦略を具体化するための情報システムの構造の設計や、開発に必要となる要件の定義、システム方式の設計及び情報システムを開発する業務に従事し、次の役割を主導的に果たすとともに、下位者を指導する。
1. 情報システム戦略を具体化するために、全体最適の観点から、対象とする情報システムの構造を設計する。
2. 全体システム化計画及び個別システム化構想・計画を具体化するために、対象とする情報システムの開発に必要となる要件を分析、整理し、取りまとめる。
3. 対象とする情報システムの要件を実現し、情報セキュリティを確保できる、最適なシステム方式を設計する。
4. 要件及び設計されたシステム方式に基づいて、要求された品質及び情報セキュリティを確保できるソフトウェアの設計・開発、テスト、運用及び保守についての検討を行い、対象とする情報システムを開発する。
なお、ネットワーク、データベース、セキュリティなどの固有技術については、必要に応じて専門家の支援を受ける。
5. 対象とする情報システム及びその効果を評価する。
https://www.ipa.go.jp/shiken/kubun/sa.html
ざっくりまとめると、「要件を満たすシステムを顧客へ提供するために、システム全体の構造や個々のシステムの構造のグランドデザインを描き、動作するソフトウェアとして実現する人」といったところでしょうか。
全体構造（システムアーキテクチャ）の面が強調され過ぎると、実際にコードを書かないのに上から目線であれやこれや言ってくる人、いわゆる「象牙の塔のアーキテクト」のイメージが強くなってしまい、そういった理由から「アーキテクト」の呼称をネガティブに感じる人が一定数いることは理解できます。
テックリード
一方、テックリードについては標準的な定義がなく、一般的な定義はあるものの認知度が高くないために、世間における使われ方が多少混沌としています。
一般的なテックリードの定義
まずは一般的な定義を確認しましょう。
求人検索サイトIndeedにおけるテックリード（Technical Leads）の定義は以下となっています（日本語訳は筆者）。
A technical lead is a professional who oversees a team of technical personnel at a software or technology company. They often lead software development or software engineering teams and troubleshoot technical issues that involve software development, engineering tasks and product releases.
A technical lead needs to have a great deal of professional experience in software development and a deep understanding of technology, but they should also be personable and capable enough to effectively lead a team and collaborate with others.
テックリードは、ソフトウェア企業やテック企業で技術者チームを監督する専門家です。テックリードはソフトウェア開発チームやソフトウェアエンジニアリングチームを率いて、ソフトウェア開発、エンジニアリング作業、製品リリースに関わる技術的課題の解決にあたることがしばしばあります。
テックリードには、ソフトウェア開発における豊富な専門的経験と技術に対する深い理解が必要ですが、それだけでなく、チームを効果的にリードし他者と協力することができる人柄と能力も必要です。
https://www.indeed.com/career-advice/finding-a-job/technical-lead
また、『エンジニアのためのマネジメントキャリアパス ―テックリードからCTOまでマネジメントスキル向上ガイド』（著：Camille Fournier 著、訳：武舎 広幸、武舎 るみ、2018年刊行、オライリージャパン）には以下のように書かれています。
テックリードは、技術的なプロジェクトのリーダー役を果たし（個人ではなくチームという）より大きなスケールで自身の専門知識を駆使してチーム全体の向上を図る、という立場にあります。…（中略）…。関係者の心をつかめなければリーダーシップは発揮できませんから、テックリード役を初めて任された人に技術的な専門知識の増強よりもはるかに求められるのは対人能力の強化なのです。
ポイントは、リーダーシープやコラボレーション、コミュニケーションといったソフトスキル面が重要視されていることです。単に技術的卓越性を持ち合わせているだけでなく、それをバックグラウンドとして、チームを引っ張り、チームとして結果を出す責務が求められているのです。
こう考えると、日本語では「開発リーダー」と言った方がしっくりくるかもしれません。もう少し的確に表現すると「コードの書ける開発リーダー」でしょうか。
テックリードのイメージ（日本のみ？）
日本で「テックリード」と言うときは、開発リーダーの役割が薄れて、「突出した技術力で周りを引っ張ったり、支援をしたりするエンジニア」というイメージで使用されることが多いように思います。そのため、「フロントエンドテックリード」とか「Flutterテックリード」のように、特定の技術領域やフレームワークに特化していることもあり、その場合は社内外で啓蒙活動を行う「エバンジェリスト」に近い役割を担う人もいます。
さて、本稿では混乱を避けるために、前者（本来の一般的定義）をテックリードα、後者（日本で普及しているイメージ）をテックリードβと呼ぶことにします。
なお、どちらが優れているかいったようなことをを論じる趣旨はありませんのでご承知おきください。
職種としてのアーキテクトとテックリード
本稿の主旨は、ITエンジニアとしてのキャリアプランを考える上で、アーキテクトとテックリードの職種や役割の違いを確認し、整理しておくことです。ということで、実務に照らし合わせて見てみましょう。
プロジェクトチームやプロダクト開発チーム
システム構築プロジェクトやプロダクト開発を行うチームを考えます。いわゆる「ピザ2枚チーム」、8〜10名程度のチームを想定します。次の図は開発チームの一例です。
開発リーダー役を担うテックリードα（Aさん）は必須です。チームが正しい方向に進むように導いたり、局面で正しいジャッジをするためには一定の技術力や経験が必要となりますが、チーム随一の技術力の持ち主である必要はありません。ソフトスキルやマネジメント力が重要となるポジションです。
アーキテクチャの設計から実装まで、いわゆるアーキテクティングを主導する役割がアーキテクト（Bさん）です。小さなプロジェクトでは専任の人をおかないこともあります。その場合は開発リーダーやその他開発者がその役割を兼任したり、複数人でアーキテクティングの作業を分担したりします。
特定の技術領域において技術的卓越性を発揮し、周囲を引っ張ったり支援したりする役割のテックリードβ（Cさん、Fさん）を必要に応じてアサインします。この例では、フロントエンドとバックエンドのそれぞれの領域で人を割り当てています。
図のDさん、Eさん、Gさん、Hさんが仮に「駆け出しエンジニア」だとすると、プロジェクトの中で開発経験を積み、テックリードβの支援を受けつつ自身の技術力を上げていきます。その過程で自分の得意領域を見つけ、それを磨いていき、周囲に影響を与えらえるようなレベルに達したならば、次のプロジェクトではテックリードβの役割にチャレンジ、というキャリアラダーになるのではないでしょうか。
テックリードβで経験を積んだ後、次に向かうべき道はどうでしょうか。技術者集団としてのチームを創り、チームとして課題に立ち向かいソフトウェアをリリースすることにやりがいを感じるなら、テックリードαが向くでしょう。アーキテクティングという専門分野を自分の中の核にしたいならば、アーキテクトを目指すことになります。どっちもやりたい欲張りな方はそれもOKです（ただし最初から二兎を追うのは失敗するリスクが高いので、ドラクエの転職システムのように、一つずつ職を極めていくスタイルがよいでしょう）。
クロスファンクショナルチーム（機能横断型チーム）
特定のシステムやプロダクトの開発を行うチームではなく、組織をまたがって横断的に開発チームを支援する組織の場合はどうでしょうか。いわゆるセンター・オブ・エクセレンス（CoE）と呼ばれる組織です。
このモデルではアーキテクトもテックリードβもCoE組織に所属し、プロジェクトやプロダクトの開発チームに対して支援を行います。その性質上、テックリードαはCoE組織には存在しません。開発チーム側に入り込んでテックリードα（開発リーダー）の役割を担うケースもなくはないですが、稀でしょう。
CoE組織のアーキテクトもテックリードも、各々の主要な職務はその定義から変わりはありませんが、以下のような追加の職務が発生するでしょう。
横断的な支援によって得られた知識やノウハウを整理し、再利用可能な情報資産として蓄積する
社内外で啓蒙活動を実施する
社外活動については、企業の技術力を対外的にアピールし、優秀な人材獲得に繋げたいという人事戦略にも関わるため、その実績が人事評価において加点対象となるような制度の会社もあるでしょう。また、この観点で見ると、アーキテクトいうある意味で汎用的な職種よりも、「XX領域で業界屈指のテックリード」という触れ込みの方が、魅力的に映るのかもしれません。
個人のキャリア実現観点からは、開発チーム所属だろうがCoE組織所属だろうが、テックリードだろうがアーキテクトだろうが、社内だろうが社外だろうが、積極的に情報発信をしていくのはよいことです。技術者としての成長に繋がりますし、またプレゼンスの向上によって社内外での認知が高まり、さらに成長できるチャレンジャブルな機会を与えられる、といった好循環が生まれます。
まとめ
アーキテクトでもテックリードでも、その他何であれ、自分の好きな呼称を使えばいい
だけど自分が目指すキャリア像やその役割・職務は明確にイメージできるようにしよう
自己実現のためには積極的なアウトプットや情報発信を続けてプレゼンスを高めていくことが重要
この記事が気に入ったらサポートをしてみませんか？