実績はあるのに弱く見える。単価につながる言語化のコツ
面談前のメモが、作業リストで止まっている
「やったことは多い。でも、これを話して単価の話になる気がしない…」
案件更新の面談が近い。前日の夜、これまでの実績をメモに書き出してみる。
APIを実装した。管理画面を直した。問い合わせ対応を減らすためにFAQを整えた。レビューもした。障害調査にも入った。
行数だけ見ると、ちゃんと働いている。むしろ、けっこう頑張っている。
でも、そのメモを見ながら「これで単価を上げたいです」と言う場面を想像すると、急に声が小さくなる。相手から「なるほど、だから単価を見直したいんですね」と受け取ってもらえる感じがしない。作業は並んでいるのに、価値が立ち上がってこない。
ここがしんどい。実績がないわけではないのに、話すと弱く見える。自分でも「ただ作業を並べているだけかも」と分かっているから、余計に言い出しづらくなる😓
でも、ここで必要なのは実績を盛ることではない。大きな成功談を作ることでもない。作業の名前を、相手が判断できる変化へ置き換えること だ。
PMI の 2025年版 Pulse Report は、プロジェクト職能に必要な力として business acumen を扱い、単なる作業遂行者から、事業価値をつくる戦略的な相手へ変わることをテーマにしている。IPA の「DX動向2025」でも、DXの取り組みや成果、成果をどう把握するか、人材の量と質が調査項目として扱われている。
つまり、現場で求められているのは「何をやったか」だけではない。やった結果、事業、チーム、顧客、運用がどう楽になったのかまで見えることだ。
この記事では、面談前の実績メモを、作業リストから単価の話につながる説明へ変える順番を整理する。
作業を話すだけだと、相手は値段を決めにくい
「APIを実装しました」「画面を作りました」「レビューしました」。これは全部、事実だ。嘘ではないし、軽く見ていい仕事でもない。
ただ、単価や評価の話でこのまま出すと、相手は判断しにくい。なぜなら、作業名だけでは、その作業がどれくらい助かったのか、どれくらい難しかったのか、次も任せる理由になるのかが見えないからだ。
作業名だけでは、同じ人に見えてしまう
たとえば、2人のエンジニアがどちらも「管理画面を改修しました」と言ったとする。作業名だけなら同じだ。
でも中身は違うかもしれない。
片方は、指示された画面をそのまま作った。もう片方は、問い合わせが多かった検索条件を整理し、運用担当が毎回CSVを加工していた手間を減らした。後者は、同じ「管理画面改修」でも、相手の業務を前に進めている。
ここを言葉にしないと、相手には伝わらない。本人の中では分かっていても、面談の場では、相手の頭の中に材料を置き直す必要がある。
作業名は入口であって、単価の根拠そのものではない。
「頑張った」は本当でも、判断材料としては薄い
面談前のメモには、つい努力量を書きたくなる。
- 短納期で対応した
- 複数タスクを並行した
- 急な依頼にも対応した
- かなり忙しかった
これは本人の実感としては本当だ。むしろ、ここを分かってほしいから面談で話したくなる。
ただ、相手が単価を決める時には、努力量だけでは少し弱い。「大変だったんですね」で終わりやすい。ここで必要なのは、忙しさの説明ではなく、忙しい中で何を守ったのか、何を減らしたのか、何を前に進めたのかだ。
短納期で対応したなら、なぜ短納期でも壊れなかったのか。複数タスクを並行したなら、どの判断を先に分けたから止まらなかったのか。急な依頼に対応したなら、次から同じ混乱を減らすために何を残したのか。
努力を消す必要はない。ただ、努力のあとに「何が変わったか」を置く。ここで実績の見え方が変わる。
価格の話では、付加価値も材料になる
中小企業庁の「価格交渉ハンドブック」では、価格交渉の準備として原価や単価だけでなく、自社の付加価値を見直す観点も扱われている。これは企業向けの資料だが、業務委託やフリーランスの説明にも近い。
単価の根拠は「時間を使いました」だけでは弱い。もちろん稼働時間は大事だ。でも、それだけだと時給の話に寄りやすい。
実績を単価につなげたいなら、時間に加えて、相手にとって何が助かったかを見る。問い合わせが減った。確認の往復が減った。納品前の手戻りが減った。担当者が上長へ説明しやすくなった。
こういう変化は、派手ではない。でも、価格の話ではかなり効く。
実績メモは、3行で書き換えられる
では、面談前のメモをどう直すか。
最初から立派な職務経歴書のように書こうとすると重い。きれいな文章にしようとして、手が止まる。だから、まずは3行でいい。
- どんな状況だったか
- 自分は何をしたか
- その結果、何が変わったか
これだけで、作業リストは実績に近づく。
先に、相手が困っていた状況を書く
実績の説明は、自分の作業から始めるより、相手が困っていた状況から始めた方が伝わりやすい。
たとえば、こうだ。
問い合わせが毎週同じ内容で発生し、運用担当が都度調査していた。
ここまで書くと、相手は「なぜその作業が必要だったのか」を理解しやすい。いきなり「FAQを整備しました」と言うより、ずっと入りやすい。
実績が弱く見える人ほど、ここを飛ばしがちだ。自分の作業から話してしまう。でも、相手にとって大事なのは、先に困りごとがあったことだ。困りごとが見えると、その後の作業がただの作業ではなくなる。
次に、自分の打ち手を短く書く
状況を書いたら、自分が何をしたかを書く。ここは長くしすぎなくていい。
問い合わせ内容を分類し、管理画面の説明文とFAQを整理した。
これくらいで十分だ。技術的に難しいことをしたなら書いていい。ただ、全部を並べる必要はない。相手が知りたいのは、作業の全量ではなく、状況に対してどう動いたかだ。
ここで「頑張った」「幅広く対応した」と書きたくなるかもしれない。でも、それは次の行で効かせる。打ち手の行では、何を見て、何を変えたかを短く置く。
最後に、変化を一つだけ置く
3行目がいちばん大事だ。
同じ問い合わせの往復が減り、担当者が本来の確認作業に戻りやすくなった。
ここまで書くと、相手は実績として受け取りやすい。問い合わせ件数を数字で出せるなら、もちろん強い。毎週5件が2件になった、確認時間が半分になった、リリース前の差し戻しが減った。数字があるなら出す。
ただ、数字がないと全部ダメではない。数字がない時は、誰の何が楽になったかを書く。運用担当が調査に戻れる。営業担当が顧客へ説明しやすい。PMが判断を保留しなくていい。これも立派な変化だ。
実績は「すごいこと」ではなく、「相手の次の判断を軽くしたこと」まで書くと強くなる。
面談で話す時は、相手の判断順に並べる
実績メモができても、面談でそのまま全部読み上げる必要はない。むしろ、長く話すほど弱く見えることがある。
相手が知りたい順番に並べる。ここが大事だ。
まず、今回の役割を一文で置く
面談では、最初に自分の役割を一文で置くと話しやすい。
今回は、実装だけでなく、問い合わせが増えていた箇所の整理と、運用側が確認しやすい形にするところまで持ちました。
これで、相手は聞く準備ができる。「この人は何を自分の価値として話そうとしているのか」が見えるからだ。
役割の一文がないまま細かい作業に入ると、相手は途中で迷う。APIの話なのか、運用改善の話なのか、単価交渉の話なのかが分からなくなる。まず役割を置く。そこから具体例へ進む。
次に、代表例を1つだけ話す
実績は全部話さなくていい。全部話そうとすると、作業報告になる。
面談では、代表例を1つ選ぶ。たとえば、問い合わせ削減、手戻り削減、確認フロー整理、レビュー観点の追加、リリース前の不具合検出。どれか一つでいい。
たとえば、管理画面の問い合わせが毎週発生していた箇所では、問い合わせ内容を3種類に分けて、画面文言とFAQを直しました。結果として、同じ確認の往復が減り、担当者が月末処理に集中しやすくなりました。
これなら、作業と変化がつながっている。相手も「なるほど」と受け取りやすい。
ここで気をつけたいのは、話を盛らないことだ。「売上に大きく貢献しました」と言い切れる材料がないなら、無理に言わない。代わりに、確認の往復が減った、説明しやすくなった、判断が早まった、という手元の変化を正確に言う。
最後に、次も任せる理由へつなげる
単価の話につなげるなら、最後に「次も何を任せられる人なのか」を言う。
今後も、実装だけでなく、問い合わせや手戻りが増えそうな箇所を先に見つけて、運用側が使いやすい形まで整理できます。
この一文があると、実績が過去の話で終わらない。次の契約期間で何を期待できるかに変わる。
単価交渉は、過去の頑張りを認めてもらう場であると同時に、次の期間に何を任せるかを決める場でもある。だから、「前回これをやりました」だけで止めない。次もどの価値を出せるかまで置く。
単価につながる実績説明は、過去の作業報告ではなく、次に任せる理由づくりだ。
言語化は、強く見せるより正確に見せる
実績を言語化しようとすると、急に自分を大きく見せないといけない気がする。これがけっこう苦しい。
でも、言語化は自己演出ではない。相手が判断できるように、事実の見せ方を整えることだ。
数字がない時は、無理に作らない
「問い合わせが30%減りました」と言えるなら強い。でも、数字が取れていない現場も多い。そこで無理に数字を作ると危ない。あとで確認された時に弱くなる。
数字がない時は、変化の方向を具体的に書く。
- 同じ確認が繰り返されにくくなった
- 担当者が上長へ説明しやすくなった
- リリース前に確認すべき項目が見えるようになった
- 次回の見積りで、修正範囲を分けやすくなった
これなら、盛っていない。だけど、作業よりは価値が伝わる。
自分だけの成果にしない方が、むしろ信頼される
実績を話す時、全部を自分の手柄にしようとすると不自然になる。現場の成果は、だいたいチームで出ている。そこを無理に一人の成果にすると、聞いている側も少し身構える。
だから、自分が担った部分を正確に言う。
チームで問い合わせ削減に取り組む中で、自分は問い合わせの分類と画面文言の修正を担当しました。
これでいい。むしろ、この方が信頼されやすい。自分の役割を正確に切り出せる人は、次の仕事でも期待範囲を合わせやすいからだ。
1つの実績を、3つの言い方で持っておく
面談、職務経歴書、提案文では、同じ実績でも言い方を変えると使いやすい。
- 面談: 問い合わせが増えていた箇所を整理し、担当者が確認しやすい状態にしました
- 職務経歴書: 問い合わせ内容の分類と画面文言改善により、同種の確認往復を削減
- 提案文: 運用で詰まりやすい箇所を整理し、リリース後の問い合わせを減らす形で実装できます
同じ実績でも、相手が見たいものが違う。面談では状況が伝わる言葉、職務経歴書では短く残る言葉、提案文では次に任せる理由になる言葉が効く。
言語化が得意な人は、急にうまい表現を思いついているわけではない。実績を、相手の判断場面ごとに置き直している。
最後に
実績が弱く見える時、足りないのは実績そのものではなく、相手が判断できる形かもしれない。
面談前のメモが作業リストで止まっていたら、まず1つだけ書き換えてみてほしい。
状況: 問い合わせが同じ内容で繰り返されていた
打ち手: 問い合わせを分類し、画面文言とFAQを直した
変化: 担当者が毎回同じ説明をしなくてよくなった
これくらいでいい。最初から完璧な職務経歴書にしなくていい。1つの作業を、1つの変化へ戻すところからで十分だ。
価格の話が毎回苦しくなる人は、見積りの切り方 や 価格の中身を分ける考え方 も合わせて見てほしい。実績の言語化は、単価交渉だけのためではない。自分の仕事が、誰の何を前に進めたのかを取り戻す作業だ。
作業を並べるだけだと、自分でも価値が見えにくい。状況、打ち手、変化の3行に戻すと、少し見え方が変わる。実績は、盛るより先に、相手が判断できる形へ戻す。 そこから単価の話は少しだけしやすくなる✨
