私はソウルに住むニュージーランド人です。この記事では、内側から見た韓国の開発現場、採用の場の両側から見えたもの、そして韓国で働こうと考えている人に伝えたいことを書きます。

ここに至るまで

#

入口は修士課程でした。ニュージーランドのワイカト大学で学士を取り、通信会社でネットワーク運用の仕事を1年した後、2017年3月から2019年2月まで慶熙大学校でコンピュータサイエンスの修士課程に在籍しました。研究室は毎学期、国内のコンピュータ系学会であるKSCとKCCに参加していました。2018年に平昌で開かれたKSCでは、韓国の大手IT企業がいくつもスポンサーに名を連ね、就職活動中の学生向けの採用ブースもありました。韓国の大学院にいる留学生なら知っておいて損はありません。

それからの経歴はこうです。

エンジニアリングは馴染みのある半分でした。ソフトウェアを出荷する仕事の大部分が実は運用だと学んだのはカスタマーサポートのスタートアップでしたし、クリエイタープラットフォームのバックエンドは今の私なら選ばないくらい多くのスタックの上で動いていました。韓国ならではの違いは端のほうにあります。Naverは気にかけるべき検索エンジンです。Kiwi Alumniの新しいWebサイトを公開したときも、SEOはGoogleとNaverの両方に合わせました。韓国のプラットフォームは想像もつかない名前でクロールしてきます（Naverのクローラーは「Yeti」、KakaoTalkのリンクプレビューは「kakaotalk-scrap」というものが取りに来ます）。そして韓国のネットバンキングは、今でも独自のセキュリティソフトをパソコンに入れるよう求めてきます。

でも、どれも難しいところではありません。

눈치とは何か、なぜ「optics」ではないのか

#

눈치は、相手が何を考え、何を望み、何を期待しているかを、言葉ではなく状況から感じ取る感覚です。눈は「目」の意味で、2019年の著書『The Power of Nunchi』で英語圏に눈치を広めたユーニ・ホン（Euny Hong）は、この言葉を「eye-measure（目で測ること）」と訳しています。日常の言い回しにもよく出てきます。「눈치가 빠르다（눈치が速い）」人は場をすぐに読めます。「눈치가 없다（눈치がない）」人はまったく読めず、これは褒め言葉ではありません。そして「눈치를 보다（눈치を見る）」は、周りの、たいていは目上の人の反応をうかがい続けて、嫌われない側に自分を合わせることです。

英語圏の人がここで持ち出す言葉は「optics」ですが、私はそれは違うと思っています。opticsは、実態がどうであれ外からどう見えるかの話です。「人員削減の発表と同じ週にボーナスを発表するのはopticsが悪い」という使い方ですね。見た目の問題で、管理するのは見られている側です。눈치はたいてい逆を向いています。自分が他人にどう見えるかではなく、自分が他人をどれだけよく見ているかの話です。両者が重なるのは「눈치를 보다」だけで、周りを観察しながら、周りに自分がどう見えるかを調整すること。韓国の職場について書かれた海外の記事に出てくるのは、まさにこのバージョンです。

そうした記事に出てくる例はだいたい同じです。チームリーダーより先に帰らない、年次休暇（연차）を実際に取るときの눈치、회식（チームの飲み会）からいつ帰っていいかを見極める、目上の人に反論するなら会議中にするか後でこっそりするかを決める。それぞれをどう受け止めるにせよ、形は共通しています。全員が従っていて、誰も口にしないルールだということです。日本の職場を知っている人なら、思い当たる節があるかもしれません。

そしてこれは言語とは別の問題です。韓国語は言葉の中にあり、눈치は言葉を取り巻くすべての中にあります。

開発チームのどこに現れるか

#

開発チームは、まさにその形で回っています。初めてマネージャーになって数か月後、チームノームについての記事を書きました。書き出しはこうです。私が対処した摩擦のほとんどは技術的な問題ではなかった。コードレビューはどれくらいで返すべきか、「完了」とは正確に何を指すのか、2回メンションするのは失礼か。人によって暗黙の前提が違っていただけだ。当時はその言葉を使いませんでしたが、あのリストは一行残らず、눈치が読み取る対象です。チームが口に出さずに合意しているルールで、新しく来た人は見て覚えるしかありません。

同じ記事で私は、新メンバーがノームをオンボーディングで明示的に教わるのではなく「言い伝えとして」覚えていくことや、グローバルなチームが自分たちの基準を全員の基準だと思い込むことに文句を言っています。눈치が何で動いているかを表すのに、私が見つけた一番いい英語はfolklore、言い伝えです。チームで外国人が自分だけなら、ずれている基準は自分のほうで、その言い伝えはどこにも書かれていません。

一番コストがかかるのはスタンドアップです。2023年に、自分がリードしていたプロジェクトが遅れていたのに誰かに聞かれるのを待っていた話を書きました。ようやく誰かが聞いてきたのは3週間後で、その頃にはもう大惨事でした。눈치がよくても、これは解決しません。場を読めば誰も聞きたくない話が何かは分かりますが、それでも言えとは教えてくれないからです。私が身につけた習慣は、待つことの正反対です。聞かれる前に、先に、文字で伝える。「思ったより時間がかかっています。5日ではなく8〜10日の見込みです。スコープを削りますか、それとも締め切りを延ばしますか？」

自分が読まれる側になったとき

#

2024年2月、ソウルのソフトウェア企業でエンジニアリングチームを任されて、눈치の向きがひっくり返りました。開発者のときは私が場を読む側でした。マネージャーになると、私自身が場になりました。会議で言ったこと、言わなかったこと、返信の速さ、何時に帰るか。すべてが周りから読まれるものになったのです。

プロジェクトリード時代に書いたことの多くは、マネージャーになるとより強く当てはまります。何が壊れているかを安心して言えない雰囲気なら、知るのはマネージャーが最後になります。情報を長く抱えすぎると周りはそれを察し、自分が残した沈黙を噂が埋めます。会議で5人が自分の答えを待っているとき「分かりません」は失敗のように感じますが、だからこそ言う価値があります。そして、私が何度も立ち返る一文。人は自分の意図を読めない、読めるのは言葉だけだ。눈치で回っているチームでは、それでも読もうとします。表情から、こちらが飛ばしたことから、帰る時間から。だからこそ、推測させる材料を減らすべきなのです。

