毎年、新卒の履歴書を見ていると、ある質問が圧倒的に多いんです。
「履歴書を書く最大の悩みは——実務経験がないのに、どうやって自分を信じてもらえばいいのか？」
この気持ちはよくわかります。でも、その前提が間違っています。
面接官が新卒に求めているのは、決して「実務経験」ではありません。 実務経験なんて、最初の仕事を始める前はみんな同じです。面接官が本当に見ているのは——この人の学習能力はどうか？ 問題に直面したとき、自分で考えるのか、それとも誰かが教えてくれるのを待つのか？ チームに入ったらうまくやっていけるか？
これらは「ソフトスキル」と呼ばれるものです。そして、これらは履歴書で「証明」できます。ただ「言う」だけではダメです。
ここでは3つの最も重要な能力——学習能力、思考力（認知能力）、チームワーク——について、面接官が何を見ているのか、そしてどう書くべきかを解説します。
一、学習能力：「できる」ではなく「証拠」を見せる
まず、就活生が最もよくやるミスから。
新卒の履歴書の自己評価を10枚見れば、少なくとも6枚に「学習能力が高く、新しい環境に素早く適応できます」と書いてあります。ところが、面接官が3ページ目までスクロールしても、「学習」に関係する具体的なエピソードが一つも出てこない。
これが典型的な「口だけのソフトスキル」です——自分では言っているけど、履歴書がそれを証明してくれない。つまり、誰でも書けるただの一文になってしまう。
面接官が見たい証拠とは？
最も効果的なのは次の3つです。
1. ゼロから何かを学び、成果を出した
「Pythonを独学しました」ではなく、こう書きます。
3年生の前期にゼロからPythonを独学。3ヶ月後、新型コロナに関するデータ可視化プロジェクト（スクレイピング＋Flask＋ECharts）を自力で完成。データの自動取得、保存、表示までを一貫して行い、Alibaba Cloudにデプロイして半年間稼働させました。
ここで大事なのは「Python」ではなく、「ゼロ→3ヶ月→リリース→継続稼働」という流れです。面接官は「この人は学習能力が高い」と、自分で結論を出します。
2. 未経験の領域で短期間で実務レベルに到達した
志望する職種が専攻と完全に一致していない場合、これは特に重要です。
金融専攻ではありませんが、「クオンツ投資」の選択授業に興味を持ち、2ヶ月かけてPandasと金融時系列分析を独学。最終的に「ARIMA-GARCHモデルに基づくCSI300指数のボラティリティ予測」という授業論文を執筆し、教授に推薦されて学科の論文選考に参加しました。
この一文が伝えているのは「この人は、未経験分野でも2ヶ月で論文を書けるレベルまで到達できる」ということです。専門外の人間にとって、これ以上ない学習能力の証明です。
3. 具体的な「学習→応用」のサイクル
多くの新卒にとって、大学での「学び」と「実践」は別物です——授業は授業、プロジェクトはプロジェクト。でも、もし「習ったことをすぐに使った」という経験を書ければ、そのサイクル自体が非常に説得力を持ちます。
「オペレーティングシステム」の授業でLinuxのプロセス管理を学んだ後、C言語で簡易シェルインタプリタを自作。パイプ、リダイレクト、バックグラウンド実行に対応。コード量は約1500行。
わかりますか？ 「学んだ→すぐに何かを作った」——この動作そのものが、学習能力の最も直接的な証明です。どんな評価よりも強い。
学習能力の書き方の公式： どこから学び始めたか ＋ どのくらいの期間をかけたか ＋ 何を作ったか ＋ その成果のレベル（リリースした？ 選ばれた？ 実際に使われた？）
二、思考力（認知能力）：面接官が見ているのは「問題の処理の仕方」
「何をやったか」よりも、経験豊富な面接官が重視するのは「どうやって仕事を進めたか」です。
思考力（認知能力）は漠然とした言葉ですが——履歴書に落とし込むと、結局は次の3つに集約されます。どんな問題を見つけたか、どう分析したか、どんな判断を下したか。
多くの新卒はプロジェクト経験を書くときに「何をしたか」だけで終わってしまい「なぜそうしたか」を書きません。これは思考力をアピールするチャンスを逃しています。
「何をしたか」を「どう考えたか」に変えるには？
2つのバージョンを見比べてみましょう。
普通の書き方：
キャンパス内フリマアプリの開発を担当。Java Spring Boot＋MySQLで商品出品・検索機能を実装。
これは「要件を技術的な解決策に落とし込んだ」という標準的な記述です。仕事をやったことは伝わりますが、どう考えたかは伝わりません。
改善版：
キャンパス内フリマアプリのバックエンドを構築（日間ユニークユーザー約300）。商品検索機能の設計にあたり、MySQLのLIKE検索とElasticsearchの2案を比較。プロジェクト初期のデータ量（5,000件未満）と運用コストを考慮し、MySQLの全文検索を採用。クエリ時間を200ms以内に抑え、後日Elasticsearchへ移行できるインターフェースも準備しました。
この数行には、3層の思考の深さが表れています。
- 技術選定を自分で行った（誰かに言われたからではない）
- データ量、コスト、拡張性という複数の軸で判断した
- 「まずは軽量な方式を選び、後でアップグレードできる余地を残す」という判断をした——これは実務に非常に近い考え方です
新卒でここまでの思考プロセスを履歴書に書ける人がいたら、面接官は確実に2分は余計に読み込むでしょう。
技術職以外でも同じです：
学部の公式WeChatアカウントを運営中、記事の開封率が継続して低下していることに気づきました（15％→6％）。直近2ヶ月の12記事のデータを分析したところ、トップ画像のスタイルとタイトルの文字数が開封率に大きく影響していると判明。画像をインフォグラフィック調に統一し、タイトルを18文字以内に抑えたところ、テスト4記事の平均開封率が11％まで回復しました。
整理すると：問題を発見 → データを分析 → 原因を特定 → 行動を起こす → 効果を検証。これは完全な認知のサイクルです。マーケティングでも、営業でも、プロダクトマネジメントでも、この構造は通用します。
判断基準： 履歴書に書いたそれぞれの経験——それを削除したら、面接官があなたの問題処理能力を判断できなくなるかどうか。もし「削除しても問題ない」なら、それは書き方が浅すぎる証拠です。
三、チームワーク：「コミュニケーションが得意」ではなく「チームの中でどんな役割を果たしたか」
チームワーク能力は、新卒の履歴書の中で最も中身のない書き方がされている項目です。間違いなく。
10人中9人が「コミュニケーションが得意で、チームワーク精神を持っています」と書きます。でも、これも同じです——面接官は「証拠は？」と思います。
最も効果的な方法：チームの中での自分の役割と貢献を書く。
チームワークとは「みんなで楽しく仕事を終わらせた」ということではありません。チーム内に意見の相違があったとき、プレッシャーがかかったとき、協働上の摩擦があったときに——あなたは何をしたのか、です。
いくつかの方向性：
1. 本来の担当以外の役割を自ら引き受けた
起業コンテストのチームで、技術開発の担当に加えて、自らプロジェクト管理の役割を買って出ました。Notionでチームのタスクボードを構築し、毎週進捗ミーティングを進行。議事録を整理し、3つの方向性の進捗を揃えるよう調整。チームは期限内にプロトタイプを完成させ、中間審査を通過しました。
これは「プログラミングが得意」ではなく「チームの協働効率を上げるために動いた」という話です。どの面接官も「この人をチームに入れたら安心だ」と思うでしょう。
2. チームメンバーを助けた
授業のグループ課題で、メンバー2名にGitのブランチ管理と協働ワークフローを説明。コードのコンフリクト発生率を90％削減しました。以降、チーム全員が統一ワークフローで作業し、プロジェクトを2日早く納品できました。
この書き方の巧みなところは、技術力（Gitを理解している）と協働意欲（自ら教えた）の両方を示している点です。しかも「実際に助けになった」という結果まで書いてあります。
3. チーム内で意見が分かれたときに、意思決定を促進した
ディベート部の学内大会で、チーム内で論点の方向性について意見が分かれました。私は30分だけ時間を取り、各自が自分の論点を支える具体事例をリストアップすることを提案。最後に投票で最も完成度の高い論点を選びました。結果的に大会に勝利し、この決定はチームリーダーから「重要なターニングポイントだった」と評価されました。
意見の対立や衝突はどんなチームでも起こります。そんな中で物事を前に進められる——この能力は「協調性がある」よりずっと価値があります。
チームワークを書く際の原則： 「関係性」ではなく「役割」を書け。あなたとチームの関係は？ このチームの中で何の機能を果たした？ もしあなたがいなかったら、チームには何が足りなかった？
四、おまけ：主体性——見落とされがちだが非常に価値の高いシグナル
上の3つの能力に加えて、もう一つ面接官がとても気にする要素があります。ただし、一つの経験だけで単独で示すのは難しい——それが主体性です。
わかりやすく言えば：「これをやっておけ」と誰にも言われていないのに、自分でやることを見つけられたかどうか。
これは独立したモジュールではなく、上のどの経験の中にも埋め込むことができます。
もしあなたが書いている経験が「先生から指示された課題」や「授業で課された宿題」なら、次の方向で一文追加できないか試してみてください。
- 要求された部分を終えたあと、さらに何か余分なことをしたか？（最適化した？ 反復改善した？ 拡張した？）
- 作業中に、計画になかった問題を見つけて、ついでに解決したか？
授業の課題として基本的な図書管理システムの実装が求められました。基本機能を完成させたあと、「延滞自動通知」機能を追加——毎晩バッチで貸出テーブルをスキャンし、延滞レコードを抽出してメール通知を送信するものです。この機能を後に別の学科の先生が見て、「うちのクラスにも導入できないか」と聞いてきました。
最後の一文が絶妙です。「別の先生に見つかって、うちでも使いたいと言われた」。これがさりげなく証明しているのは2つのこと。第一に、要求以上の仕事をしたこと。第二に、その成果が誰かに認められたこと。
五、比較：「書く前」vs「書いた後」
最後に、一つの経験について「書く前」と「書いた後」を比較してみましょう。先に述べたすべての原則を一つの経歴に詰め込むと、情報量にどれだけ差が出るかがわかります。
書く前：
全国大学生創新創業訓練計画（大学生向けの国家イノベーションプログラム）に参加。プロジェクトメンバーとして市場調査とデータ分析を担当。プロジェクトは国家級認定を取得。
書いた後：
全国大学生創新創業訓練計画（国家級認定、全学でわずか15％）
プロジェクト背景：チーム4名でキャンパス内相乗りアプリを開発。立ち上げ段階で、競合が長距離相乗りに集中しているのに対し、キャンパス内の短距離相乗りは未開拓であることに気づき、プロジェクトの方向性を「キャンパス移動プラットフォーム」から「キャンパス内短距離相乗り」に絞ることを提案。この方針は指導教員にも認められ、プロジェクトの最終方向となりました。
自分の役割：市場調査とデータ分析を担当 | 自らプロジェクト管理も買って出る
- 有効回答320件のアンケートを設計・回収し、Excel＋SPSSでクロス分析を実施。12ページの調査レポートを出力（ユーザーペルソナとニーズの優先順位付けを含む）
- 調査データに基づき、プロダクト機能の優先順位として「最小限の機能セット（MVP）」を提案、チームに採用される
- チーム共有ドキュメントと作業スケジュール表を整備し、3つの方向の進捗を調整
プロジェクト成果：国家級認定を取得（全学での認定率15％）、プロトタイプを開発し50名のクローズドテストを実施、ユーザー満足度4.3/5
「書く前」を読んだ面接官の心中：「うん、参加したプロジェクトね。」
「書いた後」を読んだ面接官の心中：「この人、市場の隙間を見つけられる、チームの方向性を明確にできる、定量分析で判断を検証できる、さらにチームの調整までできる——まだ3年生？ 面接でもっと話を聞いてみたい。」
同じプロジェクトです。嘘はついていません。あなたが元々やっていたことを、「能力が伝わる形」で書いただけです。
書き終わったあとのチェックリスト
- すべての経験から「担当」「参加」を削除し、具体的な行動に置き換えたか（提案、構築、設計、推進、最適化）
- 「できない状態からできるようになった過程」を示す経験が少なくとも一つあるか？（学習能力）
- 「何をしたか」だけでなく「なぜそうしたか」が書かれた経験が少なくとも一つあるか？（思考力）
- チームについて書くとき、「自分はどんな役割を果たしたか」であって「チームで何をやったか」になっていないか？（チームワーク）
- 課題の要求範囲を超えて行動した経験が一つでもあるか？（主体性）
- それぞれの経験に具体的な数値がつけられるか？（調査数、改善率、カバー人数）
このチェックリストを一通り確認すれば、履歴書は少なくとも一段階はレベルアップします。
書き終えても「これで本当に大丈夫かな……」と不安が残るなら——自分の書いたものは、自分では客観的に見づらいものです。DeepResumeの無料診断なら、成果の定量化・マッチ度・表現の明確さなどの観点から総合スコアを算出し、各経験ごとの改善提案も行います。