株式会社Voicy Tech Lead 三上氏の発表
三上氏：
株式会社VoicyでTech Leadをしております三上と申します。ニックネームは「みっきー」と呼ばれてます。voicyには2020年1月に入社し、現在4年目になります。
当初はテックリードとして入社しましたが、途中で1年半程度エンジニアマネージャー（EM）の役割も担い、その後再びテックリードに戻っています。
専門はバックエンドエンジニアリングです。ソフトウェアエンジニアとしてはWeb開発に18年の経験があります。
これまでには受託開発、客先常駐、スタートアップなど、多様な環境で働いた経験があります。また、CTOやEMなど、人事面でも経験を有しています。テックリードとしては累計で3年程度、複数の企業で勤めました。
現在の会社では、スマートフォン1台で音声コンテンツを楽しめるプラットフォームを開発しており、設計から開発まで幅広く携わっています。最近は特に、パーソナリティ向けのサービスのバックエンドエンジニアリングに注力しています。
これまでの経歴としては、数名から50名規模の企業で働いてきました。Voicyに入社する前は、BtoB向けのコンテンツマーケティングSaaSのサービスに携わっていました。当初はバックエンドエンジニアとして参加し、後にCTOが退職したため、私がその役職を引き継ぎました。次の会社では、アンケートを用いたNPS調査分析サービスを提供していました。初めてテックリードとして参加し、後にはCTOが退職した際に開発部門長として活動しました。
その後、Voicyにテックリードとして入社。状況によりEMも担当し、現在は、役割を交代しテックリードを担っています。
このように、いろんなポジションでの経験を積んでいます。その中で、組織には、以下の4つのマネジメントが必要だと考えるようになりました。
- テクノロジーマネジメント
- プロジェクトマネジメント
- プロダクトマネジメント
- ピープルマネジメント
テックリードは、主にテクノロジーマネジメントの仕事に区分されると考えています。
スタッフエンジニアの書籍によると、テックリード、アーキテクチャ、アーキテクトなどの役割は4つに分類されています。アーキテクチャに関わる仕事は全体の約5%で、開発が大体45%を占めています。コードレビューは約5%しか行っていないのは、各プロダクトごとにチームがあり、それぞれのチームに設計やアーキテクチャを担当するエンジニアがいるからです。したがって、私が一人で全てのアーキテクチャを考えたり、コードレビューに専念するわけではありません。
テックリードとしての仕事の内訳は、エンジニアのカルチャー構築が約10%、要件対応が約30%、開発が約50%です。
私からの発表は以上となります。ご静聴ありがとうございます。
佐藤氏：
ありがとうございました。テクノロジーマネージャーとしていろいろな影響力を発揮されていることがわかるお話でしたね。
続きまして、高松様の自己紹介LTも続けてお願いします。
MODE, Inc. Software Engineer 高松氏の発表
高松氏：
改めまして、自己紹介させていただきます。
高松真平と言います。「shin」と呼ばれることが多いので、そう呼んでくれたら嬉しいです。
ソフトウェアエンジニアとしては13年目になります。最初はSIerでキャリアをスタートしました。主にスタートアップ企業で仕事をしてきました。企業規模は、最小でCEOと数人のメンバーから、最大で全社で50人程度までと、様々です。グローバルには大きな企業もありますが、東京オフィスは小さい場合もあります。
過去にはVPoE（Vice President of Engineering）のポジションを担当したこともあります。また、プロダクトマネージャーとしての経験も多いです。直近では、MODE, Inc.でソフトウェアエンジニアのポジションに就いています。
その傍らで、私は技術的な内容を中心にブログも書いていて、 その中でジョブロールや役割に関する話題もしばしば取り上げています。
一番左側の『テックリード」という役割』については、実は2017年、つまり6年前に初めて書いたんです。それでも今でも「読んだよ」というフィードバックを頻繁にいただいています。その当時、テックリードとは何かという疑問から、約1年間実際にその役割を担ってみた結果を記録しています。
中央の部分は、2021年、テックリードの役割を継続的に経験した後に、それ以上先にはどのような役割があるのかを考えたいとおもって書きました。この時はまさに「スタッフエンジニア」の本が出版される前だったので、その本を参考にしながら考えていました。
右側の部分は、当時多くのプロダクトマネジメントに関わっていたため、プロダクトマネジメントがどういうもので、どのように協働するかについても書いています。ジョブロールや役割に関する内容を多く発信していました。
と振り返ってみると、13年のキャリアの中で、初めの4～5年間はひたすらコードを書いてスキルを上げようと努力していました。しかし、時間が経つにつれて、スキルは確実に上がっているはずなのに何かがうまくいかないという疑問が浮かんできました。
プロジェクトが遅れたり、品質が思うようにならなかったり、プロダクトが成長しなかったりする経験から、技術だけでなく他の要素も重要だと徐々に感じるようになりました。
エンジニアリングマネージャーになって採用も担当するようになったところで、明確にロールや役割について説明できる必要性を強く感じました。具体的には、このポジションで求めている人材が何か、明確に伝えないと採用が難しいという状況になりました。
プロダクト開発チームで必要な役割、例えばテックリードやスタッフエンジニアなどについても継続的に考えています。これらの役割について、できる限り明確に説明できるようにしたいと思っています。
ただ、ジョブロールについては多く発信しているものの、自分自身が特定のキャリアパスに固執しているわけではありません。
どのような役割がチームやプロダクトに必要なのかを理解し、必要ならばそのスキルを習得したいと考えています。その結果、多様なプロダクトや役割を経験してきたわけですが、それは現在必要なスキルや役割を自分で担うという決断から来ています。
MODE, Inc.には2023年6月から所属しており、ちょうど3ヶ月が経過しようとしています。
ジョブロールとしてはソフトウェアエンジニアです。当社には20人以上のエンジニアがいます。CTOを除いて、ほとんどが「ソフトウェアエンジニア」という役職で働いています。一部、サービスアーキテクトという異なる役職も存在しますが、ほとんどはソフトウェアエンジニアです。
現在の主な業務は、実装と設計に90%以上の時間を費やしています。Go言語を多用しており、ゲートウェイやサーバーに関するコードを書いています。また、インフラ構築にはterraformやserverless技術を使用しています。当社の文化として設計文書を丁寧に書くことが推奨されています。最近の1〜2週間では、この設計文書を作成し、関連するエンジニアやCTO、プロダクトチームとディスカッションを行っています。
まだ新しく参加したばかりでリーダーシップを発揮しているわけではありませんが、今日の話はこれまでの経験を踏まえて行いたいと考えています。
以上が私の状況と経歴です。ご静聴ありがとうございました。
佐藤氏：
ありがとうございます。お二人の自己紹介を聞いて感じたのは、お二人とも様々なポジションで働いてきたという点です。行ったり来たり、戻ったりと、おそらくお互いに話を聞いている中で親近感を感じている部分もあるでしょう。
今後は、さまざまなジョブタイトルやロールの違い、あるいはそれらの関係性についても、整理して話を聞けそうだと感じました。
ディスカッション
それでは、本日の主要な内容であるパネルディスカッションに移りたいと思います。今回は5つのテーマを用意しており、それぞれに沿ってお話を伺っていきたいと思います。よろしくお願いします。
ディスカッションテーマ①「アーキテクト、テックリードとの違いは何ですか？」
佐藤氏：
最初のテーマは、「アーキテクトとテックリードとの違いは何ですか？」というような質問になっております。先に三上さんからお願いしてもよろしいですか？
三上氏：
このテーマは複雑ですが、車に例えて説明してみます。
アーキテクトは、エンジンや車体を設計・製作する人です。目的は早く走る車を作ることや、運転しやすい車を作ることなどです。
一方、テックリードは整備士に近い役割だと考えています。テックリードの主な仕事は、車が長期間安定して走れるようにすること、維持管理を行うことです。
高松氏：
会社全体が50人でエンジニアが20人未満のような規模では、専任のアーキテクトがいることは少ないのではないでしょうか。
一方で、開発チームが存在する場合、そのチームを引っ張る人物は自然に現れるか、またはその役割として任命されると考えています。
具体的に弊社の状況を話すと、タイトルとして「テックリード」と名付けられた人はいません。皆がソフトウェアエンジニアとされています。ただし、中にはシニアレベルの人もおり、プロジェクトごとにプロジェクトのリーダーとして任命されることがあります。
この任命された人が実質的なテックリードで、プロジェクト内で他のメンバーのコードレビューをしたり、必要な決定を行うようなリーダーシップを発揮しています。
アーキテクトとテックリードの違いについては、確かにアーキテクトが主に設計に関わり、テックリードが整備を行うという違いがあると思います。
三上氏：
設計が主要なタスクになるのは、新規開発を行う時や、ゼロから何かを作らなければならない状況、またはプロダクトが増えてきた場合です。1つや2つのプロダクトであれば、一人で管理することも可能です。しかし、プロダクトが10個に増えたり、プラットフォームビジネスを展開している企業のように、プロダクトがどんどん増えていくケースでは、全体の整合性を考慮する必要があります。
このような場合、エンジニア組織が100人ぐらいいると、整合性を保つためには特定の役割が必要になると考えています。最近では、マイクロサービスやモジュラーモノリスといった概念がありますが、それらを適切に設計できる専任の人材が必要になるでしょう。
それゆえに、このような専門的な役割は、実際の業務が増えてきた後に肩書きとして付与されるケースが多いと感じています。
高松氏：
Netflixにおけるマイクロサービスの導入時期についてQiitaで記事を読んだことがあります。その記事によれば、企業規模が約50人になると、開発基盤の統一やマイクロサービスの設計を考慮し始めるようです。この段階で適切な対応をしないと、事態が収拾できなくなり、開発が遅延するリスクがあると書かれていました。
三上氏：
弊社にはiOSアプリが2つ、Androidアプリが2つ、PC向けの管理画面が3つ、そしてそれに対応するバックエンドがそれぞれあります。
リポジトリの数は多く、使用しているフレームワークやライブラリも様々です。例えば、私が入社した当初、3つの異なるORMのライブラリが存在していました。
これを標準化する必要がありました。標準化しないと、それぞれのプロダクトを修正する際に、異なる方法を覚える必要が出てきます。新入エンジニアの学習コストが増え、修正時間が長くなり、事業のスピードが遅れる恐れがあります。
そのため、標準化や統一を推進する役割が必要です。複数のプロダクトを横断的に見る立場、つまりテックリードの役割が、このような役割を果たしていくと思います。
佐藤氏：
ありがとうございます。実際に「スタッフエンジニア」というタイトルを持っている人が、アーキテクト的な役割を果たすのか、それともテックリード的な活動をするのかは、その場面やフェーズによって異なると思います。それでは、次のテーマに移ります。
ディスカッション・テーマ②どのぐらいのフェーズまたは現場で必要とされるのでしょうか？
佐藤氏：
ここまでの会話で少し触れられたようですが、高松さんからお話を聞かせていただけますか？
高松氏：
三上さんが先ほど指摘されたように、タイトルは後からつけられるものです。実際、スタッフエンジニアという名前が付いていなくても、そのような役割を果たしている人は多くの開発組織で存在すると考えています。
最近改めて「スタッフエンジニア」の本を読んでみましたが、技術戦略ビジョンの策定や経営者とのコミュニケーションなど、規模に関係なく必要な業務があると思います。そのような仕事は、開発組織内で確実に誰かが担当しているはずです。
スタッフエンジニアという明確なタイトルがあるかどうかは別として、そのような役割を果たしている人々は存在しています。しかも、その役割の重要性は増しているようです。ビジョンを明文化したり、ドキュメンテーションを整備するなど、時間をかける必要が出てくると、専門の人材が必要になると感じています。
弊社においては、現状20人ほどの規模で、1プロジェクトあたり5人以下、場合によっては1〜2人で構成されています。それに対するテックリードも何人かいる状態です。このような規模であれば、特定の「スタッフエンジニア」のタイトルは必ずしも必要ないかもしれません。
しかし、組織が成長してテックリードが4人、その下に各5人ぐらいが配置され、合計で20〜30人になるような場合は、組織全体を取りまとめる人が必要になります。そうなったときにスタッフエンジニアが必要になるのではないかと、私は考えています。
三上氏：
現在、弊社にはテックリードが2人います。従業員の総数は約60人で、その中でエンジニアは約20人です。したがって、大体10人のエンジニアに1人のテックリードがいる、という割合です。
具体的なプラクティスとしては、「2ピッツァルール」に近い形です。一つのプロジェクトには、大体8人から10人のエンジニアが関わっています。その中でも半分程度の人数がテックリードの管理下にあります。このような規模だと、組織全体を横断して全体を見ることができる人数だと感じています。
たとえば、20人程度のチームでテックリードがいないという状況は、少し厳しいと感じます。テックリードがいない場合、CTOがその役割を担っていることがあります。そういったケースでは、CTOは実際にはその役割を適切な人に任せたいと考えていますが、適切な人物がいないために仕方なく担当していると、よく耳にします。
高松氏：
私も20人の優秀なエンジニアを集めただけでは、必ずしも良い開発組織が形成されるわけではないと考えています。プロジェクトのスコーピングや取りまとめ、さらに他部署との連携を行うような人が自然と現れる必要があると思います。
特に組織が拡大し、組織的な形態をしっかり整える段階になると、テックリードのようなポジションやタイトルが必要になってくると感じています。
三上氏：
多くの人が機能開発に焦点を当てがちですが、私がテックリードとして行っている仕事の約半分は非機能要件に関わっています。具体的には、エンジニアレベルでしか課題を見つけられないような非機能要件について、いつ対応するのかという点を事業側とコミュニケーションしています。
パフォーマンスチューニングは一例で、画面の表示速度が遅すぎて使い物にならないといった場合は、成果がすぐに出ることが多いです。しかし、テストコードが不足している、あるいはリファクタリングが必要な場合には、いつこれらを行うのかという計画も必要です。そのような調整と計画をリードしていく役割が求められると考えています。
高松氏：
三上さんにお伺いしたいことがあります。ライブラリのバージョンアップなど、エンジニア以外には説明が難しい技術的な問題が出てくることもあります。このような場合、プロダクトマネージャーとどのように関わっていますか？プロダクトマネージャーは主に事業側と話をするという印象ですが、その関係性はどうですか？
三上氏：
我々のチームには、エンジニアリードのような役割を持つ人がおり、その人がスクラムマスターのような活動もしています。
プロダクトオーナーとコミュニケーションを頻繁に取っています。スプリントの計画段階で、特定の機能を作る際に予め発生しうるリスクや問題、必要な工数などを説明しています。例えば、あるSDKが半年後にサポートが終了するといったケースでは、その情報を早めに共有しています。このようにして、スプリントのプランニング時にリスクや課題を明示しています。
佐藤氏：
お二人ともありがとうございました。技術リードがいろいろな場所で分散し始めたという背景に応じて、徐々に統括者やCTOの代わりとなるようなディレクション役が、多様な分野で出現していると感じます。これが今回のテーマにも関連するのではないかと思います。
次のテーマに進みましょう。
ディスカッション・テーマ③「どのような組織であればスタッフエンジニアはうまくワークしますか？」
三上氏：
まず、組織でエンジニアを評価する仕組みが存在することが基本です。特に「システムトラブルが起きていないことを評価できる体制」が重要で、それがスタッフエンジニアが活躍する場です。
一般に、スタッフエンジニアが必要とされる状況は、実は半年後や1年後に気付くものです。何も問題が発生していない、つまり品質管理がしっかりと行われている状態が理想です。この点で、弊社では「ハインリッヒの法則」を参考にしています。この法則によれば、一つの重大な事故が起きる背景には、29件の軽微な事故と300件の異常（ヒヤリハット）が存在するとされています。
我々はこのヒヤリハットをスプレッドシートで管理し、品質の優先度に基づいて分類しています。これにより、何がいつまでに対応すべきかが明確になるため、スタッフエンジニアの評価も容易になります。このような管理作業も、スタッフエンジニアの仕事に含まれると考えています。組織全体でこれがうまく機能すれば、可視化と定量化が可能になるので、より効率的に業務が進行すると考えています。
高松氏：
長い目で見たときに技術としっかり向き合う必要があると考えています。特に、スタートアップが非常に初期段階で、プロダクトマーケットフィット（PMF）を探してビジネスを模索している際は、スタッフエンジニア的な視点や規模での考慮はあまり必要ないと思います。
そういった初期段階では、早くリリースできるか、最低限の品質で継続してリリースできるかが重要です。アプリケーションが一定レベルの複雑さになったり、チームが拡大したり、長期間メンテナンスが必要になるような状況にならない限り、スタッフエンジニア的な考慮は特に不要です。
そういった前提をクリアした上で、どのように機能するかというと、それは組織化されているかどうかです。テックリードや、テックリード的な役割は自然と出てきます。更に、三上さんが現在行っているような仕事になると、この人が主に何に焦点を当てているのか、何を期待されているのかが、みんなに共有されている必要があると思います。
初期の成長フェーズを抜け、エンジニアの人数も増えてきた状況では、組織図を作成する必要性があると感じています。一人ひとりがどの部門に所属しているのか、どのような責任を持っているのかを明確にすることが重要です。
確かに、フラットな組織から少し階層を持つように変わる際には抵抗もあるでしょう。しかし、しっかりとした組織図があり、その中で各人の役割が明確にされている場合、全員がその状況を納得することができると思います。逆に、そのような明確な組織図や役割がないと、現場からの反発が起きやすく、うまく機能しない可能性が高いです。
私自身も現在は異なるポジションにいますが、スタッフエンジニアレベルのポジションに参加する際には、組織内での自分の位置や、他にどのような役割の人々がいるのかを事前に詳しく知るようにしています。
三上氏：
確かに、求人情報に「テックリード」と書くのは非常に難しいです。多くの場合、テックリードには高い技術力が求められるとされ、そのように記載されがちです。しかし、新しくその役割で採用した人がいきなり現場に参加すると、場合によっては現場が壊れるリスクも考えられます。
ですから、採用する際には何をその人に期待するのか、という点の調整が非常に重要だと思っています。
高松氏：
ある程度の規模になってそのアサインされるメンバーがまだ想定されてないとかの規模になると、また話は別なんですけど。
なるべく実際の日々の業務で、メンバーは何人で、こういうロールの人がいて、今ここが課題だと思ってます、みたいなのを選考の段階で話せると、役割や業務が想像しやすいと思います。
例えば、VPOEが欲しいですとか、テックリードが欲しいですってロールだけでは、判断できない可能性はあります。
三上氏：
いいテックリードを雇う時は、そういった課題を色々と質問してきてくれる方がいいですね。
役割や業務について深掘りしていって「こういう課題があるんですね、だったら私はこういうことができます」とかって言える人は、すぐワークするんだろうなって思います。
職務経歴書だけを見て採用すると、職務とスキルがマッチングしないトラブルになるようなことがでてきます。
佐藤氏：
ありがとうございます。リードの要件が過剰になっているケースはよくある話ですね。身に覚えがあります。次のテーマに参りましょう。
ディスカッション・テーマ④スタッフエンジニアとして組織やメンバーを動かすために意識していることは？
佐藤氏：
ここまで組織やメンバーに影響力を発揮するためのスタッフエンジニアとしての振る舞いについてお話がありましたが、具体的にこれまで意識してきた点をお二人から伺いたいと思います。高松さんからお願いします。
高松氏：
この話題は、スタッフエンジニアの役割の中でも特に重要だと感じています。テクニカルリーダーシップは、スタッフエンジニアとして繰り返し強調される点で、その重要性は非常に高いと考えています。
ただリーダーシップを発揮するためにはコミュニケーションスキルだけでなく、技術的な能力が非常に重要です。常に新しい情報をキャッチアップし、チームメンバーや他部署の人との対話でも技術的な洞察を提供できる状態を保つ必要があります。
また、経営層やビジネスサイドの人々に対しても、テクニカルな詳細は理解できないかもしれませんが、少なくとも「この人は技術的に詳しい」と認識される状態が必要だと感じています。そのためには、技術力を常に磨き続けることが必要だと思います。
最近、特にリーダーシップについてよく考えます。「リーダーはフォロワーが作る、マネジメントは権限が作る」という言葉があります。リーダーシップとは、新しい考えを促進するようなフォロワーをどう作るかが重要で、その方法には多くのバリエーションやスタイルが存在すると思います。
弊社には、シニアレベルのエンジニアが多く、各々が異なるスタイルでリーダーシップを発揮しています。一部はコードを勢いよく書くことで影響を与え、一部はドキュメンテーションが得意です。私自身がリーダーシップを発揮するポジションにつく場合には、コードを書く速度とコミュニケーション、そしてアジャイルの運用という面が特徴であると感じています。
最近は、自分がまだ十分に磨きをかけていないスタイル、例えば技術的に深く掘り下げる能力やドキュメンテーションスキルについて、改善が必要だと感じています。
結論としては、リーダーシップは非常に重要で、多様なスタイルで適用しなければならないと考えています。
三上氏：
私もフォロワーシップが重要だと考えています。単に「俺についてこい」というスタイルのリーダーシップはうまく機能しない場合が多いです。
説明責任も非常に大切だと思います。新しいアーキテクチャがメンテナンスしやすい理由を、チームメンバーに理解してもらわなければならないと思っています。テックリードとしての信頼獲得が最も重要です。
信頼を得る方法は大きく3つに分かれると考えています。
1つ目は、新しい技術を導入した際に説明会を開くことです。ただ聞くだけでは不十分なので、実際にハンズオンを行い、コードを触ってもらいます。
2つ目は、以前に紹介した「デザインドッグ」の方法を文書化し、他のメンバーがそれを作成できるようにすることです。これも信頼を得るために効果的です。
3つ目は、コードレビューの依頼が来たときにすぐに対応することです。1時間以内にフィードバックを返すことが重要です。エンジニアはレビュー結果を反映してすぐにリリースしたいと考えているので、その意志を尊重し、迅速なレビューと修正を行うことが大切です。
最近では、弊社のタイムスで、特定の問題に詰まっているというような記事を寄稿してくれる人がいます。そういった情報が明確で分かりやすいので、それが問題解決につながる一つの役割だと考えています。
そういった情報を発信することで、多くの人から相談が寄せられるようになります。信頼が増えると、自分が推進しているアーキテクチャやメンテナンス性に関する方針についても、チームが一致して取り組むようになります。
リーダーシップを発揮することで、自分が作りたいプロダクトの開発スピードが速くなるだけでなく、それが事業全体のスピード向上にも貢献すると考えています。全体として、良い影響が多いと感じています。
高松氏：
私自身が「リーダーとマネジメントは違う」と言っている手前で恐縮ですが、三上さんの話を聞いていると、やはりマネジメントの経験が役立っているケースが多いように感じます。例えば、困っている人を見つける能力や、迅速なレスポンスはマネジメントの習慣に起因する部分が多いと感じています。
リーダーシップを発揮する際にも、マネジメントの手法や経験が活かされる場面が多いと感じました。
三上氏：
マネージメントという肩書きがあると、何か特定のタスクを達成しなければならないというプレッシャーを感じることもあるでしょう。しかし、実際には「自分のコードをより効率よく開発したい」というような基本的な願望があります。例えば、不具合やバグがあると、すぐに価値のあるものを作りたいのに、テストコードが書きづらいとか、作業が非効率なところがある。
そういった問題を解決しようとすると、自然と他の人にも協力を仰ぐようになると思います。外から見ればそれが「マネージャー的な仕事」に見えるかもしれませんが、本質的には「働きづらい環境を改善したい」ということです。
高松氏：
テックリードを初めて担当した当初、マネージャーとテックリードの役割を極端に分けて考えていました。その結果、1on1のようなマネージメント活動を積極的には行わなかったのです。しかし今は、そのようなマネージメント活動も必要だと感じています。
三上氏：
モチベーションを高く保ち、開発を楽しむために行っていた活動が、後にテックリードやマネジメントといった役割に繋がりました。だから肩書きが後から付与される形になるんです。ドキュメンテーションを整理する能力や、他の人に事象を説明するスキルも重要です。このような説明力を高めることは、コードを書く能力以外の大切なスキルだと思います。
佐藤氏：
ありがとうございます。お二人とも、多様な経験からチーム内や組織内での自分の位置を理解しているようです。その経験から、信頼やフォロワーを得る自然な振る舞いに繋がっているのではないかと感じました。さて、次のテーマに移りましょう。
ディスカッション・テーマ⑤ずっと技術を極めてきたのに急に事業のことが考えられないのだけど…？
三上氏：
難しい質問ですね。前提として、事業を考えずにプロダクトを作ることはできません。
私の経験上、スタートアップやサービス開発の場で、事業を考慮しながらプロダクトを作ることが多かったです。しかし、客先に常駐しているエンジニアやSIerのような場所では、事業のことには直接関わらないかもしれません。それでも、サービス開発に関わる経験は有益だと思います。
一方、ミドルウェアの開発や特定のソフトウェアサービス提供会社では、事業のことを深く考える必要はないかもしれません。しかし、エンジニアが必要な理由は、最終的には事業を進めるためです。技術だけにフォーカスしていても、その価値を評価できなければ、事業としては進められません。したがって、事業のことも考慮するエンジニアが求められます。
自分が雇われている理由を理解すると、仕事の意義や方向性が明確になると思います。会社や働き方によって、この視点は変わるかもしれません。今、様々な働き方や環境があるので、自分に合った場所を見つけることが大切だと思います。
高松氏：
私もしばしばこのテーマに関する質問を受けることがあり、答えるのに悩んでいます。もし事業について全く考えられないなら、三上さんも言っていたように、ミドルウェアなどを扱うような業務に集中すればいいと思います。
しかし、それだけでない場合は、徐々に事業側のことも考えられるようになっていけばいいと思います。多くのエンジニアが経験するように、初めは自分のタスクにだけ集中していますが、徐々に他のチームや技術の全体像に興味を持つようになります。
事業についても、いきなり詳細な数値や経営の話をする必要はなく、徐々に視野を広げればいいと考えています。最初はプロダクトに集中し、次に事業、そして組織、経営と視野を広げていくのがいいでしょう。
現段階でプロダクトマネージャーから指示を受けている場合、その指示の背景にある「なぜ」を理解することから始めてもいいと思います。英
語で「相手の靴を履く」という表現がありますが、プロダクトマネージャーからビジネスディベロッパーまで、それぞれの立場から事業や経営について考えることで、全体像が見えてくるでしょう。
三上氏：
「相手の靴を履く」という考え方は非常に有用です。私がCTOに任命された当初、正確に何をするべきか理解していませんでした。
そこで、高い役職に就いている人たちが何を考え、どのように行動しているのかを理解するために、多くのビジネス書を読んで勉強しました。
現在では、エンジニアのマネージャーやテックリードに特化したキャリア向けの本も増えています。まずは、そのような本を読んで、その職種で求められる思考や行動が自分に合っているかどうか考えることが重要です。もし興味を持ったら、その道に進むべきかもしれません。
逆に、厳しそうだと感じたら、その考えは一旦忘れてもよいでしょう。
佐藤氏：
ありがとうございます。用意させていただいたディスカッションテーマは一応以上となります。
ここからは、質疑応答のところに入らせていただきたいと思います。
質疑応答
①「スタッフエンジニアとVPoT（VP of Technology）の違いは何ですか？」
高松氏：
実際、私が所属したことのある組織でVPoTと名乗る人はいませんでしたが、組織は多くの場合ピラミッド構造になっています。階層が増えると、下部には多くのメンバーがいる一方、上位にはより少ない数のポジションが存在します。
スタッフエンジニアの上にはさまざまな役職が考えられますが、特に大きな組織では、スタッフエンジニアたちを束ね、さらに経営層に近い役割を果たすポジションが必要になると思います。そのようなポジションにはVPoTという名前が付けられるのかもしれません。
VPoEも確かに存在しますが、エンジニアリングマネージャーはより経営に近い役職となります。そして、その上の役職として、さらに広範囲での影響力を持つポジションがVPoTとして設定されるのではないか、と私は考えています。
「スタッフエンジニア的な役割など、なかなか成果が見えにくいのかなと思う中で、成果の出し方、評価のされ方を伺いたいです」
三上氏：
信頼の獲得が評価において重要になります。また、評価されるためには説明責任が大事です。一番詳しい人が自分である場合、その価値を明確に説明し、信頼関係を築くことが必要です。
事業への直接的な貢献も評価されます。特に、そのエンジニアが専門の領域で誰よりも詳しい場合、事業への貢献やKPIの達成率などで定性評価がなされます。できれば数値で示すのが一番です。
成果が数値で示せた場合や新しいサービスの展開が可能になった場合、それがさらなるプロジェクトや責任領域の拡大に繋がることもあります。
これによって「もし私がいなければ、これはできなかった」という状況が明確になるので、その点もしっかりと説明するべきです。
「技術的な判断をする際の基準や考え方を教えてください」
高松氏：
例えば、新しい技術を導入したいというエンジニアがいた場合、最初にその提案がどれぐらいのインパクトを持ち、後から変更が難しいか否かを判定すると思います。テスティングツールなどがその例で、プロダクションコードに直接影響を与えない場合は、比較的アグレッシブに試して、必要なくなったら除去する、というような判断が可能です。
三上さんが挙げた、複数のORM（Object-Relational Mapping）を一つに揃えるようなケースは、非常にシビアな判断が必要だと感じています。
判断基準としては多くの観点がありますが、まずは技術的な妥当性や、その技術がどれぐらいメンテナンスされているか、といった基本的な要素を確認します。
そして最後に重要なのはコミュニケーションです。選定対象の技術のPros/Consを整理し、、必要なドキュメントやコードを揃え、最終的にはコミュニケーションを通じて合意を取っていくプロセスが、特に大変だと感じています。
実際に一番時間を使うのは、どのようにしてみんなが納得する方向に持っていくか、という部分だと思います。
三上氏：
先ほど話したように、私は3つのORMの中から一つを選択した経験があります。選択の基準として、データベースのスキーマからGoのコードを生成できるものが良かったので、それを基準にしました。しかし、オープンソースを選ぶ際には、コードが継続的にメンテナンスされているかどうかが重要です。GitHubのスター数やコミットのログなどを参考にします。
ただ、スターが100を超えているようなものを比較する際には、ドキュメントの量やコミュニティの活発さが大切です。さらに、その技術を使える人材がどれくらいいるのか、というのも採用の大きな要素となります。技術的な難易度が高いものは、メンテナンスや再現性にコストがかかるため、技術トレンドは常にチェックする必要があります。
一方、我々の会社では、Angularを採用しています。Angularのエンジニアを育成し、コミュニティ内でリーダーシップを取る活動やイベントを積極的に行っています。これにより、限られたAngularのスキルを持つ人材を集め、コミュニティの力を強化しているという戦略も取っています。
「スタッフエンジニアをチームメンバーに任免する場合、どんな性格のエンジニアが向いていると思いますか」
高松氏：
自分が熱中したい作業の範囲を超えて、知的好奇心や少しのおせっかいさを持っている人は、キャラクター的にエンジニアリングのリーダーシップに向いていると思います。
このような人は、緊急の状況下では「手を動かせ」と言われることもあるかもしれません。しかし、根本的には「これをなぜやるのか」という疑問を持ち続け、その疑問に基づいて行動する人は、おそらくエンジニアとして広い影響力を持つことができるでしょう。
三上氏：
プロフェッショナルとしての意識が大事ですね。基礎知識、例えばアーキテクチャやデザインパターンなど、広範なベストプラクティスに精通している人は信頼できます。そういった知識が豊富な人は、どの手法がいつ適用できるのかを理解しているので、非常に頼りになります。
また、弊社で大事にしているのは「ギブファースト」の精神です。先に何かをする、人助けが好きな人が良いと考えています。テイクファーストではなく、積極的に他人のために行動することで信頼が積み重なっていくという性格の人が適しています。高松さんも指摘していましたが、お節介な性格の人が向いていると思います。
コミュニケーションも重要です。人の話に積極的に参加し、意見を交換する環境があると、技術的にも切磋琢磨できます。そのような性格を持つ人がリーダーシップに適していると感じます。
「スタッフエンジニアのような存在が組織が必要と感じつつ、それを任せたいと思う人がいない場合、どのようなアプローチを取るべきでしょうか？」
三上氏：
カルチャー作りが非常に重要だと考えています。この点は、単に誰かを採用する以上に、組織内でスタッフエンジニアを活用できるような土壌、つまりカルチャーをCTOが先頭で築く必要があります。そのような環境がない場合、適切な人材が生まれず、環境を改善することが最優先です。
そのため、カルチャーにフィットする人材を採用することが非常に重要です。
高松氏：
私も、採用でスタッフエンジニアレベルの人材を求める場合、外部から連れてくるのが一番だと考えています。ただ、現状ではそのような人材はなかなかいないでしょう。そのため、外部からの採用は困難で、成功する確率は低いと思います。社内で育成する選択肢もありますが、それもまた容易ではありません。したがって、時間をかけて、納得いくスタッフエンジニア候補を採用するしかないと考えています。
三上氏：
信頼が非常に重要で、それを築くためには1on1でしっかりと話をすること、そして期待値を明確に伝えることが大切です。
このプロセスにはコーチングのスキルが求められます。相手が望む行動を取るように、質問を通じて本人の意思を引き出すアプローチが必要です。そのため、コーチングの手法を用いて、その人がしっかりとリーダーシップを執れるように努力することが、良いアプローチだと考えます。
「会社はエンジニア以外の方もいらっしゃると思いますが、エンジニア専用の評価制度はありますか？」
高松氏：
弊社では、エンジニア専用の評価制度というわけではありません。半年ごとの相互評価の仕組みが運用されていますが、大企業のようなフォーマルな評価制度が存在しているわけではありません。さらに、前にも触れたように、社員の約半数がソフトウェアエンジニアです。そのため、役割の定義を厳格に設定するよりも、各自が自分のマネージャーと話し合い、納得のいく形で仕事を進めているケースが多いです。
具体的な役割が定義されているわけではなく、むしろ柔軟な形で成り立っている印象を持っています。
佐藤氏：
本日はここまでになります。お二方とも、ありがとうございました。
