![[PukiWiki]](image/pukiwiki.png "[PukiWiki]")
#author("2023-04-13T09:58:29+09:00","default:irrp","irrp") #author("2024-01-29T12:46:32+09:00","default:irrp","irrp") →日本のIT業界の問題点 →顧客対応 →見積もり・発注 →IT業界の労働環境 -[[ベンダー社員過労死の遠因はユーザー企業にもあるのか：「訴えてやる！」の前に読む IT訴訟 徹底解説（111）（1/2 ページ） - ＠IT>https://atmarkit.itmedia.co.jp/ait/articles/2311/13/news009.html]] 2023.11 -[[レガシーなインフラを改善するつもりが組織の悪者になる話 - Qiita>https://qiita.com/gokibiruzaka/items/de14cd8e384b0540511d]] 2023.4 -[[会社員70％がExcelでのデータ管理に「限界」、脱Excelしない理由は？ | TECH+（テックプラス）>https://news.mynavi.jp/techplus/article/20230411-2650476/]] 2023.4 --予算管理や案件管理、タスク管理、顧客管理 --「複数人による同時編集ができない」「管理の属人化」「最新版が分からない」「大容量データ処理ができない」 --回答者のおよそ70％がExcelでのデータ管理に限界、デメリットを感じており --「脱Excelできない理由」として最も多かったのは「Excelの利便性を手放したくない」だった。業務自体は煩雑なものの、Excelの利便性に代わるものもない、ということが判明した。加えて、「Excelデータが整理できない」「何に置き換えるべきか分からない」「マクロや関数の移行ができない」という声も多く挙げられている。 -[[「日本企業に半導体を売りたいか」“買い負け”真の敗因を関係者がこっそり吐露 | サプライチェーン難問山積 | ダイヤモンド・オンライン>https://diamond.jp/articles/-/316684]] 2023.1 --理由その1 決断がとにかく遅い --理由その2 日本は「客」としての魅力が下がっていることを理解していない --理由その3 とにかく過剰なサービスを求める -[[製造業でシステム化が受け入れられづらい理由 – プログラマーやめました>https://www.premium-tsubu-hero.net/why-kaizen-system/]] 2022.12 --「責められたくないから」 -[[提案依頼書に含まれる無理難題の分類(詳細)>https://www.ipa.go.jp/files/000062702.pdf]] 2017 -[[提案依頼書に含まれる無理難題の分類(プレゼン資料)>https://www.ipa.go.jp/files/000062860.pdf]] 2017 -[[野村HDが日本IBMに「敗訴確定」、システム開発の失敗巡る訴訟の上告を取り下げ | 日経クロステック（xTECH）>https://xtech.nikkei.com/atcl/nxt/news/18/11853/]] 2021.12 --要件の後出しが敗訴に -[[京都市基幹系システム刷新失敗の考察>https://www.orangeitems.com/entry/2019/12/28/084402]] 2019.12 -[[「情報システム部門が崩壊しても問題はない」のか>http://www.atmarkit.co.jp/ait/articles/1310/01/news119.html]] 2013.10.1 --情報システム部門が主体的に、ITによるビジネス変革の可能性を模索し提案していかないと、情報システム部門の危機どころか、企業のビジネスが危機を迎えることもあり得る -[[要件が確定しなかったことにつきベンダに責任がないとされた事例>http://d.hatena.ne.jp/redips+law/20120502/1335971526]] 2012.5.2 --本件は，若干特殊な事例であり，当初1000万円に満たない規模のシステムであったにもかかわらず，要件の確定に3年も要するなど，尋常でない経緯をたどっています。事実認定を見ると，相当多数回の打ち合わせが行われ，ベンダもプロトタイプを開発するなどの工数を投下したにもかかわらず，ユーザが仕様確定を拒絶しているなど，「モンスターユーザ」の典型であったともいえるでしょう。 -[[「スルガ銀-IBM裁判、日本IBMに74億円超の賠償命令」>http://d.hatena.ne.jp/JavaBlack/20120329/p1#20120329fn3]] 2012.3.29 -[[日本の情報システムは頑張りすぎ？ 日本企業の計画外停止は年間平均1.6時間、米国企業は12.6時間というデータ>http://www.publickey1.jp/blog/12/_16126.html]] 2012.1.12 -[[ユーザー企業がSIerに対して抱く、理想と現実>http://jibun.atmarkit.co.jp/lcareer01/rensai/etype/01/01.html]] 2011.11.21 -[[「企業IT動向調査 2011 報告書」>http://www.meti.go.jp/policy/mono_info_service/joho/itdoukou/2010/01.pdf]] 2011.3 --日本情報システム・ユーザー協会（JUAS）／経済産業省より発行 -[[使いまわしの提案が目立つ「できます」と簡単に言うな>http://itpro.nikkeibp.co.jp/article/COLUMN/20080703/310127/]] 2008.7.8 --我々が求めるのは、情報システム部門の代わりとなって、社内を駆け回ってくれる存在。システム開発や運用・保守といった技術的な業務はもちろん、利用部門との調整作業といった役目もお願いしたい。 -[[自分の役割を限定し 要件を丸投げ 現場を疲弊させる>http://itpro.nikkeibp.co.jp/article/COLUMN/20080321/296681/]] 2008.4.10 --ユーザー部門から出てきた要求をベンダーにただ丸投げするだけのシステム担当者に，存在意義はない -[[SEをつぶした値引き 信頼も連帯感も消えた>http://itpro.nikkeibp.co.jp/article/COLUMN/20080307/295714/]] 2008.4.1 --その後，X社のSEたちに会ったとき，この値引きが取り返しのつかない暴挙だったことを知った。SEから表情が消えていた。筆者との信頼関係も崩れ，元のそっけない対応に戻っていた。真摯に顧客のことを考えて見積もり金額を削った努力が，政治的判断で無為にされたことを彼らは悔しがった。 --プロジェクトはスタートしたが，SEたちのやる気が回復することはなかった。彼らもプロだから，ノルマは淡々とこなした。しかし，前向きな提案は一切ない。何かあると「それは契約の範囲外なのでできません」と言うのが常套句となってしまった。「一応動く」ものはできたが，エンドユーザーからの不満は大きかった。 --開発プロジェクトの成果は作る人間の情熱によるところが大きい。700万円を値切ってSEのやる気を潰したことで，その数倍の損をしたのである。 -[[東芝：世界レベルの発注力を身に付ける>http://itpro.nikkeibp.co.jp/article/COLUMN/20080306/295577/]] 2008.3.10 --「仕様書の品質はシステムの品質に直結する。いいシステムを作ってもらうには、発注側がしっかり要件を書かなければならない」。峯村センター長は断言する。「仕様書に書かなければ実装してもらえないのが当たり前だと肝に銘じるべきだ」と続ける -[[中小のユーザー企業は保護されるべきか？>http://itpro.nikkeibp.co.jp/article/Watcher/20080306/295645/]] 2008.3.7 --とにかく全編にわたって、対等な交渉力のないユーザー企業を“保護”するために、どんな契約であるべきかというトーンで貫かれている。それってどうよ、である。「おいおい、企業は消費者ではないよ」とツッコミを入れたくなる。例えば、あれほど個人投資家保護を重視した金商法でも、なんの専門知識も持たずに仕組債なんかを平気で買う中小金融機関を保護しろとは言っていない。なのに、商品がITだと何故こうなるの。 -[[境界線はほどほどに>http://remote.seesaa.net/article/80198773.html]] 2008.1.23 --うーむ。見積もりのために約200万円請求しろと？ --担当の営業と話をする。 --営業「200万円請求しろだって？」 --私「そうです。私もそんなの無理だと説明しましたが営業に任せろと。」 --営業「....。そうなんだよな。前の外資で働いてたときも、本社はすぐそういうこと言い出すんだよ。日本でそんなもん--通るわけないだろ。前の会社でも散々客ともめてものすごい険悪になったよ。これ言ったら終わるよ。」 --営業「だから外資って嫌いなんだよ。」 -[[境界線ははっきりと>http://remote.seesaa.net/article/80035121.html]] 2008.1.22 --「どうして、彼らの曖昧な仕様と彼らのバグとドキュメント不足ために、こんな手戻りを自分が何回もやらなければならないだっ！」 --というわけで、こちらのエンジニアにはまったく理解されない。 --考えてみると、日本の曖昧な境界線のなかで下請けが奉公することで仕事を受注する関係というのは、会社間にとってはいいのかもしれないが、エンジニアには大いに危険が伴うのだ。 --どういう危険かというと発注元の要求が肥大化したときに抑えられない。そしてその要求はどこに行くかというと、営業とかプロジェクトマネージャーではなくて、末端のエンジニアやその下請けのエンジニアなのである。 --そして、不景気や過剰な競争になると、受注することがすべてになっていくので仕事は選べず、発注元の要求もひたすら受けなければならない悪循環に嵌っていく。 --かくして、境界線の無い日本の末端エンジニアはデスマーチに突入していく、という筋書きなのであるなあ。 -[[日本企業はやっぱり違う>http://remote.seesaa.net/article/79044622.html]] 2008.1.18 --・要求仕様があいまい --・業務分担があいまい --・契約があいまい --・パートナーといいながら、下請け --・発注主は殿様。下請け間でよきに計らえ --こちらのエンジニアと話をすると、フラストレーションたまりまくりである。 ---「なぜ契約書を無視するんだ？」 ---「なぜ仕様が勝手にころころ変わるのに、いちいち対応しないといけないんだ？請求しろ」 ---「なぜ彼らのライブラリのデバッグを我々がしないといけないのだ？」 ---「発注主がなんでちゃんとプロジェクトマネジメントしないんだ？」 -[[システム開発のプライムは誰？>http://itpro.nikkeibp.co.jp/article/Watcher/20071115/287246/]] 2007.11.16 --IT業界の問題の根本は、ユーザにある、という話 --それが今、いろんな理由から多くのユーザー企業でシステム部門の劣化が進んだ。その結果、ITのプロとして経営層に物申し、利用部門をしつけることができなくなった。しかも最近では、利用部門などの“お客様”の要望を聞こうという意識が過剰に働き、単なる御用聞きになってしまっているケースも多い。当然、経営層や利用部門から一目置かれないから技術者のモチベーションも下がる。“プライム”がこの状態では、そこから仕事を請け負うITサービス会社も大変だし、ITという仕事のイメージも悪くなる。 -[[ユーザーを敵視すると現場の実情を知るチャンスを見逃す>http://itpro.nikkeibp.co.jp/article/COLUMN/20071108/286788/]] 2008.3.6 -[[ソフトウェア危機」を利用してユーザ教育を>http://business.nikkeibp.co.jp/article/tech/20071012/137404/?P=1]] 2007.10.16 --私は今回のソフトウエア危機に対処するには、思い切って利用者の教育・啓蒙を行うべきだと考える。「利用者」とは、ベンダーではなく利用企業を指す。特に、利用企業の中でもIT部門ではなく、ユーザー部門や経営者を指す。 --そう考えるのは、企業の情報システムを具体的に見るにつけ、需要サイドに対するコントロールが利いていないことが原因でムダが起きているケースがあまりに多いからである。 -[[ITのプロって何ですか？>http://www.future-planning.net/x/modules/news/article.php?storyid=2685]] 2007.9.21 --これは特に経営層に訴えかけたいことですが、社内にITのプロ（専門家）は必要ない、という発想は非常に危険です。もはやビジネスとITに垣根を設ける意味はなくなりました。 --ほとんどの会社には少なからずITに携わる人々がいるわけで、 IT無しで会社を運営することは段々難しくなっています。 --コアコンピタンスにリソースを集中するのも結構ですが、必要最低限のITのプロは社内に繋ぎとめておかないと、後できっと後悔しますよ。 -[[今ならITサービス会社のビジネスを変革できる、その理由>http://itpro.nikkeibp.co.jp/article/Watcher/20070425/269535/]] 2007.4.26 --多くのユーザー企業のIT部門の弱体化が進んでいる。弱体化したIT部門は、もはや自分たちだけの力で、システムを企画したり、開発プロジェクトをマネジメントしたりすることが不可能になりつつある。ITサービス会社に今風のソリューション提案を求めなければ、自らの仕事を完遂することはできなくなってきた。 --にもかかわらず、これまでは昔の“商慣行”が残り、ユーザー企業は力もないのにITサービス会社を依然として人出し業者扱いし、ITサービス会社も御用聞きの心地よさから抜け切れず、提案力を磨くことを怠ってきた。その結果、近年システム障害などのトラブルが頻発し、開発現場が疲弊して新3K（きつい、厳しい、帰れない）が常態化してしまった。 --さすがに今は、それじゃもう回らないことを、一部の勘違い企業を除いてユーザー企業は広く自覚するようになった。だから、ITサービス会社が契約形態を変えると通告しても、「何をエラそうに」とは思わなくなった。むしろ、「それじゃ、是非ソリューションを提案してくれ」と期待をかけるようになった。 -[[改めて考える「日本のソフトウェア産業、衰退の真因」>http://itpro.nikkeibp.co.jp/article/OPINION/20070423/269190/]] 2007.4.24 --ソフトウエア産業体制を変える最大のカギを，ソフトウエアを発注するいわゆるユーザー企業が握っているからです。ユーザー企業がソフトウエア会社に「技術者を人月単価で派遣するのではなく，成果に責任を持って請け負って欲しい」と言えば産業体制は変わります。もっとも，そうするにはユーザーに，開発に耐える要件をまとめる力がなければなりません。これはシステムを作るなら当然のことです。 --知的産業で派遣という契約形態は，技術者，それも優秀な技術者を駄目にします。派遣形態の場合，右向け左向けと命令されて仕事をすればよいので，人を受け身にするばかりか，時には悪い条件で働かされ，精神的にも，体力的にも，耐え難い状態になることがあります。といって技術者が学んで効率を上げると，ソフトウエア会社の儲けは減ってしまいます。 -[[日本のソフトウエア産業、衰退の真因>http://itpro.nikkeibp.co.jp/article/COLUMN/20070306/264055/?ST=management&P=3]] 2007.3.6 --ソフトウエアエンジニアリングの知識に乏しいユーザーは、どのようなソフトウエアを開発したいのか、「要求仕様」が書けない。あるいは書きたがらない。取りあえず派遣プログラマーを雇って、「作っては直し」を繰り返してシステムをアドホックに仕上げていく。バグだらけなのは当然で、効率も悪いのだが、もともと効率を競う感覚に乏しいので問題にならない。かくして、ベンダー、ユーザー両者が望むので、日本にプログラマー派遣業が定着してしまった。日本のソフトウエア産業の労働力ピラミッドは、人海戦術で働く派遣要員で支えられている。 -[[ユーザの弱体化がIT業界をダメにした>http://itpro.nikkeibp.co.jp/article/OPINION/20070418/268785/]] 2007.4.20 --ユーザー企業のIT部門が弱体化したのは，極端な人員削減を進めてきたことと，それに反して情報化テーマの難易度が高くなってきたことにある。ユーザー企業のIT部門の多くは，「システム企画に特化」との名目で過剰なまでに縮小されてきた。 -[[ユーザのIT部門が頼りなくなった原因は？>http://www.atmarkit.co.jp/fwin2k/dnitpro/whatisdt03/whatisdt03_01.html]] 2007.1.10 --現状 ---ユーザーニーズがいつになっても決まらない ---着手後に新しいニーズやニーズ変更が続出して大きな手戻り ---ユーザーのいうことをベンダに取り次いでいるだけ --理由 ---IT部門が自信を失ったから ---IT技術の発展についていけなくなってしまった ---現在では業務が未知のものになってしまった ---ユーザー自身ですら、自分たちのニーズが分からなくなっている ---ITシステムへ何を要求すればよいのかが分からない ---「現在のニーズに忠実なシステムほど、将来の新ニーズへの対応が困難になる」というパラドックスが生じることすらある ---ユーザーにプロジェクトマネジメントの知識がない ---ユーザーに情報システム開発の知識がなく、それが重要な問題であることに気づいていない ---(1)プログラムの機能に対して開発コストは指数的に増加すること ---(2)開発の後工程で出た要求ほどコストが高くなること --対策は？ ---ユーザとベンダとの密接なコミュニケーション、ベンダSEや経営コンサルタントなど社外資源の活用 ---人員の計画的ローテーション ---不確定なニーズを前提としたシステム開発方法論の検討(SOAがそうなの？) ---データウェアハウス的利用、ワークフロー管理システムなどのEUC
