SI業界の老害が若手と下請けを蝕む理由

10年間泥のように働いて花が咲きましたのぶくまのコメントにこういうのがありました。

経営層がプログラムの品質を度が越えたほどに軽視する理由の

一つが説明されてます。目から鱗です。

意外とみんな知らないようなので、「SI業界の経営層の考えが古い理由」をきちんと説明したいと思います。
汎用機あるいはオフコンの時代は、COBOLやRPGなど(他にもありますが私が経験したものをあげています)の言語が使われていました。
昔の言語は、誰が書いても同じようなコードになると思われていました。もっというと、コピペしてちょっと書き換えるという開発スタイルが多かったのです。もちろん現場によって開発スタイルは違うと思いますが、コピペが横行してたんじゃないかなぁ。
コピペでの開発なら、そりゃ誰が書いても同じようなコードになるよね。
再利用性、保守性より「最初にとりあえず動かすこと」が重要視された。コピペでちょろっと変えて動かすから、とりあえず動くようになるのです。でも、後から仕様変更が入るといろんなコードを直さなければいけないから、コストがかかる。
仕様変更が、すっげー悪だとみなされるのは、この辺の事情もあると思います。だから保守の費用が馬鹿高くなってしまうのです。

年間運用コストが500億円超に上る巨大システムの刷新を進める社会保険庁は8月21日、新システムの基本設計を請け負うベンダーを競争入札により決定した。アクセンチュア、NTTデータ、日立製作所の3社が請け負う。

年間運用コストが500億円超って、今の常識から言うとありえないって気がするでしょう。でも、この数字が、汎用機の世界の保守性の悪さをあらわしているのです。

汎用機の開発現場ですと，プログラミングに付加価値はありません．
それこそ誰でも書ける，と信じて疑われません．

というか，書く人によって生産性に差が出るほど自由度があったりいろんな事ができるわけではないんです．

やれることが固定長のファイルの中身をいじくってDBに突っ込むだけなんです．

という意見も汎用機やオフコンのプログラミングは差別化が難しく価値が低く見られたということを良くあらわしていると思います。

汎用機の後には、クライアントサーバ(C/S)時代が来るわけですが、今の経営層の人たちは、C/S時代を現場で経験していない。多少技術は変わっても汎用機時代の経験がそのまま生かせると信じ込んでいるのです。

実際にC/S以降何が起こったかというと、RAD、オブジェクト指向、Webアプリケーションなどの技術がプログラミングの世界を大きく変えることになりました。プログラミングは高度になり、プログラマの実力によって、生産性は大きく左右されるようになりました。

一方、プログラミングが高度になったことにより、プログラミングを知らずに上流工程はできなくなってしまったのです。

プログラムでできることが増えるということは、より使いやすい機能を提供できる可能性があるということですが、仕様を決める人が何ができるかを正確に知っていないと使いやすいものにはなりません。また、昔の汎用機時代の常識を持ち込んでもらっても困ります。ベースとなる技術が違うのだから。

悲劇はここから始まります。経営層は、時代が大きく変わったことを認識できていないので、「上流工程は自分たちが行い」「下流工程は下請けに任せよう」とします。

ここで、老害による悲劇が起こります。プログラミングを軽視し、若手にプログラミングを教えないのです。

どうも会社では、僕に上流工程を任せようとしているようです。しかしながら僕は、上流工程にはまったく興味がありません。上流工程のほうが付加価値が高いし儲かるということは一応知っているつもりですが、設計をしたり人の調整をしたり、なんていうことは好きでもないし、得意でもないのです。まだ入社して2年目にもなっていないわけですし、もっと実際のコードに触れていたいと強く思うのです。

それにしても、上司は根本的な勘違いをしているような気がしてなりません。上流工程が儲かるのは、それだけ付加価値が高いからです。付加価値が高いということは、それだけ難しい仕事だということです。僕にそんな仕事ができるだなんて、何を間違ったらそんなことを思えるのでしょう。僕は何一つ実績など挙げていないのに、です。

なんてひどい老害でしょうか。プログラミングは大事だと思っている正しい若者を間違った道へと導いているのです。そしてこの間違いが、次の世代へ伝わってしまったら悲惨です。なんて負のスパイラル。

元請けの若手より、下請けのほうがもっと悲惨です。元請けの書いた「どうやって実装するんだこらばか」とおもうような仕様書を実装しなければいけないのだから。

さらに最悪なのが、元請けが「誰が書いても同じようなコードになるべきだ」といって、生産性の低いやり方を押し付けてくることです。詳しくは「「誰が書いても同じコード」は大事なことなのかを参照してください。

IT業界の人気がないのは、こうした元請けの老害が下請けにもたらした悲劇が広く知られるようになったためでしょう。

昔はこんなことはなかったと思います。仕様書どおりに実装するのは、あまり難しいことではなかったからです。

こうした構造は、そのままにしておくと何も変わりません。元請けは、下請けに一括請負(最終成果物に対して金を支払うやり方。途中いくらコストがかかろうと元請けには関係ない。)で発注しているので、いいかげんな仕様書に下請けが苦労しても、予想以上にコストがかかったとしても自分たちの収支には関係ありません。だから、仕事のやり方を変えないのです。

元請けの老害を追放できればいいのですが、立場的にそんなことはできないでしょう。追放なんてそんな過激なことではなくて、プログラミングの重要さを経営層が理解できるように、何度も繰り返し伝えることも重要でしょう。

うちの会社もかつては、プログラミングをあまり重要視していませんでしたが、今はその逆です。特に若手にはプログラミングをきっちり身に着けて欲しいと思っています。今年から、研修期間も半年とるようにしました。これは、現場でのOJTを除く期間です。上流工程だけやればいいと考えている新人が毎年いるので、そういう人たちにプログラミングの大切さを伝えることも心がけています。

経営層の考えを変えられないなら、せめて、老害のウィルスが若手に感染しないように、中堅の人は、若手をしっかりガードして欲しい。

根本的な解決策は、ユーザ企業がこういう老害のいるSIerとは契約しないようにすることです。老害のいるSIerは、生産性が悪く高コスト体質なはずなので、ユーザ企業にとってもデメリットが多いはず。ただし、現状の日本は、ちゃんとしたSIerが少ないのも事実。

プログラミングファースト開発のように上流から下流まで自分たちでやるような会社がもっと現れて欲しい。そして、うちの会社もそうなりたいと思う。
追記:
紙パンチカードのころから、この業界にいた小林さんに聞いてみたら、コピペ文化は、PL/Iを使った汎用機では、なかったそうです。最初、PAD(フローチャートみたいなもの)を紙で書いて、みんなでレビューしてOKになったら、コーディングシートに記述して、パンチしてくれる人に渡すと、パンチする人がマシンに打ち込んで、コンパイルしていたそうです。
その時代の生産性は、紙に文字を書くスピードで決まっていたらしい。
「これはすごい」
実際はレビューの時間などがあったので、開発者によって生産性の違いはなかったそうです。
後、社会保険庁のやつは、汎用機はレンタル料が高いので、その値段が大きいのではということです。