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

ここに至るまで

#

入口は修士課程でした。ニュージーランドのワイカト大学で学士を取り、通信会社でネットワーク運用の仕事を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の習慣ではカバーできない形で重要になります。

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

先にバイアスを白状しておくと、私のキャリアはほとんど小さな会社で、いまも小さな会社で開発チームを率いています。それでも、学生に「どっちのインターンにすべきですか」と聞かれたら、ほぼ毎回、小さくて泥くさいほうを勧めています。

スタートアップと大企業のインターンを比べると

#

並べるとこうなります。ここから先は、その長いバージョンです。

仕事が本物です

#

社員10人の会社には、つまらない仕事を押し付ける相手がいません。インターンが機能をリリースし、顧客と話し、企画会議にも参加します。プロダクトもマーケもオペレーションも触ることになり、同じ週に全部やる日もあります。ごちゃごちゃしていますが、その分だけ成長は速いです。

さらに良いのは、自分の作ったものが実際に世に出ることです。プロダクトの一部を指さして「これ、自分がやりました」と言える。何かを作って、人が使っているのを見る。このループはクセになりますし、大企業がインターンにここまで触らせてくれることは、まずありません。

実利もあります。成長中のスタートアップは常に人が足りず、創業者は「すでに一緒に働いたことのある人」を採りたがるものです。良いインターンシップは、気づけば内定に化けていることがよくあります。

創業者を間近で観察できます

#

大企業では、CEOに一度も会わないまま終わることもあります。スタートアップなら、たぶん隣に座っています。どうやって意思決定するのか、プレッシャーをどうさばくのか、全部が緊急に見えるときに何を優先するのか。教科書には載っていないものを、毎日見られます。

フラットな組織は両刃でもあります。リリースまでの間に三段階の承認は挟まらないので、何にどう取り組むかについて本当に発言権があります。その代わり、誰も手取り足取り教えてはくれません。この環境で伸びる人もいれば、怖くなる人もいます。申し込む前に、自分がどちらかを知っておいて損はないです。

正直なデメリット

#

給料はたいてい安いです。体制は最小限。専任のメンターはいないかもしれませんし、会社そのものが2年後に存在しない可能性もあります。そこをごまかすつもりはありません。それでも、ビジネスが実際にどう回っているのかを内側から学びたいなら、これより速い方法を私はまだ知りません。

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

実際に何が変わるのか

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

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

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

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

大事になりそうなスキル

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

肩書きが来る前の準備

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

トレードオフ

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