コーヒーチャットは30〜45分の気軽な会話です。カフェでもビデオ通話でも構いません。ホワイトボードなし、面接官のパネルなし、ひっかけ問題なし。こちらは何をなぜ作っているかを話し、相手はいま何をしていて次に何を望むかを話す。それだけで、もっと深い話をする意味があるかどうかが双方にわかります。採用は選抜の問題というよりマッチングの問題で、マッチングに必要な情報を交換する手段として、これより速いものを知りません。

なぜ続けているのか

#

このチャットを「採用活動」だと考えるのは、もうやめました。ただの会話です。そして、そのうちのいくつかが、忘れた頃に採用につながります。相手の状況が変わった18ヶ月後に、ということもあります。良い採用を安定して生むパイプラインは、求人広告ではなく、こういう関係の積み重ねでできています。

職務記述書の問題も解決してくれます。JDはどうしても一般的な書き方になります。コーヒーを挟めば、候補者は本当に知りたいことを聞けます。最初の6ヶ月で何ができれば成功なのか。誰と働くことになるのか。チームがいま抱えている一番厄介な技術課題は何か。正直な答えを聞いた人は、自分に合うかどうかを自分で正しく判断してくれます。

それから、チャットは文化を「説明」する代わりに「見せて」くれます。準備してきたか、本気で興味を持っているか、相手の時間を尊重しているか。どんな採用ページよりも雄弁です。これは逆方向にも働きます。肩の力が抜けた会話での振る舞いは、練習済みの面接よりずっと多くのことを教えてくれます。

特に効くのは、転職活動をしていない人に声をかけるとき、正式な選考の前に、紹介の下地をつくっておくとき、そしてキャリアの転機（現場のエンジニアからマネジメントへ、スタートアップから大企業へ、あるいはその逆）を迷っている人と話すとき。人材の取り合いになっている市場では、欲しい人のほとんどがこのどれかに当てはまります。

私の進め方

#

最初のメッセージがすべてを決めます。テンプレのアウトリーチは削除されて終わりです。下調べをして、意図を正直に書きます。

「こんにちは、サラさん。QConでの分散システムのご講演と、イベントソーシングについてのブログ記事を拝見しました。[会社]でも、決済インフラをスケールさせる中で同じような課題に取り組んでいます。30分ほどコーヒーチャットでお話しできないでしょうか？面接ではありません。サラさんのお考えを伺いつつ、私たちの取り組みもご紹介できればと思っています。」

これが機能するのは、具体的で、意図を隠さず、時間をくださいと頼むだけでなく「面白い問題について話す機会」という価値を差し出しているからです。あとは相手の手間を減らすこと。候補日時をいくつか出し、相手に便利な場所（オンラインならダウンロード不要のビデオツール）を選び、詳細を書いたカレンダー招待を送って、相手に何も推測させないことです。

会話そのものは、ゆるい型があれば十分です。最初の数分は本物の雑談と、なぜ声をかけたのかの説明。次に相手の話。いまの仕事、楽しいこと、うんざりしていること、次に望むもの。ここでは話すより聞くのが仕事です。それから自分たちの話。ミッションと、チームが実際に抱えている課題を、大変な部分も含めて話します。候補者は率直さを尊重しますし、売り込みの匂いには敏感です。一番価値があるのは終盤のオープンな時間で、「どういう条件が揃ったら転職を考えますか」を一緒に探ります。最後は次のステップを明確に。「また連絡を取り合いましょう」だけでも構いません。

チャットの後は、24時間以内に、会話の中の具体的な何かに触れた短いお礼を送ります。約束したもの（紹介でもリンクでも）は素早く渡します。文化が本当に表れるのは、この地味な後始末です。

継続的にやるなら、話した相手を簡単なスプレッドシートで管理して、募集がなくてもたまに連絡してみてください。マネージャー専用の活動にする必要もありません。エンジニアが自分のネットワークのすごい人とコーヒーを飲む——良いリファラルはたいていそこから始まります。

時間を割く価値のある質問

#

私がよく聞くもの：