私が頼りにしたのは地味なことばかりでした。全員との1on1。スプリントではなくその人自身の話をして、ほとんどの仕事をしてくれるシンプルな質問をします。「仕事を進めるうえで、私やチームにできることはありますか？」

誰でも見られる場所に書いた、3つから多くても5つの短いチームノーム。マネージャーがノームを破ったらどうなるかも含めて。8人いる場では絶対に発言しない人を待たずに、こちらから聞きに行くこと。そして二度と話題に上らない「検討します」の代わりに、正直な「できません、理由はこうです」。曖昧な答えは、読まなければならない空気をひとつ増やすだけですから。入社して1か月ほど経った頃のプロダクトチームの社外ワークショップは、カフェでお互いの価値観とチームノームを話し合うところから始まりました。会社が눈치に対して出せる答えとして、これほど直接的なものはなかなかありません。普段なら口にされないことを、午前中まるごと使って声に出したのですから。

外国人として採用されるということ

#

韓国での採用についてのプレイブックは持っていません。私にあるのは採用マネージャー側の経験で、そこから出てくるアドバイスは、契約にサインする前に会社に対して눈치を働かせよう、ということです。

マネージャーとして採用していたとき、私が一番採りたかった開発者は求人サイトにはいませんでした。以前にも書いたとおり、創業者はすでに一緒に働いたことのある人を採りたがるものです。だから一番いい入口は、採用される前に自分の働きぶりを見てもらえる場です。小さな会社のインターンは、いつの間にか内定に変わることがよくあります。ハッカソンなら週末まるごと見てもらえます。2023年、私は4人チームでLunit Global主催のSeoul Tech Impact Hackathonに優勝しました。作ったのは、韓国では住所を持たない屋台を探すためのアプリです。

そしてコーヒーチャットです。リラックスした会話での振る舞いのほうが、準備された面接よりも一緒に働く姿をずっとよく教えてくれると書きましたが、これは双方向です。候補者にとっては、中に入る前にチームを読める唯一の機会です。候補者の立場なら、私はこう聞きます。今チームが直面している一番大きな課題は何か、なぜ入社して、何が理由で今も残っているのか、そしてここで働いて驚くかもしれないことは何か。最後の質問は、눈치を前もって教えてほしいと丁寧に頼む方法です。離職率や会社の方向性について答えをはぐらかされたら、それだけで十分に分かることがあります。

外国人開発者を採用するなら

#

韓国でチームを運営していて、海外出身の開発者を採用するなら、一番役に立つのはあのチームノームの記事に書いた一言です。暗黙のものを明示的にすること。新しく来た人に、チームのルールを言い伝えとして覚えさせないでください。最初の週に伝えてください。レビューはどれくらいで返すのが普通か、「完了」とは何を指すのか、2回メンションするのは失礼か、みんな実際に何時に帰っているのか、年次休暇を取るときに申請書以外に気にすることがあるのか。最後の2つが典型的な눈치の質問で、チームの中にいる人は言おうとすら思わないものです。

その次は、読まなければならないものを減らす地味な習慣です。聞かれる前に伝える。金曜日に関係者へ3行のメール（今週出したもの、次にやること、気になっていること）を送るのに10分もかかりません。会議で静かな人を待たずに、直接聞く。「できません」も含めて、理由を添えた本当の答えを返す。そしてすべての候補者を同じ質問、同じ評価基準で面接する。これは私も身につけるのに時間がかかりましたが、人を公平に比べる唯一の方法です。そうしないと、最後に話した人を高く評価してしまいます。それに、チームの暗黙のルールを知らない候補者も、知っている候補者とまったく同じ質問を受けることになります。

ここにあるニュージーランドのコミュニティ

#

2018年、まだ学生だった頃にKiwi Chamberのリーダーシップ朝食会で写真を撮り、その後で、両国の関係を深めるイベントでボランティアをするのが本当に楽しいと書きました。2020年1月からは、Kiwi Alumniの会長を務めています。韓国に住むニュージーランド人と、ニュージーランドで学んで今は韓国で暮らし働いている人たちのコミュニティです。ボランティアの役職で、仕事のほとんどは人に関わることです。イベントを企画し、駐韓ニュージーランド大使館や教育機関との関係を築き、新しいロゴや会員が必要な情報をちゃんと見つけられるWebサイトといった地味な仕事もします。2023年には大使館と一緒にKiwi Alumni Nightを開き、KTVでも取り上げられました。

その夜の後に書いた一文が、この記事の主題に一番近いものです。韓国とニュージーランドの両方で暮らしたことのある人は、両方の文化を経験しているからこそ、その違いの橋渡しの仕方を知っている。働くために韓国に来るなら、どこの出身であれ、そういう人を見つけてください。その場の空気が何を言っていたのかを、はっきりした言葉で教えてくれる人たちです。

ソウルでフリーランスとして

#

マネージャーの仕事を離れ、2025年10月にフリーランスになりました。実際には契約ベースのDevOps・MLOpsの仕事で、ほとんどがオンプレミスです。PostgreSQLの高可用性クラスターを組み、続けて同じハードウェア上にLLMのサービング基盤を載せました。やってみると、配管工事より品質管理のほうが多くなりました。トレースやマルチターンの会話を見ながら、モデルの出力がどこでずれるかを探す仕事です。2026年2月からは、自分のマーケットプレイス兼コミュニティアプリも別に作っています。

フリーランスになっても눈치から逃れられるわけではありません。読む対象が変わるだけです。どこのチームに入っても、私が最初に見るのはモニタリングです。READMEよりもチームについて多くを語ってくれるからです。システムに向けた눈치と言えます。チームがやっていると言っていることではなく、実際にやっていることを読むのです。

韓国行きを考えている人へ

#

