ネガティブなフィードバックをする時に気をつけていること

メンバーへのフィードバックはエンジニアリングマネージャー（EM）にとって欠かせない業務の一つです。ただ、それがネガティブな内容を含む場合、相手を傷付けてしまわないか、納得してもらえないのではないかという不安や、自分が本当に正しいんだろうか、偉そうにみえてしまわないかという迷いがつきまとい、非常に精神的なエネルギーを消費します。個人的には、EM業務の中で最もハードなものに部類します。

しかし、不安や迷いを抱えながら中途半端なフィードバックをされてもメンバーにとってはいい迷惑です。耳が痛い内容でも前向きに捉えてもらうための努力をEMとして最大限すべきと考えます。感情的な負担に負けず、自信を持ちながら迷いのないフィードバックを実践するために自分が気をつけていることを自己整理のため書き出してみました。

1.冒頭で、相手の成長のためであることを伝える

誰もが、自分ができていないことを指摘されるのは気分が良くないもので、フィードバックを受けるとなると、普通は身構えてしまいます。最初から対立する雰囲気が生まれると、受け手も素直に受け入れることが難しくなり、フィードバックする側としても精神的に辛く感じてしまいます。

相手に受け入れてもらうために、本題に入る前に「いまからネガティブなフィードバックをするが、それはあなたの成長のために行うものだ。耳が痛い話かもしれないが、必ず改善できるはずなのでよく聞いてほしい」ということを伝えるようにしています。成長にむけた話として捉えてもらうことで、前向きな姿勢で聞いてもらうようにします。また、フィードバックを成長のための課題とすることで、あなたvsわたしの構造ではなく、課題vsわたしたちという構造を構築できます。

2.ポジティブな話でごまかさない

ネガティブな話を伝えるときに、サンドウィッチ型フィードバックでごまかさないように気をつけています。サンドウィッチ型とは、ネガティブな話の前後にポジティブな話を挟むフィードバック方法で、クッションを置くことで中間のネガティブな話を受け入れやすくする効果があります。

確かにサンドウィッチ型を使用すると、フィードバックする側としても少し気が楽になりますが、本当に伝えたいネガティブな内容が薄まってしまうデメリットもあると言われています。個人的にはサンドウィッチ型を選択するのはフィードバックする側の都合が強いと感じており、相手に受け止めてもらうためには、やはり誠実に本題であるネガティブフィードバックだけを伝えるほうがより効果的だと考えています。

3.「〜のように見えています」と周りから見えている姿を伝える

相手の行動の良し悪しを判断するのはとても難しいことです。伝え方を間違えれば、信頼を失います。

「〜をしたのは良くなかったね」といった形で行動と評価を結びつけるのではなく、「あなたの行動は〜のように見えています。それにより、周りは〜な影響を受けています。」と、相手の行動や姿を鏡のように伝えるようにしています。相手の行動が周囲からはどのように見えどう感じられているかは周囲に主体が有るため、客観的な事実としてはっきりと伝えることができます。

この方法の利点は「人格否定につながりにくい」という点にあると感じます。どうしてもネガティブなフィードバックは「人格を否定された」と受け取られることがありますが、客観的に見た事実として伝えることで、行動やアウトプットに問題があると受け入れてもらいやすくなります。

相手の行動を鏡として映すためには、客観的な事実を集めることが不可欠です。自分の思い込みを頼ったり、第三者から聞いた話を鵜呑みにしてしまうと、事実と異なることを伝えてしまい、相手を傷つけてしまうかもしれません。客観的事実を集めるためには、偏見を排除し、自分で確かめる、ログを確認し、定量的なデータで検証するなど、情報収集を時間が許す限り丁寧に行うよう心がけています。

4.改善方法を自分で考えてもらう

フィードバックで伝えたことは本人にはしっかりと受け止めてもらいたいものですが、それが影響して相手が消極的になってしまったり自信を失ってしまうことは望んでいません。

改善策までを具体的に指示してしまうと自律を妨げてしまうため、どのように改善できるか、できるだけ本人に考えてもらうように心がけています。相手のレベルや課題によっては自分で考えることが難しい場合も、対話の中で相手から引き出せないかを試みます。

