IT エンジニアにとっての「技術力」はどういう意味か【現役 Web エンジニア考え】

こんにちは、昔は SE やってて今は Web 系のフリーランスな Nash です。

この記事では、下記のことについて自分の考えをまとめた記事になります。

  • 現代の IT 系のエンジニアにおける「技術力」とは何か？

先に結論ですが、下記の通りです。

  • 技術力　＝　① 知識力　＋　② 実現力
  • ≫ ① 知識力　＝　知識　＋　知識に関する力
  • ≫ ② 実現力　＝　知識を元に、実際にモノに昇華する力

では見ていきます。

「技術力」とは何か？

まず、「技術力とは？」を考える上で、公式の定義を知りたかったので、Wikipedia を読んでみました。

⇒ 技術 - Wikipedia

ただ、実際わかったのは「明確に技術とは何か？を定義するのは複雑すぎて無理っす」っていうことでした・・・。（文化的な違い、歴史的な遷移、翻訳の違いや誤訳、他言語・意味と融合などなどが原因）

ただ、最後らへんのトピックで「技術」と「技能」の違いがあり、今回のトピックの「技術力とは？」を考える上で参考になりました。

「技術」と「技能」の意味と違い

簡単に言うと下記の通りです。

  • 技術　＝　知識

  • 技能　＝　能力

技術とは、Wikipedia 曰く狭義の意味で「知識」のことらしいですね。（個人的にかなり違和感があるけど）

技能とは、個人に蓄積されるて他人に引き継ぐことが出来ないモノです。 例えばサッカーのリフティングを例にすると、知識としては「足でボールを上に蹴り上げる行為」という知識は理解できるし他人に説明もできます。 ですが、それを実現するための技能は他人に引き渡すことができません。練習を通して技能が個人に蓄積されるわけです。（ポケモンで言う、わざマシンが現実世界に生まれたら、この限りではないですが）

さて、技術力の定義として、上記の考えはかなり良いのですが「技術と技能」という言葉が直感的でなく、かつ誤解も生みやすそうです。 （技術って言葉なのに知識のことなの？ってなる）

なので、この考えを元に自分の考える「技術力」を定義しました。

技術力＝知識力＋実現力

  • 技術力　＝　知識力　＋　実現力
  • 「技術力とは、知識力　と　実現力の総和である」

が自分の考える技術力です。

それぞれについて具体例を交えながら考えていきます。

知識力

知識ではなくて知識力です。

知識力とは、「知識それ自体かつその知識に対する力学を操る能力」と考えたからです。 少しかっこよく書いてみましたが「知識＋知識にまつわる力」です。

箇条書きにすると下記みたいな感じ。

  • 知識量（＝深さ＋広さ）
  • 収集力
  • 更新力
  • 発想力
  • などなど

ここで言及したいのは、xx 力です。

例えば、現代のエンジニアにおいては、下記の力は他の職種よりも遥かに重要です。この力によって知識の質が左右されることもあります。

  • 問題に対して、的確に答えにたどり着くググり力（＝収集力）
  • 情報収集して知識をアップデートする力（＝更新力）

また、エンジニアリングの中で自分の引き出しの知識をそのまま当てはめられないケースも多々あります。

例えば、ベストプラクティスを知っていてもビジネス的な制約などによって別の選択肢を考えないといけないケースがあり、そういう場合は持っている知識をベースとした発想力が必要になります。

というわけで、このように知識を駆使する力も一定レベルが必要になります。

実現力

  • 速度
  • 確実性
  • 効率性

持っている知識を駆使してモノを実現させる力です。

例えば Rails でアプリケーションを作ることを考えます。この場合は、「Rails という FW からどんな API が提供されているか？」を知識として知っている上で、それを使って具体的なモノとしてアプリケーションを実現させていく力、つまり実現力が必要になります。

前提として知識は知っている必要がありますし、もし知らないなら場合によっては推測する力も必要です。（両方とも知識力）

実現力が高いとは、タイプミスなどが少なく爆速で効率的にコーディングが出来る力が高いとも言いかえられます。

というわけで、ここまで自分の考える技術力についてでした。

では、具体的に〇〇なエンジニアを例にこの定義を考えて行きます。