1. 採用される前に働きぶりを見てもらえる入口から入ってください。私の場合は修士課程でした。ハッカソン、小さな会社でのインターン、韓国にある自分の国のコミュニティも同じ役割を果たします。両方の国で暮らしたことのある人に出会えるのもコミュニティです。
2. 小さな会社を候補から外さないでください。私のキャリアのほとんどは小さな会社でした。10人規模の会社には退屈な仕事を押し付ける相手がいませんし、自分が作ったものが実際に世に出ます。
3. 入る前にチームを読んでください。コーヒーチャットを使い、ここで働いて驚くことは何かを聞き、離職率についてはぐらかされたら真剣に受け止めてください。
4. 聞かれるのを待たないでください。遅れそうな見積もり、リスクのある変更、誰かが待っている決定。先に、文字で伝えてください。
5. 書かれていないルールを声に出して聞いてください。レビューはどれくらいで返ってくるのか、「完了」とは何か、2回メンションするのは失礼か。誰も書いていないなら、自分が書きますと申し出てください。
6. 自分のスタックを取り巻くスタックを学んでください。韓国では、NaverとKakaoがGoogleの習慣ではカバーできない形で重要になります。

エンジニアリングは、来る前に準備できる半分です。눈치は働きながら覚える半分で、私が知っている一番早い覚え方は、言われていない部分を声に出してほしいと頼むこと、そして自分の分を先に言うことです。

その解決策には「チーム規範」という地味な名前がついています。Center for Creative Leadershipの定義では「チームメンバーの相互作用を形作る一連のルールや運営原則」。人事の書類仕事のように聞こえますが、要するに「みんなが当たり前だと思い込んでいたことを明文化する」だけの話です。

納得させられた研究

#

GoogleのProject Aristotleは、社内の180あまりのチームを調べて、良いチームは何が違うのかを探りました。結果は意外なもので、チームに「誰がいるか」より「どう協働しているか」のほうがずっと重要だったそうです。優秀な人を集めても、働き方の合意がぐちゃぐちゃなら平凡な結果しか出ないわけです。

この研究では、強いチームに共通する5つの要素が特定されました。心理的安全性、信頼性、構造と明確さ、意味、インパクトです。中でも一番効いていたのが心理的安全性。つまらない質問をしても、ミスを認めても、それで損をしないと感じられることです。関連する数字を見ると無視できません。パフォーマンス分散の43%を説明し、生産性は19%向上、イノベーションは31%増、離職率は27%減。

このリストの良いところは、5つのどれも生まれつきの性格ではないことです。全部、チームが意図して作れるもの。そのための道具が規範なんです。

日々の規範はこんな感じ

#

会議から始めるのが一番簡単です。悪い癖が目に見えやすいので。アジェンダは事前に配る、時間どおりに始めて時間どおりに終わる、反論する前に相手の話を要約する。私が気に入っているのは、身も蓋もない「アジェンダがなければ会議もなし」というルールです。

コミュニケーションの規範はもっと重要ですが、見えにくいものです。私の場合は、迷ったら共有しすぎるくらい共有する、決定事項は誰でも見られる場所に書き残す、会議を唯一のチャネルにしない、の3つに尽きます。8人の会議で絶対に発言しない人はいるので、そういう人には直接聞きに行きます。多様な視点を持つチームが同質的なチームに勝るという研究は山ほどありますが、それはその視点が実際に口に出された場合の話です。

意見の対立については、まず善意を前提にする、人ではなく問題を相手に議論する、相手が掲げている「立場」ではなく本当に必要としているものを探る。どうしても収まらない揉め事には、中立の第三者に入ってもらいます。

官僚主義にせずに規範を決めるには

#

CCLが勧めているのは理論ではなく経験から始めるやり方で、私もこれが良いと思っています。全員が「今までで最高だったチーム」と「最悪だったチーム」を語り、何がそうさせたのかをみんなで掘り下げ、見えてきたパターンを今のチーム向けの具体的な行動に落とし込む。上から配るのではなく、議論して合意する。破られたときにどうするか（マネージャーが破った場合も含めて）を先に決めて、見える場所に書き、ときどき見直す。

ひとつ付け加えるなら、最初は3〜5個に絞ることです。規範は習慣になって初めて機能しますが、10個の習慣を同時に身につけられる人はいません。

つまずきどころ

#

規範を一番手っ取り早く殺すのは、それを無視するリーダーです。私が「忙しいから」とアジェンダのルールを飛ばせば、チームは即座に見抜いて、すべてが茶番になります。文言の出来より、上に立つ人間の一貫性のほうがよほど大事です。

ほかに気をつけたい落とし穴もあります。新しいメンバーが規範をオンボーディングで明示的に聞くのではなく、口伝えの言い伝えとして学んでしまうこと。グローバルなチームで、自分の常識を全員の常識だと思い込むこと（暗黙の前提こそ明文化すべきです）。そして、規範づくり自体を形式主義だと感じている人。最後のタイプには、説教するより規範づくりに巻き込むほうがずっと効きます。

規範がどこで強化されるのかを知っておくのも役立ちます。高パフォーマンスチームの研究では、同じ3つの習慣が繰り返し見つかっています。ちゃんとしたキックオフ、定期的な1on1、そしてレトロスペクティブ。合意が生まれ、試され、静かに更新されていくのはそういう場であって、ポリシー文書の中ではありません。

規範が魔法だとは思っていません。ただ、Googleのデータが指す方向は、これまでの私の実感と同じです。チームの働き方は、メンバーの顔ぶれに勝る。だからうちの規範は短くしておくつもりです。数個の合意を全員が見える場所に書いて、実態に合わなくなったら見直す。定着したかどうかは、半年後に聞いてください。

今年からエンジニアリングチームを任されるようになって、パフォーマンスレビューは「受けるもの」から「自分が回すもの」になりました。この記事は自分の頭の整理も兼ねているので、正解というより「試行錯誤中の人のメモ」として読んでください。

そもそもレビューをやる意味

#

どの職級であれ、目的は突き詰めると2つです。学び続けられるようにすること。そして、役割の期待を超えて働いている人が、きちんと報われるようにすることです。