すぐに答えが出るものではないのでフィードバックの場では沈黙が続くこともありますが、考えてもらうことが大事なので、沈黙に耐えこちらからのサポートは極力我慢します。また一度のフィードバックの場で答えを出す必要は良いので、時間をおいて考えてきてもらうでも良いと思います。

---

ネガティブなフィードバックは伝える側としても精神的なしんどさをともないますが、うまく伝えることで相手の成長をうながしチームの健全性を維持できるため、改めて重要だと感じます。一方でヘタをすると人を傷つけ信頼を失ってしまうもので、今後も真摯に向き合いたいです。

参考書籍

フィードバック入門 耳の痛いことを伝えて部下と職場を立て直す技術

フィードバック入門 耳の痛いことを伝えて部下と職場を立て直す技術 (PHPビジネス新書)

自律型組織をつくるマネジメント変革

自律型組織をつくるマネジメント変革 人の能力を引き出す「ピープルマネジメント」

エンジニアの多様性を活かすには

「多様性の科学」という本がめちゃくちゃおもしろかった。多様性とは何か、なぜいま重要視されているか、多様性のある組織を作るにはどうすればよいかといったことが、事例をまじえてわかりやすく説明されている。多様性is何？という状態から読み始めたが、これ１冊でかなり理解は深められたように感じる。

多様性の科学

一番大きい学びは、単に「多様である」だけではなく「多様性を活かせる」環境を作らなければその価値は発揮されない、という点だ。そもそも多様性が重要視されている理由は、変化の激しい世の中なので様々な視点を持つことがリスク回避につながるし、新しい発想はこれまでにないコラボレーションから生まれやすいという点にある。なんだけれど、心理的安全性の無く若い人が発言しにくい環境にあったり、部署ごとに壁がありコラボレーションが生まれにくい環境にあったりすると、多様な人材がそろっていても意味がなくなってしまう、とのことだ。（超意訳）

ここでは書籍の内容をふまえて、エンジニア組織において多様性を活かすためにすべきことについて考えてみた。

エンジニアの多様性を活かすには

技術力を権威にしない

「副操縦士らは機長に意見するより、死ぬことを選んだ」。人間の心はヒエラルキーに多大な影響を受ける。たとえ生死に関わる状況でも、無意識のうちに自分を押し殺してしまう。

書籍「多様性の科学」では、機長が副機長に意見が言えずに事故にいたってしまう航空事故の例が紹介されている。機長が権威となり、大事なことが言えなくなってしまうというものだ。

エンジニアの場合、役職や年齢といったラベルよりも、技術力の高さや合理的であるかどうかを重要視する人は多いと思う。それが純粋なリスペクトであればよいが、ときに権威になってしまわないかは注意したほうがよい。例えばコードレビューのときにレビュアーとレビュイーとで技術力に差があるときに、レビュー内容が無条件に適用されてしまう、といったことがないだろうか（書籍では信頼は盲目につながるとある）。

権威に感じるかどうかは心理的な問題なので、コントロールしづらいところだが、権威につながる行動はルール下で制限できるように思う。 コードレビューであればレビュアーは断定的な表現を使わない、レビュイー自身が責任をもちコミットする、といったガイドラインを作成するのは有効だと考える。

エンジニアへの偏見を取り除く

一番わかりやすいのは１９７０年代のオーケストラの例だろう。この時代、アメリカ（に限らず各国）のオーケストラは団員のほとんどが男性だった。入団審査をする側が「一般的に見て、男性のほうが演奏がうまい」と思い込んでいたからだ。それを「実力主義による採用」だと主張していた。

どちらかというとエンジニアではなく人事やディレクターなどのエンジニアにかかわる人に伝えたい内容だが、エンジニアへの偏ったイメージをお持ちでないだろうか？エンジニアに独特な人が多いのは認めるが、事実とは異なるイメージを持たれていることも結構ある。最近だと、朝早くに働くエンジニアをみて驚いている人がいたが、エンジニアはみな夜型というわけではない（弊社、フレックス制のため早朝から働く人もいる）。

35歳定年説？

