「顧客の評価基準が明確」と感じているSESエンジニアはたった27%。【SES・派遣500人調査】

SES・派遣エンジニアを受け入れている現場で、「思ったより成果が上がらない」と感じることはないでしょうか。原因をスキルや単価に求めたくなりますが、現在就業中のSES・派遣エンジニア500人への調査から、成果が出ている開発現場では評価やフィードバックが現場のエンジニアにきちんと届いているということがわかりました。

 

本コラムは、ホワイトペーパー「SES・派遣エンジニア500人に聞いた、成果が出る開発現場の条件」の内容を抜粋しています。技術者派遣・SESに従事しているエンジニア500名にアンケート調査を実施。これまでに携わった、代表的な(従事していた期間が長い)システム開発プロジェクトについて、オンボーディング、PM/PLとの関わり方、評価とフィードバック、プロジェクトの成果や継続意向など、32問にわたって聴取しています。

▶ ダウンロードはこちら

「業務成果に対するクライアントの評価基準が明確」と感じているのは、4人に1人

「業務成果に対するクライアントの評価基準は明確でしたか」という設問に対し、「ややそう思う」「かなりそう思う」と答えたエンジニアは 27.4%でした。一方で「どちらとも言えない」が 50.8%、「明確ではない」が 21.8% でした。つまり、7割以上のエンジニアが、自分がどう評価されているのか分からないまま業務に当たっていました。

これは個々のエンジニアの能力や意欲の問題ではなく、評価基準そのものが現場に浸透していない、という構造の問題です。

Q.業務成果に対するクライアントの評価基準は明確でしたか?

成長実感や参画意向を、評価基準の明確さ別に比較

前述の「評価基準の明確さ」によって回答者を3つの層に分け、プロジェクトを通じた成長実感や参画意向といった項目の評価を比較しました。

指標評価基準が明確(n=137)どちらとも言えない(n=254)評価基準が不明確(n=109)
1.プロジェクトがうまくいった78.8%27.2%24.8%
2.個人の成長を実感した69.3%26.8%25.7%
3.働きやすかった75.2%36.6%33.0%
4.また参画したい62.8%24.0%26.6%
評価基準の明確度×エンジニアからみたプロジェクトの評価

注目したいのは、「どちらとも言えない」層と「不明確」層に、ほとんど差がないことです。プロジェクトがうまくいったと回答した人は27.2%と24.8%しかいませんでした。一方で「評価基準が明確」と答えた層だけが78.8%と突出しています。回答したエンジニアの体感値ではあるものの、評価基準の明確さとプロジェクトの成果には相関関係があるといえるでしょう。

また、ここから読み取れるのは、評価の明確度は段階的に効くものではないということです。「なんとなく評価されている気がする」状態は、「評価されていない」状態とほぼ同じ体感になります。基準が言語化され、相手に届いて、初めて差が生まれます。

「また参画したい」は、発注側のコスト抑制の話でもある

4つ目の指標である、「また参画したい(継続意向)」は、一見すると発注側に関係のない項目に見えるかもしれません。しかし、参画中のエンジニアが抜ければ、代わりの人員を探し、業務を説明し、開発環境を整え直すところからやり直しになります。

この調査では、参画開始時のオンボーディング資料が不十分だった現場が48.2%にのぼりました。立ち上げに時間がかかる現場ほど、交代のたびに失う工数は大きくなります。継続意向が高いプロジェクトは、人員の入れ替わりが少なく、立ち上がりコストの削減につながるとも言えるでしょう。

とはいえ、そもそも「外注先のエンジニアの評価まで発注側が気にする必要があるのか」と感じる方もいらっしゃるかと思います。その部分についても整理します。

発注側が外注エンジニアからの評価を気にするべきなのか

答えは、この調査が測っているものにあります。本調査で取り扱っているのは、参画したエンジニアが快適に働けたかどうかではありません。そのプロジェクト自体がうまくいったかどうかです。調査では次のように聞いています。

//Q17. このプロジェクトの「プロジェクト自体の成果」への満足度を教えてください。

個人の待遇や気分ではなく、プロジェクトの成否についての評価です。現場で手を動かした当事者が、そのプロジェクトを成功と見ているかどうか、という指標だとお考えください。そして、その成否を分ける要因についても聞いています。エンジニアが挙げた項目は、次のとおりでした。

成果が出やすいPJの特徴割合成果が出にくいPJの特徴割合
コミュニケーションの取りやすさ51.4%人員・スキルの不足45.2%
無理のない計画48.8%コミュニケーションの齟齬40.0%
人間関係の良さ39.2%見積もり工数の甘さ37.6%
要件定義の明確さ37.8%要件定義の曖昧さ・変更の頻発37.4%

※いずれもn=500、最大3つまでの複数回答

技術力の高さでも予算でもなく、発注側のマネジメント判断で動かせる項目が並んでいます。プロジェクトの成否は、こうした運営の質に大きく左右されている。少なくとも、現場のエンジニアはそう見ています。

つまり、エンジニアの評価を気にするというのは、外注先の士気を心配するということではありません。プロジェクトがうまくいっているかどうかを、最も近くで見ている人の目線で確認するということです。

一方で、これはあくまで参画したメンバー側から見た景色です。プロジェクトを動かすリーダー側の視点と重ね合わせることで、成果を出す組織運営の輪郭がより立体的に見えてきます。

▶  PM/PL視点からみた外注活用のポイント」をダウンロードする

