見送りメールを閉じたままにしない。失注から次の提案を1つ変える振り返り

火曜18時12分、通知の一行で提案書を閉じた

火曜の夕方、3か月かけて社内問い合わせシステムを作り直す案件について、メールが届いた。

件名は「選考結果のご連絡」。通知欄には、本文の最初だけが見えていた。

慎重に検討した結果、今回は別の方へお願いすることになりました。

日曜の午後を使って提案書を直し、月曜の面談では質問にも答えた。担当者が何度もうなずいていたので、少しは手応えもあった。その分、胸の奥が急に重くなった。

メールを最後まで読んだものの、返信せずにアーカイブした。提案書のフォルダーも閉じた。「金額が高かったのか」「技術が古く見えたのか」「そもそも自分には営業が向いていないのか」と考え始めると、どこから見直せばよいか分からない。

その夜に開いたのは、提出した提案書ではなく、案件検索サイトだった。次は単価を2割下げようと入力しかけ、別のタブでは新しい技術講座を探した。

見送りがつらいのは、仕事が一件なくなるからだけではない。時間をかけた提案と、自分のこれまでを同時に否定されたように感じるからだ。その気持ちが強いと、事実を確かめる前に値下げしたり、学び直しへ逃げ込んだり、反対に何も見たくなくて記録を消したりする。

しかし、見送り通知だけで確認できる事実は「今回は選ばれなかった」までだ。価格、スキル、相性のどれが理由だったかは、まだ分からない。

失注を次へ生かす最初の仕事は、前向きになることではない。痛みから急いで結論を作らず、分かっていることを残すことだ。

失敗は、起きただけでは学びにならない

失敗すれば自然に成長できる、とは限らない。

『Psychological Science』に掲載された2019年の研究では、自分の失敗について結果を知らされた参加者は、成功を知らされた参加者より、その結果から学べなかった。別の人の失敗からは学びやすくなる結果も示されている。失敗した本人の中では、内容を理解する前に「自分が否定された」という痛みが前へ出やすいからだと研究者は考察している。

これは、見送りに弱い人だと決める話ではない。通知を受けた直後に提案書を開けないことには、理由がある。無理にその日のうちに深く反省すると、「全部、自分の実力不足だった」という大きすぎる結論を作りやすい。

そこで、その夜は反省を終わらせようとしなかった。次の五つをメモへ移し、画面を閉じた。

• 相談された業務: 社内問い合わせシステムの作り直し
• 相手が話した困りごと: 問い合わせが電話と紙に分かれ、回答履歴を探せない
• 自分が提案したこと: 問い合わせ受付、担当振り分け、履歴検索のWeb化
• 自分が提示した条件: 3か月、週3日、月80万円
• 相手から届いた言葉: 今回は別の方へ依頼する。詳しい理由の記載はない

ここには評価を書かない。「説明が刺さらなかった」「金額が高すぎた」は、まだ事実ではないからだ。感情が残っていても、事実だけなら保存できる。翌朝の自分が戻る場所を作るためのメモだ。

翌朝、事実・推測・不明を分ける

翌朝、同じメモに三つの見出しを置いた。

表にすると、「全部ダメだった」という感覚の中に、分かっていないことが多いと気づく。

ここで推測を消す必要はない。気になっていることとして残してよい。ただし、推測を事実の欄へ移さない。理由が確認できないなら、「不明」のままにする。

この区別がないと、見送り一件から「この技術を学び直すべきだ」「今の価格では通らない」と決めてしまう。IPAが2026年4月に公開したデジタルスキル標準v2.0は、個人の学びや企業の人材育成で使う指針として、必要な役割やスキルを整理している。学び直す時は、見送りの痛みだけで講座を選ぶのではなく、次に担いたい役割と、実際に不足が確認できた力を照らし合わせたい。

聞ける関係なら、一問だけ尋ねる

見送り理由を教えてもらえるとは限らない。比較内容を外へ出せない企業もあるし、担当者に説明する時間がない場合もある。回答を迫ると、相手にも負担がかかる。

それでも、面談を重ねた相手で、今後も関係を続けたいなら、一問だけ尋ねられる。

ご連絡ありがとうございます。今後の提案を改善する参考に、差し支えなければ、今回の比較で特に差が出た点を一つだけ教えていただけますか。回答が難しい場合は不要です。

聞く目的は、判断を覆してもらうことではない。「価格ですか、スキルですか」と選択肢を狭めず、相手が答えられる範囲を残す。

翌日の昼、この文面を送った。送信後は、「負け惜しみに見えただろうか」と何度も受信箱を開いた。返信がなくても、それは質問が悪かった証拠ではない。分からないことを不明のまま扱う、と先に決めておく。

