「ITスキル」って何？「プロジェクトマネージャー」とエンジニア」から見たちがい。

ITスキル

IT業界の人材を計るモノサシ、「経歴書」と「単価」

IT業界では、プロジェクトチームを組んで開発や運用保守といった業務を遂行することが多くあります。

プロジェクトによって、クライアントの業界や業種、担当する業務内容が違ってくるため、同じメンバーでプロジェクトチームを組み続ける、ということはあまり多くなく、初対面のメンバーがチームを組んで仕事をしていることのほうが多いのではないかと思います。

ITプロジェクトのメンバー選定は、プロジェクトマネージャーやチームリーダーとエンジニアの面談で決まります

では、プロジェクトメンバーはどうやって選定されているのでしょうか。

多くの場合、プロジェクトマネージャーやチームリーダーのようなプロジェクトを指揮・牽引する立場の人材が、メンバー候補のエンジニアと面談してプロジェクトに対する適性を判断し、アサインの可否を決めていきます。

このとき、面談をする側・受ける側の双方にとって重要な要素となっているのが「職務経歴書」というドキュメントです。

IT業界におけるスキルシートのサンプル
※IT業界でよくある「スキルシート」のサンプル

エンジニアが作成している職務経歴書は「どのような職務を経験してきたか」という、いわゆる「職務経歴」の他に、「どのプログラミング言語の経験があるか」「どのメーカーの機種の経験があるか」を表現する箇所が必ず含まれています。

こうした「プログラミング言語」や「機種」等のことを「要素技術（スキル）」と呼ぶことがあります。

エンジニアの中には、「要素技術（スキル）をたくさん身につけたい」と言い、様々なプログラミング言語を勉強しようとします。その理由は2つあります。

①エンジニアとしての市場価値(単価)が上がる

単価とは、「人月単価」、すなわち、エンジニア1名が1ヶ月間ある案件に専属で稼働した場合の金額のことを言います。

一つの要素技術（スキル）だけ身に着けているより、複数の要素技術（スキル）を身に着けているほうが「より、仕事ができる（だろう）」と判断され、市場価格は上がりやすい傾向があります。

これはあくまで「書面上での値付けが上がる」わけで、実際の仕事振りを見て最終的な単価が決定されるのですが、ただでさえ上げにくい単価を最初から高い状態からスタートできるという意味で、要素技術（スキル）をたくさん身に着けておきたい、という、「値付けを受ける側の論理」は理解できなくはありません。

②未経験だと面談を通過出来ないことが多い

例えば「PHP」をしっかり身につけたエンジニアであっても、開発言語として「Ruby指定」だった場合、その案件には応募しづらいといったことがしばしば起きます。

書類選考だけで落とされてしまうこともああります。プログラミング言語には、それぞれ特徴やクセがあり、未経験者が経験者と同様の仕事振りを発揮するのは困難であることは間違いありませんから、プロジェクトマネージャーやチームリーダーは、未経験者よりも経験者をアサインしたがるものです。

※しかしIT人材不足の昨今、そうは言ってられないので、ある要素技術（スキル）に関して未経験であっても、それまでの経験を元にアサインすることはしばしばありますし、そうやってアサインした人材が力を発揮することも少なくありません。

勉強をせず、それまでに獲得した要素技術（スキル）だけに胡座をかいてしまっていると、いつの間にか「仕事が来なくなる」状況に追い込まれてしまうでしょう。

IT業界で働く者として、常に最新の技術を勉強し、できるだけ複数の要素技術（スキル）を身に着けようとすることは、もはや当然のこととされています。「一生、勉強」などと言われるエンジニア。エンジニアとして生き抜いていくには、研鑽は欠かせないものとなっています。

スキルを持たなことで書類選考落ちになってしまうことも

実際にプロジェクトマネージャーとしてエンジニアを評価してみると…

人が人を評価する。とても難しいことですよね。プロジェクトマネージャーやチームリーダーとして仕事をしていると、どうしても「エンジニア（人）を評価する」というシーンに数多く遭遇します。

