TL;DR（この記事の要約）

• AIがコードを書く時代、**エンジニアの価値はコーディング速度ではなく「何を作るべきか考え、人と協力して実現する力」**にシフトしている

• ソフトスキルとは「コミュニケーション能力」だけではない。問題構造化力・ステークホルダー調整力・技術翻訳力・フィードバック力・学習適応力の5領域で構成される

• 「なんとなく良い人」という感覚的な評価は、バイアスの温床になる。行動面接（STAR法）＋ロールプレイ＋チーム演習で構造化すべし

• ソフトスキル評価は技術力評価と独立して設計し、統合的にスコアリングする。配点の目安はジュニア30%・ミドル40%・シニア50%

• 導入は一度に完璧を目指さず、3ヶ月で段階的に組み込むのが現実的

このページでわかること

「技術力は申し分なかったのに、入社後にチームと噛み合わなかった」「設計レビューで自分の意見をまったく説明できない」「要件のすり合わせが苦手で、作ったものが毎回ズレる」――こんな経験、ありませんか？

AIコーディングアシスタントの普及により、「コードを書く」という行為そのものの価値は相対的に下がりつつあります。一方で、問題を正しく定義し、チームと協力して最適な解を導く力――いわゆるソフトスキル――の重要性は急速に高まっています。

ところが、多くの企業ではソフトスキルの評価が「面接官の主観」に依存したままです。これでは評価のバラつきが大きく、結果として採用ミスマッチを招きます。

この記事では、以下のポイントを解説します。

• AI時代にエンジニアのソフトスキル評価が必須になる背景

• 評価すべきソフトスキルの5領域と具体的な行動指標

• 面接・選考プロセスへの組み込み方（質問例20問付き）

• ソフトスキル評価を導入する90日ロードマップ

• ジュニア・ミドル・シニアのレベル別評価基準

• よくある失敗パターンと対策

スタートアップの採用担当者・人事・経営者の方に向けて、明日から使える実践的な手法をお伝えします。

1. なぜ今、エンジニアのソフトスキル評価が不可欠なのか

AI時代の構造変化：「書ける」から「考えられる」へ

GitHub CopilotやClaude CodeといったAIコーディングツールの登場により、エンジニアの仕事は大きく変わりました。定型的なコーディングはAIが代替し、エンジニアに求められる役割は「AIに正しい指示を出し、出力を評価・修正し、チームで意思決定する」方向へシフトしています。

この変化は採用にも直結します。従来の「アルゴリズム問題が解ける＝優秀」という評価軸だけでは、入社後に活躍するエンジニアを見極められなくなっているのです。

ソフトスキル不足が引き起こす3つの問題

問題1：設計の手戻りが多発する

要件定義の段階でビジネスサイドとの認識をすり合わせる力がないと、「作ってみたけど違った」が頻発します。AIツールで開発速度が上がっても、方向を間違えれば意味がありません。

問題2：チームの生産性が下がる

コードレビューで建設的なフィードバックができない、設計議論で自分の考えを論理的に説明できない。こうしたエンジニアがチームにいると、周囲のメンバーの負荷が上がり、チーム全体のパフォーマンスが低下します。

問題3：早期離職につながる

技術力は高いがソフトスキルに課題があるエンジニアは、チーム内で孤立しやすくなります。結果としてエンジニアの定着率が下がり、採用コストが膨れ上がるという悪循環に陥ります。

データが示すソフトスキルの重要性

採用後のパフォーマンスと相関が高いのは、技術試験のスコアよりも「チームとの協働」「問題の構造化」「ステークホルダーとのコミュニケーション」といった行動特性です。多くの採用担当者が「技術力とカルチャーフィットの両方を見極めたい」と考えているにもかかわらず、ソフトスキルの評価を体系化できている企業はまだ少数派です。

2. エンジニアに求められるソフトスキルの5領域

