こんにちは。コミュニケーションプラットフォームディビジョンプロダクトユニットファサード開発グループ (なげぇ！) の 須田 です。2023年4月に新卒で入社して現在3年目を走っております。今年 (2025年) の10月から所属するファサード開発グループのエンジニアリングマネージャー (EM) を任されています。
EM になって最初に何をやろうと考えたとき、まずはチームメンバとの関係を再構築して EM としての信頼を獲得する必要があるという考えに至ったので、就任当日の10月1日から 1 on 1 の設計をして実施をしました。
年末のこの機会を使って、2ヶ月間の取り組みをふりかえってみたいと思います。
--
この記事は kubellアドベントカレンダー2025 の12月15日分の投稿です。
はじまり：「須田くん、EM やってみない？」
私はもともと2023年4月にフロントエンドエンジニアとして入社しているのですが、サーバーサイドの知見も得ておきたいとは常々思っており、2025年5月にファサード開発グループという BFF (Backend for Frontend) の開発と運用を担う部署に異動しました。今はクライアントとサーバーの間に立つ GraphQL サーバーを作っています。
なんとなくサーバーサイドや GraphQL の気持ちも分かってきたな〜、チームにも馴染んで良い感じだ！と思っていたある日、私は上長に呼び出されました。曰く、諸々のタイミングが噛み合って君のグループの専任 EM を探している (当時は他グループと兼務の EM が付いている状態だった)、須田くん興味ありそうだしやってみないか、とのことです。仕事は選ばないことに決めている私は2つ返事で了承しました。
初手を練る：信頼の再構築
EM になることが決まって何から始めようかと考えたとき、最初にやるべきは各メンバーとの信頼関係の再構築だということに思い至りました。EM の仕事はチームをマネジメントすることであり、チームは人間であるメンバーで構成されているわけですから、各メンバーと信頼関係を構築することは必須です。
当時私はフロントエンドの部署から移籍してきて半年も経たないというタイミングだったので、まだまだ信頼関係は発展途上という段階でした。私が所属するファサード開発グループは若手中心のチームで、全員が20代という構成です。とはいえ、メンバーの中には「コイツは本当に仕事ができるのか」と見極めモードだった方もいるでしょうし、「ポッと出の若造がマネジメントなんかできるのか？」と思っていた方もいるでしょう。また自分としても、エンジニアの須田として結ばれる信頼関係と、マネージャーの須田として信頼関係は少し毛色が違うものだとも感じていました。
そんなわけで、メンバーとの信頼関係を再構築しようと思い至りました。信頼関係を構築するやり方にはいくつかあると思いますが、当時の私がやることに決めたのは 1 on 1 です。1 on 1 を手段として選択したのは、今回は須田個人の役割が大きく変わるという状況だったので、個人 vs 個人で信頼関係を構築するのがスジだろうという思いからでした。
1 on 1 の問題点を考える
ところで 1 on 1 には一般的に様々な問題が生じがちです。当時の私が考えた 1 on 1 の「あるある」な問題は
- 毎回何を話せば良いのか分からない
- せっかく準備をして臨んだのに、相手の話を聞くだけで時間が終わった
- 相手に要望を出したのに、対応されている気配を感じない
- 気づけば業務連絡だけになってしまい、サシで話をする意味が分からない
といったあたりです。今まで自分が経験した 1 on 1 でも、しばしばこういった問題は現れました。
1 on 1 でこのような問題が現れると、個人間の信頼関係に影響を及ぼすので、かなり注意が必要だと私は考えています。特にあるあるな問題の一つである「相手に要望を出したのに、対応されている気配を感じない」のあたりは最悪です。1 on 1 の設計で工夫できる問題かもしれないのに、それが個人の信頼関係に強い悪影響を与えてしまいます。
ところで、1 on 1 をやる側 (EM側) に立ってみると、これらの問題は少し違った見え方をしてきます。それぞれ例えば
- メンバーがどんな状況なのか、何でも聞かせてほしい！
- メンバーの成長のためにいろいろと伝えたい！
- 要望してくれた内容は本当に良く分かるんだけど、諸々の事情で実現は難しい…！
- まずは何をやったのか事実ベースで確認してから話をしたい！
みたいな事情がありそうです。
ただ、1 on 1 を受ける側のメンバーからすればそんなことは知ったことは無くて、「そういう事情があるなら先に言ってくれよ」としか思いません。
ということで、先に言ってしまうことにしました。
1 on 1 の README を作る
1 on 1 の「あるある」な問題の芽を摘んでおくために、1 on 1 の README を用意することにしました。メンバーと 1 on 1 を初めて行う際に時間をとって読み合わせを行う、といった使い方を想定しています。
README を作るにあたっては、具体的な 1 on 1 の内容をあえて規定しすぎないことにしました。具体的な内容を事前に規定しすぎてしまうと、対話の自由度が失われ、規定から外れた話題に触れづらくなる危険性があると考えたからです。
一方で「1 on 1 をなぜやるか」「1 on 1 を誰がやるか」にはしっかりとフォーカスを当てました。
まず、「1 on 1 をなぜやるか」については、ここさえ合意しておけば、1 on 1 をやる意味が無いんじゃないかというレベルで問題が発生することは防止できるでしょう。最悪の場合でも「まぁこっち (メンバー) としては良く分からないけど、EM がやりたいって言ってんだからやってやろうか」というラインは死守することができます。また、なぜやるかを明らかにしておけば、メンバーはそこから逆算して話題を思いつくことができます。「こういう目的でやっている 1 on 1 ならば、こんな情報も役に立つかも」と考えて話をしてくれるかもしれません。
また「1 on 1 を誰がやるか」については、私の立場と限界を明確に記述しています。私は EM という立場ですが、メンバーから出された要求をなんでもかんでも実現できるような超人ではありません。権限の限界もありますし、能力の限界もあります。そして権限や能力の限界は自分に分かったり分からなかったりします。なので、「伝えてくれた要求を必ずしも実現できる保証はない、でも努力はする」という点は強調して盛り込んでいます。また、組織の中の個人として 1 on 1 を行う以上、1 on 1 で出た話題を完全に2人だけの秘密とするのは難しいタイミングもある、ということも明記しています。
せっかくなので README の一部を公開してみます。
1 on 1 のテンプレートを作る
とはいえ README を作っただけでは、なかなか話は盛り上がらないことが予想されます。README 単体でも「結局何を話せば良いんだい」という問題を軽減させることはできると思いますが、解決には至らないでしょう。そこで 1 on 1 のテンプレートを作ることにしました。
現在、私とメンバーの間で使っているテンプレートはこのようなものです。
テンプレートを作る際は、なるべく「なんでも書ける」ようなものにすることを意識しました。例えば目標チェックの項目では、「現在の進捗」「直面している問題点」など細かく項目を切ってコメントしてもらうこともできたでしょう。しかしそうすると、そこからはみ出た話題を書きづらくなってしまいます。1 on 1 では「いやーぶっちゃけこの仕事はどうにもやる気が出なくて」といった生々しい話を聞きたいのですが、こうした生々しい話はあまりに具体的な項目があると対話のテーブルに上りづらくなると考えました。そもそも、詳細な項目を埋めて報告してもらえば済むようならば、わざわざメンバーの貴重な時間を奪って対面で対話をする必要はないのです。テンプレートに「なんでも書ける」ようにすることで、書いてくれた内容を参考にしつつ、そこから話題を深掘っていくことができます。
とはいえ、EM としてはメンバーがどのような仕事をしているのかを改めて把握しておくことも必要です。そのために「お仕事年表」という項目を作って、前回の 1 on 1 から今回の 1 on 1 までの間に行った仕事を自由に列挙してもらうようにしています。ただ列挙してもらうだけではなく、感想や学びもあれば書いてもらうことにしています。私はチームにベタ付きするスタイルを取っているのでメンバーの仕事はおおむね把握できているつもりなのですが、それでも 1 on 1 で改めてふりかえると「こんなことやってくれていたのか…！」と思うこともしばしばです。ちなみにこの「お仕事年表」は期末の評価・査定の際、メンバーが資料として活用できるように工夫をしてあります (もちろん、EM である私が 1 on 1 の資料を査定に使うなんて野暮なことはしません)。
ニヤリ・モヤリの項目は私のお気に入りの項目です。この項目には日々の業務で「ニヤッ」としたことと「モヤッ」としたことをそれぞれ書いてもらいます。仕事をしていると誰しも「これすごく自己満足してるけど、誰にも見えてないなぁ」とか「困っているわけではないんだけど、ちょっとモヤモヤするんだよなぁ」などといった場面には日々遭遇するものです。そうした場面をメンバーにふりかえってもらい、EM である私と対話をする中で整理・昇華できたら良いな、という思いから設置した項目です。
やってみる・やってみて
README を読み合わせテンプレートを展開して、2ヶ月ほど 1 on 1 をやってみました。頻度は原則週に1回は欠かさず実施、基本的には1回30分だけども仕事の状況に応じて短縮も延長も可、というスタイルで実施しています。
どうも毎回盛り上がっているぞ
これは EM サイドの視点の所感なのでメンバーは別の所感を持っているかもしれませんが、少なくとも私の視点からは「毎回何を話せば良いか分からない」「気づけば業務連絡だけになっている」というような問題は発生していないように感じています。テンプレートがあるので最低限それについては話ができる、というのは大きいと思います。よくある 1 on 1 の流れとしては、序盤はテンプレートに書いてある内容からスタートするのですが、そこから徐々に脱線してああでもないこうでもないと話をするような回が多いです。「書いてある内容を参考にしつつ、そこから深堀っていくことができる」がテンプレートを作った目的だったので、これは達成されていると考えて良いでしょう。
期待値調整も今のところ問題なさそう
また、1 on 1 の中で EM である須田に要望であったり苦情であったりが伝えられる場面も少なくありません (主に「モヤリ」のコーナーを深堀りするタイミングで出てくることが多いです)。そんなときには喜んで承りつつ、場合によっては改めて README を読んで「努力はする、でも約束はできない。経過は報告できるように善処する」というようなことを伝えています。メンバーとしても README は事前に読んでおり内容に合意の上で 1 on 1 に臨んでいるので、期待値のズレは発生しづらいのではないでしょうか。
ニヤリ・モヤリの項目でメンバーやチームの天気が分かる
ニヤリ・モヤリの項目もかなり私の目論見どおりに機能しました。1 on 1 の内容なので具体的に出た話題を書くことはできませんが、ニヤリ・モヤリに書いてくれた、あるいはそこから出発して深掘った会話から、次のアクションが生まれてくることが多いです。私としても、必要に応じてより役職の高い社員にエスカレーションしたり、あるいは他のチームの EM から協力を得て別の視点を入れてもらったりと、いろいろな打ち手を取ることができていると感じています。
相互フィードバックの項目は工夫の余地あり
テンプレートの最後に相互フィードバックの項目を用意しており、「メンバー → EM / 組織」「EM / 組織 → メンバー」の相互でフィードバックを書けるようにしているのですが、この項目は比較的メンバーが書くのに苦労している (というか空欄になっている) ことが多いようです。相互フィードバックの項目を設置した最大の目的は、私が何か間違った・適切でない行動をしているときにフィードバックをできる場を作ることだったのですが、なかなか 1 on 1 で面と向かって言うのは難しいのかもしれません。この点は 1 on 1 以外の手段で達成した方が良いのかもしれない、と考えつつあります。
最後に
ということで、2025年10月1日に EM に就任してから 1 on 1 をどう進めてきたかをつらつらと書いてきました。README やテンプレートは、私がかつて受けた 1 on 1 で欲しいと思ったものを具現化したものです。実際に運用してみるとなかなかに狙い通りに機能してくれたので、準備をしたかいがあったなと感じています。
次にこの README やテンプレートが機能するかが試される場面は、チームに新しいメンバーが入ってきたタイミングだと思います。今のメンバーは私との間にもともとベースとなる信頼関係があり、このことは 1 on 1 を順調に行うことができている大きな要因の一つだと考えています。まったく知らない新しい方がメンバーとしてチームに参加してくれたとき、この README やテンプレートが良い仕事をしてくれるのか、楽しみにしています。
--
株式会社 kubellでは、チームや組織に誠実に向き合うエンジニアリングマネージャーや、そうしたマネージャーのもとで活躍したいエンジニアを募集しています。気になる方はぜひ採用ページもご覧ください。
参考文献
本文に直接関係はしませんが、1 on 1 について考えるにあたっての僕のバックグラウンドになっていそうな文献は次のとおりです。いずれも良い文献なので、目次だけでも眺めてみるのはオススメしたいです。
