Posted on

いまITエンジニアに求められるスキル(2022年版)

コロナは大変なパンデミックですが、良いこともありました。それは、リモートでも仕事が出来ると認識されて働き方が変わったことです。2020年の後半から約1年間フルリモートでひとつのシステム開発プロジェクトを無事導入まで完遂しました。そこで携わってくれたエンジニアの9割の人と実際に会ったことはないのに、それでも仕事を進められたことでリモートでもオンサイトとなんら変わりなく仕事ができることがわかりました。多少不便なことはあってもそれが当たり前の世界になれば常識となって定着していくと実感しています。
ITエンジニアは、リモートワークの恩恵を特に受けたと思いますが、ラッキーと思って油断していると危険かもしれません。エンジニアを集めチームを組成するプロジェクトマネージャーという立場から言うと、この環境変化によってITエンジニアの置かれた状況はシビアになり、求められるスキルも変わってきています。

単価は低下傾向

2019年の経産省の調査レポートによると、IT人材は2030 年まで増加傾向になると見られています。ITの需要は高い水準を維持しているものの環境変化と人材増加によってエンジニアの単価は、低下傾向になると考えます。


理由①:地理的な優位性の低下
リモートワークが当たり前になった今では、オンサイトとオフショア、ニアショアの差はほぼなく、日本語ができて時差も少なければ沖縄や札幌はもちろん海外から仕事をするのと、都内からするのとで違いはありません。以前は、クライアントのオフィスや開発拠点の通勤圏内で開発ベンダーを探していたのに、今は全国から、もっと言うと全世界からエンジニアを探すことができます。地理的な優位性がなくなったため、東京のエンジニアだから高い、オフショア、ニアショアだから安いといった方程式は使えなくなっています。
これまでもオフショアやニアショアとはリモートでしたが、それなりの規模がないと費用対効果が得られなかったのが、今やフリーランスでも数名のベンダーにも活用の幅は広がっていて、もはやオフ、ニアという概念すらなくなっています。固定費の安い地方や海外のエンジニアが安い単価で提供すれば、価格競争が激しくなり平均単価も安くなっていきます。


理由②:供給量の増加
ITに強い外資系コンサルや国内大手SIerは常にエンジニアを大量募集しています。その背景には、2025年の崖やDX推進など事業会社のIT投資が高い水準を維持している状況があります。DXの高いニーズに加えて基幹システム刷新など従来型のプロジェクトでも募集が絶えないため、エンジニア不足は今後も続くと予想されます。この需要増を狙ってかはわかりませんが、経産省のレポートにある通り新卒IT人材と他業種からのキャリアチェンジ人材によりエンジニアの供給量も比例するように高まっています。
DXエンジニアや一部のスーパーエンジニアが高単価となる一方で新規ITエンジニアは安い単価で大量投入されるため、単価差は広がりつつも全体的に見ると平均単価は低下傾向になっていくと思います。

ITエンジニア戦国時代

全世界からエンジニアを集められる状況では、未熟なエンジニアは低単価の中で激しい競争を強いられ、ベテランエンジニアは高スキル者と比較されることになります。ITに馴染みのある若年世代は、勘所も良く成長も早く、これまでの慣習や固定概念にも縛られないため即戦力となるのも早いです。エンジニアという職を名乗る人に会社の地位や役職は関係なく、年功序列もありません。今後は、どんなスキルレベルのエンジニアも評価対象が全国全世界に広がり、ベテランと新人が入り交じる中で競争が行われます。
ここ数年、システム開発会社は地方や海外に続々と拠点を設立していますし、地方を主戦場としていた開発ベンダーもその土地にこだわることなく都内の案件に営業をかけてきます。
これまで地方大会で戦っていればよかったものが、いきなり全国大会に出場し、全国の猛者と戦わないといけない、まさにITエンジニア戦国時代の到来です。

ますます求められる工程マルチの技術力

システム開発プロジェクトを請け負うベンダーは、プライムであれば要件定義から始めて導入まで、サブコンだとしても出来るだけ長い期間プロジェクトに携わることを求めています。昨今は、ウォーターフォール型のプロジェクトであっても、要件を固めたらその範囲しか設計しません、仕様を決めたら一切の変更を認めませんという厳格なスタイルから一定の要件追加や仕様変更を許容して進めるスタイルに変化してきています。
これまでの厳格な進め方では、設計はSE、開発はプログラマー、テストはテスターといった工程毎に必要なエンジニアを調達することも多かったですが、変更を許容する進め方では、設計も開発も出来る、テストケースも挙げられる工程全般の技術力をもったエンジニアが活躍するようになってきています。アジャイル開発によって注目されたフルスタックエンジニアは、大規模なウォーターフォール型のプロジェクトでも重宝される存在なのです。
設計にはロジカルに整理する力、網羅的にケースを洗い出す力が必要なため、設計が上手なエンジニアは開発力も高いです。今の時代、レベルはそこそこでも工程マルチのスキルを持ち、長い期間フレキシブルに活躍できるエンジニアの貢献度が高くなっています。

ますます求められる工程マルチの技術力