「レビューをやる時間もリソースもない」と言う小さな会社は少なくありません。そういう会社は結局、在籍年数だけを頼りに「そろそろシニアかな」を決めることになります。これは間違いだと思っています。年数が怠惰な指標だから、というだけではありません。レビューをやめると、会社と社員の双方向のチャンネルが消えて、働く関係そのものが痩せていくからです。

これは両方向に効きます。本人は「会社のために一番いいやり方」と信じて働いていても、習慣ややり方、コミュニケーションのスタイルが良くない方向にズレていくことがあります。フィードバックがなければ、誰もそれに気づけません。逆に、構造化された場で社員の声を聞かない会社は、社員が会社をどう思っているかを知らないまま、心地よく過ごすことになります。

お互い、何を期待して臨むべきか

#

社員側の期待は複雑ではありません。自分の仕事がチームの目標とどう繋がっているか、何がうまくいっていて、どこを直せばいいか。それも「もっとコミュニケーションを」ではなく、具体的に。貢献はきちんと認めてほしいし、キャリアや研修の話も本気でしたい。そして、社内政治ではなく仕事そのものに基づいた、公平なプロセスであってほしい。

マネージャー側の私が期待するのは、まず自己評価を持ってきてもらうことです。何がうまくいって何がダメだったか、本人の見立てを聞きたい。弁護士の冒頭陳述ではなく、フィードバックへの開かれた姿勢がほしい。今後の目標について本音の議論をしたいし、チームの中で自分がどうフィットしていると感じているかも率直に聞きたいのです。レビューは私自身の計画の時間でもあります。チーム構成、昇進の候補、誰にどんな成長機会が必要か。

同じ型がすべてのエンジニアに合うわけではない

#

エンジニアリングチームには、文化的背景も経験年数も専門も違う人が集まっています。同じ台本のレビューが全員に効くはずがありません。「平等に扱う」と「公平に扱う」は別物で、やり方は本人のニーズ、キャリアステージ、貢献に合わせて柔軟に変える必要があります。土台になるのは、各エンジニアの役割と責任が明確で、報酬とちゃんと釣り合っていることです。

一番こじれやすいのは、肩書きと給料です。タイトルに納得していない人や、昇進の準備ができていると感じている人に、曖昧な励ましは毒にしかなりません。効くのは具体です。次のランクの基準になる具体的なチャレンジやプロジェクト目標に合意して、昇進を「雰囲気」ではなく客観的な基準にする。報酬も同じで、給料が低いと感じている人や責任を広げたい人には、次のレビューまでに何を達成すれば変更を正当化できるのか、測定可能なターゲットをプランに書き込む。そして次のレビューでは、双方ともその約束に正直に向き合う。

改善のフィードバックにも同じことが言えます。特定のギャップを狙った特定の研修、ワークショップ、プロジェクトなら役に立ちます。「スキルを伸ばし続けてね」は役に立ちません。

基準づくりは最初の面談から始まる

#

新しいメンバーとの最初のレビュー面談は、ほぼベースライン設定の時間です。役割が実際に何を含むのか、それがチームと会社の目標にどう繋がるのかを一緒に確認する。パフォーマンスを判断する測定可能なアウトカムに合意する。短期と長期の目標を置く。カルチャーと期待される振る舞い、フィードバックがいつどう届くか、使える研修やメンター制度、その席から見えるキャリアパスについて話すのもこのタイミングです。どれも刺激的ではありませんが、これをやっておくと後のレビューが全部楽になります。

2回目以降のアジェンダ

#

1. 雑談。ばかばかしく聞こえますが、これで場の緊張が抜けて、その後の会話が正直になります。
2. アジェンダの確認。どちらも話題に不意打ちされないように。
3. 前回のレビューからの成長。進歩は明示的に言葉にします。本人は案外気づいていないので。
4. 現在のパフォーマンス。強みから。
5. 改善点。それぞれに具体的で現実的なターゲットを付けて。
6. キャリアプラン。今の仕事がそこにちゃんと向かっているかも含めて。
7. 次のレビューまでのターゲット、目標、アクションアイテム。

KPIは「その人用」でなければ機能しない

#

プロダクトチームのエンジニアのKPIは、チームの目標と本人の両方に合っている必要があります。フロントエンド、バックエンド、フルスタックで役割は違いますし、ジュニアとシニアの違いはもっと大きい。コミット数はジュニア開発者について何かを語るかもしれませんが、主なアウトプットがアーキテクチャの意思決定であるシニアエンジニアについては何も語りません。だからKPIはテンプレートのコピーではなく、会話の中で決めるものです。

私が見ている領域はこのあたりです。

• コードの品質：エラー率、規約の遵守、バグ修正が必要になる頻度
• プロジェクトのデリバリー：マイルストーンと期限の達成
• イノベーションと問題解決：効率改善、難しい問題を実際に解決できたか
• コラボレーション：ピアレビュー、チームの目標や議論への貢献
• 自己成長：学習目標の達成、資格、新しく身につけた技術
• 顧客へのインパクト：ユーザーからのフィードバック、リリースした機能の利用状況

測定可能な指標という意味では、最近ユニットテストに注目しています。InfoQのこの記事は、ユニットテストをパフォーマンスレビューに組み込む方法を扱っていて、実装の仕組みと、チーム文化への影響の両方に触れています。コードの健全性を定性・定量の両面から測ろうという主張で、エンジニアを行数に還元しないKPIを探しているなら一読の価値があります。

何を選ぶにせよ、レビューか1:1で一緒に合意して、役割やプロジェクトや技術の変化に合わせて見直すこと。誰も合意していないKPIは、人を叩くための棒でしかありません。

私が使っているテンプレート

#

ドキュメントは1人につき1つにして、レビューのたびにセクションを足していきます。そうすれば履歴が1か所にまとまります。骨組みはこうです。

## パフォーマンスレビュー：[名前]、[期間]

**役割とレベル：** [肩書きと、このチームでそのレベルが意味すること]
**前回のレビューで決めた目標：** [前回のセクションからコピー]

### 自己評価（エンジニア本人が事前に記入）
- うまくいったこと。例を1つか2つ添えて
- うまくいかなかったこと。次はどうするか
- 1年後に何をしていたいか

### 前回の目標の進捗
- [目標]：達成 / 一部達成 / 未達成。根拠も添えて

