タグ

IT業界に関するelwoodbluesのブックマーク (385)

  • 派遣制度の見直しでIT業界に激震

    2013年8月20日、厚生労働省の「今後の労働者派遣制度の在り方に関する研究会」が、労働者派遣制度の見直し案を盛り込んだ報告書を公表した。同省は2013年中に「改正労働者派遣法案」の骨子をまとめ、2014年の通常国会での法案提出を目指す。 「複雑だった派遣制度がシンプルで分かりやすくなる」と、厚生労働省の富田望職業安定局 派遣・有期労働対策部需給調整事業課長は説明する。だが、IT業界やユーザー企業のシステム部門への影響は大きそうだ。 着目すべき点は二つある。IT技術者を含む専門26業務の撤廃と、特定労働者派遣における「常時雇用」の定義の見直し、である。これにより、ITベンダーはユーザー企業などに派遣している技術者の雇用契約を見直す必要が出てくる。ユーザー企業は、自社に派遣されている技術者が3年ごとに交代する可能性がある(表)。 IT業界における技術者派遣の形態は、大きく二つに分けられる。人

    派遣制度の見直しでIT業界に激震
  • SIerを退職し、Web系に転職しました - arveltのソフトウェア技術メモ

    銀行系列の中規模SIer退職し、 受託と自社サービスの開発を行っている小規模Web系に転職することになりました。 7/30が最終出社日でした。8/1からは新しい勤め先へ向かいます。 1.これまでやったこと 2.これからやりたいこと 3.なぜ転職しようと思ったのか なお、3はいわいる自分語りを含む上に長いのでご注意ください。 読ませる知り合いもいないのに何故書いた。 1.これまでにやってきたこと。 オープン系の基幹システムの保守開発に携わり4年ほど。 JavaCOBOLExcelVBAをメインにやっていました。 もちろんSQLも普通に書いたりしつつ、触ったことのあるDBOracle、PostgresSQLSQLServer。 業務知識は主に流通系。Web開発とかもやりました。Javaでstruts1.Xとか、ASP.NETとC#とVBとか。 それと個人的欲求に基づき、Android

    SIerを退職し、Web系に転職しました - arveltのソフトウェア技術メモ
  • 地方からITエンジニアが消えていく - Akai's Insight & Memo

    エンジニアは、地方から首都圏へ Facebookである人が、「関西にいる同級生がどんどん転勤や単身赴任で東京方面に行っている」とポスト。それに、呼応する形で、実際に関西から東京へ単身赴任中のIT企業のエンジニアのリプライがあった。 また、先日、ある地方のSI事業者に、取材に行ったとき、現場のマネージャーから、「この数年で、地方のエンジニアのスキルが落ちたという実感がある。競合と提案しても、コンサバだし、一昔前の提案が多い」という話を聞いた。 実際に、僕自身も、90年代は、神戸でソフトウェア開発者であったが、今は、東京で働いている状況だ。 ITバブル崩壊以降、他の産業から遅れて、IT産業の首都圏への集中化が起こっている実感は、多くの業界関係者が持っている。 IT産業を語るとき、ゲーム産業やウェブサービス産業と混在して語られる場合が多いが、IT産業というときは、歴史的には、コンピューターを中心

    地方からITエンジニアが消えていく - Akai's Insight & Memo
  • プログラマの生産性は20倍違うという表現は誤り、プログラムはピアノだと思えば良い。 猫ふんじゃったならだれでも引ける。 | レビログ (Make a little happier) 13周年+2i年

    レビログ (Make a little happier) 13周年+2i年 レビログの半分は管理人の独断と偏見でできています。残りの半分は現在残 希少につき 入荷待ちです。旧称 貧乏だけど心は萌え : プログラマの生産性は20倍違うという表現は誤り、プログラムはピアノだと思えば良い。 ふんじゃったならだれでも引ける。 2013年7月10日 Category > 6_日記 > うだうだ日記 > TAG( ) Comment : 0 (link this page) ITエンジニアの『生産性』と、データ・サイエンスの微妙な関係(佐藤知一) – BLOGOS(ブロゴス) プログラマの生産性は20倍 という表現がマズイのではないか?と思い始めている。20倍なら20人雇えばいいよねとなる。 しかし、実際のプログラマの生産性は ピアノを引くようなものだ。 ふんじゃったならだれでも引ける。 だけれど

  • IT業界エヴァンジェリストのためのオススメ書籍(しょっさん編) | oshiire*BLOG

    5月中旬までが〆切の、けっこう重要なお仕事がたくさん舞い込んでいて、3月から徐々に、そして 4月には格的に仕事優先の生活になっていたしょっさんです、こんばんわ。 3月までは、ほぼ毎日 blogを書いていたにもかかわらず、4月は 17日分だけと、とても残念な結果に終わりました。とは言え、3月までも、そんなこと書いてどうするんだ Twitter でいいじゃねぇかみたいな内容のものも多く、よくこんなものを公開してたな、このやんちゃ丸などと自分を戒める日々が続いています。 まぁ、そんなことはどうでも良いわけで、なんとなく思いつきで始めた「オススメ書籍」も今回で終了です。 しょっぱなら「オススメする書籍はありません」とか、明後日の方向を見ながら続けてきたものの、気がつくとけっこう真面目な感じになっていて、ちょっと物足りなく感じている今日この頃です。 ただ、今になっても文書の構成は考えていない、いつ

    IT業界エヴァンジェリストのためのオススメ書籍(しょっさん編) | oshiire*BLOG
  • 人を育てるということについて昔よりあきらめが早くなっている: ある nakagami の日記

    その昔、僕が会社員の3〜5年目の頃、新人の OJT 担当を押し付けられることが多かった。 その時は、業務命令でもあったし、その人達が一人前になることによって仕事が分担されるんだから、なんとか一人前になってもらおうと思っていた。 あの頃に比べて、人を育てるということについて随分とあきらめが早くなっている。 ・・・というか、あって小一時間話しただけで「あ、この人はダメだ」と思うようになってる。 決して、冷たい人というわけではない(と思う)。 同じ会社に勤めていようといまいと、直接的な利害関係があろうと、同業者としての仲間として長く働いてもらいたいと思うし、たまたま同じ職場で働いていた人が立派になるのは素直に嬉しい。 だけど、ダメな人はダメだ。僕が頑張ったところで結局、人の役に立つ前に仕事を辞めるか、いつまでも周りに迷惑をかける。それがわかってから無理するのをやめた。 与えられた仕事を「なんのた

    人を育てるということについて昔よりあきらめが早くなっている: ある nakagami の日記
  • 70~80年代のCOBOLシステムを支えたプログラマの引退が近づいているが、システムは動き続ける | スラド デベロッパー

    1980年代には「COBOLは衰退するので、ほかのプログラミング言語に移行しなければならない」などと言われた。実際に1970~1990年代に書かれた細かなCOBOLプログラムのほとんどは新しいシステムと新しい技術に置き換えられている。しかし、銀行、保険会社、製造業、小売チェーン、医療機関といった大企業のミッションクリティカルなシステムは依然として大昔にCOBOLで書かれたコードによって運営されている。多くの企業はこれらのシステムを何度も入れ替えようとしたが、システムが全体が巨大で複雑な上、重要なビジネス・プロセスに統合されていること、また問題なく動いていることからこうした取り組みの多くは失敗した。 ITWORLDの記事によると、こうしたCOBOLで書かれたシステムを支えてきた団塊世代プログラマの引退が近づいているという(ITWORLD、家/.)。 今は大学のプログラム講座などでは教えるこ

    70~80年代のCOBOLシステムを支えたプログラマの引退が近づいているが、システムは動き続ける | スラド デベロッパー
  • 優れた仕様を決定するために必要なこと - GoTheDistance

    たまにはブログ更新したいから、ついさっき流れてきたエントリにいついちゃうよー。 ソフトウェア設計とは何か 〜 設計にはプログラミング経験が必要か否か | Social Change! 工程の分断はあり得ません ソフトウエアの設計に実装経験が要るか要らないかというのはそもそも議論にならない。「ソフトウエアの設計=仕様の設計+コードの設計」なんだから、例えればコインの表と裏。それらは引き離すことは出来ないのに引き離して分業しようとするからよろしくないことが起きてしまうというのが、上記記事の主題かと思います。簡単に言えば。 僕もこの点については「工程の分断」という言葉で何度も書いています。コインの表と裏であるべきものを分断してしまうと、互いのフィードバックを得る術を無くしてしまいます。そうなったら良いことは無い。ここは誰でも納得がいく所でしょう。 仕様を設計するチャンスって超少ないんじゃない?

    優れた仕様を決定するために必要なこと - GoTheDistance
    elwoodblues
    elwoodblues 2013/01/23
    「ソフトのオーナーとプログラマが直でやるとソフトウェアの密度はめっちゃ濃くなるし仕事も面白い」同意。今、それに近い状態で仕事できてるから、ある意味幸せなのかも。しんどいけど。
  • YouTube - スパルタ達によるプログラマ職業紹介

    300人のスパルタがプログラマの職業を紹介するそうです システムエンジニアにも当てはまるかも・・?

    YouTube - スパルタ達によるプログラマ職業紹介
    elwoodblues
    elwoodblues 2013/01/20
    まさに納期1週間前のおれにとっては、とても勇気づけられる!?内容だった。
  • アジャイルの取り組みが大きく遅れている

    アジャイル開発が盛んな米国に対して、日では依然としてウォーターフォールモデルによる開発が大半だといわれている。実際に、日アジャイルの取り組みが米国のほか英国、ブラジルなどと比べても遅れを取っていることが調査結果からも明らかになった。 情報処理推進機構(IPA)が2012年6月に公開した「非ウォーターフォール型開発の普及要因と適用領域の拡大に関する調査」によると、米国や英国では非ウォーターフォール型開発の普及度が高く、逆に日中国では低い(図1)。ここで、非ウォーターフォール型開発とはアジャイル開発など、短いサイクルで反復的に開発を進める手法のことである。 アジャイル開発の普及が進まないと、激しさを増す市場や社会環境の変化に日ITが対応しにくくなる恐れがある。IPAの柏木雅之氏(技術部 ソフトウェア・エンジニアリング・センター エンタプライズ系プロジェクト 研究員)は、「アジャ

    アジャイルの取り組みが大きく遅れている
  • ソフトウエア興業(株) | 倒産速報 | 最新記事 | 東京商工リサーチ

    ソフトウエア興業(株)(TSR企業コード:291854133、千代田区神田須田町2-9-2、設立昭和50年8月25日、資金50億円、岡田雅春社長)は、1月7日付で事後処理を林康司弁護士(TMI総合法律事務所、港区六木6-10-1、電話03-6438-5511)に一任した。 会社側によると、「12月28日、1月4日と資金ショートを起こした。負債総額は約180億円が見込まれ、このうち約165億円が金融債務。所有不動産売却を進め、任意整理に入る」と説明している。 各種ソフトウエアの開発を行い、大手電機メーカーや通信会社などと取引していた。また、業容拡大に伴い各地に事業所を設置するとともに、関連会社を設立し、ピーク時の平成20年3月期には売上高310億5400万円を計上した。しかし、リーマン・ショックに端を発する急激な景気後退の煽りを受け、システム関連の設備投資が低迷するなどして、平成23年3

    elwoodblues
    elwoodblues 2013/01/09
    わお。
  • 2013年、開発者が注目すべき10のスキル

    2012年の初めに、筆者は開発業界で勢いを増しつつある技術に関する記事を書いた。1年近くたって振り返ってみると、2012年の流行のいくつかがあまりにも早く進んだことに驚く。もちろん、モバイル開発が重要になることは予想されていた。しかし、タブレットの成長、特に「Android」タブレットの急速な伸びが、この市場を新たな高みに導いた。記事では、そのことを振り返りながら2013年に目を向ける。 頻繁にアップデートされるモバイルデバイス(特に「iOS」デバイス)と、「Chrome」と「Firefox」の短いリリースサイクルのおかげで、HTML5が多くのほかの方法を押しのけて、非常に重要な技術になった。ウェブ開発の世界は、次の2つに分割されている。 Javaと.NETをバックエンドで動かし、通信にSOAPを用いるエンタープライズ市場 PHPRubyPythonをバックエンドで動かし、軽量なRE

    2013年、開発者が注目すべき10のスキル
  • 特許庁のシステム開発が破綻した本当の理由

    特許庁と東芝の新システム開発契約打ち切りについて、なぜこの開発プロジェクトが破綻したのかについて私なりの解説をしようとバックグラウンドを調べたところ、調べれば調べるほど、この問題の根底には(1)コスト意識が欠如し自分たちが「公僕」であることを忘れてしまった霞ヶ関官僚、(2)霞ヶ関から流れて来るお金にたかる IT ゼネコン、(3)そのお金の流れに対する影響力を利用して票を稼ぐ政治家、という原子力業界と全く同じような構図があることが明らかになり、ウンザリしてしまった。 破綻の原因は、ソフトウェア・アーキテクチャやプロジェクト・マネージメントにあったのではなく、「競争原理が正しく働かない社会構造」そのものにあるのだ。これではうまく行くはずがないし、たとえうまくいったとしてもやたらと高くつく。 そもそも破格だと言われた99億円という落札価格も、私から見ればどうみても高すぎる。特許庁のシステムであれ

    特許庁のシステム開発が破綻した本当の理由
  • 情報システム部はどうであると得するのか? - 急がば回れ、選ぶなら近道

    いまさらの感もあるのですが、特にいろいろと日全国を飛び回るようになって、いろいろなお客さんにお世話になっています。ということで、その辺りで感じたことで、特にエンドユーザーの情報システム部はどうあると、「有利」なのか、ということを書いてみます。 対象は、お金を湯水のように使えないエンドユーザーさんです。とにかくリスクヘッジのためなら何百億円使おうと問題ではない、というユーザーさんはフルリスクを取れという要求以外であれば、SI屋さんの方から「無理なので、ご遠慮します」ということはありません。そのようなユーザーさんは、例外だとは思いますので、ちょっと対象外です。(なんか最近そうでもない説はありますが) 以下、あくまで自分の経験なので、不快な気分の方は、完全スルーでご容赦をお願いします。ベンダー風情が生意気な事を書きやがって、という方もいらっしゃると思いますので、そういう方には事前に、謝罪してお

    情報システム部はどうであると得するのか? - 急がば回れ、選ぶなら近道
  • ソフトウェア契約「請負」と「準委任(委託)」の違い | ソフトウェア開発ちっくな話 ~CADとWebとマーケティングと~

    ソフトウェア開発をする際、客先に常駐するケースも多々ありますが、 そのときに注意する必要があると思われます、 ソフトウェア契約「請負」と「準委任(委託)」の違いについて、 改めてメモしておこうと思います。 (「請負開発」と「委託開発」とでも言うんでしょうか。。。) 請負も、準委任も、他社の労働力を利用するための契約なんですが、 いくつか違う点があります。 ・請負 仕事が完成することで、報酬が得られる契約。 私のイメージは、受注生産みたいな感じです。 ・準委任契約 労働力を提供することで、報酬が得られる契約。 私のイメージは、日雇い労働者とかアルバイトみたいな感じです。 ちなみに、 委任は、法律行為の事務の委託をすること。 準委任は、法律行為以外の事務の委託をすること。 だそうです。 これに対し「派遣」は、準委任契約に近いですが、 労働者が、派遣先の指揮命令の下で働くことをいいます。 つまり

  • みずほ、復活への再挑戦 - 1年かけてシステムを総点検:ITpro

    システム全面刷新・統合をなんとしても成功させ、信頼回復に努めたい──。2度の大規模システム障害を引き起こしたみずほフィナンシャルグループのシステム関係者が、重い口を開き始めた。みずほがシステム関連の個別取材に応じるのは、2011年3月のトラブル以後、初めてのことだ。 みずほは1年間がかりで再発防止策を講じ、現在は大手銀初となる勘定系システムの全面刷新・統合を進める。 大規模障害の再発は当に防げるのか。世界最大規模となることが確実な刷新・統合プロジェクトを、やり抜けるのか。そして長年の課題である、ITガバナンスを強化できるのか。みずほ復活に向けた再挑戦を追う(関連記事:[スクープ]みずほの次期システムはマルチベンダー、4社に分割発注)。 分担の誤謬――。2011年3月の大規模システム障害でみずほ銀行(BK)が陥ったのは、勘定系という巨大システムを維持する上で避けて通れない、人や組織の役割分

    みずほ、復活への再挑戦 - 1年かけてシステムを総点検:ITpro
  • 史上最大級のシステム統合に挑む

    2013年7月のみずほ銀行(BK)・みずほコーポレート銀行(CB)合併に先駆け、みずほは2012年4月にみずほフィナンシャルグループ(FG)とBK、CBの組織を統合し、新生みずほとしてスタートを切っている。そのみずほは2016年3月末をメドに、BKとCB、みずほ信託銀行(TB)の勘定系システムを統合する(関連記事:[スクープ]みずほの次期システムはマルチベンダー、4社に分割発注)。 「システム統合は新生みずほを象徴するプロジェクトだ」。FGの高取次長は力を込める。日経コンピュータの取材で、システム統合の概要が明らかになった。 システム統合における最大のポイントは、勘定系システムを全面刷新することだ。既存の業務にとらわれず、銀行業務のあるべき姿を描き、それを実現するシステムを構築する。 機能単位でコンポーネント化 BK、CB、TBのいずれかのシステムに片寄せはしない。「不動産信託」など独自商

    史上最大級のシステム統合に挑む
  • 今年35歳になるので、エンジニアの35歳定年説というやつについて書くぞ - developer’s delight

    エンジニア35歳定年説。IT業界で働く人なら一度は聞いたことがある言葉なのではないかとおもいます。誰が言い出したのか知りませんが、この言葉は非常にタチが悪く、言葉だけが一人歩きしていて多くの人が「35歳くらいになると能力・体力の低下により新しい技術についていけなくなり、引退を余儀なくされる」という解釈をしているようです。しまいには妙な拡大解釈でこのようなエントリまで書かれる状況です。僕の認識をどんぴしゃで書いてくれているエントリがないので、自分の経験を少し書いてみたいとおもいます。僕が「エンジニアは35歳が定年」という言葉を初めて聞いたのは、新卒で就職したソフトウェア開発会社でした。僕が就職したのは、法人顧客のための業務システムを開発している、いわゆるSIをやっている会社でした。ある日、会社の先輩に「この業界、エンジニアで飯をっていけるのは35歳までだから、よく将来のこと考えておいたほう

  • 河北新報 東北のニュース/トインクス、クラウド事業参入 きょうからサービス開始 

    elwoodblues
    elwoodblues 2012/11/15
    サービス開始っていったって、toinxのサイトに何も載ってなかったぜ。ちゃんとしたプレスリリースもない。今日付けで部署が発足するってだけなのかな?
  • もう水平分業には戻れない

    システムの複雑化に頭を悩ませてきたユーザー企業は、垂直統合路線を支持している。それはメーカーの業績にも表れている。 「Oracle Engineered Systemsは、世界の大型コンピュータの中で最も売上高の伸びが高い。売上高は2012年度に、年間10億ドルに達する見込みだ」──。オラクルのラリー・エリソンCEO(最高経営責任者)は、2012年4月の「Oracle OpenWorld Tokyo2012」の基調講演で、自信満々にこう語った。 ユーザーの支持を背景に、垂直統合は今後も進む。メーカーやシステムインテグレータ、さらにはユーザー企業のシステム部門は、ビジネスモデルや自らの役割を転換する必要がある(図1)。

    もう水平分業には戻れない