IT業界に関する統計（その4） - elm200 の日記(旧はてなダイアリー)
391 ソフトウェア業の研究の続き 第1回、第2回、第3回の続き。日本の情報サービス産業≒IT産業の実態に迫るため、経済産業省の「特定サービス産業実態調査」を見ていく。 第４表 ソフトウェア業務の業務種類別の該当事業所数及び年間売上高 細かい数字は、ここから拾える。（平成20年特定サービス産業実態調査(速報) ソフトウェア業 統計表データ(Excel 2003形式)) 業務の種類 年間売上高(百万円) 構成比 受注ソフトウェア開発 9,959,382 87% 業務用パッケージ 1,059,454 9% ゲームソフト 261,620 2% コンピュータ等基本ソフト 192,190 2% 合計 11,472,646 100% 受注ソフトウェア開発というのが、おそらくは一般的に SI 業務と呼ばれている仕事だ。その金額、約10兆円。この部分に関しては、外注費が水増しされているので、実質的な売上と
SIerが進むべきクラウドビジネスの方向性
このところ相次いでさまざまなクラウドサービスが登場しているが、これまで顧客のシステムを構築してきたSIerはクラウドビジネスにどう取り組めばよいのか。 市場拡大への期待が高まるクラウドサービス 日本IBMが先週30日、ITリソースを従量制で貸し出す企業向けサービス「IBMマネージド・クラウド・コンピューティング・サービス（IBM MCCS）」を、10月中旬に開始すると発表した。 新サービスは、同社のデータセンター内に構築したクラウドコンピューティング環境から、サーバやストレージなどのITリソースをネットワーク経由で提供。これにより、顧客はITリソースを自前で持つ必要がなくなる。 同社で用意するITリソースには仮想化技術を活用し、物理的なサーバやストレージを論理的に分割して使用するため、複数の企業や業務に対して効率よくクラウドサービスを提供できるとしている。 新サービスのさらに詳しい内容につ
第4回 システム屋にとって好都合な「IT人材不足」
経営者にとって、情報システムは頭痛の種になりがちだ。業務に必須だが投資に見合った効果が出るとは限らない。ほかの設備投資に比べて専門的で難解でもある。 野村総合研究所で約20年間勤務した後に、人材派遣大手スタッフサービスのCIO（最高情報責任者）を務め急成長を支えた著者が、ベンダーとユーザー両方の視点から、“システム屋”の思考回路と、上手な付き合い方を説く。 前回（第3回）では、企業の情報システムが目に見えないところでその企業の競争力を左右していることを説明しました。 この情報システムは、誰が発想するのでしょうか。誰が作っているのでしょうか。誰が守っているのでしょうか。ここに“システム屋”と私が勝手に呼ぶ人たちがいます。（第1回もご覧ください） 私もシステム屋の1人です。ITベンダー・システムインテグレーターに勤務している人、製造業・流通業など「ユーザー企業」の情報システム部門・システム子会
IT業界
IT業界っていっても非常に大きくて、ネットワークからユーザサポート、そしてシステム開発とあるわけだけど、 その中でシステム開発、とくに業務アプリ開発業界のうごきを1エンジニアの目から見てみる。 現状を端的にいえば、「非常に厳しい」ものとなっている。 日本の業務アプリ開発は長い間、客が提示する案件を大手SIが受注し、それを大手SIの子会社と外部協力会社（派遣会社）から派遣された技術者がくみ上げていた。 ところが08年のサブプライム、リーマンショック以降、客が案件を提示しなくなった。 それがもろにでたのは通年4月から始まるはずの新規案件で、案件数が激減した。業務とか言語とか関係ない。何でもかんでも一気に減った。 その結果、3月末日で終了した案件に投入されていた人材が一気に余剰人員となった。 また保守案件に携わっていた外注要員も、契約更新のタイミングでSIのプロパーと入れ替わりとなっていった。
景気回復後に予想されるSIer格差 - 雑種路線でいこう
景気は循環的だから遠からず企業のIT投資は回復する。しかし同じことが繰り返されることはない。ユーザー企業が開発を主導するかは別として、新技術やIT統制への対応、事故に対する責任の顕在化で、担当者の身元や能力に対する管理責任も高まった。多重下請け構造ではリスクも施工能力も管理できないから、余裕のあるところから統制に責任を持てる体制にシフトしつつあるのではないか。 SIer主導ではなく、ユーザ企業主導の開発体制になって欲しい。そうすることで、ユーザ企業は、やりたいことを素早く安く上手に行うことができるし、SI業界も再生できる。これが私の願いです。 この不況をどう過ごすかで、SIerやSEの命運は大きく変わる。仕事にブランクが生じても最新技術にキャッチアップし続けられるか、景気回復後もリスクを抑えつつ需要増へ柔軟に対処できる施工能力を持てるかが鍵となるだろう。 ネットバブル崩壊後、サーバー価格は
夢見るSIerと虚構 - GeekFactory
たまには実情を書いてみる。愚痴大会なので読み飛ばしてくだしあ。 SIer の経営方針としては、｢どんなカタチにせよ、生産性を高めるのである｣という方向に行くと思います。生産性を高める要因は２つしかなくて、｢開発プロセスの改善｣と｢ソフト生成の自動化｣です。要するにワンタッチでポンでシステムが出来ればすげぇじゃんっていう発想。でも、そもそも要件定義が終わると全部終わるので、どうにかして改善されたプロセスを最大限に働かせるアジャイル的プロセスへの移行は不可避だと思う。 http://d.hatena.ne.jp/gothedistance/20090723/1248331426 「開発プロセスの改善」はどこのSIerでも施策に挙げていると思いますが、成果を上げているところはあるのですかねぇ。要件定義と開発はまったく別の仕事だから、両者で改善方法はまったく異なるはず。まずは後者のウォーターフォー
何故「多重下請け構造」がなくならないかというと、お前らが営業をサボってるからだよ!! - 消毒しましょ!
こいつもshi3zとかいうバカgeekと同じで、定期的にバカな持論を開陳しないと気が済まないらしいので、再度disることにするw ここにあるのは業界外の人間から見れば非常識極まりない戯言ばかりであり、それが何に起因しているのかと言えば、徹底した自己中心性と幼稚な甘えに他ならない。 この不景気をきっかけに、発注側のユーザ企業に変わってもらいたい。丸投げではなく、基本、SIは自分たちで行い、手が足りない部分を技術のプロフェッショナルに手伝ってもらうやり方。 「SIerは、どうやれば生き残ることができるのか」を考えた末の結論が「この不景気をきっかけに、発注側のユーザ企業に変わってもら」うことだというのだから、相変わらず信じられないくらいのバカというか、空恐ろしいまでの甘えと幼稚さである。「多重下請け構造こそ、SI業界の最大の問題点」であるなら、さっさと自分で営業して仕事を取って来りゃいいだけの話
SIerの解体と再生 - ひがやすを技術ブログ
ござ先輩のところで、SIer涙目な状態が解説されてますね。 最近SIerがだいぶヤバくなっている件 - GoTheDistance 書いていることはだいたいあっているんじゃないかと思います。 じゃ、SIerは、どうやれば生き残ることができるのか。 「今の体制のまま生き残る必要はないんじゃないの」というのが私の考えです。多重下請け構造こそ、SI業界の最大の問題点なわけだから、「ゼネコン型SIビジネスが崩壊する」のは、悪い話じゃない。 もちろん、会社がなくなったりすると職がなくなり困る人も出てくるわけですが、問題のある業界を残しておくより、一度解体し、新たにやり直したほうがいいと思います。 だって、実際に物を作れないような人たちが設計するなんて、おかしいし、効率悪いもの。 効率の悪いことをしている人が淘汰されるのは当然の話です。 だったら、なぜこれまでゼネコン型SIビジネスが生き延びてこれたの
最近SIerがだいぶヤバくなっている件 - GoTheDistance
via IT業界から思ったことを。 Twitterでつぶやいたら結構こんな感じで厳しい状態になっているSIerが増えているようなので、僕なりに現状をまとめてみる。 よくわかるSIer涙目の構図 サブプライム、金融危機でSIerのお得意様の金融・メーカー様が大打撃を食らう。 2008年はとりあえず様子見で予算編成は据え置きだったが、今年に入って財布にチャックがかかる。 先行き不透明なので、GW明けぐらいの今期のIT予算が相当カットされた数字になった所が続出。 計画していた新規案件を中止するなどする。運用でなるべくカバーする方向へお客様が動く。 その結果SIerは新規案件がなくなる。案件自体がなくなっていく。予算が無いから当たり前。 大手がプロパーの仕事がなくなってきたのでプロパーで人数減らしてまわし始める。 プライムで食い込んでいるお客様の仕事が減ってきたので、外注に仕事が依頼できる余裕がな
ひどすぎるネーミング - idesaku blog
UKTKKNSHINF こういう名前の変数が出てくるのだが、意味わかる？ 答え：受付禁止情報 今読んでいるPL/SQLコードは本当にひどい出来なのだが、その中でもネーミングが群を抜いてひどすぎてむしろ笑えてくるので、ここでさらしてみたい。 先ほどの例でわかると思うが、悪しきネーミング習慣である子音母音抜きの嵐である。変数名だろうが関数名だろうがこのルールで命名されているので、暗号文を読んでいるような気分になる。 他には、例えばこんなのがある。 SKSI 作成 HNKN 変換 KKT 確定 CHKN 中間 DTM Datetime DTA Data こうして見ると、ktkrやwktkとなんら違いがない。 "作成"のような、比較的簡単に対応する英単語が見つかるものまで日本語子音母音抜きで書くという徹底ぶり。でも"情報"はINFだったりする統一感のなさ。そしてこれらが単独ならまだしも、複合して出
システム開発に欠かせない契約の基礎知識まとめ - GoTheDistance
先日識者の方に色々教わったのでメモっておきます。知ってそうで知らない、元々よくわからない、そういう方に向けてまとめてみました。 僕がSIにいた頃は大抵｢基本契約｣と｢個別覚書｣ってのがありました。納期とかお金とかそういうのは個別覚書に書かれたりしていました。 開発の契約体系 ｢仕様策定〜開発まで｣と｢保守運用｣で別契約にすることが多い。 ｢仕様策定フェーズ｣で1つの契約にして、別に新しく契約を締結しなおせるほうが望ましい。リスクが低減できる。 仕様策定までは準委任、開発は請負、保守運用は準委任という契約が多い。 ちなみに準委任は｢事務作業の代行｣という意味合い。委任は｢法的効力がある作業｣の代行。サムライビジネスは後者が多い。 別に運用が事務作業とイコールじゃないけど、成果を問わないタイプの契約の場合は役務提供という位置づけになる。 かといって契約で｢僕らのコンサル案を僕らが実施し成果が出
若い時にプログラムを書こう、必ず人生の豊かさにつながる
システムインテグレータ最大手NTTデータを率いる山下社長は若い頃、汎用コンピュータ用のデータベース開発に取り組み、プログラムを自ら作っていた。その経験から山下氏は「人生のどこかで手を動かしてプログラムを作る仕事を経験した方が絶対に面白い。20代あるいは30代の前半くらいまでに真水の仕事をどれだけやったか、それがその後の人生の豊かさにつながる」と同社幹部としては異例の発言をする。（聞き手は谷島 宣之＝日経コンピュータ編集長、写真は小久保松直） 2009年度、100億円近い投資を計画していると聞く。狙いは何か。 100億円のうち、40億円くらいかけようと考えているのが、「倍速開発」という案件です。これが一番大きい投資になります。我が社としてぜひともやらないといけないのは、お客様のお気の召すまま、ご希望のオーダーメード・システムを、パッケージ・ソフトを使った場合と同じスピードで作って差し上げる、
第6回 SIerのジレンマ
皆さん，2008年の目標は何ですか？ 私の目標は「健康的に太る」。そう思って食生活を変えようと牛タンを食べましたが，すぐにギブアップ。うーん，パスタなどの穀物で太るか。エビちゃんのように筋肉もつけたいんだけどなぁ。 最近，業態としてのSI（System Integration）は不人気だ。3Kと言われたり，クリエイティブじゃないと言われたり。確かに，SIer様と働くことが多い私としては，正直この業界で魅力的な人と会うことは少ないとは思う。 ただ，これだけは言える。プラクティカルという意味で，SIerの方々は非常に優秀だ。なぜなら，物事を構造化してまとめる能力と，決まったゴールを目指して何かを作るという点では，他の業界の人に比べて抜きん出た力を持つから。 しかし，それでも一緒に働いていると「オヤ？」と思うことは多い。今回は「SIerのジレンマ」と題してSIの実態を紹介したいと思う。 地獄の社
大半のSIerが3次下請け禁止
コンピュータメーカーや大手SIerなどによる、再々委託禁止の動きはごく当たり前のものになってきた。 既に富士通や伊藤忠テクノソリューションズ（CTC）、CSKシステムズ、新日鉄ソリューションズ（NSSOL）などの大手から中堅SIerまでが、3次の下請けを禁じる「再々委託禁止」の規則を導入（表1）。今回の取材で回答を得られなかったが、取引関係のある複数の企業によると、日立製作所も同様の方針である。 NTTデータと野村総合研究所（NRI）、NECは、現在のところ多重下請けを一律には制限していない。ただし、協力会社が外注を活用する場合は必ず報告と許諾を求めるなどして、下請けの管理を強化している。 再々委託禁止より厳しい外注制限を課すケースも出ている。キーウエアソリューションズやシーエーシー（CAC）は2次への業務委託も禁じるようにしたのだ。また、ある中小SIerは「最近、日本IBMの2次下請けと
内作フレームワークが持つリスクを考慮すべきですよ＞某大手 SIer さん - イトウ アスカ blog
大手（ばかりではないでしょうが）SIer さんがたまにやる、どこにも公開していない内作フレームワーク（今回は、Java の Web アプリケーション用のものを念頭におきます）でプロジェクトをすすめるのはこういうリスクがあるんですけど、考慮してますか？ っていう話です。 わざわざ書くってことは、考慮してない現場をまのあたりにしてるからなわけですが。 名の知れているフレームワークと言うとまずは Struts ですね。名が知れていないものでも、容易に情報が得られるフレームワークはたくさんあります。また、プロの編集者がちゃんと編集・校正して、しっかりと製本されたそれらの参考書も手にはいります。 いっぽう、内作のフレームワークについて、それを使わされる下請けさんなどの立場で見るとどうでしょうか。 プロジェクトが始まるまで、下手すれば名前すら聞いたことがない。 プロジェクトが始まっても、なぜか実行環境
プログラミングを自動化できないたった一つの理由 - GeekFactory
自動車産業を始めとする製造業では高度な自動化が行われているが、ソフトウェア開発は未だ自動化が行われていない。数年前から、SIerの興味は建設業から製造業に移っている。 ソフトウェア開発という「家内制手工業」をせめて「工場制手工業」へ発展させ、ゆくゆくは「機械制大工業」に進化させようという試みの多くも、同様の誤解がベースになっているわけで、「ソフトウェア開発」を「モノ作り」と見なす誤解は、広く蔓延してしまっているのかもしれない。 http://blog.gcd.org/archives/50603640.html 実に広く蔓延している。ホント失望したよ。 自然言語で記述された要件を仕様に落とし込む作業は、人でなければ不可能である。仕様を記述する行為そのものがプログラミングであり、概念を構造化して言語に書き出すことがプログラミングだ。多くの（偉い）人が勘違いしているが、自然言語をプログラミング
プログラミングを単純労働と捉える3つの理由 - GeekFactory
int128殿の会社では、 >プログラミングは誰でもできる、頭を使わない作業 と思う方が多くいるのかしら？ http://d.hatena.ne.jp/int128/20080414/1208181589 うちに限らず、多くの大企業SIerではプログラミングを単純労働と捉えています。その理由は3つあります。 （1）プログラミングは業務をプログラムに落とし込む単純労働 SIの開発手法（の考え方）は30年前から進化していません。業務をプログラムに落とし込む作業は誰がどうやっても同じようになるという思想に基づいています。現在のように高品質なフレームワークやライブラリが溢れる時代では、いかにそれらを組み合わせて作るかが効率化の鍵になります。組織のトップが進化した設計思想を理解しようとしないのは問題です。 30年前の設計思想であれば、プログラミングは業務をプログラムに落とし込む単純労働です。 （2）
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
dfltweb1.onamae.com – このドメインはお名前.comで取得されています。
今日もどしゃぶり---目次
単なる「低コストの外注先」ではなくなりつつあるインドのIT産業