がるの健忘録 このページをアンテナに追加 RSSフィード

2011-04-25

[]スキルの深広練

タイトルはきっちりと造語です。とりあえず「しんこうれん」とか読んでみようかしらん。

お題は、まぁ最近口の端に上らせることの多い「スキルの高さ」とかいう観点の話について。

とりあえず一端「Webアプリケーションエンジニア」って事にしときますが…まぁどの業界に行っても、知っている限り「一緒」です。


んと…「スキルが高い/低い」という発言は、まぁ、ままあるのですが。

実際には「3つの方向がある」んじゃなかろうか、と思ってます。


まず一番わかりやすいのが「出来るかできないか」という尺度。

この軸においては「より多くの、より高難易度なことが出来る」事が、スキルの高さに直結します。

1〜2年未満のソフトウェアエンジニアさんなんかですと「組めないもの」も多々あろうかと。これらが「組めるようになる」のがスキルの上昇です。

これをおいちゃんは「スキルが深くなる」と表現してみようか、と。


次に比較的わかりやすいのが「他の知識との組み合わせができるか出来ないか」という尺度。

ある程度を超えると数学の知識とかが必要になる世界ですし、マーケティング分析の知識なんかも便利ですね。場所によっては流通や金融、もうちょっと突っ込んで簿記が出来るとか、そゆ系の「+α」なエトセトラ、です。

「業務知識に長けた」とかいう系の方が、このあたりお強いですね。

これをおいちゃんは「スキルが広くなる」と表現してみようか、と。


最後に。一番わかりにくいのですが「"出来る"技術がどれくらい鍛錬されているか」という尺度。

非常に厄介な概念なので、ちと説明は後述。

簡単に書くと「より効率のよい、よりメンテナンス性の高いプログラム」が書けるかどうかとか、その辺。

これをおいちゃんは「スキルが練られる」と表現してみようか、と。


とりあえず。ある程度までの「深さ」と、業務にもよるのですが「広さ」とは、概ね不可欠です。

「言われてものが組めない」のではお仕事が成り立ちませんし、ある程度設計とかを進めると、多少の「業務知識」はやっぱりほしいものですので。

で…「ある程度の深さ+ある程度の広さ」は、まぁ個人差もありますが…業務経験2〜5年くらい、でつかめるんじゃないでしょうか?

表現としては「一通り(どうにかこうにか、かもしれないけど)システムが組める」状態、ですね。


で…ここが、分水嶺

「練度」が必要かどうか、ってのが、ぶっちゃけこの文章の眼目。


まずは不要論。

「練度」が高くなると「より効率的に」プログラムが書けます。練度が低いことによっておきるのは例えば

サーバ資源を大量に食ってしまう

・作成に時間がかかる

・修正変更が異様なほどに大変

・ある程度以上改修すると「作り直す」ほかなくなってしまう

などがあります。

…が、これらは全部「力技で」解決が可能です。


サーバ資源を大量に食う」場合は、単純にサーバの増強とかで片付きます。以前に「数千レコードの"マスタテーブル"をとりあえず全件読み込んで腹に抱えて処理」とかいう練度の低いプログラムを見ましたが、「サーバのメモリを潤沢に積む」ことで、この問題に対応することが可能です。


「作成に時間がかかる」ってのは、まぁそのまま時間コストを飲むなり、あるいは「ある程度の人数を投入する」なりで片付きます。「休日出勤+徹夜」も、単純に時間を短くするためには非常に有効ですね(人月神話銀の弾丸? なにそれ、おいしい?)


「修正変更が異様なほどに大変」ってのは、これはマンパワーによってどうにかなります。えと…例えば「XSS脆弱性」があって、随所に関所をしていなかったために、修正箇所がどうも何十箇所もある、なんていう練度が低いプログラムが、まぁあちこちに散らかってますが。「大量の人数を投入して修正」「大量の時間を作って、さまざまなケースをテスト」することで、つまり「大量の時間と大量の人間」をぶち込むことで、問題をヘッジすることが可能です。


