タグ

itとシステム開発に関するblueribbonのブックマーク (5)

  • みずほ、新システム夏完成へ 2度の障害、統合後初統一 - 共同通信

    みずほフィナンシャルグループ(FG)が開発中の次期システムが今夏に完成する見通しとなったことが2日、分かった。第一勧業、富士、日興業の3銀行が2000年に経営統合して発足したみずほグループのシステムは、2度の大規模障害を経て、初めて統一される。運用開始は来年度以降になるとみられる。 次期システムの開発は、02年と11年に大規模なシステム障害を起こし、11年は当時の銀行トップが引責辞任する事態に発展した、みずほグループにとって最大の経営課題だ。だが、2度にわたる開発の延期で当初の想定以上の資金と人員を投入しており、収益を圧迫していた。

    みずほ、新システム夏完成へ 2度の障害、統合後初統一 - 共同通信
    blueribbon
    blueribbon 2017/05/03
    IT界のサグラダファミリア、遂に完成へ!? w
  • IT業界で無事にいたいなら銀行に関わるな

    IT業界で無事にいたいなら銀行に関わるな 3Kとか7Kとか言われているが、底辺の会社にいなければそれほどひどくないし、正直どうでもいい。しかし関わった人は皆同じことを口にする。 銀行には関わるな。特に最新技術に詳しい人ほど真っ先に壊れる。すぐに逃げ出せ。 新規開発が出来ると思うな。10年以上経ったシステムのお守りがほとんど。当然コードは見るに堪えない。そのくせ仕事はたくさん来る。ほとんどがバグ修正か機能拡張。そして時間のほとんどはテストで消える。1行修正するだけでも数週間のテストが普通。OSが変わったら一年中テストで潰れる。 休みが人並みに取れると思うな。深夜まで仕事をするのが当たり前。GWと正月はないと思え。しかも一回や二回ではなく仕事辞めるまでずっとだ。 仕事の出来を褒められることを期待するな。動いて当然、止まったら新聞沙汰だ。当然直るまで何日でも徹夜。 キャリアの役に立つと思うな。業

    IT業界で無事にいたいなら銀行に関わるな
  • 南米発のツールがIT業界に与えるインパクト

    「プログラマはもう要らない」。大手物流会社のシステム子会社で新技術の社内展開を進めるマネージャーはこう言い切る。ここでいうプログラマとは、企業情報システムの開発プロジェクトでプログラムを作成する担当者を指す。ある開発ツールを検証したところ、こうした役割の要員は不要との結論に至ったというのだ。 このマネージャーは記者に対して、ツールを導入した場合の効果をこう語る。「様々な開発言語を知っていて、バグのないソースコードを24時間、延々と高速で書き続ける。そんなスーパープログラマを雇ったのと同じ効果が得られる」。 同社が検証したのは「GeneXus(ジェネクサス)」という開発ツールである。ご存知の方はまだ多くないかもしれない。一口に言えば、アプリケーションの自動生成ツールである。データ項目や画面、業務ルールといった設計情報をGeneXusの表記法で入力すると、ソースコードとテーブル定義情報を自動生

    南米発のツールがIT業界に与えるインパクト
    blueribbon
    blueribbon 2010/10/05
    「JavaやC#、Ruby、COBOL、Cなどのソースコードを、設計情報から自動生成する。テーブル定義情報はMicrosoft SQL Server、Oracle Database、DB2、MySQL、PostgreSQLなど各種データベースソフトのフォーマットに合わせて自動生成する。」
  • 見積もり・発注 - 技術情報Wiki

    発注/調達 † 値切ってはいけない 2009.3.6 確かに,プロジェクトには予算が決められており,その予算の枠内でやり遂げる必要がある。どうしても予算と見積もり金額が合わない場合には,入念に価格交渉を行い,発注者と受注者の双方が金額の妥当性について合意した上で確定させるべきなのだ。 そのためには,PMは出てきた見積もりを査定する能力が必要であり,かつ高い折衝能力が必要である。 はじめてのRFP 2008.2.4 調達用語 RFP,SLCP,SPAとか RFP(Request For Proposal:提案依頼書) SLCP−JCP98:Software Life Cycle Process - Japan Common Frame 1998 SPA(Software Process Assessment)

  • SI契約に変革迫る「進行基準」 IT業界に激震走る!:ITpro

    ユーザー企業のみなさんは、システム開発プロジェクトを進める際、ITベンダーに次のような依頼をしたことはないだろうか。 経営判断でシステムの稼働日は決まっている。だが、肝心の要件は固まっていない。「何としても納期を守ってくれ。要件定義と並行して、仕様が固まっている部分から、開発作業に着手してくれないか」。 すでに開発が済んだ部分について、利用部門から大きな仕様変更の依頼が来た。「予算はもう増やせない。申し訳ないが、最初に契約した金額のままで修正してくれないか。次の案件も御社に発注するから」。 新システムの予算を何とか確保した。あとはこの予算でシステムを開発してもらうだけ。「ハードウエア込み、要件定義から運用設計まで、すべて一括で契約してほしい」――。 頻繁とは言わないまでも、システム開発を進めるうえでは“よくある話”だ。問題があると分かっていても、経営層や他部門からの要請で、こうした依頼を

    SI契約に変革迫る「進行基準」 IT業界に激震走る!:ITpro
    blueribbon
    blueribbon 2008/07/01
    「仕様を固めてから開発を発注する、といった作業をユーザー企業が責任を持って行うべき」と指摘する。
  • 1