間違ったスキルを身につけていないか
スキルを身につけることは、私たちが成長する上で重要な要素であります。成長というのは抽象的に言うと２つあり、成長とは、「何かに対する課題発見の質が上がることや、何かに対する課題解決の質が上がること」を意味しています。質というのは解像度のことです。
つまり解像度はどのくらい明確に「物事」を理解しているかです。私たちはスキルを身につけることによって、物事が多角的に見え、選択肢の幅が広がり、効率性や生産性や再現性が上がります。
しかしスキルを身につける上で注意しなければならないのが、
「そのスキルはエスクペリエンスかテクニックかアーキテクチャーなのか」です。
意味がわからないと思いますのでそれぞれの要素を因数分解していきます。
スキルの因数分解
まず区別しておきたいのが、スキルの取得方法と種類です。スキルの取得方法というのは、「自分」「他人」「テレビ」「ニュース」「本」「仕事」「SNS」などあります。今回は上記のスキルの取得方法については話しません。
この記事で話すことはスキルの種類です。スキルについてもう少し深掘りしていきますと、スキルは大きく分けて3つほどあるのかなと個人的には思っています。※ここについては個人的な解釈ですので個人差はあると思います。
その３つを挙げると、以下に分類されると思います。
・エスクペリエンス（経験）
・テクニック（技法）
・アーキテクチャー（構造）
エクスペリエンスとは自身の経験に基づくスキルです。例えば何年か同じ仕事をしていればその仕事をできるようになると思うのですが、それはエクスペリエンスの要素が強いです。
テクニックとは一時的な情報に基づくスキルです。仕事をしている上で一時的に分からないことが出た時に、人に教えてもらったり、ネットで調べてインプットすることで解決できることがありますが、それはテクニック要素が強いです。
アーキテクチャーとは構造的な理解に基づくスキルです。何かを設計構築する上で、何が必要なのかなぜこの構築が必要なのかという要件定義をしたり、工程を立てたり、どのような設計をしてどのような手順で構築するかといったような、全体把握をしたあとに、実行に落とし込むような仕事は、アーキテクチャー要素が強いです。
課題解決で考えてみる
ここでスキルの区分に関して、「ご自身が使っているスマホが今まで繋がっていたWifi機器に繋がりにくくなった」という例で考えてみます。
エクスペリエンスというのは、以前発生した事象と同じスキルを用います。例えば、以前スマホのWifiの設定がOFFになっていたから、設定をONにしようとか、以前Wifi機器やスマホの再起動で復活したから再起動しようという感じです。
テクニックというのは、ネットや本で調べてきた一時的なスキルを用います。例えばネットで調べたら解決方法が載っていたWifi機器に接続して設定を変更したり、Wifiの周波数帯を変更してみたり、スピードテストをしてみるといった感じです。
アーキテクチャーというのは、スマホ側かLAN側（自身の家の通信環境）かWAN側か（通信業者の通信環境）か適切に切り分けてどのレイヤーでボトルネックが発生しているか構造的に考察し解決するようなスキルを用います。
注意してほしいのですが、アーキテクチャーのみ使って問題解決をすると言うことはまずありません。３つの区分はレイヤーが違うだけで問題解決時には全ての要素を使って問題解決をしています。ではアーキテクチャーって別にみんな使ってるからいちいち区分けしなくてもいいじゃんと思われるかもしれませんが、明確に違うと申し上げておきます。本質的に言うと、アーキテクチャーを理解せず、なんとなく（アーキテクチャーもどき）問題解決をしていると言うことです。
より詳しくスキルについてみていきます。
スキルの公式
私はスキルには公式があると思っています。
その公式は
y = ax + b
です。
それぞれのパラメータは以下と定義します。
y: スキル
a: 経験値
x: 課題（外部的な変数と思ってください）
b: テクニック
シンプルですね。
もう少し説明を加えると、あなたのあるスキルは、
「経験値 x 課題（あなたが解く問題） + テクニック」で表せます。
公式の解説
スキルというのはある課題(x)が存在する時に発揮します。課題(x)が与えられていなければ、経験値(a)もテクニック(b)もいらないのでスキル(y)は0です。ある課題(x)があってこそあなたのy(スキル)は真価を発揮します。
ある課題(x)が与えられ、その課題を定数である経験値(a)で掛けます。そしてテクニック(b)で武装してその値を足します。これがあなたのスキルとなります。
ここで疑問に思われるでしょう。スキルの中にアーキテクチャーがないのです。
アーキテクチャーについて詳しくみていきましょう。
アーキテクチャーはどこ？
公式にアーキテクチャーないじゃん！と思ったあなたは感が鋭いかもしれません。そうです。この公式にはアーキテクチャーは存在していません。ではアーキテクチャーはどこに存在するのか。
実はアーキテクチャーは公式そのものなのです。つまりはアーキテクチャーは公式を作り出すスキルということです。
y = ax + b（スキル = 経験値 * 課題（あなたが解く問題） + テクニック）
この公式を作る能力こそアーキテクチャーであり、アーキテクチャーは我々が本当に身につけるべきスキルであり、あなたが成長し続ける本質的な手段だと私は考えています。
重力の公式が思い浮かぶからこそ、崖から足を踏み外した時に下に落ちることが予測できます。エクスペリエンスやテクニックだけ知っていても、なぜ崖から落ちるのか理解できず他のことに転用できません。
つまりは、公式を推測する能力がなければ、複雑化した現代の本質的な課題の発見および課題の解決はできません。アーキテクチャーを理解する事があなたにとっての本当のスキルになるのです。
現実世界の公式は、複雑化している
実際に我々が直面する課題は、複雑化の極みのような形をしています。
つまりは、y = ax + b という緩い公式ではなく、
y =ax + b
y = y2(y1)
y = y3(y2(y1)))
・・・・
というような深い関数、そして複数の課題(つまりは変数)が絡み合って私たちに襲いかかります。この考えはディープラーニングとも少し似ています。ただし公式を作るということは、関数が増えるにつれて複雑化し難しくなります。
一方、ディープラーニングの場合だと、深い関数にするほど関数の表現力が増し、変数（入力データ）が多いほどより正確な値を返すようになるところが、公式を作ることと相反します。公式を作ったらAIに解決してもらえれば良いので人類に残された道は公式を作ることなのかもしれませんね笑
また、少し課題の変数が変化（公式が変化）しただけで対応できなくなるのはナンセンスです。どのような課題でも適切なエクスペリエンスとテクニックを用いて公式を作ることが求められます。上述しましたが、アーキテクチャーを理解せず、なんとなく（アーキテクチャーもどき）問題解決をすることはしてはいけません。
テクニックとエクスペリエンスの罠
注意してほしいのは、エクスペリエンスやテクニックが悪いとは言っていません。それらがないとあなたは成長できません。ただしある時点からあなた自身が成長していないと感じるのは、エクスペリエンスとテクニックの限界がきているのかもしれません。
私は再現性がなければそれはうまく行っても「運」であって本当のスキルではないと思います。もちろんある事象が発生した時に、解決に至る全ての道筋を初めから知っている必要はありません。
事象の解決に至るには、変数(x)を正しく理解して、公式を推定できれば良いです。あとは、経験値(a)とテクニック(b)をネットや書籍、あるいはその情報を持っている担当者に連絡するなど解決に至るための変数や定数を持ってからば良いです。
問題なのは、その公式を推定できる能力がないことです。y=ax+bという公式を推測できなければ何から始めれば良いか分かりませんし、適切なスキルを用いることができません。
どの経験やテクニックを使えば良いか分からない。そういう状態に陥ってしまうのがまさしく公式が分からない状態なのです。
因みによく文系と理系みたいな区分で分けられることが多いです。しかしこの分け方に意味はあるのでしょうか？自分が文系といっている方は自分はスキルがないと言っているようなものだと感じます。
アーキテクチャーが理解できる人は全ての分野について直ぐに理解できるようになります。その時々で全く知識がなくても、です。素早く最小のアーキテクチャーを理解して必要であればテクニックを外から拾ってきて公式に当てはめていきます。
まとめ
この記事ではあなたが成長に伸び悩む理由がアーキテクチャーではなく、エクスペリエンスやテクニックを追い求めているからであるとお話ししてきました。
上司がこのエクスペリエンスやテクニック系の人であると本当に厄介です。上司が教えてくれることは全て経験則かネットに書いてあることだからです。アーキテクチャーを作る能力がないからこそ再現性がなく、根性論を自覚がないまま言ってきます。
つまりはエクスペリエンスとテクニックを言ってくる上司には部下を育てる力はありません。その事に部下は薄々気付き始めます。そうなると上司はどうなるでしょうか。感情論に行き始めます。できないのはお前がダメだからだとちゃんとやってるのかと。部下の努力によって部下がアーキテクチャーを理解し始めてくると上司は自分の地位が脅かされます。そうなると最終的にどうなるでしょうか。上司は権威を用いて部下を支配します。
逆にアーキテクチャー系の上司だとどうなるか。部下ができない理由を的確に把握をしてピンポイントに指摘してくれます。もしくはアーキテクチャー自体やアーキテクチャーを構築する上で必要になる情報（本やネット）を教えてくれるかもしれません。そんな上司にであったら本当にラッキーだと思います。
そして是非ともあなたが上司になったらアーキテクチャーを作る側となり、部下にアーキテクチャーを教えられる素敵な上司になってください。
その一助になれば、そんなに嬉しいことはありません。若い力で日本を変えていきましょう！