システム開発プロジェクトを請け負うベンダーは、プライムであれば要件定義から始めて導入まで、サブコンだとしても出来るだけ長い期間プロジェクトに携わることを求めています。昨今は、ウォーターフォール型のプロジェクトであっても、要件を固めたらその範囲しか設計しません、仕様を決めたら一切の変更を認めませんという厳格なスタイルから一定の要件追加や仕様変更を許容して進めるスタイルに変化してきています。
これまでの厳格な進め方では、設計はSE、開発はプログラマー、テストはテスターといった工程毎に必要なエンジニアを調達することも多かったですが、変更を許容する進め方では、設計も開発も出来る、テストケースも挙げられる工程全般の技術力をもったエンジニアが活躍するようになってきています。アジャイル開発によって注目されたフルスタックエンジニアは、大規模なウォーターフォール型のプロジェクトでも重宝される存在なのです。
設計にはロジカルに整理する力、網羅的にケースを洗い出す力が必要なため、設計が上手なエンジニアは開発力も高いです。今の時代、レベルはそこそこでも工程マルチのスキルを持ち、長い期間フレキシブルに活躍できるエンジニアの貢献度が高くなっています。

チームパフォーマンスの向上に価値あり

リモートワークによる調達エリアの拡大と新規ITエンジニアの増加により、スキルレベルや文化にばらつきがある烏合の衆のエンジニア集団でプロジェクトを組成することが増えてきています。このような体制面の変化によって、上級エンジニアに求められる価値も変化しています。
これまでの上級エンジニアは、知識と経験に基づく問題解決力を売りにした高いスキルを持つスペシャリストタイプでしたが、今は未熟なエンジニア集団を統率しチームとしてのパフォーマンスを向上させることができるリーダーエンジニアが求められています。
メタバースの進化によってリモートでもオンサイトと同じような感覚で働くことができるかもしれませんが、現時点ではスキルの高い熟練のエンジニアにとっては作業に専念できる好都合な環境である一方で、気軽に相談したり手書きメモやホワイトボードを使いながら理解を深めたりといったことが難しいため未熟なエンジニアにとってリモートワークは優しくない環境です。
リーダーエンジニアは、リモートだとしてもメンバーとのコミュニケーションを上手くとり、未熟さをフォローしてチームとしてパフォーマンスを引き出すことができる人です。
予算に余裕があれば多少単価が高くてもスキルのあるエンジニアを集めた方が良いに決まっていますが、クライアントからのコストプレッシャーを考えると、単価の安い未熟なエンジニアを入れた体制とならざるを得ません。このような体制にチームビルドできるリーダーエンジニアが入ることでレバレッジの効く体制となり、低コストを実現しつつもプロジェクト推進の柔軟性が高まります。

開発スキルよりも大切な4つの力

プロジェクトにいる全てのエンジニアが高い開発スキルを持ち合わせていることはまずありません。性格も含めて一長一短ありつつも皆似たり寄ったりのスキルであることの方が普通です。そんな中で相対的に高評価となるエンジニアは、開発スキル以外に4つの能力を持つ人材です。


①日本語力(超大事)
SaaS、ローコード、ノーコードの台頭によって設計書を書くことが以前に比べて減ってきたとは言え、プロジェクトを推進するうえでは、クライアントやリーダー、メンバー同士のコミュニケーションは必要です。
4人参加している会議を2時間やれば合計で8人時間、つまり1人日分のコストを使っていることになります。この2時間を伝わらないコミュニケーションで終始されて結論も出ないままに終わってしまえば1人日分のコストを失う実害が出てしまいます。プログラミングだけをお願いするのであれば設計書を介して会話ができますが、工程マルチが当たり前になってくるとコミュニケーションの量も質も変わるため、今後はさらに日本語力が必要になってきます。


②注意力
システム改修案件で設計書をリバイズする時に「既存の設計書がこうなっていたのでそのままにしています」と間違いや誤解を招く記述に気が付いているのに平気でそのまま放置したり、レビューで指摘したことを修正するも影響箇所を見落としていて再レビューになったりする人よりは、気が付ける人の方が一緒に仕事をしていて気持ちが良いです。


③適応力
プロジェクトによってもPMによっても進め方や管理の仕方は違い、タスクを細分化して厳格に管理するプロジェクトもあれば、エンジニアに自由にやらせる方針のプロジェクトもあります。違いはあれど進捗管理や文書管理などあらゆる管理方法がプロジェクトのルールとなります。プロジェクトのやり方に合わせられずに自分の好きなやり方で進めてしまう人に、いちいちルール違反を指摘するのも面倒だし、インシデントなど重大事故を引き起こされたら堪ったもんじゃありません。スキルが高くてもルールを守れない人よりルールの中でうまく力を発揮する人の方が安心できます。


④想像力
システムの使われ方を一切考えずにプログラミングだけで勝負できるのはスーパープログラマーだけです。この機能がどのように使われるか、誰がどんな業務で使うか想像力を働かせることは、プログラマーでもテスターでも必要です。
ユーザーの使い方を想像して実装につなげていかないと全く気の利かない使えないシステムになってしまうため、利用者視点や他機能への影響など想像力は全てのエンジニアに、もっと言えば知恵を使うことで成長してきた人類の、あらゆる職種の人に必要です。

まとめ

エンジニアは、スキルを自己評価することが難しいです。チームの中では優秀でも、実はそのチームにいるエンジニアのレベルが低いだけかもしれません。それはそれで居心地は良いのですが、別世界に行ったら奈落の底に落とされるかもしれません。
昔は転職回数が多いと、長続きしない人と思われて敬遠される傾向にありましたが、今の時代、特にエンジニアであれば、様々な業界と仲間で経験してきたことは、日本語力や適応力の幅を広げられ自己評価も正しくできるため歓迎されるべきことです。
リモートワークによる環境変化と次々と新規エンジニアが誕生する今、外の世界を見なければ「井の中の蛙、大海を知らず」となってしまうかもしれません。

出典:柴田秀夫@ARAKADO※転載は筆者承諾済