0
1

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

技術力より大事なスキルTOP7 ― すべての土台となる3つのスキル【後編】

0
Last updated at Posted at 2026-09-08

はじめに

前編では、7位「独学力」、6位「リーダーシップ」、5位「スケジュール管理」、4位「コミュニケーション力」の4つをご紹介しました。

前編で扱った4つは、多くのエンジニアがある程度は身につけているスキルでした。その中で、どこまで磨き上げられるかによって、現場で頼りにされる人とそうでない人の差が生まれる。そんな「卓越性の差」を軸に選んだスキルたちです。

いよいよ後編では、3位・2位・1位をご紹介します。ここから先は少し性質が変わります。「どこまで極めているか」ではなく、「これが揺らぐと、他のすべてのスキルを支える土台そのものが揺らいでしまう」 というレベルの、より根本的なスキルです。

まだ前編を読んでいない方は、先にそちらから目を通していただくと、今回の3項目がなぜこの位置づけになっているのか、より腑に落ちるかと思います。

(前編はこちら↓)

それでは、3位から見ていきましょう。


3位:ドメイン知識

ドメイン知識とは、顧客が属する業界や業務そのものについての知識を指します。金融、医療、物流、製造業など、それぞれの現場には固有の業務フロー、専門用語、暗黙のルールが存在します。

顧客の業務を知らないエンジニアは、要件定義の場でこんな状態に陥りがちです。

  • 顧客が話している業務上の課題を、言葉としては理解できても、本質的には理解できない
  • 「なぜこの承認フローが必要なのか」「なぜこの数値だけ特別扱いされるのか」といった、業務上の"当たり前"の背景が分からない
  • 結果として、顧客の話をそのまま鵜呑みにして仕様化するしかなく、顧客自身も気づいていない本当の課題を見抜くことができない

正直に言うと、私自身はこれと言った特定のドメイン知識は持っておらず、いまだに苦しんでいます。専門用語が飛び交う要件定義の会議で、話についていけずただ相槌を打つだけの"地蔵"になってしまったことも一度や二度ではありません。ここに関しては独学で対応するのが難しく、経験がものをいうスキルだと感じています。しっかりとしたドメイン知識があれば、上流工程から顧客と対等に会話ができ、良い提案もできることでしょう。

新人ITエンジニアは、開発ではなく運用プロジェクトを任されるケースが少なくないと思います。そういう時は、発想を切り替えて、「今はドメイン知識を身につける時だ」と割り切るのも一つの考え方だと思います。この経験は後になってきっと役に立つはずです。

おすすめ書籍

ドメイン知識そのものを独学だけで身につけるのは難しいですが、最初のとっかかりとしておすすめしたいのがこちらです。

図解即戦力シリーズ

これだけで、ドメイン知識をカバーできるものではありませんが、業界特有の仕組みやビジネスモデルを図解でざっくり掴める構成になっており、未経験の業界に飛び込む際の最初のとっかかりとして役に立つシリーズだと考えます。


2位:問題解決力

ここで一度、根本的な問いを投げかけたいと思います。ITエンジニアの仕事とは、そもそも何でしょうか。

「システムを作ること」「コードを書くこと」と答える人も多いかもしれません。しかし、私はそう考えていません。ITエンジニアの仕事の本質は、顧客が抱える問題を解決することです。システム開発は、その手段の一つに過ぎません。極論を言えば、システムを作らなくても問題が解消されるのであれば、システムを作る必要はないということです。

同じ依頼を受けても、行動はまったく異なります。仕様をそのまま実装し、「言われた通りに作ったので完成です」をゴールにする人がいる一方で、まず「なぜこの機能が必要なのか」「本当に解決したい課題は何か」を考える人もいます。後者は、その結果として「言われた仕様よりも、こちらの方法の方が課題を解決できます」と提案できることもあります。

こうして本当の課題を見極めてから動く人こそが、顧客から信頼されるエンジニアです。

問題解決において、最も重要なことは、良い解決案を打ち出すことではなく、解決すべき問題を正しく見極めることだと思います。問題解決の世界では「イシュー」と呼ばれるものですが、このイシューを正しく見極められないと、仕様通りに作ったものの、実は顧客の課題を解決できていなかった、ということが起こってしまいます。

どれだけ高度な技術を使いこなせても、顧客の問題を見誤ったまま作られたシステムには価値がありません。むしろ、技術力が高いほど「間違ったものを、綺麗に、素早く作ってしまう」というリスクすら生まれます。

最近は、要件定義や上流工程でも生成AIを活用する場面が増えてきました。AIに的確な指示を出すプロンプトエンジニアリングも、突き詰めれば「何を解決したいのか」を言語化する作業そのものです。つまりAI活用が進むほど、良い解決策そのものはAIが提示してくれるようになっても、その手前にある「解くべき問い(イシュー)」を見極める力の価値は、むしろ相対的に高まっていくと考えています。

おすすめ書籍

問題解決力を鍛えるにあたって、おすすめしたい2冊があります。

イシューからはじめよ[改訂版]――知的生産の「シンプルな本質」

「頑張って作業する前に、まず取り組むべき問い(イシュー)を見極めよ」という本書の主張は、まさに「言われた仕様をそのまま作る人」と「本当の課題を見極めてから動く人」の違いを言語化したものです。手を動かす前に立ち止まって考える習慣を身につけたい方に参考になります。

ライト,ついてますか: 問題発見の人間学