ある程度年齢を重ねるとマネージメントできるようにならないと、という風潮はエンジニア界隈でも感じるが、最近は IC (individual contributor) という言葉も定着してきているように、ミドルやシニアに分類される年齢でもマネジメントロールを持たずに個人開発者として活躍する道は一般化してきている。身近にも40歳を超えてバリバリ実装しているエンジニアはざらにいる。

文系より理系のエンジニアのほうがすぐれている？

エンジニアへの向き不向きはあるのは認めた上で、文系・理系といった学歴分類自体はエンジニアを評価するうえで役に立たないように思う。エンジニアの素養を持ちながらもその時の興味や都合で文系に進んでいる人もいるし、文系で学んだ知識が分野横断的にエンジニア業務に役立っている場面を何度も見たことがある。

女性はエンジニアに向いていない?

女性エンジニアが男性より少ないのは事実だが、優秀なエンジニアかどうかはまた別の話で、優秀な女性エンジニアの方をたくさん見てきた。エンジニアに男性のイメージがある理由の一つに、3K（きつい、厳しい、帰れない）と呼ばれていた過去の労働環境の悪さがある。体力的に不向きというのは以前はあったかもしれないが、今は労働環境はだいぶ改善されてきた。

上記はぱっと思いつくものをあげたのでわかりやすいが、書籍でも「無意識のバイアス」と表現されているとおり、本当の偏見は自分では気づきにくい。 書籍では、採用時の無意識のバイアスを取り除く方法として、履歴書を「目隠し」する（性別などの情報を非表示にする）方法が紹介されている。（実験手法だったかも）

リモートワーク下でもユニットを超えた交流をもつ

１９８６年にジョージ・ルーカスから買収して新たに設立したピクサー・アニメーション・スタジオのデザインを考える際、彼はトイレを１カ所だけにすると決めた。しかも場所はアトリウム〔エントランス付近に設けられる明るい大空間〕の中だ。つまり社員はそれぞれのオフィスから出て、そこに集まってくる。一見、非効率だが、そのおかげで偶然の出会いが起こり、第三者の視点を得るチャンスが増える。「みんな誰かと出くわすんだ」とジョブズは言った。

一般的なプロダクト開発組織の形状は、機能別組織、目的別組織、マトリクス組織の３つのいずれかに分かれると思う。こういったユニット分けは、コミュニケーションパスを制限し認知負荷を下げるためにあるが、あまりにユニットが分かれすぎると交流が固定化し、コラボレーションの機会がなくなってしまうので、意図的に離れた人をつなぐ設計をすべきだと思う。

いま、オフィス回帰の流れもあるが、とくに開発業務はリモートワークとの相性がよく、リモートメインを継続するIT企業は多いのかなと思う。 リモートワーク下のなかで、ユニットをまたいだ交流点（ピクサーのトイレ）をどこに設けるかは悩ましい。

単に雑談会を開くというのはやりがちだが、経験上「さあ！雑談しよう！」というノリだと盛り上がらないことが多い。 絶賛模索中ではあるが、ユニット横断での課題を話し合うOSTであったり、設計技法などの共通項の多い領域の勉強会といった、業務にかかわるテーマで横串で集まる機会を設けるのは有効だと感じている。

エンジニアの認知的多様性に目を向ける

性別、人種、年齢、信仰などの違いは、「人口統計学的多様性」としてよく分類される。本書ではこの種の多様性のほかにもう１つ、ものの見方や考え方が異なる「認知的多様性」についても検討する。

「認知的多様性」とは、様々なバックグラウンドの違いによりもたらされるものの見方や考え方の違いのことである。書籍によれば、同質化した組織だと盲点に気づかず大きな失敗をしてしまうことがあり、そういった事態を避けるには、この「認知的多様性」のある集団であることが多様な視点を持つ点で有利だとある。

エンジニアにおける「認知的多様性」とは、個々のエンジニアリングへのスタンスの違いと言い換えられる。例えば、エンジニアには悲観的な人もいれば楽観的な人もいるし、システムの厳密性にこだわる人もいればユーザーの利便を最重要視する人もいる。

一方、「人口統計学的多様性」の方は、スキルセットや経験年数と言えそうだ。それ自体は多様性と無関係ではないが、採用やチーム組成を考える際には、表層上のスキルセットの組み合わせだけでなく、個々のエンジニアリングへの考え方や特性にも目を向けるのが重要だと感じた。

