18
14

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

More than 3 years have passed since last update.

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

Posted at

0.はじめに

お酒の場だったとおもう。
フリーランスになって多く製品を経験しながら、自分のプロダクトを持ちたいという夢を語ったところ、

「お前の技術力なんて、オレ以下だ…(長いので省略…)」

と、激励をいただいた。
まぁ、怒っているか?と言われてもなるほど?わからん・・・
ってなったので、”技術力”などという曖昧な言葉を分解しようと思った。

別に優劣つけるとかそういうわけでもないので、
相手が、技術力といったときにどれの文脈で言ったのか考えるたしになればと思う。

1. 前提

まずは、技術力という言葉の定義を次のようなモノであると定義する。

ある問題領域をテクノロジーで解決して、世の中に使える形でリリースをする力

広義すぎると思われる方がいらっしゃるかもしれない。
技術力とは、それぐらい曖昧な言葉なのではないかと思う。

2.分解

まず、製品をリリースするにあたって、必要な要素を考えてみた。

  • 世の中のシーズ・ニーズ・ウォンツを読む
  • 製品リリースを勝ち取る
  • 顧客の要求を予測する(もしくは、読み取る)
  • 技術調査をする。
  • 技術選定をする。
  • 技術に最適な、設計を考える。
  • 技術・設計を利用し、実装する。
  • 実装をテストし、品質をあげる。
  • 流通に乗せて出荷する(もしくは、Webなどの媒体でリリースする)

製品ローンチまでに行うことはこれで、漏れがないと思う。
さらに細かくしようと思うと、細かくはできるかもしれないが、
一旦の粒度は、隣り合う分野で使う技能が違うと自分が考えた結果を書いた。

2-1.社会分析能力

世の中のシーズ・ニーズ・ウォンツを読む能力とする。
社会と大きな言葉で言っているのは、自社開発であることを考慮したためである。

会社組織にいる場合は、上司や役員のシーズ・ニーズ・ウォンツからくることもある。

また、ここで製品を思いつくことになるので、一般的にいわれる発想力はこの分野である。
ただ、個人的には社会分析をした結果でてくるモノなので、分析の分野にいれた。

2-2.承認力

製品をリリースするための、承認を得る能力とする。

承認とは、会社組織は、上司や役員・もしくは取引先からリリースOKをもらうこと。
起業の場合は、VCや銀行やスポンサー・株主からリリースするための資金が調達できること。

2-3.要求定義力

顧客(社会・他社)の要求を予測する能力とする

顧客はだいたい、自分の要求をわかっていないことが多い。
というか、自分もだいたい、したいことわからない。

最終的に、何がしたいのかを予測する能力とする。
おそらく、これが一番むずかしい…

ヘンリー・フォードの言葉
『もし私がお客さんに何が欲しいかとたずねたら、彼らは、もっと早く走れる馬をと、と答えていただろう。』

要求する側も社会通念以上のことを考えがたいという証拠である。
※もちろん、要求側がイノベーションしてくることもある。

2-4. 技術調査力

要求を実現するための能力を探す。
もしくは、普段から、技術を蓄える能力とする。

実現する引き出しの多さは、ここに起因する。
発想力もこのあたりを強めることで、強くはなっていく。

2-5. 技術選定力

技術選定をする能力を指す。

ここで、大きくいいたいのがコスト感なのである。
最良を決めるコスト感覚が重要である。

世の中の問題はだいたい、「金」か「時間」が解決する
しかし、プロジェクトは終わりが決まっていることもある(時間が固定されている)
もしくは、予算が決まっているプロジェクトもある(お金が固定さている)
それとも、両方とも決まっているプロジェクトもあるだろう…

なので、このコスト内で選べる最大効率の技術を選定する能力と思っている。

このあたりすべて度外視で選べるなら、一番いい装備で挑めばいいのだ。

2-6. 技術利用能力

  • 技術に最適な、設計を考える。
  • 技術・設計を利用し、実装する。

この2つに対応していく能力を指す。
選定した技術に対して、それを適切に利用する能力だ。
設計力と実装力をわけようかと考えたのだが、技術利用という意味では同じなので一つにした。

OSSを使うなら、OSSの関数の意図を汲み取って利用したり、
必要であれば、OSSに対してIssueをあげたりもする。

設計であれば、その言語に一番適した設計をするというのが利用力であると考える。
おそらくはできるのだろうがHaskellでオブジェクト指向をしようとしたりは、あまりいい打ちてではないのだろうか?
※もちろんどういうシーンで…とかもあるので間違いはない。

多くの人が技術力技術力って言ってるのはここを指してるのではないかと思っている。

2-7. 品質向上力

技術でつくったモノの品質を向上させる能力を指す。
テスト → 修正 の流れで、品質をあげていく能力を指す。

リファクタリング能力もここに含まれるだろう。
※そもそも、リファクタリングは単体自動テストが存在するはずだ。
※最初からきれいに書く能力は、技術利用能力に含めたいと考える。

2-8. デプロイ・ローンチ力

製品出荷についての能力を指す。
デプロイフローや、はたまた、CI/CDを考える能力
顧客に先にデリバリーする流通まで考えられたらさらにいいのかもしれない。

運用をしていくソフトウェアなら、ここに、製品戦略も交えないといけない可能性もある。

3. まとめ

技術力と一言でいわれても、これくらい多岐にわたっていると考えている。
安易に、技術力と呼称するのも、なんかちょっと違うような気がしている。
逆に、なんだろうか、技術利用能力だけで語るのも、狭すぎるかもしれない。

結論を書いておくと、技術力という言葉は非常に曖昧で分野でみて、能力評価をしたほうがいいのだと思う。
なんとなく、技術力が高そうというだけでは、やはり評価として曖昧になるのではないだろうか?

細分化をしたほうが、具体的な能力向上の解決策もでると考える。

以上、技術力についてでした。

もし、こんなのも技術力じゃないか?とかあればコメントを貰えると嬉しいです。

18
14
4

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
18
14

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?