SIはやめておけ
20代の数年間SIで働いた。1年以上前に退職して今は別業界にいる。 今日、Evernoteを整理していたら「退職理由、SIの嫌な点」というメモが発掘された。退職直前のかなりストレスがたまっていた時期に書き殴った文章だった。学生の頃の私は絵を書いたりしていて、ものづくりで暮らしたいな〜などと思って始めたプログラミングが楽しかったので安易に受託開発業を選んでしまったが、その後悔が如実に表れていた。 一部自分でも覚えていない話もあったがコンテンツとしては面白かったし、今でもシステムインテグレーター業界で消耗する若者を減らしたいとは思うので公開してみる。 以下、同メモに加筆・修正したものなのでファンタジーだと思って読んでくれ。 工数至上主義受注した時点で売上がおよそ確定するので、後はその予定工数に収めて納品できれば御の字という考え方。よくある話だが、見積がおかしくても顧客と対等な関係が築けていない
定形外業務も自主的に調べるのがベンダーの努めです
定形外業務も自主的に調べるのがベンダーの努めです：「訴えてやる！」の前に読む IT訴訟 徹底解説（14）（1/2 ページ） 東京高等裁判所 IT専門委員として数々のIT訴訟に携わってきた細川義洋氏が、IT訴訟事例を例にとり、トラブルの予防策と対処法を解説する本連載。今回は、契約内容に盛り込まれていない「オペレーターがデータベースを直接操作する機能」が実装されていないと支払いを拒否されたベンダーが起こした裁判を解説する。 連載目次 IT訴訟事例を例にとり、トラブルの予防策と対処法を解説する本連載。前回と前々回は、「ユーザーのシステム導入担当者に、自社の業務に関する知識がなかったために発生した紛争」について解説した。自社の業務プロセスや経理の勘定項目について、ほとんど知識がないユーザーを相手に要件定義を行わざるを得なかったベンダーの苦労はいかばかりだったか、と同情に堪えない。 このように業務知
ユーザーが資料をくれないのは、ベンダーの責任です
連載目次 ユーザーが義務を果たすためにはベンダーの支援が必要？ 本連載は主としてITベンダー向けに書いており、取り上げる紛争事例もどちらかといえばベンダーに厳しい結果が出たものが多い。そのせいか読者の皆さまから寄せられる意見の中には「裁判所はユーザーの責任をどのように考えているのか、開発側に負担が寄り過ぎてはないか」といったものも散見される。 しかしもちろん、判決の中にはユーザーの協力義務を厳しく問うものも多く、必要な時期までに要件定義を行わないユーザーや、仕様の確定に必要な情報をタイムリーに提供しないユーザーにこそプロジェクト失敗の責任があるとするものも少なくない。裁判所が、特にユーザー寄りというわけではないというのが、数多くの判例を調査しての私の実感だ。 ただし、ここで考慮に入れなければならないのはユーザー企業のスキルと経験である。システム導入におけるユーザーが負うべき責任についての裁
「システム障害はなぜ二度起きたか みずほ、12年の教訓」を読んでみた - だいくしー(@daiksy)のはてなブログ
少し古い本だが、「そういえばみずほ銀行の開発プロジェクトってどうなってるんだろう」と思いながら2chの某スレを読んでいて、この本の話題が出てきたのでKindle版を読んでみた。 システム障害はなぜ二度起きたか みずほ、12年の教訓 作者: 日経コンピュータ出版社/メーカー: 日経BP社発売日: 2011/07/28メディア: 単行本購入: 2人 クリック: 466回この商品を含むブログ (15件) を見る 本書の構成は大きく、 2011年3月の東日本大震災の義援金処理で発生したシステム障害の解説。 2002年の合併直後の新システム稼働時の大規模障害の解説。 東証や東京消防庁などの他の大規模システム障害事例の概観 システム障害を発生させないための提言 の4つにわけられる。 本書の主張は一貫して、ITはいまや企業の根幹を担う中枢であるので、IT部門に丸投げするのではなく経営陣が積極的にITにか
今度はうちのスパゲティから虫が出てきた。
取り除いても取り除いてもスパゲティから虫がなくなりません。 ソースに絡んで最悪です。 http://anond.hatelabo.jp/20141211153120
SIから非SIのIT会社へ転職しようとしてみてわかったこと - suzan2号の戯れ
2014-12-01 SIから非SIのIT会社へ転職しようとしてみてわかったこと 最近redmine関連のことばっかり書いているので、たまには全然違うことを。タイトルから分かる通り、転職に成功したわけではないのですが、 SIから非SIの会社に行こうとして自分が感じたことを書きます。 これから同じような転職をしようとしてる人の参考になれば幸いです。 自分の経歴について 院卒3年目、ハードも作っている大手のSIerでSEをやっています。 これまでの経歴としてはアプリ開発を1年弱、 インフラ構築・運用を1年半程度といった感じです。 現在は仮想化基盤の構築・運用に携わっています。 転職検討理由 詳しくは書きませんが、よくあるSEの憂鬱というやつです。 自分が就職するよりかなり前の匿名ダイアリーだけど、以下には凄く共感します。 人月計算とExcelとスーツの世界より 転職活動について
元SIer派遣エンジニアが見たSIerあるある桃太郎｜はらぱん
昔々あるところにCOBOLの金融システムを保守しているおじいさんと、政府システム開発の孫請け会社でプロジェクトマネジメントをしているおばあさんがいました。 おじいさんは山を登ったところの上位会社に障害管理表を提出しに、おばあさんは川を少し上ったところの「システムアーキテクトのプロフェッショナル集団」を標榜する2次請けのコンサル会社にスケジュール延長交渉をしに行きました。 おばあさんが川のふもとを歩いていると、上流からそれはそれは大きな仕様上の不備を含んだ桃がドンブラコ、ドンブラコと流れてきました。 （おや、これは持ち帰りたくないわ）と内心迷惑に思いつつも、甘受する他ないので、その桃を持ち帰って内部で検討することにしました。 そして、おじいさんとおばあさんが桃の仕様を精査しようとすると、突然中から元気の良い優秀なプログラマが飛び出してきました。 「これはきっと、神さまがくださったにちがいない
paizaには認識されてないSIerで身につけられる技術 - プロマネブログ
SI⇒Web転向に失敗するエンジニアに共通した【たった１つの特徴】 - paiza開発日誌 SIerがぬるま湯なのか。。。SIerって平均的にはわりかし給料が高いけど、高給ぬるま湯ならホワイト企業ってことで、SIerへ転向進めたほうがいいんじゃないのかな。 2014/11/12 00:41 個別の転職話は正直興味ない話なのでここではおいておくとして。。。 毎度のごとく、SIer disへの誤りを指摘しておきますか。 転向者の割合を求められる水準の高さと勘違いしてはダメでしょ しかしWeb系企業の中途採用におけるSIerから転向者は22.8%であり、決して広き門とは言えない状況です。 ふむふむ。主張としては、WEB業界へ転向する人のうち、22.8％しかいないため、WEB系企業で求められる人材の水準が高い、と言いたいようですが。。。 でも、その直前にはこんなこと記載しているんですよね。。。 逆
SI⇒Web転向に失敗するエンジニアに共通した【たった１つの特徴】 - paiza times
Photo by Robert Tadlock 今回のpaiza開発日誌は片山がお送りします。 SIerに在籍しているエンジニアで、技術(開発)を中心としたキャリアを積んでいくために、SIerからWeb業界(Webサービス提供系)に転向/転職しようと思っている方は近年増えています。そんな方向けに、SI⇒Web転向で「失敗してしまう人の特徴」と、「上手くいく人の特徴」についてまとめてみました。 ■SIからの人材流出は増えているが、Web転向は狭き門 SIer⇒Web業界への転向成功者、失敗者の特徴を見てみる前に、まずはSI業界とWeb業界の採用動向について見ていきましょう。 昨今、特に飲食業界等を中心として人材不足が叫ばれていますが、IT業界も成長産業のため、常に人材が不足していると言われている業界です。2014年9月18日の日経新聞でも「IT分野の派遣『月収100万円』でも集まらず」という
銀行業界におけるSIerの勢力図を知っていますか？：情報インフラ24時 眠らないシステム：オルタナティブ・ブログ
金融業とITが一体化してからすでに久しく、いまや、あらゆる金融決済業務はITシステム無しでは語れません。私たちの生活に最も身近な銀行業界も例にもれず、東日本大震災の義援金口座トラブルの際には、お金のやりとりが滞って多大な影響を受けた方も多かったと思います。 これほど重要な業務を支えるITシステムとなると、その開発や維持には多大なコストが発生するもので、日経コンピュータ（2010年4月14日号）によれば、100億～200億（オープン系～メインフレーム）の初期開発費用が発生すると述べられています。 10年以上前までは、こういった銀行の根幹を支える勘定系システム（預金・貸出・為替業務を支えるシステム）を独自開発する銀行は多く、これの開発を得意とする国内SIerの一部は「メインフレーマー」と呼ばれ、カスタムメイドを重ねに重ねたシステム維持運用を当たり前のように提供していたのです。 しかし、業務の集
「お前が悪い!」「ウソをつくな!」名門企業どうしがシステム開発を巡って法廷闘争 野村證券vs.日本IBM 感情ムキ出し「33億円」の大ゲンカ（週刊現代） @gendai_biz
「お前が悪い!」「ウソをつくな!」名門企業どうしがシステム開発を巡って法廷闘争 野村證券vs.日本IBM 感情ムキ出し「33億円」の大ゲンカ そこまでするか、と首をかしげずにはいられない。誰もが知る有名企業同士が繰り広げる相互批判、暴露、醜聞の蒸し返し……。異例の喧嘩の裏には、どうしても負けられない「事情」があった。 まず野村が訴えた 子供の頃、喧嘩には暗黙のルールがあった。相手が泣いたら止める、血が出るようなことはしない、顔は殴らない。 大人であればなおさらのはずだが、野村證券と日本IBMという名門企業が法廷の場で争う大人の喧嘩には、そうしたルールはまったく通用しないようだ。 互いが互いを徹底的に批判し、完膚なきまでに叩きのめそうとする大ゲンカが今、展開されている。 「野村がIBMに委託したシステム開発プロジェクトが頓挫したことがきっかけで、野村が被った損害として約33億円という巨額の支
2015年問題と3年後のIT業界について - novtan別館
問題の本丸みたいなところにいるとひしひしと感じるいろんなこと。 とにかく人が足りない。いや、ぶっちゃけ人は足りてる。人材が足りない。半分はいない方がマシ。いなくてもアレやらコレやらがあればできるし品質は上がる。偉い人にはそれはわからない。なぜなら100点を目指しているから。95点を取ることは割と簡単なんだけど、100点を目指すと95点の10倍の労力が掛かった上に85点くらいにとどまってしまうリスクが物凄い高い。残り15点をどうするって？ひたすらやるだけさ。 人手不足というのは幻想なので、エンジニア不足の現状においてもクズエンジニアは雇わない。新人でもいいからかき集めろみたいな記事が出たことがあったけど、新人の方がまだクズでない可能性が高いというくらいは人材は不足している。クソみたいなエンジニアのおもりをしなければならないせいで。 問題は、システムの開発ヒエラルキー（これは単に契約関係でしか
永和さんの「価値創造契約」が大苦戦を強いられている件 - GoTheDistance
この資料、非常に衝撃的だった。中の人がここまで公開していいものなのか、という意味でも。 俺の価値創造契約 from Fumihiko Kinoshita 永和さんの価値創造契約とは 新しい契約形態での受託開発サービス「価値創造契約」 ｜ 永和システムマネジメントに詳しくありますが、簡単にいえば「初期費用無料で、常に改善・運用をしながら月額定額制でシステム利用料を頂く」というビジネスモデルです。価値あるシステムは必ず長く使われ変更を伴うのだから、その変更を受け入られるモデルを提供すれば双方にメリットがある。これが立脚点のようです。 2013年営業実績、0件 資料によればテレアポを800社行い、様々な展示会にも出展されたそうです。12社にコンタクトできたけれど受注は0件だと書いてあります。マーケティングに失敗してしまったと言って良いでしょう。 受託開発の弊害と指摘される「価値あるシステムを作り
検収後に発覚した不具合の補修責任はどこまであるのか（前編）
検収後に発覚した不具合の補修責任はどこまであるのか（前編）：「訴えてやる！」の前に読む IT訴訟 徹底解説（4）（1/2 ページ） 連載目次 今回は「稼働後に検出した不具合を理由に、ユーザーがいったんは検収したシステムの支払いを拒んだ事件」と、そこから得られる知見を解説しよう。 請負契約によるシステム開発において、検収まで行った発注者が受注者との契約を解除し費用の支払いを拒むという例は、ユーザーとベンダーがシステムの完成をめぐって争うことの多いIT業界においても決して多いことではない。 しかし、この判決は、システム導入の目的と要件の関係やその検証、および導入後のベンダーの不具合対応などについて、多くの論点を提供してくれる。今後に役立つ知見を残してくれるものであることから、今回の題材として取り上げることとした。 請負契約において、ベンダーが「ユーザーと交わした約束をしっかりと果たした」と言え
IT業界の人月商売、多重下請けがもたらす45の害毒
私は自分のコラム「極言暴論」で、ユーザー企業のIT部門とITベンダーの問題点や課題を極言し、暴論してきた。だが、特にITベンダーあるいはIT業界の話を書くと、空しくなることがある。私が指摘する問題点は、ITベンダーの経営幹部なら随分前から自覚している。それでもITベンダーや業界は何も変わらない。 「極言暴論」の読者にも「以前に何度も聞いた話」とシニカルに受け止められてしまったりする。「このままでは日本のIT業界に未来は無い」と叫んだところで、「またですか」とオオカミ少年扱い。やはり“ゆでガエル”状態になっている人には、湯の温度が多少上がったぐらいでは危機感を持って受け止めてはもらえない。 それでもクラウドの世となり、ITベンダーを丸ごとゆでる湯の温度は急激に上昇している。今起こっているパラダイムシフト、パワーシフトは以前のダウンサイジングやインターネットの爆発的普及のときの比ではない。シス
今までに経験した中で最悪の開発環境について書く
なんとなく吐きだしてみる。老害の昔語りなので興味ない人はスルー推奨。 時は2000年代初頭、俺は最初に就職した独立系SIerから4次請けの派遣として某銀行の営業店システム開発に参加していた。 新卒で入社して、二つ目のプロジェクトだった。当時は最先端であったJavaでのプロジェクトということで、ずいぶんと喜んだことは記憶している。 1フロアが丸ごとプロジェクトルームとなっており、プロジェクト統括の事業部長が常に怒号をあげながらフロアを徘徊するなかで、15インチCRTディスプレイ(当然液晶なんかじゃない)がようやく置ける狭い机とパイプ椅子で、右も左もわからないまま、Excelで書かれた仕様書と向き合い、秀丸エディタ(当時はEclipseがまだ生まれていなかった)でジャバを書いていた。 デスマであったかというと、今思うとそこまでデスってはいなかったように思う。頻繁にリスケが行われていたのでプロジ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
日本IBMに野村が33億円賠償請求 なぜ訴訟相次ぐ - 日本経済新聞
基幹システム プログラマー不要 富士通がソフト、開発費４割減 ：日本経済新聞
まとめよう、あつまろう - Togetter
特許庁システム開発中断:東芝子会社など２社５６億円返還 - 毎日新聞