「ソフトスキル＝コミュニケーション能力」と一括りにすると、評価が曖昧になります。エンジニアに必要なソフトスキルを5つの領域に分解し、それぞれに具体的な行動指標を設定しましょう。

領域1：問題構造化力（Problem Structuring）

曖昧な要件や課題を、解決可能な単位に分解・整理する力です。

行動指標の例：

• ビジネス要件を聞き、技術的な制約と照らし合わせてトレードオフを明示できる

• 「何を作るか」だけでなく「なぜ作るか」「作らない選択肢」も含めて議論できる

• 複雑な問題を構造化し、優先順位をつけて説明できる

• 不確実性が高い状況でも、仮説を立てて検証方針を示せる

領域2：技術翻訳力（Technical Translation）

技術的な内容を非エンジニアにもわかる言葉で伝え、逆にビジネスの文脈を技術要件に落とし込む力です。

行動指標の例：

• 技術的な判断の理由を、ビジネスインパクトと紐づけて説明できる

• 非エンジニアからの要望を、実装可能な仕様に変換できる

• 技術的なリスクを、経営判断に必要な粒度で伝えられる

• ドキュメントやプレゼンで、読み手のレベルに合わせた説明ができる

領域3：フィードバック力（Constructive Feedback）

コードレビューや設計議論で、相手の成長を促す建設的なフィードバックを行える力です。

行動指標の例：

• コードレビューで「なぜダメか」ではなく「どうすればより良くなるか」を提案できる

• 自分と異なる設計方針に対して、感情的にならず論理的に議論できる

• フィードバックを受けたとき、防御的にならず建設的に受け止められる

• ジュニアメンバーの成長を意識した指導ができる

領域4：ステークホルダー調整力（Stakeholder Alignment）

プロダクトマネージャー、デザイナー、ビジネスサイドなど、異なる立場の関係者と利害を調整し、合意形成する力です。

行動指標の例：

• 異なる意見を持つ関係者の間で、共通のゴールを見出せる

• 技術的な優先度とビジネス的な優先度が対立したとき、データに基づいて判断を提案できる

• 「自分の意見を通す」のではなく「チームにとって最適な意思決定を促す」姿勢がある

• 期日やスコープの交渉を、関係者全員が納得する形で進められる

領域5：学習適応力（Learning Agility）

新しい技術や業務領域に対して、自律的に学び、短期間でキャッチアップできる力です。

行動指標の例：

• 未経験の技術領域でも、自分で情報を集めて学習計画を立てられる

• 失敗から教訓を抽出し、次のアクションに反映できる

• 「知らない」ことを素直に認め、周囲に助けを求められる

• 技術トレンドの変化に対して、自分のスキルセットをアップデートし続けている

3. ソフトスキル評価の面接設計：質問例20問

評価の原則：感覚ではなく「行動事実」を見る

ソフトスキルの評価で最も重要なのは、過去の具体的な行動事実を聞き出すことです。「コミュニケーション力はありますか？」と聞いても意味がありません。

行動面接（STAR法）を活用します。

• Situation（状況）：どんな場面だったか

• Task（課題）：何が求められていたか

• Action（行動）：具体的に何をしたか

• Result（結果）：どうなったか

問題構造化力を評価する質問（4問）

Q1. これまでに、最初は要件が曖昧だったプロジェクトで、どのように要件を明確化していきましたか？具体的なプロセスを教えてください。

Q2. 技術的に複数のアプローチが考えられる課題に直面したとき、どのようにトレードオフを整理し、最終的な判断を下しましたか？

Q3. 「この機能は本当に必要か」とチームに問いかけた経験はありますか？そのとき、どんな根拠を示しましたか？

Q4. 限られた情報の中で技術的な意思決定を迫られたとき、どのように仮説を立て、検証しましたか？

評価のポイント：

• 問題を分解する思考プロセスが論理的かどうか

• 「作らない」「やらない」という判断ができるか

