![[PukiWiki]](image/pukiwiki.png "[PukiWiki]")
#author("2024-01-29T12:49:32+09:00","default:irrp","irrp") #author("2024-04-12T18:12:43+09:00","default:irrp","irrp") →IT業界の動向など →[[日本のIT業界の問題点]] →オフショアリング #contents *SI業界の動向 [#bbfc3cd3] -[[SIerは生成AI需要を取り込んでビジネス拡大につなげられるか - ZDNET Japan>https://japan.zdnet.com/article/35217605/]] 2024.4 -[[下請けベンダーから「人が消える」、大手SIerの経営者も恐れる深刻な事態とは | 日経クロステック（xTECH）>https://xtech.nikkei.com/atcl/nxt/column/18/00148/101800305/]] 2023.10 -[[富士通､マイナ誤交付で揺らぐ｢IT最大手｣の足元 システム障害が頻発､大規模組織再編が遠因か | IT･電機･半導体･部品 | 東洋経済オンライン>https://toyokeizai.net/articles/-/686242]] 2023.7 -[[System Integrators – the Key to Success for SaaS in Japan | UB Ventures>https://ubv.vc/en/contents/trends/system-integrators/]] 2022.7 -[[「10年後、大半のエンジニアは食えなくなる」マイクロソフト元社長・成毛眞が示す“日本衰退の未来”への備え - エンジニアtype | 転職type>https://type.jp/et/feature/16106/]] 2021.4 --「全員が食っていける」のは、あと10年くらいじゃないですか。それまでにいわゆるゼネコンシステムがなくなって、SIがいらなくなる --現時点ではいまだに日本企業の約７割がレガシーシステムを使っているので、クラウドに移行する作業が残っていますが、それが終わればSIに発注する企業はなくなりますよ。 --エンジニアの仕事は、その後もずっとなくなりません。ただ、私が言いたいのは、エンジニアの活躍の場がSIerからユーザー企業へ移るということ。企業がAWSやAzureを使うにしても、それを担う技術者は必要なので、自社でエンジニアを雇うようになる -[[SIと運用が消える もう水平分業には戻れない>http://itpro.nikkeibp.co.jp/article/COLUMN/20121031/433946/?ST=system&P=1]] 2012.11.8 --インテグレータが生き残るには、大きく三つのシナリオが考えられる。 ---（1）クラウド事業の強化、 ---（2）クラウドや垂直統合型システムを前提としたアプリケーション開発、 ---（3）自社のノウハウを基にしたオリジナルの運用パターンの提供、である -[[日本IBM指名解雇の一部始終 30分で退社迫るロックアウト型>http://zasshi.news.yahoo.co.jp/article?a=20121017-00000017-pseven-soci]] 2012.10.17 -[[エンジニア人月０円セールと、ござ先輩に見た未来>http://d.hatena.ne.jp/iad_otomamay/20120529/1338304867]] 2012.5.29 --[[クラウドがもたらしたSIの価格破壊の果て>http://d.hatena.ne.jp/gothedistance/20120530/1338349560]] 2012.5.30 -[[サイオスが生々しく語る「クラウドがもたらすSIの終焉」>http://ascii.jp/elem/000/000/674/674209/]] 2012.2.27 -[[一山いくらで人月見積の大手ベンダーを外し始めたユーザー企業のITガバナンス>http://togetter.com/li/97103]] 2011.2.5 -[[大手SIerの利益悪化がとどまることを知らない件>http://d.hatena.ne.jp/gothedistance/20100521/1274410669]] 2010.5.22 --今までの延長線上で取れる仕事が無くなって来た、ってことが鮮明になってきました。特に親会社に力のあるSIerの数字が悪い。系列関係の仕事しか無い証拠ですね。全体的に｢予算を切られた｣→｢見込んでた仕事無くなった｣→｢稼動しない｣→｢売上立たない｣→｢利益でない｣→｢数字悪化｣という大変分かりやすい絵になっております。昨年7月に勢いで書いたエントリ通りの展開になっているようです。稼働率を上げるためにプロパーで開発(下流工程)をと考えている会社も多いみたいですが、ドラクエでいう転職レベルの転換が求められそうなので、またLv.1からやり直すわけには・・・、という辛さが見え隠れしているようです。 -[[この先10年のエンタープライズITを大胆予測する>http://www.atmarkit.co.jp/im/cits/serial/column/01/01.html]] 2010.3.29 --サーバは売れず、ミドルウェアはクラウドに吸収され、アプリケーションも低価格なSaaSで提供されるということになると、SIが活躍できる可能性があるのは、以下の3種類になるでしょう。 ---自らがCPPになる→超大手以外は難しいでしょう ---特定業種のバリューチェーンに特化したおまけソフトの開発会社になる ---クラウド上の各種リソースやSaaSを組み合わせ、適切な業務プロセスをデザインするクラウドインテグレータ（CI）になる -[[最近SIerがだいぶヤバくなっている件>http://d.hatena.ne.jp/gothedistance/20090723/1248331426]] 2009.7.23 -[[SIerの通期見通しに下方修正相次ぐ>http://itpro.nikkeibp.co.jp/article/COLUMN/20090325/327173/]] 2009.3.30 --ドイツ証券で情報サービス産業を担当する菊池悟シニアアナリストは「他業界に比べれば需要の落ち込みはまだ健全な範囲」と説明する。同氏によれば、 2000年代前半に起きたITバブルの崩壊のときですら需要の落ち込みは3％程度だった。今回はそれより悪いが、減少幅は10％程度にとどまるとみる。「仮に90％の需要が残るのであれば、工場の操業停止に追い込まれている製造業などよりも恵まれている」 -[[今度の不況でSI業界が悲惨な状況に陥りそうな３つの理由>http://d.hatena.ne.jp/masayang/20081111/1226429835]] 2008.11.12 --空洞化:外部依存率を下げつつ、利益率向上を目指すという苦痛が待っている --分業化:残ったのは、「私はOracleしかできません」みたいな専業馬鹿多数 --規則化:くだらない規則が増える。その周知と徹底で作業が増える --なにやってもダメな時に身を粉にして働いて、身体や精神を壊すことほどむなしいことはないよ。 --こういう時だからこそ多忙な好況時にできなかった勉強や修行に力をいれるべき -[[多様化と市場縮小がSI企業を襲う>http://www.atmarkit.co.jp/im/cits/serial/itmgt/04/01.html]] 2008.3.27 --元請けとなっている大手SIベンダも、急速に進展する多様化の波には十分に追従できておらず、特に基幹系をベースとした多様化の流れには、ユーザー企業の情報システム部門も含めて開発トラブルの発生などを解決できていないのが現状 --大手SIベンダが複数社存在しているなかで、ハードウェアベンダも大規模SI案件にビジネスのシフトを進めた結果、経済成長が停滞している日本では供給過剰の状況となってきている --安い費用でシステム構築を実現することしか生き残りの道はないだろう。 --市場が小さくなった時のプレーヤーは身軽である必要がある。統合型SI企業から専門型SI企業へのシフトが、最も有効な対策だと思う。大手SIベンダは間接費用の削減を迫られ、事業遂行メリットを維持していくのが難しくなるのではないか。 --ユーザー企業とこれら専門SI企業の間をコーディネートする役割は必要であり、身軽になった大手SIベンダがブランドを使ってこの役割につくのが自然だろう。 --従来の下請け階層型受注からコーディネート／専門分業型受注への変化の推進こそが、今後の日本のIT業界にとって重要な改革なのではないだろうか。 *銀行系システム [#o79fc864] -[[みずほ銀行のトラブルに学ぶ５つの教訓 - Qiita>https://qiita.com/FumioYoshida/items/bbabe44307de0f71ad42]] 2022.10 -[[みずほ銀行のマルチベンダー化について解説する>http://d.hatena.ne.jp/NOV1975/20121120/p2]] 2012.11.20 -[[みずほの次期システムはマルチベンダー、4社に分割発注 >http://itpro.nikkeibp.co.jp/article/COLUMN/20121116/437901/]] 2012.11.20 --みずほ銀行が次期システムの開発をマルチベンダー体制で進めることが日経コンピュータの取材で判明した。富士通、日立製作所、日本IBM、NTTデータの4社に分割発注する -[[銀行SEの現在>http://d.hatena.ne.jp/NOV1975/20121115/p1]] 2012.11.15 *SI業界の問題点 [#zf88598e] -[[何でスキル不足のエンジニアをアサインしたからって訴えられるんですか：「訴えてやる！」の前に読む IT訴訟 徹底解説（112）（1/3 ページ） - ＠IT>https://atmarkit.itmedia.co.jp/ait/articles/2401/29/news008.html]] 2024.1 -[[「日本も米国もSIerは同じ」は本当か？日米SIerの構造的な差とは - paiza times>https://paiza.hatenablog.com/entry/2014/04/02/%E3%80%8C%E6%97%A5%E6%9C%AC%E3%82%82%E7%B1%B3%E5%9B%BD%E3%82%82SIer%E3%81%AF%E5%90%8C%E3%81%98%E3%80%8D%E3%81%AF%E6%9C%AC%E5%BD%93%E3%81%8B%EF%BC%9F%E6%97%A5%E7%B1%B3SIer%E3%81%AE%E6%A7%8B%E9%80%A0]] 2014 -[[【不要論】日本のIT業界（SIer）が終わってると言われる5つの理由>https://ses-beginner.com/sier-japanit-end/]] 2023.6 -[[SIerでソフトウェアエンジニアのキャリアが積めると思うなよ>https://realengineer.link/you-cant-be-an-engineer-at-a-sier]] 2023.1 -[[SES会社を離れて10年、昔を思い返す>https://www.orangeitems.com/entry/2021/08/01/083000]] 2021.8 -[[%%新卒がSIerとして1年働いた結果見えた、深い深い闇の話%%>https://qiita.com/sirootosan/items/43226b6707ab6dc9d6af]] 2018.4.1 -[[「人月問題」や「多重請負」は「害悪の原因」ではなく結果>http://getlife.hateblo.jp/entry/2014/07/27/032225]] 2014.7.27 --人月商売や多重請負って「受託開発」ってビジネスモデルの結果であって、原因じゃあ無いと思います。 --で、これまた「受託開発」はユーザ要求が原因であるわけで。。。 --ユーザ企業にだって言い分はあり、「パッケージが機能で過不足があり業務に支障がある」とか、「新規業務のための革新的なサービスを作りたい」なんてニーズがあるから、受託開発を選んだりする場合もある（パッケージで十分じゃん、て場合も多いですけど）。 -[[SIerの問題点への補記>http://getlife.hateblo.jp/entry/2014/05/24/042152]] 2014.5.24 -[[多重下請けは本当に必要悪なのか──ポジティブな改善策を考えてみる >http://itpro.nikkeibp.co.jp/article/Watcher/20140130/533589/?ST=ittrend&P=1]] 2014.1.30 --[[多重派遣への問題意識は理解できるけど、ちょっと現状認識と方向性に問題あるのでは。。。>http://getlife.hateblo.jp/entry/2014/02/04/044133]] 2014.2.4 -[[SIerを退職しました>http://hotchemi.hateblo.jp/entry/2013/09/01/103951]] 2013.9.1 -[[「システム・インテグレーション崩壊」のすすめ>http://japan.zdnet.com/blog/netcommerce/2013/07/20/entry_30022577/]] 2013.7.20 -[[n次請けSIerでもできること>http://www.slideshare.net/takigawa401/nsier]] 2013.4.29 -[[特許庁システムだけじゃない 次期年金(社会保険)システム、人事・給与システムでも中止、停止、延期>http://1000nichi.blog73.fc2.com/blog-entry-2547.html]] 2013.1.8 -[[やっぱりSIerは終わってる>http://d.hatena.ne.jp/JavaBlack/20130107/p1]] 2013.1.8 --[[SIer / SEは終わってない>http://samuraism.jp/diary/2013/01/07/1357530960000.html]] への批判 -[[新人SEがSIerに絶望した時に読みたいスライド4選>http://d.hatena.ne.jp/hotchemi/20120825]] 2012.8.25 -[[実録！SIerがネットゲーム事業に参入できない理由>http://hesonogoma.com/SIer/barriers_to_entry_online-game-market.html]] 2012.9.22 --スピード感の圧倒的な欠如と、社内手続きの煩雑さによる膨大なオーバーヘッド、システム開発やビジネスの現場から遠く離れた意思決定機構、このあたりが「SIer」と呼ばれる企業がネットゲーム事業に参入できない大きな理由であると筆者は考えています。 -[[SIで得るものはあるのか？>http://d.hatena.ne.jp/okachimachiorz/20120825/1345896902]] 2012.8.25 --SIの中で、確実にあった倫理的な矜持は、どこかで稼働率優先の数字ビジネスに変わってしまった。結果の惨状がこれです。とはいえ、その数字も立ちゆかなくなった。逆に言うと「なぜ、俺たちはSIをやっていたのか？数字のためではなくて」という点を、もう一度洗い直す機会です。いままでは、その議論は無理でした。「そんなことを考えてどうする？ 儲かってさえいればいいんだよ」という声が優勢でした。もうそうではないですね。「儲かっていない。OK。それはわかった。ではどうする。なんのためにSIをする？」そーゆー当たり前の議論がやっとできる環境になっているわけですよ。 -[[空前の大規模プロジェクト、その宴の後に来るものは >http://itpro.nikkeibp.co.jp/article/Watcher/20120731/412922/]] 2012.7.31 --クラウドビジネスは赤字続きで、アジア市場開拓も遅々として進まない。一方、旧来のSIや受託ソフト開発は今でもそれなりのボリュームがあるし、利益率は低いが全く儲からないというわけではない。「やはり人月商売の方が楽だ」と思う経営者は多い。 --そこに巨大プロジェクトが舞い降りる。人月商売の需給が少しでも引き締まれば、プロジェクトに関わるかどうかは別にして、とりあえず皆が食える。そうすると、ビジネスモデル変革や新規ビジネス育成の機運は薄れてしまう。そんな中でプロジェクトが終了し、大量の技術者がリリースされたら・・・。 --これまでも大規模プロジェクトが終了したときに、一時的に需給バランスが崩れたことがあった。ただ、今回は従来とは違う。2015年にはおそらく、企業などの情報システムのSI案件、受託ソフト開発案件はかなりジリ貧状態になっているだろう。改革を怠ったツケは、確実にITサービス会社や技術者に回ってくる。久しぶりのビッグイベントに浮かれていないで、ITサービス会社も技術者も次の道を探したほうがよいと思う。 -[[この世でアジャイルから一番遠い会社>http://d.hatena.ne.jp/JavaBlack/20120418/p1]] 2012.4.18 --NTTデータ、3年間で社員1000人をアジャイル開発人材に育成 -[[スルガ銀行が事実上の全面勝訴>http://itpro.nikkeibp.co.jp/article/COLUMN/20120409/390218/]] 2012.4.11 -[[SIerがソフトウェアベンダをスポイルした結果いろいろ崩壊しつつある>http://d.hatena.ne.jp/yuripop/20120402/p1]] 2012.4.12 -[[終わるSIerの底辺を見てきた>http://d.hatena.ne.jp/takigawa401/20120330/1333101469]] 2012.3.30 -[[年金システム開発が1年以上停滞>http://itpro.nikkeibp.co.jp/article/COLUMN/20120312/385822/]] 2012.3.15 --ITコスト削減のために分割発注の手法を取り入れ、安値で入札したITベンダーに発注した結果、ITベンダーの経験不足が露呈し、プロジェクトの成功が遠のく――。この構図は、1月に中止を決めた特許庁のシステム刷新と同じだ。 -[[とある老害大手SI企業の例（書いたらムカムカしてきた） >http://anond.hatelabo.jp/20120207012316]] 2012.2.9 -[[SI業界（日本）のJavaプログラマーにはオブジェクト指向より忍耐力が求められている？>http://d.hatena.ne.jp/ryoasai/20110109/1294581985]] 2011.1.9 --これが資格試験の問題なのかと目が点になってしまうような驚くべき設計のコードとなっています。まさに、以前にJava EEや.NETはCOBOLやVB6よりも本当に生産性が高いか？で指摘したように、COBOLの方がよほど生産性が高いのではないかと思われるような設計となっています。 -[[日本とインドのシステムインテグレータの決定的な違いと日本の行く末>http://d.hatena.ne.jp/ktdisk/20091124/1259072572]] 2009.11.24 --日本とインドのシステムインテグレータは非常に似通っているという話をしたが、今回は決定的に違う点を1点指摘したい。英語力だ。インドのシステムインテグレータの規模は10万人程度と紹介したが、10万人全てが例外なく英語を話し、全てのプロジェクトが英語で進行する、これは日本のシステムインテグレータとの大きな違いだ。 --日本のシステムインテグレータが、ソフトやハードのベンダーに「おたくは日本語の資料が充実していない」と不平を言っている間も、インドのシステムインテグレータは充実した英語の資料を読み、粛々と仕事を進めていくのだ。 --今から英語力でインドに追い付くのは容易ではないが、インドにも隙はある。というのも、メールでやりとりしている分には彼らは限りなくネイティヴなのだが、話してみると「これで英語が話せると言えるのか・・・」と思うくらい彼らのインドなまりの英語はわかりにくい。アメリカ人ですらたまにわからず、インド人との会議の最後にこそっと「次回は英語で会議をやりたいな・・・」などと言うシーンもしばしば。インドはもはや英語を話す人が世界で最も多い国となってしまったので、彼らが発音を直すことは日本人が英語を習得するより多分難しい。学校の英語でフォニックスなどを導入して、日本人がきちんとした発音ができるようになれば、まだ挽回の余地は十分にある。 -[[よかろう、ではIBMの実情について語ろう>http://d.hatena.ne.jp/NOV1975/20081005/p2]] 2008.10.5 --下請けからしてみれば IBMがケツ拭いてくれないならなんでかなり中抜きされてまでIBM配下でやらなきゃならんのか、って思うよね。実際、責任は取らんわ契約するまで相談にも乗ってくれないわ(まあこれはそれが正しいけど)で何のために高い金払っているかわからんのですよ。 --顧客にしてみればIBMというでかい会社に任せるから、何かトラブっても何とかしてくれるし、その分高いお金(銀行なんかは下請け直接雇う倍は払っているでしょうね)を払っているわけだ。もう不満たらたらですよ。 -[[開発生産性が低い方が収入が多いって変だよね>http://d.hatena.ne.jp/higayasuo/20080723/1216790705]] 2008.7.24 --大手SIerの開発手法が、生産性よりも失敗しないことを重視するのは、この事実が原因なのは間違いありません。失敗せずに多くの工数をかけたほうが売上が増えるのです。 --一定の利益率がないと受注しない会社は、一時的には、稼働率が下がることもありますが、暇なときに社員が休暇をとることもできますし、忙しいときにはできないような研究テーマをやる余裕も出てきます。このような余裕は、会社の活力を上げるためには必要なものです。 -[[SIerが必要としているのは業務知識だという都市伝説>http://d.hatena.ne.jp/higayasuo/20080619/1213849065]] 2008.6.20 --豊富な業務知識を事前に持っていないとSIができないというのは、金融以外では都市伝説 --にもかかわらず、SIerにいくと技術的なスキルより業務知識のほうが重要だと思っている人が圧倒的に多いのは事実です。どうしてかというと、そのように教え込まれたからです。刷り込みですね。 --汎用機の世界では、技術的な部分で差がつくことはほとんどなかった。だから、差別化のために業務知識が重要視されたのです。 --このようなプログラミングを軽視し業務知識を重要視する考えが、SIerでは、先輩から後輩へ脈々と受け継がれています。今では、プログラミングは発達し、人によって大きく生産性は違ってくるのに、その事実を知る機会がないのです。 --新人のころから、「プログラミングは付加価値の低いものだ。付加価値をつけるためには業務知識を身につけなければならない。」そう教え込まれたら、誰でもそうなるでしょう。 --でも、現実はそうではない。(私の知ってる限りは)金融以外の業務知識は、プロジェクトが始まってから勉強しても十分間に合います。工数の見積もりをする人が、業務知識をあらかじめ持っていればそれで十分なのです。 --それよりは、技術的なスキルを身につけ、ユーザの要件をいかにシステムに落としこめるかを知っていることが重要です。要件を技術に落とし込むスキルは、勉強しても身につかない。経験をつむしかありません。でも、技術的なスキルは、勉強して身につけることができます。SIerに入る前に身につけた技術的なスキルが、無駄になることはないのです。 -[[スーパークリエイターが日本のSI業界で即戦力になれない理由>http://d.hatena.ne.jp/aike/20080615]] 2008.6.18 --プログラミングの知識だけでなく業務知識、という主張 -[[SI業界の老害が若手と下請けを蝕む理由>http://d.hatena.ne.jp/higayasuo/20080602/1212379147]] 2008.6.2 --実際にC/S以降何が起こったかというと、RAD、オブジェクト指向、Webアプリケーションなどの技術がプログラミングの世界を大きく変えることになりました。プログラミングは高度になり、プログラマの実力によって、生産性は大きく左右されるようになりました。 --一方、プログラミングが高度になったことにより、プログラミングを知らずに上流工程はできなくなってしまったのです。 --悲劇はここから始まります。経営層は、時代が大きく変わったことを認識できていないので、「上流工程は自分たちが行い」「下流工程は下請けに任せよう」とします。 --ここで、老害による悲劇が起こります。プログラミングを軽視し、若手にプログラミングを教えないのです。 -[[大手ほどSI力の衰えが目立つ>http://itpro.nikkeibp.co.jp/article/COLUMN/20080414/298988/]] 2008.4.17 --一昔前は、発注先になるITベンダーのSEと打ち合わせれば、要件のあいまいさを補うことができたので、大きな支障はなかった。ITベンダーの読解力に期待できたからこそ、開発を外注化し、スタッフはシステムの企画や要件の取りまとめに専念できた。 --ところが最近は違う。特に開発の「オフショア化」で風向きが変わったように思う。オフショア先と我々をつなぐ「ブリッジSE」が、往々にして要求を「読解」できないのか、通訳の役割を果たしてくれないのだ。 -[[プログラミングできない元請けがプログラム設計書をレビューするという矛盾>http://d.hatena.ne.jp/higayasuo/20080415/1208224902]] 2008.4.15 --プログラミングが苦手な人にプログラム設計書を書かせても意味がない ---論理的に考えることができないから --プログラミングができない人にプログラム設計書をレビューさせても意味がない ---日本語を眺めているだけで、書いている内容を理解できないから --プログラミングができる人にプログラム設計書を書かせても意味がない ---できる人の作業効率を下げるだけ --こんな非効率・非常識なことを改善するだけで、日本のSI業界はもっとよくなる -[[SIerのジレンマ>http://itpro.nikkeibp.co.jp/article/COLUMN/20080226/294742/]] 2008.2.29 --優秀な人には雑務と質問という不毛な負荷が集中する。まるでパチンコの右下にどこにも引っかからなかったパチンコ玉が落ちるように，誰も拾わなかった困難が集中する。 -[[日本IT業界絶望論>http://japan.cnet.com/blog/kenn/2007/11/09/entry_25001425/]] 2007.11.9 --IT業界というより、SIerがダメっていう話 -[[労働集約型のSIはもうやめよう>http://itpro.nikkeibp.co.jp/article/NEWS/20070907/281491/]] 2007.9.10 ** 特許庁システムの失敗 [#g2d65e18] -[[経産省による特許庁情報システムに関する調査報告書>http://www.meti.go.jp/press/20100820003/20100820003-2.pdf]] -[[「特許庁業務・システム最適化計画」(改訂版)について@特許庁>http://www.jpo.go.jp/torikumi/system/system_optimize_re.htm]] -[[特許庁のシステム開発が破綻した本当の理由>http://satoshi.blogs.com/life/2013/01/toshiba.html]] 2013.1.6 --破綻の原因は、ソフトウェア・アーキテクチャやプロジェクト・マネージメントにあったのではなく、「競争原理が正しく働かない社会構造」そのものにあるのだ。 -[[【ITブラック】特許庁システムにまつわる黒い話が色々ヤバイ>http://matome.naver.jp/odai/2135019355282582601]] 2012.10.14 -[[特許庁の基幹システムはなぜ失敗したのか。元内閣官房GPMO補佐官、萩本順三氏の述懐>http://www.publickey1.jp/blog/12/gpmo.html]] 2012.1.31 -[[特許庁の55億かけて頓挫したプロジェクトの報告書が面白い>http://anond.hatelabo.jp/20120127061544]] 2012.1.27 -[[特許庁の情報システムについて>http://myatsumoto.hatenablog.com/entry/2012/01/26/082554]] 2012.1.26 -[[特許庁情報システムに関する技術検証委員会 | 経済産業省 特許庁>https://www.jpo.go.jp/resources/shingikai/kenkyukai/system/index.html]] 2012 *SI業の経営戦略 [#h6dda074] -[[大手SIerの考えそうなこと - orangeitems’s diary>https://www.orangeitems.com/entry/2022/04/08/090002]] 2022.4 --AWSはじめパブリッククラウドが、ソフトウェア自体を内製しクラウドに組み込んできた。インフラ基盤を使うなら一緒に使えるソフトウェアも使ってしまおう、と。そうやってパブリッククラウドは進化したが、大手SIerも負けず、そのクラウドでも我々のソフトウェア、使えますよ、と、競合しようとはせず、パブリッククラウドに馴染もうとしているのが現在だ。当初は、パブリッククラウド自体を構えてAWSなどと戦おうとしたけど、それはもう勝敗が決まってしまっている。 -[[SIerにてエンジニアの残業を無くす方法>http://d.hatena.ne.jp/ledsun/20120709/1341848774]] 2012.7.11 -[[SI屋さんとSIと、直近の課題について。>http://d.hatena.ne.jp/okachimachiorz/20120311/1331467375]] 2012.3.12 --ここ４−５年のSIの失敗率は、個人的に見ている限りは異常と言わざるを得ません。人員の確保ができないため、もう猿だか、猫だかわからないような人員ですらSIの現場に突っ込まれていることが日常茶飯事になっています。というか、そうでない現場の方が少ないように思えます。 --深刻なのは、人口構成の大きな変更によるインパクトは、労働集約産業ほど強烈になるのですが、特に現場から距離のある経営陣や部長以上の経営的中間管理職には、どうしても、その意識が薄くなってしまうということです。こと最近でいうと、クラウドやなんやらで、SIはどうかわるかという議論は、情報誌・雑誌・果てはイベントや、その手の座談会で良く聞きますが、下支えのSIの産業構造の崩壊に対する自覚はまったくないのは、よく観察されるところです。 --関連:http://d.hatena.ne.jp/JavaBlack/20120312/p1 -[[[特集:SEが消える 1/3] 富士通・組織人事改革担当者「SEにはWebエンジニアのような創造性が必要」と話す真意>http://engineer.typemag.jp/elife/2012/02/se.php]] 2012.2.14 -[[富士通の3万人SE職務転換大作戦は成功するのか？>http://d.hatena.ne.jp/gothedistance/20120122/1327208557]] 2012.1.23 -[[SI業界からはさっさと抜けだしたほうがいい>http://d.hatena.ne.jp/higayasuo/20110111/1294718077]] 2011.1.11 --今は、世の中の動きがかなり速くなっているので、その中で素早くチャンスを捕まえたものだけが生き残ります。受動的に待ってるだけじゃ、じり貧なだけ。SIは、受動的なビジネスなので、今後は、生き残っていけなくなるはずです。 --未来のある業界なら、悪いところは改善していくべきだと思いますが、未来のない業界なら、だめでも放置しておけばいいと思うんだよね。情熱は、未来のある分野に向けたほうがいい。 --SI業界からはさっさと抜けだしたほうがいい。 --サービスを作る側に回ったほうがいい。 -[[ひがやすを「SIerは顧客の良きパートナーとなれ」>http://jibun.atmarkit.co.jp/ljibun01/cs/200912/05/01.html]] 2009.12.22