### 強み（具体例つき）
- [何を、いつやって、何が変わったか]

### 改善点（それぞれにターゲットを）
- [行動やスキル] → [日付]までに[「良くなった」と言える状態]

### キャリアとレベル
- 次のレベルに対して今どこにいて、何が足りないか

### 次のレビューまでの目標
1. [測定可能な目標]
2. [測定可能な目標]

### 合意したアクション
- [誰が]、[いつまでに]、[何を]する

自己評価は面談の1〜2日前に出してもらいます。面談中に書いてもらうことはしません。先に読んでおくと、会話が変わるからです。こちらが切り出そうと思っていたことを、半分くらいは本人がもう自分で書いているので、面談の時間はそれをどうするかに使えます。

自己評価のための質問

#

事前に送っている質問がこちらです。わざとオープンな聞き方にしてあります。何をしたかだけでなく、本人が自分の仕事をどう見ているかが、答えから見えるようにするためです。

• 前回のレビュー以降で、一番誇りに思っている仕事は何ですか？なぜそれを選びましたか？
• どこで行き詰まりましたか？何があれば、もっと早く抜け出せたと思いますか？
• チームメイトやレビュアーからもらったフィードバックで、心に残っているものはありますか？
• 前回の目標のうち、達成できたと思うものはどれですか？取り下げたい、または変えたいものはどれですか？
• 次に何を学びたいですか？今の仕事に、その機会はありますか？
• マネージャーとして、私が変えるべきことは何ですか？

最後の質問が、一番気まずい沈黙と、一番役に立つ答えを引き出します。

具体的なフィードバックとはどういうものか

#

ダメなレビューのフィードバックは、たいてい厳しいのではなく、曖昧なのです。私が書くようにしているフィードバックの例で、違いを並べてみます。

具体的なほうは、どれも出来事を特定し、それが何を変えたかを言い、本人が次にできることを指しています。書くのに時間はかかります。だからこそ私は、前の晩に思い出そうとするのではなく、四半期を通して事例を集めておくようにしています。

書き残す

#

面談が終わったら、サマリーを書きます。話した要点、挙がった課題、アクションアイテム、双方が合意した目標。官僚的に聞こえますが、この記録があるからこそ、半年後の「そんな約束はしていない」という会話を防げます。文書化された課題は蒸発せずに追跡され、アクションアイテムは次のレビューの冒頭アジェンダになり、紙に書かれた目標は真剣に扱われるようになります。

結局のところ、システムの全体はこれだけです。初日から期待値を明確にし、KPIはその人に合わせて作り、すべて記録し、アクションアイテムは必ずフォローする。双方向の会話と測定可能なアウトカムのないレビューはただの形式的な作業で、エンジニアはカレンダーの招待が届いた時点でその匂いを嗅ぎ取ります。

今月からエンジニアリングチームのマネージャーになりました。エンジニアからエンジニアリングマネージャーになると何が変わるのかを書いてから、数週間後のことです。誰も事前に教えてくれなかったのは、何もかもが緊急に見えるということです。新しいチーム、新しい会社、そして自分が来る前から積み上がっていたTODOリスト。全部を一度にやるのは無理なので、まず3つに絞って取り組むことにしました。

チームを知る

#

全員と1:1を組んでいます。スプリントの話ではなく、その人自身の話をする時間にしたいと思っています。キャリアで何を目指しているのか、最近何にモヤモヤしているのか、明日変えられるなら何を変えたいか。この場での私の仕事は、ほとんど「黙って聞くこと」です。信頼は最初の1週間では築けませんが、最初の1週間で失うことは十分ありえます。

働き方も人それぞれです。細かい指示がほしい人もいれば、任せてもらったほうが力を発揮する人もいます。この見極めを間違えると、お互いに不幸になります。Camille Fournierの『The Manager’s Path』がこのあたりをよく書いています。結局のところ、共感してちゃんと聞くことがマネジメントの大半なんですよね。

「なぜ今こうなっているのか」を学ぶ

#

プロセスにも、ちょっと不思議なアーキテクチャにも、過去の意思決定の痕跡が残っています。何かを変える前に、これまで何が試され、何が失敗し、会社が本当に大事にしているものは何かを知っておきたいのです。

どの会社にも、意思決定が実際どう回っているかという暗黙のルールがあります。これを早くつかむほど、チームのために動ける範囲が広がります。Andrew Groveが『High Output Management』で書いているとおり、全体像を自分で理解しないまま、チームの仕事をそこに合わせることはできません。

コードを読む

#

もうチームで一番コードが書ける必要はありませんが、アーキテクチャ、痛いところ、技術的負債がどこに埋まっているかは把握しておくべきです。なのでコードを読み、デプロイパイプラインを眺め、「1週間まるごと自由に使えたら何を直したい？」とメンバーに聞いて回っています。この質問の答えは、たいてい一番正直なロードマップになります。

もうひとつの効果もあります。プロセスだけでなく、仕事そのものに関心があるのだとチームに伝わることです。

あとは邪魔をしない

#

土台ができたら、やることはシンプルです。コンテキストを整え、目標を共有し、技術的な判断はチームに任せる。マネージャーの仕事はすべてのPRを承認することではなく、チームに必要なものが揃っていて、正しい方向を向いているかを確かめることです。Gene Kimの『The Phoenix Project』も同じ主張をしています。自分たちで意思決定できるチームは、上の承認を待つチームより速く動き、良いソフトウェアを作ります。

新任エンジニアリングマネージャーにおすすめの本

#

本文で触れた3冊を、ここにまとめておきます。

ほかに、新任EMが読むべき本としてよく名前が挙がるのが、Will Larsonの『An Elegant Puzzle』とLara Hoganの『Resilient Management』です。前者はチームの規模、計画、組織設計といった仕組みの側を扱い、後者はチームを知る、期待値をはっきりさせる、きちんと伝えるといった人の側を扱った、短く実践的な本です。

半年後にどうなっているか、また書きます。

