タケハタのブログ

プログラマの生き方、働き方、技術について雑多に書いていくブログです。

技術力の構成要素

今日はてブに上がってたこの記事を読んで触発されたので、自分の思う「技術力」について書くことにしました。

alpacat.hatenablog.com

正直この「技術力」という言葉は人によって考え方はまちまちなので完全に個人の見解になりますが、考え方の一つとして読んでいただければと思います。

技術力は「技術を活かす力」

結論から先に書くと、技術力は「技術を活かす力」なんじゃないかなと思っています。
技術の種類は数えきれないくらいにあるし、それぞれに適切な使い方、使いどころがあります。

それらをどれだけ適切に活かし、プロダクト開発に還元できるか。
その意味を、ここから2つの要素に分けて説明していきたいと思います。

技術力の構成要素

技術力の構成要素は、次の2つだと思っています。

  • 技術的な知識
  • 知識を適切な形で使う力

この2つをどちらも高いレベルで兼ね備えていると、本当に技術力が高いエンジニアと言えるのではないかなと。
それぞれの要素について説明していきます。

技術的な知識

まずは技術的な知識。

  • 綺麗なプログラムの書き方
  • 便利なツールの使い方
  • ミドルウェア、ライブラリ、フレームワークの特性や使い方
  • 良い設計の手法
  • 開発手法
  • テスト手法
  • etc...

みんな本を読んだりプログラムを書いたりしながら勉強している知識です。
やはり技術でなにかをしようとしているので、こういった知識は必須です。

いくらすごいことをやろうとしても、持っている知識が少ないと取れうる選択肢が減るし、できることが限られてしまいます。

知識を適切な形で使う力

そして「技術的な知識」を適切な形で使う力。
ぶっちゃけこれがこの記事の本題です。

ここの認識が言語化されていなくて「技術力がある」という言葉がズレているパターンは多い気がします。

あと「技術力はあるんだけど微妙なんだよね・・・」と言われる人はここの能力が低い人が多いかなと思います。
(知識がある人を「技術力が高い」と言いがち)

オーバーエンジニアリングとアンダーエンジニアリングにならない

オーバーエンジニアリング

技術的なこだわりが強い人にありがちなんですが、「過剰に良い設計」をしようとするといわゆるオーバーエンジニアリングになってしまいます。

主に設計の部分で起こるのですが、例えば

  • ビジネスモデル上1万ユーザーくらいしか確実に来ないサービスなのに、100万ユーザーでも耐えられるサーバー設計にする
  • 小規模で数人単位での開発しかしないのに、数十人規模で作ることを想定した設計にする
  • 数年しか運用しない前提のシステムなのに、数十年動かす想定の設計にする

などなど。
「変更に強い」「高負荷にも耐えられる」「大人数での開発もやりやすい」などいわゆる「良い設計」にしようとすると、その分複雑化したり開発コストが上がる面もあります。

知識のある人ほど「こうすべきなんだ!」とプロダクトの規模など関係なく、MAXの状態の理想的な設計にこだわろうとしてしまいがちです。

本などにある「良い設計」は全ての状況に置いて「良い設計」とは限らないし、取り入れるとしてもどこまで忠実にやるかは考えないといけません(どれだけ設計を細分化するか等)。

なのでこれは知識は豊富にあるけど、それゆえ過剰にコストをかけてしまっているパターンで、技術を活かしきれていないと言えます。

アンダーエンジニアリング

もちろん逆に、

  • 100万ユーザーが来うるサービスなのに1万ユーザーくらいにしか耐えられない設計になっていた
  • 数十人規模で開発するのに、大人数が同時に触るには辛い設計になっていた
  • 数十年運用する想定なのに、数年で耐えられなくなる設計になっていた(データ量の肥大化など)

とアンダーエンジニアリングになる場合もあります。

知識が足りないだけでも普通に起こりますが、知識があっても「ここまではやらなくてもいいだろう」と手を抜いて起こってしまう場合もあります。
(2000年問題とか多分これですね)

これも言うまでもなくダメです。

新しい技術の導入の妥当性を理解している

あとは新しい技術の導入などもそう。
「今時はもうこれを使うべき!」と最新の技術を導入しようとするけど、プロダクト的にはあまり必要なかったり、こちらもかえって手間を増やしてしまうこともあります。

「今どきインフラは全部コンテナでやるべき!Docker、Kubernetes使う!」と言いながら、Terraformで構成管理するのとどうメリットがあるのかよく分かってなかったり。

「サーバーサイドは今ならGoでしょ!」と明確な理由もなく言語を決めたり。

新しい技術は魅力的に感じますが、実は元からある技術でも同じことができたり、プロダクトによってはそちらの方が適切な場合もあります。
あとエンジニアメンバーの経験値とかも考慮に入る。

エンジニアは新しいもの好きな人が多いので、最新の技術は使ってみたくなりがちです。
(それはそれで必要だったりしますが)

ただ、それがどう良くてなぜ使うべきか?をちゃんと理解してないと、気づかぬうちに負債を生んでいることもあります。
とりあえず「新しいから」ではなく、「なにがいいのか?」「他の技術と比べてどうメリット、デメリットがあるのか?」を理解して導入できることが大事ですね。

これができないと、使い方は知っているけど活かせていない状態になります。

要件と技術をどれだけマッチさせられるか

結局は「その時必要な要件がどういったもので、どこまでやればいいのか?」を正確に判断して、適切な技術を投入できることが大事だと思います。
まさに「技術を活かしている」ポイント。

ちなみに「要件」や「想定」というのも、ビジネス側から言われたことをそのままやるのではなく、それが本当に妥当なのかどうかも考えて、「こうすべきだ」を判断できるとより良いですね。
(技術力とは少し離れるかもしれませんが)

構成要素のどちらが欠けても弱い

それぞれの項目で書きましたが、「技術的な知識」がなければそもそもできることが減ってしまうし、プロダクトのレベルは下がる。
「知識を適切な形で使う力」がなければどんなに知識があったとしても、無駄なコストをかけてしまったり、余計な障害を起こしてしまうことにつながるかもしれない。

この2つがしっかりあること、つまり知識が豊富にあって、それを適切な形でプロダクト開発に活かせる人が「技術力が高い人」と言えるんじゃないかなと思います。

要は(高いレベルでの)バランスが大事ってことですね。

おまけ:たまにはぶっ飛んだ人材も必要

基本的にはバランスよくレベルの高い人がいいと思っていますが、そういう人だけでは成り立たないとも思います。
(そういう人もそんなにいないのですが)

中にはとにかく技術にこだわっていて、ぶっ飛んだ人材も必要だと思います。
新しい技術をとにかく使ってひたすら突き進んで行くような人が。
こういう人がいないと世の中の技術も発展しないし、プロダクトのレベルも上がっていかないので。

ただ、本当に突き抜けたレベルの人じゃないとキツいかなと。
中途半端なレベルでこれをやっても不和を生むだけなので、普通の人ではあり得ない時間を技術にかけている人たちの話ですね。