• 「最近取り組んだ中で一番面白かった問題は何ですか？」
• 「次の職場では何が変わってほしいですか？」
• 「どんな学び方が合っていますか？プロとしてどう成長していきたいですか？」
• 「フィットするかどうか判断するために、聞いておきたいことはありますか？」

自分が候補者側だったら聞くもの：

• 「チームがいま直面している一番大きな課題は何ですか？」
• 「このロールの成功はどう測られますか？」
• 「昇進への道筋はどうなっていますか？」
• 「なぜこの会社に入ったんですか？なぜ残っているんですか？」
• 「ここで働くことについて、私が聞いたら意外に思うことはありますか？」

コーヒーチャットに誘われたら

#

「コーヒーチャットとは」と調べている人の多くは、私とはテーブルの反対側にいるはずです。誰かにコーヒーチャットに誘われて、どんな場なのかを知っておきたい。そういう方に向けて、誘う側の立場から言えることを書いておきます。

まず、面接ではありません。誰も点数をつけていませんし、試験もないので、受け答えを準備しておく必要はありません。とはいえ第一印象であることに変わりはないので、友だちの友だちに会う感覚ではなく、将来の同僚に会うつもりで臨んでください。面接との違いは、遠慮なく好奇心を出していいことです。答えるのと同じくらい質問することが、むしろ期待されています。

服装は、その会社で普段働くときに着るような格好で大丈夫です。わからなければ、オフィスカジュアルにしておけばまず間違いありません。ビデオ通話なら、カメラはオンにして静かな部屋を確保しましょう。何を着るかより、そちらのほうがずっと大事です。

準備は30分もあれば足ります。その会社が何を作っているのか、相手が書いたものや作ったものに目を通しておきましょう。いま何をしていて、次に何をしたいのかを2分で話せるようにしておくこと。この質問は必ず来ます。自分からの質問も2つか3つ用意しておきましょう。とっかかりとしては、上のリストで十分です。

話題は、自分の仕事のこと、その仕事の何が楽しいのか、相手の仕事のどこに興味があるのか。給与の話は、相手から出ない限り後回しにしましょう。具体的なポジションを想定しているのか、もしそうなら選考はどう進むのかを聞くのは、まったく問題ありません。

支払いは、ふつう誘った側が持ちます。自分も払うと申し出るのはいいですが、押し問答にはしないこと。そして1日以内に、実際に話した内容に触れた短いお礼を送れば、それだけでほとんどの人より一歩先を行っています。

自分からコーヒーチャットをお願いしたいなら、遠慮せず頼んでみてください。メッセージは短く、なぜその人なのかを書いて、引き受けやすくしておくこと。たとえば「チームで取り組まれている新しい検索機能のお話を、ずっと興味深く拝見しています。私はプラットフォームエンジニアリングの方向に進みたいと考えているのですが、この数週間のどこかで30分ほど、コーヒーかオンラインでお話を伺えないでしょうか。日時はそちらのご都合に合わせます」という具合です。ここまで具体的なお願いなら、たいていの人は引き受けてくれます。

台無しにする方法

#

一番速いのは、こっそり面接に変えることです。技術スキルを試したり行動面接の質問を滑り込ませたりした瞬間、暗黙の約束は壊れます。それは正式な選考に取っておきましょう。次に多いのが売り込みすぎ。長く定着してくれるのは、大変な部分まで見えたうえで入ってきた人です。準備せずに現れるのも、終わった後に音信不通になるのも、静かにダメージを与えます。1回のチャットの印象が、その人が自分のネットワークにあなたの会社をどう語るかを決めるからです。

こちら側から見た危険信号は、何にも好奇心を示さない候補者、完全に取引めいた会話、過去の職場を全部同じ恨み口調で語る人。候補者側もリストを持っておくべきです。仕事の意義を説明できない担当者、離職率や会社の方向性についてのはぐらかし、あなたを理解するより売り込むことに熱心な相手。

すべてのチャットがどこかにつながるわけではありません。むしろ、ほとんどはつながりません。それでいいんです。大事なのは、次に重要なポジションを埋めるとき、白紙の求人広告からではなく、積み上がった本物の会話から始められること。職務記述書ではなく、コーヒーのお誘いを送りましょう。

