佐藤氏の自己紹介
佐藤正大氏（以下、佐藤）：株式会社ビットキーの佐藤正大と申します。マネージャーとして、ID管理や認証認可を提供するプラットフォーム （bitkey platform）の機能開発や運用を担うチームと、エンジニア組織の横断的な課題解決を行う「VPoE Office」というチームを担当しています。Twitterでもいろいろ発信しているので、もしよければ見てください。
自分のことですが、10月に開催されたアジャイルのイベントである「XP祭り」で登壇した資料、KPT（Keep・Problem・Try）について書いているんですが、盛況だったのでもしよければ見てみてください。
今日お話ししたい対象者の方は、エンジニアリングマネージャー（EM）になりたい人、なりたての人、なったけど悩んでいる人、そもそも関係性に悩んでいる人。あとは「エンジニアリングマネージャーってやるべきことが多くないかな？」と思っている人とか、あとは「ロールが世の中そもそもたくさんあって、ぶっちゃけよくわからんよ」という人を対象にしたいなと思っています。
（スライドを示して）こちらは僕のキャリアで、「こう呼ばれた気がする」という名前をあげています。現在4社目で、その過程でプログラマーとしてやっていた時もあるし、いろいろ（なふうに）呼ばれてきたなと思っています。
こういった経験から、どんなロールを自分が今担っているのかとか、どんなキャリアパスを歩めばいいのかと悩んでいる方に、少しでもヒントになればと思っています。
本セッションにおける、ベースとなるアプローチ
（セッションの）タイトルが「エンジニアリングマネージャーの役割とは何か、テックリード（TL）やインディビジュアルコントリビューター（IC）の役割と合わせての考察」として発表していきます。
まずベースとなるアプローチですが、「あるものがなにであるかを考える場合には、それがなにでないかを考えると多くの示唆が生まれるかもしれない」。ちょっと名言っぽいですが、僕の持論です。つまり、「なにであるか」ということを考えるのと同時に、「なにでないのか」ということを考えると良いかなと思っています。
また、ガイドとなるアプローチとしては、『Googleのソフトウェアエンジニアリング』という本を参照したいと思っています。Googleのさまざまなベストプラクティスを、文化、プロセス、ツールの側面から紹介している本で、非常に良いのでとてもおすすめしています。
特に第5章に「チームリーダー入門」という章があって、その中に「リーダーシップの役割は2つあるよ」と。リーダーシップの役職と言ってもいいですが、2つある。エンジニアリングマネージャーと、テックリードというものを明示的に置いていると。
それら以外、リーダーシップの役割以外はインディビジュアルコントリビューターと呼んでいて、部下を持たずに個人としてチームに貢献する社員のことを（このように）呼んでいます。
これ以降、この本のことは「フラミンゴ先生」と呼んでいこうかと思っています。これ以降、書籍の引用をたくさんしていきます。「Googleが言っているから正しい」ということではなくて、アプローチとして有用かなと思っているので紹介していきます。もし熟読された方がいれば、僕の考察のところだけ耳を傾けてもらえたら幸いです。
基本パターン〜二人三脚でいこう〜
（スライドを示して）アウトラインとしてはこの3つ、基本パターンと応用パターンとまとめという流れで紹介します。
まず基本から。この本の原則を超要約すると、「1人じゃ大変だ」ということが書いてあります。特に「テックリードとエンジニアリングマネージャーは、二人三脚で歩もう」ということが書いてあります。
テックリードの役割を引用すると、「製品の技術的な側面を担当し、技術的な決定と選択、アーキテクチャー、優先度、開発速度、プロジェクト管理一般を含む、インディビジュアルコントリビューターが自分たちのスキルセットやスキルレベルに最も見合ったタスクに取り掛かれるよう保証するのがテックリードの役割だ」と言っています。
一方で、エンジニアリングマネージャーの役割とは何か。「チームが担当する製品が、ビジネス要件を満たすことを保証しつつ、その上でテックリードを含むチーム内のすべての人員の成績、生産性、満足度に責任を持つ、これがEMである」と定義されています。
ここでいう二人三脚の部分。これは本当に“二人三脚”という表現で書かれているんですが、補足の説明がこうなっています。
「1組のリーダー、つまり1人のテックリードと、エンジニアリングマネージャーがパートナーとして連携して仕事をする。その理屈は、完全に燃え尽きることなく両方の業務を同時にうまくこなすのは本当に難しいので、2人のスペシャリストが専任で各々の役割を攻略していくほうがよい」だそうです。
「本当に難しい」ということが書いてあるので、ぜひ読んでみてください。
ちなみに「エンジニアリングマネージャーは、さらに難しい」ということが書いてあります。
（スライドを示して）これが先ほど紹介したエンジニアリングマネージャーの役割ですが、この文章の後にこう続いていました。「ビジネス要件と個々のチームメンバーの要求とは必ずしも相容れない。そのため、このことがマネージャーを難しい立場に置く可能性がある場合が多いよ」と。
今日はエンジニアリングマネージャーの方々が多く集まっているので、「あぁ、わかるな」という心境ではないかなと思っています。
ここまで簡単にまとめると、「エンジニアリングマネージャーとテックリードは二人三脚で歩むべし」と言っています。テックリードは製品の技術的側面を担当します。エンジニアリングマネージャーは、テックリードも含んだピープルの側面と、製品がビジネス要件を満たすことに責任を持ちます。
僕からの提案、考察として、こう考えるといいんじゃないかなと思っています。それは、「エンジニアリングマネージャーの仕事は、テックリードがやらないすべてである」と。
つまり、2つあると考えるよりも、テックリードが考えていないことを全部やるのがいいんじゃないかなと思っています。いわゆる包含の論理の関係でいうと、テックリードがAに対して、Aバー全部をエンジニアリングマネージャーが担う。
より具体的に、なぜ僕がこう考えるといいと提案しているのかというと、技術的な側面を担うテックリードの役割のほうが、エンジニアリングマネージャーの仕事よりも理解しやすいんじゃないかなと僕は思っています。
特にみなさんにエンジニア経験があるのであれば、テックリードの仕事、アーキテクチャー、優先度とか開発速度、プロジェクト管理一般は、大変なものの大変さも理解できるし、その責任も理解できると思います。
むしろテックリードの仕事の困難さを理解しているからこそ、テックリードが「こういう状況になっていてほしい」「こういうサポートをしてほしい」ということを、すでにみなさんは知っているのではないかなと思っています。
だからこそ、（エンジニアリングマネージャーの仕事を）「テックリードがテックリードの業務に集中するためのすべてを行う」と自己定義をしてみるといいのではないでしょうか。
さらに、この二人三脚の原則があるとすれば、大きくテックリードに頼って、任せてもいいと僕は思います。つまり、“テックリード”とはテクノロジーのテックなので、「テクノロジーの力こそがプロダクトの価値を生む源泉」と考えると、彼（テックリード）の生産性が最大化されることが、一番大事なんじゃないかなと僕は思っています。
なので、テックリードが願う状況を、もしかしたらあなたはすでに知っているかもしれないと。それを二人三脚で進めることを、僕は考察として加えています。
応用パターン〜小さいチーム、大きいチーム〜
次に応用パターンを紹介します。二人三脚の原則があるとすると、応用パターンが2つあると読み解くことができます。
1つが、テックリードマネージャーというパターンがあるそうです。「初期段階にある小規模のチームの場合、テックリードマネージャーとして両方の役割を担うのが良い」と書いてあります。これはシニアのエンジニアが必ずしもなるものではなく、最近までインディビジュアルコントリビューターだった者がなることも書いてあります。
もう1つが、「ピープルマネージャーとシニアなテックリードを置きなさい」というパターンがあります。「より大きなチームの場合にこのパターンを取りなさい」と書いてあります。
テックリードマネージャーのパターンは、両方やらなければいけないので非常に難しいです。Googleの本、フラミンゴ先生が提唱しているのは、研修を受けることに加えて、定期的なアドバイスをしてくれる、シニアなメンターを探し出しなさいと書いてあります。
つまり、メンタリングを受けたり、そもそもメンターを探す。つまりこれは、チームの外部に積極的に頼るのが良いと読み解くことができます。
もしみなさんが大きな会社にいるのであれば、きっと社員紹介記事とかインタビュー記事があるはずですので、ほかの部署の方でも助けを求めるのがいいんじゃないかなと思います。
スタートアップの場合であったとしても、同じ悩みとか同じ境遇の人、まさに今日この場のようなミートアップもあるし、カジュアル面談などで積極的に機会を作っていくのがいいんじゃないかなと思います。
ここでもう1個本を紹介すると、『エンジニアのためのマネジメントキャリアパス』という本があります。これも非常に良い本です。この中で「CTOだとしてもコーチを持ちなさい」と書いてあります。そして、「社外で助け合える仲間のネットワークを持っていますか？」と問い掛けています。
CTOに限らずいろいろなキャリアラダーを説明している本ですが、メンターの重要性を繰り返し書いています。これもおすすめです。
2つ目、ピープルマネージャーとシニアなテックリードのパターン。より大きなチームのパターンです。これをよく読んでみると、大きなチームの人数の定義とかは特にされていないんですね。
また別のページを見ると、「比較的大きなチームでは、テックリードのプロジェクト管理を補佐するプログラムマネージャーもいるかもしれない」と書いてあって、（読んだ方は）きっと「結局どういうことやねん」と思うんですね。
ここでいう、「チームにおける大きい・小さいとは何か？」とは、もしかしたらGoogle社内に行けば基準があるのかもしれませんが、あえて記載されていないのは、むしろこれこそ「マネージャーの才覚で選択してチームを編成しなさい」と言っている気がしています。
こちら（について）も、別の先生を呼んでみると『チームトポロジー』という本があります。これも非常にすばらしい本だなと思います。この中に、“ダンバー数”というキーワードが出てきます。
これは認知限界の理論を紹介しているものです。この5人、15人、50人、150人という枠が、人々がほかの人を理解できる限界の人数であると書いてあります。
僕からの考察としては、自分から見て、誰が5人（の中）に入っているのか、15人（の中）に入っているのか。誰に該当するのかを考えるのが1個ヒントになるんじゃないかなと思います。
逆に、メンバーに対してロールスイッチをして、今ワーキングメモリーを保持できる限界を超えていないかとか、そういうことを考えるヒントにもなるかもしれません。
テックリードとエンジニアリングマネージャーの役割の考察まとめ
考察を最後にまとめたいと思います。二人三脚でいきましょう。テックリードとエンジニアリングマネージャー。
こちらは僕の提案ですが、テックリードの仕事を捉えた後に、エンジニアリングマネージャーがそれを補完するというのがわかりやすいかもしれません。それは、テックリードが願う状況を、あなたはすでに知っている可能性が高いからです。
そして、エンジニアリングマネージャーは相容れない2つの課題に向き合うのですが、これはみんなでがんばるということですね。
そして応用パターンとしては、テックリードマネージャーという、さらに難しい立場もあり得ると。これ（の場合）は、ぜひメンターを探してください。社内でも社外でも、どんな役割だとしても。上司である必要はまったくなくて、（社）外とか、（社）中の斜め上を探すのがいいと思います。
あと、大規模だったらロールは増えるということが書いてあります。その時には、ダンバー数という考え方がおすすめです。どこまでが自分が認知できている人々なのか、そしてメンバーにロールスイッチして、どこまで考えられているのかと考察すると良いかもしれません。
終わりに。今日はビットキーのことをなにもしゃべっていません。すみません、引用と考察、私見ばかりの発表で。
Qiitaさんのプラットフォームの「Qiita Jobs」、「Devトーク」というところに（ビットキーのページを）オープンさせてもらっているので、ビットキーのことをちょっとでも知りたいよという方は、立場にかかわらず、こちらから応募してくださいというところで、僕の発表を終わりたいと思います。
ご清聴ありがとうございました。