夕方、担当者から短い返信が届いた。

機能と開発経験は十分でした。今回は、公開後1か月の職員研修と、週1回の現地支援まで含む提案を優先しました。

価格も技術力も理由だと決まったわけではなかった。相手が比べていたのは、作るところまでではなく、現場へ定着するところまでの支援だった。

ここで初めて、学びに使える事実が一つ増えた。

「案件・提案・条件」のどこを変えるか決める

事実がそろったら、次の三つに分ける。

1. 案件との合い方

相手が必要とする働き方を、自分が引き受けたいかを見る。今回なら、週1回の現地支援を続けられるかだ。

できない条件まで受け入れる必要はない。現地支援が難しいなら、見送りは能力不足ではなく、案件との合い方の違いでもある。次からオンライン運用支援を求める案件へ絞る判断も学びになる。

2. 提案で伝えたこと

相手が重視していたことを聞けていたか、それに対する行動を提案書へ書けていたかを見る。

今回の面談では、担当者が運用開始後の支援を質問していた。それなのに、開発機能の説明へ戻り、「操作説明も対応できます」と口頭で答えただけだった。次は、公開後4週間の質問受付、説明会、問い合わせ記録の見直しを提案の中へ置ける。

相手の困りごとから提案を組み立てる順番は、スキルを並べても刺さらない。受注前に「頼む理由」をどう伝える？でも詳しく整理している。

3. 条件とタイミング

価格、稼働日数、開始時期、契約期間が合っていたかを見る。ただし、根拠がなければ「高かった」と決めない。

価格が理由だと確認できた場合も、すぐに全体を値下げするのではなく、範囲を小さくする、最初の調査だけ分ける、支援回数を選べるようにする、といった代案がある。見送り一件だけで、自分の基準価格を下げ続けない。

次の提案では、一つだけ変えて確かめる

振り返りの最後に書くのは、長い反省文ではない。

Scrum Guideでは、振り返りの目的を品質と効果を高める方法の計画としている。案件営業をScrumにする必要はないが、振り返りを「自分を責める時間」ではなく「次に試す変更を決める時間」と見る考え方は使える。

三日後、別の業務システム相談があった。提案書を全部作り直さず、最初の一ページだけを変えた。

公開後4週間は、週次の質問会と問い合わせ記録の確認を行います。現地対応が必要な場合は、回数と場所を確認して別途見積もります。

面談では、機能の説明へ入る前に「公開後、誰が最初の問い合わせを受けますか」と聞いた。相手は、総務の一人へ質問が集中しそうだと話した。そこから、受付担当を二人に分け、よくある質問を一緒に残す提案へ変わった。

まだ受注は決まっていない。それでも、前回の見送りから変えたことと、その結果出てきた相手の言葉は確認できた。学びは「次はきっと成功する」という気合いではなく、何を変えたら会話がどう変わったかという記録になった。

見送りを、自分の評価ではなく次の観察へ戻す

見送り通知を読んだ直後は、提案書を閉じたままにしたくなる。すぐ返信できなくてもよいし、当日に立派な反省を終えなくてもよい。

まず、相手が言ったこと、自分が提案したこと、提示した条件を残す。翌日に、事実、推測、不明を分ける。聞ける関係なら一問だけ尋ねる。そして、次の提案で一つだけ変え、相手の反応を確かめる。

実績を次の相手へ伝え直す時は、実績はあるのに弱く見える。単価につながる言語化のコツも使える。失注の記録は、欠点の一覧ではない。自分がどの相手に、どんな変化を作れるかを具体的にする材料だ。

あの夜に入力しかけた2割の値下げは、保存しなかった。新しい技術講座も申し込まず、代わりに提案メモへ一行を足した。

次回は、作るものを説明する前に、公開後に誰の手が止まるかを聞く。

見送りの痛みが消えたわけではない。ただ、何をすればよいか分からず案件一覧を眺め続ける状態から、次の商談で確かめる一問へ戻れた。それが、失注を学習データへ変える最小の一歩になる。

参考にした情報

• Psychological Science「Not Learning From Failure—the Greatest Failure of All」（2019年12月公開、2026年8月5日確認）
• IPA「デジタルスキル標準ver.2.0を公開」（2026年4月16日公開、2026年8月5日確認）
• IPA「デジタルスキル標準（DSS）とは」（2022年12月21日公開、2026年7月9日最終更新、2026年8月5日確認）
• Scrum Guides「スクラムガイド 日本語版」（2020年11月版、2026年8月5日確認）