エンジニアの特性を表したもので、「エンジニア風林火山」というのがある。*1

• 風のエンジニア：迅速な設計・実装によって開発を加速させる
• 林のエンジニア：突発的なトラブルにも冷静に対処できる
• 火のエンジニア：新しい技術や方法を積極的に導入する
• 山のエンジニア：厳密なエラーチェックと堅牢なプログラミングで成果物の安定性を高める

この分類はあくまで一つの視点にすぎないが、こういったエンジニアならではの特性分類について知っておくのは良いと思う。

---

ここまで真面目に書いたけれど、ぶっちゃけ多様性というものの抽象度が高すぎて、今の開発チームがいい感じに多様なのかどうかはさっぱりよくわからない。

ただ、自分自身が多様性によって助けられてきた、という感覚はある。マネージャーをしているといろいろ考えているつもりでも特定の視点が抜け落ちることがあって、そんな時は「メンバーの気持ち分かってます？」とか「これ私にはさっぱり意味がわかりません」とか、どぎつい愛のある直球の意見をもらうことで「はっ」とさせられてきた。

多様性のある組織のマネージャーは、結構しんどいのかもしれない。。（愛ある直球をくれた方々にはめちゃくちゃ感謝しています）

*1:参考書籍： https://www.amazon.co.jp/dp/B08CQRKHKR?tag=note0e2a-22&linkCode=ogi&th=1&psc=1

会議で揉めたときは向きと前提知識をそろえる

WEB開発において、チーム内で意見が衝突することはめずらしくない。 会議中にメンバー同士で揉めた時、まず行うことが２つある。 ひとつは向きをそろえることで、もうひとつは前提知識をそろえることである。

向きをそろえる

意見が対立すると「あなたと私は敵である」という意識が生まれ、理論よりも感情が先行しやすくなる。 ただ本来、WEB開発チームは「プロダクトを成功させる（あるいは事業を成功させる）」という同じ目的を持った集まりであるべき。 プロダクトのビジョンやプロジェクトのゴールなど、最上位に位置する目的を再認識してもらい、メンバー同士が同じ方向を向くようにうながす。 すると、敵対関係が消え、感情を抑えて話し、相手の意見を聞き入れられる雰囲気が作られる（気がする）。

また、最上位の目的にひもづく下位目的があった場合に、各々の立場によっては優先する下位目的が異なることがある。例えば、デザイナーはユーザーの使いやすさ、エンジニアはシステムの保守性、ディレクターはコスト削減を第一に考えている、といった具合に。まずは各々の狙いをテーブルにあげてもらい、それらがトレードオフの関係になっている場合は、優先度をすりあわせるようにしている。

前提知識をそろえる

意見の食い違いがあった場合は、前提としている知識が違うことが多い。 専門とするドメインやバックグラウンドの違いによって、前提とする知識は人それぞれであることは自明だけれど、「相手がなにを知っていて、なにを知らないか」を知ることは難しい。 そのため、「あなたがなぜそう考えるのか、前提としている知識も含めて教えてください」という質問を投げかけ、本人から詳しく話してもらうようにする。 そうすると「あれ？このことが伝わっていないのかな」とか「ああ、そんな情報があったのか！」というズレに気づくことができる。

かっこよさげな横文字の単語が行き交っているときは危険信号で、同じ言葉でも人によって違う意味で捉えていることがよくある。これも「◯◯という言葉はどういう意味で使っていますか？」と丁寧に確認していくのがよい。

---

以前、自分が作成したチーム目標をメンバーに共有した時に、みんなから「なぜその目標になるのか理解できない」と総スカンをくらったことがあった。一人ひとり対話してみると、どうやら「会社からチームに求められているミッション」がうまく伝わっていないことがわかり、その前提から立ち返って説明すると納得してもらえたことがあった。自分では伝えていたつもりでも相手に届いているとは全く限らということを切に感じた経験だった。

最初からみんなが同じ方向を向いている、同じ知識を知っている、なんてことはありえない、って気持ちをもっておけば、会議で揉めてもその原因に意識が行くようになり、落ち着いたファシリテーションにつながると思う。