実は近いうちに、自分自身がこの転身をすることになりました。それもあって、ここしばらくは経験者に話を聞いたり、手に入る本を読んだりしています。今のところ一番はっきりした学びはこれです。エンジニアからエンジニアリングマネージャーになるのはステップアップではなく、まったく別の仕事への横移動だということ。自分のアウトプットはコードではなくなり、チームが生み出すものすべてになります。誰もがそう言うのに、誰もがその大きさを見誤るらしいのです。

実際に何が変わるのか

技術的な問題を自分の手で解く仕事から、人にまつわる問題を解く仕事に変わります。カレンダーは1on1と計画ミーティングとチーム間調整で埋まり、採用もパフォーマンスレビューも自分の机にやってきます。仕事の中心は、チームが仕事に集中するために必要なもの、つまり背景情報と明確な優先順位、そして余計なノイズの少なさを確保することになります。

厄介なのは、アーキテクチャの議論についていけて、まともな技術判断を下せるだけの技術力は保ちながら、「コードを書くのは自分ではない」と受け入れなければならない点です。両方やろうとしたマネージャーを何人か見てきましたが、たいてい両方とも中途半端になっていました。

エンジニアとエンジニアリングマネージャーを並べてみる

経験者からいちばんよく釘を刺されるのが、このフィードバックループの行です。エンジニアなら、ほぼ毎日なにかしら小さな手応えがあります。マネージャーにも手応えはちゃんとあるのですが、届くのが遅い。自分の判断が正しかったのかどうか、しばらくわからないままでいることに慣れる必要があります。

大事になりそうなスキル

仕事の大半はコミュニケーションです。チームとプロダクトと経営層のあいだの通訳になり、この3者が同じ話をしているかを確かめるだけで、驚くほどの時間が過ぎていきます。どんなプロセスより効くのは信頼です。「ここが壊れています」と安心して言ってもらえない限り、問題を一番最後に知るのは自分になります。カレンダーは油断すると本当に予定で埋め尽くされてしまうので、考える時間とチームのための時間を守るのは終わりのない戦いです。そして、会社が何を達成しようとしているのかを理解していなければ、チームをまともな方向に向けることもできません。

肩書きが来る前の準備

繰り返し聞いたアドバイスで、自分でも保証できるのがこれです。肩書きをもらう前からリードを始めること。プロジェクトを回す、誰かのメンターになる、何かを立ち上げる。私自身、この1年ほどプロジェクトリードとしてやってきましたが、その経験がどんな本よりも効いています。とはいえ本も役に立ちます。Camille Fournierの “The Manager’s Path” はみんなが薦める一冊で、読んでみて理由がわかりました。技術力も磨き続けてください。アーキテクチャ論争はなくなりませんから。そして、すでに転身を経験したメンターを見つけること。後から見れば当たり前に思える失敗を、事前に避けさせてくれます。

トレードオフ

ものづくりの方向性への影響力は増えますが、自分の手で作ることはほとんどなくなります。それが気持ちいい日もあれば、コードが恋しくてたまらない日もあるはずです。経験者は口を揃えて「それが普通」と言います。半年後にまた聞いてください。

最近このことをよく考えるのは、自分自身がプロジェクトをリードする立場になって、ごまかしたくなる誘惑を実感しているからです。会議で質問されて、5人が答えを待っている場面での「わかりません」は、負けを認めるような気分になります。でも実際は逆で、たいていの場合それが一番強い一手です。ただし、次に何をするか、つまり誰に聞くのか、いつ答えを持ってくるのかを添えることが条件です。

ごまかしは必ずバレる

#

ソフトウェアの世界は変化が速すぎて、全部を頭に入れておける人はいません。そしてエンジニアは、知ったかぶりを驚くほど敏感に見抜きます。一度でも「知っているふり」を見破られると、チームはそれ以降、こちらの本当の答えまで割り引いて聞くようになります。逆に、知らないことを認めて、その穴をきちんと埋めに行くマネージャーの言葉は信頼されます。本物の答えかどうか、みんなちゃんと聞き分けているのです。

「わかりません」は答えではなく出発点

#

大事なのはその後です。「わかりません」で終わったら、ただの投げっぱなしです。いいマネージャーは、そこからより良い質問を組み立てます。「今使っているものと比べてどうか」「この前提が外れたら何が壊れるか」。そして、その質問を適切な人にぶつけます。どのチームにも、データベースに住んでいるような人や、フロントエンドの厄介なエッジケースを全部知っている人がいるものです。全部を自分で知っている必要はありません。誰が知っているかを把握して、実際に聞きに行けばいいのです。

仕事で「わかりません」を上手に伝える言い方

#

私が心がけているのは、「わかりません」で文を終わらせないことです。実際に口に出して使える言い方をいくつか挙げます。

• 「今の時点ではわかりません。木曜までに確認してお返事します」
• 「そこは私より佐藤さんのほうが詳しいので、聞いてみましょう」
• 「確証はないのですが、おそらくXだと思います。決める前にYだけ確認させてください」
• 「手元に数字がないので、会議のあとでチャンネルに共有しますね」
• 「申し訳ありません、私ではわかりかねますので、担当の者に確認してご連絡いたします」（社外やお客さま向け）

「勉強不足ですみません」と謝るところから入る必要もありません。「わかりません」は失礼なのでは、と気にする人もいますが、次の行動が添えてあれば失礼にはなりません。相手が本当に困るのは、何も前に進まない「さあ……」か、自信満々に答えたのに後で間違いだとわかる回答のほうです。面接でも同じで、知らないことは知らないと言ったうえで、どうやって調べるかを話せば、当てずっぽうの答えよりずっと多くが伝わります。

意思決定の質が上がる

#

ソフトウェアの意思決定は後々まで残ります。だからこそ、「ここは確信がある」「ここは推測だ」と正直に区別する価値があります。わからない部分を先に認めておけば、決めた後ではなく決める前に足りない情報を集められますし、反対意見のある人も声を上げやすくなります。それこそ、一番聞くべき声です。決めたら理由を説明する。間違っていたら、それも認める。マネージャーが自分の失敗を認められないチームほど、正直さが早く失われていく場所はありません。

