みずほ銀行のマルチベンダー化について解説する - novtan別館
はてブではすでにボロクソ言われてますね。フラグ立ちまくりと。ちょっとこれは解説せねばなるまいか… 以下はすべてとある人からの伝聞です。伝聞なんだってば。 みずほ銀行が次期システムの開発をマルチベンダー体制で進めることが日経コンピュータの取材で判明した。富士通、日立製作所、日本IBM、NTTデータの4社に分割発注する。 ［スクープ］みずほの次期システムはマルチベンダー、4社に分割発注 | 日経 xTECH（クロステック） 周知の話だけすると、現行システムにおいては 勘定系（ホスト）…富士通 営業店端末システム…富士通 インターネットチャネル（ダイレクトバンキング）…IBM 情報系システム…IBM 周辺系（中継系）…IBM 外部接続系…日立 コーポレート銀行勘定系…日立 等々、すでにここに出てきているベンダーがマルチベンダーの状態で仕事をしている。また、ここ重要なところだと思うけれども、ベンダ
笑ってはいけないSIer 抽出
Kenji HASUNUMA "btnrouge" @btnrouge ベンダーがサポートを打ち切ったミドルウェアを「安定版」と信じていつまでも使い続ける。そしてバージョンアップの時に痛い目を見る（その上結果しくじったら会社の信用を失う）。 #笑ってはいけないSIer 2011-11-12 05:22:25
IT業界就職偏差値ランキング
2013年 IT業界就職ランキング 最終更新日：2012/1/28 ☆☆☆☆☆☆☆☆☆☆☆☆☆☆ 2013年 IT業界就職偏差値ランキング ☆☆☆☆☆☆☆☆☆☆☆☆☆☆ ━━━━━━━━━━━━━━━（Sランク：ネ申の領域）━━━━━━━━━━━━━━━ ﾗﾝｸ 企業名 社員 年齢 年収 勤続 . 売上高..離職率 特徴 75 [Google] 19000人 ---歳 . ---万 --年 ---億 --％ 71 IBM（東京基礎研）. 200人 ---歳 . ---万 --年 ---億 --％ 70 NTT研究所. ---人 ---歳 . ---万 --年 ---億 --％ 69 [Microsoft] 2383人 ---歳 . ---万 --年
SIビジネスの流れ - @ledsun blog
システムインテグレータ（SI）のビジネスは大きく以下のような流れで進みます。 集客 営業 要件定義 製造 検収・請求 フォローアップ 集客 どんなビジネスでも同じですが、まずは見込み客を集めます。システム開発に興味を持ったお客様を探しアポイントを取ります。よく使われる手法に商品・サービスの説明をするテレアポ、割引を謳ったDM、自社の推す技術のセミナー、役員が個人的に懇意にしている既存顧客の紹介があります。会社の規模やブランドにマッチした手法を選ぶ必要がありますが、会社が成長にするにつれ手法を変えていかなければいけないのが難しいところです。 営業 アポイントの取れたお客様に顧客に直接、自社の提供するサービス、商品の説明を行います。また会社の紹介も同時に行います。お客様がある程度の金額を掛けてソフトウェア開発を行いたいと意思表示をされた場合に次の段階に入ります。そこで現状の課題を聞き出します。
SI業界で技術者が軽視されてしまうのは何故なのか - GoTheDistance
日本のSI業界でこそ、専門の技術者の必要性がもっと見直されるべきではないのか？ - 達人プログラマーを目指してを拝読しました。この手の議論は定期的に出てくる根の深い問題でありまして、1億年と2000年前から多くの方に言及されています。しかし、それほど大きい問題であるということです。一概にああしろこうしろで片付く問題ではありません。 色々論点はありますが、「技術を売って社会貢献している業態なのに、一番重要な技術者を軽視するってどういうこと？」という１点に集約でき、上記エントリの主題も同じです。技術onlyの専門家の存在が認められないのが問題だと。しかしですね、「技術者そのものを売ってるんだから、軽視云々を言ってもどうしようも出来ない」という果てしない平行線を辿っていることが見えているでしょうか？ブルーハーツの「弱いものたちが夕暮れ 更に弱い者を叩く」というフレーズが思い起こされます。 技術者
ＩＴサービスのビジネスモデル
ＩＴサービスのビジネスモデル ５月になって上場IT企業の決算発表が続いています。ITProによれば、業績の二極分化が進んでいるということです。ＳＩ企業においても同じ傾向で、NTTデータ、ＮＲＩ、ＣＳＫが好調を持続し、ＣＴＣやＮＳＳＯＬなどが増収増益に戻っていますが、ＴＩＳ、ユニシス、富士通ビジネスシステム、ＮＳＷなどが不採算案件のために低迷しています。総合ベンダーの日立、ＮＥＣ、富士通は、相変わらず一部事業の赤字を理由として、元々低い利益率を更に減少させています。数万の社員が必死に働いて数兆円も売り上げた結果が、赤字や数百億円の利益です。いっそ米国ＴＢでも買って、寝ていた方が株主に還元できるではないかと思う状況です。我国には２千社を超えるＩＴサービス企業がありますが、１０年以上も新たなビジネスモデルを捜し求めてきました。しかし、まだ、見つかっていません。 http://itpro.nikk
「情報システムのパフォーマンスベース契約に関する調査研究」報告書の公表について（METI/経済産業省）
本件の概要 経済産業省では、情報システムの取引において、現行の「人月方式」以外での価格決定方法を模索するため、情報システムの付加価値に着目して価格を決定する「パフォーマンスベース契約」について検討を行ってまいりました。 今般、「情報システムのパフォーマンスベース契約に関する調査研究」報告書として取りまとめましたので、公表いたします。 担当 商務情報政策局 情報処理振興課 公表日 平成21年7月31日(金) 発表資料名 「情報システムのパフォーマンスベース契約に関する調査研究」報告書の公表について(PDF形式：12KB) 報告書(PDF形式：2,175KB) Acrobat Readerをダウンロード（Adobeサイトへ） このページの先頭へ
経産省が脱・人月を目指す「情報システムのPBCに関する調査研究」報告書を公開
報告書は「現行の人月をベースにした価格による契約では，ユーザーとベンダーの双方が価格に対して不信や不満を感じている」とし，「人月積算を前提とした固定価格のみでは，ベンダーの品質向上や創意工夫などへのモチベーションは生まれない。さらに，ユーザーにとって経営層に説明できない価格では，投資の妥当性を提示できず，投資意欲そのものを減退させてしまう」と，人月の問題を指摘している。 そしてPBCではユーザーにとっては「無駄な投資が減る等，適正な価格でのIT投資ができる」，「目的を共有することから，ベンダーの積極性を期待することができる」，ベンダーにとっては「システムの効果に応じた適正な対価を得ることができる」，「人月ベースの契約から脱却することで，付加価値の創出や効率化に対するモチベーションが向上する」といったメリットがあるとする。 PBCのデメリットとしては，ユーザーにとっては「契約時に価格が確定せ
システム開発に欠かせない契約の基礎知識まとめ - GoTheDistance
先日識者の方に色々教わったのでメモっておきます。知ってそうで知らない、元々よくわからない、そういう方に向けてまとめてみました。 僕がSIにいた頃は大抵｢基本契約｣と｢個別覚書｣ってのがありました。納期とかお金とかそういうのは個別覚書に書かれたりしていました。 開発の契約体系 ｢仕様策定〜開発まで｣と｢保守運用｣で別契約にすることが多い。 ｢仕様策定フェーズ｣で1つの契約にして、別に新しく契約を締結しなおせるほうが望ましい。リスクが低減できる。 仕様策定までは準委任、開発は請負、保守運用は準委任という契約が多い。 ちなみに準委任は｢事務作業の代行｣という意味合い。委任は｢法的効力がある作業｣の代行。サムライビジネスは後者が多い。 別に運用が事務作業とイコールじゃないけど、成果を問わないタイプの契約の場合は役務提供という位置づけになる。 かといって契約で｢僕らのコンサル案を僕らが実施し成果が出
システム開発の見積 - OKWAVE
当方、地方で働くSEです。 最近開発の見積をやるようになったのですが、 営業からは毎回高いと言われてしまいます。 システム開発はピンからキリまであって、全く同じシステムを開発をすることはほぼありません。 なので、仮に今まで開発したシステムそれぞれの開発にかかったお金が記録として残っていて、それらを参考にできたとしても、見積る人本人の感覚による見積になってしまいます。 通常は、感覚だけの見積は許されないので、生産量と生産性を算出して上司や営業に説明するのですが、営業はそういった数値よりも金額を気にするので、極端に言うと、感覚だけで見積っていようが、でたらめな生産量と生産性を出していようが、安ければどうでもいいのです。 見積には、少なからずリスクを含めると思いますが、それが高いと言われるのです。 毎回開発内容が異なるので、どんな人でも多かれ少なかれリスクを入れると思うのですが・・・。 たとえ過
保守開発の見積もりはどうする？
保守開発による見積もりは，新規開発とは違った難しさがあります。母体部分と，修正を加えるエンハンス部分を分けて見積もる必要があるからです。今回は，保守開発における見積もりについて考えてみましょう。 最近は，ゼロからソフトウエアを作るプロジェクトの方がむしろ少なくなってきました。すでに企業活動のほぼ全域にわたってIT化されていること。システム開発にもスピードが求められ，既存システムに手を加えて要求を実現することが多くなったこと――などが理由です。 ところが，保守開発における見積もり方法は，発展途上にあります。このため見積もりに戸惑うエンジニアは実に多いことでしょう。 エンハンス部分の見積もりは，新規開発と同じです。問題は，母体部分の見積もりをどう行うかです。そこで私は，以下の三つの方法を提案します。 (1)母体係数法 母体部分の品質を保証するために必要な作業工数を，母体規模をベースに算出する方
システム開発の見積
当方、地方で働くSEです。 最近開発の見積をやるようになったのですが、 営業からは毎回高いと言われてしまいます。 システム開発はピンからキリまであって、全く同じシステムを開発をすることはほぼありません。 なので、仮に今まで開発したシステムそれぞれの開発にかかったお金が記録として残っていて、それらを参考にできたとしても、見積る人本人の感覚による見積になってしまいます。 通常は、感覚だけの見積は許されないので、生産量と生産性を算出して上司や営業に説明するのですが、営業はそういった数値よりも金額を気にするので、極端に言うと、感覚だけで見積っていようが、でたらめな生産量と生産性を出していようが、安ければどうでもいいのです。 見積には、少なからずリスクを含めると思いますが、それが高いと言われるのです。 毎回開発内容が異なるので、どんな人でも多かれ少なかれリスクを入れると思うのですが・・・。 たとえ過
IT業界の裏話: 日本のIT企業が雑魚である理由
名前： 吉澤準特 職業： ＩＴコンサルタント 連絡： メルマガに記載 自己紹介のコメント： 自己紹介の詳細はコチラ→■ 外資系企業に住む住人の視点からIT業界の出来事を伝えます。ご興味のある方は、メルマガの登録をお願い致します。 Twitterやっています。 →http://twitter.com/juntoku_y マイナビニュースで「IT業界裏講座」を掲載中です。そちらもヨロシクお願い致します。 →コンサル直伝－IT業界”裏”講座 EnterpriseZine（翔泳社）で記事掲載中です。そちらもヨロシクお願い致します。 →ファシリテーションで会議を変える/ITIL解体新書/デキるシステム担当者のスキルノート 2010年7月末、日本能率協会マネジメントセンター（JMAM）より「フレームワーク使いこなしブック」を上梓しました。仕事の質と効率を高める思考の枠組み・フレームワーク。本書は、架空
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
