![[PukiWiki]](image/pukiwiki.png "[PukiWiki]")
#author("2023-04-03T09:44:48+09:00","default:irrp","irrp") →[[日本のIT業界の問題点]] #contents -[[コーディング技術にこだわり過ぎるとITエンジニアの地位は向上しない>http://getlife.hateblo.jp/entry/2014/02/06/030300]] 2014.2.6 -[[ダメなシステムが無くならない理由はエンジニアを正しく活用できないから>http://d.hatena.ne.jp/gothedistance/20130321/1363836092]] 2013.3.21 --ウオーターフォールが逆流できないせいだ/丸投げするからダメ/リスクをとらないからダメ/技術力のないやつが舵を取るからダメ・・・ってさ。つまりはエンジニアを正しく活用できないからダメなシステムが出来るってことを焼き直しているだけだ。簡単に言えば、理由なんてそれだけでしょ？ この議論をもっとしていきましょうよ。なぜシステムがクソなのかじゃなくて、何故エンジニアをマネジメントできなかったのかという方向にさ。 -[[ソフトを他人に作らせる日本、自分で作る米国>http://business.nikkeibp.co.jp/article/tech/20121010/237890/]] 2012.10.10 --日本の航空会社の情報システム担当者から20年近く前に聞いた話で、以前書いたことがあるが再度紹介する。彼が米国の航空会社の情報システム担当者に会い、情報交換した際、今後の方針として「ソフト開発や出来上がった情報システムを動かす運用といった仕事はシステム子会社やIT企業にアウトソーシングしていく。我々はシステムの企画に注力していきたい」と説明した。それを聞いた米国の担当者は目をむいてこう言った。「開発や運用を自分でやらず外部に頼んで何か問題が起きたらどうするつもりだ。企画なんか外に頼めばいい。コンサルティング会社に金を払えば、いくらでも企画を持ってきてくれる」。 -[[[考え事]今の日本の技術系企業には、何が欠けているんだろう>http://d.hatena.ne.jp/chintaro3/20120106/1325851866]] 2012.1.6 --あらゆるものが、その場しのぎで流れていく。社員教育といえば、実務を通して必要な知識を身に付けさせるというものばかりだ。確かにこれだと金儲けしながら勉強できるから、効率が良いように見える。でもそれは本当だったんだろうか。その方法の欠点が、今になって日本中で噴き出しているのではないのか。 -[[ソフトウェア技術者軽視のシステム開発を続けるのはもう限界かもしれない>http://d.hatena.ne.jp/ryoasai/20120125/1327501906]] 2012.1.25 --クラウドの普及により、要件の定義から実現、運用までの期間が大幅に短縮できるようになったり、基盤構築など多くの仕事が自動化されることで、上流から下流まですべてを担当できるような真のソフトウェア技術者の役割がシステム開発で重要になってきているというところにあると思います。したがって、上流担当のSEだからといってプログラミング言語や基盤技術のことをまったく知らないといったことが許されない時代になってきている -[[SEとPG、どっちが頭がいい？>http://el.jibun.atmarkit.co.jp/karyu/2008/10/sepg2-0e2d.html]] 2008.10.20 --JavaによるWebアプリ開発でPG作業が軽視されている傾向は現在でも一向に変わりません。かえって強くなっているくらいです。特に大規模なアプリケーション開発では、いっそうそれが激しい。ということは、社会的に重要なシステムほど粗悪なプログラミングがなされている可能性が強い。事実わたしがうわさに聞く話では、あの大企業のシステムがそんな状態なのかということが多いのです。これは日本のIT産業におけるソフトウェア設計技術が構造的な原因から空洞化していることを意味しています。いくら見かけのドキュメントを整備しても、それは顧客の要求だけが精緻に文書化されたというに過ぎず、それによってソフトウェアの品質をコントロールしているわけではありません。大事なことはソースコードの品質なのです。にもかかわらず今日のIT業界は、ソースコードの品質を向上させるどころか、かえって悪くする方向に向かいつつあります。いったいなぜでしょう。 --前回も触れましたように、「PGは労働集約型の単純作業で、SEこそが高度な技術を担う職分だ」という、1960年代の職制がアウトソーシングによる固定費節減戦略に誤って適用されている傾向が、その原因の1つです。何度もいいますが、本来ソフトウェアの作成という仕事は設計とコーディングという作業に明確に分けることができません。それを無理やりに分けようとするなら、ネット社会を形成してきた数々の技術革新の成果はすべてPGに残り、SEはそれらから完全に疎外されることになりかねません。 -[[下流からみたIT業界 IT業界のシュールな現実>http://el.jibun.atmarkit.co.jp/karyu/2008/09/it1-054e.html]] --[[その２>http://el.jibun.atmarkit.co.jp/karyu/2008/09/it-2-38cf.html]] --ソフトウェア開発の業界では、PGよりSEのほうが単価が高いので、SIerは自分の社員をできるだけ早くSEにしようとします。そのためSIerには SEがたくさんいますが、実装技術が未熟な人も多い。わたしを担当したタカビーなSEのように、すこしばかりSQLをプログラミングしたというだけでSE の業務につかされるケースも出てきます。彼らがしてきた仕事はといえば、ほとんどが仕様書作成。わたしはあまり役にも立たない仕様書作りなどまともな仕事だとは思わないのですが、それだけを専門にしてきたSEはそれが正しい有意義なシステム開発の手法だと思い込んでいます。それを2、3年も続ければ、当然自分はさらに上流工程で仕事ができると思い込んでしまう。それが出世だと思い込んでいるし、そうしないと自分はいつまでもつまらない仕様書書きを続けさせられることになる。件のSEからは、実装作業に対する根拠のない侮りと、強烈な功名心と自分の置かれたポジションについての不満しか感じられませんでした（真の技術者はあまりポジションには執着しないものです。自分の技術が自分の価値を決めるのだと知っていますから）。 -[[IBMの問題はアメリカナイズされた老害>http://d.hatena.ne.jp/higayasuo/20081005/1223179715]] 2008.10.5 --今は昔と違って、プログラミング言語も進んでいていろんなことができます。事前に頭の中だけで考えることには限界があります。実際に作ってみないとわからないことが多いのです。それなのに、プログラムよりも先にプログラム設計書を書くってのは無理があるのです。 --なぜ、こんなことが起きるかというと、IBMの上層部(今だとUS主体)がプログラミングは単純作業だと思っているからです。これは、日本のSIerの上層部にもいえることだけどね。 --老害に関しては、日本のSIerもIBMもそんなに変わらないんだけど、IBMはグローバル企業らしく、徹底的にオフショアを進めているのが悲劇の始まりです。日本のBPさんなら、だめなプログラミング設計書でも、なんとかがんばろうしようとしますが、オフショア先だと、そんながんばりはしないからね。 --日本のSIerもオフショア志向を強めているところが多いと思いますが、プログラミングだけを任せるやり方は、上記で書いたようにうまくいく可能性は低いと思うよ。 -[[プログラマが仕様を決めればいい>http://d.hatena.ne.jp/gothedistance/20080410/1207832176]] 2008.4.11 --プログラマが仕様を決めちゃえばいいんだよ。そのほうがいいに決まってる。マネージャはユーザーの立場に立って要件を抽出しそれを固めていくことに邁進すればいい。プログラマはその要件を元に「それならこれで出来ます」という仕様を決めて、後は全部自分が実装までやればいい。本来、システム開発は要員が少ないほうがいいと思う。多すぎるとコミュニケーションコストが高すぎて死ねる。 -[[なぜプログラミングが楽しくなくなったのか>http://it.nikkei.co.jp/business/news/index.aspx?n=MMIT2z000003042008]] 2008.4.7 --日本のソフトウエア開発では、なぜか各工程に関わる職種のなかでもプログラマーの地位が低くなってしまっている。その労働環境の悪い一面が新３Ｋ（きつい、厳しい、帰れない）などと言われ、業界イメージ全体が悪くなっている。 --最近の大きなシステムでは、システム化できることがどんどん増えて複雑になっていて、コンピューターにやらせること、つまり仕様がなかなか決まらない。でも最終納期が決まっているので、後のほうの工程を受け持つプログラマーにしわ寄せがいってしまう傾向がある。 --そして、当初想定してなかったような機能を後から足してくれと言われたりすると、美しく作ったはずのプログラムの構造がどんどん崩れていく。そして人とのやり取りや調整ばかりに時間が取られ、納期に追い立てられているとやらされ感のようなものばかりが残ってしまうという悪循環が生まれているのだと思う。 -[[日本のパッケージベンダーがダメな理由>http://forza.cocolog-nifty.com/blog/2008/03/post_78bb.html]] 2008.3.13 --SIerが分業化すると、要件定義する会社、設計する会社、プログラミングする会社などのように分かれる。 --だから、多重の下請け構造が発生し、コミュニケーションロスがプロジェクトマネジメントを阻害し、更には、元請が手配師しか脳のない集団になる。 --現代は、自社の内部でハードやライブラリを作りこむよりも、オープンソースをうまく使う方が実は品質もコストも良いと言う時代。 --その体制を作り出すには、自社の技術者が常にオープンソースライブラリを調査して、その技術の先進性を見極めるという高度な能力を必要とする。 --手配師だけの会社では成り立たない。 -[[プログラマー軽視のツケ>http://www.sankei.co.jp/keizai/sangyo/070323/sng070323000.htm]] 2007.3.23 --《技術者の能力低下も指摘されている。開発計画全体を管理するプロジェクトマネジャーを重用し、優秀なプログラマーを確保してこなかったことが問題とされる》 --「ソフトは最終的にはコーディング（プログラミング）で形作られる。コーディングしてテストをする工程がキーポイントだ。ところが分業化が進み、設計専門の技術者はプログラミングやテスト技術に明るくない状況が発生している。建築に例えると、ビル工事の現場を知らない技術者が設計しているわけだ」 --−−ある電子部品会社の幹部が「ハンダゴテを使ったことがない社員がいる」と嘆いていました --「プログラミングができない技術者も一緒だ。設計に当たる技術者に開発工程の問題点まで見通す力があれば、生産性も品質も高めることができる。日本のソフト業界はプログラマーを軽視した。能力のあるプログラマーにはいい報酬を支払い、品質や生産性を上げなければならないのに、そうしなかった。ある実験によると、できるプログラマーとそうでないプログラマーでは生産性に２０倍くらいの差がある。無論、できる人のプログラムは品質も高い」 --−−システム構築にかける時間が短期化しているのも、技術者への圧迫要因と聞いています --「お客さまのビジネスサイクルが速くなり、短期間でのシステム開発が要求される。技術者が時間に追われ、新しい技術を習得する余裕がなくなって、モチベーションと技術力低下を招いてしまっているケースがある」