難しい話ではありません。質問をして、自分より詳しい人の話を聞いて（自分より詳しい人は必ずいます）、推測で話すときは推測だと言う。それだけです。「わかりませんが、調べてみましょう」という一言は、ごまかして切り抜けたどんな答えよりも、私の信用を積み上げてくれました。

私はその線を、身をもって探ってきました。マネジメントの訓練を受けたわけではなく、開発者として働くうちにプロジェクトチームを率いる立場になったタイプなので、以下に書くことはだいたい、一度少し間違えてから学んだことです。

リーダーシップにおける共感とは

#

リーダーシップにおける共感とは、メンバーが実際にどういう状態にあるかを理解し、意思決定をするとき、フィードバックを伝えるとき、チームの進め方を決めるときに、それをきちんと重みとして扱うことです。全員に同意することでも、会議で感じよく振る舞うことでもありません。相手の事情を十分に理解したうえで「ノー」と言うことは、普通にできます。自分の事情が考慮されていると分かると、人は肩の力が抜けて、早めに声を上げるようになり、仕事も目に見えて良くなります。この部分に関しては、世間の定番アドバイスは正しいと思います。

足りなくても、多すぎてもダメ

#

よく警告されるのは、人をリソースとしか見ない冷たいマネージャーの失敗です。これは実在します。メンバーの生活で起きていることを無視すれば、みんな口を閉ざし、士気は下がり、問題は何か月も経ってから発覚します。

一方、誰も警告してくれないのが、その逆の失敗です。何もかも受け入れていると、境界線が曖昧になります。締め切りはただの目安になります。そして、黙って水準を守っている人たちが、守らなくても許される人たちの分をかぶることに、不満を募らせていきます。私自身、その場では優しさのつもりで譲りすぎたことがあります。チームの他のメンバーにとっては、まったく優しくありませんでした。

共感がうまく働く例、行き過ぎた例

#

並べてみると違いがよくわかります。ルールというより、私が目指している形くらいに読んでください。

行き過ぎた例には共通点があります。その場では優しく感じられて、実はツケを後回しにするか、誰か別の人に回しているのです。

1on1がほとんどの仕事をしてくれる

#

私がバランスを保てているのは、何か哲学があるからではありません。カレンダーの定期予定のおかげです。定期的な1on1があれば、小さな問題は小さいうちに表に出てきます。ある日突然、退職願というかたちでまとめて届くのではなく。

私の1on1は、毎回だいたい同じことを聞きます。何に詰まっているか。最近うまくいったことは何か。チームの連携はどうか。今後どう成長したいか。そして、私が変えるべきことはないか。

いちばん役に立っている質問は、ごく地味なものです。「タスクを進めるうえで、私やチームから必要なものはありますか？」。ありふれた質問に聞こえますが、そうではありません。「私も解決に関わるつもりだ」という意思表示になりますし、返ってくる答えはほぼ毎回、実際に対処できる具体的なことです。誰かへのアクセスだったり、宙に浮いたままの決定だったり、1時間のペアプロだったり。

「ノー」を伝えるときこそ正直に

#

1on1をやれば要望が出てきます。全部には応えられません。応えられない要望をどう扱うかで、信頼は築かれもすれば、失われもします。

私のやり方はこうです。まず要望を真剣に受け止めて、そう伝える。今は実現できない理由を説明する。部分的な代替案があれば出す。いつ再検討するかを言う。そして結論が変わっていなくても、必ずその話に戻ってくる。

これで「ノー」を伝えるのが楽しくなるわけではありません。ただ、理由付きの正直な「ノー」は、二度と話題に上らない曖昧な「検討します」よりも、はるかにまともに受け止めてもらえます。

私がたどり着いた公式は、せいぜいこの程度です。メンバーの状態を本気で気にかける。仕事に必要なことは正直に言う。そして、どちらかに寄りすぎたことに気づけるくらいの頻度で、話す機会を持つ。

ここまでが短いバージョンです。以下に長いバージョンを書くのは、フィードバックの場で同じ失敗を、認めたくないほど何度も繰り返してきたからです。こちらが何か指摘すると、相手の肩にぐっと力が入り、その瞬間からお互い相手の話をちゃんと聞けなくなる。そういうパターンです。

そもそも、なぜ人は防御的になるのか

#

防御的な反応は、頑固さとは違います。少なくとも、頑固さから始まることはめったにありません。脅かされたと感じたときの反応で、フィードバックは私たちが思っている以上に人を脅かします。表向きはプルリクエストや守れなかった締め切りの話をしていても、相手に聞こえているのは「自分はこの仕事に向いているのか」「このチームにいていいのか」「何か月も前から内心そう思われていたのか」という問いです。

いったんそう感じると、相手の注意はこちらの言いたいことではなく、自分を守ることに向かいます。強く言い返せば、その脅威が本物だと裏付けるだけです。なので、以下に書くうまくいく方法の大半は、まず場の緊張を下げて、それから中身に入る、という順番の話です。

もうひとつ覚えておくといいのは、最初から傷を負った状態でこういう会話に臨む人もいる、ということです。批判するときしか口を開かない上司がいた、ミスをすると干される職場だった、など。その過去を一回の面談でどうにかすることはできません。ただ、軽い一言に不釣り合いなほど大きな反応が返ってくることがある理由は、これで説明がつきます。

話す前に

#

フィードバックの会話は、たいてい始まる前に勝負がついています。昔はやっていなかったけれど、今は気をつけていることがいくつかあります。

話題はひとつに絞ります。5つも溜め込んでいたら、相手にはフィードバックではなく起訴状に聞こえます。残りの4つは後回しで構いませんし、結局ひとつ目の症状だった、ということもよくあります。

早めに伝えます。6週間前の出来事についてのフィードバックは「なんで今さら言うんですか？」と受け取られます。もっともな疑問で、うまい答えはありません。出来事から1〜2日後くらいがちょうどいいと思っています。記憶が新しいうちで、かつお互いの頭が冷えている頃です。

人のいないところで伝え、できればチャットは避けます。文字だとトーンが抜け落ちますし、身構えている読み手は、その抜けたトーンを最悪のバージョンで補ってしまいます。チームがリモートだったりタイムゾーンをまたいでいたりして、どうしても文章で伝えるしかないときは、短くまとめて通話を提案します。

