ソフトウェアエンジニアにとって、「技術力」とは何か（WIP）

※ 警告：この雑文は、良くてポエム、悪くて怪文書の類なので、あまり鵜呑みにしないでください。フィードバックは歓迎します。

前書き

ソフトウェアエンジニアは、「技術力」という言葉を頻繁に、カジュアルに使うように思われます。例えば、ある人を称して「あの人は技術力がある」と使われたり、目標設定を行う際に「今期は技術力の向上に取り組みたいです」と使われたりします。

一方で、この技術力という言葉は、ひどく曖昧模糊としています。技術力が高いとはどういう状態なのか？逆に低いとはどういう状態なのか？というのは、ハードコア・ポルノと同じように、「見ればわかる」ような気はします。

スチュアート判事はいたって真面目で目立つのが嫌いな人であったが、修正第1条の言論の自由保護条項がどこまで猥褻な表現を保護するかが問題となった１９６４年のジャコベリス対オハイオ事件判決で、「ハードコア・ポルノ」の定義について「見ればわかる」と記し、国民の間で一躍有名になった。（憲法で読むアメリカ現代史、NTT出版Webマガジン）

しかしながら、前述の例に出したような目標設定の場面では、「見ればわかる」では著しく定性的であり、定量的な評価は全く持って不可能です。

自分の置かれた「テックリード」というロールでは、メンバー（または潜在的なメンバー）の技術力を正しく評価すること、できることが求められます。メンバーとの1on1でも「技術力とは何を指すのか」ということは、よく質問を受ける事柄です¹。そのため、「技術力とは？」という問いに対する一般解を導出することは困難であるとしても、せめて自分の置かれた、局所的なポジションにおける特殊解くらいは、なんとか導出しておきたいものです。

現時点では納得のいく答えがでるかわからないので、Work In Progressです。フィードバックは歓迎します。

言葉の意味

まずは言葉の意味を考えます。「技術力（ぎじゅつりょく）」という言葉は、「技術（ぎじゅつ）」と「力（りょく）」という独立した2個の単語が結合した複合語です。それぞれの意味を検討することで、「技術力」という言葉が内包する意味を明らかにします。

まずは「技術」について。恥ずかしながら、手元に適当な国語辞典がありませんでしたので（あとで買っておきます）、Wikipediaより引用いたします。

技術（ぎじゅつ、英語: technique, technology）は、物事に関する取り扱いや処理の方法・手段、巧みに行う技・技巧・技芸。または科学の研究成果を人間の生活に役立たせる方法、科学を応用して自然を改変・加工して役立てる技。（技術、Wikipedia）

ソフトウェアエンジニアの立場になって読み替えると、「ソフトウェアを巧みに操る技芸。ソフトウェアに関する知見を人間の生活に役立たせる方法」というような感じに読めるでしょう。

次に「力」について。

物事が変化する原因となるもの。またはその象徴を指す。（力、Wikipedia）

ソフトウェアエンジニアに置き換えると…難しいですね。

とはいえ、話を進めるために、ここまでの内容をまとめて仮置きの結論を出しておきます。ソフトウェアエンジニアにとっての技術力とは、「ソフトウェアを巧みに操り、人間の生活に役立たせる技芸の巧拙」です。なんだろう…当たり前のことを改めて言っているだけな気がしますね。当たり前のことを言っている分、納得感はあります。何も進んでない感もありますが。

技術力をどう測るか

ここまでで、ソフトウェアエンジニアにとっての技術力が「ソフトウェアを巧みに操り、人間の生活に役立たせる技芸の巧拙」であることがわかりました。では、それをどのように測れば良いのでしょうか？まずは、アンクル・ボブの言葉を引きます。

ソフトウェアは「ソフト」になるように考案されたものだ。マシンの振る舞いを簡単に変更する手段になることを目標としたものである。（クリーンアーキテクチャ、Robert C.Martin、P.42）

ソフトウェアは、マシンの振る舞いを簡単に変更する手段であると述べています。そうであれば、ソフトウェアを巧みに操る技芸とは、マシンの振る舞いを簡単に変更する手段を提供する技芸であると言えそうです。

「マシンの振る舞いを簡単に変更する技芸」を自分の置かれたモバイルアプリケーションのフロントエンドエンジニアとしての立場に置き換えると、以下のようになると考えます²。

• 変更の可能なアーキテクチャを構築する技芸
• 変更によって既存の機能が壊れないことを保証する自動テストの技芸
• 変更を容易にユーザーに届けるためのCI/CDの技芸

ソフトウェアエンジニア一般にまでスコープを広げて適用できるかはちょっと自信がありませんので、スコープを「モバイルアプリケーションのフロントエンドエンジニア」に狭めました。

身近な例を見ていても、ソフトウェアエンジニアとして成熟している人は、このあたりの技芸が巧みであると感じます。もっと他の要素もあるような気はしますが、これらの項目が挙がることには大きな違和感はないです。

とはいえ、これらの技芸の巧拙をどう測定するかは相変わらずわからないままなので、この章の目論見は失敗したと言えそうです。せっかく読んでいただいたのにごめんなさい。やっぱり技術力とは「見ればわかる」ものなのかもしれません。

技術力をどう伸ばすか

WIP。

インプット（本を読む、コードを読む、コードレビューを受ける、メンタリングを受ける）とアウトプット（学んだことを文字に残す、コードを書く、コードレビューをする、学んだことを教える）をしっかりしよう、という当たり前のことしか思い浮かびませんでした。もっと良いアイデアが降りてきたら、本記事を更新します。

先行研究

先行研究というか、他に似たようなブログ記事を探してみました

• 【あいまい回避】技術力とかいうよくわからんワードを分解する - Qiita

こちらの記事には、「技術力という概念は非常に広い概念だけど、おおむねある問題領域を技術で解決してリリースする力であると言えそう」というようなことが書いてあります。同意できる意見です。

• 技術力があるとは？2019年振り返り - アルパカログ

こちらの記事では、「技術力の定義は個人によって違うけど、それはともかく技術力が高い人と他のことが得意な人の両方必要だよね」という趣旨のことが書かれています。

• 技術力の構成要素 - タケハタのブログ

こちらの記事では、「技術的な知識と技術的な知識を適切にプロダクト開発に活かせる力」というようなことを言っています。1つ目の記事と同じような論旨であると思います。

Reference

1. 憲法で読むアメリカ現代史 NTT出版Webマガジン -Web nttpub-（最終アクセス日：2022年1月16日）
2. 技術 - Wikipedia（最終アクセス日：2022年1月16日）
3. 力 - Wikipedia（最終アクセス日：2022年1月16日）
4. クリーンアーキテクチャ 達人に学ぶソフトウェアの構造と設計、Robert C.Martin（2018）、ASCII DWANGO
5. 【あいまい回避】技術力とかいうよくわからんワードを分解する - Qiita（最終アクセス日：2022年3月15日）
6. 技術力があるとは？2019年振り返り - アルパカログ（最終アクセス日：2022年3月15日）
7. 技術力の構成要素 - タケハタのブログ（最終アクセス日：2022年3月15日）

Change Log

1. 2022年1月16日初版
2. 2022年3月15日先行研究の項を追加