〇〇なエンジニアは技術力がある、と言えるのか？

上手に説明はできないけど、コーディングスキルが高いエンジニア

単に表現力が足りてない、悪く言えばコミュ障、良く言えば職人気質。個人的には、これこそが THE エンジニアで、技術力は高いケースが多いイメージ。ただ、今どきなエンジニア的イメージとは違うので、ステレオタイプなイメージかと思います。

⇒ 技術力はあるけど、コミュ力が足りてないケース。

上手に説明できるけど、コーディングスキルが低いエンジニア

知識に振っていて実現力が欠如している系。悪く言えば、しゃべくりエンジニア、良く言えばマネジメント寄り。SE がコレ系なイメージ。

⇒ 技術力の中の実現力が足りてないけど、それとは別にコミュ力があるケース。

コーディングスキルがあっても、古い技術しか知らないエンジニア

もし実現力が高くても、つまりいくらコードを速く書けてバグが少なくても、かなり危険だと思います。 というのも、その元となる知識が古いと出来上がったソフトウェアは表面上は品質が高いけど、内部的には技術的負債が多い状態だから。

例えば「Web アプリケーションを FW なしで Plain な PHP でフルスクラッチで作りました！」みたいなケースです。

⇒ 知識が古くて腐ってしまってるパターン

めちゃくちゃ手が早いけど、裏で何が起きてるかがわかってないエンジニア

特にスタートアップ界隈では即戦力が重要なのでこのタイプが多いイメージ。 ただ、裏で何が起きてるか何もわかってない、ってのは言い過ぎで、実際は必要最低限の理解で止めている感じです。

手が早い＝各 FW の使い方とかを覚えて知っている、という感じですが、特にココらへんの知識は劣化が早い印象です。例えば新しい FW が出たら覚え直しになるので。知識の積み重ねがあり、新しい技術も過去の技術の延長なので 0 ベースではないとは思うけど。いずれにしても、ラットレースよろしくな感じ。

長期的にみると学習スパンが辛く見えるけど、2020 年時点でこのタイプのエンジニアはフリーランスでかなり稼げるのでキャッシュが貯まるし、新しい技術を最速でキャッチアップするスキル自体も磨けるし、モダンな現場に入りやすいし、とむしろ 20〜30 代くらいまではメリットが多い印象。

⇒ 手が早いエンジニアのイメージ

ビジネスに直結するコードを書けるエンジニア

ビジネス的思想を理解して、かつ行動に落とし込めれるタイプ。 具体的には、ユーザーニーズを理解して、本当に優先すべきものだけに絞れる思想を持っていて、そのアクションが取れる人間。

そのため、時には技術的セオリーを犠牲にできる思想の持ち主とも言える。例えば、べき論で導入すべき技術を後回しにしてビジネスインパクトを優先したり、とりあえず動けば OK なクソコードでも許容して作ったり。

この思想は曖昧さを許容するのとベストプラクティスと相反することも多いので、固い思想を持ちたがる職人気質のエンジニアと相性が悪い印象。例えば、エンジニアリングとはこうあるべきだ、みたいな考えを固めて持っているタイプとか。

おわりに

というわけで、自分の考える「技術力とは？」について改めて考えて、色々エンジニア像と当てはめてみました。

  • 技術力＝知識力＋実現力

技術力とは？を改めて考えた結果いろいろ気づくところがあり、ひいては技術力を上げるには？に至るヒントも多く見つけられたので収穫でした

ここらへんについても、時間があれば今後書いていこうかと思います。

おまけ

Wikipedia の技術のトピックで下記についても言及されていて、ここらについても自分的には腹落ちした定義でした。

  • エンジニアリング＝編み出す技術

  • テクノロジー＝編み出された技術

つまり、日本語の技術とは文脈によってエンジニアリング（編み出す技術）、テクノロジー（編み出された技術）、スキル（技法と技能）のどれかひとつをさすこともあれば、いずれか二つの意味を持つ場合や、さらには、それらが一体となった意味としても使用されることもある。

つまり、過程がエンジニアリングで、それによって生み出される結果のモノがテクノロジーです。

テクノロジーを用いて更に、エンジニアリングして、次のテクノロジーを生み出す、という輪廻が生まれるイメージ。