そして、自分の状態を確認します。こちらが苛立っていると、どんな言葉を選んでも、相手は最初の一文で察します。苛立ちが収まるまで待っていればずっとうまくいったはずのフィードバックが、いくつも思い当たります。

実際に何と言うか

#

私が何度も立ち戻る型は、一般に「状況・行動・影響」（SBI）と呼ばれるものです。いつ起きたか、相手が何をしたか、それが何を引き起こしたか。ポイントは、どの部分も観察できる事実だということです。相手がどういう人間かについては何も言わず、何が起きたかだけを話します。

実際の違いを見てみます。たとえば、ある開発者が金曜の午後にレビューを待たずに変更をマージして、週末に決済が動かなくなったとします。

相手が壁を作るバージョン：「いつも急いで出しますよね。もっと慎重になってください」

まだ望みがあるバージョン：「金曜に決済まわりの変更がレビューなしで入って、土曜に数時間、決済が止まっていました。何があったのか知りたいんです。不注意だったとは思っていないので」

後者は、出来事をひとつに絞り、それで何が失われたかを率直に伝え、最後に相手の善意を前提にしています。いちばんダメージが大きいのは「いつも」「一度も〜ない」という言葉です。一度の出来事を人格の評価に変えてしまいますし、相手はすぐさま、こちらが間違っていることを示す反例を思い浮かべます。

観察を自分のものとして言うことも心がけています。「〜に気づきました」「〜が気になっています」と言えば、これはあくまで私の見方で、私の側から差し出しているものだと正直に示せますし、私が何かを見落としている余地も残せます。実際、見落としていることはよくあります。

それから、話すのをやめて聞きます。「そちらからはどう見えていましたか？」たいていは、私の知らなかった事情があります。誰か別の人が決めた締め切りだったとか、レビュアーが病欠していたとか。そういう事情がなかったとしても、この質問をすれば、これは判決ではなく会話なんだと相手に伝わります。

フィードバックは、次の一手を添えるとずっと受け取りやすくなります。問題点を並べるのではなく、「次からは、〜してみませんか」。その次の一手が相手の口から出てくれば、なお良いです。

それでも反発されたら

#

全部正しくやっても、抵抗されることはあります。反発にはいくつか見分けのつく型があって、それぞれ少しずつ違う対応が要ります。

いちばん多いのは否定です。「そんなことはありませんでした」。ここで言い争わないこと。コミットやメッセージ、日付など、お互いに確認できるものに戻って、自分が何を見落としているのかを聞きます。事実そのものに本当に食い違いがあるなら、「お互いもう一度確認して、明日続きを話しましょう」で構いません。

次に、話をそらすパターン。「でも要件がころころ変わったので」「〇〇さんもやってますよ」。たいてい一理あるので、退けずに認めます。「それはその通りで、要件の問題も直さないといけませんね」。そのうえで、そっと話を戻します。「それとは別に、レビューの手順について話したいんです」

逆襲、たとえば「そっちだってしょっちゅうレビューなしでマージしてるじゃないですか」は、同じ調子で返したくなるのをこらえるのがいちばん難しいパターンです。ひと呼吸置きましょう。相手の言う通りなら、そう認めます。それが場の温度を下げるいちばんの近道ですし、相手に求めているオープンさを自分が先に示したことにもなります。そのうえで、元の話に戻ります。

心を閉ざすパターン、つまり黙り込んだり「はいはい、おっしゃる通りです」と言ったりするのは、同意に見えて同意ではありません。私はそれを柔らかく言葉にします。「あまりうまく伝わらなかったみたいですね。それで大丈夫です」という感じで、続きはまた後でと提案します。引いてしまった人に無理やり答えさせても、返ってくるのは本心ではない答えだけです。

謝りすぎ（「本当にダメですね、すみません」）も防御反応で、向きが内側になっているだけです。先に自分で自分を批判することで、身を守っているわけです。これはあくまで特定のひとつの件で、仕事ぶり全体の話ではないと安心してもらい、これからどうするかの話に移ります。

どのパターンでも、私が守ろうとしているルールはひとつ、相手のテンションに合わせないことです。相手が防御的になると、こちらもつい防御的になりがちですが、それをやると会話は確実に沈みます。自分が落ち着いていれば、場の温度はたいてい自然に下がっていきます。「聞いていて、もどかしいですよね」と相手の気持ちを口に出すのも効きます。緊張がないふりをするより、ずっといいです。

引き際を知る

#

どれも効かず、相手の壁が崩れないこともあります。そこで押しても何も得られません。会話をいったん置いて、落ち着いた頃に、1〜2日空けて仕切り直せばいいんです。フィードバックの中身は明日になっても変わりませんし、ひと晩寝かせると、人はずっと冷静に振り返れるものです。これまでのフォローアップの会話でいちばん良かったもののいくつかは、相手の「この前言われたこと、考えてみたんですけど」という一言から始まりました。

これを身につけるのに、一番時間がかかりました。

話したあとで

#

その後の1週間に起きることは、会話そのものと同じくらい大事です。相手が行動を変えたら、気づいたことを、はっきり、早めに伝えます。そうすれば、私からのフィードバックが悪い知らせばかりではないとわかってもらえますし、次の会話もしやすくなります。

それから、タイミングが合えば、フィードバックがどう受け止められたかを聞きます。「今の伝え方はフェアでしたか？」と聞けば会話のバランスが取れますし、相手に期待しているオープンさを自分から示せます。マネジメントの立場になってからはこれを習慣にしていて、自分の頭の中では明確だったのに口に出したらそうでもなかった、というケースを何度か拾えました。

要するに

#

本題に入る前に、まず脅威を下げること。話題はひとつに絞り、人のいないところで早めに切り出し、相手の人柄ではなく行動とその影響を伝え、解決策を出す前に相手の言い分を聞きます。反発されても同じ調子で返さないこと。気持ちを受け止め、事実に戻り、いったん止めて別の日に続ける覚悟を持っておきます。そして、フォローアップを忘れずに。信頼が築かれるのは、会話のあとの会話だからです。