SIビジネスはなくなります - ベテランIT営業が教える「正しいITの使い方、営業の使い方」昨日、ある大手SIerさんで研修がありました。そこで、「どうすれば、自社のクラウド・ビジネスを拡大できるか」をテーマに議論をしました。 「うちはSIerなんだから、クラウド・ビジネスを拡大するではなく、SIビジネスを拡大することが目的。クラウドは、それなりの機能があって安けりゃいいんじゃないですか。それを目指すべきであって、クラウド・ビジネスをどうするかという議論は、そもそも本末が転倒していると思います。」
『SIエンジニアの自分戦略 -急がば回れ、選ぶなら近道-』に参加してきた #devlove - Diary of absj31
SIエンジニアの自分戦略 -急がば回れ、選ぶなら近道- - DevLOVE 2012/10/09 SIエンジニアの自分戦略 -急がば回れ、選ぶなら近道 - DevLOVE #devlove - Togetter 講師及びその講師の方が話されるテーマも相俟って、募集後即定員が埋まる盛況振り。自分もタイミングを逸しキャンセル待ちで登録していたのですが、晴れてキャンセル待ち繰り上がりで参加資格を得る事が出来たのでこの日参加して来ました。 会場はマイクロソフト品川本社セミナールーム。今回はいつにもまして参加者も著名な方が多数参加。注目度の高さがここでも伺えます。 papandaさんの今回のイベント開催に至る経緯として以下の様なコメントが最初にあり、間髪入れずに本編へGOです。 ブログを読んでいて、書かれている事が仕事に対して危機感を持つ内容だった。 こういった内容を書かれる方のお話を聞いてみたい。
雑種路線でいこう - どっこいSIerは簡単になくならない
SIerが変わらなきゃってことには同意。けど日本でSIerは当分なくならない。少なくとも解雇規制がなくならないとね。米国で何故ユーザー企業が専門家を雇えるかというと、要らなくなったらクビにできるからだ。例えば汎用機とCobolのシステムをLinuxとJavaに移行する場合は、汎用機オペレータとCobolプログラマを切って、LinuxオペレータｔJavaプログラマを雇い入れる。そういう世界だ。 日本じゃ簡単にクビを切れないから、潰しのきかない技術者はできるだけ雇いたくない。そこのところはSIerに押しつける訳だ。重層的な下請け構造が何故あるかというと、SIerも簡単にはクビを切れないんでバッファを必要とするからで、6次とか7次になれば会社そのものが吹けば飛ぶ世界で、労働基準法なんか形骸化しているしね。 今後はユーザー企業がどんどん内製で出来るようなシステム作りを支援する方向に向かわねばならな
アメリカにはSIerなんて存在しない - GoTheDistance
知人のmark-wadaさんのBlogからTB。 親子丼的ビジネス奮闘記(4) IT業界構造 SIerなんてものは無い 米国と日本との大きな違いは、米国の企業は基本的に内製なのだ。すなわち、社内のＩＴ部門に開発エンジニアを抱え、そこでシステムの開発から運用を行なう。 ですから、米国のベンダーはそこに製品を供給する役割であり、日本でいうSIerというのはほとんどなく、あっても企業でリソースが不足したらそれを補う役割でしかない。契約にしてもはっきりしますよね。提供されるプロダクトやサービスに対する対価を払えばよいわけで、かかった人月で支払ういう出来高払いのような形態は少ない。日本のようにベンダーやSIerに丸投げして、できてからこんなはずではなかったなんて事態にははじめからならない構造なのだ。 親子丼的ビジネス奮闘記(4) IT業界構造 言われてみれば・・・、っていう感じですが改めて目が鱗です
クラウドがもたらしたSIの価格破壊の果て - GoTheDistance
クロノスの山本さんと飲みにいきました。遅刻してすいませんでした＞＜ 僕らの興味はやはりSIビジネスがどうなってしまうのだろうかという点で、色んな観点から話が盛り上がった。 クラウドの台頭によって、ビジネスでITを利用したくても出来なかった層にIT技術の裾野が広がっていく。SIは自前でシステム環境を構築することで差別化を図り儲けていた側面も強かったけれど、クラウドがハードのアウトソースを加速させた事でシステム開発案件の単価は下がっているし、価格下落話には枚挙に暇がない。目の上のたんこぶではあるが、業界のパイは小さくなったとしても優秀な人間にお金が回るようになれば長期的には良いこと的な帰結を考えていた。 でも、その歪みがひどい事態を生んでしまったようで・・・ 一方、SIおよびSEのこれからに暗い影を落とす話もある。関西のあるSE派遣の企業のはなし。 何十人もの新人さんを集めて、無料でプロジェク
特許庁の基幹システムはなぜ失敗したのか。元内閣官房GPMO補佐官、萩本順三氏の述懐
特許庁が進めてきた基幹系システムの刷新プロジェクトが失敗に終わり、開発に投じた約55億円が無駄になってしまったことが、先週相次いで報じられました。 ［スクープ］特許庁、難航していた基幹系刷新を中止へ - ニュース：ITpro 朝日新聞デジタル：費やした５５億円、水の泡に 特許庁がシステム開発中断 - ビジネス・経済 このプロジェクトに「内閣官房GPMO（ガバメントプログラムマネジメントオフィス）補佐官」の肩書きで2009年まで民間から参加した萩本順三氏（現 匠BusinessPlace 代表取締役社長）がFacebook上で当時を述懐しつつ、失敗の要因を分析していました。今後、失敗プロジェクトを繰り返さないためにも、重要な発言として本人の許可をいただいてまとめました。 特許庁の情報部門に幾度も中止を迫った 萩本順三氏の発言の主要な部分を引用します。 内閣官房GPMO（ガバメントプログラムマ
人月商売が悪だと思っている、イノセントなあなたへ - GoTheDistance
色んな意味で示唆的なエントリ。山本さん、どうしちゃったんですか。飲みにでも行きますか。 人月は悪どころか、ものすごい善かもしれない - 山本大＠クロノスの日記 140文字ぐらいでまとめちゃうと、人月ではなくソフトウエアの持つ価値だけでお金を取ろうとすると、例えばスマホアプリの場合は非常に単価が安いのでペイする算段が立たないこともある。それを鑑みると、エンジニアの稼働ベースで請求できる人月ってなんだかんだでイイとこあるよ、って話です。 人月について語られる記事はエンジニアよりの観点で議論されることが多いんですが、そうなると「人月はエンジニアにとって善か悪か」という方向に話が飛んでしまい、ゼネコンは死ねば良いし多重請負は終わってるし日本のIT競争力はなんだかんだっていう感じで一定の結論が出しにくい。なので、もっとビジネスよりの観点で整理してみたい。 人月のメリットは成果物ではなく作業内容に対し
大規模SIは少数精鋭で乗り切れるのか？ - 急がば回れ、選ぶなら近道
まず現状の認識は以下の通り 1.20-30代の就業人口の減少これは大前提になる。 また情報共有も進むためよりブラックな会社が 人を集めること自体のハードルがあがる。 結果として、人員を集めるということがより厳しくなる。 これはITに限らず、労働集約的産業全体の課題でもある 2.能力格差の拡大今の40-50代よりも間違いなく、現状の20-30代は 勉強している人としていない人の格差は広がっている。 ゆとり云々とは別に、社会的なプレッシャーから、 むしろ勉強しないと勝ち残れないという強い意識のある集団と、 ゆるふわほんわか草食集団の差が非常に非常に広がっている 3.資源の拡大要するに、割とハード・リソースに余裕が出てきている まず、クライアントサイド。 要はなんでもできる状態になりつつある。 jsあたりはほぼ無法地帯の感もある。 一時、jsでOSみたいのまでいけるぜ、というデモもあったが 技術
キャプション直すだけで数万円？システム開発の値段が高くなる３つの理由とは | Social Change!
今のシステム開発の業界における価格は、実はその提供している価値に対して、コストが高すぎるのではないか、と以前から考えていました。IT投資に対するパフォーマンスの比率が著しく悪い、摩擦係数が異常に高い気がします。それが何故なのかを考えてみました。（今回は問題提起だけなので悲観的なようですが、別途私の提案編を書く予定です） 色々なお客様とお話しさせて頂くと、かなりの予算投資をしてシステムを構築した後に、実際に使い始めると修正したい箇所が出てくるもので、その改修をベンダに依頼すると想像以上の金額の見積りが返ってきて驚いた、という話をよく聞きます。 実際に、画面の一部のキャプションを少し直すだけでも、数万円とかの見積が出てきた、というのも大袈裟な話ではないのでしょう。そんな経験をしてしまうと、より一層に構築時に確実に作って、改修しなくて済むように、と考えてしまっても仕方ありません。 また、システム
エンタープライズ開発者が負け組として軽蔑される日本のSI業界って - 達人プログラマーを目指して
本ブログの記事に対して多くの皆さんからいただいた意見を総合すると、技術力のあるトッププログラマーにとって現状の日本のSI業界での仕事というのは、働き甲斐のない、魅力の少ない仕事として認識されているという残念な事実を思い知らされます。 オブジェクト指向の基本すらいまだにきちんと使いこなせない開発の現場 技術について勉強した知識をほとんど活用できないし評価もされない 無駄なドキュメント作成などに対する膨大な単純作業を強いられる いわゆる3K職場と言われるような過酷な労働と低い賃金 20年以上も前の仕事の進め方からあまり進歩が見られない 多重下請け構造によりユーザーに直接価値を提案するような仕事が難しい 多くの業務アプリケーション開発現場における体験を通して、以上のようなことが語られているということを考えれば、「業務アプリケーションのプログラマーは負け組だ」という意見が出てくることも当然のことか
日本のIT技術者はもういらない？
NTTデータは現状比1割増の1万人超、日立製作所が同2倍超の6000人、富士通も同2倍超の5000人――。これは数年後、国内ITベンダーが抱えるようになるインド拠点におけるIT技術者の数だ。米ガートナーの予測では2014年まで、日本のITサービス市場の成長率は円建てで年平均0.8％。世界で最低の伸びと予測されている。一方で新興国の同市場は年平均10～11％の高成長が続く。旺盛なIT投資が見込まれる海外市場の攻略や海外拠点へのITサービスの拡充には、技術力が高く賃金が安いインドのIT技術者の確保が重要になっている。 既に米IBMや米ヒューレット・パッカード、米アクセンチュアといった米ITベンダーがインド拠点に抱える技術者はそれぞれ6万～8万人。日本のユーザー企業がグローバル展開を加速させるなか、国内ベンダーも遅ればせながらインド拠点の人員数を急激に増やし、海外の顧客へのITサービスを拡充しよ
クラウド時代にSIerはどう生き残るのか？ 人月ビジネスからどう脱却するのか？ 大手SIer役員にインタビューしました
クラウド時代にSIerはどう生き残るのか？ 人月ビジネスからどう脱却するのか？ 大手SIer役員にインタビューしました リーマンショック以降の決算が軒並み大幅減収だった大手SIer。この状況は、景気が回復すれば持ち直すなどと楽観視できません。その背景には、クラウドや仮想化技術などによるシステム単価の下落や、ユーザー企業による内製化の進展による案件の減少といった構造の変化があるからです。 こうした構造変化の中で、SIerは今後の成長戦略をどう描こうとしているのでしょうか？ また、その中でどんなエンジニアが今後必要とされるのでしょうか？ ブログ「GoTheDistance」のブロガーで、「ござ先輩」として知られる湯本堅隆氏から、こんな主題でインタビューしてみたい、という企画がPublickeyに持ち込まれました。湯本氏は、自身もかつてSIerに勤務し、現在は中小企業の情報システム担当に転職した
SI業界からはさっさと抜けだしたほうがいい - ひがやすを技術ブログ
SI業界（日本）のJavaプログラマーにはオブジェクト指向より忍耐力が求められている？ - 達人プログラマーを目指して http://d.hatena.ne.jp/ryoasai/20110109/1294581985 をうけて自分の考えを書いておきます。 二年前なら、自分もどうしたらSI業界をよく出来るか真剣に考えていたし、NTTデータの人達と実際に話し合いもしています。 NTTデータとの真昼の対決シリーズ http://d.hatena.ne.jp/higayasuo/20080612/1213241779 http://d.hatena.ne.jp/higayasuo/20080828/1219901392 でも、ソーシャル、クラウド、スマフォの時代になって、考えが変わりました。 今は、世の中の動きがかなり速くなっているので、その中で素早くチャンスを捕まえたものだけが生き残ります。受
大手ITからベンチャー「CROOZ」への転身で分かったこと － ＠IT
2010/12/21 （2013/11/7更新 編集部注：小俣泰明氏はクルーズ株式会社を退職済み） 軽い茶髪にモヘアのカーディガン。腰よりも低く首から長く垂れ下がった柄物のストール。取材相手の男性は、デルのラップトップを片手に「ゆらり」と静かに会議室に現れた。 独特のスタイルに面食らう。 モバイル系ベンチャー企業とはいえ「取締役 技術統括担当執行役員」の肩書きから想像できないスタイル。小俣泰明さんの存在感は強烈だった。 驚くことに、小俣さんは、もともとは大手ICT企業のNTTコミュニケーションズに勤務していたこともあるという。MCSE（Microsoft Certified System Engineer）の肩書きまで持つエンタープライズ系のエンジニアだった。一緒に取材に応えてくれた技術統括部の池田朋大さんも、伊藤忠テクノソリューションズ（CTC）に在籍していたサーバ運用技術者だったという
「契約もアジャイルに」、中堅SIerの新たな挑戦 － ＠IT
2010/12/07 「アジャイル」といえば、ソフトウェアの開発手法として近年注目を集めてきた。半年や1年といったプロジェクト期間で完成品を作る「ウォーターフォール型」ではなく、2週間程度の短いサイクルで、途中経過であっても実際に動くものを見ながら開発を進めるスタイルだ。事前にシステム要件を定義しづらい場合や、市場変化が激しい場合などに柔軟に対応できる。 アジャイルは開発スタイルの実践を指すが、これを受託開発の契約形態に当てはめようという企業が登場して注目を集めている。中堅SIerの永和システムマネジメントは2010年11月11日、初期費用0円、月額利用料15万円からという、まったく新しい契約形態による受託開発のトライアルサービスを発表した。永和システムマネジメントに話を聞いた。 こう語るのは永和システムマネジメントサービスプロバイディング事業部の木下史彦氏だ。アジャイルといえば、開発の方
アジャイルと受託開発
先日、永和システムマネジメント社がアジャイルによる受託開発サービスを発表し、話題になっている。多くの人の関心を引いているのは、アジャイル開発手法を取り入れるということだけでなく、その価格の安さだ。一ヶ月あたりの料金は、もっとも安いものでは月々15万円から、もっとも高額なプランでも月々150万円からとなっている。果たしてそんなので儲かるの！？というのが多くの人がいだいている疑問であろう。自分なりに「アジャイルによる受託開発サービス」について分析してみたので語ってみようと思う。なお、本エントリは永和システムマネジメント社が公開されている資料と筆者の推測に基づくものであるので、より詳細で正確な内容は永和システムマネジメント社さんへ問い合せて頂くよう悪しからず了承いただきたい。 採算割れしないのか？筆者の見解では、たぶんしない。何故か？それは一旦開発が終わったらそうそう頻繁にシステムの仕様を変更し
大手SIerの利益悪化がとどまることを知らない件 - GoTheDistance
田中克己の針路IT - ソフト会社に明日はない？：ITpro ＿＿＿_ ／:::::::::: u＼ ／:::::::::⌒ 三. ⌒＼ ウソだろ！？ 今期、いきなり利益半減？ ／:::::::::: （ ○）三（○）＼ 会社どーすんだろ・・・orz |::::::::::::::::⌒（__人__）⌒ | ＿＿＿＿＿＿＿_ ＼:::::::::: ｀ ⌒´ ,／ .| | | ノ::::::::::u ＼ | | | ／::::::::::::::::: u | | | |::::::::::::: ｌ u | | | ヽ:::::::::::: -一ー_~､⌒)^),-､ | |_＿＿＿＿＿＿__| ヽ::
スーツとギークという区分けがなくなった時代の理由 - 山本大＠クロノスの日記
id:gothedistanceのエントリで話題になってた1つのコメントが、まさに僕のブログに対してつけられたコメントでした。 http://d.hatena.ne.jp/iad_otomamay/20100216/1266333904#c1273690204 上記の「コメント主」に対して言いたいことはなにもないのですが、 id:gothedistanceの話題に少し触発されて、僕がリーマンショック以後の日本のSIerにいて感じることを述べます。 テーマは「スーツとギークという区分けがなくなった時代の理由」です。 （とりあえず、皆がスーツとかギークとかいう論争に飽きたことという理由は除いて語ります。） もはや、今の時代のSI業界では「要件定義だけやるからあとヨロシク」と言って逃げられる人はいなくなりました。 理由のひとつは、簡単な話です。 理由 1. 不景気で逃げる先の仕事がなくなった さ
社員20人から先に進めない小規模ソフトハウス | 独り言v6
転職歴の多いL.starは50人以下の従業員のソフトハウスに、既に数社勤めている。また、知り合いの会社など含め、オープンソース関係を中心に、情報交換しながらいくらかよく知ることができた。 縦割りの一部門はともかく、多くの独立開業エンジニアは、もちろんそれなりの勝算があって起業しているに違いない。まず一つあげるとすれば、少数精鋭は、大企業の硬直した体制に勝る。例えば大きなSIerの下のくだらない案件の問題点というと、馬鹿げたコーディング規則やいつまでも前構造化プログラミングかと言いたくなるような古めかしい設計などがやり玉に挙げられる。しかし質の低いかもしれない100人に安定して同時に作業させるには、やや馬鹿げた程度に抑えるのはおそらく必要なものであり、その人海戦術によって発生する膨大な開発工数は大企業にしかハンドル不可能である。しかしそう言うモデルではハンドルするに小さすぎる案件では、少数精
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
dfltweb1.onamae.com – このドメインはお名前.comで取得されています。