Hatena::ブログ(Diary)

yvsu pron. yas このページをアンテナに追加 RSSフィード

2008-06-02

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

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

経営層がプログラム品質を度が越えたほどに軽視する理由の
一つが説明されてます。目から鱗です。

意外とみんな知らないようなので、「SI業界経営層の考えが古い理由」をきちんと説明したいと思います。

汎用機あるいはオフコンの時代は、COBOLRPGなど(他にもありますが私が経験したものをあげています)の言語が使われていました。

昔の言語は、誰が書いても同じようなコードになると思われていました。もっというと、コピペしてちょっと書き換えるという開発スタイルが多かったのです。もちろん現場によって開発スタイルは違うと思いますが、コピペが横行してたんじゃないかなぁ。

コピペでの開発なら、そりゃ誰が書いても同じようなコードになるよね。

再利用性、保守性より「最初にとりあえず動かすこと」が重要視された。コピペでちょろっと変えて動かすから、とりあえず動くようになるのです。でも、後から仕様変更が入るといろんなコードを直さなければいけないから、コストがかかる。

仕様変更が、すっげー悪だとみなされるのは、この辺の事情もあると思います。だから保守の費用が馬鹿高くなってしまうのです。

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

社会保険庁のレガシー刷新、落札ベンダーが決定:ITpro

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

汎用機の開発現場ですと,プログラミング付加価値はありません.

それこそ誰でも書ける,と信じて疑われません.

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

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

意外な歴史 - シークの日記

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

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

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

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

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

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

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

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

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

意外な歴史 - シークの日記

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

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

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

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

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

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

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

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

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

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

プログラミングファースト開発のように上流から下流まで自分たちでやるような会社がもっと現れて欲しい。そして、うちの会社もそうなりたいと思う。

追記:

紙パンチカードのころから、この業界にいた小林さんに聞いてみたら、コピペ文化は、PL/Iを使った汎用機では、なかったそうです。最初、PAD(フローチャートみたいなもの)を紙で書いて、みんなでレビューしてOKになったら、コーディングシートに記述して、パンチしてくれる人に渡すと、パンチする人がマシンに打ち込んで、コンパイルしていたそうです。

その時代の生産性は、紙に文字を書くスピードで決まっていたらしい。

「これはすごい」

実際はレビュー時間などがあったので、開発者によって生産性の違いはなかったそうです。

後、社会保険庁のやつは、汎用機はレンタル料が高いので、その値段が大きいのではということです。

trshugutrshugu 2008/06/02 20:19 ITドカタゼネコンを支えてるのは捨て駒技術者の死ですよね。
一番問題なのは経営層の人財を見る目がないことだと思う。
いい人財がいるのかもわからないからいなくなったのもわからないし、なぜいなくなるのかもわからない。

通りがかり通りがかり 2008/06/03 14:26 PADは日立の文化ですね。最近時々出てくる「ソフトウェア工場」という言葉も日本で昔、日立がそういう名前のシステムを持ってたはずです。
メインフレーマは、OSやコンパイラを自製しているわけですし、ハードウェア開発では完全なテスト体制を構築しています。COBOLコピペ文化ではないシステム開発能力がある(あった?)はずなのに、どこで断絶しているのか、と、思うわけでありますが。

trattrat 2008/06/03 15:03 経営者の年齢は関係ないっすね。
だって社長が30代、平均年齢が20代の会社をいくつか見てきましたが
プログラマ軽視は同じですもの。
本当に最先端の会社はプログラマの技量が最大限に生かされるんでしょうけど
中小なんかだと言っちゃ悪いが中卒の低レベルな人間がプログラマやってたりして
ものすごく敷居の低い仕事扱いされて感がある。
実際セキュリティ意識皆無のひどいプログラマもいる。
プログラマって能力にすごく幅があるのに、低い方の人の基準で待遇が決められてるような。
趣味が高じて仕事にしちゃった人が(他の職種より)多い職場って
結局舐められちゃってるんですよ。

乳牛乳牛 2008/06/29 04:06 私が感じるのは”設計”と”実装”のレベル感を業界全体が勘違いしたまま進んできている、ということです。

ソフトウェア開発は良く建築や製造業に当てはめて考えられるのですがそこで勘違いが起きているためにプログラマの価値が低く見られていると思うのです。

多くの場合こんなマッピングのイメージで捉えられているかと思います。
 ソフトウェア開発での設計 = 設計行程(図面を書く)
 ソフトウェア開発での実装 = 製造工程(設計図面通りに組み立て)

でも実装作業って本当に”製造”でしょうか???
私は実装作業も製造業、建築でいう”設計”だと思うのです。

製造や建築の設計は詳しくは知らないのですが、正確な図面を書いて、その図面は数学的な方法で検証されていますよね。
ソフトウェア開発で数学的な方法で検証されたと言える状態ってソースのコンパイルが通った状態じゃないですか???
ソフトウェアの設計書と言われるものは製造や建築の設計図ほど精緻なものでしょうか?? 大半はイメージ図程度のラフスケッチなんじゃないでしょうか。

私はプログラミングと言う作業は設計で、製造に該当する部分と言うのはコンパイラがバイトコードを生成したり、makeやantがビルドする部分だと思うのですよ。

そこを勘違いしているから「プログラミングなんて設計書どおりに作業をするだけ」「誰がやっても同じ」というイメージでプログラマが軽視されているのだと思っています。

結局、プログラミング=キーパンチのイメージのままの人たちが上の方で考えちゃうから何じゃないかなぁ…と思う今日この頃をここに書いてしまいました。

yy 2008/08/20 15:31 年間運用コストが500億円超って、いつの時点がわかりませんが、それで空に浮いた年金記憶データが5千万件ですかー。笑いますね。おそらく、そのほとんどがシステムとは関係ないところに流れている気がしますが、なんせ落札業者はマスコミにとっては大スポンサーだし、そもそもマスコミ自体、文系の頭の悪い人立ちばかりなので、そこに偽装とか不正があっても追求は無理でしょう。そういう体質が変わらない限り、小手先の手法を変えてもプログラマーが幸せにはならないと思います。

泥の中に20年泥の中に20年 2009/12/14 19:21 今の経営層の人たちはC/S時代を現場で経験していない、
というより、
今の経営層の人たちはC/S時代に汎用機のやり方で進めようとしたところ、ソコソコできてしまったので、その後のRAD・オブジェクト指向・Webアプリケーションもそのやり方が通用するだろうと勘違いした。そして...そのまんま取り残された。
というほうがしっくりきます。

投稿したコメントは管理者が承認するまで公開されません。

スパム対策のためのダミーです。もし見えても何も入力しないでください
ゲスト


画像認証

トラックバック - http://d.hatena.ne.jp/higayasuo/20080602/1212379147