元ネタ
コーディング技術にこだわり過ぎるとITエンジニアの地位は向上しない
http://getlife.hateblo.jp/entry/2014/02/06/030300
ん…端的には「言っている話」そのものではなくて、そこから匂い立つものが、大変に香ばしいかなぁ、っと。
とりあえず「直接書いてある」、多分、肯定的な見解をしている人達が見ているところを、先に見てみます。
「どう作るか」よりも「何を作るか」の方が価値があるからです。
………………びみょ〜〜〜、では、あるのですが。
これを、善意を持って「どう作るか、と同じくらい、何を作るかには価値があるからです」と読み替えると、結構うなずける人も多いのではないか、と思います。
イノベーションの源泉は顧客に対してどんな価値を提供するか、にあり、価値の提供方法が問題となるわけではないと。
ここは(突っ込みどころは山盛りであれど)一定の肯定が得られるところかと思います。
お客様は、結局「自分たちが得られた果実に」対価を支払うものなので。
ビジネス価値を生み出すための仕様を作れる人が優遇され
この部分も、肯定感を持つ人は多かったのではないかと思います。
まぁぶっちゃけ「プログラムを何行何百行何万行書いたところで、どこからもお金は生えてこない」ので。
技術があることが価値ではないんです。お客を喜ばせることが価値なんです。
ここは、(ここだけを抜き出せば)非常にYesなんですね。
実際「技術だけの会話をしてお客様をあきれさせた」エンジニアや、それを横目で見てうんざりしているエンジニアってのは、一定数いるんじゃないか、って思うので。
で、お客からしたら技術の中身なんかぶっちゃけどうでもいいんです。
………但し書きはつくものの、事実の一面ではあります。
前後しますが、冒頭で
本旨は「プラスアルファが必要って言ってる
とあるので、このあたりからも「技術力だけじゃなくて、プラスアルファも必要だよ」って言いたいんだろうなぁ、という、善意的解釈が成り立ち得ます。
なので。
元々の欲求として「単にプログラムを書くだけではなくて、ビジネスの話を含む諸々にまで視野を広げたエンジニアになりたい」と思う向きについては、この記事を肯定的に見ている人も少なくないのではないか、と思うのですね。
若干善し悪し微妙にしても「フルスタックエンジニア」とかって単語もありましたし。
おいちゃんも、特に経営系の方からの評価軸って「技術力」というよりは(まぁ「無茶ぶり出来る人」って評価をしてくださる方もいるのですが)、「金の話が出来るエンジニア」って事も、少なくないですし。
ただ…正直。
文章の各所から「技術力蔑視」の臭いが、びしばしと香るわけですよ正直。
そこが物凄く気になる。
で、ちと「自分自身の咀嚼」を兼ねて、その辺を見ていこうかなぁ、と。
推進役（プロジェクトマネージャー、プリジェクトリーダなど）
タスク優先度の決定やメンバーの補充、教育など、チームを活動させるための旗振り役を担います。
分析役（SE、アプリケーションエンジニア、業務エンジニア、システムアーキテクトなど）
業務分析やシステム分析を行い、「何を作るべきか」を明確にするための分析役を担います。
実装役（コーダー、テスターなど）
実際に動くアプリケーションをプログラミング、品質評価を行う実装役を担います
まぁこれを分業にしている時点で正直。
推進役はある程度重要なんだけど「専業」にするには少々お仕事の幅が狭くて。
分析と実装は、行きつ戻りつの関係なので、そもそも分離してはいけない。
もちろん「SIerは大抵分離したがる」ってのもあるんだけど、同時にそれって「駄目なシステムばかり産み散らかしてる」って現実も忘れちゃいけない。
ん…前にも書いた(っつかどこかから持ってきた)けど、簡単な一言。
「一手目二手目で、王手まで読み切れるのですか？」
理由はカンタン。「どう作るか」よりも「何を作るか」の方が価値があるからです。
文章を「そのまま」読み取ると、アウト。
「どう作るか」と「何を作るか」は、どう考えても両輪。「どちらにより価値があるか」とか、考えている時点でおかしい。
コレって「他方を低く見ている」わかりやすい証左。
ん…この文章を逆にするとわかりやすいかも。
理由はカンタン。「何を作るか」よりも「どう作るか」の方が価値があるからです。
実際、この文章も「ある程度までの正当性」がある。おいちゃんは、言おうとは思わないけれども。
「作ったはいいけど糞プログラム糞設計の塊で、保守メンテがあんまりにも高コストで酷い目にあった」技術者なら、一度は「「何を作るか」よりも「どう作るか」の方が価値がある」って思った事が、あるんじゃなかろうか？
イノベーションの源泉は顧客に対してどんな価値を提供するか、にあり、価値の提供方法が問題となるわけではないと。
これもダウト。
「価値の提供方法」は、「どんな価値を提供するか」に直結する部分があるので。
コストメリットだけではなく、オフショア−本国間の時差を利用したスピード開発などでも利用されてます。
ちなみに。おいちゃんの身近のオフショアで、一定以上の品質を、正直あまり見たことがない。
いや別に「オフショアは全部低品質」とは言わないんだけど。
実際問題、例えば展示会でオフショア誘発を各国がやってるんだけど、彼らが最近必ず言うのが「日本に匹敵する品質」。つまりこれって「少なくとも今までは低品質だった」って言っているようなもんだし、これは、実際に見聞きしたり体験したりしている状況と合致している。
でも、件のBlogの主は、納品物の品質に全く言及していない。
そのあたりからも「納品物の、コードの品質」に気を払っているのか？ と考えると、とても懐疑的にならざるを得ないんじゃないかなぁ、と。
事実上アメリカ内のプログラマとして生き残っているのは、ビジネス分析や高度な設計などオールラウンダーとして活躍するプログラマ、ビックデータなどのデータアナリスト要素を持つプログラマ、インフラとの統合など高度な技術を持つプログラマが主に生き残ると推測できます。
ん…「ビジネス分析や高度な設計などオールラウンダーとして活躍するプログラマ」「ビックデータなどのデータアナリスト要素を持つプログラマ」これが出来る人がいると、いわゆる分析屋さんは「不必要」になりますよね？
「インフラとの統合など高度な技術を持つプログラマ」…インフラとの統合、ってのが何を意味しているのか、にもよるんだけど。
Web系やってたら「ある程度のインフラ知識があり、プログラム知識と組み合わせる」って、前提条件じゃないの？ 高度なの？
プログラムを書く人（＝コーダ）ではなく、プログラムを使ってビジネスが出来る人（≠コーダ）
「プログラマ」と「コーダ」って、かなりニュアンスに差があると思う。
で、この用法もまた、割と「技術軽視、技術蔑視」の人が無意識にやりやすいポイント。
ビジネス価値を生み出すための仕様を作れる人が優遇され、ただのコーディングが出来るだけのコーダが冷遇されてきた時代があります
さて。「美しいコードが書ける」人は、どっち側になるんだろう？ という質問。
おそらく質問をしたら「ビジネス価値を生み出す方だ」って言いそうなんだけど、割と懐疑的。
ちなみにその場合、多分おいちゃんはこう質問をする「なんで"美しいコード"ってビジネス価値があるの？ それは、おいくら万円？」*1
ここも怪しい。
「美しいコードが書ける」人は、どっち側になるんだろう？ という質問を、再度。
そのための解法で「paiza」を紹介してますが
-中略-
といったコーディング志向になってしまっています。ビジネスのビの字も出てきてません。なんでそこでプログラムにいっちゃうの。せめて、ビジネス分析だとか、違った面のスキルを競えばいいのに。。。
このあたりから。プログラミングスキルについて、全く価値を置いていないんだろうなぁ、という事が、割とありありと見て取れます。
逆に聞きたいんですが。「基本的なデータ構造とアルゴリズムをちゃんと修めていないようなレベルのプログラマが書いたコード、ビジネス的に、役に立ちますか？」と。
このプラスアルファこそが、日本の冷遇されているとされるエンジニアに不足していると感じてます。
であれば、そちらを改善する事こそがエンジニアの地位向上を図る早道ってもんだと思います。
で、ここ。
彼の言うプラスアルファは常に「ビジネスの提案」であって、「提供するプログラムの品質の向上」という側面が、欠片も出てこない。
で、お客からしたら技術の中身なんかぶっちゃけどうでもいいんです。Javaで書こうが、Cで書こうが、COBOLで書こうが、そこに価値の本質はないから。
ある。そこに、価値の本質の一旦があり、お客様にとってのメリットデメリットが、明らかに、ある。
なのに「ない」と言い切っているあたりで「オワッテルなぁ」と思うのです。
技術が、見えていないし、重要視していないというか軽視している。
これが「素人さん」の発言なら、まだ、いざ知らず。
「とあるSIerでプロマネやっているオッサン」という立ち位置の人が言っていると考えるにつれ「あぁ技術軽視なんだなぁ」としみじみ感じるわけです。
…ってのを書いてたら、追記があったぽい。
「コーディング技術にこだわり過ぎると〜」の反省会
http://getlife.hateblo.jp/entry/2014/02/07/030227
技術がなければ動けないし、ニーズを汲み取れなければあさっての方向に進んでしまう。両方揃うことが必要、って意味で。
多分書くと思った。
でも、上述の通り、実際には「双方とも重要」とは、とても取れない内容だったわけで。
SIerでは指示通りの実装の人を「コーダ」として軽視していた因習があったよ。
あぁやっぱり。
んじゃ「きちんとプログラミングを設計する」のは、誰なんだろう？
で、ここからすると
プログラムを書く人（＝コーダ）ではなく、プログラムを使ってビジネスが出来る人（≠コーダ）
ってつまり「指示通りの実装をしている人、が、いきなりビジネスを出来るようにする」って登り方になって、やっぱり「適切に技術力を磨く」ルートが、多分、存在すらしていない。
実装だけしかできないと
「だけ」って単語でくくれるほど、実装の世界、甘くないし。
っつか舐めんな、って感じだ。
故に
技術軽視なんて思いにもよらなかった指摘をもらってしまった。。。
と書かれても「…思いもよらなかった？」と疑問しか湧かないわけで。
ココらへんにも書いたけど、上手く伝えられなかった。。。書き方のミスですね。
正直、技術軽視と言われるとちょっと書き方失敗したなってキモチです。
「書き方の問題」じゃないよなぁ、と感じる訳です。
んで、結局、どれだけ言い訳しても、根底にある「プログラミングの品質に対する無配慮、無思慮」があふれ出てるので。
そりゃまぁ嫌がられるよなぁ、と。
プログラミングだけじゃない技術だけじゃない、ってのは、おいちゃんも常々思ってるし、書いてるし、言ってる。
ただ、それは「技術を軽視蔑視していい」ってお話しではないし、本質的に「高いクォリティのプログラム」は、ビジネスメリットになり得るものだし、それをちゃんと、上には提案、下には教育、横には啓蒙していく必要がある。
そこが見て取れず、結果的に「品質とかなんにもわきまえていない」ような文章は、正直、おいちゃん大嫌いだな。
*1:おいちゃんはこの質問に一定の回答を持っているし、うちの弟子のある程度以上の子は、全員知ってると思う
