あらたま氏の自己紹介
あらたま氏：こんにちは、よろしくお願いします。（スライドを示して）こんな感じのタイトルでしゃべっていきたいと思います。
まずは「お前、誰よ？」というところで自己紹介します。あらたまといいます。LayerXという会社でEM（エンジニアリングマネージャー）をやっている者です。これまでバックエンド中心のキャリアをずっとやってきたのですが、前職では執行役員CTOをやったりして、2023年に転職してLayerXに入りました。
ちなみに、11時の松本（松本勇気氏）のセッション聞いたよという方……。（会場を見渡して）ありがとうございます。いい話でしたね、はい（笑）。
あとは、「YAPC」とも縁の深い人生を送ってきています。YAPCがきっかけでディー・エヌ・エーに就職したというところから始まり、2016年から「YAPC::Japan」という、ローカルを転々としている（イベント）……。今回もそうですが、これの立ち上げメンバーをやったりしています。
あと、2023年の「YAPC::Kyoto」でベストスピーカー賞をいただきました。ありがとうございました。あれは、いただけると本当にめちゃくちゃうれしいので、ぜひ投票してください。私の回じゃなくていいので、ぜひ投票してください。
私が関わっている事業です。法人支出管理という領域の事業を展開している、「バクラク」というシリーズをやっています。
会社の話は先ほど松本がしたのですっ飛ばして、事業の話もすっ飛ばして、今日は、本題をメインにいこうかなと思います。
「君、来月からEMね！」 さてどうする？
（スライドを示して）EMの一歩目、Day 1みたいなところを話していこうと思っています。みなさんいろいろなフェーズ、「メンバーやっています」とか、EM始めたての方もいるかもしれないし、CTOの方も何人か見える感じなので（笑）。みなさんに合った使い方をしていただけるような、旅のしおり的な立ち位置のトークにしようかなと思って来ています。
時間の関係上、「そもそもEMってなんで必要なんですっけ？」みたいなところ、私が実際に実践して爆死した話とか、そういうのは盛り込みきれなかったので。資料にいっぱいリンクがつけてあって、後で公開するので、よかったらそちらも併せてご覧ください。
（スライドを示して）私が出したプロポーザルから抜き出して持ってきたのですが、「あなたにEMを任せたいです」とCTOの方が言ってきています。きっとCTOにはなにか光るものが見えたんでしょうね。あなた自身も、マネージャーと言われて、「まんざらでもないぞ」「なんとなく興味があるぞ」という（状態になっている）前提です。
EMになって変わる3つのこと
何を準備したらいいのかということの手前で、何が変わって何が変わらないのかみたいなところから話をしていけたらなと思います。
EMになって変わること、変わったことを、「どういうのがあったかな」と自身を振り返ってみていたのですが、大きく分けてこの3つがあるかなと思います。
仕事の捉え方や、それをどう評価するのかというところ。あとは業務範囲の部分と、仕事の進め方の3つですね。
「全部じゃん」っていう、「なにもかもが変わるぞ」というところではあります（笑）。
（スライドを示して）これは最後のまとめのスライドから持ってきました。後でも触れますが、とにかくなにもかもが変わるぞ、と。かといって、これまでの経験がまったく活きないとか、全部捨てて生まれ変わってくださいとか、そういう話ではありません。異世界転生じゃないですが、さらにブラッシュアップさせたような感覚を私は持っています。
なので、めちゃめちゃ違和感があったかというとそうでもなかったというのが正直なところです。この3つについて一つひとつ見ていければと思います。
仕事の捉え方・評価軸の変化
まずは仕事の捉え方・評価軸の変化ですね。『HIGH OUTPUT MANAGEMENT（ハイアウトプット マネジメント）人を育て、成果を最大にするマネジメント』っていう本があるのですが、そこから取ってきました。マネージャーのアウトプットは、自分の組織のアウトプットと、お隣さんのアウトプットの総量で評価されるという話が書いてあるんですね。
なぜかというと、ビジネスにしても教育にしても、さらには外科学にしても、と例では書いていたのですが、仕事はチームでやるものだからです。
会社はただの箱でしかないので、みんなの力を十二分に引き出せて、初めて成果を出せる生き物になることができるんですよね。
メンバーとしてやっていると、自分が上げた成果と、自分が上げた成果がチームにどれだけ影響を与えられたかというところで成果が測られることが多かったかなと思います。
マネージャーになると、主語の部分が「自分」から「チーム」になるんですね。（そうすると）どうなるかというと、これまでチームメンバー同士で行っていたやり取りが、そのチーム同士のインタラクションに変わっていきます。
（スライドを示して）この図はScrum@Scaleという大規模スクラムのプラクティスから取ってきた図なんですが、フラクタルの構造になっているんですね。左から右に行くほど関わる人が増えていきます。
大変になるんですが、基本の形は変わらないよねという図になっていて、マネジメントもこういう性質があるかなと私は思っています。
業務範囲の変化
次に業務範囲の変化ですね。（スライドを示して）これもまた有名どころから取ってきましたが、広木さん（広木大地氏）の「エンジニアリングマネージャ／プロダクトマネージャのための知識体系と読書ガイド」から図を拝借しています。プロダクト開発におけるマネジメント業務ですね。これを4つに分割すると、こういう組み合わせになるんじゃないかという図です。
このうち、テクノロジーマネジメントとプロジェクトマネジメントというものについては、メンバーレイヤーの頃から兼務することもあったり、求められたりすることもあるかなと思います。この4つの円のうち、テクノロジーマネジメントとピープルマネジメントのところに特化した領域をやるプロダクトマネージャーも存在します。
これを、タイミー（株式会社タイミー）の基裕さん（石井基裕氏）というEMの方が、“深いEM”と名付けていたのですが、この名付けはいいなと思っています。
対義語は“広い”になるのですが、EMがエンジニア出身であることを活かして、Howの部分の底上げを、技術面と人の面の両面から行っていくというイメージを持っています。アプローチや目的がちょっと違うのですが、個人的にはスクラムマスターの役割もわりと似たところがあるかなと思っています。
対して“広いEM”ですね。全部のマネジメント領域を、フェーズに合わせて濃淡をつけて、チームの成果を最大化していきましょうというアプローチです。個人的にはこっちのアプローチのほうが好みで、LayerXでもわりとこういうスタイルのEMが多いです。
ですが、これはチームメンバーの数が増えれば増えるほど、ピープルマネジメントの負荷が集中していって、どんどんそっちが濃くなってしまうんですよ。
それは大変なので、LayerXではチームのサイズを小さく保つ……。大きなチームもあるのですが、基本的には5人ぐらいのチームに留めてメンバーの数を抑えることで、ピープルマネジメントの負荷を下げるという取り組みをしていたりします。
プロダクトマネジメントも入ってくるのですが、「じゃあ、プロダクトマネージャーになりなさいってことなの？」というとそれは違って、プロダクトマネージャーと協力して、彼らの視点をインストールしながら、コラボレーションしながらいいものを作っていきましょう」「チームを方向付けしていきましょう」という話かなと思っています。
（スライドを示して）EMに何が求められるかは、各社で定義もさまざまだと思います。、私もEMとは何なのかというテーマでミートアップを開催したりしたのですが、つまるところ、そのプロダクト開発において必要とされるマネジメント的なものを満たすための役割の組み合わせでしかないと思っています。
先ほどの説明を受けて、「“広いEM”って大変そうだな」「それってスーパーマンにならないといけないことなんだっけ？」みたいに思われた方もいるかもしれません。しかし、そうではなくて、それはマネージャーだけが満たす必要があるわけではなくて、メンバーも含めて、みんなで必要なだけ満たせていればよいという話だと思っています。
ですが、目的としてマネージャーが背負っているものは「チームで成果を上げましょうね」というところなので、なにか満たされていない領域があって、それが成果の妨げになっているのであれば、あらゆる手段でそれを満たす必要があります。
例えば「開発の頭数が足りません、ぜんぜんフィーチャーが実装されません」という状態で、人が足りないというペインがあって、そこに対して、「よっしゃ、俺も開発するぜ」と言って開発をするのは、ある種正しいと思うんですよ。
しかしそれをずっとやっていると、例えば採用が止まってしまいます。採用が止まっちゃうと人が増えなくて、「困った。人が増えない。フィーチャーがぜんぜん実装されない。またループになる」ということになってしまいます。
なので、短期的にはいったん手出しするのを止めて、採用とか、例えば異動の算段をほかのチームの人と協力して取りつけてくるとか、そういうアプローチが必要になるかもしれないです。なので、そういった視点を養うのが大事だなと思います。
自分で観察して、決めて、動かすという、このサイクルを回すのが大事なのですが、めちゃめちゃ大変なんですよ。「えっ、それ、僕が決めていいんですか？」みたいな。最初のうちはすごく怖いと思うのですが、やっているうちに慣れるので大丈夫です。
もちろん周りを頼るのもすごく大事なことですが、最終的に決めるのは自分だという気持ちを持って臨むのが大事なんじゃないかなと思っています。
仕事のサイクル、やり方の変化
（スライドを示して）3つ目ですね。仕事のサイクル、やり方の変化みたいなところです。評価制度がきちんと整っている会社さんだと、人事の方から、「そろそろ期末だから、振り返り、ここに書いてね」「『SmartHR』に書いてね」「目標立てようね」みたいな、そういうアナウンスがあると思っています。目標を立てるのが苦手な人？ （会場を見渡して）ありがとうございます、私もです（笑）。
まあまあ大変じゃないですか。「なんでこんな大変なものやらせるんだ」といつも思いながら、みなさんやっていると思います。これには、受動的にやるんじゃなくて、ぜひ能動的に仕掛けるほうに回っていきましょうということを言いたいなと思っています。その差分が、メンバーでいることとマネージャーになることの、わりと大きな差分だなと思っています。
これをメンバーの頃から意識できるとけっこういいなと思っています。なぜかというと、なくてもいいんですが、自分の「こうしたい」「こうなりたい」とか、「こういう仕事を楽しいと思うな」とか「こういう仕事は苦手だな」という自分の認識と、会社から自分に対して「あなたにはこういう役割を期待しています」みたいなところや会社自体が「こうしたい」「こうなりたい」というところの、お互いの期待をすり合わせていくのにとてもいいツールだと思っています。
なので、例えば、「今十分な給料をもらっていて、これ以上別に成長しなくてもいいです」と思っていたとしても、イベントをスルーせずに、自分を知る、会社を知る機会にしてもらえると、より仕事がおもしろくなっていくんじゃないかなと思っています。
「能動的にマネジメントサイクルを回すってどういうことなの？」みたいなところも見ていければと思います。サイクルを回すことの最小単位は、メンバーにフィードバックして、そのフィードバックからメンバーの反応を受けて、自分もフィードバックを受けてという、フィードバックのループを回すことだと思っています。
これを半期とかそういう長い単位じゃなくて、日々の細かい単位で短く短く回していくといいですよということです。（スライドを示して）右下に書いてあるのですが、『急成長を導くマネージャーの型 〜地位・権力が通用しない時代の“イーブン”なマネジメント』という本があって。これは私がめちゃめちゃ影響を受けている本です。
下の斜体のところは引用してきた部分ですが、メンバーが上げた成果は、期末のタイミングでも成果は残るのでわりと集めやすいのですが、能力やバリュー、成果を上げる手前で発揮された事柄は、そのタイミングで集めていかないと流れていっちゃうんですよね。
ふだんの行動に根差したものなので、きちんと見ておかないと、事実をもとにフィードバックすることができなくなってしまいます。
逆説的ではあるのですが、成果はそういう日々の行動の積み重ねによって生み出されるものなので、そこにより着目してフィードバックしていくことが大事なんじゃないかなと思っています。
観察して、細かい単位で見立てを立てて、フィードバックして、そこからの反応を得て、フィードバックとしてもらってというループを回していくことが大事です。
（次回につづく）
