スキルの深広練
タイトルはきっちりと造語です。とりあえず「しんこうれん」とか読んでみようかしらん。
お題は、まぁ最近口の端に上らせることの多い「スキルの高さ」とかいう観点の話について。
とりあえず一端「Webアプリケーション系エンジニア」って事にしときますが…まぁどの業界に行っても、知っている限り「一緒」です。
んと…「スキルが高い/低い」という発言は、まぁ、ままあるのですが。
実際には「３つの方向がある」んじゃなかろうか、と思ってます。
まず一番わかりやすいのが「出来るかできないか」という尺度。
この軸においては「より多くの、より高難易度なことが出来る」事が、スキルの高さに直結します。
１〜２年未満のソフトウェアエンジニアさんなんかですと「組めないもの」も多々あろうかと。これらが「組めるようになる」のがスキルの上昇です。
これをおいちゃんは「スキルが深くなる」と表現してみようか、と。
次に比較的わかりやすいのが「他の知識との組み合わせができるか出来ないか」という尺度。
ある程度を超えると数学の知識とかが必要になる世界ですし、マーケティング分析の知識なんかも便利ですね。場所によっては流通や金融、もうちょっと突っ込んで簿記が出来るとか、そゆ系の「＋α」なエトセトラ、です。
「業務知識に長けた」とかいう系の方が、このあたりお強いですね。
これをおいちゃんは「スキルが広くなる」と表現してみようか、と。
最後に。一番わかりにくいのですが「"出来る"技術がどれくらい鍛錬されているか」という尺度。
非常に厄介な概念なので、ちと説明は後述。
簡単に書くと「より効率のよい、よりメンテナンス性の高いプログラム」が書けるかどうかとか、その辺。
これをおいちゃんは「スキルが練られる」と表現してみようか、と。
とりあえず。ある程度までの「深さ」と、業務にもよるのですが「広さ」とは、概ね不可欠です。
「言われてものが組めない」のではお仕事が成り立ちませんし、ある程度設計とかを進めると、多少の「業務知識」はやっぱりほしいものですので。
で…「ある程度の深さ＋ある程度の広さ」は、まぁ個人差もありますが…業務経験２〜５年くらい、でつかめるんじゃないでしょうか？
表現としては「一通り(どうにかこうにか、かもしれないけど)システムが組める」状態、ですね。
で…ここが、分水嶺。
「練度」が必要かどうか、ってのが、ぶっちゃけこの文章の眼目。
まずは不要論。
「練度」が高くなると「より効率的に」プログラムが書けます。練度が低いことによっておきるのは例えば
・サーバ資源を大量に食ってしまう
・作成に時間がかかる
・修正変更が異様なほどに大変
・ある程度以上改修すると「作り直す」ほかなくなってしまう
などがあります。
…が、これらは全部「力技で」解決が可能です。
「サーバ資源を大量に食う」場合は、単純にサーバの増強とかで片付きます。以前に「数千レコードの"マスタテーブル"をとりあえず全件読み込んで腹に抱えて処理」とかいう練度の低いプログラムを見ましたが、「サーバのメモリを潤沢に積む」ことで、この問題に対応することが可能です。
「作成に時間がかかる」ってのは、まぁそのまま時間コストを飲むなり、あるいは「ある程度の人数を投入する」なりで片付きます。「休日出勤＋徹夜」も、単純に時間を短くするためには非常に有効ですね(人月の神話？ 銀の弾丸？ なにそれ、おいしい？)
「修正変更が異様なほどに大変」ってのは、これはマンパワーによってどうにかなります。えと…例えば「XSS脆弱性」があって、随所に関所をしていなかったために、修正箇所がどうも何十箇所もある、なんていう練度が低いプログラムが、まぁあちこちに散らかってますが。「大量の人数を投入して修正」「大量の時間を作って、さまざまなケースをテスト」することで、つまり「大量の時間と大量の人間」をぶち込むことで、問題をヘッジすることが可能です。
「最早改修不能、作り直しが不可避」なんていうのもまた、マンパワーによって片付きます。んと…おいちゃんが言うところの「レゴじゃなくてジェンガなプログラム」で、かつ崩壊係数がMaxに行ったような、練度の低いプログラムでも。「大量の人数を投入して」一端作り直すことで、一端ジェンガを「リセット」できるので。しばらくの間は、また修正追加が可能になります。
こうやって考えると、「より適切なプログラムを組む」練度という方向については、あまり必要なものではありません。
…というのが、多くの現場の、まぁ正直「本音」でしょう。口ではなくて、態度/行動を見ていると、顕著に見え隠れします。
また、いわゆる「腰掛けている」ソフトウェアエンジニアな方々が思っている根っこが、大体この辺です。「出来るからいいじゃん」。
このあたりは概ね「体力で片付く」ソフトウェア作成法ですね。
35歳定年説、うべなるかな。
で。
少しだけ冷静に、別ジャンルの知識を持ち込んでみましょう。
利益、っていう「概念」があります。
利益は「利益として」出てくるのではなくて、「売上高 - 経費」という数式から導き出される差分です。
んで、ソフトウェアにとっての「経費」って、ほとんど人件費です。
だとすると。
・サーバに対して無理な負荷をかけない設計とか
・makeの時間が早いとか
・ビジネスの流れにあわせた修正が、無理のない工数で可能とか
・「作り直し」をせずに、無理のない追加修正が長い間可能であるとか
というような「経費部分が圧縮/削減できる」事は、普通に、冷静に考えると「不可避」なはずです。
で、そこから「スキル練度の上昇」は、経営的には「不可避」なんじゃなかろうか、と、おいちゃんは考えるわけです。
この辺を「数字だけで」考えると、大体、こんな天秤になると思われます
左のお皿：(新人の募集＆大量の無駄資源)
vs
右のお皿：(人材の教育)
で。数字で見極めたわけじゃないので、そのレイヤーでとやかくは言わないってか言えないのですが。
おいちゃん的には「練度が低いままの体力勝負＆磨耗部品扱い」は「人間の使い捨て化」なので、いやだなぁ、と。
まぁいつものおいちゃんの基本スタンス。
なので。
おいちゃんは、スキルの深度広度以上に練度を見るわけ、なのですね。
自分の技術が「自分のサービスを構築する」ものだとしても「他人のサービスを構築する」ものだとしても。
一方で。
既存の会社さんの「ごく」一部が練度を見ない、「スキルの高さ」を深広だけで見てしまう理由もまた、このあたりから明らかになってきます。
深い広いで出てくる「出来るできない」は素人にも判定可能であるのに対して、練度だけは「判定する人間のスキルレベル」がダイレクトに問われます。
深遠を覗き見るものは注意しなければならない。深遠を覗き見るとき、深遠もまた私たちを見ているからだ Nietzsche
上司が部下のスキルチェックをするときは。部下もまた、上司のスキルチェックをしているものです。
逆に言うと「部下にスキルをのぞき見られたくない」ような状況の場合、上司が部下の「スキル練度を問いかける」ことは、まずないといってよいでしょう。「そもそも判定できない」上に「面倒くさい逆らいが発生しかねない」わけですから。
そうすると、できるだけ「練度」部分については、つまり具体的にはプログラムの「可読性」とか「性能」とか「メンテナンス性」とか、そういった「質」の部分への言及を出来るだけ避けて「動くか動かないか」だけで会話をするようにんるんですね。
で。
そうすると必然、その現場のエンジニアもまた「練度」について意識がなくなりはじめ、結果として「まったく練度が磨かれない」まま、時間だけが経過していきます。
時間が経過すると、その時間が「自分に対する肯定材料」になってしまうので。結果、より一層「練度は不要である」という感覚が磨かれていきます。
まぁ。
前述したとおり、実際問題「練度が低くても」、リソースをぶち込むことで十分に対応可能なので、不要っちゃぁ不要なのですがね B-p
ビジネスとしても、いちエンジニアとしても。
「練度を無視する」ような世界観に、おいちゃんは、1ミクロンたりとも興味は持てませぬ B-p
素晴らしい想定
元ネタ
「避難３原則」守り抜いた釜石の奇跡 防災教育で児童生徒無事
http://sankei.jp.msn.com/life/news/110413/edc11041314070001-n1.htm
http://sankei.jp.msn.com/life/news/110413/edc11041314070001-n2.htm
原則１「想定、とらわれるな」
-中略-
児童・生徒ら約６００人は、５００メートル後方にある高台のグループホームまで避難。ここも指定避難場所だったが一息つく間もなく、裏側の崖が崩れるのを目撃する。危険を感じて児童生徒はさらに約５００メートル先の高台にある介護福祉施設を目指した。その約３０秒後、グループホームは津波にのまれた。
原則２「最善を尽くせ」
背後から聞こえる轟音と防潮堤にぶつかる白い波しぶきを見た児童・生徒はたどり着いた介護福祉施設からさらに高台へ駆けた。
原則３「率先し避難せよ」
-中略-
中学生が率先避難者となって小学生を導いた
災害時「以外」でも、色々と当てはまりそうなお話です。
ん…とりあえず「ありえない」とか「大丈夫な、はず」とか「対岸の火事」とか「責任の所在が〜」とか「それはオレのタスクじゃない〜」とかが、一番よろしくない orz
行き詰ると思うんだがなぁ…
「ちょっとしたTipsで劇的に何かが変わる」的な、上っ面な生兵法がえらく人気な反面、「地味なんだけど大切な、んでもって難しい基礎」が、割合とどこまでも軽視されている…というか、好まれていない気がする。
ある程度「まで」はTipsのほうが便利なんだけど。ある程度「以上」に進む場合、原理原則がないと、足元が危なくて仕方ないと思うんだが…ど〜なんだろ？
…で、ふと思う。
もしかして…極論「一子相伝」とかその辺の、いわゆる「奥義についてはごく一部の門弟にしか伝えない」ってのは、その辺から来てるんだろうか？ と。
つまり…「ふつ〜の門下生にはTipsを教えて」おいて。「ををこれは見込みあるぢゃん」と思える弟子にのみ「基礎と原理原則を正しく教える」、っと。
これだと、まぁ差別化も出来るし「ふつ〜の」人たちにとっては面倒もないし。一方で「真っ当な」弟子には、まともなこと教えられるし、教える側のストレスもないし。
…分け隔てなく教えたい、とは思ってはいるんだけど。
その辺は「区別」したほうが、もしかしたら、よいのかしらん？
日々の積み重ねとBreakthrough
量は質に変わる。
変化はある一瞬に、かつ、割と多くの場合に「あるきっかけによって」訪れるのだけれども。
その「変化」に必要なエネルギーのほとんどは、そのきっかけ「以外」の、日々の、さまざまな積み重ねによる。
そう、そのきっかけは、時として「小石が竹にあたって出る音」である程度、かもしれないのだけれども( 翠竹のなかより，発心得道するあり )。
学習も。
「その場から決別したい」という思いも。
それらは、多分、日々の積み重ね。
「未来にツケる」のって、おいちゃんは好まないなぁ…
(潜在を含む)ニーズ「A」がある。
そのニーズを満たすサービスを作成する。
実はそのサービス、正常系はどうにかなっているんだけど、異常系やセキュリティで「特盛りつゆだくだく」な問題点があるんだけど。
その辺は色々と「押し通して」、とにかくまず「みんな使ってる/流行ってる/今動いている」という既成事実を構築してしまう。
問題点をきちんと考察/解決しないのは、コストがかかるから。見方を変えると「今コストを支払うのではなく、問題が発生したときにコストを支払おう」という、後回し。
ある程度以上軌道に乗ってから「問題が発覚」するんだけど、そこは風評操作や公的資金などで「力技で」乗り越える。あるいは「見なかったことにする」とか。実害なんて「知ろうとしなければ」いつまでもなかったことにできるし。
でも、実際には「上っ面を取り繕った」だけなので、本当にシリアスな「実害」は、見えなくしただけで、なくなってるわけじゃない。
これもまた。「もう一回問題が起きたら、そのときにちゃんと対応をすればいいや、今はとりあえず安上がりに上っ面を取り繕うくらいのコストで済ませよう」という、後回し。
増えていく技術的負債と、それに伴う利子。
困ったことに、この手のって複利なので、元本がすげぇ青天井に持ち上がっていく。
で、その元本をみて「こんな量の借金は支払えないから」なかったことにされて上っ面を糊塗して、結果、もっと借金が膨れ上がる。
以上を無限ループ。おいちゃんは for(;;) ではなくて while(true) のほうが好みだけど。
原発(言うまでもなく)とかEvernote(XSSにまつわる話：でも事後対応みてると、ちゃんと「コストかけて、利子だけじゃなくて元金も払ってる」ように、も、見える)とか。Facebookのセキュリティ周りも大分とグレーな話を耳にするし、普通に「セキュリティホールその他の技術的負債のあるシステム」なんてのは正直、山盛りでごろり。
問題があるのはやむをえない部分もあると思う。「完璧な設計」が、人間にそもそも可能かどうか、おいちゃんはとても懐疑的だし。
ただ。
問題点が見えてしまったときに、それを「未来にツケる」のを、おいちゃんは好まない。
問題点が見えるのがイヤで「見ようとも知ろうともしない」のを、おいちゃんは好まない。
コストを後回しにしたほうが、圧倒的に儲かるし、楽なんだけどね。
おいちゃんは「フェイディアスの教訓」を大切にしたいから。
性懲りもなく「PHPについて語っているBlog」に興味を持ってみる
元ネタ
http://d.hatena.ne.jp/tumf/20110321/1300661187
一部「ネタ」とか書かれているハテブもあるようですが、社長さんですし社名を正面に出して書いているようなBlogですんで、正面から受け取ってみたいと思います。
PHPのエンジニアは同じ単価でもスキルの差がある。マネージャはそれを埋めるために最悪自分で動かねばなりません。以下はその最悪に近いケースの話です。
別に、他の言語でも「同じ単価でスキルの差異」はふつ〜にあると思う。
なので「PHPのエンジニアは」って部分には違和感あり。でもまぁそれ以外はそんなもんだと思う。
「マネージャはそれを埋めるために最悪自分で動かねばなりません」は、おいちゃん的には理想到達点(っつかまぁやってるけど)。ただ、それを「すべてのマネージャに要求してよいのか？」って部分で疑問。…要求したいんだけど(苦笑
逆に、運良く良いエンジニアを集められて場合はマネージャの仕事は本来の顧客に向いたものとなるでしょう。
ん…なんか引っかかる。
よいエンジニアであろうとも、マネージャの向きは常に「顧客とチームの両方」を向いている必要があるんじゃないかなぁ？
1.メンバーの経歴はあてにしない
言語に拠らず、ごく当然。
2.メンバーは定時に出社させ定時に退社させる
ど〜なんだろ？
「週40時間労働」は、諸手を挙げて賛成。…ってなるとまぁ、定時出社、定時退社、になるのか。
3.Subversion利用を徹底させる
うんまぁ特に違和感もなく。
4.PHP5.3専用のフレームワークは使わない
状況次第、ではあるかなぁ。ただ「ど〜しても5.3系が必須」って状況もレアだと思うので、業務ベースで考えると、もうちょっと静観してもよいような…名前空間は欲しいような…でも￥はキライｗ
5.テキストエディタの設定を確認する
文字コードと改行コードはたしかに。
インデントは、個人的には２spaces派ｗ
まぁ「統一ルール」があればよろしいのではないか、と。
6.難しいコードを書かせない
いつもながらに難しいところ。おいちゃん的には「必要なら書く、必要ないなら書かない」。
call_user_func()・SPL・リフレクション
call_user_funcは、基本つかわない。
SPLは…うんやっぱり使わないなぁ。
リフレクションは、使わないってよりもうちょっと踏み込んで「可能な限り忌避する」かなぁ。
なんだおぢちゃんのコード、難しくないぢゃんｗ
7.浮動小数を使わせない
至極当然。
8.switchを使わせない
break忘れってのはどうかと思いますが(苦笑
switchを「小器用に多用する」のは、大抵「ろくでもないコードの臭い」がするので、慎んだほうがよろしいのではなかろうか、と。
「どんなswitchがまずいのか」って部分の議論を、ちゃんとメンバー内でしておくとよいのだと思う。
9.正規表現を書かせない
単純に「重い」からおいちゃんキライ。抜けも多いしね。
10.SQLを書かせない
びみょ〜〜〜。「できればORマッパーを利用しましょう」は元々否定派だし。
SQLは「複雑なSQLが書ける」スキルを持ちつつ「基本、シンプルであることを旨とする」のがよいと思っているので。
11.一行でもブロックの{}を省略させない
これも、言語よらず一緒。
12.無理にコメントを要求しない
やだｗ
コメントは「何があろうとも潤沢に」書いてもらうのがおいちゃん流。
13.関数名を日本語にしたがる人に優しく辞書を渡す
あぁ…うん…(遠い目
おいちゃんは、Web系の辞書と翻訳サイトを多用(苦笑
14.ブランチのマージ
ん…これは「やだ」なぁ。
ちゃんと話をした上で、メンバーを信頼したい。
15.コードレビュー環境を用意する
「管理者は、メンバーが帰った後に大量のコードを読まなくてはいけませんので」いやまぁ居る間に読みますがｗ
自分の手に合ったお道具ってのは、大切ですね。
16.深夜にCIを動かして朝一番にチェックする
引き続き思案中。
17.テストは管理者が書く
テストって「指示書」の代わりにもなるので、ひとつあり。
おいちゃんは「テストを書いてもらって、それをレビューする」ことで、設計のお勉強を兼ねていただくことが多いです。
18.バグはBTSに
よろしいのではないか、と。
19.他の言語の話をしない
そなの？
そこまで深い愛着をPHPに対してもつ人が周囲にはいないっていうかそもそも平気で「PHPってだめぢゃん」とかBlogに書いているおいちゃんがなに言ったって説得力ないよねぇｗ
20.開発環境の話をしない
んむり…ここもそんなに気にしないかなぁ。っつかまぁ、おいちゃんのIDEは「vi」基本だしｗ
私の経験では、コードレビューと修正、明日の分の指示書作成については、1メンバーあたり1時間程度見ておけば十分だと思います。（たとえば5人分なら19:00から5時間なので終電に間に合いますね！）
ここは断固として否定。
「週40時間」は、あらゆる人に適用されるべきだと思っているので。
全体として…「マネジメント」というか「現場指揮官」という感じの印象値。
あとは…端々に、びみょ〜に「現場を信用していない感」が漂うのが、なんとなく気になるのかなぁ。
気になったので、memo。