▶ 「SES・派遣エンジニア500人に聞いた、成果が出る開発現場の条件」をダウンロードする

評価の不透明さは、単独では起きていない

評価だけを切り出して改善しようとすると、たいてい機能しません。受け入れ全体の状態と連動しているためです。同じ調査では、次のような結果も出ています。

  • 48.2%— 参画開始時のオンボーディング資料が不十分(「あまりなかった」「まったくなかった」の合計)
  • 39.2% — クライアントのPM/PLとの距離を感じた
  • 41.2% — 成果や業務姿勢へのフィードバックがほぼなかった

そして、これらは評価の明確度と強く結びついています。評価基準が明確だと答えた層では、オンボーディング資料が充実していた割合が 69.3%。評価が不明確だった層では 38.5% にとどまります。

PM/PLとの距離感も同様です。PM/PLとの接点があると答えた層で「評価基準が明確」だったのは37.2%。距離を感じている層では12.2% まで下がります。

評価は、評価制度だけで成り立っているわけではありません。情報が渡っていて、接点があって、はじめて基準が伝わるという順序があります。

フィードバックを定期的に設けることで、プロジェクトへの印象は変わる

もっとも実行しやすく、効果が見えやすいのがフィードバックです。成果や姿勢へのフィードバックが「適宜・定期的にあった」層(n=294)と、「まれ・まったくなかった」層(n=206)を比較すると、こうなります。

フィードバックの有無 × プロジェクト成果・継続意向

指標FBあり(n=294)FBほぼなし(n=204)
プロジェクトはうまくいった53.1%23.3%
また参画したい41.8%25.7%

フィードバックの有無で、2.3倍の差です。制度設計も契約変更も必要なく、伝える場を置くかどうかだけでこれだけの違いが出ています。

「評価基準が明確だった」現場が実際にやっていたこと

「評価基準が明確」だと答えた137名に、なぜ「明確だと感じたか」を自由回答で聞いています。そこに書かれていたのは、特別な仕組みではありませんでした。

1.評価が「数値」で出てくる

「毎月同じ基準で数値化された評価がでてくる」― 40代・男性

「定量的な指標の認識合わせができたから」― 30代・男性

2.伝える場が「定期的」に置かれている

「定期的、月に1回は打ち合わせの場があったから」― 50代・男性

「定期的な会議とは別に適宜必要に応じて連絡を取っていた」― 50代・男性

3.基準が「文書」として残っている

「基準がドキュメントされているから」― 50代・男性

「全て文書でやりとりしている」― 40代・女性

「品質基準マニュアルがあった」― 50代・男性

整理すると、「数値化」「定期的な場」「文書化」 の3つです。そしてもう一つ、印象的な回答がありました。

「評価基準がこちらにも展開されていて、納得のいく内容だった」― 40代・男性

評価基準が存在することと、それがエンジニア本人にまで渡っていることは別です。この回答者が「納得のいく内容だった」と書けているのは、中身を読める状態にあったからにほかなりません。裏を返せば、多くの現場では評価が「担当者の頭の中」にあり、「必要が生じたときだけ」「口頭で」伝えられている、ということでもあります。

発注側・受注側、それぞれの打ち手

■クライアント(発注)側のPM・発注担当の方へ

契約や単価に手をつけなくても、明日から着手できる打ち手があります。

1.評価の観点を3つだけ書き出す — 完璧な評価制度は不要です。「何をもって良い仕事とするか」を3項目に絞り、文章にする

2.伝えるタイミングを先に決める — 「必要に応じて」ではなく、月1回など日程を固定する

3.参画初日に基準を渡す — 評価は終わったあとに伝えるものではなく、始まる前に共有するものとして扱う

■開発会社・SES企業側のPL・営業の方へ

評価基準のすり合わせは、提案の価値そのものになります。

1.参画前の商談で「評価の観点」を確認する項目を入れる

2.定例のなかにフィードバックの時間を組み込む提案をする

3.自社メンバーが「何を求められているか分からない」状態を放置しない

エンジニアの定着とパフォーマンスは、送り出したあとの現場設計に大きく左右されます。ここに踏み込めるかどうかが、単なる人員供給との差になります。

調査データの全体像を無料レポートで公開しています

本記事で取り上げたのは、調査の一部です。レポートでは以下を掲載しています。

  • 成果が出る開発現場の条件
  • プロジェクト期間別の満足度・継続意向の推移
  • うまくいった現場/いかなかった現場の特徴
  • 今すぐ取り組める8つのアクション
  • AI活用の現在地

自社の受け入れ体制をどう設計すべきか、個別に相談したい方はお問い合わせください。STELAQは上流から運用まで、チーム単位で開発現場を支援しています。

調査概要
調査対象:現在エンジニアとして働いており、技術者派遣(SES)業務に従事しているエンジニア500名(SES契約77.6% / 派遣契約22.4%)|職種:IT・システム関連|調査時期:2025年10月|調査方法:インターネット調査|設問数:32問(属性含む)|発行:株式会社STELAQ

※「プロジェクトはうまくいった」は、Q17「プロジェクト自体の成果」への満足度で「やや満足した」「かなり満足した」と回答した割合です。その他の指標も同様に、5段階評価のうち上位2段階の合算値です。

関連する他のコラム

ソフトウェア品質に関するあらゆるお悩みを解決します。
サービスに関するご相談など、お気軽にお問い合わせください。