SI系企業で社内独自のフレームワークを作りたくなる理由について
tl;dr社内フレームワークは開発生産性を高めるためと言われることが多いが、実際はシステムを守るために産まれる（ことがある）すべては複雑怪奇な業務をシステム化する人が、システムアーキテクチャや非機能面まで全て見れないことに起因する画期的なハックはなく、業務にもシステムにも詳しい人を増やしていきましょうはじめにSI系の大規模な業務システム開発に参加すると、社内独自の重厚なフレームワークに遭遇することがあると思います。ここでいう社内フレームワークとは以下の条件に一致するものを指すことにします。 クローズドソースであるその社内でゼロベースで開発されたり、既存のフレームワークを拡張・ラップしているなど、独自の背景・思想により開発されているそのため、フレームワーク独自のお作法や制約がある開発生産性の向上や、非機能的な要件を満たすことを目的とする社内フレームワークに思いを馳せる自分が経験があるのはJa
IT業界における下請け企業の過去現在未来の話 - orangeitems’s diary
底辺IT企業は『書けない』プログラマとどう向き合ってきたか、を読んだ 「あの世界は今、そうなっていたのかあ」、という文章を読みました。 www.megamouth.info 感想 私が昔いた会社は、底辺IT企業とは言わないまでも下請メインの会社だったので、10～20年前が本当にこうだったことを知っています。大量の下請案件が流通していて、それを大量の下請会社が消費していました。この文中のように、とりあえず人をあてがうことが重要であり、その中の人の品質は見事に軽視されていました。単価こそ重要。あとは本人のキャラクターが次に大事で、それこそあいさつ、言葉遣い、勤務態度などに問題なければ採用という時代でした。採用といっても正社員じゃないですよ。SESです。もちろんSESにしろ派遣にしろ、常駐先との事前面接は法的に禁止ですから、「じゃあ面談で」なんて言葉遊びに終始しておりました。もう山とも海ともわか
#完全SIer脱出マニュアル が #技術書典 5から1週間で800部も売れて心底驚いている - #がみぶろ
こんにちは、gamiと申します。 2018年10月8日(月)に開催された技術書典5に軽い気持ちで初サークル参加しました。 techbookfest.org 結果、オンライン購入も含めて1週間で800部も売れたので、驚いてブログを書いてます。 別に売れた本が良い本という訳でも無いですが、「こんなに需要があったのか！」という感じです。 頒布した本は、『完全SIer脱出マニュアル』という、なんとも燃えそうなタイトルの本です。今でもPDF版はダウンロード購入できます。 booth.pm 本の内容や本を出すまでの経緯は、以下のブログに書いたのでぜひご覧ください。 jumpei-ikegami.hatenablog.com 事前の準備 紙の本は200部刷った 技術書典では、Webサイト上でサークルを「チェック」することができます。 さらにサークル側は、自サークルの被チェック数を見ることができ、どのくら
IT業界は日本社会の縮図となっているんだよ - こうして僕らは腐る
僕も住人たるIT業界 ossan.hatenablog.com anond.hatelabo.jp 弱いSE、強いSEという視点で説明しておられる。 僕は経営と日本社会という視点で見てみよう。 この業界にはもう10年近く住んでいる。21歳で学もなくブラブラしていた僕はオンラインゲームの世界にいりびたっていた。当時は今ほど常時オンラインでゲームすることは一般的ではなかった。今ほど便利でなかったため、必然的に多少のITスキルは身についた。例えばゲーム操作をしながらチャットする必要があるためPCでのタイピングは速くなったし、攻略法をネットで調べるという検索力なんかも身についていた。そのため僕は親にどやされてアルバイト生活から正社員になる時、IT業界を選んだ。 理系の学位などもない僕は、超文系のプログラマ見習いから始めることになった。いわゆる弱いSEである。入った会社はIT業界歴の長い人たちで独立
新人SEが同じ場所で常駐を続けると蝉になる - 室長のひとりごち
4月入社の新人システムエンジニアも、春のうちに配属になったり、夏のこの時期から現場に配属になったりと、組織の教育制度によりバラバラでその辺りは新人SEをどこまで教育できるかという組織の体力や現場のリソース不足が如実に現れますね。それよりこうして配属時期を思うと、入社してすぐにSEとして認められるなんてある意味すごい業界なような気がしますね…。 新卒の学生が企業を選択するのも、企業が新卒を採用するのもどちらも博打な訳ですが言い方を変えればエンゲージメントなのですよね。合うのか合わないのかはそれぞれの体質みたいなものですから。 新人SE、常駐先に配属になる ワタシもそうでしたが、新人教育というなのちょっとした教育期間後に、速攻で現場に常駐に出されるケースが多いです。現場の規模が大きければ大きいほど、顧客とSIerの双方の依存関係は深いですからワークロードの道幅も広く、業務も顧客よりエンジニアの
日本のIT産業がいびつな理由
印刷する メールで送る テキスト HTML 電子書籍 PDF ダウンロード テキスト 電子書籍 PDF クリップした記事をMyページから読むことができます 「世界のIT産業の方向性や事業ポートフォリオなどから見て、日本のIT産業はメチャクチャにいびつだ」。ITコンサルティングを展開するフューチャーアーキテクトなどを傘下に抱える持株会社フューチャーの金丸恭文会長兼社長（グループCEO）は、日本のIT産業の問題点を指摘する。同氏の発言などから、IT企業が進む道を探ってみる。 保守的なIT投資スポンサー 同社が株式公開を果たしたのは1999年のこと。ITコンサルティングサービスを掲げた初のIT企業だったが、金丸会長は「そんな事業内容はない」と言われたことを今も覚えている。指摘通りか、「マーケットは広いと思ったが、現実は広くなかった」。 革新的なIT活用に挑戦するユーザー企業が少なかったということ
「一括請負はお互い不幸」から「作らないSI」へ - GoTheDistance
僕がSIerを退職して５年。大きな潮目を迎えているのかもしれない、SIビジネスのお話。 itpro.nikkeibp.co.jp 簡単にまとめると「一括請負はゼロサムになってお互い不幸なんで、XaaSを使って作らないSIをやり始めている」という話を「オルタナティブSI」という言葉で表現しているようです。この5種類に分類してくれていますが、ただ並べただけで軸はバラバラです。 月額契約型サービス「納品のないSI」 固定料金でシステムを構築する「定額パッケージSI」 自動生成ツールを使う「自動生成SI」 クラウドでITインフラを構築する「クラウドインフラSI」 ユーザー企業自らシステムを外販する「コミュニティSI」 作らないSIはずっと前から目指していた 代替となる選択肢は色々あるけれども、根幹にあるには「作らないSI」を目指していることだと思っています。 僕がSIerにいた10年前も「作らない
日本でプログラマが少ない理由は戦う戦場を間違えているからです - 文系プログラマによるTIPSブログ
2015-03-08 日本でプログラマが少ない理由は戦う戦場を間違えているからです IT業界 ◯ 広告 昔から言われている日本のプログラマ問題、さて、皆さんどう考えているのでしょうか。 日本でプログラマが少ない理由は正当な対価を支払わないからである : SIerブログ この記事を読んで、色々と思うところがありました。 社長や偉い人の見解 日本史なんか教えなくていいからプログラミングを教えろ、日本でプログラマが足りない理由は 工学系とかプログラム系を学ぶ学生が少ないから http://wirelesswire.jp/london_wave/201503031606.html まあ一理あるとは思いますが、ちょっと浮世離れしている感が否めません。 スレ住人の見解 続いてスレ住人達の見解です。こちらは現場サイドの意見が見られます。 ぶっちゃけ日本人は能力格段に低い 日本のIT企業はコミュ力で勝
ITベンダー、ユーザーを問わず大企業の技術者がダメな理由
先日、小売業のCIO（最高情報責任者）の人と話していて、互いに激しく同意したことがある。それは「大規模プロジェクトを担当してきた技術者よりも、小規模なプロジェクトを担ってきた技術者のほうが、優秀な人が多い」というもの。もう少し踏み込んで私流に暴論すると、ITベンダーかユーザー企業かを問わず、大企業の技術者の力量は大したことがない。 もちろん、大規模プロジェクトを担う技術者や、大企業に所属する技術者にも優れた人はいる。そうでないと、プロジェクトは破綻し、ITベンダーなら倒産してしまうだろう。だが、必ずしも技術者だけの職とは言えないプロジェクトマネジャーを除けば、「この人、本当にすごいな」と思える技術者は、少人数のITベンダーに所属していたり、中堅のユーザー企業で“ひとり情シス”をやっていたりする。 いま「プロジェクトマネジャーを除く」と書いたばかりだが、実はプロジェクトマネジャーも、大企業で
元社畜SEが教える、IT土方から抜け出す方法 - NZ MoyaSystem
「IT業界で働きたいけど、残業が多そうで怖い」という不安を抱えている人、多いんじゃないだろうか？ 確かに、IT業界は一歩道を間違えるとデスマーチという落とし穴が待ち受けている。 あまりに過酷な働き方から「IT土方」なんて言葉もあるくらいの業界だ。 僕は、かつては日本でシステムエンジニアとして働き、毎日終電、休日出勤も当たり前のブラック労働をしていた。 そこから脱出して、今ではニュージーランドのIT企業でプログラマをやっている。 残業はゼロで毎日定時で帰れる職場だ。 天国と地獄の両方を見てきた経験から、今日はどうすれば「IT土方」にならずに働けるかについて考えたいと思う。 なおこの記事では「IT土方」を「過剰な残業(月60時間以上)、休日出勤を強いられるIT技術者」と定義する。 ITゼネコンの一部になるな 大手ITベンダー 下請け 孫請け IT土方にならないための具体的な方法 高いプログラミ
IT業界に足りない人材は“臨時工”や“コボラー見習い”なのか！
SIerや下請けの受託ソフトウエア開発会社など SIガラパゴスに生きるITベンダーの経営者は、口を開けば「IT人材が足りない！足りない！」と騒ぐ。だが、彼らが足りないと言うIT人材とは、大型案件が集中する今の繁忙期を乗り切るための“臨時工”か、スパゲティ状のコードを永遠に保守し続ける“コボラー見習い”の若者だ。本来、必要なはずのIT人材に関心が無いから恐ろしい。 必要なはずのIT人材とは、別にニュータイプの技術者のことを言っているのではない。以前から必要性が叫ばれてきた「顧客の業務や最新技術に知見を持ち、提案できる技術者」のことだ。だから一応、ITベンダーの経営者も口では、そうしたIT人材が必要だと言う。だが今、欲しいのは臨時工か、コボラー見習い。だから技術者を志す若者は、彼らの言う必要な人材の意味を見極めないと、あとで泣きを見る。 臨時工とコボラー見習いのうち、ITベンダーにとって焦眉の
皆が大嫌いなコンサルタント、それ以上に無責任な面々のたわ言
コンサルタントほど、ユーザー企業のIT部門やIT業界の人たちから広く嫌われている職業はないだろう。「うちの社長をたぶらかした」「いい加減なことばかり言う」「言うだけ言って、とっとと逃げる」等々。そんな罵詈雑言の嵐なので、私は少々気の毒になってしまうのだが、当のコンサルタント自身が「コンサルタントにろくな奴はいない」と罵ったりするものだから、もうわけが分からない。 今回は、そのコンサルタントにまつわる話で暴論してみようと思う。ただ、コンサルタント自身の話しではない。タイトルの通り、コンサルタントを「無責任な連中」と罵るコンサルタント以上に無責任な面々の話である。この「極言暴論」の以前からの読者ならお察しの通り、その面々とはシステム部長やIT部門の技術者、そして御用聞き商売のSIerの営業や技術者たちである。 一概にコンサルタントと言っても、担当領域は多様である。ここで想定するのは、経営課題の
SIerのクラウドは、生き残ることができるのか？ - ベテランIT営業が教える「正しいITの使い方、営業の使い方」
「SI事業者が提供するクラウド・サービスは、生き残っていけるのでしょうか？」 ある講義の中でこんな質問を頂きました。私は、次のように答えました。 「これまでのユーザー企業との関係を踏襲したままでのクラウド・サービスは、長続きするとは思えません。」 「イノベーションのジレンマ」の中で、著者であるクリスチャンセンは次のようなことを述べています。 新技術のほとんどは、既存製品の性能を高めてゆくものです。各社はそれを競い、完成度を高めてゆきます。その行き着くところは、市場の求める要求を越えるものとなり、それ以上の性能の向上は、もはや競争力を生みだすことはなくなります。そうなると今度は価格競争となり、市場は拡大しつつも収益を上げることが難しくなります。 時として、同じ市場のニーズをカバーする全く新しい技術が生まれることがあります。この技術は、短期的には既に市場に存在する技術に比べて性能の劣るものでし
僕がCOBOLから学んだこと - worarの日記
SAStruts＋DBFluteでの開発が終わり、またCOBOLで書かれたシステムの保守が始まる・・・。 あぁ、楽しかったSAStruts、楽しかったDBFlute、楽しかったJava。 ということで、この辺りで一度、COBOLから学んだことについてまとめてみようと思う。 僕が今、主にかかわっているシステムはクライアント側がVB(Windows)、サーバ側がCOBOL(UNIX)で出来ている。そして更にバックボーンには、メインフレームが構えている。メインフレーム側の構成は主にPL/1＋JCLで、もちろんDBは階層型だ。 そんなシステムを２年近く保守してきた中で気付いたことを書いて行こうと思う。 カプセル化やスコープの重要性 今更何を言っているのかと思う方もいると思うけど、マジなんだ。僕が初めて学んだ言語はC言語でそれからC++、Javaと続き、その後LL言語にも手を出し始めた。C++を始め
終わるSIerの底辺を見てきた - ミッションたぶんPossible
ご挨拶 今月の第二日曜日は3月11日でした。言わずと知れた、あの「3.11 東日本大震災」から丸一年が経過した日です。改めまして、当時亡くなられた方々のご冥福をお祈り申し上げます。また、被災され現在も不便な暮らしを強いられている大勢の方々にお見舞い申し上げます。一日も早く元通りの日常が送れるようになることを願って止みません。 3.11の14:46、オレは代休で自宅にいるところにあの大地震がやってきました。自身が立つこともままならないような衝撃の中、不安定なテレビ台とPC棚をなんとか抑えて揺れが収まるのを必死で耐えたのは、今でも鮮明に思い出すことができます。それもあって我が家の被害は全くなく、妹も職場の方の好意で車で送って貰え、日付が変わった頃に無事帰宅できました。都内では翌日昼を過ぎても帰宅できなかった人が多かった中、我々は非常に運が良かったと思います。 はじめに さて、オレにとって、この
受託開発は本当にオワコンか？ SI業界の未来を前向きに考える
Webサービス全盛の今こそ、エンジニアリングについて本気で語るイベント、「これからのエンジニアリングの話をしよう」第1回レポート。未来の受託業界を担うベンチャー企業のエンジニアが集まってパネルディスカッションを行った。 「Webサービスは格好いい」「SIオワコン」本当に？ 「Webサービスが盛り上がっていて、“クリエイティブで楽しい”“華やか”というイメージがある。一方、受託開発は“地味でオワコン”という風潮があるが、本当のところはどうなのか？」 2012年1月19日、ベンチャーカフェが主催するイベント「これからのエンジニアリングの話をしよう」で、このような質問が投げ掛けられた。 本イベントは、「Webサービス全盛の今こそ、エンジニアリングについて本気で語る場が欲しい」というエンジニアの声によって生まれた。さまざまな切り口で「受託開発の未来を考える」シリーズイベントで、全5回を予定している
特許庁の基幹システムはなぜ失敗したのか。元内閣官房GPMO補佐官、萩本順三氏の述懐
特許庁が進めてきた基幹系システムの刷新プロジェクトが失敗に終わり、開発に投じた約55億円が無駄になってしまったことが、先週相次いで報じられました。 ［スクープ］特許庁、難航していた基幹系刷新を中止へ - ニュース：ITpro 朝日新聞デジタル：費やした５５億円、水の泡に 特許庁がシステム開発中断 - ビジネス・経済 このプロジェクトに「内閣官房GPMO（ガバメントプログラムマネジメントオフィス）補佐官」の肩書きで2009年まで民間から参加した萩本順三氏（現 匠BusinessPlace 代表取締役社長）がFacebook上で当時を述懐しつつ、失敗の要因を分析していました。今後、失敗プロジェクトを繰り返さないためにも、重要な発言として本人の許可をいただいてまとめました。 特許庁の情報部門に幾度も中止を迫った 萩本順三氏の発言の主要な部分を引用します。 内閣官房GPMO（ガバメントプログラムマ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
「情報システム産業では、2000年代後半から協力会社を中心として労働環境の悪化が相次ぎ受託開発ビジネスの限界に直面。丸投げ委託、多重下請けと人月ビジネスの横行等により、業界全体の魅力が低下した」という経済産業省の産業構造審議会の公式見解について
ComputerworldとCIO Magazineは閉鎖しました
SIerからWebエンジニアへの失敗しない転職方法
