takeda-soft.jp 2023 著作権. 不許複製 プライバシーポリシー
Photo by Robert Tadlock 今回のpaiza開発日誌は片山がお送りします。 SIerに在籍しているエンジニアで、技術(開発)を中心としたキャリアを積んでいくために、SIerからWeb業界(Webサービス提供系)に転向/転職しようと思っている方は近年増えています。そんな方向けに、SI⇒Web転向で「失敗してしまう人の特徴」と、「上手くいく人の特徴」についてまとめてみました。 ■SIからの人材流出は増えているが、Web転向は狭き門 SIer⇒Web業界への転向成功者、失敗者の特徴を見てみる前に、まずはSI業界とWeb業界の採用動向について見ていきましょう。 昨今、特に飲食業界等を中心として人材不足が叫ばれていますが、IT業界も成長産業のため、常に人材が不足していると言われている業界です。2014年9月18日の日経新聞でも「IT分野の派遣『月収100万円』でも集まらず」という
「SIで得るものはあるのか?」 おそらくここ10年以上、日本各地で自問自答された問いでありまして。かくいう自分もその一人であります。デスマの度に、ここまでやる意味はあるのか?赤字の度に、そこまでやる意味はあったのか? 思わなかった人はいないはずです。特にここ数年は、見るもの聞くもの、酷いプロジェクトが自分の周りでも多く、「いいから、そのまま回れ右」という行動パターンの機械学習全開です。(遠い目 他方、「構築をやらないと確実に実装力は落ちる」こういう声もあるでしょう。これもまた真実ではあります。特に、SIの中身丸投げモードのスイッチが入りっぱなしで液漏れ寸前なところは、もはや経験不足を通り越して「リバース・プロキシーって何をするんだっけ?」って真顔で聞くPMの方もいらっしゃる状態もありまして。実際にやらないとわからない、ということは普通におきます。特にアーキテクチャやインフラ周りは、そうなっ
近年、ユーザー企業の「自社サービスの内製化」や「システムのクラウド化」などに伴い、SIerへの要求レベルが高まってきている。ここ2年で4000億円の減益といわれるSI業界の中で生き残っていくためには、どんなエンジニアスキルを磨いていけばいいのか。 第1回 ※本記事は、「エンジニアtype」のコンテンツを一部@IT表記に統一した上で、許可を受けて転載するものです。 インターネット広告代理事業を皮切りに、各種メディアサービスを手がけるサイバーエージェント。同社はソーシャル系サービスを提供する企業の中でも、特にシステムの内製化を強力に推し進めていることで知られている。 最高技術責任者を務める佐藤真人氏によれば、システム内製化の背景には、分業主義的な従来型のSIerに対する問題点を指摘しているかのような意図が見え隠れしていた。 サイバーエージェント CADC推進本部 最高技術責任者 執行役員 佐藤
もう何周目になるのでしょうか。「情報システム部門が経営に貢献できていない」というこの手の話は。 システム部門再生 - 経企部門が吐露する「システム部門への不満」:ITpro なんか色々ダメだしされていますが、重要なポイントは1つだけです。システム部門がビジネスに貢献するためには、自社の事業に対する理解が必要なだけではなく、その遂行手段である業務プロセスの理解が必要だ、という圧倒的な事実があることだけ。WhatとHowはクルマの両輪だと。で、この手の問題はシステム部門の問題ではなく経営の問題だという水掛け論が水びだしになるまで色んな人にされてFUDが残るのも味わい深いポイントであります。 自分達で管理できないものを改善できるわけが無い システム部門が業務プロセスの改善に貢献できない理由。突き詰めれば1つだけです。自分達で管理できずに、安易に外部に投げているからです。管理できないシステムをたく
「絶対落ちないシステムを作れ」という要件に、開発者たちはどう対応したのか。東証arrowheadの当事者が語る 「素人的に言えば、絶対落ちないシステムを作れ、というのがユーザーから見た要求条件」と発言したのは、東京証券取引所の株式売買システム「arrowhead」開発のプロジェクトマネージャ 宇治浩明氏。 東京証券取引所は2005年にシステム障害を起こし、取引が一時全面停止するという事態を引き起こしました。そのため2010年に稼働を開始した新システム「arrowhead」の開発では、高性能と高可用性という高い品質を実現することが絶対の目標となっていました。 東京証券取引所と、arrowheadの開発に当たった富士通。両社はどのように開発プロジェクトを通して高いソフトウェア品質を実現したのでしょうか? 9月9日、早稲田大学 西早稲田キャンパスで行われた日本科学技術連盟主催「ソフトウェア品質シ
IT系上場企業の平均給与を業種別にみてみた 2011年版 ~ パッケージベンダ、SIer、モバイル企業編 IT系企業で給与が高いのはSIerなのか、パッケージベンダなのか、それともネットベンチャーなのでしょうか。前編のネットベンチャー、ISP/ホスティング、SEO/SEM、アフィリエイト企業などに続き、今回はパッケージベンダ、SI/システム開発、ゲーム開発、モバイル関連の企業についてみていきましょう。 この記事は、Yahoo!ファイナンスの「業種別銘柄一覧:情報・通信」および金融庁の「EDINET」で公開されている企業の有価証券報告書から、従業員数、平均年齢、平均年収などの情報を収集、Publickeyが独自の判断で主な企業をピックアップし業種を分類、平均給与が高い順に並べてみたものです。年収の単位は千円です。 この記事は「IT系上場企業の平均給与を業種別にみてみた 2011年版 ~ ネッ
国内の主要なシステムインテグレータやソフトウェア開発企業で構成する一般社団法人 情報サービス産業協会は、クラウドがシステム開発などの情報サービス事業に与える影響や課題を整理したレポート「クラウドコンピューティングが情報サービス事業者に与える影響とビジネス拡大に向けての提言」(PDF)を、公開しました。 本レポートは、システムインテグレータやソフトウェア開発企業の立場からクラウドによるビジネスの影響を分析し、それに対応したビジネスモデルを提案している点が特徴です。 クラウドの登場などによる「所有から利用へ」の流れは、サーバなどハードウェアの販売や開発案件の減少など、システムインテグレータが依拠してきたビジネスモデルをおびやかそうとしています。その現状分析と今後の対応策をシステムインテグレータ自身がどう考えているのか、このレポートから垣間見ることができます。 新たな4つのビジネスモデルを提言
昨日15日付の「記者の眼」に続き「システム内製」に絡む話を掲載するが執筆者も内容も異なるのでご了承頂きたい。 「ユーザーが主体的にシステムを開発せよというテーマで“IT企業参加お断り”のシンポジウムを開く真意は何か。中小のIT企業は不要ということか」。 中小IT企業の経営者を集めた勉強会を企画している方からこう尋ねられた。意図を説明したところ、それを経営者の前で述べてほしいと言われ、全国ソフトウェア協同組合連合会(JASPA)で先日話をしてきた。 中小IT企業と書いてみたものの「ITエンジニア」と同じくらいなじめない。やはりソフトハウス、システムズエンジニアと書きたいところである。 勉強会で話したこと 勉強会では、まず「ユーザー主体開発」に関する筆者の活動内容を紹介した。骨子は以下の通りである。 ユーザー主体開発に関する諸活動 6月1日付で編集委員に加え「研究員」の肩書きが付いた。ユーザー
1 : ◆YKPE/zzQbM @ゆきぺφ ★:2011/08/27(土) 23:36:03.54 ID:??? 金融庁が7月上旬、銀行に対してコンピューターシステムのリスク総点検を 要請した。またひとつ当局への報告事項が増えたと、業界では頭を抱えている。 金融庁はかねてから、こうした銀行システムのチェックに乗り出そうとしていた。 そのきっかけを作ったのは、東日本大震災の直後に起きた、みずほのシステム障害。 要請文の冒頭に「今回の主要行のひとつで見られたシステム障害」と明記して いることからも、うかがい知れる。 各行は今月末までに報告書を提出しなければいけないので、地方銀行関係者は 「システム部門はお盆休み返上。しかも提出後に当局からヒアリングを受けるので、 そのことを念頭に入れて(報告書を)作成するので悩ましい」と話す。 金融庁が求めているのは、経営陣がシステム障害の未然防止と障害発生時
まず現状の認識は以下の通り 1.20-30代の就業人口の減少これは大前提になる。 また情報共有も進むためよりブラックな会社が 人を集めること自体のハードルがあがる。 結果として、人員を集めるということがより厳しくなる。 これはITに限らず、労働集約的産業全体の課題でもある 2.能力格差の拡大今の40-50代よりも間違いなく、現状の20-30代は 勉強している人としていない人の格差は広がっている。 ゆとり云々とは別に、社会的なプレッシャーから、 むしろ勉強しないと勝ち残れないという強い意識のある集団と、 ゆるふわほんわか草食集団の差が非常に非常に広がっている 3.資源の拡大要するに、割とハード・リソースに余裕が出てきている まず、クライアントサイド。 要はなんでもできる状態になりつつある。 jsあたりはほぼ無法地帯の感もある。 一時、jsでOSみたいのまでいけるぜ、というデモもあったが 技術
今のシステム開発の業界における価格は、実はその提供している価値に対して、コストが高すぎるのではないか、と以前から考えていました。IT投資に対するパフォーマンスの比率が著しく悪い、摩擦係数が異常に高い気がします。それが何故なのかを考えてみました。(今回は問題提起だけなので悲観的なようですが、別途私の提案編を書く予定です) 色々なお客様とお話しさせて頂くと、かなりの予算投資をしてシステムを構築した後に、実際に使い始めると修正したい箇所が出てくるもので、その改修をベンダに依頼すると想像以上の金額の見積りが返ってきて驚いた、という話をよく聞きます。 実際に、画面の一部のキャプションを少し直すだけでも、数万円とかの見積が出てきた、というのも大袈裟な話ではないのでしょう。そんな経験をしてしまうと、より一層に構築時に確実に作って、改修しなくて済むように、と考えてしまっても仕方ありません。 また、システム
週末スペシャル - “スルガ銀−IBM裁判”を振り返る:ITpro スルガ銀行がIBMを訴えたのは債務不履行とのこと。つまり、債権者であるスルガ銀行が「IBMの責任で」自分たちが望むシステムを作り上げることが出来なかったと言っております。債務者(IBM)の責任である場合は、スルガは契約の解除や、不履行により生じた損害を請求することが民法で認められているそうです。スルガから契約解除&損害賠償という強烈なワンツーパンチが飛んでいます。 要件定義を3度もやり直すという記述がありましたが、恐らく要件と要求が入り交じった「こーゆーことができるようになりたいです!」という夢と現実の区別が付かない仕様書があって、結局そいつの着地点がスルガもIBMも決められず「そのうちどうにかなるやろ」と宙ぶらりんのまま続けていき、現行業務とのギャップが後から後からザックザク出てきて、そのギャップに+αされた機能が特盛り
勘定系システムの開発失敗を巡り、スルガ銀行が日本IBMに111億円超の支払いを求めた裁判の口頭弁論が7月4日、東京地方裁判所で開かれた。同裁判では非公開の「弁論準備手続」が続いていたため、公開形式の口頭弁論は1年4カ月ぶりだ。 口頭弁論で争点となったのは、要件定義の成果物についてである。具体的には、中止したプロジェクトで作成した要件定義書が、当初導入を予定していたのとは別の勘定系パッケージを使う際にも使えるかだ。スルガ銀と日本IBMの双方が、証人を一人ずつ出廷させて、それぞれの主張を述べた(図)。 スルガ銀の主張は「使えない」というものだ。出廷したスルガ銀の米山明広プロジェクト担当部長は次のように証言した。「現在、新たな勘定系刷新プロジェクトを進めているが、そこでは、日本IBMと共に作成した要件定義書は一切、再利用できなかった」。新たなプロジェクトとは、日本ユニシスのオープン勘定系パッケー
[後編]人とITでサービスを極める 21世紀型のビジネス確立へ りそなホールディングス 取締役兼代表執行役会長 細谷 英二氏 顧客視点なら全体最適になる 顧客視点に立つからこそ、顧客の接点である部門ごとに最適化されてきた、といった反論も聞こえてきそうですが。 それは、部門ごとに顧客層が全く違うと考えるからです。ところが現実の顧客は、例えばオーナー経営者であれば、個人部門と法人部門の両方にとっての顧客です。つまり、その顧客についての情報を共有化できるシステムが必要です。ですから縦割りの壁を破って、全体最適のシステムを構築できないといけません。情報を共有化すれば、システムの構築コストも下がるわけです。 全体の最適化により、効率化と顧客満足の両立が図れるというわけですね。 もちろん、システムだけでカバ ーできるわけではありません。顧客は経営課題や生活設計についても、本当に信頼できる人、金融知力の
これまで数回にわたって、SEの販売・提案活動に関することを書いた。現役時代からずっと、日本の「SEのあり方」と企業の「SEの扱い方」に強い疑問を感じていたからである。 事実、現在も多くのSEが「営業とSEの関係」で悩んでいる。特にSEが販売・提案活動に参画した時の悩みは大きい。筆者の時代もそうだったが、現在もSEからその類のグチを結構聞く。例えば「営業は売ればよいと思っているからSEがシステム開発で苦労する」とか「営業は技術が分かっていないから後でSEが困る」といった話だ。中には「実際は我々SEが売っているのに、営業はいい格好ばかりする」と言うSEさえいる。 このような声が出てくるのは、きっとSEと営業との関係がうまくいっていないからだと思う。IT企業にとっては深刻な問題である。生産性が下がるし、下手をするとお客様に迷惑をかけかねない。以下、読者の方への問題提起も含め、「SEと営業との関係
最近、Amazon Beanstalkが発表されて、PaaS領域が一段と盛り上がってきました。 業務系に強いForce.com、ソーシャルアプリなどコンシューマ系サービスに強いGoogle App Engineあたりが有名でしたが、最近は選択肢がかなり増えました。 この記事を書いている最中にもちょうど以下のような記事がでていて、PaaSに対する注目度が高いことがうかがえます。 http://www.publickey1.jp/blog/11/google_app_engine_paas.html http://www.publickey1.jp/blog/11/_java_paas.html 上記の記事でだいたいよいところ、難しいところがまとまっているのですが、今日はGoogle App Engine、Force.com、AWSのサービス、それぞれ実サービスの運用や受託開発で使った経験や、
日本のSI業界でこそ、専門の技術者の必要性がもっと見直されるべきではないのか? - 達人プログラマーを目指してを拝読しました。この手の議論は定期的に出てくる根の深い問題でありまして、1億年と2000年前から多くの方に言及されています。しかし、それほど大きい問題であるということです。一概にああしろこうしろで片付く問題ではありません。 色々論点はありますが、「技術を売って社会貢献している業態なのに、一番重要な技術者を軽視するってどういうこと?」という1点に集約でき、上記エントリの主題も同じです。技術onlyの専門家の存在が認められないのが問題だと。しかしですね、「技術者そのものを売ってるんだから、軽視云々を言ってもどうしようも出来ない」という果てしない平行線を辿っていることが見えているでしょうか?ブルーハーツの「弱いものたちが夕暮れ 更に弱い者を叩く」というフレーズが思い起こされます。 技術者
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く