プレイングマネージャーは悪手か？

■背景

いくつかのチームでマネージャーを経験する中で得た、プレイングマネージャーについての考えを整理してみました。以前は、マネージャーはマネジメントに専念すべきでプレイングマネージャーは人手不足を補う次善の策でしかないという考えを持っていました。ただ、いくつかのチームでマネジメント業務を経験する中で、プレイングマネージャーにもメリットがあり組織設計次第で取りうる選択肢になるという考えに変わりました。

■プレイングマネージャーは悪手か？

◎成果が最大化できるかで考える

マネージャーの仕事はチームの成果を最大化させることです。そう考えると、必ずしもメンバーに任せるだけが正解ではなく、自分が動いた方が成果が出せる場合は動いても良いことになります。マネージャー自身のリソースは有限であるため、自分がプレイする割合とマネジメントにまわりメンバーに任せる割合を調整し、成果が最大化される塩梅を見つける必要があります。その時々で以下の方程式を解くようなイメージです。

成果を求める方程式

ただし、この方程式には時間軸は考慮されていません。眼の前の成果を優先しマネージャーがプレイし続けていると権限委譲が進まずメンバーの成長が阻害されてしまいうことがあります。上の方程式で言うと「メンバーのプレイスキル（定数）」がずっと変わらないことになり、そうなると長期的には成果が頭打ちすることになります。マネージャーがプレイングを担うことは短期的にはありですが、長期的な成果を考えると成長につながるようなタスクは極力マネージャーから手放していくべきだろうと考えます。

■プレイングマネージャーはなぜ忙しいのか？

◎相反する動きが求められる

プレイングマネージャーは業務過多になりがちです。単純にやることが多いからといえばそれまでですが、私の経験上、相反する性質の動きが求められることで、物理的にも体感的にも忙しさが増していると考えます。

マネージャーに求められる動きは環境によって変わるのであくまで私の場合の話ですが、当時私がマネージャーとして求められていたのは、他のメンバーが成果を出しやすい状況を作ることでした。それには全体を俯瞰して見ながら社内調整などの細かいタスクをマルチに素早く打ち返すといった動きが必要でした。一方で、リードプレイヤーであることも求められており、他の人にはできない難易度の高い仕事を担当し、まとまった時間と集中を要する仕事をしていました。

前者と後者は真逆の性質の動きになっていたため、タスクの優先度付けも時間の確保もめちゃくちゃ難しくなり、結果、プレイヤー業務は残業時間に集中してやることでなんとかカバーしていました。くわえて、業務によってマインドを切り替えることのオーバーヘッドは大きく、体感的な忙しさも飛躍的に上がっていたと思います。まるで、ボクシング選手とセコンドとの両方を一人で担っているような感覚がありました。

前述の「成果を求める方程式」のところでメンバーの育成観点で長期的にはプレイングマネージャーは脱するべきと書きましたが、マネージャー自身の負担的にも、過度な疲弊を生むため長続きするものではないと考えます。

■専任マネージャーのジレンマ

◎現場感の喪失

ではマネージャーに専任できることは幸せでしょうか？

私もずっとプレイングマネージャーをしていたわけではなく、マネジメントに集中できていた時期もあります。その時はメンバーが成長し権限委譲も進んでいたこともあり、私自身はメンバーをサポートすることに集中でき、チームとしても成果が出ていたと思います。ただ悩みがなかったわけではありません。

しばらく自分で手を動かす業務から離れることで、メンバーの方が今のシステムに詳しいことが多くなっていくことに、淋しさと焦りを感じるようになりました。気持ちの問題だけであればまだ良いですが、現場の感覚が薄れることで技術的な判断やメンバーの評価がだんだんと難しくなっていきました。まるで技術の貯金が切り崩されていくような感覚がありました。

マネージャーであり続けるためには、現場感を失わないためのキャッチアップが必要となり、定期的にプレイヤーよりの動きに戻らねばならないというジレンマのようなものを感じました。 （最近マネージャーからICに戻る人の話をよく耳にしますが、あれはここに起因するところがあるのかなと想像します）

■一つの理想形

