道中はチーフ・オブ・スタッフの隣に座って、「趣味の見つけ方」について話していました。忙しい毎日の中で、一人でも楽しめる趣味を見つけるのは案外難しいよね、という話になり、そこから大学時代の話へ。意外なことに、彼女はもともとアーティストで、3Dアートを作るのが好きだったそうです。ただ、作品を作り続けなければというプレッシャーが自分の生活には合わなかったのだとか。なので「じゃあ、うちのちょっと殺風景なオフィスに一作品どうですか」と冗談で提案しておきました。笑

カフェに着くと、全員が座れる大きなテーブルがすぐに見つかりました。お互いにとって大事なことをじっくり話せて、本当に良い時間でした。

みんなお互いの意見をきちんと尊重していて、CEOとモデレーターが上手に進行してくれたおかげで、次のアクティビティにもちゃんと間に合いました。

次はウイスキー蒸留所の見学です！ウイスキー好きの私にとっては、人よりちょっとだけ詳しい製造とテイスティングの知識を披露できる絶好の機会でした。ガイドさんは英語と韓国語の二本立てで説明するというチャレンジをしてくれました。まずは小麦を槽に入れて浸し、糖分を引き出す工程を見学。続いて、数日ほど発酵させた状態のものも見せてもらいました。最後は蒸留器です。「巨大なしずく形のチョコみたい」と紹介されていましたが、確かにその通り。中は30度近くあったので、「外の貯蔵庫を見に行きましょう」とガイドさんが言ってくれたときは正直ホッとしました。

貯蔵庫には、いろいろな種類の木の樽が天井まで積み上がっていました。樽の口に「コチュジャン」と書かれたものもあり、いかにも韓国らしいフュージョンです。樽から直接ウイスキーを試飲させてもらえたのですが、アルコール度数はなんと約60%！全員、喉が焼けるようでした。

締めくくりには、熟成させた樽の異なるウイスキー、つまり最終製品の飲み比べをさせてもらいました。ジンも試したのですが、これはちょっと選択ミスだったかもしれません。どうにもキノコに似た風味が強くて…。

その後はバンでソウルに戻り、バーに寄ってみんなで静かに一杯やってから解散しました。一日でこれだけ盛りだくさんだと、楽しみながらお互いのことをずいぶん知れた気がします！

韓国で職場を探している方がいれば、ぜひ私に声をかけてください！

今月からエンジニアリングチームのマネージャーになりました。エンジニアからエンジニアリングマネージャーになると何が変わるのかを書いてから、数週間後のことです。誰も事前に教えてくれなかったのは、何もかもが緊急に見えるということです。新しいチーム、新しい会社、そして自分が来る前から積み上がっていた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』です。前者はチームの規模、計画、組織設計といった仕組みの側を扱い、後者はチームを知る、期待値をはっきりさせる、きちんと伝えるといった人の側を扱った、短く実践的な本です。

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

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

ごまかしは必ずバレる

#

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

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

#

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

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

#

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

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

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

意思決定の質が上がる

#

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

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

それでもオープンが基本である理由

#

透明性を勧める定番の論拠は、どれも本当です。実際にその通りになる場面を何度も見てきました。決定の背景にある理由が分かれば、たとえ気に入らない決定でも、納得はしてもらえます。私と同じ情報を持っていれば、メンバーは私の指示を待たずに良い判断を下せます。そして、自分に関わる話が自分の知らないところで進んでいたと後から知って、嬉しい人はいません。

生の情報をそのまま流すと何が起きるか

#

失敗のパターンは、だいたい3つです。

量。中途半端な情報まで全部転送していると、本当に大事な話が埋もれます。そのうち誰も読まなくなります。

文脈。背景抜きの生の情報は混乱を生みます。「ロードマップを見直しています」という一文は、説明付きならただの近況報告ですが、説明なしだとずっと不穏に聞こえます。

タイミング。まだ決まっていないことを共有すると、チームは1週間、実際には検討すらされていない結末について憶測を巡らせることになります。生煮えのニュースは、最終決定そのものより多くのエネルギーを食いつぶすことがあります。

待つことは隠すことではない

#

共有のタイミングを計るというと、操作的に聞こえます。でも誠実にやれば、むしろ逆です。理解に必要な文脈と一緒にニュースが届くようにする、ということですから。悪い知らせは、対応策とセットで伝えたほうが受け止めやすくなります。良い知らせは、金曜夕方の連絡ラッシュに埋もれないほうがちゃんと届きます。

ただし、待つことにはコストがあり、それは膨らんでいきます。情報を抱え込みすぎると、みんな何となく気づきます。空白は噂話が埋めますし、噂は決まって現実より悪い内容になります。そして、いつも最後に知らされる人は、それを自分の評価だと受け取ります。まあ、実際そうであることが多いのですが。