そして、悲しいことに「要素技術（スキル）はたくさん身につけているけど、仕事で成果を出せない」というエンジニアが意外にも多いことに気付きます。どうしてそのような「スキルアンマッチ」が起きてしまうのでしょうか。

①要素技術（スキル）を多く身に着けている人材＝高い能力を持っているという「思い込み」

要素技術（スキル）を多く身に着けている場合、「経験豊富」という印象が浮かびます。

そこに「経験豊富なはずなのに、どうしてこれができないんだろう」という、「期待はずれ」感が起きやすくなってしまいます。

職務経歴書をパッと見た時に「経験豊富」という印象がある場合、特にこうした「期待はずれ」という事象が起きてしまうようです。

②要素技術（スキル）だけではプロジェクトは前に進められない

デジタルビジネスにおいて、要素技術（スキル）が最も必要となるのは「製造（プログラミング／エンジニアリング／コーディング）」と呼ばれる作業工程です。

システム開発の領域において旧来からある「ウォーターフォールモデル」によれば、

「要件定義」⇒「基本設計」⇒「詳細設計」⇒「製造」⇒「単体試験」⇒「結合試験」⇒「総合試験」⇒「シナリオ試験」⇒「リリース（カットオーバー）」

となりますから、要素技術（スキル）が必要となる作業工程が局所的であることがおわかりいただけるかと思います。

デジタル・ビジネスの全容
※デジタルトランスフォーメーション（DX）が進んだ現代のビジネス領域における作業工程の例

ですから、要素技術（スキル）だけが高い人材ですと、前後の工程で力を思うように発揮できず、前項のように「期待はずれ」とされてしまうことがあるようです。

集まった人材を適材適所で配置しプロジェクトをうまく回していくのが、プロジェクトマネージャー・チームリーダーの職責ですから、スキルアンマッチが起こってしまったとき、一概にエンジニアのせいだ、とはいい切れません。

プロジェクトにアサインを決定する前に必ず実施される面談で、プロジェクトへの適性を正しく判断していかねばならないのです。

どうすればスキルアンマッチを防げるのか

スキルアンマッチが起きてしまうと、いろいろと大変なことが起こります。要員を交代させなければならない場合は、交代要員の手配（募集をかけ、面談し、決定する）から、交代のための引き継ぎの準備等、タスクが一気に増えてしまいます。

交代させない場合は、当該要員に対して他エンジニアがフォローに回ることもあります。それに、エンジニアも「人」なのですから、スキルアンマッチを言い渡されれば、当然、言い渡された本人は傷つきます。場合により自信を失ってしまい、プロジェクトに参加するモチベーションが大幅に低下してしまうこともあるでしょう。

このように、スキルアンマッチが起きると、プロジェクトの進捗遅延の原因になるばかりでなく、負荷が高まったり、人が傷ついたりと、良いことは何もありません。

このような不幸な事態に陥ることを防ぐためにも、プロジェクトマネージャーやチームリーダーという立場においてエンジニアとの面談は非常に重要な仕事でした。筆者がこれまでに経験してきたプロジェクトにおいて、人材のアサインを決める際に注意していたことをここでご紹介したいと思います。

①職務経歴書の記載内容だけで判断しない

要素技術（スキル）を多く身に着けていることよりも、これまでの経歴の中で、どのような経験を積んだのかが重要です。

要素技術（スキル）は、勉強することで身に着けることが可能です。しかし、「使える要素技術（スキル）」となるのは、なんといっても実際の職務で経験したことで培ったものなのです。

ですから、担当した職務の中で自らの役割は何で、どんなことをミッションとして働いてきたのかを必ず確認します。多くの案件をこなしているベテランエンジニアの方だと「忘れてしまった」とおっしゃる方もいました。そういう方に対しては「プロジェクトに対して熱意を持って取り組んでもらえるのだろうか」と不安になったものです。

熱意を持って取り組んでいれば、どんなに昔のことであっても必ず印象に残っていて、記憶されているはずだからです。