• 不確実性への耐性があるか

技術翻訳力を評価する質問（4問）

Q5. 非エンジニアのステークホルダーに技術的なリスクを説明し、意思決定を促した経験を教えてください。

Q6. ビジネスサイドから「○○を実現してほしい」と依頼されたとき、技術的な制約をどのように伝えましたか？代替案を提示した経験があれば教えてください。

Q7. 技術選定の理由を、エンジニア以外のメンバーにどのように説明しますか？最近の事例で教えてください。

Q8. 自分が書いたドキュメントやプレゼンで、「わかりやすい」と評価された経験はありますか？工夫したポイントを教えてください。

評価のポイント：

• 技術用語に頼らず、ビジネス言語で説明できるか

• 一方的に説明するのではなく、相手の理解度を確認しながら進められるか

フィードバック力を評価する質問（4問）

Q9. チームメンバーのコードレビューで、相手の設計方針に強い違和感を覚えたことはありますか？どのように伝えましたか？

Q10. 自分が出したプルリクエストに対して厳しいフィードバックをもらったとき、どのように対応しましたか？

Q11. ジュニアエンジニアのコードをレビューするとき、どんなことを意識していますか？

Q12. チーム内で技術的な意見が対立したとき、どのように合意に至りましたか？

評価のポイント：

• 「否定」ではなく「改善提案」ができるか

• フィードバックを受ける側としての成熟度

• 感情と論理を分離できるか

ステークホルダー調整力を評価する質問（4問）

Q13. プロダクトマネージャーやデザイナーと意見が食い違ったとき、どのように解決しましたか？

Q14. 技術的負債の解消と新機能開発の優先度が対立したとき、どのようにチームや上長を説得しましたか？

Q15. 複数チームにまたがるプロジェクトで、調整役を担った経験を教えてください。

Q16. 期日に間に合わないことが判明したとき、関係者にどのタイミングで、どのように伝えましたか？

評価のポイント：

• Win-Winの解決策を模索する姿勢があるか

• 「報告」だけでなく「提案」ができるか

• 対立を恐れず、かつ建設的に議論できるか

学習適応力を評価する質問（4問）

Q17. 直近1年で、業務に直接関係ない技術やスキルを自主的に学んだ経験はありますか？なぜそれを学ぼうと思いましたか？

Q18. これまでのキャリアで最も大きな失敗は何ですか？そこから何を学び、その後どう行動が変わりましたか？

Q19. 未経験の技術スタックで開発することになったとき、どのようにキャッチアップしましたか？

Q20. AIツール（GitHub Copilot、Claude Code等）を開発に取り入れた経験はありますか？どのように使い方を工夫しましたか？

評価のポイント：

• 学習の動機が「外発的（指示された）」か「内発的（自分で判断した）」か

• 失敗を隠さず、そこから学びを抽出できるか

• 新しいツールや手法への抵抗感が低いか

4. 面接以外の評価手法：ロールプレイとチーム演習

面接だけではソフトスキルの実態を把握しきれません。以下の手法を組み合わせることで、評価精度が上がります。

ロールプレイ型評価

候補者に実際の業務シーンを模した状況を提示し、対応してもらう方式です。

シナリオ例1：要件定義ロールプレイ

面接官がプロダクトマネージャー役を務め、「ユーザーからこういう要望が来ている。どう対応するか一緒に考えたい」と相談します。候補者がどのように質問し、要件を深掘りし、技術的な提案をするかを観察します。

シナリオ例2：インシデント対応ロールプレイ

「本番環境で障害が発生した。ビジネスサイドへの説明と、技術チームへの指示を同時に行ってほしい」というシナリオを提示。優先順位のつけ方、情報の整理と伝達の仕方を評価します。

シナリオ例3：スコープ交渉ロールプレイ

「リリース期日まで2週間だが、要望された全機能の実装は間に合わない」という状況で、面接官がPM役として交渉相手になります。何を削り、何を残すか、どのように提案・合意するかを見ます。

