はじめに
私は、ITエンジニアとして25年以上、この業界で仕事をしてきました。
その間、決して平坦な道のりだったわけではありません。技術トレンドの移り変わりに翻弄されたり、難しいプロジェクトで頭を抱えたり、時には自分の力不足を痛感することもありました。それでも今、この仕事を楽しく続けられていますし、どんな困難な状況に直面しても、なんとか成果を出せるという自信もついてきました。
もちろん、ITスキルそのものはとても重要です。新しい技術やツールに触れ、学び、使いこなしていく過程は、今でも純粋に楽しいと感じています。この気持ちは、25年経った今も変わりません。
しかし、これまでのキャリアを振り返ってみると、あることに気づきます。一流のエンジニアとそうでないエンジニアを分けているのは、実はITスキルそのものではなく、その"手前"にある、もっと別のスキルだった、ということです。
技術力は大切な武器です。しかし、それを使いこなし、活かしきるためには、技術力とは別の土台が必要になります。この記事では、私が25年の経験の中で実感してきた「技術力より重要なスキル」を、あらためて整理してお伝えしたいと思います。
第7位から、カウントダウン形式で紹介していきます。
あくまでも私の主観でありますので、その点はご容赦ください。
7位：独学力
IT業界の技術は、次から次へと新しいものが登場します。数年前まで常識とされていた技術やアーキテクチャが、あっという間に過去のものになることも珍しくありません。
この絶え間ない変化に対応し続けるためには、誰かに教えてもらうのを待つ姿勢では追いつけません。自分で学ぶべきものを見つけ、自分のペースでキャッチアップし続ける力、すなわち独学力が欠かせません。研修や資格制度がどれだけ整っていても、最終的に技術を血肉にできるかは、本人の独学力次第です。ITエンジニアとして一時的に活躍するだけでなく、このキャリアを末長く続けていくために、避けて通れない能力だと考えています。
私自身、キャリアのスタートから6年間、COBOLのプロジェクトに携わっていました。ここから先のキャリアチェンジを本気で考えた結果、当時トレンドだったJavaやオブジェクト指向をひたすら独学しました。その後、Javaプロジェクトに参画し、実際に成果を出すことができました。この経験を通じて、私の中で「プロジェクトを通じて新技術の経験を得る」という考え方から、「独学で学んだ技術をプロジェクトに貢献する」という考え方へと変わっていきました。
生成AIがコードを書いてくれる時代になり、「もう自分で学ばなくてもAIに聞けばいい」と感じる場面も増えました。ただ、AIが出してくる答えの妥当性を判断し、自分の血肉として使いこなせるようになるには、結局のところ自分自身の学ぶ力が土台として必要です。むしろAI時代だからこそ、「何を学ぶべきか」「AIの回答をどう検証するか」を見極める独学力の価値は、下がるどころか上がっていると感じています。
おすすめ書籍
独学力を鍛えるにあたって、私が特におすすめしたいのがこちらの一冊です。
SOFT SKILLS ソフトウェア開発者の人生マニュアル 第2版
技術書というと、特定の言語やフレームワークの解説書をイメージしがちですが、本書はタイトルの通り「ソフトウェア開発者としての人生」全般を扱った異色の一冊です。中でも第3部「学習」は、独学力そのものをテーマにした内容で、次のようなことが具体的に書かれています。
- 効率的に新しい技術を学ぶための方法論
- 「10ステップ学習法」のような、体系立てた学習の進め方
- モチベーションを維持しながら学び続けるための考え方
技術そのものの解説書ではなく、「学び方をどう学ぶか」に焦点を当てている点が、独学力を鍛えたいエンジニアにとって非常に実践的です。私自身、この第3部を読んでから、新しい技術に取り組む際の学習の組み立て方が明確に変わりました。
6位：リーダーシップ
基本的に、システム開発はチームで行うものです。プロジェクトを進める中で、自分自身が強いリーダーシップを発揮しなくても、プロジェクトマネージャーやリーダーが引っ張ってくれれば、それなりに仕事は回っていきます。リーダーシップは「無いと成立しない」スキルというより、ある程度は他人に任せられる領域だと言えます。
ただ、現場で「この人が入ると、なぜかプロジェクトがうまく回り出す」と評判になる人には、共通する行動があります。
- 明確な指示がなくても、自分でチームの状況を見て、周囲を動かす
- 自分の役割の範囲を超えて、チームの成果そのものに当事者意識を持つ
- 誰かに動かされるのを待つのではなく、自分からチームを回す側に回る
言うのは簡単ですが、実際にリーダーとしてやってみると、これがとても難しいと痛感しました。私自身、プロジェクトにおいて、リーダーを数多く経験してきました。成功したプロジェクトもありますが、それ以上に、失敗したプロジェクトの方が多くあります。いくら自分が頑張っても、プロジェクトの規模によっては一人でカバーできる範囲には限界があります。「メンバーにいかに頑張ってもらえる環境、支援を準備できるか」 が、成功の鍵だと考えています。
プロジェクトの成果は、最終的にチーム全体の総力で決まります。誰かに動かされるのを待つ姿勢と、自らチームを牽引する姿勢とでは、プロジェクトにもたらす価値が大きく変わってきます。だからこそ、リーダーシップは技術力以上に、現場での評価を大きく左右する要素だと考えています。
おすすめ書籍
リーダーシップというと、カリスマ的な統率力や、華やかなマネジメント理論をイメージするかもしれません。しかし私がおすすめしたいのは、少し毛色の違うこちらの一冊です。
「なぜITエンジニアが角栄なのか」と思われるかもしれません。ですが、IT業界はロジックと数字で動いていると思われがちな一方、実際の現場は驚くほど泥臭い人間関係の積み重ねでできています。仕様変更に激怒する顧客をなだめたり、デスマーチ寸前のプロジェクトで疲弊したメンバーの心を立て直したりする局面では、正論やロジックだけでは人は動きません。
本書には、部下や周囲を動かし、結果を出し続けた田中角栄氏の言葉が数多く収められています。「義理と人情を欠かさない」「相手に恥をかかせない」といった氏の姿勢は、まさにトラブル対応や利害調整の場面で効いてくる、実践的なメンタリティです。技術書だけでは学べない、人間くさい説得力のある言葉の数々は、チームを率いる立場になったときに一度読んでおく価値があると思います。
5位：スケジュール管理
ここでいうスケジュール管理とは、単に「締め切りを守る」「スケジュール帳をつける」といった話ではありません。顧客からの依頼を具体的な作業タスクにまで分解し、作成すべき成果物を定義した上で、いつまでに、どこまでやるかを自分で決めて実行する力を指しています。
チームのマネジメントを行う上で、最も重要なのが、スケジュール作成と進捗管理だと考えます。ここがしっかりできているかどうかで、チームを天国に導くか、地獄に突き落とすかというくらいの大きな差になります。私自身、安易なスケジュールを引いてしまい、残業や休日出勤が常態化し、チームを混乱させてしまった経験もあります。今は、「他者の人生をも左右する重要な作業」だと強く認識しています。
タスクを整理し、期限を意識して動くこと自体は、多くのエンジニアがある程度できています。進捗管理ツールを使ったり、上司やPMに管理してもらったりすることで、平均的な水準の仕事は回せてしまいます。ある程度は他人に任せることができる領域だとも言えるでしょう。
それでも、現場で頼りにされる人を見ていると、次のような違いに気づきます。
- 曖昧な依頼を受けた時点で、自分で作業単位にまで分解し、優先順位をつけられる
- 見積もりの精度が高く、「いつまでにできるか」を最初から高い確度で示せる
- 誰かに管理されなくても、自分の作業を自走で完遂できる
管理される側ではなく、自分自身のマネージャーとして機能できるかどうか。この差は、思っている以上に大きなものです。
一流にしかできない難易度の高い技術的な作業は、他の誰にも肩代わりしてもらえません。その仕事を期限内に自分の責任で完遂しきる力が伴っていなければ、どれだけ技術力があっても宝の持ち腐れになってしまいます。どれほど優れた技術を持っていても、それを期限内に形にできなければ、顧客やチームにとっての価値にはならないのです。
余談ですが、生成AIがコードを書いてくれる時代になり、実装そのものにかかる時間は短縮されつつあります。だからこそ逆に、「曖昧な依頼を、AIに指示できる粒度まで自分で分解する力」が、これまで以上に問われるようになってきたとも感じています。
おすすめ書籍
スケジュール管理、とりわけ「見積り」の精度を上げたいと考えている方におすすめしたいのがこちらです。
見積りというと、経験と勘に頼る属人的な作業だと思われがちですが、本書は見積りの基本的な考え方から具体的な手法まで体系立てて解説しています。「なぜ見積りは外れるのか」「不確実性をどう扱うべきか」といった、多くのエンジニアが感覚でしか捉えていなかった部分を、論理的に理解できるようになる一冊です。曖昧な依頼を精度の高い計画に落とし込む力を鍛えたい方には、非常に参考になると思います。
4位：コミュニケーション力
「技術はすごいのに、何を言っているのかさっぱり分からない……」
25年現場にいて、そう評価されて損をしているエンジニアを何人も見てきました。説明が長い上に伝わらない、質問がうまくできず顧客や上司をイライラさせてしまう。こうしたことを繰り返してしまうと、エンジニアである以前に「仕事ができない人」と見なされてしまいます。
私は顧客に対し、多くの情報を提供しようと、詳細な説明資料をもとに説明したところ、「何を言っているかわからない」とお叱りを受けたことがあります。それ以来、簡潔な資料を心掛けるようになりました。情報量ではなく、相手にとっての伝わりやすさで話を組み立てる。これも、コミュニケーション力の一つの側面です。
チャットで聞かれたことに答える、進捗を報告するといった最低限のやり取りは、多くの人ができます。しかし現場で「この人がいてくれて良かった」と言われるエンジニアは、もっと泥臭いコミュニケーションをしています。
- 利害が対立する相手と、着地点を探りながら交渉して握りにいく
- 顧客自身が言語化できていないモヤモヤを、対話の中で引き出す
- システム構造を知らない非エンジニアの役員にも、「要するにこういうことです」と一発で伝わる例えに翻訳する
こうした、相手の文脈に合わせて言葉を翻訳する力こそが、評価を大きく左右するコミュニケーション力だと感じます。
おすすめ書籍
コミュニケーションを鍛えるにあたって、おすすめしたい2冊があります。
「何回説明しても伝わらない」はなぜ起こるのか？ 認知科学が教えるコミュニケーションの本質と解決策
「何度説明しても相手に伝わらない」という経験は、多くのエンジニアが一度は感じたことがあるはずです。本書はその原因を精神論ではなく認知科学の観点から解き明かしており、なぜ説明が伝わらないのか、どうすれば伝わるようになるのかを理論立てて理解できます。
一目置かれるリーダーの戦略的話し方: アナウンサーが教える言葉を相手に届ける技術
こちらは、アナウンサーという「言葉を届けるプロ」の視点から書かれた一冊です。話す内容そのものだけでなく、どう届けるかという伝え方の技術に焦点を当てており、顧客や上司、チームメンバーとのやり取りの中で自分の言葉をより説得力のあるものにしたいエンジニアの参考になります。
おわりに
ここまで、7位「独学力」、6位「リーダーシップ」、5位「スケジュール管理」、4位「コミュニケーション力」の4つを紹介してきました。
これらに共通するのは、多くのエンジニアが、ある程度は身につけているという点です。独学も、リーダーシップも、スケジュール管理も、コミュニケーションも、誰しも仕事をする中で自然と多少は行っているものだと思います。しかし、その"多少"のレベルで満足してしまうか、意識的に磨き続けて頭一つ抜けたレベルまで引き上げられるか。この差こそが、現場で頼りにされるエンジニアとそうでないエンジニアを分けていると、私は感じています。
つまり、前編で紹介した4つのスキルは、持っているかどうかではなく、どこまで磨いているかで差がつくスキルでした。
そしてもう一つ、この4つには共通点があります。AIがコードの大部分を書けるようになった今だからこそ、純粋なプログラミングのスピードや正確さだけでは差がつきにくくなってきました。だからこそ、AIには代わりが効かない「曖昧な依頼を分解する力（スケジュール管理）」「人間同士の利害を調整する力（コミュニケーション）」「チームを動かす力（リーダーシップ）」「学び続ける力（独学力）」が、これからの時代にむしろ大きな差として表れてくるはずです。
さて、次にご紹介する3位・2位・1位は、これまでとは少し性質の異なるスキルになります。ここから先は「卓越しているかどうか」ではなく、エンジニアとしての在り方そのものを大きく左右する、より根本的な話になっていきます。
後編では、そんな3つのスキルについてお伝えしていきたいと思います。
（後編に続く↓）