富士通などのSIerの惨状を見ていると、太平洋戦争で負けた大日本帝国を思い出す - 文春オンライン
日本人が経営の組織はだいたい同じ問題を抱えている で、先日、日本の大手SIerであり、官公庁から大手企業、地方の中小企業にいたるまで多くの組織の情報化を支えてきた富士通グループというステキ法人について、5年勤めたとされる人物が増田（はてなアノニマスダイアリー）で実情記事を書いていて話題となりました。 5年いた富士通を退職した理由 https://anond.hatelabo.jp/20190326233147 あまりにも感動的でストレートな内容だったため、この界隈だけでなく私の生息する社会調査やサイバーセキュリティ関連の皆さんのハートを直撃しました。もうね、キュンキュンしますよ。開発系の人たちの集まるコミュニティでは大盛り上がりでした。さすがに富士通で働いている人からは「そこまで酷い環境じゃないよ」という反論もいくつか出ていまして、細かい点では事実と異なるのかもしれません。 しかし、この記
無料のシステム開発テンプレート集（Excel版）: ある SE のつぶやき
はじめに システム開発を効率よく進めるための１つの方法として、システム開発のテンプレートを使用することがあります。 ですが、システム開発のテンプレートは企業内で閉じてしまっていてなかなかインターネットで公開されることはありません。 ですので、システム開発で使用するであろうテンプレート集を Excel で作成して公開します。もちろん無料で商用利用可能です。改変も OK です。 プロジェクト管理用 スケジュール管理などのプロジェクト管理用のテンプレートはなかなかないのですが、プロジェクト管理の補助となるようなテンプレートを用意しました。 プロジェクト管理ツールは、別記事の「フリーで使えるプロジェクト管理ツールまとめ」をご参照ください。
技術を軽視するIT業界には萌えられない
“こんなシリーズを書いておいて何ですが、僕は日本のIT産業に明るい見通しを持てていません”――。 「萌えるSE残酷物語」がコンセプトのライトノベル『なれる！SE』（アスキー・メディアワークス発行）が2017年8月、16巻目にしてシリーズ本編完結を迎えた。ITproでもたびたび採り上げており、ご存じの方も多いだろう。 『なれる！SE』は新人エンジニアの桜坂工兵が個性豊かな上司や顧客に囲まれて成長する物語だ。16巻で工兵は引き続きエンジニアの道を進むか、経営に近い道を歩むか、判断を迫られる。2年目SEの工兵がどのような決断を下したかは是非本編を読んで確かめてほしい。 最初に紹介した文章は、16巻の筆者あとがき冒頭から引用したものだ。元SEである筆者の夏海公司氏はあとがきで「新しいものをつくる」「面倒なことを便利にする」ことができるエンジニアへのあこがれを明かす一方で、日本のSEを巡る状況につい
SIについて私が思ったこと。そしてSIerにおけるモダン開発について : 小野和俊のブログ
ひとことで言えば、「レビュー文化は良くない」ということになるだろうか。 Slack導入、そして同時期に開始した服装の自由化、バイモーダルという考え方の浸透、AIやブロックチェーンを活用したPOC等の取り組みによって、SIerとしてのセゾン情報システムズは、社内の雰囲気もずいぶんと変わってきた。 しかし、こうした取り組みだけではどうにもならないものも少なからずあった。 そのひとつは、「悪い報告がしづらい」ことだった。 これは他のSIerでも同様のことが多いのではないかと思うが、問題プロジェクトに認定されると、品質管理部のモニタリングが強化されたり、第三者によるプロジェクト監査が始まったり、経営会議での定期的な報告が求められたり、何をやっているのかとレビューでこっぴどく叩かれたり、、、。 そうした責任感から、遅れをキャッチアップできるよう少しでもがんばろう、と励まし合う中で、それなのに四方から
エンジニアから見たSIerがクソな理由 - 負け犬プログラマーの歩み
少なくとも90%以上のSIerはクソだと思っている。 もちろん、これはポジショントークだ。SIerの中の人なら「SIerは最高だ」と言うだろうし、エンジニアをWeb系に売り込んで紹介料を稼ぐ転職エージェントなら「SIerはクソだ！Web系こそ至高！」と言うだろう。そして中立的な第三者であれば、一歩引いて日本にとってSIerは必要悪なのかどうかという視点で語るかもしれない。 しかし俺はエンジニアであり個人事業主だ。その上「技術的にはそこそこかもしれないが、人間としてはクソ」という特徴を持つ。だからこんな世渡りが下手な人間にとって便益があるかどうかという狭い視点でしか語れない。これが一般的な観点と言われれば否かもしれない。 それを前提で書かせてもらうと、よほど未熟でもない限り、エンジニアがSIerで働くのは時間の無駄だ。 なぜなら、SIerとはエンジニアの為の組織ではないからだ。 SIerの主
【Web系最高って言うけど本当なの？】SIから転職したエンジニアたちに聞いてみた - paiza開発日誌
Picture by ITエンジニアを目指す女子高生たちの学園ライフ4コマ漫画『ぱいじょ！』 こんにちは、谷口です。 退職・転職エントリの記事は多々ありますが、転職を考えている人にとって参考になるのは、「転職を実際に経験した人が、その後どうなったのか？前職との違いをどう感じているのか？」といった後日談ではないでしょうか。 paizaを開発しているのは、ほとんどが転職を経て中途で入社したエンジニアです。 paizaで転職のご相談をいただく方の中には、SIerからWeb自社サービス系に転向したいという方が多いため、今回は、SIerからWebサービスを自社開発している弊社へ転職して半年～1年弱のエンジニア2人が、実際の業務を経験してみて感じた前職との違いを、開発環境や労働環境、モチベーションやキャリアについてなどあらゆる面において聞いてみました。 いずれは転職を考えている人、転職はまだ考えてない
SIはやめておけ
20代の数年間SIで働いた。1年以上前に退職して今は別業界にいる。 今日、Evernoteを整理していたら「退職理由、SIの嫌な点」というメモが発掘された。退職直前のかなりストレスがたまっていた時期に書き殴った文章だった。学生の頃の私は絵を書いたりしていて、ものづくりで暮らしたいな〜などと思って始めたプログラミングが楽しかったので安易に受託開発業を選んでしまったが、その後悔が如実に表れていた。 一部自分でも覚えていない話もあったがコンテンツとしては面白かったし、今でもシステムインテグレーター業界で消耗する若者を減らしたいとは思うので公開してみる。 以下、同メモに加筆・修正したものなのでファンタジーだと思って読んでくれ。 工数至上主義受注した時点で売上がおよそ確定するので、後はその予定工数に収めて納品できれば御の字という考え方。よくある話だが、見積がおかしくても顧客と対等な関係が築けていない
巨大銀行の巨大システム開発で大変素晴らしい経験を得たという話
最近まで、ネット上のIT系ニュースで度々システム障害で我々にネタを提供してくれる某巨大都市銀行の次期システム開発に下請けとして新卒から参画していた。「某巨大都市銀行の次期システム」という時点でどこの銀行かピンとくると思う。次期システムとは大雑把にいうと80年代に構築され今なお稼働しているシステムのうち、外為、内為、預金などの業務にて稼働するサービス(実際のプログラムになる)を疎結合化してそれぞれのサービスを部品として再利用性やメンテナンス性の向上を図る、いわゆるSOA(サービス指向アーキテクチャ)で作り直そうというものだ。この辺も心当たりのある銀行と次期システムとかでググれば出てくると思う。銀行システムをSOAで構築するのは日本では初めて！！すごい！！先進的！！！という触れ込みだったらしいが、立ち上げからいるわけでもなくSOAの利点も結局実感できぬままこの業界から去ってしまったので本当に謎
IT業界の『多重下請け構造』は社会悪になりつつある - paiza times
Photo by Jonathan Kos-Read 今回のpaiza開発日誌は片山がお送りします。 SIerについて語られる際にIT業界の「多重下請け構造」についての問題点が良く取り上げられますが、「多重下請け構造」がITエンジニアにとってどのような問題点があるのでしょうか？ その点について今回は少し整理してみようと思います。 ■「多重下請け構造」とは何か 説明するまでもないかもしれませんが、「多重下請け構造」とは、受託システム開発において、発注者から直接仕事を請け負った元請（たいていの場合が大手SIer）が、請けた仕事を切り出して2次請け、3次請け、4次請けと仕事を下ろしていくピラミッド構造の事を言います。 良くある例で言うと、元請は要件定義や概要設計等の上流工程を請負い、開発・実装などの下流工程は2次請けに委託する、というような構造です。2次請けは自社リソースで開発を賄えない場合に3
検収後に発覚した不具合の補修責任はどこまであるのか（前編）
検収後に発覚した不具合の補修責任はどこまであるのか（前編）：「訴えてやる！」の前に読む IT訴訟 徹底解説（4）（1/2 ページ） 連載目次 今回は「稼働後に検出した不具合を理由に、ユーザーがいったんは検収したシステムの支払いを拒んだ事件」と、そこから得られる知見を解説しよう。 請負契約によるシステム開発において、検収まで行った発注者が受注者との契約を解除し費用の支払いを拒むという例は、ユーザーとベンダーがシステムの完成をめぐって争うことの多いIT業界においても決して多いことではない。 しかし、この判決は、システム導入の目的と要件の関係やその検証、および導入後のベンダーの不具合対応などについて、多くの論点を提供してくれる。今後に役立つ知見を残してくれるものであることから、今回の題材として取り上げることとした。 請負契約において、ベンダーが「ユーザーと交わした約束をしっかりと果たした」と言え
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
「情報システム産業では、2000年代後半から協力会社を中心として労働環境の悪化が相次ぎ受託開発ビジネスの限界に直面。丸投げ委託、多重下請けと人月ビジネスの横行等により、業界全体の魅力が低下した」という経済産業省の産業構造審議会の公式見解について
コピーした画像を「Excel」へ自動でスクラップできる「imageClipPaste」NOT SUPPORTED