◎小さく優先度の低い「ささやかな作業」を担当する

プレイングマネージャーであることは、現場感を維持するのに良い方法のように見えます。ただ前述のようなリードプレイヤーの動きも求められるマネージャーだと、疲弊を生み長続きしません。

書籍「エンジニアのためのマネジメントキャリアパス」によると、管理者は管理業務のかたわら「バグの処理やちょっとした機能の作成」といったささやかな作業をするとよいとあります。ITスキルを維持し、現場の問題を察知することにつながるためです。また、ささやかな作業であれば、いざというときは優先度を下げ、管理者がボトルネックになることを避けることもできます。

前述のリードプレイヤーは、マネージャー自身が直接成果に貢献するアプローチでしたが、こちらの「ささやかな作業」を担当する方法は現場感を維持することで「マネージャーのマネジメントスキル」を保ち、長期的に高い成果を上げるアプローチだと言えます。

マネージャーは現場感・マネジメント力を維持する目的で小さく優先度の低い「ささやかな作業」を担当する、成長につながる難易度の高いタスクはメンバーに渡しチーム全体の成長を促す、という在り方が、長期的に安定して高い成果を出せる形であると考えます。

◎マネージャーオブマネージャー

では専任のマネージャーは必ず成り立たないものでしょうか？一つありうるのは、プレイングマネージャーをマネージするマネージャーオブマネージャーであれば持続可能なのかなと考えます。

専任マネージャーの問題は現場感の喪失にあると述べました。ただ、マネージする対象がマネージャーであれば、その接点は自分が専門とするマネジメントに関する判断や評価、壁打ちになることが主となるため、相手の方がいつの間にか詳しくなっているということが起きにくいのかなと思います。少なくとも全く話についていけなくなるということは無いはずです。プレイヤーをマネージする専任マネージャーよりも、ジレンマにはおちいらず長続きするのではないかと考えます。

採用難易度を踏まえるとそんなにマネージャー集められるのかという疑問もあるのであくまで理想形の話として、プレイングマネージャーをマネージするマネージャーオブマネージャー（長い！）はありではないでしょうか。

■おわりに

プレイングマネージャーについて考察してみました。コア業務を担うようなプレイングマネージャーは、短期的にはありだが、育成観点と難易度の高さから、長期的には脱するべきであるという考えを述べました。一つの理想形として、「ささやかな作業」をするプレイングマネージャー、およびマネージャーオブマネージャーの形を提示しました。

理想の形を書いたものの、昨今のエンジニア不足を考えると、チーム内のできるエンジニアがマネージャーに選ばれ、なし崩し的にマネジメントとプレイングを両立せざる得なくなることはあるあるだろうなと思います。採用や育成、長期的な組織設計で、プレイングマネージャーが無理を被らないチームにしたいものです。

EMが転職後の焦りと仲良く付き合っていくためにやったこと

こんにちは、エンジニアリングマネージャーの chome （@anachro3）です。この記事は Engineering Manager Advent Calendar 2021（その２） の20日目の記事です。

今年の10月に転職し、Baseconnect Inc.にエンジニアリングマネージャー（以下EM）として入社しました。初めての転職ということもあり、入社後に感じたこと試したことを書いてみます。

これはなに？

EMが転職後に感じた焦りと向き合い、焦りと仲良く付き合っていくために試したことをまとめた記事です。

私自身は今回が生まれて初めての転職でした。くわえて技術スタックもLAMP環境主体からRuby、React主体の環境に変わりました。マネジメントも前職で行っていたのはプロジェクトや運用チームのマネジメントが主で、エンジニアチームのマネージを任されるのは初めてという、変化の大きい転職でした。（正確にはまだマネージャー候補です）

新しい環境で２ヶ月を過ごして思うのは、想像していたよりも焦りを感じたということです。私自身、受け入れる側として転職者と向き合ってきた中で、入社後オンボーディング中の辛さは聞いていましたが、いざ当事者になってみると聞いていた以上だなと感じました。

日増しに焦りがつのっていく日々に、私は思い悩み、自信が崩れ、自暴自棄になり、毎晩酒に逃げるように・・・ということには全くならず「え、何この感情？めっちゃレアじゃん！貴重な体験やし自分自身を観察して対策を立ててみよう！」と、何でもネタにしようとする関西人のノリが発動しました。

