→日本のIT業界の問題点
→顧客対応
→見積もり・発注
→IT業界の労働環境
- 要件が確定しなかったことにつきベンダに責任がないとされた事例 2012.5.2
- 本件は，若干特殊な事例であり，当初1000万円に満たない規模のシステムであったにもかかわらず，要件の確定に3年も要するなど，尋常でない経緯をたどっています。事実認定を見ると，相当多数回の打ち合わせが行われ，ベンダもプロトタイプを開発するなどの工数を投下したにもかかわらず，ユーザが仕様確定を拒絶しているなど，「モンスターユーザ」の典型であったともいえるでしょう。
- 使いまわしの提案が目立つ「できます」と簡単に言うな 2008.7.8
- 我々が求めるのは、情報システム部門の代わりとなって、社内を駆け回ってくれる存在。システム開発や運用・保守といった技術的な業務はもちろん、利用部門との調整作業といった役目もお願いしたい。
- SEをつぶした値引き 信頼も連帯感も消えた 2008.4.1
- その後，X社のSEたちに会ったとき，この値引きが取り返しのつかない暴挙だったことを知った。SEから表情が消えていた。筆者との信頼関係も崩れ，元のそっけない対応に戻っていた。真摯に顧客のことを考えて見積もり金額を削った努力が，政治的判断で無為にされたことを彼らは悔しがった。
- プロジェクトはスタートしたが，SEたちのやる気が回復することはなかった。彼らもプロだから，ノルマは淡々とこなした。しかし，前向きな提案は一切ない。何かあると「それは契約の範囲外なのでできません」と言うのが常套句となってしまった。「一応動く」ものはできたが，エンドユーザーからの不満は大きかった。
- 開発プロジェクトの成果は作る人間の情熱によるところが大きい。700万円を値切ってSEのやる気を潰したことで，その数倍の損をしたのである。
- 東芝：世界レベルの発注力を身に付ける 2008.3.10
- 「仕様書の品質はシステムの品質に直結する。いいシステムを作ってもらうには、発注側がしっかり要件を書かなければならない」。峯村センター長は断言する。「仕様書に書かなければ実装してもらえないのが当たり前だと肝に銘じるべきだ」と続ける
- 中小のユーザー企業は保護されるべきか？ 2008.3.7
- とにかく全編にわたって、対等な交渉力のないユーザー企業を“保護”するために、どんな契約であるべきかというトーンで貫かれている。それってどうよ、である。「おいおい、企業は消費者ではないよ」とツッコミを入れたくなる。例えば、あれほど個人投資家保護を重視した金商法でも、なんの専門知識も持たずに仕組債なんかを平気で買う中小金融機関を保護しろとは言っていない。なのに、商品がITだと何故こうなるの。
- 境界線はほどほどに 2008.1.23
- うーむ。見積もりのために約200万円請求しろと？
- 担当の営業と話をする。
- 営業「200万円請求しろだって？」
- 私「そうです。私もそんなの無理だと説明しましたが営業に任せろと。」
- 営業「....。そうなんだよな。前の外資で働いてたときも、本社はすぐそういうこと言い出すんだよ。日本でそんなもん--通るわけないだろ。前の会社でも散々客ともめてものすごい険悪になったよ。これ言ったら終わるよ。」
- 営業「だから外資って嫌いなんだよ。」
- 境界線ははっきりと 2008.1.22
- 「どうして、彼らの曖昧な仕様と彼らのバグとドキュメント不足ために、こんな手戻りを自分が何回もやらなければならないだっ！」
- というわけで、こちらのエンジニアにはまったく理解されない。
- 考えてみると、日本の曖昧な境界線のなかで下請けが奉公することで仕事を受注する関係というのは、会社間にとってはいいのかもしれないが、エンジニアには大いに危険が伴うのだ。
- どういう危険かというと発注元の要求が肥大化したときに抑えられない。そしてその要求はどこに行くかというと、営業とかプロジェクトマネージャーではなくて、末端のエンジニアやその下請けのエンジニアなのである。
- そして、不景気や過剰な競争になると、受注することがすべてになっていくので仕事は選べず、発注元の要求もひたすら受けなければならない悪循環に嵌っていく。
- かくして、境界線の無い日本の末端エンジニアはデスマーチに突入していく、という筋書きなのであるなあ。
- 日本企業はやっぱり違う 2008.1.18
- ・要求仕様があいまい
- ・業務分担があいまい
- ・契約があいまい
- ・パートナーといいながら、下請け
- ・発注主は殿様。下請け間でよきに計らえ
- こちらのエンジニアと話をすると、フラストレーションたまりまくりである。
- 「なぜ契約書を無視するんだ？」
- 「なぜ仕様が勝手にころころ変わるのに、いちいち対応しないといけないんだ？請求しろ」
- 「なぜ彼らのライブラリのデバッグを我々がしないといけないのだ？」
- 「発注主がなんでちゃんとプロジェクトマネジメントしないんだ？」
- システム開発のプライムは誰？ 2007.11.16
- IT業界の問題の根本は、ユーザにある、という話
- それが今、いろんな理由から多くのユーザー企業でシステム部門の劣化が進んだ。その結果、ITのプロとして経営層に物申し、利用部門をしつけることができなくなった。しかも最近では、利用部門などの“お客様”の要望を聞こうという意識が過剰に働き、単なる御用聞きになってしまっているケースも多い。当然、経営層や利用部門から一目置かれないから技術者のモチベーションも下がる。“プライム”がこの状態では、そこから仕事を請け負うITサービス会社も大変だし、ITという仕事のイメージも悪くなる。
- ソフトウェア危機」を利用してユーザ教育を 2007.10.16
- 私は今回のソフトウエア危機に対処するには、思い切って利用者の教育・啓蒙を行うべきだと考える。「利用者」とは、ベンダーではなく利用企業を指す。特に、利用企業の中でもIT部門ではなく、ユーザー部門や経営者を指す。
- そう考えるのは、企業の情報システムを具体的に見るにつけ、需要サイドに対するコントロールが利いていないことが原因でムダが起きているケースがあまりに多いからである。
- ITのプロって何ですか？ 2007.9.21
- これは特に経営層に訴えかけたいことですが、社内にITのプロ（専門家）は必要ない、という発想は非常に危険です。もはやビジネスとITに垣根を設ける意味はなくなりました。
- ほとんどの会社には少なからずITに携わる人々がいるわけで、 IT無しで会社を運営することは段々難しくなっています。
- コアコンピタンスにリソースを集中するのも結構ですが、必要最低限のITのプロは社内に繋ぎとめておかないと、後できっと後悔しますよ。
- 今ならITサービス会社のビジネスを変革できる、その理由 2007.4.26
- 多くのユーザー企業のIT部門の弱体化が進んでいる。弱体化したIT部門は、もはや自分たちだけの力で、システムを企画したり、開発プロジェクトをマネジメントしたりすることが不可能になりつつある。ITサービス会社に今風のソリューション提案を求めなければ、自らの仕事を完遂することはできなくなってきた。
- にもかかわらず、これまでは昔の“商慣行”が残り、ユーザー企業は力もないのにITサービス会社を依然として人出し業者扱いし、ITサービス会社も御用聞きの心地よさから抜け切れず、提案力を磨くことを怠ってきた。その結果、近年システム障害などのトラブルが頻発し、開発現場が疲弊して新3K（きつい、厳しい、帰れない）が常態化してしまった。
- さすがに今は、それじゃもう回らないことを、一部の勘違い企業を除いてユーザー企業は広く自覚するようになった。だから、ITサービス会社が契約形態を変えると通告しても、「何をエラそうに」とは思わなくなった。むしろ、「それじゃ、是非ソリューションを提案してくれ」と期待をかけるようになった。
- 日本のソフトウエア産業、衰退の真因 2007.3.6
- ソフトウエアエンジニアリングの知識に乏しいユーザーは、どのようなソフトウエアを開発したいのか、「要求仕様」が書けない。あるいは書きたがらない。取りあえず派遣プログラマーを雇って、「作っては直し」を繰り返してシステムをアドホックに仕上げていく。バグだらけなのは当然で、効率も悪いのだが、もともと効率を競う感覚に乏しいので問題にならない。かくして、ベンダー、ユーザー両者が望むので、日本にプログラマー派遣業が定着してしまった。日本のソフトウエア産業の労働力ピラミッドは、人海戦術で働く派遣要員で支えられている。
- ユーザの弱体化がIT業界をダメにした 2007.4.20
- ユーザー企業のIT部門が弱体化したのは，極端な人員削減を進めてきたことと，それに反して情報化テーマの難易度が高くなってきたことにある。ユーザー企業のIT部門の多くは，「システム企画に特化」との名目で過剰なまでに縮小されてきた。
- ユーザのIT部門が頼りなくなった原因は？ 2007.1.10
- 現状
- ユーザーニーズがいつになっても決まらない
- 着手後に新しいニーズやニーズ変更が続出して大きな手戻り
- ユーザーのいうことをベンダに取り次いでいるだけ
- 理由
- IT部門が自信を失ったから
- IT技術の発展についていけなくなってしまった
- 現在では業務が未知のものになってしまった
- ユーザー自身ですら、自分たちのニーズが分からなくなっている
- ITシステムへ何を要求すればよいのかが分からない
- 「現在のニーズに忠実なシステムほど、将来の新ニーズへの対応が困難になる」というパラドックスが生じることすらある
- ユーザーにプロジェクトマネジメントの知識がない
- ユーザーに情報システム開発の知識がなく、それが重要な問題であることに気づいていない
- (1)プログラムの機能に対して開発コストは指数的に増加すること
- (2)開発の後工程で出た要求ほどコストが高くなること
- 対策は？
- ユーザとベンダとの密接なコミュニケーション、ベンダSEや経営コンサルタントなど社外資源の活用
- 人員の計画的ローテーション
- 不確定なニーズを前提としたシステム開発方法論の検討(SOAがそうなの？)
- データウェアハウス的利用、ワークフロー管理システムなどのEUC
![[PukiWiki]](image/pukiwiki.png "[PukiWiki]")
