ユーザ目線のシステムの是非
Ognacの雑感 木漏れ日々 目次 ホーム 連絡をする RSS Login Blog 利用状況 投稿数 - 1487 記事 - 0 コメント - 45665 トラックバック - 143 書庫 2014年5月 (6) 2014年4月 (13) 2014年3月 (14) 2014年2月 (12) 2014年1月 (12) 2013年12月 (13) 2013年11月 (13) 2013年10月 (11) 2013年9月 (13) 2013年8月 (14) 2013年7月 (13) 2013年6月 (14) 2013年5月 (15) 2013年4月 (13) 2013年3月 (14) 2013年2月 (13) 2013年1月 (15) 2012年12月 (14) 2012年11月 (14) 2012年10月 (15) 2012年9月 (14) 2012年8月 (13) 2012年7月 (13)
雑種路線でいこう - どっこいSIerは簡単になくならない
SIerが変わらなきゃってことには同意。けど日本でSIerは当分なくならない。少なくとも解雇規制がなくならないとね。米国で何故ユーザー企業が専門家を雇えるかというと、要らなくなったらクビにできるからだ。例えば汎用機とCobolのシステムをLinuxとJavaに移行する場合は、汎用機オペレータとCobolプログラマを切って、LinuxオペレータｔJavaプログラマを雇い入れる。そういう世界だ。 日本じゃ簡単にクビを切れないから、潰しのきかない技術者はできるだけ雇いたくない。そこのところはSIerに押しつける訳だ。重層的な下請け構造が何故あるかというと、SIerも簡単にはクビを切れないんでバッファを必要とするからで、6次とか7次になれば会社そのものが吹けば飛ぶ世界で、労働基準法なんか形骸化しているしね。 今後はユーザー企業がどんどん内製で出来るようなシステム作りを支援する方向に向かわねばならな
SIerという奇形児と、SIという珠玉の仕事 - GoTheDistance
先日のエントリーがアツいことになっており、初のホッテントリ入りに若干興奮している今日この頃です。同じような問題意識を持っておられる方が多くいらっしゃることがわかり、改めて書いてよかったなぁと思っています。 話の流れは相当グダグダなのですがあのエントリーで表現したかったことは、「アメリカにSIerが存在しないのである」⇒「アメリカは素晴らしいのである」というのが骨子ではなく、いわゆるディフェンシブなシステム開発を強いられているSIerというのは、いわば奇形児のような存在ではないかということです。 改めて、ディフェンシブとは 言わずと知れた名エントリから。 ディフェンシブな開発とは、開発途上のリスクを計画上の時点でなるべく潰し、開発側に発生する利益分を減らさないような開発の進め方をすることを言っている。加えて、この場合、開発側はリスク分はなるべく多めに見積もり金額にいれようとしがちだ。 なぜそ
アメリカにはSIerなんて存在しない - GoTheDistance
知人のmark-wadaさんのBlogからTB。 親子丼的ビジネス奮闘記(4) IT業界構造 SIerなんてものは無い 米国と日本との大きな違いは、米国の企業は基本的に内製なのだ。すなわち、社内のＩＴ部門に開発エンジニアを抱え、そこでシステムの開発から運用を行なう。 ですから、米国のベンダーはそこに製品を供給する役割であり、日本でいうSIerというのはほとんどなく、あっても企業でリソースが不足したらそれを補う役割でしかない。契約にしてもはっきりしますよね。提供されるプロダクトやサービスに対する対価を払えばよいわけで、かかった人月で支払ういう出来高払いのような形態は少ない。日本のようにベンダーやSIerに丸投げして、できてからこんなはずではなかったなんて事態にははじめからならない構造なのだ。 親子丼的ビジネス奮闘記(4) IT業界構造 言われてみれば・・・、っていう感じですが改めて目が鱗です
ITサービス業の産業構造は近い将来、間違いなく崩壊する
ITサービス会社は今、技術者不足に悩んでいる。業界自体が若者に不人気で、プログラマ、SEを志す人も減りつつあるという。それはそれで大きな問題なのだが、あくまでも現象論。少し考えてみてほしい。このままでは、ITサービス業の産業構造、ビジネスモデルは人材面の問題から間違いなく崩壊する。これは論理的必然である。 多くの人がもう忘れ始めているが、ほんの2～3年前にはITサービス業界では技術者が余っていた。優秀な技術者はその頃でも足らなかったという議論があるが、総体としてはやはり過剰だった。多くのITサービス会社が危ない案件の安値受注に走ったのも、技術者の稼働率を維持するためだった。下請け会社が容赦ない料金引き下げ要求にさらされたのも、その頃だ。 もともとITサービス業界はその黎明期から、慢性的な技術者不足が続いていた。ITサービス市場は景気変動の影響をほとんど受けず、基本的には右上がり。人さえ手当
よいSEにはよい報酬を，“人月いくら”はもうやめよう
少し前のIT Proニュースで，日本IBM・大歳卓麻社長の「ユーザー企業には，技術者の出席をとらないでいただきたい」，という発言が紹介されている（当該記事）。「技術者の頭数ではなく，成果物について対価を払っていただける商慣習に変えていくよう，広く呼びかけたい」，という主旨だ。 私自身も取材のなかで，技術者の数や開発にかかった時間でシステムの価格を決めるのはおかしい，という声を，多くのSEの方々からお聞きする。ベンダーに籍をおくSEからだけではなく，ユーザー企業の方からもである。 システム開発にかかる工数，すなわち“人月”は，価格見積もりの根拠として，現在でも広く使われている。仮に一月100万円のSEが10カ月働いたから1000万円，という見積もりがあったとしよう。では，そのSEが努力して生産性を向上させ，5カ月でシステムを開発できるようになったら，価格は500万円になってしまうのだろうか。
オープンソースと「オープンデザイン」が出会うとき - 設計者の発言
◆オープンソースの台頭 無償で手に入る業務システム向けの開発・実行環境やフレームワークが急速に充実してきた。Apatche,Eclipse,Seasar2,MySQL,Ruby on Rails等々、枚挙にいとまがない。それらの多くが活発なＯＳＳ(open source software)コミュニティを伴っていて、優れたソフトウエアを開発して社会に貢献したいと願う技術者達の情熱の受け皿となっている。その創造的な流れが止むことはないだろう。 そのような変化を、ソフトウエア業界を牛耳ってきた大規模ＳＩｅｒも無視できなくなっている。初めの頃には品質がアテにならないとかドキュメントが貧弱などと言って相手にしていなかったのだが、いつの間にか実務で使えるレベルまで成熟していることに気づきはじめている。クレイトン・クリステンセンが「イノベーションのジレンマ」で示したさまざまな業界での事例と似たことが、ソ
kuranukiの日記 - ディフェンシブな開発 〜 SIビジネスの致命的欠陥
Rubyをはじめとするスクリプト言語ではなく、なぜJavaを選ぶのか。 そして、XPをはじめとするアジャイル開発ではなく、なぜウォーターフォールを選ぶのか。 そこには、言語の良し悪しや、開発プロセスの考え方などが理由の中心にあるわけではなくて、SIerというビジネスの仕事の仕方（ビジネスモデル）に起因している。 RubyやXPは、考え方や技術としてはとても良くて、生産性もあがるし、何よりもソフトウェアをクリエイティブに作り上げることができ、利用者にとっても使い勝手がよく、スポンサー（経営者）にとっても経営戦略に沿ったものが手に入り、開発者にとっては何よりも仕事に対してやりがいを感じることができる。すばらしい！・・・・が。。。 しかし、だからといって、誰でもRubyやXPを使って開発をするべきか、というとそうではない。もし、本質を理解しない誰かが、「やってみたいのだが・・・」と相談に来たら、
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