転職後の焦りがどこから来るかを自分なりに整理し、自己のはたらきかけで解消できるものとどうしようもないものを分類し、解消に向けたアクションをとってみました。これからEMを目指す人や、エンジニア部門の人事担当者の方に参考にしてもらえると幸いです。前提として、EM職の場合の事例であることにご留意ください。

転職後の焦りはどこから来るか

まず、自分が転職後に感じた焦りの要因を分類しました。

①マネジメントされる側になるギャップ

新しい職場ではオンボーディングを丁寧に行ってもらいました。どの領域で力を発揮していきたいかのすり合わせや、エンジニアとしての社内ルールのレクチャーなど、部門長とオンボーディング担当者に丁寧にみてもらえる環境でした。それは良いことのはずなのですが、困ったことに、丁寧に接してもらうほど、前職では自分が行っていたマネジメントを自分が受けていることにギャップを感じ、もどかしさがありました。職業感の中でのアイデンティティが無くなるような感覚でした。

②情報を持っていないことによる不安

マネージャーの仕事に一つに「情報を活かすこと」があります。書籍「HIGH OUTPUT MANAGEMENT」ではマネージャーがすべき行動として、現場での情報を収集し活かすこと、現場に必要な情報をもたらすことがあげられています。前職でも、経営層と現場、クライアントと自社、メンバーの間に立ち、情報をつなぐ動きをしていた感覚があります。

転職後は、当たり前ですが、事業のことも組織のこともプロダクトのことも、さっぱりわからないことばかりです。これは、マネージャー職にとっては、まるで武器をもたずパンツ一丁でモンスターがいるフィールドに立っているような感覚です。マネージャーにとって何をするにしても情報が足場になることを認識しました。

③期待値の大きさ

入社後、経営層やメンバーと話していくうちに、嬉しいことに思ったよりも期待をいただいている事に気づきました。もちろん、ポジションに限らず中途入社者は何かしらの期待があって採用されているので、期待されるのは当たり前です。また、雰囲気から感じてそう思っているところもあるので、実際のところの期待値はわかりません（自意識過剰かもしれません）。

ただ、リップサービスもあるとはいえ「これまでの豊富なプロジェクト経験を活かして〜」といわれれば「いやそこまで豊富でもないんだけどな・・・」と思ったり、「これまでのうちのやり方に縛られずに新しいことを〜」と言われると「いやまだ現状を知るのに精一杯なんですけど・・・」と思ったりして、期待が先走っているような感覚をうけました。この期待値のギャップは、採用面談の時に受かるために自分を良く魅せようとしていたことが要因なので、身から出たサビ、起こるべくして起こるギャップではあるのですが、正直プレッシャーは感じます・・・。

④結果が出るまでの期間の長さ

入社して2週間ほど経つと、徐々にですが、1on1や開発フローの改善検討、エンジニア採用といった具体的な仕事を任せてもらえるようになりました。ただ、こういったマネジメント系の業務はすぐには結果がでず、結果がでるまで数ヶ月とか一定の期間がかかるものです。

開発系のタスクも一部担っていたので、「あいつ何もしてなくない？」と思われないためにより早くプルリクを出そうともがんばりました。ただ、EMとして求められているのはそこではないよなー、と、プルリクを出せば出すほどEMとしての結果がすぐに出ないことにもどかしさを感じました。

⑤関心事の多さ

EMの職務領域は明確な定義はなく企業によって変わるところですが、一般的には広くなりがちです。広木大地さんの「エンジニアリングマネージャ/プロダクトマネージャのための知識体系と読書ガイド」で定義される強いEMを求めてしまうと、エンジニア部門のマネージに加えてプロジェクトやプロダクトについても働きかけが必要になり、関心事はかなり多くなってしまいます。

私の場合は組織自体が変化のタイミングということもあり、EMとして何をしていくか領域を絞らず進めながらすり合わせていく事になっていました。くわえて技術スタック自体が変わるため、基礎的な技術領域の再勉強も必要になり、関心事の多さにプチパニックでした。

