こんにちは、WhiteBox広報です。
元インフラエンジニアで、スキルシートを書いたことがない私ですが、とあるSIerで働くエンジニア（仮名：スクラムマスターA）さんに取材をする機会があり、そのときに得た情報をまとめてみました！
これからスキルシートを更新しようとしているエンジニア、もしくはSES営業の方のお役に立てれば幸いです！
それではいってみましょう！
目次
ちょっとしたスキルでも書いちゃおう！
エンジニアはプログラム言語以外のスキルをちゃんとスキルシートに書いているか？っというのは重要な視点だそうです。
それはツールやフレームワークなどのことを指しているのですが、世の中のエンジニアさんたちのほとんどは、スキルシートにそこまで記載しないようです。
驚いたことに、この「ちょこっとしたスキル」をクライアントは注視しているということです！それが決定打になり入場が決まるケースが往々にしてあるようで、見逃せないファクト情報です。
とあるケースをご紹介しますと・・・
Javaを欲しがるクライアントの元には、多くのJavaエンジニアが応募してきます。
（当然ですが。。。）
そのときにクライアントが最終的にエンジニアを選択する際に、何を見ているのかというと、＋αがあるかどうか、だそう。
その＋αの要素としては、人柄やチームに馴染めそうかなどの評価ポイントがあるのは当たり前ですが、「必須スキル以外に何のスキルを持っている人なのか？」だそうです。
一例をあげますと、現状はオンプレでシステムを組んでいたとしても、「近い将来、AWSに移行したい」と密かにクライアントが思っているかもしれない。そうなるとクライアントは自然とAWSのスキルを持っている人間を意識する。
この場合でいくと、Javaの開発経験があり、かつAWSの開発経験もある、
なんて人がいたら”おっ”っと目に留まるわけです。つまり、クライントが心の奥底で何を考えてスキルシートを見ているかは分からないんです。
だからこそ、ちょっとしたスキルでも書こう！が鉄則だと、スクラムマスターAさんは語ってくれました。
“何が刺さるか分からないのだから、網は大きく広げておくに越したことはない。”
SES営業担当者の方も含め、スキルシートを書くすべての方にお伝えしたいのでは、「ちょっとしたスキルでも書くよう」にしていただければ、チャンスのとりこぼしが減るかもしれませんね！
「早く言ってよ〜😭」SES営業担当の悲劇＜スキルシート事件簿＞
筆者がSES営業担当者から聞いたエピソードをご紹介します。
結論からいうと、案件受注を逃したときのエピソードです。
とある案件に応募するのですが、先方からの条件としては、必須スキルにJava8.0とJavaのフレームワークのSpringのスキルが必須というものでした。
必死に自社エンジニアのスキルシートをみても、Java8.0とSpringの両方のスキルを持ったエンジニアがいなかったそうです。オフィスにはエクセルファイルをダブルクリックするクリック音だけが響き渡りました。
当時、時間も迫っていた中で、SES営業担当者もエンジニア一人一人に声をかけて確認するわけにもいかなったようです。そのため、スキルシート上で保有スキルを判断するしかなく、どのスキルシートも必須条件を満たせていませんでした。
とはいえ、数少ない優良案件で、かつ時間の猶予がなかったSES営業担当者は、
必死に電話しエンジニアのポテンシャルを買って欲しいと食い下がりました。しかしクライアントの答えはNoです。
無理もありません。クライアントは ”今” のスキルを買いたいんですものね。
後日、そのSES営業担当者が、自社のエンジニアと話をする機会があり、その際に「Spring使ったことありますよ」っとエンジニアに言われたそうな。。。
「早く言ってよ〜」っというSES営業担当者のため息と共に、後悔ばかりが押し寄せたそうです。営業側からすれば「経験したことあるスキルは何でも書いてよ！」なのですが、エンジニアからすると「スキルシートってそこまで細かく書く必要あるの？」という意見でした。
両者のボタンのかけ違いが原因で起きた悲しい事件でした。
このエピソードを聞いたとき、私としてはエンジニアさん側の意見に同感でした。
何せ私も、エンジニア時代はスキルシートを書いたことがなかったですし、そもそも存在すら知りませんでした笑
なので、エンジニアの中にはスキルシートに何をどう書いたら良いのか分からない人は少なからず存在するかと。
SES営業担当者の方が、この状況を改善し、売上を上げていくには、
エンジニアとコミュニケーション量を増やし、スキルシートをバージョンアップしていくことが最初の第一歩かと思います。
下請けエンジニアの主張！
「少ししか触ったことがない言語やツールは絶対にスキルシートに書かないし、言わないよ」 とある下請けエンジニアの彼は私にそう語りました。
それを聞いた私は続けて、その理由を尋ねました。
「ちょっとしたスキルでも書こう！」と前置きしたのですが、
彼曰く、スキルシートに “スキルを書かない” エンジニアには２パターンあるということなのです。
その２パターンとは、
パターン１、ただ単純に書くことの意義を知らない
パターン２、書くことで自分に不利益があるから
１に対しては、意義を伝えて啓蒙していけばよい話ですが、問題は２なんです。
２でいうところの不利益というのは、「現場での仕事が増える」ということだそうです。
っというのも、
知見の浅いスキルを書いてしまうと、
クライアントからは”できる”と思われてしまうのです。
そうなるとエンジニアが入場後にどうなるかというと、
現場のクライアントから、“あの人ならできる”という目で見られてしまい、
どんどん仕事が舞い込むようになるんだそうです。
そうなるとエンジニアは、ある悪循環に頭を悩ませることになります。
●現場で仕事が増える
↓
●身を削って仕事せざるを得なくなる
↓
●でも給料上がらない
↓
●でも評価されない
っという悪循環に陥ってしまいます。
つまり、自分の首を締めることになると、エンジニアたちは分かっているのだそうです。
この傾向は、生産性の良いエンジニアにも当てはまることが多いようです。
彼らは現場で、仕事のスピードをコントロールしています。
それもそのはず、仕事を効率良く処理しても、次なる仕事が回されて、
下手をすると炎上プロジェクトの手伝いまでやらされることになるそうです。。。
本来は２〜３時間で終わる仕事を、きっちり定時まで時間をかけて終わらせて退社する。こういうことをしているエンジニアも実際にいるようです。
エンジニアが自己防衛のことを考えなければならないという現状を知り、
SES業界の影の部分を垣間見ました。
ITをつくっているエンジニアの労働環境の改善をしないと、昨今叫ばれているIT投資効率の低さは改善されていかないと思いました。
ある種、エンジニアは被害者なのかもしれません。
バージョン情報を書くことで受注につながる！？
スキルシートのテクニックをもう一つご紹介したいと思います。
それは「バージョン情報を書け！」です。
スクラムマスターAさんの会社では、エンジニアに「言語やフレームワークなど、可能な限りバージョン情報まで書け！」と指導しています。
え？そんなこと？っと私は不思議に思ったのですが、スクラムマスターAさんが所属する会社で起きた、あるエピソードがキッカケだったそうです。
とあるクライアンにエンジニアを提案したときの話です。
Javaのエンジニアを探していたクライアントに、SES営業担当者は自信をもってJavaのスペシャリストを提案したそうです。
経験年数、コミュニケーション力も申し分なく、受注できると踏んでいたSES営業担当者の顔は、数日後に真っ青になりました。
そう、面談にすら呼んでもらえなかったんです。
何が原因だったのか？
それはクライアント内部で起きているバトンリレーが原因だった。
各プロジェクトのプロジェクト責任者は、自分のプロジェクトに人手が欲しくなったときに、自社の別部門である購買部（仕入れ、または仕入れの審査や管理をする部署）に依頼を出します。
その依頼というのは、「Java8.0ができるエンジニアがほしい」という内容です。
すると、購買部の担当者は「Java8.0」というキーワードを頼りにエンジニアを探し始めます。
もしこの担当者が、「Java」としか書かれていないスキルシートをみたときには、まず書類審査で落とされてしまいます。
ちょっとまって！電話確認すれば良いんじゃない？っという声が聞こえてきそうですが、そうもいかない事情があるようです。
クライアントの購買部には、SES企業から何百というエンジニアの提案メールが押し寄せてきます。
そんな状況に置かれている担当者が、Javaとしか書かれていないスキルシートをみてSES企業に確認を取ると思いますか？
そう、答えはNoなんです。
こうして、SES営業担当者は案件を逃し、会社の利益を逃し、さらにエンジニアはキャリアを築けず、みんな損をしてしまうのです。
バージョン情報を書いていなかっただけで、です。
エンジニアが一番、バージョン情報を気にしている？
ここまではクライアント視点についてご説明しましたが、エンジニア視点ではバージョン情報ってどう見えているのでしょうか。
何人かのエンジニアに質問して回ったのですが、皆さん「重要」とのお答えでした。
特に、メインバージョンが変わってくると、使える関数が違ってきたり、動作させる上での扱い方が大きく変わったりするケースがあるからです。
分かりやすい例をあげると、Windows7を使い慣れたユーザーが、Windows8にアップデートした場合はUIがかなり様変わりしていたり、一瞬別物のような印象を受けた方もいるのではないでしょうか。
そうすると、画面の解像度を変えようとして「コントロールパネル」を発見することができず、時間がかかったりします。まさしく扱い方自体が変わってしまったために、ユーザーが迷ってしまうレベルです。
話が脱線してしまいましたので、先ほどのJavaエンジニアの話に戻します。
Java 7.0は経験があるけど、Java 8.0は経験がないエンジニアは、いきなりJava 8.0を使えるのでしょうか？それはNoです。
より正確に言うと、「バージョンアップによる違いを把握していないから扱えない」ということです。
Java 8.0の場合、新たに使えるようになった新機能があり、かつその機能が重宝されてりる開発現場だったりすると、Java 8.0を触ったことがないことによるリスクは大きくなります。
エンジニアがキャッチアップするまでの間は、生産性はあがらないことは容易に想像がつきます。言い換えると、プロジェクトに遅延が発生する可能性が出てくることでもあり、プロジェクト責任者からすれば見過ごせない問題です。
そのためJava 7.0を使ったことがあるならJava 8.0も扱えるんでしょ？という安易な考えはキケンです。エンジニアの技量にもよるかもしれませんが、キャッチアップには時間がかかり、プロジェクト全体に遅延を与えることにもなります。
だからこそ、クライアント側はバージョン情報を気にします。また、即戦力を期待しているケースが多いでしょう。
たかが、バージョン、されどバージョン。
バージョン情報というのは、プロジェクトに与えるインパクトは大きいのです。
SES企業の営業担当者はバージョン情報を気にしているか？
では最後になりますが、SES企業の営業担当者の視点からはどうでしょうか。
はたしてバージョン情報の記載を気にしているのでしょうか。
私が今まで取材してきた限りにおいては、多重下請け構造の深いレイヤーに属するSES企業（3次請け・4次請け）のSES営業担当者達は、あまり気にしていないと感じています。
というのも、その方たちにとっては、目先の稼働をきっちり決めることが一番重要なので、
スキルシートは二の次になってしまいがちというのが私の所感です。
そこには、中小SES企業にとって、空き稼働が死活問題になっている現実があります。
SES営業担当者が置かれている状況は、マズローの欲求段階説を例にすると「生理的欲求」が脅かされている状況と言ってもよいかと思います。
どれくらい死活問題か、実際にエンジニアの単価を元に試算してみます。
ここでは、3次請けSES企業を例にします。
雇用しているエンジニアに支払っている給料は平均60万円程です。
では、2次請けSIerにエンジニアの単価をいくらで提案しているかというと、65万円前後です。
SES業界を知らない人は驚かれるかもしれませんが、会社の利益は本当にこの5万円の部分のみです。
このような薄利の中、もし1ヶ月でも空き稼働が出るとどうなるのでしょうか？
60万円の損失が出ることに、取り返すためには１年（※60万÷5万で算出）かかる計算です。
1ヶ月の空き稼働分を取り戻すのに、１年かかるってかなり壮絶です。
会社にとって大打撃です。
そのため、空き稼働を作ってしまったSES営業担当者は、経営者からめちゃめちゃ詰められるという話を良く耳にします。だからSES営業担当者は意地でもエンジニアの稼働を決めて、数字を作ろうとします。
正直な話、エンジニアの能力で差別化して案件を決めるのは難しいです。
じゃあどうするのかというと、単価を下げざるを得ないです。
それでも案件が決まるかどうかという瀬戸際で、SES営業担当者は必死に営業電話をかけまくる等をして、提案活動をバリバリやります。
極端な話をすると、先月までラーメン屋だったエンジニアだとしても、稼働を決めるといった具合です。その結果、大手優良企業のシステム開発を元ラーメン屋のエンジニアが開発しているケースが存在したりします。
これが良いか悪いかは置いておき、今のSES業界ではこれが日常茶飯事です。
しかし、それが故にある問題が起きます、
SES営業担当者が苦労して稼働を決めたとしても、アサイン先の現場では高確率でトラブルが発生します。 いわゆる”炎上”です。現場に入ってから、エンジニアのスキルがアンマッチであることが発覚する等して、炎上するケースがあります。
この状況から、エンジニアの正確なスキルシートがクライアントに渡っていたのか疑わしいかもしれません。
ここには、スキルシートの質が二の次にされてしまっている現実があるかと私は思います。それこそ、バージョン情報がスキルシートにちゃんと記載されているかなんて、期待できるはずもありません。
最後は少し暗い話になりましたが、スキルシートを充実させることは、案件の受注だけでなく、エンジニアが成長できるプロジェクトへの配属にもつながっていきますので、定期的な見直しをお勧めいたします。
私が書いたこの記事が、スキルシートを武装する足がかりになれば幸いです！
（※編集部注：本コラムは執筆者の個人の考えによるものです。当サイト・運営会社の見解ではありませんので、予めご了承ください。）
▼編集部便り
本コラムは、SES業界に関連した事項を中心に、いろいろな方の見解を掲載しております。現在、本編集部ではコラムを寄稿してくださる方を募集中です。お問い合わせフォームよりご連絡ください。
