コーディング技術にこだわり過ぎるとITエンジニアの地位は向上しない
エンジニアの地位向上を図りたい、これは同意ですが、そのための解決策がコーディングスキルですか。。。
エンジニアの地位向上のためには、まず何が問題かをきちんと分析できなければ話になりません。ちょっと考えてみます。
追記)
なぜかブコメ欄を見るといろいろコメントが発散してる。。。
下手な日本語で申し訳ないです。
本旨は「プラスアルファが必要って言ってるのに、paizaはコーディングの話だけなんだ～。プラスアルファどこいった」です。
ちなみにJavaの誤記は直しときました
ブクマ炎上反省会はこちら
「コーディング技術にこだわり過ぎると～」の反省会 - プロマネブログ
IT業界の価値提供の構造
いわゆるSIerをモデルに価値をどのように提供しているのか、考えてみます。
※まあ、自分の仕事から考えるのが一番カンタンですし。
SIerを中心に、ソフトウェア開発のプロジェクトチームを組む場合、概ね以下の様な役割にわかれます。
推進役（プロジェクトマネージャー、プリジェクトリーダなど）
タスク優先度の決定やメンバーの補充、教育など、チームを活動させるための旗振り役を担います。
分析役（SE、アプリケーションエンジニア、業務エンジニア、システムアーキテクトなど）
業務分析やシステム分析を行い、「何を作るべきか」を明確にするための分析役を担います。
実装役（コーダー、テスターなど）
実際に動くアプリケーションをプログラミング、品質評価を行う実装役を担います
※長くなるので詳細は別枠で。
さて、上記のような役割に別れた場合、よく言われるように推進役や分析役に比べて、実装役のプログラマの地位は低いと言われています。
理由はカンタン。「どう作るか」よりも「何を作るか」の方が価値があるからです。
つまり、イノベーションの源泉は顧客に対してどんな価値を提供するか、にあり、価値の提供方法が問題となるわけではないと。
元記事では非常に残念なことにココらへんをごっちゃになっており、技術力があることと、何を提供するべきか分析することの話が明確になっておりません。。。。
プロダクト志向とマーケット志向の切り分けができてないんです。これでは正しい解決策を導けません。
オフショア開発はアメリカの方が先進国
また、元記事で気になったのは日本のオフショアを引き合いに出している点。
日本の工場がどんどん海外に流出しちゃったというのになぞって、プログラマーもいずれ必要なくなるみたいなことを言う人が結構多いんです。
実は、アメリカは日本以上にオフショア開発を活用しております。というか、日本のオフショア開発手法はアメリカからの輸入です。
例えば、
IBMのインド子会社の従業員数はすでに本国アメリカの従業員数を超えています。つまりアメリカなどではオフショア開発は十分に浸透していると言えます。
アメリカでは多くのソフトウェア企業が、オフショアでソフトを開発している。（中略）調査対象企業のうち、オフショアの開発者を採用しているのは84％で、2年前の63％から大きく増加している。
コストメリットだけではなく、オフショア－本国間の時差を利用したスピード開発などでも利用されてます。
例えば米国のエンジニアが昼間に依頼したプログラムを、米国側が夜間に時差のため昼間となるインドなどオフショア側で開発し、翌朝にはチェックインするなど。
これにより開発スピードを高めるなど、米国のオフショア利用は非常に高度な水準と成ってます。
なので、アメリカでは単純なコーダについては既にオフショアに移されております。事実上アメリカ内のプログラマとして生き残っているのは、ビジネス分析や高度な設計などオールラウンダーとして活躍するプログラマ、ビックデータなどのデータアナリスト要素を持つプログラマ、インフラとの統合など高度な技術を持つプログラマが主に生き残ると推測できます。
一種の生存者バイアスがかかるので、現在活動してるアメリカのプログラマは給料も上がってくるんじゃあないかなって思います。
結局、生き残るのはビジネスを作れる人
結局のところ、プログラムを書く人（＝コーダ）ではなく、プログラムを使ってビジネスが出来る人（≠コーダ）が生き残るって面では日米大差ありません。
日本でITエンジニア（正確にはコーダ）が冷遇されてきた、というのは、プロジェクトチームによる分業の中で、ビジネス価値を生み出すための仕様を作れる人が優遇され、ただのコーディングが出来るだけのコーダが冷遇されてきた時代があります。
ITエンジニア内での価値創造の度合いにより待遇の傾斜があったわけです。
となれば、どうすれば改善されるかは明らか。
現状不遇なプログラマは、ただのコーダから脱却しビジネスを作れるマルチなプログラマーに転向するべきです。
要は、アメリカと同じ方向を目指すわけですね。
で、この点については元記事でも
プログラムだけじゃなくて、サーバー回りも、フロントエンドも少し分かるしみたいな、なるべく縦に深いというか、全部の工程が1人でできるようなタイプの人が求めてられています。
と記載があります。そのための解法で「paiza」を紹介してますが
はい。それで、「paiza」を去年10月末に正式に開始しました。SランクからEランクまで、6段階でエンジニアを評価できます。
Sランクだと、アルゴリズムをきちんと理解していないと解けません。想定しているのはイノベーティブな開発ができる人です。例えば検索エンジンを作りましょうとか、ビッグデータの解析をするエンジンを作りましょう、といった話になると、計算速度を考えながらすごく効率的なアルゴリズムを組まなくてはなりません。そういうことに対応できる人を見つけ出すのが、Sという位置付けになっています。
といったコーディング志向になってしまっています。ビジネスのビの字も出てきてません。なんでそこでプログラムにいっちゃうの。せめて、ビジネス分析だとか、違った面のスキルを競えばいいのに。。。
これでは、ただのコーダから脱却できません。。。
元記事でも記載されているように
技術だけじゃなくて、プラスアルファの周辺領域の何かをきちんと深く学んでいるということもすごく大事なことです。
このプラスアルファこそが、日本の冷遇されているとされるエンジニアに不足していると感じてます。
であれば、そちらを改善する事こそがエンジニアの地位向上を図る早道ってもんだと思います。
まとめ
オッサンは、今回の元記事にあるような徹底したコーディング技術主義こそが、日本のITエンジニアを冷遇してきた最大の要素だと思ってます。
技術があることが価値ではないんです。お客を喜ばせることが価値なんです。
で、お客からしたら技術の中身なんかぶっちゃけどうでもいいんです。Javaで書こうが、Cで書こうが、COBOLで書こうが、そこに価値の本質はないから。
もちろん、手段は多ければ多いほどいい。そういった意味でのコーディング技術は有用です。
ただし、あくまでも手段は手段。価値を生み出すという目的には別の考えが必要です。
そういった意味では、今回の記事は非常に残念です。
ITエンジニアの地位向上をしたい、という目的は正しいと思います。ただ、そのための結論は真逆でコーディング技術の強化となってます。
というわけで、オッサンとしてはITエンジニアの地位向上のためにも、何を作れるという「れる論」から何を作るべきという「べき論」への意識転換とそっち方面でのスキル向上こそが、ITエンジニアの地位を向上させることができると思いますよ。
- 作者: ロナルド・G・ロス、グラディス・S・W・ラム,宗雅彦(監訳),渡部洋子
- 出版社/メーカー: 日経BP社
- 発売日: 2012/11/22
- メディア: 単行本
- この商品を含むブログ (1件) を見る
以上