さらに読む

#

このサイトの関連記事：

• 開発者採用の面接でSTARメソッドを使う - チャットが正式な面接プロセスに進んだときのために
• 新任エンジニアリングマネージャーとして、まず取り組んでいる3つのこと - チームをうまく回すものは何か。マッチングで見るべきものでもあります
• スタートアップでインターンすべき理由 - スタートアップ行きを迷っている人と話すときの背景として

外部リソース：

• First Round Review：エンジニア採用 - 経験豊富なオペレーターによるスタートアップ採用ガイド
• Lara Hoganの「最初の1on1のための質問」 - 1on1向けですが、コーヒーチャットでも見事に機能します
• Patrick McKenzieの給与交渉について - 候補者側の視点を知るために
• Who: 採用のAメソッド - Geoff SmartとRandy Streetによる体系的な採用フレームワーク
• Harvard Business Review: 採用 - 人材獲得についての研究に基づいた記事

Alanが会議を見限った理由

#

出発点は誰にでも覚えがあるはずです。誰も準備してこない、開始は遅れる、そして声の大きい人が正しかろうが間違っていようが議論を制する。1時間後には入室前より頭が混乱していて、鎮痛剤の残りを気にしている。

Alanもまず会議の改善を試みました。最大15分、明確なアジェンダ、必ず決定を出す。それでもダメでした。議論は脱線し、何が話されたか誰も覚えておらず、欠席者やリモートの人は蚊帳の外。それで、丸ごと文章に移すことにしたそうです。

彼らの主張には頷けるものがあります。書くとなると立ち止まって考えざるを得ないので、議論はより丁寧に、根拠のあるものになる。すべてが記録に残り、うろ覚えに頼らなくて済む。弁論大会でもなくなる。しかもフォーラムは全社に公開されているので、たまたま会議室にいた人だけでなく、誰でも議論に参加できます。

社内フォーラムとしてのGitHub

#

フォーラムの正体はGitHubです。本来コードレビューのためのプラットフォームを、Alanは堂々と転用しました。仕組みは拍子抜けするほど簡単です。

1. GitHubのアカウントを作る。
2. コードの入っていないプライベートリポジトリを作る（Alanでは「Topics」という名前）。
3. 会話を分類するためのラベル体系を用意する。
4. Issuesタブを使う。openなissueは進行中の議論、closedは決定済み。

彼らのissueは17,000件を超えました。開かれずに済んだ会議の数と考えると相当なものです。そして私が一番惹かれるのはここですが、すべての決定について「なぜそうなったか」を検索できる履歴が残ります。過去の決定を蒸し返したくなったら、前回どの議論が勝ったのかを先に読めるわけです。

いつissueを開くか

#

すべての決定がissueに値するわけではありません。彼らのフィルターは4つの質問です。誰が影響を受けるか？どれくらい可逆的か？どれくらい急ぎか？決めるためにもっと文脈が必要か？

大まかには、影響が大きく後戻りしにくい決定はフォーラムへ、それ以外はSlackで済ませます。ワンウェイ・ツーウェイの区別も使っています。ワンウェイの決定（撤回に大きなコストや労力がかかるもの。例として挙がっているのは料金の値上げ）はフルコースの文章化。ツーウェイの決定（安く取り消せて、失敗しても多少エネルギーを失うだけのもの）には儀式は不要です。

LOCI：誰が何をするか

#

すべての議論に、LOCIモデル（Lead、Owner、Consulted、Informed）で役割を割り当てます。

Leadは決定の成否に責任を持ち、決定の背景がチームに正しく理解されるようにします。冒頭で自分がどこまで関与したいかを表明し、あとはOwnerを信頼してチームの成果に責任を持ち、強く反対のときだけ口を出します。Leadは議論ごとに1人だけ。

Ownerは最終決定を下し、プロジェクトを前に進めます。貢献者に情報が行き渡り、期限内に意見が集まるようにし、問題を調査し、issueを開いて閉じ、決定を共有します。自分で解決できない壁に当たったらLeadに相談します。Ownerも決定ごとに1人。