チーム演習型評価

実際のエンジニアチームに候補者を交えて、短時間の設計議論やモブプログラミングを行う方式です。

設計ディスカッション（60分）：

チームメンバー2〜3名と候補者で、実際のプロダクト課題について設計議論を行います。

評価のポイントは以下の通りです。

• 自分の意見を持ちつつ、他者の意見にも耳を傾けるか

• 議論を前に進める発言ができるか

• 質問の質が高いか（表面的な質問ではなく、本質に迫る質問ができるか）

• 知らないことを正直に認められるか

ペアプログラミング型評価

ペアプロ・ライブコーディング面接の中で、ソフトスキルも同時に評価できます。コーディングの過程で「なぜその設計にしたか」「他にどんなアプローチがあるか」を自然に言語化できるかどうかを見ます。

5. レベル別の評価基準：ジュニア・ミドル・シニア

ソフトスキルに求めるレベルは、候補者のキャリア段階によって異なります。ジュニアに過度なステークホルダー調整力を求めても意味がありませんし、シニアに学習適応力だけを求めても不十分です。

ジュニアエンジニア（経験0〜3年）

重点評価領域：学習適応力・フィードバック力

配点目安：技術力70% / ソフトスキル30%

ミドルエンジニア（経験3〜7年）

重点評価領域：問題構造化力・技術翻訳力・フィードバック力

配点目安：技術力60% / ソフトスキル40%

シニアエンジニア・テックリード（経験7年以上）

重点評価領域：全5領域（特にステークホルダー調整力）

配点目安：技術力50% / ソフトスキル50%

6. 評価シートの設計と運用

ソフトスキル評価シートのテンプレート

面接評価シートにソフトスキル評価を組み込む際は、以下のフォーマットが実用的です。

各領域を5段階で評価：

重要なルール：

• 各スコアには必ず**具体的な行動根拠（「○○という質問に対して、△△と回答した」）**を記載する

• 「なんとなく印象が良かった」は根拠にならない

• 面接官ごとの評価のバラつきをデブリーフで確認・調整する

技術力評価との統合スコアリング

ソフトスキルと技術力は独立して評価した上で、最終的に統合します。

統合スコアの計算例（ミドルエンジニアの場合）：

• 技術力スコア：4.0（5段階平均）× 重み0.6 = 2.4

• ソフトスキルスコア：3.5（5領域平均）× 重み0.4 = 1.4

• 統合スコア：3.8

ただし、足切り基準も設けるべきです。技術力が5でもソフトスキルが1なら、チームへの悪影響が大きい。逆もまた然りです。一般的には、どちらかが2以下の場合は慎重に判断するルールが有効です。

7. ソフトスキル評価でやりがちな5つの失敗

失敗1：「コミュニケーション力が高い＝饒舌」と勘違いする

よく話す人がコミュニケーション力が高いとは限りません。エンジニアに必要なのは、必要な情報を適切なタイミングで、適切な相手に伝える力です。寡黙でも、質問が的確で、ドキュメントがわかりやすいエンジニアはコミュニケーション力が高いと言えます。

失敗2：同質性バイアスに陥る

「話しやすい」「波長が合う」はカルチャーフィットではなく、単なる同質性バイアスの可能性があります。自分と似たタイプの候補者を高く評価してしまうと、チームの多様性が損なわれます。

評価基準を事前に明文化し、行動事実に基づいて判断することで、このバイアスを軽減できます。

失敗3：職種・レベルに関係なく一律の基準で評価する

前述の通り、ジュニアとシニアでは求めるソフトスキルのレベルが異なります。ジュニアに「経営層への説明力」を求めたり、シニアに「素直さ」だけを評価軸にしたりするのは不適切です。

失敗4：ソフトスキル評価を1回の面接で完結させる