焦りと仲良くするためにやったこと

次に、焦りの要因に対して、どういうアクションが取れるかを考えました。

情報が集まる場に行く

まずは組織のことを知るのが大事だと思い、自分から情報収集の機会をつくるようにしました。具体的には、自分がアサインされていないプロジェクトや他部門のミーティングに、情報が集まっていそうだと思えば許可をもらって参加していました。入社してしばらくは時間的余裕があったのでできたことです。

特にプロジェクトふりかえり会への参加は、これまでの情報が凝縮されており開発プロセスの課題感がつかめたのでとてもよかったです。直近では、メンバーのGoogleカレンダーを見て面白そうなミーティングがないかを探るのが日課になっています。

また、部門長のはからいで、営業や企画といった他部門の方との1on1の機会を作っていただき、これも部門間の連携の課題を掴むのに非常に役立ちました。部門を超える調整になるので会社によっては難しいかもしれませんが、はたらきかけてみる価値はあると思います。

注力する領域を絞る

情報が集まってくると、少しずつ開発部門の解像度が上がり、課題感がわかるようになってきました。組織的な課題や技術的な課題の全てに手を広げてしまうと中途半端になることは見えていたので、注力するポイントを絞ることにしました。

前述の広木大地さんの記事を参考に、EMの４象限の中から、自分がやりたいこと・できることと、開発組織にとって必要なことの重なる部分がどこか考えました。私の場合、デプロイや品質周りの課題に対して自分の経験が活かせるイメージがあったので、特にプロジェクトマネジメントに注力しようと考えました。

自分の中で比重を置くところを明確にしたというだけですが、それだけでも関心事の優先度が整理でき、頭をすっきりさせることができました。

メンバーからの期待値を不要にあげない

1on1の機会があったので、自分が得意なことに加えて、苦手なこと、やっていきたいことがあるが中長期的にはなることを伝えるようにし、期待値の調整を行いました。

また、メンバーには「EMに期待していることを聞かない」ように注意していました。期待をメンバーに聞いても全てに応えられるわけではなく、応えられなかった時にがっかりさせてしまうためです。1on1では課題感を探るようにし、組織の目標と合わせて何ができるかを考えることを大事にしました。

※ この「期待していることをメンバーに聞かないようにする」やり方は、Meetyで面談させていただいた西場さんからアドバイスいただいたものです（その節はありがとうございました！）。Meety では転職前にEMのキャリアについて複数の方にご相談させていただき、アドバイスをいただきました。こういった面談ツールの活用も転職の不安解消の方法としてオススメできます。

焦らずに焦りを受け入れる

ここまで３つ対策を立ててみましたが、焦りを解消しきるには十分ではありませんでした。ただ、やれることをやってみると、あとはもう時間が解決するのを待つしかないなと気持ちを切り替えることができました。それまでは焦ることをネガティブに捉えていましたが、無理に焦る気持ちを否定せず、「ちょっと焦るくらいがちょうどよいよね」と焦る自分を認めるようなスタンスでいることが、バランスがいいなと思うようになりました。

転職者からするとまわりの評価は気になるものですが、受け入れ側からすると意外と急かす気持ちはなく、中長期的に活躍してくれることを期待しているものです。当事者がそのマインドを持つのは難しいですが、私の場合、以下の記事が気持ちを切り替える助けに非常になりました。

note.com

終わりに

EMとして転職した後に感じた焦りと向き合い、やってきたことについてまとめました。転職後の焦りにはいくつかの要因があり、それを紐解いていくだけで少し心の安定を得ることができました。手を打てることは打った上で、どうしようもないことに対しては、焦らずに焦りと長期的に付き合っていく思考になることが肝要だと学びました（タイトルの“仲良くする”はここから来ています）。

初めての転職は、不安だけではありません。新しい職場では、エンジニア同士が助けあう雰囲気があり、ご多分に漏れず助けてもらっています。社内勉強会も盛んで、私自身、入社１週間目でLTする機会があり、刺激を与え合う環境があります。総じて、挑戦することを楽しむ雰囲気の中で前を向いて仕事ができています。

また辛いことがでてきたらネタにして、長期視点でやっていこうと思います。