今の判断基準

#

センシティブなことを共有する（あるいは保留する）前に、いくつか自問するようにしています。これはチームの仕事に必要な情報か、それとも自分が楽になりたいだけか。文脈をきちんと説明できる段階か、それとも断片を投げつけるだけになるか。どう受け止められそうか。当然出てくる質問に答えられる準備はあるか。

そのうえで、どちらに転んでも同じことをします。情報には文脈を添える。後から質問しやすい空気を作る。そして伝わり方を観察して、次の判断の精度を上げる。欲しい情報量は人によって違いますし、それは見て、聞いてみないと分かりません。

基本はオープン。文脈を添える。送信する前に、どう受け止められるか1分だけ考える。これで、今まで出会った場面のほとんどはカバーできています。

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

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

#

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

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

#

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

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

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

#

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

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

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

#

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

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

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

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

#

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

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

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

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

これまで関わったプロジェクトで、いちばん遅かったのはコードではありません。行列です。マネージャー一人のカレンダーの前に意思決定が積み上がり、三日後にやっと届く「OK」を待っている。非同期コミュニケーションと自律的なチームが定番の解決策で、私も支持派ですが、この移行の正体は、ツールの問題の顔をした信頼の問題です。

そもそも、なぜ何にでも承認が要るのか

#

承認文化がどこから来るのかは、公平に見ておく価値があります。コントロールは精度のように感じられるものです。すべての決定がマネージャーの机を通れば、何も脇道に逸れない、というわけです。まずい判断はプロジェクトだけでなくマネージャー自身の評判も傷つけるので、恐れがかなりの部分を動かしています。チームに判断できるだけの経験があるのか、本気で疑っているケースもあります。そして、単なる残滓のこともある。組織図が昔からそう動いてきたから、今日もそう動いているだけ、という。

この四つの理由のうち、チームの側の話は一つだけです。残りは全部マネージャーの側の話です。

自律に本当に必要なもの

#

方向合わせのない自律は、士気の高い混乱にすぎません。メンバーが目標を本当に理解していれば、それぞれの独立した判断はだいたい同じ方向を向きます。仕掛けは実質これだけです。トレーニングも効きます。装備の整った人は、熱意だけの人より信頼しやすいからです。そして境界線は残すこと。経営側に留めるべき決定は実際にありますし、それがどれなのかを口に出しておくと、最悪のサプライズを防げます。あとはフィードバックループを回して、避けられないミスを「証拠」ではなく「授業料」として扱うことです。

信頼がすでに傷んでいる場合——承認文化から抜け出そうとするチームでは、たいてい双方向に傷んでいます——近道はありません。オープンな場で問題に名前を付け、まず経営側が自分たちの分のミスを認め、それから何か月も退屈なくらい一貫した行動を続ける。役割の明確化と定期的な対話のほうが、派手な仕掛けよりよほど修復に効きます。

非同期の部分こそ簡単

#

ツールの話は手短に。SlackでもMicrosoft Teamsでも十分です。本当の仕事はドキュメンテーションです。誰も同じ部屋、同じタイムゾーンにいない以上、書かれた決定がチームの記憶になります。応答の基準も決めておきましょう。非同期がいつの間にか無応答にならないように。「一日以内」は「いつか」に勝りますし、この基準は、誰がどの報告を受け取るかと一緒に、チームのコミュニケーション計画に書いておくべきものです。それから、良い非同期の報告の書き方はちゃんと教えること。判断に足る文脈、求める決定、期限。生まれつき書ける人はいません。たとえばこんな感じです。

木曜までに判断をお願いします：決済のリトライについて
現在、カード決済が失敗すると24時間後に1回だけリトライしています。そして「注文はどうなっていますか？」が、今いちばん多い問い合わせです。
案A：24時間以内に3回リトライする（作業は半日ほど）。案B：リトライはそのままにして、顧客にメールで知らせる。
私のおすすめはAです。詳細と数字はリンク先のドキュメントにまとめています。
木曜17時までに異論がなければ、Aで進めます。

これなら朝7時でも夜11時でも、どのタイムゾーンにいても読めますし、会議を開かずに返事ができます。

Slackの導入は午後一つで終わります。信頼のほうは何か月もかかり、そしてこの取り組み全体の成否を決めるのはそちらです。目標を明確にして、ミスの代償をキャリアではなく教訓にする。そこまでできれば、非同期の部分はだいたい勝手にうまくいきます。

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

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

#

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

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

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

話す前に

#

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

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

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

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

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

実際に何と言うか

#

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

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

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

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

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

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

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

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

それでも反発されたら

#

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

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

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

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

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

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

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

引き際を知る

#

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

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

話したあとで

#

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

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

要するに

#

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