Consultedは、トレードオフの判断に本当に意見が必要な人たちです。期限内の貢献が義務で、「追加することはありません」の一言でも構いません。決定が大きく間違っていると思ったら警鐘を鳴らし、最悪の場合はLeadにエスカレーションします。Alanはこの人数を6人程度までに抑えています。それ以上はスケジュールが犠牲になるからです。

Informedは、たいてい決定後に知らされるだけの人たちです。コミュニケーションは一方通行で、何の貢献も期待されません。誰に知らせるかは、影響範囲を考えてOwnerが決めます。

ここまでは決定ひとつ単位の話です。プロジェクト全体については、同じことをプロジェクトのコミュニケーション計画として一度まとめておきます。誰が何を、どのくらいの頻度で、誰から伝えられるべきかを書いた表です。

issueの解剖図

#

どのissueも同じテンプレートに従います。思考が研ぎ澄まされるうえ、ジュニアメンバーへの「問題の分解の仕方」の教材にもなっています。

• Scope - 議論の「なぜ」。地味に効くのが「このissueは〜については扱わない」の一文
• Context & materials - 過去の議論や資料へのリンク
• LOCI - 誰がLead、Owner、Consulted、Informedか
• 期限 - 貢献の締め切り、issueを閉じる日、解決策が必要になる日
• 解決策の提案 - 推す案をひとつ、または選択肢をいくつか
• 質問 - 特定の人に向けて、特定の仮定を確認・反証するための質問。issueを「海に流すボトルレター」にしないための工夫です

議論を停滞させないための書き方のルール

#

文章の議論も、口頭と同じくらいダラダラと長引き得ます。だからルールがあります。まず簡潔に。彼らはボワローの「よく構想されたものは明晰に語られる」を引いています。シンプルに書けないなら、まだ自分の主張に確信がない証拠です。それから、書いたものすべてに「So what?」テストをかけること。コメントの含意が自明でないなら、はっきり書き添えます。

Ownerにとっては、開いた後の運営も同じくらい重要です。議論を「100万ドルの質問」、つまり本当に重要なたったひとつの争点に向け続け、細部の海で迷子にさせない。合意できた点とまだ開いている点を定期的に整理して見せる。そしてSlackでの催促は最後の手段。貢献の遅延か、本当の緊急時に限ります。

Ownerは会話を前に進めないコメントを非表示にすることもあります。また、見出し、脚注、表、キーボードショートカットといったGitHubの書式機能は全員が使いこなす前提です。文章では、中身と同じくらい見た目が物を言うからです。

コンセンサスなし、傍観者なし

#

この仕組みが「委員会による決定」に堕ちないよう、2つの歯止めがあります。

1つ目。Ownerは、Alanいわく「啓蒙専制君主」として決定します。アイデアを調査し、リスクを測り、同僚に質問はするけれど、コンセンサスは求めないし、言われたことを全部実装する義務もない。Alanは「うちは民主主義ではない」と言い切っています。全員が株主であり、チームや個人よりも会社の利益を優先する。とはいえ、孤立した拙速な決定を望んでいるわけでもありません。Ownerが「この賭けで行ける」とそれなりに確信したら決めて、みんなで試し、影響が見えてきたら振り返って次に活かします。

2つ目。貢献者の数を管理します。Jeff Bezosの「ピザ2枚ルール」は非同期にも当てはまります。人が増えるほど、1人あたりの貢献は減る。6人を超えたあたりから傍観者効果が顔を出し、参加の質が落ちるそうです。通知も同じ思想で、段階的に。全員が自分のGitHub通知を正しく設定している（Settingsで「Participating」と「Watching」の「Web and Mobile」にチェック）と信頼して、issueのQuestionsセクションでのタグ付けは最小限に抑えます。

自分が持ち帰るもの

#

会議の内容を、その場にいなかった人に完全に説明することはできません。でも、書かれた決定なら誰でも読めます。Alan自身、これが最善で唯一の仕組みだとは言っていません。ただ自分たちに一番合っていた、というだけです。割り込みが減り、傍観者効果が薄れ、一歩引いて事実ベースで決められるようになった。私もチームの決定を全部GitHubのissueに移すつもりはありませんが、下のテンプレートはさっそくうちのリポジトリに入れます。