30分〜1時間の面接1回で5領域すべてを正確に評価するのは不可能です。複数回の面接で異なる領域を評価するか、ロールプレイやチーム演習を組み合わせましょう。

失敗5：評価結果を採用後に活かさない

ソフトスキル評価の結果は、オンボーディングの設計にも活用すべきです。「ステークホルダー調整力はやや弱いが、問題構造化力は高い」というデータがあれば、入社後にPMとの接点を意識的に増やすといった対策が打てます。

8. ソフトスキル評価の導入90日ロードマップ

Phase 1：準備（1〜30日目）

やること：

• 自社のエンジニアに求めるソフトスキルの優先領域を決める

• 現在の面接プロセスを棚卸しし、ソフトスキル評価がどこで行われているか（または行われていないか）を把握する

• レベル別の評価基準を策定する（前述の5段階評価シートを叩き台にする）

• 面接官向けの評価ガイドを作成する

判断のポイント：

5領域すべてを一度に導入しようとしない。自社で最も課題が大きい1〜2領域から始めるのが現実的です。たとえば「入社後に技術翻訳力の不足で問題が起きることが多い」なら、まずそこから評価を始めましょう。

Phase 2：試行（31〜60日目）

やること：

• 直近の選考案件で、新しい評価基準を「試し運用」する（合否判断への影響は限定的にする）

• 面接官同士でデブリーフを行い、評価基準の認識をすり合わせる

• ロールプレイ型評価のシナリオを1〜2本作成し、試行する

• 候補者からのフィードバック（選考体験アンケート等）を収集する

よくある課題と対処：

• 面接官によって評価のバラつきが大きい → デブリーフでの事例共有と基準の具体化

• ロールプレイの進行が難しい → 面接官向けのファシリテーションガイドを作成

• 評価に時間がかかりすぎる → 1回の面接で評価する領域を2つまでに絞る

Phase 3：定着（61〜90日目）

やること：

• 試行結果を踏まえて評価基準を修正・確定する

• ソフトスキル評価を正式な選考フローに組み込む

• 面接官トレーニングにソフトスキル評価の手法を追加する

• 入社後のパフォーマンスとソフトスキル評価スコアの相関を追跡する仕組みを作る

成功の目安：

• 面接官間の評価のバラつき（同一候補者に対するスコア差）が1.0以内に収まっている

• 候補者から「選考プロセスが丁寧だった」というフィードバックが得られている

• 入社後6ヶ月以内の離職率が、導入前と比較して改善傾向にある

9. AI時代に特有のソフトスキル：AIとの協働力

2026年の採用市場では、従来の5領域に加えて「AIとの協働力」という新しいソフトスキルが注目されています。

AIとの協働力とは

単に「AIツールを使える」という操作スキルではありません。以下のような能力を指します。

• AIの出力を批判的に評価できる：AIが生成したコードやドキュメントの品質・正確性を判断し、修正できる

• AIに適切な指示を出せる：プロンプトの設計や、AIに渡すコンテキストの整理ができる

• AIの限界を理解している：AIが苦手な領域（創造的な設計判断、倫理的判断、ドメイン固有の知識）を認識し、人間が担うべき部分を判断できる

• AIの活用方針をチームに提案できる：開発プロセスのどこにAIを組み込むべきか、組織レベルで考えられる

面接での評価方法

Q. 開発業務でAIツールを使っている場合、「AIに任せる部分」と「自分で判断する部分」をどのように切り分けていますか？

Q. AIが生成したコードに問題があった経験はありますか？どのように気づき、どう対処しましたか？

Q. チームでAIツールの活用ルールやガイドラインを作った経験があれば教えてください。

この領域は、AI活用スキル評価の記事でも詳しく解説しています。

FAQ（よくある質問）

Q. ソフトスキル評価を導入すると、選考プロセスが長くなりませんか？