「そもそも何が問題なのか」を見極めることの難しさと面白さを、寓話形式で軽妙に説いた古典的名著です。技術書にありがちな堅苦しさがなく、問題解決の本質をやさしく学べる一冊です。


1位:主体性を発揮する力

私の中でダントツの1位が、主体性を発揮する力です。

言いたいことがたくさんあるので、別記事を書いています。そちらもぜひご参照ください。

「主体性(Proactivity)」というと、多くの人が「自分から進んで行動すること」と認識していると思います。ですが私は、次のようなより深い概念だと考えています。

主体性とは、「自分の身に起こる出来事を、他人や環境のせいにせず、自分ごととして引き受けること」

たとえば、上司から理不尽に指摘を受けたとき。

  • 主体的でない人は「あの人の言い方が悪い」「自分は悪くない」と、感情のまま反応します。
  • 主体的な人は、一呼吸おいて「言い方はきついが、指摘自体は正しい。改善のチャンスにしよう」と、自分がどう受け止めるかを選択します。

同じ扱いを受けても、主体性がある人とない人とでは、反応がまったく異なります。この小さな積み重ねが、その人のキャリアや人生そのものを豊かにするかどうかの差になっていきます。

主体性を発揮できる人は、周囲から信頼され、難しい仕事を任され、その結果さらに実力をつける「成長のループ」に入れます。逆に、主体性がない人は「常に言い訳しかしない人には任せられない」という理由で、簡単な作業しか回ってこなくなります。技術力を伸ばす機会そのものが減っていく、「停滞のループ」に陥ってしまうのです。

つまり、技術力を磨くチャンスを得られるかどうかも、実は主体性次第です。技術は、主体性という土台の上に、初めて積み上がっていくものだと言えます。

ただ、本当の意味で主体性を発揮できている人は、ほんの一握りだと考えています。人間には自己防衛本能が働くもので、悪い状況になると、つい人のせいにしてしまいがちです。

私は、主体性を発揮するコツは「承認欲求を捨てる」ことだと思っています。承認欲求が強いと、どうしてもエネルギーが他者に向いてしまいます。自分の思い通りに他者は動いてくれないので、「一生懸命やっているのに評価されない」など、常に不満を抱えることになります。

正直に言うと、私自身も若い頃は、上司や周囲から認められたくて空回りしていた時期がありました。評価してもらうことばかりに気を取られ、肝心の「何を解決すべきか」がおろそかになっていたと思います。あるとき、評価を気にしてもコントロールできるのは結局自分の行動だけだと腹落ちしてからは、「他者がどう思おうが、やるべきことをやる」という姿勢に自然と切り替わり、驚くほど仕事が楽になりました。承認欲求を捨てることができれば、こうした姿勢を取り続け、エンジニアとして成長し続けることができます。

なお、主体性というと「何でも一人で抱え込むこと」と誤解されがちですが、それは違います。難しい課題にぶつかったとき、誰かに助けを求めるという選択を自分で下すこと自体が、立派な主体性の発揮です。抱え込んで状況を悪化させるのは、むしろ主体性とは逆の、環境や成り行きに流されている状態だと言えます。

おすすめ書籍

主体性を鍛える上で、原点として読んでおきたいのがこちらの2冊です。

完訳 7つの習慣 30周年記念版!

主体性という概念そのものの原典です。第1の習慣として位置づけられている「主体性を発揮する」を軸に、なぜそれがすべての土台となるのかを体系的に学べます。

嫌われる勇気 自己啓発の源流「アドラー」の教え

「他者の評価に振り回されず、自分の課題に集中する」というアドラー心理学の考え方は、本章で触れた「承認欲求を捨てる」という話と深くつながっています。対話形式で読みやすく、主体性を実践レベルまで落とし込みたい方におすすめです。


おわりに

ここまで、7位から1位まで、私が25年のキャリアの中で「技術力より重要だ」と感じてきたスキルを紹介してきました。あらためて全体を振り返ってみます。

  • 7位 独学力:技術そのものではなく、技術を学び続ける力
  • 6位 リーダーシップ:チームを自ら動かす力
  • 5位 スケジュール管理:自分自身を律し、自走させる力
  • 4位 コミュニケーション力:相手の文脈に合わせて言葉を翻訳する力
  • 3位 ドメイン知識:顧客の業務を理解し、問題解決の解像度を上げる力
  • 2位 問題解決力:システムを作るのではなく、顧客の課題を解決する力
  • 1位 主体性:すべての土台となる、自分の反応を選び取る力

こうして並べてみると、この7つは決してバラバラなものではなく、主体性という一番の土台の上に、問題解決とドメイン知識という「仕事の本質を捉える力」が積み上がり、さらにコミュニケーション・スケジュール管理・リーダーシップという「人や組織を動かす力」が磨かれ、最後に独学力によって技術力そのものが継続的にアップデートされ続けるという、一つの構造としてつながっていることに気づきます。図にすると、次のようなイメージです。

技術力は、これらすべての土台があって初めて、意味を持ち、輝き始めます。逆に言えば、技術力だけをいくら磨いても、土台が弱いままでは、その技術力を十分に活かしきることはできません。

生成AIの登場で、コードを書くという行為そのものの価値は大きく変わりつつあります。だからこそ、AIには代わりの効かないこれらの人間的なスキルこそが、これからのエンジニアの価値を左右していくのではないかと、私は感じています。

25年間、この業界で仕事をしてきた一人のエンジニアとして、これから技術者として歩んでいく方々にとって、この記事が少しでも参考になれば幸いです。ここまでお読みいただき、ありがとうございました。

0
1
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
0
1

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?