GitHubのissueテンプレートとして使う

#

フォーラムとして使うリポジトリに.github/ISSUE_TEMPLATE/decision.mdとして保存しておけば、誰かが新しいissueを開くたびに、GitHubがこのテンプレートを選択肢として出してくれます。セクションの構成はAlanのもので、LOCIの行とラベルは私が足しました。

---
name: 意思決定
about: 決定を提案して、意見を文章で集める
title: "[意思決定] "
labels: decision
---

## スコープ
- このissueの目標は...
- このissueでは...は扱いません

## このissueを開いた理由

## LOCI
- Lead:
- Owner:
- Consulted:
- Informed:

## 期限
- 意見の締め切り:
- 決定日:

## 背景と資料

## 提案

## 質問

GitHub IssuesとGitHub Projectsの使い分け

#

GitHubをもっと広くプロジェクト管理に使おうと考えているなら、この2つは役割が違うと押さえておくと楽です。Issuesには議論が残り、閉じたあとはそれがそのまま決定の記録になります。GitHub Projectsは、1つ以上のリポジトリのissueの上に重ねるボードや表で、ステータスや担当者、期限といった独自のフィールドを持たせられます。Alanのような意思決定フォーラムなら、ラベルとissue一覧で十分です。Projectsを足すのは、開いている決定を、決めなければならない日付順に1画面で並べたくなったとき。それから、開発の進捗も同じ場所で追い始めたときです。たいていのチームは、結局そこで両方を使うことになります。

アイデア

#

韓国の屋台には住所がありません。ポジャンマチャは出したい場所に店を出すので、その場所を知っている人でなければ、ネットで探しようがないのです。うちのアプリは屋台を文字どおり地図に載せます。屋台の人にとってもありがたいし、夜中にトッポッキを探し回る人にとっても便利なはずです。

当日の様子

#

主催はLunit Globalで、会場のオフィスも提供してくれました。いろんなバックグラウンドのチームが集まり、ほとんどのメンバーが夜通し作業。運営もスムーズでした。ふと顔を上げたら朝4時だった、というタイプのイベントです。

チーム

#

メンバーはSharon Levy、Jonothan Sue、私、そしてTiaan van der Rielの4人。それぞれ持ち味が違ったので、分担で揉めることはありませんでした。ピッチが審査員に刺さったのは、問題の説明が要らなかったからだと思います。「屋台はネット上で見つけられない」と口に出せば、解決策は自ずと見えてきますから。

これから

#

いまはこのアプリをストアに出す準備を進めています。週末のプロジェクトとして始まりましたが、解決しようとしている問題は本物なので、ここでやめるのはもったいない気がしています。

はじめてのハッカソンなら

#

ハッカソンに出たことがない人には、ぜひ一度と言いたいです。初対面の人たちと短期間で何かを作り上げて、プレッシャーの中での自分の動き方もわかって、たまに続ける価値のあるものまで持ち帰れます。最悪でも、無料のお菓子付きの週末と、誰にも頼まれていない動くプロトタイプが手に入ります。

出る前に知っておくと楽になることを、いくつか挙げておきます。

• 一文で説明できる課題を選びましょう。審査員が課題を理解するのに最初の1分を使ってしまうと、肝心の解決策はちゃんと聞いてもらえません。
• 役割分担は早めに、できれば最初の1時間で決めます。誰が作り、誰がデザインし、誰がピッチを担当するか。夜中の2時に決めようとすると、ずっと高くつきます。
• デモの動線から作りましょう。本番で見せる流れをひとつ、最初から最後まで動くようにしてから、ほかの機能を足していきます。
• ピッチは実際のデモを動かしながら、声に出して最低2回は練習を。ピッチはほぼ必ず想定より長くなります。
• 少しでいいので寝ましょう。2、3時間眠るだけでも、朝の判断もピッチも目に見えて良くなります。

リンク:

#

https://lnkd.in/drMXUgPB