――続いてのご質問です。
ピープルマネジメントと呼ばれる業務（1on1や目標管理など）は誰がどのように設計していますか？特徴的な取り組みがあればお聞きしたいです。
konifar氏：ピープルマネジメントをやろうという気持ちでやっていないかもしれないですね。よく言われる1on1はメンバーのためで傾聴が大事、みたいなものにあまりしっくりきていなくて。1on1では、とにかく分からないことが多いので、現状を教えてくださいと言って聞くようにしています。もちろんその過程でメンバーの思考整理にもなりますし、自分もちゃんと現状を把握できるというのはありますが、教育みたいなのは考えてできていないですね。
ただ一つ特徴的なことでいうと、憧れている人はいますか？というのはたまに聞くようにしたりします。それは、例えば3年後にどうなりたいですか？と聞いてもすぐに答えられる方ばかりではないので、この質問をすることで、その人が目指したいところや何を美しいと思っているのかなどが見えてきやすいなと思っています。
あらたま氏：いい質問ですね。
――あらたまさんはいかがでしょうか？
あらたま氏：前職と現職の話がありますが、先に前職のお話をします。前職では自分が0から制度を作っていました。こちらについてはnoteにもまとめているので、ぜひ見てみてください。
https://note.com/ar_tama/n/n52979b3c0ef3
今日は掻い摘んでお話しします。社員として雇用されている以上は、自分たちの成長をそのまま組織や事業の成長に還元させるプロセスが必要で、もっと言えばその成長に対して会社はお金を払っていると理解をしています。
もちろんその人の元々のスキルはあるかと思いますが、その上澄みの部分をどれだけ溢れさせるかで次の期のお給料が決まると考えています。この正のサイクルを一緒に回していく相手として会社と自分を捉えられると、成長というものをすごく自然に組み込んでいけるのではないでしょうか。
例えば、業務委託であればスキルの切り売りだと理解しているので、そこまで期待をかけることはありません。しかし社員の場合はこの成長に対して会社が責任を持っているという違いがあります。
なので、本人がありたい姿をあぶり出すお手伝いと、会社が成長していくために、あなたにはこういう成長曲線を描いてほしい。そのためにはこういう打席が用意できると思うから、ここで挑戦してくださいと期待をお伝えし、それを週次で話しながら一緒に軌道修正していく、みたいなことをピープルマネジメントにおいてはやっていました。
現職においては、すでに仕組みが出来上がっている中に参入したという形ですが、スタンスとしては前職時と変わらないと思っています。
今は、OKRを使っていますが、目標立てはどうしても積み上げがちになるため、今の自分が何もしなくてもこのくらいいくかなというところから、更にキャップを外してあげるような装置としてOKRを使っているという感じですね。
konifar氏：現職では、1on1の頻度や目標管理のフォーマットの設計を誰がどのように行っているのでしょうか？
あらたま氏：この辺りは事業部のVPoEである小賀さんが、実施していますね。
konifar氏：横断的に、エンジニアだけでなく人事と異なる領域だと思いますが、人事とはどのように関わってやっているのでしょうか。
あらたま氏：Engineering Officeという、技術組織におけるイネーブリングの役割を持つチームがいて、そこが内部・外部関係なく連携の部分を担ってもらっています。あとは、HRの部署の中にHR企画のような部署があり、そことEngineering Officeが連携して、成長支援の仕組みを部署ごとに決めていると聞いています。
konifar氏：ありがとうございます。
質問をみていると、EMがどこまで責務としてやるべきなのかという話にも見えていて、1on1をやるかやらないか、や目標管理をやるかやらないかは、本当に組織によるなと思います。kyashの場合では、目標管理はトップダウンでマネージャーがやりましょうと決めています。1on1の頻度に関しては少なくとも月1と人事が決めているものがありますが、毎週にするか隔週にするかなどはマネージャーに委ねられているという状況です。自分はマネージャーに対して、少なくとも隔週ではやって欲しいという話は伝えています。
あらたま氏：私も、sprintと同じサイクルで実施できるといいんじゃないかという肌感はありますね。月1だと少しスパンが長く、その間にいろんな浮き沈みがありタイムリーに拾えないというリスクとのトレードオフかなと思います。
――ピープルマネジメントにおいてどちらかというと実行責任を追うというところなのでしょうか。
あらたま氏：そうですね、ただどのような設計意図の元で行われているのかを自分なりに理解することは大切かなと思います。
――ありがとうございます。では次の質問です。
「上司から経営視点を持って欲しいと言われることがあります。全社最適・長期目線のことかなと思っていますが、組織やタイミングなどで違うと思います。皆さんはEMに経営視点・経営者目線を求めているのか、経営をしたことがない一般的なEMはどのようにキャッチアップすればいいのか教えていただきたいです。」とのことですがいかがでしょうか。
konifar氏：経営者と同じような振る舞いをして欲しいということとは少し違いますよね。目線ということは理解した上で物事を考えて欲しいという意味だと思いますが、何か責務を持ったり、それ相応のロールを持って動きまで変えて欲しいということではなく、少なくとも理解をして提案して欲しいという意図が含まれているのかなと思います。
あらたま氏：質問にまっすぐ答えると、どのような振る舞いをみて上司が言っているのかが擦り合っていないと、明後日の方向に飛んでいきそうで危ないなという気がしました。なので、具体的な自分の言動や立てる目標であったり、何を持って目線が低いと感じているのか、求める高さまでどのようにギャップを埋めるべきかということを話していただくのがいいかなと思います。
konifar氏：そうですね。思い返してみると、私もCEOから同じような話をされたことがあり、その時は何のことを言っているのかが分からないなと思っていました。その時に、これは経営者目線だと思う記事やPodcastをまとめて持ってきてくださいと話をしたことがあります。抽象的な話になってしまいがちなので、具体的な話を元に、ちょっとずつ擦り合わせていったみたいなことはありますね。
あらたま氏：とても良いですね。
konifar氏：全社最適やEMとしての経営者目線については、具体的に何を意味しているのかをすり合わせることが重要だと思いますね。
あらたま氏：このご質問から読み取れることでもう一つ付け加えると、マネージャーの仕事は自分のチームのパフォーマンスをあげるだけでは不十分で、隣のチームにも影響を及ぼすことが求められると思っています。
隣のチームが何をしていて、何を目標にしていて、何を課題に捉えているのか、をある程度理解しておく必要があるかなと思っています。
konifar氏：経営がどういう状態かというのは理解した上で、それを解決するような動きをEMが目指さなくてもいいと思います。それよりも、経営や取締役から降りてきた目標の背景を理解した上で、戦略を立てる方にフォーカスした方がいいのではないでしょうか。
というのも自分でもありがちなのが、全部を理解すると手数が増える一方で、頑張ってキャッチアップしているとなんとかしなきゃと思うようになり自分自身がしんどくなっていきます。これは他の方からも聞いたことがあることなので、経営者目線は持ちつつも全部自分がやろうとしなくてもいいというのはスタンスとして大事かなと思いました。
――「EMとして転職する場合、コードベースの知見や経験の差から、チームと適切な関係を作り上げることに難しさを感じるケースがあるように思います。チームとの関係性を作るために留意してるポイントなどありますでしょうか。」
konifar氏：当社でもEMを絶賛募集中ではありますので、ぜひ興味があればお声掛けください。
私は最初からEMとして入社してもらうのかどうかをちゃんと擦り合わせるようにしています。プレイヤーとして入ってもらい、ちゃんと滑走路を設けるほうがいいかもしれません。Kyashのメンバーは比較的対話しやすい方が多いので、”お手並み拝見はするな”という話をEMに限らず誰かが入社する時に話をしています。私は組織を作るという意味では、受け入れる側が重要かなと思っています。その人のパフォーマンスを最大化するというのも、メンバーや既にいるEMとかの責務であるということは言い続ける必要はあるかなと思っています。
ただ、私はあくまでも迎え入れる側の立場で、自分がパラシュート人事を経験したわけではありません。この点、あらたまさんはいかがでしょうか。
あらたま氏：私もEMで転職を経験された皆さんと同じように結構悩んだりしました。実際、受け入れ側はウェルカムという感じで、私の強みを引き出しみんなで強いチームになっていこうねという動きをしてくれてたと思うのですが、質問にあるように、コードベースだったりドメインに対する理解が浅い状態から、チームをマネジメントしていく必要があるため、チームの中でされる意思決定の確からしさみたいなところが自分では判断できなかったことがあり、マネージャーとしている意味はあるのかな、と苦しく思う時期もありました。ただそれは、キャッチアップするために一定の時間を使わせてもらうというところで、そりゃそうだよね、と思い進んでいきました。
あとは、採用に関する動きを自分自身が今の会社だったり、事業だったり、魅力をちゃんと語れるような状態になるまでキャッチアップして、もう動けるよねと思えるところで、ブログなどを書いて露出していき、チームに対して貢献していくことの実感を持つことでポジティブなループを回していくというのは実際に自分がやっていたことです。
konifar氏：とても良いお話ですね。
――「エンジニアとして熱量や意欲がない人に対する、EMとしての接し方で工夫や意識していることはありますか？シニアエンジニアになるほど組織課題への取り組みに熱量を持てない（現状維持）人もいるなと感じています。」とのことですが、いかがでしょうか？
konifar氏：そういう方はいますね。ある程度は採用時のマッチングを工夫すべきところかなと思いますが、何でテンションが上がる人なのか、喜びを感じるのか、が掴みづらいなと感じる方はいますね。
自分の場合は、月並みではありますがその人と話をして、開発に限らずどういうときにテンションが上がるのか、人生の話などを聞くようにしています。
常にニュートラルな人に対して、何かを無理やり上げていくのは健全ではないので、会社としてはこういった方を評価しようと思っていて、こういう振る舞いをしてほしいと思っているということをちゃんと伝えていくしかないかな、というのが自分の今の考えですね。
それが上手くできてるとは思いませんが、組織としてやっていく以上もうここはこういうルールなんですという指針を前面に押し出して、対話していくしかないと思っています。
もちろん思想を押し付けるのは怖いですし、それに対して反発が来ることもあるかなと思いますが、とはいえこの会社の組織、このチームはこういうふうにしたいと思っています、というのはある程度必要なのかなという感じですね。
あらたま氏：万人にとって、居心地のいい組織は存在しませんし、お互いに選択の自由があると思ってます。
例えば、品質を担保するためにunit testを書いていきましょうという組織があったとして、一方で絶対にテストを書きたくありませんと言う方がいたとします。もしかしたら自分が携わったコードに関しては障害が出ないかもしれませんが、他の方が触ると必ず障害が起きてしまう…となれば、それはその人がパフォームしていないことになってしまうので、それは私達が求める基準に達していませんというのをちゃんと言うべきだと思います。
程度の差はあれ、熱量の高さは表に出やすいので分かりやすい部分だったりしますが、仕事をどういうものと捉えていて、どうコミットしたいと考えているかというのは、konifarさんが先ほど話してくださったちゃんと聞くということに尽きるのかなと思いますね。
konifar氏：シニアエンジニアになるほど、組織課題の取り組みに熱意を持てないというケースも、こういう期待があるからこれも解決してほしいっていう期待を寄せるのであれば、それをちゃんと伝えて、今までこういう振る舞いなどもみてきてできると思っているので、ぜひお願いしたい。という話をしていく感じですね。
極端な言い方をすると、組織のために動いてほしいっていうことをちゃんと言いつつ、押しつけではないですが、擦り合わせて合意していくしかありません。
――「1on1などで、厳しいフィードバックをした際に、その後のお互いの関係性が悪くなる場合など、どれぐらいしょうがないものとして気にしないようにしていますか？」とのことですが、いかがでしょうか？
konifar氏：「フィードバック入門」（https://amzn.asia/d/imMwppp）という本が非常におすすめです。その中の、良いフィードバックと悪いフィードバックを一緒にやらない方がいい、という話が印象に残っています。
悪いフィードバックの後に、でもこういうとこも良かったよねみたいなふうに言うと、悪いところって全然頭に残らないという研究があるみたいで。こういった割と学術に基づいたフィードバックの仕方が書いていて、それをベースに自分はフィードバックをしています。
厳しいフィードバックについてですが、今のところ関係性自体が壊滅的に悪くなったことはないですね。その中で気をつけていることとしては、そういったフィードバックは必ず対面でします。あとは、「今からちょっと言いにくいこと言っていいですか」みたいなことから話をするようにしています。
「直接的な表現で言うけど、これは別に嫌いとかじゃないんですよ」という話からはじめます。もっと前段の話で言うと、自分の思想として、何かモヤっとしたりこれは絶対に良くないと思ったことがあったら、直接速攻で話すというのをモットーにしていることを伝えています。
なので、本当にまずいと思ったときは、1on1を待たずに「この後すぐ話せますか」とDMして話しちゃいますね。
基本的には話せば分かると思っているので、しょうがないとして諦めたことはありません。少なくとも、エンジニアリングの組織において、そこまで困ったことは今のところはないですね。
――コミュニケーションの方法を工夫してフィードバックを行うことが重要ということですかね。
あらたま氏：そうですね、あとは最終的には割り切りも必要かなと思います。
新しいチャレンジをして、ポジティブな意味で退職されるのは喜ばしいことですが、例えば組織が変わっていく中で、ポジションとのミスマッチが発生し、環境を変えるという決断をして退職をした社員がいた際に、それを自分のせいだと自責的になってしまう方もいると思います。
一度自分ごとにして、それを防ぐことができたのか、防げたとしたらどういうところだったのか、と反省をする必要がありますが、それを一通り考えたあとに引きずっちゃうとそれはどちらも不幸じゃないですか。
なので、ある種の割り切りも必要かなと思います。
konifar氏：確かに、退職者が出た場合でも、そのことに過度に引きずられず、意識的に「気にしない」姿勢を持つのはあるかもしれませんね。
――ありがとうございます。続いて「EMの皆さんの今後のキャリアってどのようにお考えですか？」とのことですが、いかがでしょうか？
konifar氏：私自身は、あんまり目的地を定めずにここまで来ました。EMを打診され、やってみた結果辛くなり一度やめて、もう一度VPoEを打診されたのでやっているという形でのらりくらりと来たような気がします。ただそれ自体は悪いことだとは思っておらず、結果的にはいろんな経験が繋がっていますね。
今後のキャリアの話でいうと、先ほども紹介したキャリアパスの本が一つ参考になります。EMとしてキャリアを続けていく人もいれば、一度プレイヤーに戻るという選択肢も全然ありかなと。むしろ、EMを経験したプレイヤーはとても頼り甲斐があると思います。
あらたま氏：EM経験のプレイヤーは、非常に頼りがいがありますね。
konifar氏：なので、打診されたらやってみるくらいの気持ちでいてもいいのかなと思います。一般的には、そのままマネジメントを極めるか、組織規模が違うところにEMとしてチャレンジしていく、とか思っているよりも無限に今のキャリアに繋げる選択肢があるのではないでしょうか。
あらたま氏：そうですね、組織の規模や事業の状態によって、同じEMの役割でも直面する課題や責任が大きく異なりますよね。例えば、プロダクトに関わるだけでなく、組織全体や事業戦略に関わることが求められる場合もありますし、逆に特定の領域に特化して深く関わることができる状況もあります。なので、いろんな形のマネジメントを経験したいと思えば、そういうキャリアのスライドの仕方もありますね。
konifar氏：あらたまさんは、CTOとしての経験を経てEMを務め、現在は再びプレイヤーとして活動されていますよね。それは、考えがあって選んできているのでしょうか？
あらたま氏：そうではないですね。やれるチャンスがあるのに、やらないのは勿体無いという気持ちでやっていて、オファーを承諾するかどうかを決めているのは自分自身ですが、それをやるぞと思ってやっているわけではありません。
今後のキャリアについてですが、幸いにもCTOやEMという役割を経験すると、解ける課題の抽象度が高くなってきます。例えば一つのチケットをどう考えて解決するか、という課題が具体的だとすると、もう少しふわっとした事業課題や経営者が対峙するような課題の抽象度のイメージです。
どの課題の粒度を解くのが自分にとって気持ちがいいと感じるのかは、これからもう少し見極めていきたいと思っています。それに必要なロールを得るためのコミュニケーションを次のステップでしていくことになるかなと思います。
konifar氏：メンバーからEM、EMからVPoEや役員になった時の違いとして、最初はルールがある程度決まったボクシングだったのが、本当に何でもありの総合格闘技になっていく感じがあります。
例えば、まずはチームのEMだとすると、チームの中で成果を最大化させていくというのが選択肢の一つになりますが、そこからもう少し幅が広がると、組織自体から考え直すという選択肢が増えたり、プロダクトマネジメントの方に染み出すと、そもそも作ることから取捨選択していいという選択肢に変わります。
元々やっちゃいけないという訳ではないと思いますが、こういう前提も崩して課題解決するという発想が生まれやすくなるのかなと思います。
EMの次のキャリアという質問に戻ると、不正解はないと思いますが、EMのロールを嫌だと思っておらず、その幅が広げられそうであれば一度やってみるのはいいんじゃなかなと思います。
あらたま氏：幅を広げていくというところに関して、例えば既に自分の組織にCTOやVPoEがいるからそのポジションにはつけないなと思っている方もいらっしゃるかなと思うのですが、EMのロールが分解可能であるのと同じように、CTOやVPoEも分解可能です。
そのため、自分が担えそうだと思えるポイントが一つでもあるのであれば、その部分を磨いて、今のCTOやVPoEの業務をいくばくか貰い受けるチャレンジはぜひやってみるといいのではないかと思います。それってやっていいんですよ、と言われないと気付けない部分かなと思いますが、CTOやVPoE視点では奪われることを期待していると思うので。
konifar氏：とてもいい話ですね。
――最後に1つだけ質問があります。
「未来のEMを育てることもEMの役割なのでしょうか？」とのことですが、いかがでしょうか？
あらたま氏：「Yes」以外の回答は無いですね。
自分が新しい挑戦をしなくても良いなら良いかもしれませんが、未来永劫、自分が現在のポジションにとどまるというわけにはいかないですからね。
konifar氏：EMになりたいと言ってくれる人がいたらその人の能力を上げるために積極的にサポートしていきたいと考えます。具体的にお願いしていきたいことを伝え、コミュニケーションを通じて、その人の能力を伸ばしていくことができると思います。
ただ、Kyashで現状はできていないですね。というのも自分が育てるというよりは、みなさん優秀なので、お願いして引き受けてくれたという感じです。ですが、役割としては持つべきだと思います。
あらたま氏：新たなEMを育てるというよりも、その役割を移譲していく取り組みを行うべきみたいな感じですかね。社内に適任者がいない場合は、その役割を埋めるために積極的に採用活動を行い、適切な人材と出会うことも責務だと感じています。
LayerXでも採用を行っておりますので、少しでも興味を持っていただいた方はぜひ一緒にお話ししましょう。
https://jobs.layerx.co.jp/7b31f370acc0411994174700fe212287
――ありがとうございました。