「最早改修不能、作り直しが不可避」なんていうのもまた、マンパワーによって片付きます。んと…おいちゃんが言うところの「レゴじゃなくてジェンガプログラム」で、かつ崩壊係数がMaxに行ったような、練度の低いプログラムでも。「大量の人数を投入して」一端作り直すことで、一端ジェンガを「リセット」できるので。しばらくの間は、また修正追加が可能になります。


こうやって考えると、「より適切なプログラムを組む」練度という方向については、あまり必要なものではありません。

…というのが、多くの現場の、まぁ正直「本音」でしょう。口ではなくて、態度/行動を見ていると、顕著に見え隠れします。

また、いわゆる「腰掛けている」ソフトウェアエンジニアな方々が思っている根っこが、大体この辺です。「出来るからいいじゃん」。

このあたりは概ね「体力で片付く」ソフトウェア作成法ですね。

35歳定年説、うべなるかな。


で。

少しだけ冷静に、別ジャンルの知識を持ち込んでみましょう。


利益、っていう「概念」があります。

利益は「利益として」出てくるのではなくて、「売上高 - 経費」という数式から導き出される差分です。

んで、ソフトウェアにとっての「経費」って、ほとんど人件費です。


だとすると。

サーバに対して無理な負荷をかけない設計とか

・makeの時間が早いとか

・ビジネスの流れにあわせた修正が、無理のない工数で可能とか

・「作り直し」をせずに、無理のない追加修正が長い間可能であるとか

というような「経費部分が圧縮/削減できる」事は、普通に、冷静に考えると「不可避」なはずです。

で、そこから「スキル練度の上昇」は、経営的には「不可避」なんじゃなかろうか、と、おいちゃんは考えるわけです。


この辺を「数字だけで」考えると、大体、こんな天秤になると思われます


左のお皿:(新人の募集&大量の無駄資源)

vs

右のお皿:(人材の教育)


で。数字で見極めたわけじゃないので、そのレイヤーでとやかくは言わないってか言えないのですが。

おいちゃん的には「練度が低いままの体力勝負&磨耗部品扱い」は「人間の使い捨て化」なので、いやだなぁ、と。

まぁいつものおいちゃんの基本スタンス。


なので。

おいちゃんは、スキルの深度広度以上に練度を見るわけ、なのですね。

自分の技術が「自分のサービスを構築する」ものだとしても「他人のサービスを構築する」ものだとしても。


一方で。

既存の会社さんの「ごく」一部が練度を見ない、「スキルの高さ」を深広だけで見てしまう理由もまた、このあたりから明らかになってきます。

深い広いで出てくる「出来るできない」は素人にも判定可能であるのに対して、練度だけは「判定する人間のスキルレベル」がダイレクトに問われます。

深遠を覗き見るものは注意しなければならない。深遠を覗き見るとき、深遠もまた私たちを見ているからだ Nietzsche

上司が部下のスキルチェックをするときは。部下もまた、上司のスキルチェックをしているものです。

逆に言うと「部下にスキルをのぞき見られたくない」ような状況の場合、上司が部下の「スキル練度を問いかける」ことは、まずないといってよいでしょう。「そもそも判定できない」上に「面倒くさい逆らいが発生しかねない」わけですから。

そうすると、できるだけ「練度」部分については、つまり具体的にはプログラムの「可読性」とか「性能」とか「メンテナンス性」とか、そういった「質」の部分への言及を出来るだけ避けて「動くか動かないか」だけで会話をするようにんるんですね。


で。

そうすると必然、その現場のエンジニアもまた「練度」について意識がなくなりはじめ、結果として「まったく練度が磨かれない」まま、時間だけが経過していきます。

時間が経過すると、その時間が「自分に対する肯定材料」になってしまうので。結果、より一層「練度は不要である」という感覚が磨かれていきます。


まぁ。

前述したとおり、実際問題「練度が低くても」、リソースをぶち込むことで十分に対応可能なので、不要っちゃぁ不要なのですがね B-p


ビジネスとしても、いちエンジニアとしても。

「練度を無視する」ような世界観に、おいちゃんは、1ミクロンたりとも興味は持てませぬ B-p