A. 既存の面接にソフトスキル評価の要素を「追加」するのではなく、「組み込む」ことがポイントです。たとえば、技術面接の中でペアプロを行いながら、コミュニケーションの取り方も同時に評価する。こうすれば面接回数を増やさずに済みます。選考リードタイムを意識しながら設計しましょう。

Q. エンジニアの面接官が「ソフトスキルの評価は苦手」と言っています。どうすればいいですか？

A. エンジニアの面接官がソフトスキル評価に抵抗を示す理由は「基準が曖昧で、何をどう見ればいいかわからない」ことが大半です。評価基準を行動指標レベルまで具体化し、「この質問をして、こういう回答なら3点」というガイドを用意すれば、エンジニアでも評価しやすくなります。

Q. リモート面接でもソフトスキルは評価できますか？

A. 評価できます。むしろリモート環境でのコミュニケーション力は、リモート面接で自然に観察できます。画面共有しながらの設計議論やペアプロ、オンラインホワイトボードを使ったロールプレイなど、オンライン面接ならではの手法を活用しましょう。

Q. ソフトスキルが高いがスキルが足りない候補者と、技術力は高いがソフトスキルに課題がある候補者、どちらを採用すべきですか？

A. 一概には言えませんが、一般的な傾向として、技術力は入社後に伸ばしやすく、ソフトスキルは大人になってからの変化が難しいとされています。特にシニアポジションでは、ソフトスキルの課題はチーム全体に影響するため慎重に判断すべきです。ただし、ジュニアポジションではポテンシャルとしての技術力を重視する方が合理的なケースもあります。

Q. ソフトスキル評価は主観的になりがちです。客観性を担保するにはどうすればいいですか？

A. 3つの対策が有効です。1つ目は評価基準の行動指標化（「具体的にどんな行動が見られたら○点」を明文化する）。2つ目は複数面接官による独立評価（評価を面接中に共有しない）。3つ目はデブリーフでの根拠確認（「印象」ではなく「行動事実」に基づいているかを相互チェックする）。構造化面接の手法を参考にしてください。

Q. ソフトスキル評価で候補者に不快感を与えないか心配です。

A. ソフトスキル評価は、候補者にとっても「自分がこの会社で活躍できるか」を確認する機会です。面接の冒頭で「技術力だけでなく、チームとの働き方についても相互理解を深めたい」と伝えれば、候補者も自然体で臨めます。むしろ「ソフトスキルをちゃんと見てくれる会社」として好印象を持たれるケースが多いです。

Q. 新卒・未経験者のソフトスキルはどう評価すればいいですか？

A. 業務経験がない場合は、学生時代のチームプロジェクト、アルバイト、サークル活動など、チームで何かを成し遂げた経験から行動特性を評価します。「学習適応力」と「フィードバック力（受け止める力）」を重点的に見ると良いでしょう。ポテンシャル採用の記事も参考にしてください。

まとめ：ソフトスキル評価は「採用の質」を根本から変える

AIがコードを書く時代、エンジニアの価値は「何を書くか」から「何を作るべきか考え、チームで実現する力」へと移行しています。この変化に対応するには、採用の評価軸そのものをアップデートする必要があります。

ソフトスキル評価は、導入に手間がかかるように見えますが、その効果は大きいものです。

• 入社後のミスマッチが減り、定着率が改善する

• チーム全体の生産性とコミュニケーションの質が向上する

• 「技術力は高いのにチームで機能しない」という採用リスクを未然に防げる

まずは以下のステップから始めてみてください。

1. 自社で最も課題が大きいソフトスキル領域を1つ特定する

2. その領域の行動指標と評価基準を策定する

3. 次回の面接で試しに使ってみる

完璧な評価制度を一度に作る必要はありません。小さく始めて、改善しながら育てていくアプローチが最も確実です。

エンジニア採用のソフトスキル評価設計でお困りの場合は、ぜひtechcellarにご相談ください。スカウト運用から選考設計まで、エンジニア採用を総合的に支援しています。