タイトルはきっちりと造語です。とりあえず「しんこうれん」とか読んでみようかしらん。
お題は、まぁ最近口の端に上らせることの多い「スキルの高さ」とかいう観点の話について。
とりあえず一端「Webアプリケーション系エンジニア」って事にしときますが…まぁどの業界に行っても、知っている限り「一緒」です。
んと…「スキルが高い/低い」という発言は、まぁ、ままあるのですが。
実際には「３つの方向がある」んじゃなかろうか、と思ってます。
まず一番わかりやすいのが「出来るかできないか」という尺度。
この軸においては「より多くの、より高難易度なことが出来る」事が、スキルの高さに直結します。
１〜２年未満のソフトウェアエンジニアさんなんかですと「組めないもの」も多々あろうかと。これらが「組めるようになる」のがスキルの上昇です。
これをおいちゃんは「スキルが深くなる」と表現してみようか、と。
次に比較的わかりやすいのが「他の知識との組み合わせができるか出来ないか」という尺度。
ある程度を超えると数学の知識とかが必要になる世界ですし、マーケティング分析の知識なんかも便利ですね。場所によっては流通や金融、もうちょっと突っ込んで簿記が出来るとか、そゆ系の「＋α」なエトセトラ、です。
「業務知識に長けた」とかいう系の方が、このあたりお強いですね。
これをおいちゃんは「スキルが広くなる」と表現してみようか、と。
最後に。一番わかりにくいのですが「"出来る"技術がどれくらい鍛錬されているか」という尺度。
非常に厄介な概念なので、ちと説明は後述。
簡単に書くと「より効率のよい、よりメンテナンス性の高いプログラム」が書けるかどうかとか、その辺。
これをおいちゃんは「スキルが練られる」と表現してみようか、と。
とりあえず。ある程度までの「深さ」と、業務にもよるのですが「広さ」とは、概ね不可欠です。
「言われてものが組めない」のではお仕事が成り立ちませんし、ある程度設計とかを進めると、多少の「業務知識」はやっぱりほしいものですので。
で…「ある程度の深さ＋ある程度の広さ」は、まぁ個人差もありますが…業務経験２〜５年くらい、でつかめるんじゃないでしょうか？
表現としては「一通り(どうにかこうにか、かもしれないけど)システムが組める」状態、ですね。
で…ここが、分水嶺。
「練度」が必要かどうか、ってのが、ぶっちゃけこの文章の眼目。
まずは不要論。
「練度」が高くなると「より効率的に」プログラムが書けます。練度が低いことによっておきるのは例えば
・サーバ資源を大量に食ってしまう
・作成に時間がかかる
・修正変更が異様なほどに大変
・ある程度以上改修すると「作り直す」ほかなくなってしまう
などがあります。
…が、これらは全部「力技で」解決が可能です。
「サーバ資源を大量に食う」場合は、単純にサーバの増強とかで片付きます。以前に「数千レコードの"マスタテーブル"をとりあえず全件読み込んで腹に抱えて処理」とかいう練度の低いプログラムを見ましたが、「サーバのメモリを潤沢に積む」ことで、この問題に対応することが可能です。
「作成に時間がかかる」ってのは、まぁそのまま時間コストを飲むなり、あるいは「ある程度の人数を投入する」なりで片付きます。「休日出勤＋徹夜」も、単純に時間を短くするためには非常に有効ですね(人月の神話？ 銀の弾丸？ なにそれ、おいしい？)
「修正変更が異様なほどに大変」ってのは、これはマンパワーによってどうにかなります。えと…例えば「XSS脆弱性」があって、随所に関所をしていなかったために、修正箇所がどうも何十箇所もある、なんていう練度が低いプログラムが、まぁあちこちに散らかってますが。「大量の人数を投入して修正」「大量の時間を作って、さまざまなケースをテスト」することで、つまり「大量の時間と大量の人間」をぶち込むことで、問題をヘッジすることが可能です。
「最早改修不能、作り直しが不可避」なんていうのもまた、マンパワーによって片付きます。んと…おいちゃんが言うところの「レゴじゃなくてジェンガなプログラム」で、かつ崩壊係数がMaxに行ったような、練度の低いプログラムでも。「大量の人数を投入して」一端作り直すことで、一端ジェンガを「リセット」できるので。しばらくの間は、また修正追加が可能になります。
こうやって考えると、「より適切なプログラムを組む」練度という方向については、あまり必要なものではありません。
…というのが、多くの現場の、まぁ正直「本音」でしょう。口ではなくて、態度/行動を見ていると、顕著に見え隠れします。
また、いわゆる「腰掛けている」ソフトウェアエンジニアな方々が思っている根っこが、大体この辺です。「出来るからいいじゃん」。
このあたりは概ね「体力で片付く」ソフトウェア作成法ですね。
35歳定年説、うべなるかな。
で。
少しだけ冷静に、別ジャンルの知識を持ち込んでみましょう。
利益、っていう「概念」があります。
利益は「利益として」出てくるのではなくて、「売上高 - 経費」という数式から導き出される差分です。
んで、ソフトウェアにとっての「経費」って、ほとんど人件費です。
だとすると。
・サーバに対して無理な負荷をかけない設計とか
・makeの時間が早いとか
・ビジネスの流れにあわせた修正が、無理のない工数で可能とか
・「作り直し」をせずに、無理のない追加修正が長い間可能であるとか
というような「経費部分が圧縮/削減できる」事は、普通に、冷静に考えると「不可避」なはずです。
で、そこから「スキル練度の上昇」は、経営的には「不可避」なんじゃなかろうか、と、おいちゃんは考えるわけです。
この辺を「数字だけで」考えると、大体、こんな天秤になると思われます
左のお皿：(新人の募集＆大量の無駄資源)
vs
右のお皿：(人材の教育)
で。数字で見極めたわけじゃないので、そのレイヤーでとやかくは言わないってか言えないのですが。
おいちゃん的には「練度が低いままの体力勝負＆磨耗部品扱い」は「人間の使い捨て化」なので、いやだなぁ、と。
まぁいつものおいちゃんの基本スタンス。
なので。
おいちゃんは、スキルの深度広度以上に練度を見るわけ、なのですね。
自分の技術が「自分のサービスを構築する」ものだとしても「他人のサービスを構築する」ものだとしても。
一方で。
既存の会社さんの「ごく」一部が練度を見ない、「スキルの高さ」を深広だけで見てしまう理由もまた、このあたりから明らかになってきます。
深い広いで出てくる「出来るできない」は素人にも判定可能であるのに対して、練度だけは「判定する人間のスキルレベル」がダイレクトに問われます。
深遠を覗き見るものは注意しなければならない。深遠を覗き見るとき、深遠もまた私たちを見ているからだ Nietzsche
上司が部下のスキルチェックをするときは。部下もまた、上司のスキルチェックをしているものです。
逆に言うと「部下にスキルをのぞき見られたくない」ような状況の場合、上司が部下の「スキル練度を問いかける」ことは、まずないといってよいでしょう。「そもそも判定できない」上に「面倒くさい逆らいが発生しかねない」わけですから。
そうすると、できるだけ「練度」部分については、つまり具体的にはプログラムの「可読性」とか「性能」とか「メンテナンス性」とか、そういった「質」の部分への言及を出来るだけ避けて「動くか動かないか」だけで会話をするようにんるんですね。
で。
そうすると必然、その現場のエンジニアもまた「練度」について意識がなくなりはじめ、結果として「まったく練度が磨かれない」まま、時間だけが経過していきます。
時間が経過すると、その時間が「自分に対する肯定材料」になってしまうので。結果、より一層「練度は不要である」という感覚が磨かれていきます。
まぁ。
前述したとおり、実際問題「練度が低くても」、リソースをぶち込むことで十分に対応可能なので、不要っちゃぁ不要なのですがね B-p
ビジネスとしても、いちエンジニアとしても。
「練度を無視する」ような世界観に、おいちゃんは、1ミクロンたりとも興味は持てませぬ B-p
