フリーランスエンジニアが案件を決めるときは、参画先の企業と商談（面談）をします。私はこの商談のために、毎回「話」を用意しています。
用意する話は、案件情報から逆算して作ります。そして、そのネタは商談の直前ではなく、毎日の仕事の中で貯めています。
面談の攻略法ではありません。私の場合のやり方として読んでください。
先に結論
- 商談は30分から60分と短い。そのあいだに、ほかの候補と比べられている
- 話は、案件情報の必須と歓迎から作る。相手の頭に残すのは3つくらいに絞る
- 歓迎に「API設計」とあった案件では、その話を用意し、経歴書にも「API設計」と書いた。商談では実際にAPI設計を詳しく聞かれ、その日のうちにオファーが来た
- 話は、最低でも6つは持っておきたい。理想は15個
- ネタは、毎日の設計判断をMarkdownに書いてGitで管理している。NotionのメモにはPRのURLだけを書く
- 話がなければ、今の現場で作りに行く。私は自分用のツールから始めて、Webシステムの責任者になったことがある
商談は短く、ほかの候補と比べられている
私が受けてきた商談は、短くて30分、長くて60分でした。
面談する側は、1日に3件以上の面談をしていることもあります。私自身も、同じ日に3件の商談を受けたことがあります。個別の面談でも、ほかの候補と並べて見られていると考えたほうがよいと思っています。
この短い時間で、相手の頭に何を残すか。私は、それを商談の前に決めておきます。
話は、案件情報の必須と歓迎から作る
聞きたいことは、案件情報に書いてある
面談する側が聞きたいことは、案件情報の中にあります。エージェントから届く資料には、必須と歓迎の項目が並んでいます。私はそこから、相手が求めていることを考えます。
相手の頭に残すのは、3つくらいに絞ります。多いと、相手が覚えていられないからです。配分は案件に合わせて変えます。
- 必須から3つ
- 必須から1つだけ
- 必須から2つと、歓迎から1つ
求められている役割を推測する
同じ開発の案件でも、どこに重きを置いているかは違います。私は、だいたい次の3つのどれかを考えます。
- 高い設計能力: 設計の品質そのもの
- プロトタイプ力: 設計が雑でも、まず動くものを作る
- ブリッジ・要件定義: ユーザーとの間に入って、要件を固める
手がかりは、案件情報に出てくる言葉です。「顧客折衝」や「スクラム」が並んでいれば、技術よりもコミュニケーションや要件定義の話を用意します。「API設計」「DB設計」「並行処理」が並んでいれば、技術的な設計判断の話を用意します。
1件だけでは分かりにくいので、3つ以上の案件情報を見比べて推測します。
話すことは変える。経歴書は1つ
商談で話すことは、会社ごとに変えます。ただし、経歴書は1つです。
1つしかないので、経歴書は抽象的に書くしかありません。具体的な中身は、商談で話します。そのかわり、経歴書には相手が質問しやすい言葉を入れておきます。そこに書いていないことは、相手も質問しづらいからです。
変えるのは、やった経験のどこを前に出すかだけです。やっていない経験は書きません。
歓迎の「API設計」から話を作った
実際にこのやり方で準備した商談があります。いま参画している案件の商談です。
エージェントの資料を見ると、歓迎の項目に「API設計」とありました。そこで、API設計の話を前もって用意しました。あわせて、その話になりやすいように、経歴書に「API設計」という言葉を書いておきました。
商談では、APIの設計について詳しく聞かれました。データベースの外部キーについても聞かれています。用意していた話は、そのまま使えました。
ただ、全部に答えられたわけではありません。まったく分からない質問もあり、3秒ほど黙ってしまいました。それでも、商談を終えてから2時間もたたないうちにオファーが来ています。この商談の詳しい中身は、レバテックフリーランスの商談で聞かれたことに書きました。
同じ日に受けた別の商談では、見送りになっています。準備をすれば必ず通る、という話ではありません。準備しておくと、聞かれたいところを聞いてもらえる可能性が上がる、というのが私の実感です。
話は、最低6つは持っておく
話の数
私が考えている話の数は、こうです。
- 自己PRで使う話: 3つ
- 自己PRから聞かれそうな話: 3つ
これで最低6つです。
理想を言えば、もっと持っておきたいです。答えると、たいていまた質問が来ます。別の人から質問されることもあります。
自己PR 3 ＋ 1回目の回答 3 ＋ 2回目の回答 3 ＋ 別の人からの質問 3 ＋ その2回目の回答 3
= 15個
15個の話を先に持っておくと、商談でかなり余裕ができると思っています。
話の長さ
1つの話題は、だいたい1分です。自己PR全体で3分から5分にします。
質問への回答は、短くて30秒、長くて90秒です。1回で全部を話しません。答えるとまた質問が来るので、そこで続きを話します。
質問が多いのは、悪いサインではないと思っている
質問が続くと、詰められているように感じます。でも私は、質問が多いほど良いと考えるようにしています。
質問がない、または誰でも答えられる質問ばかりのときは、相手が深く聞くほどの興味を持っていない可能性があります。私が通った商談では技術的にかなり詰められ、落ちた商談では志向の話が中心でした。
ただし、これは私の経験から考えていることです。詰められたら必ず通る、とまでは言えません。
ネタは、毎日Gitに貯めている
話は、商談の直前に作ろうとしても間に合いません。商談は、日々の仕事のメモから始まっていると思っています。
毎日、判断をMarkdownに書く
私は毎日、設計判断や仕様の詳細を、すべてMarkdownのファイルに書いています。そのファイルはGitで管理しています。
Notionにもメモを残していますが、そこに書くのはPRのURLだけです。
振り返るときは、Claudeに読ませる
あとで「10月に何をやったか」を振り返るときは、Claudeなどに読ませます。
- PRのURLから、書いたコードが分かる
- Gitのログから、そのとき何を考えたかが分かる
- ローカルのMarkdownから、そのときの判断が分かる
- Slackやメールから、結果の数値が取れる
Notionには、PRのURLという入り口だけを置いておけば足ります。中身はGitとMarkdownに残っているからです。
話がなければ、今の現場で作りに行く
ツールから始めて、Webシステムの責任者になった
話にできる経験がないなら、今の現場で作りに行けばいいと思っています。
私がやったことがあるのは、ツールを勝手に作って、自分で使うことです。これまでに作ったのは、たとえば次のようなツールです。
- ログを集めるツール
- 大量のファイルを仕分けるツール
- 自動テストを走らせて、ログを取るツール
- 自動テストを走らせて、画面の挙動を撮影するツール
- 組み込み製品の、複数のGitのブランチとハッシュの組み合わせと、成果物を対応づけるツール
私の場合は、こう進みました。
- 最初は、自分のためのツールだった
- 自分の仕事が早くなったので、上司に理由を聞かれた。そこで、このツールを使っていると話した
- ほかの人にも使えるようにしてほしいと言われ、修正してから共有した
- 共有すると、メンバーのPCの環境によってはうまく動かないことがあった。それが理由で、Webシステムに作り替えた
- そこからWebシステムの機能を広げるようになり、工数ももらえるようになった
こうして、そのWebシステムの責任者になりました。
チームのためのものを作って結果が出ると、仕事が少しずつそちらの開発に傾いていきます。
勝手に仕事を増やすと、心象は悪くなる
ただし、何でも作ればいいわけではありません。
上司から見ると、やりたいことはたくさんあります。でも、部下に渡せるところまで噛み砕けていないことが多いです。そこに部下が勝手に仕事を増やすと、心象が悪くなります。
だから私が選ぶのは、チーム全体で困っていることや、上司が困っていそうなことです。上司にとっては、いつかやりたいけれどやれていないことです。できれば生産性は上がるけれど、面倒を見る余裕はない。そういうものを、責任を持って管理してくれる人がいると助かるはずです。
mustをやりながら、少しずつ進める
上司から来る仕事のmustは、必ずやります。そのうえで、shouldやwantにあたることができると、上司からgoサインが出やすくなります。
自分から上司に「これをやりたい」と言ってみるのも1つの方法です。私の場合は、mustをやりながら少しずつ進めて、結果が出たところで「実はこれを使っていました」と言うほうがよいと考えています。さきほどのツールも、仕事が早くなった理由を聞かれて、初めて上司に話しました。
持っている話を、全部使うわけではない
このWebシステムの話は、さきほどのAPI設計の商談では話していません。経歴書にも書いていません。その商談では、ほかに目立たせたいこと、質問させたいことがあったからです。
話はたくさん持っておきます。でも、商談で使うのは、その案件に合わせて絞った3つくらいです。
まとめ
- 商談は30分から60分。ほかの候補と比べられている
- 話は、案件情報の必須と歓迎から作り、3つくらいに絞る
- 歓迎の「API設計」から話を作り、経歴書にも書いた。商談ではAPI設計を詳しく聞かれ、その日のうちにオファーが来た
- 話は最低6つ、理想は15個。回答は30秒から90秒
- ネタは、毎日の判断をMarkdownに書いてGitで管理している。NotionにはPRのURLだけ
- 話がなければ、今の現場で作りに行く。自分用のツールを共有し、Webシステムに作り替えて、工数をもらえる責任者になったことがある
商談の準備は、案件情報を読むところから始まります。でも、話そのものは、毎日の仕事の中でしか作れません。
経歴書を書き直したら、紹介される案件の中身が変わった話は、組み込みエンジニアのWeb系転向に書いています。実務経験が浅いときの考え方は、実務経験が浅いとフリーランスは厳しい？にまとめました。