［スクープ］みずほの次期システムはマルチベンダー、4社に分割発注
みずほ銀行が次期システムの開発をマルチベンダー体制で進めることが日経コンピュータの取材で判明した。富士通、日立製作所、日本IBM、NTTデータの4社に分割発注する。ハードウエアの調達とアプリケーションの開発を分離し、さらに預金や融資といった機能ごとに開発委託先を変える。大手4社に発注を分散させることで、総額4000億円を超えるとみられる大規模プロジェクトにおける技術者確保などに万全を期す。 委託内容と発注先との関係は次のとおりだ（図）。勘定系システムの中核をなす「流動性預金」のアプリケーション開発は、富士通に委託する。富士通はみずほ銀が現在使っている勘定系システム「STEPS」の開発元である。 流動性預金のアプリケーションの動作プラットフォームには、日本IBM製メインフレームを使う。みずほ銀は「CIF（カスタマー・インフォメーション・ファイル）」や「処理フロー制御」など、各アプリケーション
IT業界で無事にいたいなら銀行に関わるな
IT業界で無事にいたいなら銀行に関わるな 3Kとか7Kとか言われているが、底辺の会社にいなければそれほどひどくないし、正直どうでもいい。しかし関わった人は皆同じことを口にする。 銀行には関わるな。特に最新技術に詳しい人ほど真っ先に壊れる。すぐに逃げ出せ。 新規開発が出来ると思うな。10年以上経ったシステムのお守りがほとんど。当然コードは見るに堪えない。そのくせ仕事はたくさん来る。ほとんどがバグ修正か機能拡張。そして時間のほとんどはテストで消える。1行修正するだけでも数週間のテストが普通。OSが変わったら一年中テストで潰れる。 休みが人並みに取れると思うな。深夜まで仕事をするのが当たり前。GWと正月はないと思え。しかも一回や二回ではなく仕事辞めるまでずっとだ。 仕事の出来を褒められることを期待するな。動いて当然、止まったら新聞沙汰だ。当然直るまで何日でも徹夜。 キャリアの役に立つと思うな。業
クライアントよ、お前の依頼の大変さを思い知れ！これが「デザイン修正」だ！
昨日紹介したデザインができるまでの過程をまとめたイラストが多くの反響をもらった。これを機にデザイナーに優しくしよう！ 元々@nerichichiさんという方が描いたイラストらしいのだが、その方の別の作品でクライアントが当たり前のように言ってくるデザイン修正がどれだけデザイナーにとって大変なのかを描いた漫画があったので、紹介する！これも物凄く納得感のあるイラストだ…。 密にコミュニケーションを取り、最高のアウトプットを これを見るだけでデザイン修正の大変さに納得すると同時に今後自分も発注する側として気をつけよう、と改めて心に誓った。 【img via 練乳の投稿画像】 クライアントによる大量かつ細かい要望に応えつつも複数回に渡る校正。最後にできあがったものは「絶妙なバランス」を持って成り立っているのを、根本的な要素に対して当たり前のようにデザイン修正を求めるクライアント。 もしあなたがデザイ
SIで得るものはあるのか？ - 急がば回れ、選ぶなら近道
「SIで得るものはあるのか？」 おそらくここ10年以上、日本各地で自問自答された問いでありまして。かくいう自分もその一人であります。デスマの度に、ここまでやる意味はあるのか？赤字の度に、そこまでやる意味はあったのか？ 思わなかった人はいないはずです。特にここ数年は、見るもの聞くもの、酷いプロジェクトが自分の周りでも多く、「いいから、そのまま回れ右」という行動パターンの機械学習全開です。（遠い目 他方、「構築をやらないと確実に実装力は落ちる」こういう声もあるでしょう。これもまた真実ではあります。特に、SIの中身丸投げモードのスイッチが入りっぱなしで液漏れ寸前なところは、もはや経験不足を通り越して「リバース・プロキシーって何をするんだっけ？」って真顔で聞くPMの方もいらっしゃる状態もありまして。実際にやらないとわからない、ということは普通におきます。特にアーキテクチャやインフラ周りは、そうなっ
コードレビューの歴史 - プログラマの思索
コードレビューの歴史に関して良い記事があったのでメモ。 【元ネタ】 コードレビューいろいろ - steps to phantasien コードレビューは非同期ペアプログラミングとも言える。 二人の目を必ず通すことで、ソースの品質をチェックする。 ソースインスペクションを真面目にやるGoogle、MS: プログラマの思索 コードレビューはペアプログラミングの代替手段: プログラマの思索 コードレビューでよくあるのは、ウォークスルー。 コードレビューされる人が司会者となり、別のレビューアにコードレビューしてもらう。 ウォークスルーは、司会者によほどの力量がない限り、あまりうまくいかない。 一人の人の役割が大きすぎるからだ。 「Code Complete第2版―完全なプログラミングを目指して」のような本では、インスペクションが推奨されている。 インスペクションは、モデレータ、書記など役割分担がは
技術革新は何のためにあるのか？ - 急がば回れ、選ぶなら近道
技術革新は須く斬新的なものであるべし、という肩に力の入った信念の人は流してください。ちょっと、力の抜いた小ネタなので。 最近というかここ10年来、いわゆる業務系のシステムに関わっていてよく思うことではあります。特に最近、NoSQLやHadoopといった「新技術」が登場するにつけて強く感ることではあるのですが、なんというか、「こんな感じ」のことができます、というようなプロダクトアウト的でありながら、かつ、漠然とした抽象的な話が多すぎる気がします。要は、全般的に問題の設定が苦手だよなということです。 特定の技術の各論はともかく、まず、大上段に構えると、実はITでは一般の人が想像する以上にユーザーとベンダーで期待ギャップがあります。ユーザーから見ると、大抵は「こんなこともできないのか？」ということがごく普通にできません。一方、一般のTVとか報道とかは、スパコンや遺伝子やビッグデータや、なんやらか
受託開発脳から自社開発脳へ切り替えの7つの壁
velc: これ、思ったより大変でした。 自分含め、うちにいるメンバー全員、 これまでの経歴では受託開発をメインにやっていたため、 自社サービス開発の経験はかなり少なかったです。 でも、ヴェルクでは、受託開発をしつつ、 時間を作って色々と作っていこう、というスタンスのため、 起業直後から色々と企画を考えていました。 でも、受託開発脳から自社開発脳への切り替えは思った以上に苦労しました。 要件定義等でお客さんと一緒に要件を考えたりしますが、 最終的に「やりたい事」を持っているのはお客さんになります。 要件定義の前の企画やグランドデザインと言った分野は お客さんの戦略に沿ったものになります。 だから、最終的には、誰かが答えを持っている事が殆どです。 そのため、ゼロからそれを考える事があまりないんですよね。 いざ、ゼロから自分たちで企画を考えようと思った時、 いろいろと壁がありました。 1. 本
Joel on Software - やさしい機能仕様 - パート 2: 仕様書とはどんなものか?
Joel Spolsky ジョエル・スポルスキ 翻訳: Yasushi Aoki 青木靖 2000/10/3 (パート1はもう読んだ? 読んでなければ、ここにある。) このアーティクル･シリーズで扱っているのは機能仕様であって、技術仕様ではない。人々はこの2つを混同している。標準的な用語があるのかどうか知らないが、私がこれらの用語を使うときに意味しているのは以下のことだ。 機能仕様書は、ユーザの観点から製品がどのように動くか記述する。それはどのように実装されるかは問題にしない。それは機能を話題としており、画面とか、メニューとか、ダイアログとかいったものの仕様を定める。 技術仕様書は、プログラムの内部の実装について記述する。それはデータ構造、関係データベースモデル、プログラミング言語や開発ツールの選択、アルゴリズムといったものを話題としている。 あなたが製品を隅から隅までデザインするとき、最
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
