「ITスキル」って何？ 「プロジェクトマネージャー」とエンジニア」から見たちがい。
IT業界の人材を計るモノサシ、「経歴書」と「単価」
IT業界では、プロジェクトチームを組んで開発や運用保守といった業務を遂行することが多くあります。
プロジェクトによって、クライアントの業界や業種、担当する業務内容が違ってくるため、同じメンバーでプロジェクトチームを組み続ける、ということはあまり多くなく、初対面のメンバーがチームを組んで仕事をしていることのほうが多いのではないかと思います。
では、プロジェクトメンバーはどうやって選定されているのでしょうか。
多くの場合、プロジェクトマネージャーやチームリーダーのようなプロジェクトを指揮・牽引する立場の人材が、メンバー候補のエンジニアと面談してプロジェクトに対する適性を判断し、アサインの可否を決めていきます。
このとき、面談をする側・受ける側の双方にとって重要な要素となっているのが「職務経歴書」というドキュメントです。
※IT業界でよくある「スキルシート」のサンプル
エンジニアが作成している職務経歴書は「どのような職務を経験してきたか」という、いわゆる「職務経歴」の他に、「どのプログラミング言語の経験があるか」「どのメーカーの機種の経験があるか」を表現する箇所が必ず含まれています。
こうした「プログラミング言語」や「機種」等のことを「要素技術（スキル）」と呼ぶことがあります。
エンジニアの中には、「要素技術（スキル）をたくさん身につけたい」と言い、様々なプログラミング言語を勉強しようとします。その理由は2つあります。
①エンジニアとしての市場価値(単価)が上がる
単価とは、「人月単価」、すなわち、エンジニア1名が1ヶ月間ある案件に専属で稼働した場合の金額のことを言います。
一つの要素技術（スキル）だけ身に着けているより、複数の要素技術（スキル）を身に着けているほうが「より、仕事ができる（だろう）」と判断され、市場価格は上がりやすい傾向があります。
これはあくまで「書面上での値付けが上がる」わけで、実際の仕事振りを見て最終的な単価が決定されるのですが、ただでさえ上げにくい単価を最初から高い状態からスタートできるという意味で、要素技術（スキル）をたくさん身に着けておきたい、という、「値付けを受ける側の論理」は理解できなくはありません。
②未経験だと面談を通過出来ないことが多い
例えば「PHP」をしっかり身につけたエンジニアであっても、開発言語として「Ruby指定」だった場合、その案件には応募しづらいといったことがしばしば起きます。
書類選考だけで落とされてしまうこともああります。プログラミング言語には、それぞれ特徴やクセがあり、未経験者が経験者と同様の仕事振りを発揮するのは困難であることは間違いありませんから、プロジェクトマネージャーやチームリーダーは、未経験者よりも経験者をアサインしたがるものです。
※しかしIT人材不足の昨今、そうは言ってられないので、ある要素技術（スキル）に関して未経験であっても、それまでの経験を元にアサインすることはしばしばありますし、そうやってアサインした人材が力を発揮することも少なくありません。
勉強をせず、それまでに獲得した要素技術（スキル）だけに胡座をかいてしまっていると、いつの間にか「仕事が来なくなる」状況に追い込まれてしまうでしょう。
IT業界で働く者として、常に最新の技術を勉強し、できるだけ複数の要素技術（スキル）を身に着けようとすることは、もはや当然のこととされています。「一生、勉強」などと言われるエンジニア。エンジニアとして生き抜いていくには、研鑽は欠かせないものとなっています。
実際にプロジェクトマネージャーとしてエンジニアを評価してみると…
人が人を評価する。とても難しいことですよね。プロジェクトマネージャーやチームリーダーとして仕事をしていると、どうしても「エンジニア（人）を評価する」というシーンに数多く遭遇します。
そして、悲しいことに「要素技術（スキル）はたくさん身につけているけど、仕事で成果を出せない」というエンジニアが意外にも多いことに気付きます。どうしてそのような「スキルアンマッチ」が起きてしまうのでしょうか。
①要素技術（スキル）を多く身に着けている人材＝高い能力を持っているという「思い込み」
要素技術（スキル）を多く身に着けている場合、「経験豊富」という印象が浮かびます。
そこに「経験豊富なはずなのに、どうしてこれができないんだろう」という、「期待はずれ」感が起きやすくなってしまいます。
職務経歴書をパッと見た時に「経験豊富」という印象がある場合、特にこうした「期待はずれ」という事象が起きてしまうようです。
②要素技術（スキル）だけではプロジェクトは前に進められない
デジタルビジネスにおいて、要素技術（スキル）が最も必要となるのは「製造（プログラミング／エンジニアリング／コーディング）」と呼ばれる作業工程です。
システム開発の領域において旧来からある「ウォーターフォールモデル」によれば、
「要件定義」⇒「基本設計」⇒「詳細設計」⇒「製造」⇒「単体試験」⇒「結合試験」⇒「総合試験」⇒「シナリオ試験」⇒「リリース（カットオーバー）」
となりますから、要素技術（スキル）が必要となる作業工程が局所的であることがおわかりいただけるかと思います。
※デジタルトランスフォーメーション（DX）が進んだ現代のビジネス領域における作業工程の例
ですから、要素技術（スキル）だけが高い人材ですと、前後の工程で力を思うように発揮できず、前項のように「期待はずれ」とされてしまうことがあるようです。
集まった人材を適材適所で配置しプロジェクトをうまく回していくのが、プロジェクトマネージャー・チームリーダーの職責ですから、スキルアンマッチが起こってしまったとき、一概にエンジニアのせいだ、とはいい切れません。
プロジェクトにアサインを決定する前に必ず実施される面談で、プロジェクトへの適性を正しく判断していかねばならないのです。
どうすればスキルアンマッチを防げるのか
スキルアンマッチが起きてしまうと、いろいろと大変なことが起こります。要員を交代させなければならない場合は、交代要員の手配（募集をかけ、面談し、決定する）から、交代のための引き継ぎの準備等、タスクが一気に増えてしまいます。
交代させない場合は、当該要員に対して他エンジニアがフォローに回ることもあります。それに、エンジニアも「人」なのですから、スキルアンマッチを言い渡されれば、当然、言い渡された本人は傷つきます。場合により自信を失ってしまい、プロジェクトに参加するモチベーションが大幅に低下してしまうこともあるでしょう。
このように、スキルアンマッチが起きると、プロジェクトの進捗遅延の原因になるばかりでなく、負荷が高まったり、人が傷ついたりと、良いことは何もありません。
このような不幸な事態に陥ることを防ぐためにも、プロジェクトマネージャーやチームリーダーという立場においてエンジニアとの面談は非常に重要な仕事でした。筆者がこれまでに経験してきたプロジェクトにおいて、人材のアサインを決める際に注意していたことをここでご紹介したいと思います。
①職務経歴書の記載内容だけで判断しない
要素技術（スキル）を多く身に着けていることよりも、これまでの経歴の中で、どのような経験を積んだのかが重要です。
要素技術（スキル）は、勉強することで身に着けることが可能です。しかし、「使える要素技術（スキル）」となるのは、なんといっても実際の職務で経験したことで培ったものなのです。
ですから、担当した職務の中で自らの役割は何で、どんなことをミッションとして働いてきたのかを必ず確認します。多くの案件をこなしているベテランエンジニアの方だと「忘れてしまった」とおっしゃる方もいました。そういう方に対しては「プロジェクトに対して熱意を持って取り組んでもらえるのだろうか」と不安になったものです。
熱意を持って取り組んでいれば、どんなに昔のことであっても必ず印象に残っていて、記憶されているはずだからです。
②担当職務の中での失敗事例・成功事例を聞く
前項にも少し絡んできますが、担当した職務の中でどんな失敗をし、その時何を考え、どう切り抜けたのか。成功事例であれば、どんな工夫をしたことが成功につながったのか。そうしたことを聞きます。
これが答えられないエンジニアは、どんなに要素技術（スキル）を多く持っていても、アサインしないことすらありました。
失敗・成功の事例を自ら振り返り、自らの糧とすることが出来ていない人材は、仮に今回のプロジェクトに着任したとしても、同じ失敗を繰り返してしまう可能性がありますし、振り返りをしないということは、いわゆる「PDCA」の概念を仕事上活かすことができないのだろう、と考えるからです。
③理解力
これは面談全体を通して気をつけていることですが、「質問に対する答えの的確さ」を見ています。
こちらが期待する答えと全く異なることを答えたり、話を逸しているかのような会話が続くと、面談結果をNGとすることが多くありました。プロジェクトにアサインしたとしても、コミュニケーションがうまく行かず、結果としてスキルアンマッチに繋がりかねないからです。
職人気質のあるエンジニアの中にはいわゆる「口下手」な方もいらっしゃいますが、様々な話題を振ることで、回答が的確であるかを判断するようにしていました。
これからのIT時代を生き抜いていくために身に着けるべきスキルとは？
「手に職を付ける」という言葉があります。そこに「働き方改革」「ホラクラシー」「副業解禁」「小学校教育に英語とプログラミングが取り入れられる」という動きが時代のうねりとともに流れ込み、にわかに「要素技術（スキル）を身に着けなければ」という焦燥感を覚える方が増えたように感じます。
要素技術（スキル）は、それそのものは身に着けられるなら身に着けておいて損になることは間違いなくありません。
身に着けているからこそ得られる仕事や、人生の選択肢があるからです。
しかし、「要素技術（スキル）」だけに固執し、振り回されていないでしょうか。
要素技術（スキル）を、一つ一つ「点」で捉えていないでしょうか。
デジタルトランスフォーメーション（DX）が進み、IT業界に限らず非IT専業の企業活動においてもITが深く浸透した今日では、ITに関わる要素技術（スキル）の有無は確かに重要です。
ただし、より重要なのは、いかにその要素技術（スキル）を駆使するか、という、「上流工程」であり、エンジニアにもIT以外の広い視野が求められるようになっています。
ビジネスに人が関わるからこそ、人の興味関心といったことを学ぶのも重要ですし、ビジネスの背景や経緯・将来像といった、ビジネスの全体・概要を把握する力をこそ身に着けていくことが大事です。
プログラミングやデザインツールという局所的な要素技術（スキル）を点で捉えるのではなく、ビジネス全般を俯瞰して捉えることができる要素技術（スキル）として、点と点を結び、線・面で捉えていく。
次世代を生き抜いていくのに必要な要素技術（スキル）とは、本質のところではそうした「総合的なスキル＝ユニファイド・スキル」なのかもしれません。
著者：新村 繁行 ▶ セブ島のIT留学「アクトハウス」を詳しく見る
